W3C home > Mailing lists > Public > xml-uri@w3.org > May 2000

Need for a Unified spec? Further XPath & Namespace Divergance

From: Clark C. Evans <cce@clarkevans.com>
Date: Fri, 19 May 2000 13:16:13 -0400 (EDT)
To: John Cowan <jcowan@reutershealth.com>
cc: Julian Reschke <reschke@muenster.de>, "xml-uri@w3.org" <xml-uri@w3.org>
Message-ID: <Pine.LNX.4.10.10005191236060.7984-100000@clarkevans.com>
Julian Reschke wrote:
> Playing the devil's advocate...: So maybe it's XPath that needs to and
> should be fixed, not the namespace rec?

The language about "absoultizing" relative URI references is
not the only divergance between the Namespace and XPath 
specification!  

The specifications also diverge on their treatment of the 
infamous "per-element-partition".  The XPath spec's notion 
of "equal" *ignores* the element part of the expanded-name.

From my reading of the XPath spec, the expanded name for 
att in <x:a att='val' /> is 'equal' to the expanded name
for att in <x:b att='val' />.   While, according to the
namespace spec, they would not be equal, as "a" != "b".

I can see that the per-element partition is problematic
for XPath expressions.  Take the following input:

  <test xmlns:x="some:uri" xmlns:y="another:uri"> 
     <x:a att="1" />
     <y:a att="2" />
     <x:b att="3" />
     <y:b att="4" />
     <c   att="5" />
     <c x:att="6" />
  </test>

Which one of the attribute nodes should end up in the 
node-set fetched by "//@att" ?  How about "//@x:att" ?

It seems that "//x:b/att" seems the only 'valid' form.
So, perhaps the first form "//@att" should be interpreted
as a short hand for:  "//*:*/@att" ?  Hmm.  Would this
match case #5?   

...

Perhaps the namespace spec, the xml:base spec, and
the relevant portions of the XPath spec, and any other
spec should be bundled together and re-specified in
a consistent way.

Best,

Clark Evans



P.S.

test.xml
  <test xmlns:x="some:uri" >
    <x:one att="val" />
  </test>

test.xslt
  <xsl:template match="/" >
     <xsl:value-of select="//@att" />
  </xsl:template>

As expected, the result of this is "val" under XT.
I can only guess that XT treats //@att as having
a wildcard namespace-uri that matches anything...
beacuse it is clearly null; while what it is matching
is not null... according to the namespace spec.  
A tad bit confusing if you ask me.
Received on Friday, 19 May 2000 13:13:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:42 UTC