- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 29 Jun 2009 21:40:24 -0700
- To: Cameron McCormack <cam@mcc.id.au>
- Cc: public-webapps@w3.org
On Jun 28, 2009, at 10:54 PM, Cameron McCormack wrote: > The OMG-ish IDL fragments published for W3C specs use C preprocessor- > like directives to include other IDL fragments, so that names resolve > correctly. For example, > http://www.w3.org/TR/DOM-Level-2-Events/idl/events.idl has: > [...] > That way the IDL processor knows exactly what dependent IDL files it > needs to process, and there’s no need to assume that the user of the > IDL > files has to place the DOM Core and Views IDL files with specific > names > in the same directory as the events.idl file. > > Thoughts? Specs having to provide actual IDL files and name them seems like a burden for spec authors, and not helpful to the spec. It's also not helpful for implementations, which do not generally want to have IDL files at whole-spec granularity, but rather per-interface. It would be nice if we could find a way to make things more rigorous with a mechanism that's convenient to both spec writers and browser developers. On possibility: we could consistently use modules and have a way to import by module name, a la Java. Specs could import other modules wholesale with prose or an IDL fragment at the top of the document. We could recommend that non-W3C spec specs should use "reverse DNS" style module prefixes to avoid the possibility of collision. This makes the name binding more rigorous than filename-based includes and should not overly get in the way of implementations or specs. Regards, Maciej
Received on Tuesday, 30 June 2009 04:41:05 UTC