W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

[WebIDL] Including other IDL fragments

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 27 Jan 2009 22:34:56 +1100
To: public-webapps@w3.org
Message-ID: <20090127113456.GB4152@arc.mcc.id.au>

Hi.

In already-published DOM specs, the OMG IDL fragments use C-style
preprocessor instructions to explicitly include any dependent IDL.  For
example, the DOM 3 Core IDL looks like this:

  #ifndef _DOM_IDL_
  #define _DOM_IDL_

  …
  module dom
  {
    …
    interface Node {
      …
    };
    …
  };

  #endif

and the DOM Level 3 XPath IDL looks like this:

  #ifndef _XPATH_IDL_
  #define _XPATH_IDL_

  #include "dom.idl"

  …
  module xpath
  {
    typedef dom::Node Node;
    …
    interface XPathExpression {
      DOMObject evaluate(in Node contextNode, …) …;
    };
    …
  };

  #endif

The #include is being used to ensure that ::dom::Node has been declared
before its use in ::dom::xpath::XPathExpression::evaluate(), though it
seems a bit dodgy to include a file with a particular name.

Does Web IDL need such a mechanism?  Should it be up to the user of the
IDL fragments to have all the relevant ones passed to the IDL processor
in the right order?

At the moment, for example, selectors-api references some DOM Core
interfaces in its IDL without them having been declared earlier:

  http://dev.w3.org/2006/webapi/selectors-api/#nodeselector

XMLHttpRequest similarly doesn’t declare the Document type that it uses:

  http://dev.w3.org/2006/webapi/XMLHttpRequest/#xmlhttprequest

(Plus the interface is not explicitly in the dom module.)

Any thoughts about how to deal with this?

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 27 January 2009 11:35:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:29 GMT