Re: [Simple] WGLC: XCAP Base

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

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

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.

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

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

> -Jonathan R.

br,
Jari


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