Re: [Simple] WGLC: XCAP Base

[Jonathan Rosenberg <jdrosen at dynamicsoft.com>]

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).


> 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?

> >  (and if you use fully xpath 1.0 compatible
> >
> > > libraries they'll most likely have some "hooks" where namepaces can be
> > > "registered" when evaluating xpath expressions). I'll also remind that
> > > with XCAP it was agreed that namespace definitions can not be added like
> > > attributes, so during insert you can not just insert <test:bar> (as it
> > > has namespace definition), instead you have to insert <foo>.
> >
> > No, xcap does not say this. It says you cannot SELECT based on a 
> > namespace attribute. That does NOT mean that an inserted element (i.e., 
> > the thing in the  body of the PUT) cannot contain a namespace 
> > declaration attribute.
>
>
> ok, that's better than my incorrect interpretation. This is definitely
> worth mentioning more clearly in the draft, because it needs some
> handling during implementation. Even an example would not be bad...

OK, I will clarify.

> > > > > ---------------
> > > > > I still miss non-default namespace examples. 
> > > >
> > > > Once I figure out how this works, I will add them. The norm for us will 
> > > > include non-default namespaces, so, in fact, I will change all of them 
> > > > to use non-defaults.
> > >
> > > as both models are allowed it would imo be best to have also both
> > > examples.
> >
> > OK.
> >
> >
> >
> > > > Good point. Caching responses is OK, I think. If a client is GETing lots 
> > > > of different elements within the document, the caching won't be very 
> > > > effective. A cache won't know how to relate the URI for the document 
> > > > with the URIs for the elements and attributes within the document, but 
> > > > thats OK. The caching isn't broken; its just not taking advantage of 
> > > > xcap URI interdependencies to improve performance. Putting that aside, 
> > > > subsequent requests for the same URI/resource could fetch the content 
> > >
> > > > from a cache. That would be OK. The server probably wants to set the 
> > >
> > > > max-age such that the content expires relatively quickly, but this 
> > > > probably depends on the application usage.
> > > >
> > > > As long as all of that sounds fine, I will add text explaining this in a 
> > > > new section on caching.
> > > >
> > > > -Jonathan R.
> > >
> > > What worries me here mostly is that after partial delete/put caches may
> > > send incorrect content (e.g. when getting the whole document). This is a
> > > similar problem as what we have with ETags, because a single document
> > > contains many resources which are somehow related.
> >
> > Ahh, interesting. You are correct. A cache knows to invalidate when it 
> > gets a PUT to a resource, but not when it sees a PUT to another resource 
> > which invalidates the cache.
> >
> > Of course, with ANY caching scheme, the resource could change by a PUT 
> > to that resource that doesn't go through the cache. Thats a consequence 
> > of caching. I don't think XCAP changes anything there. The same caveats 
> > apply; if you cache, the document may be stale.
>
>
> that's right that caches may miss requests (e.g. different route), but 
> in order for them to be efficient they should also know xcap semantics
> the requirement of which is not desirable.

Well, we can't (and shouldn't) ask for caches to change.

-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen at dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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