Subject: [Simple] XCAP Issue 8: Etag Scope

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Jun 2004 22:39:49 -0400

Folks,

I've spent a bunch of time since the interim trying to work out details
on how etag handling in XCAP needs to work, and to address the question
asked by Aki, which is how the client keeps its etags synchronized with
the server. As you may recall, at the last IETF meeting, we had
consensus that etags could be scoped to various sub-trees in a document,
rather than the whole document.

In a separate note, I will send out the text that I created for the xcap
specification which  defines what this means. It concretely defines a
"scope" as a set of resources (each resource having a unique HTTP URI)
which all share the same value of an etag. Each resource can only be in
one scope. A change in one resource in a scope causes a change in the
etags for all other resources in that scope. A scope is structured as
either a subtree, or as the intersection of a sub-tree with sub-trees
beneath it.

Unfortunately, it got really complicated, as you can see from the text.
I think we need to simplify this a lot. I was able to come up with three
possible simplifications that made sense. They are:

1. Revert to whats currently documented in xcap - there is only one
scope, and its for the entire document. Thus, the document, and all
elements and attributes within it, would have the same etag. This would
make it very hard to have two people independently edit separate parts
of the same document. If you want that, you need to have multiple documents.

2. Redefine a scope as just a tree (never the intersection of a tree
with some of its sub-trees). Any elements outside of the defined scopes
have NO etag. Here's an example. Lets say I have a document that looks
like this:

<document>
   <lists>
      <list id="1">STUFF</list>
      <list id='2">OTHER STUFF</list>
   </lists>

   <users>
     <happy-users>
        <user id="joe"/>
        <user id="bob"/>
     </happy-users>
     <sad-users>
        <user id="mary"/>
        <user id="bill"/>
     </sad-users>
   </users>
</document>

The application usage would indicate that the scopes are defined by the
elements matching the expressions "/document/lists/list" and
"/document/users/happy-users/user" and "/document/users/sad-users/user".
  Any element that matches one of those expression is the root of a
scope, and that scope would include the sub-tree rooted in that element.
Any element outside of those scopes has no etag. This includes the
document itself.

The rationale for this is that it matches how things would work if each
scope was actually a document in a filesystem, and every  element above
it was a directory in that filesystem. Normally, those directories are
not directly referenceable as an HTTP resource, and don't inherently
have etags.

This appraoch vastly simplifies the procedure by which a client keeps
its etags up to date. It would also allow a single document to be edited
by multiple users, without stepping on each others toes. The drawback is
that, if you don't want to edit just pieces of the document, but rather
the document as a whole, you can't take advantage of etags to make sure
you don't clobber someone elses changes.

There are two variants for this approach:

Variant A: The definition of the scope boundaries are defined by the
application usage, and applied to all documents

Variant B: The definition of the scope boundaries are defiend by the
application usage. It can define a multiplicity of potential scope
boundaries, and each document uses one of them. We provide a way for the
client to dynamically determine which scope boundaries are in use. This
would allow some documents to have an etag for the whole document, and
others to have etags only for sub-trees within it.

3. Go with the approach documented by the text I sent in the other note.

So, which do we do? I think we should do option 1. Its really simple. I
dont think any of our current usages would really require multiple
editors on the same document; it seems like we should always be able to
split it into multiple documents.

Thoughts?

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

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Jun 2004 16:54:00 -0400

I think we should stick with option 1.
(It happens I had this same debate with a person here at the office last 
night.)

If we tried to define "scopes", we would be defining the outermost layer at 
which we could provide atomicity.  If, when we first defined the 
application usage, we could be really sure that we knew the right scopes, I 
suppose we could allow that.  However, trying to guess the evolution of 
information in a structure is difficult.  We would probably end up over 
time with documents with information in strange places so that the lock 
scope (etag checking) matched the semantic coupling.

Unless we are prepared to add additional mandatory headers (a fate I hope 
to avoid) we have to make sure that the scope that turns out to be 
necessary is the one that is used.
While the "document" may be too large sometimes, too large is not a 
significant drawback.  If the defined scopes are too small, we will find 
ourselves having to add locking mechanisms.

Yours,
Joel

PS: On the insert issue, I can live with documenting what we have, and I 
can live with "things are always vacuously present".  Adding optional 
headers is not a good idea.