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
