- From: Michael Kay <michael.h.kay@ntlworld.com>
- Date: Tue, 2 Apr 2002 23:45:17 +0100
- To: "'Philippe Le Hegaret'" <plh@w3.org>, "'Joe Kesselman'" <keshlam@us.ibm.com>
- Cc: "'Ray Whitmer'" <rayw@netscape.com>, "'WWW DOM'" <www-dom@w3.org>
Yes, this was the sort of thing I had in mind. You might also decide to anticipate some of the XPath 2.0 terminology (which has actually stabilised since the last published drafts): * "number" becomes "double" (as per XML Schema) * A sequence is a collection of items; each item is either a node or an atomic-value. Booleans, doubles, and strings are atomic-values. Michael Kay Software AG home: Michael.H.Kay@ntlworld.com work: Michael.Kay@softwareag.com ... > > The XPathSingletonResult interface forces the implementation to > encapsulate the Node into an object ... unless the Node implementation > supports the XPathSingletonResult interface (and I'm not sure > we want to > implement the DOM that way :). So I certainly see this > encapsulation as > a drawback for XPath 1.0 implementers and the > XPathSingletonResult will > not be enough for XPath 2.0 anyway and will need to be revised. Yes. I think it probably makes sense for the "XPathItem" interface to be offered by an object that wraps the Node, rather than being offered by the Node itself. This might also provide a good way of delivering direct access to things defined in the XPath data model, such as the name and string-value of a node, which don't correspond directly to properties of the node as defined in DOM. (I think it would be a shame if users have to construct XPath expressions to get hold of these node properties). Michael Kay Software AG
Received on Tuesday, 2 April 2002 17:44:50 UTC