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

Hi Marcos,

Thanks for your comments!
As stated in the email to Robin, I hope to avoid misunderstanding.

>>Exactly. Vendors SHOULD NOT provide legacy support for unfinished spec
>>implementations. Developers beware! and shame on vendors that do this
>>for they are the cause of fragmentation that standardization is trying
>>to overcome.
I basically agree as long as the standardization process does not take too long. Again, versions may be helpful here.
>From the tone of your email I have an impression that I have touched upon some probably lengthy discussion that I may be not aware of. If you could point me to some mail or IRC archive, I could maybe read about more arguments.

Again I take Widgets 1.0 as background. It is just an example and has nothing to do with the actual standard.
Let's imagine the following scenarios...

SCENARIO A
It is 10. November 2006, one day after the first working draft of Widgets 1.0 has been published. It is then available under http://www.w3.org/TR/widgets/ (as the latest version at that time).
We are in the Arctic (chosen because of the distance without flying to the moon). Person A, a web developer, reads the spec and thinks it is a cool one, W3C is a well-known organization doing good standards. He/she talks to person B, who is a software developer, who can develop a Widgets 1.0 engine on some open platform (mobile or not).
They are not standardization experts, they do not have to be.
They work a few weeks and create a very cool service that gets popular in the neighborhood. So they live further with the service, maybe getting some revenue out of it.
Similarly..
It is 23. December 2008, one day after the fourth working draft of Widgets 1.0 has been published. It is then also available under http://www.w3.org/TR/widgets/ (as the latest version at that time).
We are in Greenland (again chosen because of the distance without flying to the moon). Person C, a web developer, reads the spec and thinks it is a cool one. He/she talks to person D, who is a software developer, who can develop a Widgets 1.0 engine on some open platform (mobile or not, e.g. other than for person B).
The persons do not care about the previous working drafts, they take the latest, marked all the time as version 1.0.
They are not standardization experts, they do not have to be.
They work a few weeks and create a very cool service that gets popular in the neighborhood. So they live further with the service, maybe getting some revenue out of it.

Then we have some other day, e.g. today, 01.05.2009 (depending on the time zone).
The people A,B,C,D travel and meet together e.g. somewhere in Europe. They talk and suddenly realize that they could exchange their experiences with the implementation of Widgets 1.0 at http://www.w3.org/TR/widgets/. They try contents and... it most probably does not work. Their contents and implementations are not interoperable.
They start raising questions and are probably unhappy, their expectations happened to be naïve.
And it could have been better if the first would know that they implemented Widgets 0.1 and the others Widgets 0.4. They would probably realize earlier about the issues.

SCENARIO B ad your comment:
>>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

I hope you watched Minority Report (http://www.imdb.com/title/tt0181689/).
Similarly to the above SCENARIO A imagine:
It is 10. November 2006, one day after the first working draft of Widgets 1.0 has been published. Person A is reading Widgets 1.0. The first sparking idea of implementing that spec appears in the mind of person A.
And then someone from W3C / the editor [W3C's elite law enforcing squad :) ] comes to person A saying: "You cannot implement our standard. It is still in WD status"....
Then probably people A,B,C,D would never care about W3C standards. They would create their own, probably by copying parts of Widgets 1.0. This would be really painful for the industry and would create even more fragmentation, I think.
Now implementations of Widgets 1.0 WDs probably differ, but have also a lot in common.

So, let's come to the ground.
Proper versioning may help here.
E.g. versions prior to LC 1.0 are like non-existing, not well-endorsed by W3C and deprecated etc., but it could be clearer from the standard's text.
I understand that it may be difficult to version specifications that are about static content like markup.
But in this mail thread we are talking specifically about APIs, i.e. dynamic stuff. There is a model that could help with versioning based on DOM's hasFeature().
If the content developer knows that the current spec is in version e.g. 0.3, then he writes his content with hasFeature("...","0.3").
Such content may e.g. quit if the version simply does not match, without thinking about backward/forward compatibility.

Versioning may be a good tool for management of expectations.
The versions of the standards are not necessarily growing monotonically.
Sometimes some features are dropped or modified. So if it takes long to implement some WD and features are dropped, the old implementation usually creates a de-facto standard. Not in the spec, few people want it and it is still there.

Apart from that versioning is a good tool for organization of the work. Each version may incrementally address some issues. And if you create a big standard at once, you probably follow a waterfall pattern that is usually deprecated in the industry.

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: Marcos Caceres [mailto:marcosc@opera.com]
Sent: Thursday, April 30, 2009 1:49 PM
To: Robin Berjon
Cc: Marcin Hanclik; 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 4/30/09 12:29 PM, Robin Berjon wrote:
> Hi Marcin,
>
> On Apr 30, 2009, at 11:55 , Marcin Hanclik wrote:
>> 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.
>
> Yes, you can, it's called an alpha version. This is very clearly the
> case of an API that may change and for which the authors do not
> guarantee that they won't break compatibility. WGs don't generally
> object to having people implement drafts early, so long as said people
> make it clear to their customers that they're not selling a stable long
> term solution, and so long as they don't claim conformance to anything.
>

Exactly. Vendors SHOULD NOT provide legacy support for unfinished spec
implementations. Developers beware! and shame on vendors that do this
for they are the cause of fragmentation that standardization is trying
to overcome.

Besides, this also means a test suite would need to be built for every
working draft published for vendors to claim conformance to a working
drat. Another tasks that is totally unfeasible.

>> But now WD=CR=PR=Rec. People simple do not know what they buy.
>
> If anyone is getting the impression that WD=CR=PR=Rec the vendors are to
> blame I'm afraid.
>

Agreed.

________________________________________

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 16:00:54 UTC