Re: Specs using Web IDL

Hi, Cam-

Cameron McCormack wrote (on 6/28/09 7:10 AM):
> Robin Berjon:
>>  I wonder what the value is of having it on Rec track in the first place?
>>  Could it simply be a Note?
>
> I’d be reluctant to make it a note, given the normative requirements it
> makes of implementations of a given IDL fragment.

Yes, it seems pretty clear to me that it should be normative.  The 
Process is flexible enough with regards to Rec-track deliverables that 
it allows us to decide what the best way for this spec to be 
demonstrably baked.


Cameron McCormack wrote (on 6/28/09 7:21 AM):
> Doug Schepers:
>>  As we talked about at the SVG F2F, we need to have a discussion about
>>  what the exit criteria for Web IDL will be, since the implementations
>>  are actually other specs, and there is concurrent development between
>>  those specs and Web IDL.  This seems to be a special case with regards
>>  to the Recommendation Track... should other specs be allowed go to
>>  CR/PR/Rec before Web IDL?  Should we park them in CR while features of
>>  Web IDL are solidified by other specs, like HTML5?
>
> Yeah I’m still not sure what the best approach for CR exit criteria is.

If we follow a more traditional approach, have multiple (two or more) 
interoperable implementations, as demonstrated by a test suite, is 
enough to justify moving it along to Rec.  Would it make sense to have a 
test suite for Web IDL (I suspect so), and if so, what are we counting 
as implementations?  I see a few options:

* other specifications that use Web IDL
* implementations of specifications that use Web IDL
* a combination of the other specs and their implementations
* Web IDL checkers
* parser libraries

Given that Web IDL is also meant to describe interfaces in Java in 
addition to JavaScript, would it be reasonable to require that there is 
at least one Java implementation for each of the interfaces, or would 
that be constraining ourselves too much?



>>  Will there be an updated revision or version 2 of Web IDL?
>
> My guess is that there will be if:
>
>    * we find mistakes or implementors aren’t happy with how some things
>      are specified,
>    * we want to add some extended attributes or definitions that would be
>      generally useful across multiple specs, or
>    * we want to update the ECMAScript language binding to ES5.
>
>>  Another possible implementation of Web IDL would be an IDL checker, like
>>  a validator.
>
> Yes, a validator or other kind of processing tool would demonstrate
> whether the conformance requirements on IDL fragments are internally
> consistent, at least.
>
> I think what we want to do is to make sure that each feature that is in
> the spec is useful for at least one other spec.  There are plenty of
> features that currently are depended on by other specs, but I don’t know
> if (m)any people have read through the detailed conformance requirements
> they entail.  It’s these details that I think are in most need of
> verification somehow.
>

-- 
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Sunday, 28 June 2009 19:37:18 UTC