El Lunes, 8 de Febrero de 2010, Daniel Veillard escribió: > On Mon, Feb 08, 2010 at 03:08:49AM +0100, Iñaki Baz Castillo wrote: > > Unfortunatelly in my case I'm implementing a XCAP (RFC 4825) client and > > server. XCAP reuses Xpath but allows Xpath nodes without prefix matching > > an "application specified namespace". This is, the following "Xpath" > > should work > > Sorry, that's not XPath behaviour, and not possible with libxml2 which > implements XPath. I'm very surprized that such a deviation from a W3C > standard was allowed in an IETF specification, there used to be liaison > between W3C and IETF to avoid this kind of problems. I note that RFC 4825 > references an XPath 2.0 Candidate Recommendation, libxml2 implements > XPath 1.0 , so maybe the divergence is normal but this should be > double-checked.
Thanks a lot for your response. I asked about this issue in IETF-SIMPLE maillist (SIMPLE is the SIP group handling presence/XCAP subjects), and I got this response: ----------------------------------------------------- > Unfortunatelly I don't understand yet the real purpose of the "default auid > document namespace" :( As said, it was defined to avoid those long URIs. If the model were according to XPath 1.0 spec, you'd always need query parameters with requests (with qualified element conventions). So there's indeed a deficiency with selections if default document namespace is defined for an AU, i.e. you can't select unqualified elements then, but this is a minor issue. Note also that XPath 2 selects also qualified elements (default namespace) with a selection like "foo", so XPath 2 is closer to XCAP interpretation, but it's not the same. If you still insist on having more XPath like selection logic look section 4.2.1 and 4.2.2 of rfc5261 ------------------------------------------------------- and RFC 5261 section 4.2.2 says: ------------------------------------- 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. ------------------------------------- Also I've found in Xpath 2.0 specification the following: -------------------- [Definition: Default element/type namespace. This is a namespace URI or "none". The namespace URI, if present, is used for any unprefixed QName appearing in a position where an element or type name is expected.] The URI value is whitespace normalized according to the rules for the xs:anyURI type in [XML Schema]. -------------------- and also: -------------------- 2.5.4 SequenceType Matching [...] QNames appearing in a sequence type have their prefixes expanded to namespace URIs by means of the statically known namespaces and (where applicable) the default element/type namespace. As usual, two expanded QNames are equal if their local parts are the same and their namespace URI's are the same. An unprefixed attribute QName is in no namespace. -------------------- Does it mean that Xpath 2.0 allows the behavior I meant (present in RFC 4825)? Is it planned libxml2 to implement Xpath 2.0? > 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 :( Thanks a lot. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
