[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] WGLC: XCAP Base
On Sun, 2004-08-01 at 18:25, ext Jonathan Rosenberg wrote:
> Thanks for your comments, Jari. Responses inline.
>
> Jari Urpalainen wrote:
>
> > A few comments/questions.
> >
> > 8.5 Managing Etags
> >
> > As Jonathan has interpreted (complying with rfc2616) that a node or even
> > an attribute of an xml-document can be regarded as a resource is it
> > allowable to send the document ETag after partial delete which is then
> > actually an ETag of a different resource ?
>
> I don't know. I fear that the answer is no; after a DELETE, the resource
> is deleted, so by definition THAT resource doesn't have an etag anymore.
>
> > I would certainly prefer that
> > it is still being sent as otherwise you introduce a second deficiency
> > into safe updates of the document (the first one being partial append).
>
> I'm not sure what ability we have to mandate this. Since we're using
> HTTP, its going to depend on what HTTP says. I looked around for any
> text which talks about etags in DELETE responses, and didnt see anything.
>
> > This would mean that only partial modifies are safe. I can think only
> > ugly solutions to this IMO annoying problem which is mostly due to the
> > fact that partial updates were (naturally) not thought when http was
> > created.
>
> Well, we have what we have. I do think we need to clarify the etag
> behavior in DELETE. If someone can confirm that a DELETE response would
> never contain an etag, that would be helpful.
>
>
> An alternative that I debated (but discarded) for this whole mess was to
> think of resources in a document as not getting deleted, but rather,
> becoming empty. That is, if element <foo> exists in a document, than any
> child of that element is said to exist, but be empty. Thus, if you did a
> GET against an element whose direct parent existed, you would not get a
> 404; you'd get a 204 (No Content). That would include an entity tag,
> since 204 explicitly permits meta-data.
>
> Thus, you would never actually DELETE. To remove an element, you would
> do a PUT against it, and the body of the PUT would be empty.
>
> This has the benefit that an insertion operations morphs into a
> modification. An element gets modified from empty to having the value in
> the PUT.
>
> As a result, entity tags would become meaningful for insertions,
> deletions and modifications as we know them today.
>
> The drawback to this approach is that its clearly a hack. It will
> require the server to be able to create and manage meta-data for an
> infinite number of resources. Clearly this would be done on-the-fly, but
> its ugly. It also adds some complexity, and produces behavior which is
> non-obvious. Furthermore, it might have ugly interactions with other
> mechanisms we might consider down the road, but I'm not sure.
>
> So, I discarded this approach.
>
>
> >
> > 6.3 Node selector
> >
> > Although I have already commented on the default namespace issue I'll
> > repeat it here: XPath 1.0 has the interpretation that namespace uri is
> > null if the location step prefix is empty. The upcoming XPath 2.0 seems
> > to use the element context which is the only sane way in XCAP, too. So
> > just clearly state that in the text (otherwise compliant with XPath 1.0).
> >
>
> This is flagged as "todo" in the document. I understand that the default
> namespace for xpath expressions is null (something I have never
> understood the rationale for). I agree this seemed horribly broken. In
> XPath 2.0, help me understand how this works. Lets say the namespace is
> defined as the one from the current element context in which the Xpath
> expression is being evaluated. I have a doc that is like this:
>
> <foo>
> <test:bar xmlns:test="urn:testing:namespace"/>
> <other:bar xmlns:other="urn:testing:other"/>
> </foo>
>
> Lets say I want to select the test:bar element, and I'm evaluating an
> expression within the foo context. I can't figure out how to construct
> an xpath expression to do that. The reason is that, if the evaluation
> context is foo, I can't name test:bar or other:bar because the
> namespaces test and other aren't defined in the foo context.
>
> 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> -> 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. (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>.
>
>
> > 7 Client Operations
> >
> > I am sorry to repeat but I still don't understand idempotent delete.
> > What should the server do during "a subsequent DELETE to the same URI
> > should FIND the resource deleted..." ? I don't understand find here.
>
> The server wouldn't do anything different. WHen the second DELETE
> arrives, it would look at the URI, and find that the resource doesn't
> exist, and thus reject the DELETE with a 404.
>
> I reworded the text thusly:
>
> look the same. Similarly, when a client performs a DELETE, if it
> succeeds, a subsequent DELETE to the same URI will generate a 404;
> the resource no longer exists on the server since it was deleted by
> the previous DELETE operation. To maintain this property, the client
>
> Is that better?
>
definitely, though idempotency issue still remains, btw. has anybody
contacts to the http authors ?
>
> > ---------------
> > 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.
> > Also in all examples where
> > location steps exist there should be more predicates to imply that each
> > step has to point to a single element.
>
> OK, I will do that.
>
> >
> > Also I havn't noticed any discussions in the mailing lists about caching
> > proxies as they will certainly try to cache responses unless
> > Cache-Control or Expires headers are used. So some recommendations are
> > needed in the text.
>
> 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.
Thanks,
Jari
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple