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 <i...@aliax.net>
_______________________________________________
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
http://mail.gnome.org/mailman/listinfo/xml
