DOM3 XPath comments

Hi,

Three comments on the DOM3 XPath WD:

In the createExpression() and evaluate() methods of the XPathEvaluator
interface, the resolver argument is defined as follows:

  resolver of type XPathNSResolver
    The resolver permits translation of prefixes within the XPath
    expression into appropriate namespace URIs. If this is specified
    as null, any namespace prefix within the expression will result in
    DOMException being thrown with the code NAMESPACE_ERR.

Does this include the XML namespace? In other words, will:

  evaluator.createExpression('@xml:space', null)

raise a NAMESPACE_ERR? In other specs, the XML namespace has a special
status -- it doesn't have to be declared explicitly within documents
for example -- perhaps the same special status should extend to here.

---

In the description of the constant ANY_UNORDERED_NODE_TYPE, it says:

  If there are more than one node in the actual result, the single
  node returned may not be the first in document order.

This is ambiguous - you might be saying that an implementation
shouldn't return the first node in document order, but I don't think
that's what you intend. It would be clearer if you used "might"
instead of "may": "the single node returned might not be the first in
document order". There's similar use of "may" when you mean "might"
throughout, but this one is particularly ambiguous.

---

In the definition of the XPathNamespace interface, there are a few
things that are strange for people used to dealing with XPath
namespace nodes. The description of XPath namespace nodes is at
http://www.w3.org/TR/xpath#namespace-nodes, and says:

  The element is the parent of each of these namespace nodes...

which implies that the parentNode attribute of XPathNamespace should
return the ownerElement (although it would be consistent with the Attr
interface, and the Infoset, not to do this).

Regarding the name:

  A namespace node has an expanded-name: the local part is the
  namespace prefix (this is empty if the namespace node is for the
  default namespace); the namespace URI is always null.

This implies that the prefix attribute should be null (since the
namespace node is not associated with a namespace through a prefix),
that the nodeName should be the prefix of the namespace, and that the
namespaceURI should be null.

The XPath definition goes on to say:
  
  The string-value of a namespace node is the namespace URI that is
  being bound to the namespace prefix; if it is relative, it must be
  resolved just like a namespace URI in an expanded-name.

This implies that the nodeValue attribute should be the namespace URI
being bound to the namespace prefix rather than null (ref Issue
XPath-11).

In particular, I think it's dangerous to give the prefix and
namespaceURI attributes different semantics for XPathNamespace nodes
to those they have for Element and Attr nodes -- a XPathNamespace
node is not *in* a namespace, it *represents* a namespace. If you want
to follow the Infoset, then you should define new attributes:

  - namespaceNodePrefix
  - namespaceNodeNamespaceURI

rather than reusing 'prefix' and 'namespaceURI' attributes, which do
not give access to Infoset properties, but rather are convenience
methods for accessing information about the [name] property in the
Infoset.

Cheers,

Jeni
---
Jeni Tennison
http://www.jenitennison.com/

Received on Friday, 29 March 2002 05:21:59 UTC