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

Hi Marcos,

Thanks for your comments and questions!

>>putting "1.0" versioning on our spec was a huge [marketing] mistake
I agree. Our discussion seems to be mainly around that.

>>1. How can you test for conformance to a spec that is not done and for
>>which no test suite will be published?
I believe this is the part of a bigger issue, not only for Widgets. There seems to be no solution for WD.
Usually vendors and their customers perform their own testing. Of course it would be perfect if the public test cases were prepared in parallel with the spec development.

>>2. How can two or more interoperable implementations be created when
>>working drafts contain unfinished sections in which case implementers
>>need to fill in the gaps by inventing their own solutions (which
>>become "bugs")?
I agree, those implementations would be interoperable by accident. Versioning of the spec, implementation and content may only make it clearer and more visible without hoping that it would work.

>>3. What happens if an unfinished WD version gets developer traction
>>and millions of widgets are built for it? How do you then achieve
>>interoperability when developers are not coding to standard but to
>>implementation?
This is another big issue and seems to be a discussion about principles: do standards get developed without implementation? Rarely. Implementations are needed also in W3C process. The question is: what happens if the available implementation(s) is/are different from the standard? Is standard to be updated or the implementation(s)? Are test cases good enough? What about errata?
I share your concerns about buggy implementations that get developer traction. (As for me it is good to put into the standard a few statements about what it is NOT about. Then the potential implementers could know what is left at their discretion).
Probably there may be voices that standards should only reflect the business needs and thus the standard may have to be redefined. But it may also be stated that probably the implementers were not capable of / interested in the implementation of the full standard.
There are also cases where the existing implementations (that may also be already on the market) are brought for standardization (seeing the initial contribution from Nokia and the BONDI activity, this seems to be our case). So I assume the actual technology is not that much in focus as reaching consensus.

To sum up:
I would like to suggest that the charter and participants of the new WG should assume that:
1. Parties contributing to this new WG may have existing implementations (probably deployed on the market) of the subject of the new standard.
2. Versioning is important and the version of the content as well as the version of the implementation should be discoverable to each other.

It is simply hard to imagine for me that e.g. the standard Calendar API will be usable on the Web not earlier than 2011. But I can imagine and accept that Calendar API 1.0 will be there agreed by the industry players in 2011, whereas e.g. Calendar API 0.1 (probably 90% of the functionality to be available in 2011) will be available in 2010Q1 if not earlier.
And even if Calendar API 0.1 will be completely redesigned through version 1.0, it will be discoverable as summarized above.

BONDI activity makes me think that there is enough industry support to define the specs within the new charter (if not more, aka fast re-chartering) quite promptly.

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: Saturday, May 02, 2009 11:52 AM
To: Marcin Hanclik
Cc: Robin Berjon; 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"

All,
If there is anything to take away from this discussion is that putting
"1.0" versioning on our spec was a huge [marketing] mistake. It should
just have been called "Widgets: [insert spec name here]" and should
have been developed with "levels". Too bad it's too late to change the
name now.

Marcin,
In your scenarios, you did not address my conformance testing question
and interoperability questions.

1. How can you test for conformance to a spec that is not done and for
which no test suite will be published?

2. How can two or more interoperable implementations be created when
working drafts contain unfinished sections in which case implementers
need to fill in the gaps by inventing their own solutions (which
become "bugs")?

3. What happens if an unfinished WD version gets developer traction
and millions of widgets are built for it? How do you then achieve
interoperability when developers are not coding to standard but to
implementation?

Kind regards,
Marcos

On Thu, Apr 30, 2009 at 6:24 PM, Marcin Hanclik
<Marcin.Hanclik@access-company.com> wrote:
> Hi Marcos,
>
> It seems our mails crossed... :)
>
>>>Marcin, this is by design and totally on purpose. We don't want this to
>>>ever happen. This would be really really REALLY bad. Working Drafts are
>>>NOT TO BE IMPLEMENTED for shipping! Only implement them to fix a spec,
>>>not to ship to market.
> I still basically agree. But I cannot stop my customers from wanting some WD implemented. If someone comes and wants to buy WD implementation, I would be **** not doing that.
> I just want to mark such an implementation as not implementing the final standard in some "standard", agreed and discoverable (for all: customer, content developer etc.) way. I think any method would be ok and stopping discussions on this sensitive topic is not the way to move the problem forward. I do not want to endorse bad implementations.
>
> What you mention in your email below are bugs related to the implementation of the specifications. Probably less people would object if the IE would have well-documented features / modifications of the standards instead of saying that it implemented web standards without in fact doing it correctly.
>
> I try to find a solution for an intentional and foreseenable process of the specifications changing in time.
>
> Many industry members have agreed in BONDI (I hope no-one from the readers objects to this statement) that there may be and will be new versions of that standard. Nobody is perfect. The next releases may add, remove or modify parts of the previous version. This is life, technologies come, improve and go.
>
> So why not to have a solution for that?
> Still I mean dynamic APIs specifically.
>
> 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 5:57 PM
> To: Marcin Hanclik
> Cc: Robin Berjon; 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 5:08 PM, Marcin Hanclik wrote:
>> Hi Robin,
>>
>> I suppose my point was misunderstood or I expressed myself not clearly enough.
>> By "on the implementation" level I mean how the content (being usually intelligent, e.g. by checking some UA parameters, e.g. by hasFeature()) can discover the capabilities of the UA.
>> I did not mean that the UA implementation is intentionally marked incorrectly.
>>
>>>> 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.
>>>> If anyone is getting the impression that WD=CR=PR=Rec the vendors are
>>>> to blame I'm afraid.
>> As stated above this is not the intended subject of my email.
>>
>> Still, for the content implemented based on WD or CR or PR or Rec, there is currently no way in Widgets 1.0 specs to discover which particular version of the WD was taken as basis for the potential WUA implementation.
>
> Marcin, this is by design and totally on purpose. We don't want this to
> ever happen. This would be really really REALLY bad. Working Drafts are
> NOT TO BE IMPLEMENTED for shipping! Only implement them to fix a spec,
> not to ship to market. We clearly say "Implementers who are not taking
> part in the discussions are likely to find the specification changing
> out from under them in incompatible ways."
>
> If someone actually wants to do what you are suggesting, they should do
> that as a proprietary widget format and say absolutely nothing about W3C
> widgets.
>
>> And versioning model for both content and WUA could help here, I think.
>
> No. People should code to spec, not to implementation (and yes, this is
> to implementation because WD have holes that are being filled in
> proprietary/arbitrary ways: e.g., what URI scheme is BONDI's RI using?
> Why is it using that one when W3C has not even specified one?
> conformance FAIL). The Web is soooo broken today because vendors did
> what you are suggesting and now we have a 500 page HTML5 spec that tries
> to fix all the mistakes browsers vendors have ever made. Look at all the
> pain IE6 caused developers for not implementing to spec (this might not
> be MS fault because the specs were ambiguous)! all the work around and
> hacks, that's all bad! All the browser version checking code, etc. It's
> a freeken nightmare + all the reverse engineering everyone has had to do
> to render pages like IE does.
>
> Don't repeat this for widgets!
>
>> If my intentions are now clearer, I would be happy to hear your comments on them.
>
> I hope I'm the one misunderstanding you and you are not seriously
> suggesting what I think you are suggesting.
>
> Marcos
>
> ________________________________________
>
> 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.
>
>



--
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 Sunday, 3 May 2009 21:59:48 UTC