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

Received on Thursday, 30 April 2009 09:38:38 UTC