On Mon, Feb 08, 2010 at 01:14:22PM +0100, Iñaki Baz Castillo wrote: > El Lunes, 8 de Febrero de 2010, Daniel Veillard escribió: [...] > > Does it mean that Xpath 2.0 allows the behavior I meant (present in RFC 4825)?
I don't know, I doubt it. > Is it planned libxml2 to implement Xpath 2.0? I have no such plan > > I also see it reference XML Fragment Interchange CR draft, so I really > > wonder if the liaison work was properly done on that IETF specification >:-> > > RFC 4825 is a pain as it reuses Xpath 1.0 with some restrictions and > additions > (as the "application default namespace" which allows the Xpath deviation I > told) so a XML library implementing Xpath 1.0 is not enough valid to > implement > a XCAP client/server :( You will have to capture the XPath expression and mofify them before calling libxml2, there won't be any way around. The fundamental reason why allowing something like "//foo" to mach an element in the default namespace is that this namespace can change wherever in the document <foo> <foo xmlns="http://example1.com/foo"/> <foo xmlns="http://example2.com/foo"/> </foo> //foo would then returns 3 elements with completely different semantic coming from different vocabularies. XML being designed for being extensible XPath had to put a safeguard. Matching in XPath is designed as a match on the tuple [Namespace URI name , element name] , that's made 100% clear in the XPath spec, the prefix, present or not, is completely irrelevant in the XPath query. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ _______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml