W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2002

RE: XPath DOM and XPath 2.0

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>
Message-ID: <000201c1da98$102f8b40$6501a8c0@pcukmka>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:10 UTC