- From: Marcos Caceres <w3c@marcosc.com>
- Date: Sat, 24 Mar 2012 12:43:54 +0000
- To: Cameron McCormack <cam@mcc.id.au>
- Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On Saturday, 24 March 2012 at 00:45, Cameron McCormack wrote: > Marcos Caceres: > > I don't know how the following relates to, or has any bearing on, the > > exit criteria, but I feel I need to at least mention it (I've been > > thinking about this for a few days now, and something about the above > > is not sitting right with me). > > > > There are at least five types of products I have seen in the wild > > that make use of WebIDL directly. > > > > 1. Specifications (human written): a number of specifications across > > a number of working groups define interfaces in terms of WebIDL. > > E.g., DOM4, HTML5, etc. > > > > 2. Specifications (semi-generated): WebIDL is taken as input, and > > out comes HTML and content. Examples include Respec.js and widlproc. > > Respec.js is used by specifications in the DAP WG, as well as > > IndexDB, as well as others. Widlproc has been used by groups outside > > the W3C (namely Webinos and WAC). > > > > 3. Test generators: WebIDL is taken as input, out comes lots of > > tests. Example include the generator used to create this test suite: > > http://dev.w3.org/2006/waf/widgets-api/test-suite/ > > > > 4. Code generators: WebIDL is taken as input, a code template comes > > out as output. Example includes: > > http://www.chromium.org/nativeclient/sdk/sdk-experimental/c_salt-design/web-idl-and-c-salt > > > > (I know of one other similar system used on a commercial product, > > but I don't have a link to share) > > > > 5. Browsers: browsers base (or will base) their behavior on it. > > > > Of course, 5 is obviously the most important - and the one you are > > basing the exit criteria on…. 1-4 may or many not be significant > > enough to warrant the attention of the WG when considering > > conformance requirements and exit criteria (depending on what members > > feel is the priority). However, I have a feeling that WebIDL will > > play a pretty important role in QA departments of browser makers. I > > know it's played a very significant role in QA work I've been > > involved in over the last few years. > > > > I think the exit criteria implicitly #1 as well, since we > need to base our #5 tests on specs that correctly use Web IDL. > > I am not sure we could do anything useful for #2 - #4 in terms of exit > criteria. Probably not (or not right now, anyway). I guess if there the spec goes through a revision on the future, and there is enough interest from people making interesting stuff, that parsing rules with error handling could be added; all the right bits appear to be in place. You can build so much cool stuff on-top of this spec that I'm pretty certain at some point we will need to define such things in the future. -- Marcos Caceres http://datadriven.com.au
Received on Saturday, 24 March 2012 12:44:29 UTC