GNOME.org
 

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


Le 8 févr. 10 à 17:02, Iñaki Baz Castillo a écrit :


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?


Yes.
Either you specify a default namespace in the XPath static context (not in the document), and unprefixed requests match only elements in that default namespace, 
or you will match only non-qualified elements.






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"} )


or "/root/ns:child" or "/ns:root/child".
That only 2^n possibilities. Fine.
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.
But as far as I understand XCAP, it is possible to use regular XPath expression by providing a namespace-prefix pair in the request part of the URL. 
In fact, I don't understand why XCAP does not simply use XPointer.





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.




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

Thanks a lot.




--
Iñaki Baz Castillo <ibc aliax net>
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xml gnome org
http://mail.gnome.org/mailman/listinfo/xml
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]