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
