Re: [xml] Using Xpath with default namespace and null prefix

[Iñaki Baz Castillo <ibc aliax net>]

El Lunes, 8 de Febrero de 2010, François Delyon escribió:

> No XPath 2.0 does not allow this kind of ambiguity.
> If a "Default element/type namespace" property exists in the static
> context, this URI is used for "for any unprefixed QName appearing in a
> position where an element or type name is expected."
> (but how can I reach elements without namespace? )
>
>
> And the RFC 5261 section 4.2.2 says more precisely:
>
> "The prefix matching rules described previously in this section are
>     different from those required in XPath 1.0 and 2.0
>     [W3C.REC-xpath20-20070123].  In XPath 1.0, a "bar" selector always
>     locates an unqualified <bar> element.  In XPath 2.0, a "bar"
> selector
>     not only matches an unqualified <bar> element, but also matches a
>     qualified <bar> element that is in scope of a default namespace
>     declaration.
> In contrast, in this specification, a selector without
>     a prefix only matches one element, and it may match an element with
>     or without a prefix but only if the namespace it's qualified with
> (or
>     none) is an exact match."
>
> That's clear!
> Less clear is how can I reach elements without namespace in Xpath 2.0?
> Mysterious.

I understand from the above text the following:

 <root xmlns="urn.default">
    <child />
  </root>

with Xpath 1.0 the query to get <child> must be (in Ruby Nokogiri syntax but 
hope it's clear what I mean):

  doc.xpath( "/ns:root/ns:child", {"ns"=>"urn.default"} )


With Xpath 2.0 the following would be valid:

  doc.xpath( "/root/child" )

Both "root" and "child" match the nodes into the document as "in XPath 2.0, a 
"bar" selector not only matches an unqualified <bar> element, but also matches 
a qualified <bar> element that is in scope of a default namespace 
declaration."

Am I wrong?



> I agree with Daniel, XPath 1.0 is very clear.

Yes, I also agree :)
I'm just asking it because I've found this "special addition" to Xpath in XCAP 
protocol for which I¡m developing a server and client.


> On the other hand, considering XPath and xhtml, in most cases you have
> to invent an irrelevant prefix to build correct XPath expressions.

Sure. The problem is that in XCAP sometimes a XMl document contains a 
reference to a XMl node into other XML document, i.e.:

  <external anchor="http://xcap.server.org/document.xml/~~/root/child"; />

Let's suppose that the "application default namespace" (a concept added in 
XCAP RFC 4825) is "urn.default". Then the XCAP client should parse the Xpath 
expression from the <external> node:
  "/root/child"
and should inspect such Xpath in the above document. But unfortunatelly prior 
to it the client must transform such Xpath into:
  "/ns:root/ns:child"
and then use:
  doc.xpath( "/ns:root/ns:child", {"ns"=>"urn.default"} )

This is a pain because it requires the client to parse and modifies the Xpath 
expression :(

  

> In this context, it is rather uncommon to have elements without
> namespace.

Unfortunatelly it's common in XCAP protocol and applications as the above 
example.


> Thus the XPath 2.0 rule is perhaps relevant, and
> I think that it should be easy to add the "Default element/type
> namespace" property to the xmlXPathContext; this could simplify Xpath
> expressions for xhtml.
>
> By the way (prefix and namespace), I have a request about exslt.
> Some useful functions like exsltStrXpathCtxtRegister have been added.
> But they require a non-null prefix, which is not convenient in my case.
>
> int
> exsltStrXpathCtxtRegister (xmlXPathContextPtr ctxt, const xmlChar
> *prefix)
> {
>      if (ctxt
>          && prefix
>          && !xmlXPathRegisterNs(ctxt,
>                                 prefix,
>                                 (const xmlChar *)
> EXSLT_STRINGS_NAMESPACE)
>          && !xmlXPathRegisterFuncNS(ctxt,
>                                     (const xmlChar *) "encode-uri",...
>
> could be replaced with
>
> int
> exsltStrXpathCtxtRegister (xmlXPathContextPtr ctxt, const xmlChar
> *prefix)
> {
>      if (!ctxt)return -1;
> if(prefix && xmlXPathRegisterNs(ctxt,prefix,(const xmlChar *)
> EXSLT_STRINGS_NAMESPACE))return -1;
> if(!xmlXPathRegisterFuncNS(ctxt,
>                                     (const xmlChar *) "encode-uri",...


Could this modification in libxml2 allow the "wrong" behavior I need?

Thanks a lot.




-- 
Iñaki Baz Castillo <ibc aliax net>