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

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.

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

Kind regards,

On Thu, Apr 30, 2009 at 6:24 PM, Marcin Hanclik
<> 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:
> -----Original Message-----
> From: Marcos Caceres []
> Sent: Thursday, April 30, 2009 5:57 PM
> To: Marcin Hanclik
> Cc: Robin Berjon; Thomas Roessler; Arthur Barstow; Nick Allott;
> 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
> 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

Received on Saturday, 2 May 2009 09:52:58 UTC