Re: DOM3 XPath comments

Jeni Tennison wrote:

>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.
>
I agree that this should be clarified, and I believe I agree that it 
should be built-in rather than requiring the resolver to do it.

>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.
>
Might sounds better, I agree, and we can check for others realizing the 
ambiguous interpretation.

>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).
>
As in other places in DOM API descriptions, the attributes are not 
repeated that are already described elsewhere.

The description of parentNode in core refers explicitly to the infoset, 
and not to XPath.

The description of the namespace node states that all attributes not 
explicitly mentioned in the description are null or false, which applies 
to this as well.  DOM XPath users will be familiar with the fact that 
they need to go to the ownerElement.  

If there is more clarification required, it might be true of other 
attributes as well, but we thought it was covered right in the 
description of the node.  What, specifically would you suggest?

>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.
>
I think I originally used the XPath spec for guidance on this.  But then 
others believed that having a prefix that was not the prefix and a 
namespaceURI that was not the namespaceURI was wrong, especially since 
the infoset uses these same attribute names that were used in the 
element.  DOM tends to be more-closely-bound to infoset than XPath.  I 
think the current definition has a perfect correspondance with respect 
to the infoset, because if you compare element and namespace, the same 
items have the same corresponding names -- [prefix] and [namesapce name].

>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).
>
Again, this is XPath, not infoset.

>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.
>
prefix and namespaceURI very clearly DO give access to the infoset 
properties. [namespace name] is equivalent to namespaceURI, just as it 
is in other places, and [prefix] is equivalent to prefix, just as it is 
in other places.  An application may wait until serialization or 
normalization to fix-up the prefix, but that changes nothing -- it is 
just one of several ways the DOM may get into an imperfect state between 
parsing, which correctly sets it, and normalization or serialization, 
which also makes sure it is correct.

As I interpret infoset, the specification is exactly correct -- which 
does not match XPath, but the definitions of these attributes in the 
Node interface is not based upon XPath but upon infoset.

Ray Whitmer
rayw@netscape.com

Received on Monday, 1 April 2002 15:52:56 UTC