Re: [Simple] WGLC: XCAP Base

[Jari Urpalainen <Jari.Urpalainen at nokia.com>]

On Wed, 2004-08-04 at 03:52, ext Jonathan Rosenberg wrote:
> inline.
> 
> Jari Urpalainen wrote:
> 
> > On Mon, 2004-08-02 at 21:29, ext Jonathan Rosenberg wrote:
> > 
> >>Jari Urpalainen wrote:
> >>
> >>
> >>>>I'm hoping that I've just misunderstood how to construct the namespace 
> >>>>context for xpath expression evaluations....
> >>>>
> >>>
> >>>As you can't send namespace prefix and corresponding namespace uris with
> >>>queries (unless you use namepace-uri() and local-name() functions) you
> >>>have to use in-scope definitions that you find from the document. Given
> >>>your example I don't see a problem: <foo> does not know test or other
> >>>namespace definitions only <bar>'s have in-scope definitions. So you can
> >>>do relative selections like "test:bar[condition xxx]" within <foo>
> >>>context as <bar> (which is a child node of <foo> 
> >>
> >>Here is where I don't follow. Within foo, the namespace "test" is NOT 
> >>defined. So, how can I possibly canonicalize it in order to do an 
> >>equality check? Remember, equality checks with namespaces require 
> >>canonicalization to the namespace URI; that is, the prefix is always an 
> >>alias to the namepsace URI. Thus, the following two elements are equal:
> >>
> >><foo xmlns="namespace">
> >>
> >><ns:foo xmlns:ns="namespace">
> >>
> >>
> > 
> > right.
> > 
> > 
> >>-> also a new location
> >>
> >>>step) clearly belongs to test:.. namespace. So when doing
> >>>implementations location step parsers have to be aware of all in-scope
> >>>namespace definitions.
> >>
> >>Right, I agree. But the two namespaces I need to select the children are 
> >>not in scope!
> >>
> > 
> > 
> > right, not in-scope of <foo> but instead in-scope of <bar> the child of
> > <foo>. 
> 
> Right; but we are selecting based on foo's context!
> 
> > So if you select from foo's parent context with relative request
> > foo/test:bar you'll first find <foo> (lets's say no default namespace
> > defined) as no prefix no namespace expansion. Then you take the next
> > step, the bar node which happens to have prefix and in-scope namespace
> > definition so you have to compare the namespace uri and element name in
> > <bar> context. 
> 
> Your assumption here is that the context is modified each time we do an 
> equality comparison. That is, when I check to see if the location step 
> matches a particular child, I adopt the namespace context in scope for 
> that child. This seems circular to me, and not what the Xpath spec is 
> saying (I thought).

I have just glanced at the spec but I can't imagine any other way how
expression evaluation could work, because in xml you can/will attach the
namespace definition to the same node where it is defined.

Also XPath 1.0 spec does not say from where you do find the namespace
definitions (prefix and uri), for that e.g. XPointer (look 5.2) is
needed (i.e. if you don't use local-name() and namespace-uri()). If (and
when) you have to rely on the document context I don't see any other
options unless you have better ideas ?

> > 
> > Similarly, if <foo> happens to be a root node of the document and you
> > have namespace definition there, then you also have "in-scope" namespace
> > definitions that has to be followed:
> > 
> > <foo xmlns="namespace">
> > </foo>
> > 
> > selecting with absolute query /foo will fail with xpath 1.0 compatible
> > query because <foo> has in-scope namespace definition. For the request
> > to succeed you should provide a query like /ns:foo where ns="namespace".
> > With xpath 1.0 you can have
> > /*[local-name()="foo"][namespace-uri()="namespace"]
> > This syntax is of course "not so nice" and it is desirable to use the
> > in-scope namespace definition which is defined in this case within the
> > child element. So the confusion seems to be where the in-scope namespace
> > is defined and how the query is interpreted.
> 
> Right. So, are you saying that XPath 2.0 says that, when evaluating 
> steps along a child axes, you define the scope as the scope of that 
> child when performing the evaluation?
> 

if you look at the query /foo, / means document root and <foo> is the
child of /, i.e. the document root. So if we select from the document
root we'll find the child the <foo> node and yes the context in <foo> is
different from / as it is another step, right ? And if you have a query
like /ns:foo it is clear to me that you start searching for definition
for ns from <foo> context given the xml namespace model. 

The bogus default namespace behavior in xpath 1.0 is a well known
feature (deficiency) and I just assume that 2.0 will have that fixed by
this in-scope namespace definition. Also I assume that declaration of
namespaces in queries are left to XQuery so that XPath 2.0 don't either
have them (I might be wrong here). However, imo it doesn't matter that
much how it will be handled in the new xpath 2.0 spec because XCAP is
having an own bnf which is otherwise compatible with xpath 1.0, but
default namespace handling just needs to be different (i.e. sensible)
and that search for non-default namespace definitions should also be
defined in the draft. 

I am aware that using document context is far from optimal (or elegant)
but do we really have any good options ?

Furthermore, all of the libraries that I am aware of and claim to be
XPath 1.0 compatible leave this non-default namespace definitions search
out of the query, so you have to "register" namespace definitions
separately.

This is certainly a problem (as you have said) but imo it is up to us to
find a proper search model. 

br,
Jari


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple