RE: ACCESS' input, was: RE: Proposal for new WG to specify "Concrete APIs"

Hi Thomas,

Thanks for your comments.

>>I don't quite understand what you mean here.  Are you suggesting
>>deployment of draft APIs as working drafts are issued?
The deployment of draft APIs you ask about above is actually the fact. There is simply demand on the market.
I tried to address here the multiplicity of the W3C Working Drafts of the same specification and the time it takes to prepare a final recommendation.
I fully understand that the standardization process may and is lengthy, taken into account the time that is necessary to consult various other groups and organizations. Quality of the specifications is very important.

There are however also other aspects of this process.
Let's take Widgets 1.0 P&C at http://www.w3.org/TR/widgets/ (I know it is not about API, but it depicts the problem well).
The header of this specification states that there were 3 previous versions.
The current editor's draft is even newer, i.e. there are 4 official previous versions of the Widgets 1.0 P&C specification.
The industry has already deployed solutions based on this specification.
The question is: based on which version?
Many vendors claim compliance to Widgets 1.0 P&C.
And the end users / developers work with the software packages that implement Widgets 1.0 P&C.

The question arises: how a developer may discover that the implementation is based on the given version of the Widgets 1.0 P&C Working Draft?
At best it could be done programmatically.
But: no way.
And the spec is still in version 1.0, for almost 3 years. The industry goes very fast now and so the standards could / should go.

So what I would like to suggest for the API specifications - released as a Working Draft, prior to LC / Recommendation - to be appropriately versioned.
For example, let's take Calendar API.
Our target for 2011 would be Calendar API 1.0.
Probably in the course of the spec development between 2009Q3 (e.g. group chartered), 2010Q1 (FPWD) and 2010Q3 (LC), we could have a few working drafts, e.g. every 3 months.
Then my suggestion would be to version the APIs specified in that spec not constantly as 1.0, but maybe we could start at 0.1, step by 0.1 at each release of the WD to arrive to 1.0 for LC.
BONDI has designed an API versioning design pattern, so that the above temporal dependency of the implementation on the specification could be discovered programmatically.
I believe no-one claims that the presumed version 0.1 would be perfect (and is for 1.0, I think), but probably there would be implementations of that API.
So for the purpose of the expectations' management, it should be possible for the application code to know that the underlying engine implements version 0.1 and not e.g. 0.5, to be able to act correctly.
This is all to facilitate the industry adoption and make the life of the users / developers easier.

I am not sure about the relation of the above proposal to W3C process, but I assume there should be no formal obstacles.

Thanks.

Kind regards,
Marcin

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: Thomas Roessler [mailto:tlr@w3.org]
Sent: Wednesday, April 29, 2009 1:21 PM
To: Marcin Hanclik
Cc: Arthur Barstow; Nick Allott; public-device-apis@w3.org
Subject: Re: ACCESS' input, was: RE: Proposal for new WG to specify "Concrete APIs"

On 28 Apr 2009, at 23:54, Marcin Hanclik wrote:

> 2. The scope of the Device API WG should be extensible.

Given the way in which the patent policy and process work, that's not
likely to happen.  However, Working Groups can be re-chartered as they
go, to extend scope and add new deliverables.  That re-chartering
doesn't come cheaply, though, so you won't want to do it too often.

Therefore, it will be important to identify what set of APIs should
take priority for a first round of work, and to put these into the
initial charter.

> As an example please consider that BONDI IF WG defines now 14
> different sets of APIs. There is partial overlapping between those
> APIs and the work pursued in W3C, specifically for the Location API
> and preferences from Widgets 1.0. There should be a clear plan to
> unify those APIs.

It would be "interesting" for a newly chartered group to step into the
scopes of the existing work on widgets and geolocation; my advice
would be that BONDI participants interested in these points make their
input known to the working groups that are already operating in these
fields as quickly as at all possible.  As an aside, I understand that
there's some progress toward last call working drafts in both groups.

> Having API versioning model seems to be semantically equivalent to
> the updates of the Working Drafts in W3C, but in my personal
> opinion, API versioning model is more transparent to the actual API
> user and shall be discoverable by the web application code.

I don't quite understand what you mean here.  Are you suggesting
deployment of draft APIs as working drafts are issued?


________________________________________

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

www.access-company.com

CONFIDENTIALITY NOTICE
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 Wednesday, 29 April 2009 13:51:22 UTC