Re: testing plans for Web IDL

Le mercredi 01 juin 2011 à 11:16 +1200, Cameron McCormack a écrit :
> > > Whether these other specifications write correct IDL fragments is
> > > another thing to look at, and something we can (and you do) test for.
> > 
> > Yes, I think that as part of finding specs that use the various Web IDL
> > features, we should also ensure that they use them properly — and by
> > that I mean also beyond the syntax, ensuring that the semantics of the
> > fragments match the prose / perceived intent of the author.
> That sounds subjective.  Would we have someone analyse the other
> specifications to see if they have used Web IDL features with the right
> intent?  It might be hard to phrase the CR exit criteria for this.

It is indeed somewhat subjective, but it wouldn't be a first for a CR
exit criteria; for instance, the Mobile Web Application Best Practices
        Sufficient reports of implementation experience have been
        gathered to demonstrate that the Mobile Web Application Best
        Practices are implementable and are interpreted in a consistent
        manner. To test this, the Working Group expects to evaluate Web
        content (Web sites, pages) that has been created using the
        Mobile Web Application Best Practices

The Working Group had to actually judge whether the sites / apps that
were submitted as illustration of the best practices did indeed follow
these best practices.

I think it would be a useful exercise for the CR of Web IDL as well.

> Yes, I worry about the chicken–egg problem here.  Selectors API is
> probably the furtherst advanced spec that depends on Web IDL: for it to
> progress to REC, is having Web IDL in CR sufficient?

By default, all normative dependencies have to be Rec for a spec to
progress to Rec, although there can be exceptions granted by the

> > I guess I wouldn't mind keeping the Java binding on the Rec track for
> > the time being, and moving it to Rec or to Note depending on the
> > interest in the document. Should the split happen before Last Call,
> > though?
> Let’s do it after Last Call, and identify the Java binding as one of the
> features “at risk”.

Makes sense, indeed.


Received on Wednesday, 1 June 2011 08:00:55 UTC