- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 27 Jan 2009 22:34:56 +1100
- To: public-webapps@w3.org
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 UTC