W3C home > Mailing lists > Public > public-device-apis@w3.org > August 2009

RE: ISSUE-4 (api-versioning): API Versioning [APIs - General]

From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Date: Thu, 27 Aug 2009 12:38:45 +0200
To: Marcos Caceres <marcosc@opera.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
CC: Anne van Kesteren <annevk@opera.com>, Robin Berjon <robin@robineko.com>, "<richard.tibbett@orange-ftgroup.com>" <richard.tibbett@orange-ftgroup.com>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C2890C65C16@OBEEX01.obe.access-company.com>
Hi Marcos,

I am ok with voting, this gives us some guidance for the future.

The only issue is what we vote for and against?
If we vote against versioning, what is then the practical alternative?
Could we then (clearly) identify what we vote for in that case?

Some statistics:

XMLHttpRequest [1] defines 1 interface with 5 methods and 6 attributes.
Additionally [1] states what is left for future [2].

BONDI 1.01 [3] defines a bit more as summarized at [4]:
interfaces: 68,
attributes: 116,
constants: 82,
methods: 177,
typedefs: 24.

The above provides very rough information about the extent of what we are heading for.
When starting the work in DAP I think we should prepare ourselves to cope with that amount of Web IDL, accompanying documentation, state machines etc.
Versioning may help and it is a kind of security policy, just in case we would need to break backwards compatibility due to some technical arguments coming late.

I understand that each vendor wants to differ.
The issue is whether the outcome of DAP, i.e. the documents/standards will be usable for a potential user/developer and how they are going to evolve process-wise.


[1] http://www.w3.org/TR/XMLHttpRequest/

[2] http://www.w3.org/TR/XMLHttpRequest/#notcovered

[3] http://bondi.omtp.org/1.01/apis/index.html

[4] http://bondi01.obe.access-company.com/1_0_3836_108/stats.html

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: Marcos Caceres [mailto:marcosc@opera.com]
Sent: Thursday, August 27, 2009 11:22 AM
To: public-device-apis@w3.org
Cc: Anne van Kesteren; Robin Berjon; <richard.tibbett@orange-ftgroup.com>; Marcin Hanclik
Subject: Re: ISSUE-4 (api-versioning): API Versioning [APIs - General]

Marcin Hanclik wrote:
> Hi All,
> Traditionally  (discussed thoroughly in WebApps and BONDI) I am in favour of versioning.
> My motivation is not based on the need to release new version of the API or syntax or whatever every month or year.
> I would be happy if the standard could stay e.g. in version 1.0 forever.
> The principle is: "give it a name".
> We should clearly identify the parties and rules governing the ecosystem, version of the specification is such a rule for APIs and syntaxes.
> My motivation is purely practical.
> We have a cloud of:
> a) releases of specifications,
> b) incomplete or bad implementations,
> c) contents.
> In DOM there is hasFeature() method, e.g. explicitly used in the DOM3Events.
> If we want to drop versioning then I assume we should also drop hasFeature(), since it is the same problem.
> As stated below by Anne new releases of the specification may break backwards compatibility.
> If it is ok, then I assume we should allow the content to advertise based what (which version of) specification it was developed.
> Content developed against versionless specifications has little chance to survive and be usable if the specification changes.
> It may become a requirement for the software engines to be backwards compatible for practical reasons.
> As you may know, versioning - as a generic issue - is currently discussed in TAG and WHATWG, so we could first look at the arguments there, since my belief is that they are similar to ours.

Discussions around versioning are booooooring and getting us nowhere.
I've personally had it up to here with filibustering around versioning.
We've discussed versioning to death in BONDI, on WebApps, etc. I think
we should just take a vote (or something) and reach a formal resolution
and be done. Then, when either side raises this again, we just point
them to the resolution and move on.

As a process thing. It would be nice to have a place where the group's
resolutions are publicly available. Is there some way to suck
resolutions out of Trackbot?

Kind regards,


Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda


This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Received on Thursday, 27 August 2009 10:39:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:38 UTC