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

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

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 <ibc aliax net>