- 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