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

Hi Marcos,

Thanks for your comments!

These are mine.

>>People SHOULD NOT be implementing WD!
>>Implementers implement at their own risk.
I would rephrase it: customers should not buy implementations based on WD.
But this cannot be stopped, I think.
E.g. ones Calendar API 1.0 FPWD (if not earlier) would be published, I assume customers would like to buy the implementations from that date.

>>It's not that the W3C is slow
I do not claim that W3C is slow (quality and process matters for me as well) and agree with your comments on this.
My issue is that on the implementation level you cannot distinguish WD from CR/PR/Rec.
If it would be possible to mark an implementation as WD, then there should be no problem. Then the customers would think twice and maybe would get engaged. But now WD=CR=PR=Rec. People simple do not know what they buy.

>>I'm sorry, this is a terrible idea. This would mean that the
>>implementation would need to support potentially x number of
>>incompatible versions of an API! This would bloat software and be a
>>management nightmare for implementers.
Yes. But the current process results in exactly the same and supports de-facto standards. What's more, it is implicit, whereas I try to suggest to make this fact explicit. That is the only difference to me.

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: marcosscaceres@gmail.com [mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres
Sent: Thursday, April 30, 2009 11:38 AM
To: Marcin Hanclik
Cc: Thomas Roessler; Arthur Barstow; Nick Allott; public-device-apis@w3.org
Subject: Re: ACCESS' input, was: RE: Proposal for new WG to specify "Concrete APIs"

On Wed, Apr 29, 2009 at 3:46 PM, Marcin Hanclik
<Marcin.Hanclik@access-company.com> wrote:
> 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.
>

Whoa! hold up there Marcin. This has been a massive disaster and is
causing an interop nightmare ATM. People SHOULD NOT be implementing
WD! Especially not in production code. I'm started adding "THIS SHOULD
NOT BE IMPLEMENTED" to the top of specs (e.g., A&E in an attempt to
stop people from implementing). The way to make things go faster is
for companies to actively participate in the process. It's not that
the W3C is slow (in fact, apart from Thomas and a few others, there is
very little direct input from the W3C into the standardization process
so it is wrong to suggest the W3C is slow; the member companies are
slow at sending feedback, editing, and reviewing specs).

> So what I would like to suggest for the API specifications - released as a Working Draft, prior to LC / Recommendation - to be appropriately versioned.
>

My personal opinion is, "no no no!".

> 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.
>

That's all well and good for BONDI, but I think it's the wrong
approach for the W3C.

> 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.
>

Implementers implement at their own risk. This should be discouraged
till the spec is in CR!

> 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'm sorry, this is a terrible idea. This would mean that the
implementation would need to support potentially x number of
incompatible versions of an API! This would bloat software and be a
management nightmare for implementers.

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

Um, Opera would formally object to this.

--
Marcos Caceres
http://datadriven.com.au

________________________________________

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 Thursday, 30 April 2009 09:57:08 UTC