Re: testing plans for Web IDL

Dominique Hazael-Massieux:
> I think I would go for:
> * by default, each feature of Web IDL needs to be present in at least 2
> specs
> * except for features of Web IDL that are explicitly marked as legacy
> artifacts in the spec, for which a single legacy reference would suffice
> 
> This also ensures the Web IDL spec would clearly mark which features are
> to be avoided :)

That sounds OK.

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

> > I wonder if the existing specifications that use Web IDL aren’t enough
> > for us to use.
> 
> If they cover enough of the required features, yes, I think that's
> probably enough; we'll probably also want to have specs that are stable
> enough (although of course we don't want to be trapped in an egg and
> chicken problem where specs can't get stable because Web IDL isn't
> finished, and Web IDL can't be finished because it needs stable specs.)

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?

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

> Summarizing a possible action plan based on the discussion in this
> thread:
> * we need to identify all the features of Web IDL; I guess a good
> starting point is the various syntactic keywords that it defines
> * among them, we need to mark legacy ones
> * we should start looking for specs that use the various identified
> features of Web IDL, with a preference for the most mature/deployed
> * we should write test cases that allows to verify the proper ECMAScript
> binding of these features in the said specs

Sounds good!

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Tuesday, 31 May 2011 23:17:16 UTC