Re: [Simple] WGLC: XCAP Base

[Jonathan Rosenberg <jdrosen at dynamicsoft.com>]

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



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

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


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

-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