W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2002

Comments on DOM XPath Interface

From: Michael Kay <michael.h.kay@ntlworld.com>
Date: Thu, 28 Mar 2002 16:37:56 -0000
To: <www-dom@w3.org>
Message-ID: <000501c1d676$eaafcf80$6501a8c0@pcukmka>
1. It is likely that XPath 2.0 will relax some of the rules concerning
namespace nodes. In particular, rules concerning their identity, parentage,
and position in document order. These relaxations are designed to make
namespace nodes easier to implement without removing any useful
functionality. The DOM might consider anticipating these changes, at the
very least by a note advising users not to rely on these properties.

2. The specification does not say what methods such as getNodeName() and
getNodeValue() will return, when applied to a namespace node. I would expect
them to return the name and string-value of the node as defined in XPath,
but since that is not true of other node types, I might be wrong.

3. It might help if the specification spelled out exactly how the set of
namespace nodes for an element are derived from information accessible
through other DOM interfaces. The different ways namespace information can
be represented in DOM (through attributes representing namespace
declarations, through namespace URIs on the element and attribute nodes,
etc) is a constant source of difficulty. It should also be made explicit
that xmlns: attributes will *not* be exposed as attribute nodes through the
XPath interface.

4. The interface provides only limited ability to set the XPath static and
dynamic context. It provides no capabilities to create variables or
extension functions, and no way of setting the context position or size. For
the typical end-user of the interface, this is not a problem. However, it
means that an implementor wishing to provide an XPath engine that is
suitable for use, for example, by an XSLT processor, will need to provide
additional interfaces, and these will vary from one implementation to
another, which will make it more difficult to write an XSLT engine that can
work with any DOM implementation.

5. In designing the XPathResult interface, it would be a good idea to
anticipate the XPath 2.0 data model. In XPath 2.0, everything is a sequence;
it is possible to return a single node, or a sequence of strings. This might
suggest separating the notion of result type into two parts (a) is it a
singleton or a sequence, (b) what type are the items?

6. Only two codes are defined for XPathException: invalid expression error,
and type error. I couldn't find any definition of these codes. For example,
which one should the (incorrect) expression "count(3)" return?

7. The specification says nothing about the use of the XPath id() function.
Does this mean it is always guaranteed to work?

8. XPath says that it is the job of the host specification to define
conformance rules. Where are the conformance rules? For example, is an
implementation conformant if it extends the vocabulary of functions that can
be called within an XPath expression?

Michael Kay
Software AG
home: Michael.H.Kay@ntlworld.com
work: Michael.Kay@softwareag.com
Received on Thursday, 28 March 2002 11:37:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:55 GMT