RE: [xml-dev] the Canonical path of a node

At 01:08 PM 2007-01-08 +0000, Michael Kay wrote:
>It's a shame that XPath doesn't define a mechanism for binding
>prefixes within the expression itself. I think it would be a good idea if we
>could establish a conventional notation for an "augmented XPath expression":
>a string containing a set of namespace bindings and an XPath expression, and
>we could then encourage people to implement APIs that accept an "augmented
>XPath expression".

I fully agree.  Prefixes, being only aliases in XML standard, ought not 
become as
standard within XPath relative to namespace values as they are now.  What 
we need
is a standard way to refer to the namespace value without changing the logical
address referred to by a given XPath, even with prefixes are changed.


>  One candidate is the XPointer syntax:
>
>xmlns(p1=http://p1.uri/) xmlns(p2=http://p2.uri/) xmlns(p=http://p.uri)
>xpath2(/p1:a[1]/p2:b[1]/p:c[1])
>
>This has a few drawbacks like not allowing the default namespace to be
>declared, and requiring ")" and "^" to be escaped as "^)" and "^^"; but at
>least it's defined in an existing standard.

I don't think, however, the XPointer syntax is useful either;  it is only 
hiding
the dust (prefixes) under the carpet (of predefining the prefixes with 
namespace
values, then followed by XPath).  I'd suppose a characteristic of a suitable
syntax would be such that it is as independent of prefixes as XML has 
defined it.

Another syntax I'd suggest, using your logical XPath point example above,
would be:

/{http://p1.uri/}:a[1]/{http://p2.uri/}:b[1]/{http://p.uri/}:c[1]

Advantage is clearly it is prefix-independent, follows closely XPath's style
of expressing pathways, and does not hijack space character.  Disadvantage
is certainly the length involved for long XPaths or long namespace values.
But I think I'm happier living with the latter.  I've seen it used somewhere,
but not sure if it has worked its way into some proposed standard or something.




cheers.