Re: DOM 3 XPath: default namespace nodes?

Ray Whitmer wrote:
> >Result[1] = XPathNamespace { // Note: omitted attributes are null or false
> >	nodeName:	"xmlns"
> >	nodeType:	13
> >	ownerDocument:	(Document node)
> >	namespaceURI:	"http://www.w3.org/2000/xmlns/"
> >	prefix:		"xmlns"
> >}
> >  
> >
> No.  This does not appear in the XPath or DOM model or in the infoset.

Indeed, now that you point it out, the Infoset is quite specific about both
cases.  From section 2.2:

    [in-scope namespaces] An unordered set of namespace information
    items, one for each of the namespaces in effect for this element.
    This set always contains an item with the prefix xml which is
    implicitly bound to the namespace name
    http://www.w3.org/XML/1998/namespace. It does not contain an item
    with the prefix xmlns (used for declaring namespaces), since an
    application can never encounter an element or attribute with that
    prefix.

> >Result[2] = XPathNamespace { // Note: omitted attributes are null or false
> >	nodeName:	"" // i.e., empty string, NOT null
> >	nodeType:	13
> >	ownerDocument:	(Document node)
> >	namespaceURI:	"default/"
> >	prefix:		"" // i.e., empty string, NOT null
> >}
> >  
> >
> I believe nodeName should be null in this case.  The namespaceURI is a 
> deprecated relative URI, so the value of namespaceURI is unpredictable, 
> at best.  but they may be treated literally as you have shown here.

Sorry about the relative URI.  Substitute the following example XML:

   <doc xmlns="http://ns.adobe.com/default/" />

> >* For xmlns="default/", should the nodeName and prefix be empty string, or
> >null?  I'm assuming empty, because I can find no reference in any DOM Core
> >spec that permits nodeName to be null, and I'm told that anything not
> >expressly permitted in the spec is forbidden.
> >
> This is a case that we did not specifically consider when creating the API.
> 
> It is obvious to me that prefix should be null in this case, as it is in 
> other similar cases in the specification.  This should be made clear in 
> the specification.  We did not think of the default namespace when 
> creating that part of the API.
> 
> I agree that it is a problem with nodeName being null because we have 
> never said it may be null except by implication that it must match the 
> others.  I am not sure what to do in this case.  I will have to think 
> about that.  Perhaps we need to reconsider the decision to make nodeName 
> match prefix, because it is unnecessary and may be confusing, as we now 
> see.  Another alternative would to have the value of nodeName be 
> something like "#namespace", as it is #text for text, etc.

I completely agree that the prefix should be null for the default namespace
declaration.  I also agree that the nodeName should NEVER be null. 
Therefore, some change in the specification seems necessary.

Either alternative you propose would be fine with me, with a slight
preference for the "#namespace" alternative.

> By the way, are you implementing this?  If so, in what language, if I 
> may ask.

Yes, we have implemented the DOM 3 XPath API on our existing DOM
implementation.  It is in C++.

We're already putting this implementation into products, so a quick
resolution of this issue would be greatly appreciated.

Perry A. Caro
Adobe Systems Incorporated

Received on Friday, 20 September 2002 16:06:10 UTC