- From: Mike Mansell <MMansell@PureEdge.com>
- Date: Mon, 25 Nov 2002 15:23:38 -0800
- To: <www-dom@w3.org>
Two issues: 1) In quite a few of the specifications, there is talk about using the getInterface of either DOMImplementation or Node as a mechanism to get access to the specialized API's. I think this is a great solution over the previous 'binding-specific casting method', that was completely different for every implementation. However, the problem I see is that the current specifications specialized API's do NOT inherit from DOMImplementation or Node. This puts us exactly back into the 'binding-specific casting method' world. In which case, there's no point in having the getInterface method. For example, in the Load & Save spec (http://www.w3.org/TR/2002/WD-DOM-Level-3-LS-20020725/load-save.html), the inteface DocumentLS is defined as: interface DocumentLS { ... }; and the statement is made: --- The expectation is that an instance of the DocumentLS interface can be obtained by using binding-specific casting methods on an instance of the Document interface or, if the Document supports the feature "Core" version "3.0" defined in [DOM Level 3 Core], by using the method Node.getInterface with parameter values "LS-Load" and "3.0" (respectively). --- Therefore, if I want to use the Node.getInterface("LS-Load", "3.0") to get a DocumentLS, the object I get back must implement Node as well as DocumentLS. Otherwise, I need a 'binding-specific casting method' for this to work. I believe that the expected code would look like: { Document myDocument; DocumentLS myDocumentLS; // myDocument filled out via normal DOM calls myDocumentLS = (DocumentLS)myDocument.getInterface("LS-Load", "3.0"); myDocumentLS.abort(); } However, if 'DocumentLS' does NOT inherit from Node, this is going to throw an exception in Java and crash in VB and C++. This problem occurs in many places, but a few places that I've noticed are: Load & Save: DOMImplementionLS and DocumentLS Events: EventTarget XPath: XPathEvaluator 2) The getInterface method is defined as only taking a feature parameter. However, most of the other specifications refer to the getInterface method as if it takes both a feature and a version parameter. I would prefer that the getInterface be updated to take both a feature and a version so that it is similar to isSupported. Michael Mansell, Senior Product Architect PureEdge Solutions Trusted Digital Relationships v: 250-708-8046 f: 250-708-8010 1-888-517-2675 http://www.PureEdge.com
Received on Monday, 25 November 2002 18:24:19 UTC