Re: Specs using Web IDL

Hi, again-

Oops, email sent too soon... I need to disable the keyboard shortcut for 
"Send" on Thunderbird, it's very annoying.

Email finished inline....

Doug Schepers wrote (on 6/28/09 3:37 PM):
> 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?

It comes down to what we think is the most useful indicator of success 
for Web IDL.


>>> 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.

I guess the first point would call for a revision, while the others 
indicate a need for a new version.  No need to dwell on it, but setting 
expectations about the future of the spec is useful.


>>> 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.

Maybe we should have a LC to draw out these comments... if not now, what 
timeframe are you thinking?  What else needs to be done to the spec?


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

Received on Sunday, 28 June 2009 20:17:17 UTC