W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: An import statement for Web IDL

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 29 Jun 2009 21:40:24 -0700
Cc: public-webapps@w3.org
Message-id: <8220A24C-F40A-46D1-98A1-7319C558A2E5@apple.com>
To: Cameron McCormack <cam@mcc.id.au>

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

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.

Received on Tuesday, 30 June 2009 04:41:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC