- 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>
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