Subject: [Simple] XCAP issue 5: selecting multiple elements

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 May 2004 02:12:25 -0400

This is probably the second most significant open issue in xcap (second 
to PUT vs. POST).

Currently, XCAP has a major limitation that each URI can select only a 
single XML element or attribute at a time. So, if you want to delete 
more than one element, you need multiple DELETE operations. If you want 
to add more than one new element, you need to either do multiple PUTs, 
or do one PUT, but include in that put all of the existing siblings for 
the new elements.

The concern has been raised that this limitation is simply too 
prohibitive for a protocol whose purpose in life is to muck with lists 
of things.

So, I had, during the meeting, proposed a technique for doing this. The 
idea is that we would take on a few more of the features of Xpath, and 
allow boolean OR expressions inside of a predicate. The grammar for this 
(thanks to Jari for correcting me on it) would look like this:

PUT http://server.com/xcap-root/document/foo/bar[position()=4 or 
position()=5]

<bar id="first new one"/>
<bar id="second new one"/>

This selects the 4th and 5th bar elements, and replaces them with the 
two in the body of the request.

This change introduces some complexity, though its almost entirely in 
the selection operations. The rest of the protocol remains as it was. 
There is also some increased complexity in the grammar of the URIs and 
of their length. ALso we'll need to escape these in many cases, making 
the URIs uglier. The benefit is adding a major feature that many have 
expressed concerns about.

So, I'm somewhat on the fence, though leaning towards adding this 
functionality to the spec. Jari has indicated that he successfully 
implemented it, which is a good sign.

Thoughts?

-Jonathan R.
-- 
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: Jari Urpalainen <[email-masked]>
Date: Mon, 10 May 2004 11:03:20 +0300

> two in the body of the request.

As I have already posted the other option which I prefer I'll repeat it
here. Instead of position() function we'll use union (as Jonathan
originally proposed) with format like

PUT http://server.com/xcap-root/document/foo/bar[4] |
document/foo/bar[5]

The reasoning behind this is that 
1. each location path selects single node (or node with childlist). This
is already currently the inherent logic in XCAP.
2. union will separate different location paths and it is therefore
trivial for the server to know the intended count of nodes in the
request. Knowing this count is IMO important e.g. when doing multiple
DELETEs. E.g. if the fifth element does not exist in the document
probably we should fail the multiple DELETE request. While I'll admit
that the count can be distinguished from the request above the union
version is easier to implement and what's more you could add nodes to
different locations at the same time (not only sibling nodes). 

Also it has to be defined what should the server do e.g. in the PUT-case
when the 4. element exists and the 5. doesn't and therefore the 4.
element would be replaced and the 5. element is added. If the "usual
http put-semantics" is followed this would not be allowed, I presume.

> expressed concerns about.

uri escaping is also necessary if/when uris are compared with
XPATH-expressions.

BR,
Jari

---

From: Jari Urpalainen <[email-masked]>
Date: Mon, 10 May 2004 11:03:20 +0300

BR,
Jari

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 May 2004 07:48:20 -0400

I believe that the restriction on XCAP that the path select exactly one 
element is a very helpful restriction.  It keeps the semantics simple, and 
at least for the implementation I am working with keeps the implementation 
simple.
I would prefer not to make this change.
Yours,
Joel M. Halpern

At 02:12 AM 5/10/2004 -0400, Jonathan Rosenberg wrote:
>This is probably the second most significant open issue in xcap (second to 
>PUT vs. POST).
>
>single XML element or attribute at a time. So, if you want to delete more 
>than one element, you need multiple DELETE operations. If you want to add 
>more than one new element, you need to either do multiple PUTs, or do one 
>PUT, but include in that put all of the existing siblings for the new elements.
>
>The concern has been raised that this limitation is simply too prohibitive 
>for a protocol whose purpose in life is to muck with lists of things.
>
>PUT http://server.com/xcap-root/document/foo/bar[position()=4 or position()=5]
>
>This selects the 4th and 5th bar elements, and replaces them with the two 
>in the body of the request.
>
>This change introduces some complexity, though its almost entirely in the 
>selection operations. The rest of the protocol remains as it was. There is 
>also some increased complexity in the grammar of the URIs and of their 
>length. ALso we'll need to escape these in many cases, making the URIs 
>uglier. The benefit is adding a major feature that many have expressed 
>concerns about.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 10 May 2004 07:48:20 -0400

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 11 May 2004 12:43:35 -0400

inline.

> PUT http://server.com/xcap-root/document/foo/bar[4] |

Ahh.

I wasnt ignoring your previous post Jari, I simply didnt understand that 
you were proposing this. Its an interesting idea. Comments on this 
approach below.

> is already currently the inherent logic in XCAP.

Right, but one way or another we are going to have to now say what it 
means for the URI to select multiple things, so I think this is not 
really an issue.

> different locations at the same time (not only sibling nodes). 

You are combining two issues here. One is, knowing the count, and the 
other is, being able to modify the document in several places at the 
same time.

Regarding the count, I'm not sure this is important. I think we need to 
look at the desired use cases here. Mostly its to add a multiplicty of 
buddies to a buddy list at once, or to add a multiplicity of users to a 
CPCP ACL at once. The main benefit in doing multiple insertions instead 
of one at a time is to save latency and bandwidth. If I need to 
explicitly list each URI for each thing I want to add or delete, its 
less savings. Its still savings, but less.

There is always the possibility of the xcap operation doing something 
you hadn't intended, if for some reason you have a stale version 
locally, or there has been an error in the implementation. The latter 
case is prevented with If-Match, and in the former case, since the error 
is unrecoverable, I'm not sure it really matters to catch it.

Regarding doing insertions in multiple places, I see now what you are 
suggesting. Its very neat. Not sure its a requirement.

Simplicity is however a good thing, and I think the implementation 
complexity of these approaches needs to be thought about a bit, more on 
that later in a separate note.

> http put-semantics" is followed this would not be allowed, I presume.

No, I think it could be allowed if we want. Step back a second - the URI 
points to a single resource. In the case you are proposing, that 
resource is actually a concatenation of components of the document. The 
PUT operation says that "this is the new value for that resource". In 
the cae you describe, the server would modify the document so that the 
URI now returned the content present in the request. It would do this by 
  modifying the doc where modifications were called for, and adding to 
it where additions were called for.

We could disallow this ourselves by simply declaring such a case as a 
conflict, and therefore have it return 409. Its up to us to define what 
constitutes a conflict for that resource.

> uri escaping is also necessary if/when uris are compared with

Right.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 11 May 2004 13:05:15 -0400

Joel,

This is useful input, thank you. I am glad that we have the opportunity 
to design the protocol while at least two implementations are in 
progress (that running code bit!).

I think its worth thinking about the implied complexity in the 
implementation. I had in mind (and I havent myself been doing an 
implementation I'll admit) that it would work like this. The server 
receives a PUT/GET/DELETE for a document under the xcap root services 
URI. It fetches the XML document (from disk, DB, or whatever), and 
parses it, resulting in a DOM type of structure. Then, the node selector 
expression is applied to the DOM tree. If the xpath expression returns a 
node in the tree, that node is replaced with the DOM-parsed version of 
the content of the request (this is the replacement case). If the xpath 
expression returns empty, its insertion and tree surgery time.

Now, here is where things get tough. You need to insert the content from 
the request such that the URI would select that content after insertion. 
For arbitrarily complex URIs, this is hard, really hard. Indeed, if you 
included full regular expressions and things like that, I would suspect 
it approaches an O(N) search, where N is the number of nodes in the 
tree. That is, you'd have to insert the new element at each possible 
place in the document (O(N) for a tree with N elements) and check to see 
if, after re-evaluation of the node selector, it selects what you just 
inserted.

We *dont* want to do that, and therefore, we need to make sure that 
there is a sane way to do this insertion without a search.

As currently defined, its easy. You'd strip off the last step in the 
xpath expression in the URI, and evaluate the rest of the URI. That will 
select the parent node of the new element. Then, you look at the piece 
you just stripped off. If its a positional selector, you know just where 
to insert the new thing. If its an attribute/vaue selector, you insert 
at the end. I think that, by removing the constraint that the insertion 
be done as schema aware, you make this step much simpler. If you had to 
do the insertion with schema awareness, you might get back to a search 
operation - continually trying several insertion points until you found 
one that works (i.e., the resulting tree was validated according to the 
schema).

Now, if you have a URI that selects multiple nodes, I agree, this gets 
much more complicated. In Jari's proposal, I think the implementation is 
easy - you'd take that union, extract the individual components (say N 
of them). You then take the N elements in the body (there have to be N), 
and associate each with one of the N paths in the URI. You then operate 
on each URI/xml content pair as if it were a separate xcap request per 
above. You need to be careful that you can back up to the original tree 
if something fails part way through.

I must admit that, for a more general expression its hard to see how it 
would work. In the approach I had proposed, I think you basically need 
to do the same kind of processing I describe above. You would use the 
position indicators to break it into N separate element selectors.

Anyway, I'm warming to Jari's approach because it provides a really easy 
way to extend xcap into multiple insertions with what feels to me to be 
a pretty straigthforward extension of what we have today. It may not be 
maximally efficient, but it would give us an easy solution out of the 
box. If we need something more efficient, we could add it downstream 
through an xcap extension (a separate spec).

So, to Joel specifically and the group in general - would you be 
comfortable with Jari's approach for doing this, given the resulting 
implementation logic required as I describe above?

Thanks,
Jonathan R.

Joel M. Halpern wrote:

> element is a very helpful restriction.  It keeps the semantics simple, 
> and at least for the implementation I am working with keeps the 
> implementation simple.
>> This is probably the second most significant open issue in xcap 
>> (second to PUT vs. POST).
>>
>> more than one element, you need multiple DELETE operations. If you 
>> want to add more than one new element, you need to either do multiple 
>> PUTs, or do one PUT, but include in that put all of the existing 
>> siblings for the new elements.
>>
>> So, I had, during the meeting, proposed a technique for doing this. 
>> The idea is that we would take on a few more of the features of Xpath, 
>> and allow boolean OR expressions inside of a predicate. The grammar 
>> for this (thanks to Jari for correcting me on it) would look like this:
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 11 May 2004 12:43:35 -0400

inline.

Ahh.

Right.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 11 May 2004 13:05:15 -0400

Joel,

Thanks,
Jonathan R.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 May 2004 15:09:31 -0400

I think that with some clarifications, Jari's approach should allow 
multiple fetches or multiple insertions in a way that is easy to implement 
and understandable.  A couple of questions / clarifications:

1) The repeating component (that on each side of the "|"), is that any path 
component, the full URI, or the intra-document selector?  With the addition 
of the URI separator ("//" for now), I would like to suggest that it be 
everything after the separator.  The only other alternative would be that 
it always be just the last element, and with the idea that this is a 
preprocessing step, there is no need for that restriction.

2) Presumably, the positions of all elements should be evaluated before any 
one is added?  If I have a list with 3 elements, and I want to add one 
between the first and second, and one between the second and third, (each 
with a unique attribute) what positions do I send?  [2][att="new1"] and 
[3][att="new2"]?  What order will I get if I do [1][att="new3"} and 
[1][att="new4"] in the same PUT request?

3) What happens if the two paths (on a PUT) nest?  Is it defined that they 
be applied in order?  I realize that this case is somewhat silly for the 
client to generate, but we ought to decide what should happen.  I suppose 
we can say "indeterminate" but we should say.

Yours,
Joel M. Halpern

At 01:05 PM 5/11/2004 -0400, Jonathan Rosenberg wrote:
>easy - you'd take that union, extract the individual components (say N of 
>them). You then take the N elements in the body (there have to be N), and 
>associate each with one of the N paths in the URI. You then operate on 
>each URI/xml content pair as if it were a separate xcap request per above. 
>You need to be careful that you can back up to the original tree if 
>something fails part way through.
>
>would work. In the approach I had proposed, I think you basically need to 
>do the same kind of processing I describe above. You would use the 
>way to extend xcap into multiple insertions with what feels to me to be a 
>pretty straigthforward extension of what we have today. It may not be 
>maximally efficient, but it would give us an easy solution out of the box. 
>If we need something more efficient, we could add it downstream through an 
>xcap extension (a separate spec).
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 May 2004 15:09:31 -0400

Yours,
Joel M. Halpern

---

From: Jari Urpalainen <[email-masked]>
Date: Wed, 12 May 2004 09:29:14 +0300

> everything after the separator.  The only other alternative would be that 

yes. "//" will separate the XPATH-compatible query i.e. IMO location
paths has to be complete. Different absolute location paths can also
exist in the query.

> [3][att="new2"]?  

indexes that you send have to end up to be the ones in the final
document, i.e.

[2][@att="new1"] and [4][@att="new2"]

> What order will I get if I do [1][att="new3"} and 

this is an error

BR,
Jari

---

From: Jari Urpalainen <[email-masked]>
Date: Wed, 12 May 2004 09:29:14 +0300

this is an error

BR,
Jari

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 May 2004 08:10:24 -0400

This means that the logic sequence under discussion would be
1) Take apart the request URI into its alternative pieces
2) Extract the corresponding sequence of top level XML elements from the 
request body.  Associate each extracted element with the corresponding URI 
alternative.
3) Process each pair in sequence.  That is, repeatedly
3a) find the location identified by the current alternative compoent from 
the request URI
3b) apply the corresponding top level element to that alternative

The point being that the implementation must not attempt to resolve the 
second location specification until it has processed the first request and 
built an update document to check.

This whole topic also raises an atomicity issue that we have not had to 
deal with until now.  If I can send multiple updates in a request, what 
happens if one of them is in error?    Are all changes rolled back if any 
are in error?  Are changes up to the successful point accepted?  And when 
is document / schema validity to be checked?  (If I have multiple updates 
in the same request, I could have one part adding an item with a "key", and 
another part adding a reference to that "key", using schema key and 
keyref.  Is the order of these two in my update important?)

Yours,
Joel M. Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 May 2004 08:10:24 -0400

Yours,
Joel M. Halpern

---

From: Alex Audu <[email-masked]>
Date: Wed, 12 May 2004 12:21:40 -0500

I think Jari's approach  is a good one.  It seems to be simpler and the 
added counting benefit  is a plus.

Regards,
Alex.

Jonathan Rosenberg wrote:

> Joel,
>
> This is useful input, thank you. I am glad that we have the 
> opportunity to design the protocol while at least two implementations 
> are in progress (that running code bit!).
>
> parses it, resulting in a DOM type of structure. Then, the node 
> selector expression is applied to the DOM tree. If the xpath 
> expression returns a node in the tree, that node is replaced with the 
> DOM-parsed version of the content of the request (this is the 
> replacement case). If the xpath expression returns empty, its 
> insertion and tree surgery time.
>
> Now, here is where things get tough. You need to insert the content 
> from the request such that the URI would select that content after 
> insertion. For arbitrarily complex URIs, this is hard, really hard. 
> Indeed, if you included full regular expressions and things like that, 
> I would suspect it approaches an O(N) search, where N is the number of 
> nodes in the tree. That is, you'd have to insert the new element at 
> each possible place in the document (O(N) for a tree with N elements) 
> and check to see if, after re-evaluation of the node selector, it 
> selects what you just inserted.
>
> xpath expression in the URI, and evaluate the rest of the URI. That 
> will select the parent node of the new element. Then, you look at the 
> piece you just stripped off. If its a positional selector, you know 
> just where to insert the new thing. If its an attribute/vaue selector, 
> you insert at the end. I think that, by removing the constraint that 
> the insertion be done as schema aware, you make this step much 
> simpler. If you had to do the insertion with schema awareness, you 
> might get back to a search operation - continually trying several 
> insertion points until you found one that works (i.e., the resulting 
> tree was validated according to the schema).
>
> much more complicated. In Jari's proposal, I think the implementation 
> is easy - you'd take that union, extract the individual components 
> (say N of them). You then take the N elements in the body (there have 
> to be N), and associate each with one of the N paths in the URI. You 
> then operate on each URI/xml content pair as if it were a separate 
> xcap request per above. You need to be careful that you can back up to 
> the original tree if something fails part way through.
>
> I must admit that, for a more general expression its hard to see how 
> it would work. In the approach I had proposed, I think you basically 
> need to do the same kind of processing I describe above. You would use 
> the position indicators to break it into N separate element selectors.
>
> Anyway, I'm warming to Jari's approach because it provides a really 
> easy way to extend xcap into multiple insertions with what feels to me 
> to be a pretty straigthforward extension of what we have today. It may 
> not be maximally efficient, but it would give us an easy solution out 
> of the box. If we need something more efficient, we could add it 
> downstream through an xcap extension (a separate spec).
>
>> I believe that the restriction on XCAP that the path select exactly 
>> one element is a very helpful restriction.  It keeps the semantics 
>> simple, and at least for the implementation I am working with keeps 
>> the implementation simple.
>>> Currently, XCAP has a major limitation that each URI can select only 
>>> a single XML element or attribute at a time. So, if you want to 
>>> delete more than one element, you need multiple DELETE operations. 
>>> If you want to add more than one new element, you need to either do 
>>> multiple PUTs, or do one PUT, but include in that put all of the 
>>> existing siblings for the new elements.
>>>
>>> prohibitive for a protocol whose purpose in life is to muck with 
>>> lists of things.
>>>
>>> The idea is that we would take on a few more of the features of 
>>> Xpath, and allow boolean OR expressions inside of a predicate. The 
>>> grammar for this (thanks to Jari for correcting me on it) would look 
>>> like this:
>>>
>>> This selects the 4th and 5th bar elements, and replaces them with 
>>> the two in the body of the request.
>>>
>>> This change introduces some complexity, though its almost entirely 
>>> in the selection operations. The rest of the protocol remains as it 
>>> was. There is also some increased complexity in the grammar of the 
>>> URIs and of their length. ALso we'll need to escape these in many 
>>> cases, making the URIs uglier. The benefit is adding a major feature 
>>> that many have expressed concerns about.
>>>

---

From: Alex Audu <[email-masked]>
Date: Wed, 12 May 2004 12:21:40 -0500

Regards,
Alex.

---

From: Jari Urpalainen <[email-masked]>
Date: Thu, 13 May 2004 10:00:56 +0300

> built an update document to check.

Right. In principle, when inserting sibling nodes it is far easier if we
add lowest indexes first. However, as Jonathan has put it GET(PUT(x))=x
does not necessary imply that, although this requirement should IMO be
put in the draft.

> keyref.  Is the order of these two in my update important?)

These are good points that have to be addressed. I could also add that
if we allow multiple node inserts, probably also attributes within
multi-inserts should be allowed. This may/could lead to a situation
where the current attribute response format will be changed to a more
well-formed xml-style.

BR,
Jari

---

From: Jari Urpalainen <[email-masked]>
Date: Thu, 13 May 2004 10:00:56 +0300

BR,
Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 May 2004 03:19:30 -0400

Joel asked:

> multiple fetches or multiple insertions in a way that is easy to 
> implement and understandable.  A couple of questions / 
> clarifications:
> 
> 1) The repeating component (that on each side of the "|"), is that 
> any path component, the full URI, or the intra-document selector? 
> With the addition of the URI separator ("//" for now), I would like 
> to suggest that it be everything after the separator.

> paths has to be complete. Different absolute location paths can also 

Which I disagree with. That is, I don't want to allow each selector to
be a full URI. I think it should be like this:

<document-selector>//<node-selector>|<node-selector>|...

So, for example:

http://xcap.example.com/xcap-root/usage/users/joe/doc1//foo/bar[1]|foo/bar[2]

would select the first and second bar element in doc1.

  The only other
> alternative would be that it always be just the last element, and 
> with the idea that this is a preprocessing step, there is no need for
>  that restriction.
> 
> 2) Presumably, the positions of all elements should be evaluated 
> before any one is added?  If I have a list with 3 elements, and I 
> want to add one between the first and second, and one between the 
> second and third, (each with a unique attribute) what positions do I 
> send?  [2][att="new1"] and [3][att="new2"]?

No, as Jari poitned out, its essential that each URI component describe
its position in the *final* document after all insertions (this is
needed for GET(PUT(x))=x). As such, it would be [2][att="new1"] and
[4][att="new2"].

> What order will I get if I do [1][att="new3"} and [1][att="new4"] in
> the same PUT request?

I think this would be an error condition.

> 
> 3) What happens if the two paths (on a PUT) nest?  Is it defined that
>  they be applied in order?  I realize that this case is somewhat
> silly for the client to generate, but we ought to decide what should 
> happen.  I suppose we can say "indeterminate" but we should say.

This is a good point, we do need to say something. I'd like to try to
start with an insertion algorithm, and work backwards and see what it
would produce. Here is my suggestion for PUT behavior:

1. break the URI into a sequence of N selectors, each one selecting a
specific element

2. if there isn't N elements in the body, reject the request

3. apply the N selectors to the document

4. if the number of elements selected is not 0 or N, reject the request

5. if step 3 yielded N elements, this is a replacement. For each element
selected, replace it with the element content from the body
corresponding to the URI component used in the selection. Verify that,
for each of the N selectors, the content just inserted is selected by
it. If not, reject the request. if so, done.

6. we are now dealing with the case where step 3 yielded zero elements.
Firstly, take the N selector/element content pairs, and reorder them.
The reordering is done thusly. The ordering is by path-length of the
selector. If two selectors have the same path length, and have different
paths, the ordering is irrelevant between them. If they have the same
path length and the paths are the same, then they differ by predicate.
If the predicate includes a positional selector, order them based on the
position, with lowest first. If they have the same positional selector,
its an error. If there is no positional selector, ordering between them
is irrelevant.

7. OK, now, execute an insertion of each of the selector/element pairs
IN ORDER, each one done independently. For each, treat it as if that
selector/element was received in a PUT by itself. For each, if, when you
evaluate the URI/selector, it points to an element that exists in the
document, its an error - reject the request.

I believe that this algorithm achieves the desired effect, which is that
after doing the insertion, each selector will point to the element just
inserted. We need this property.

It also defines behavior in the nested case - it works fine. Lets say I
have this document:

<foo>
   <bar/>
<foo>

and I do:

PUT http://server/doc//foo/bar/baz|foo/bar/baz/wow
<baz>
  <first-wow/>
</baz
<wow>This gets added</wow>

Then the resutling document will be:

<foo>
  <bar>
    <baz>
     <first-wow/>
     <wow>This gets added</wow>
    </baz>
  </bar>
</foo>

commenting on some of what Jari said:

Jari Urpalainen wrote:

>> This means that the logic sequence under discussion would be 1) 
>> Take apart the request URI into its alternative pieces 2) Extract 
>> the corresponding sequence of top level XML elements from the 
>> request body.  Associate each extracted element with the 
>> corresponding URI alternative. 3) Process each pair in sequence. 
>> That is, repeatedly 3a) find the location identified by the current
>>  alternative compoent from the request URI 3b) apply the 
>> corresponding top level element to that alternative
>> 
>> The point being that the implementation must not attempt to resolve
>>  the second location specification until it has processed the first
>>  request and built an update document to check.
>> 
> 
> 
> Right. In principle, when inserting sibling nodes it is far easier if
>  we add lowest indexes first.

Not just easier. Necessary. If you don't, you won't preserve the
property that GET(PUT(x))=x.

> However, as Jonathan has put it GET(PUT(x))=x does not necessary
> imply that, although this requirement should IMO be put in the draft.
> 

I believe that, if you want to do an algorithm that incrementally
inserts, you must do the ordering with lowest indexes first or you won't
preseve this property.

Joel asked:
> This whole topic also raises an atomicity issue that we have not had
> to deal with until now.  If I can send multiple updates in a request,
> what happens if one of them is in error?    Are all changes rolled
> back if any are in error?  Are changes up to the successful point
> accepted?  And when is document / schema validity to be checked?  (If
> I have multiple updates in the same request, I could have one part
> adding an item with a "key", and another part adding a reference to
> that "key", using schema key and keyref.  Is the order of these two
> in my update important?)

To answer each question in turn:

(1) it succeeds or fails in its entirety, so that if it fails partway 
in, you need to rollback to the point before you did anything.

(2) validity is checked only when you are done

I dont think anything else makes a lot of sense.

and Jari added:

> 
> 
> These are good points that have to be addressed. I could also add 
> that if we allow multiple node inserts, probably also attributes 
> within multi-inserts should be allowed. This may/could lead to a 
> situation where the current attribute response format will be changed
>  to a more well-formed xml-style.

Well, I'd like to keep it simple here. I definitely don't want mixed 
element/attribute inserts. It should either be all elements or all 
attributes. I would go so far as to say that we can stick with just 
multi-element inserts; thats the real driving need here. If we want 
multi-attribute inserts, we can address that later in an extension.

If you don't ever support mixed element/attribute insertions, than you 
would never need a response format thats in xml. You'd just need the 
attribute format to support multiple lines. If you want mixed insertions 
down the road, you would probably want to change the current format to 
XML as Jari suggests, to facilitate that downstream. If you didnt make 
that change now, then later on, you'd have completely different document 
formats returned if you get one attribute as opposed to many, which is ugly.

I'm on the fence here, since I really want to keep it simple...

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 May 2004 03:19:30 -0400

So, for example:

  The only other

<foo>
   <bar/>
<foo>

and I do:

<foo>
  <bar>
    <baz>
     <first-wow/>

-Jonathan R.

---

From: Jari Urpalainen <[email-masked]>
Date: Mon, 17 May 2004 10:50:27 +0300

> would select the first and second bar element in doc1.

Sorry, looks like I was unclear when expressing this. Of course, I was
proposing just this. When I spoke about location paths I meant different
XPATH location paths and the document part remains the same.

> I'm on the fence here, since I really want to keep it simple...

OK, that's fine with me, just had to raise the question as it was so
obvious.

BR,
Jari

---

From: Jari Urpalainen <[email-masked]>
Date: Mon, 17 May 2004 10:50:27 +0300

BR,
Jari

---

From: Avshalom Houri <[email-masked]>
Date: Wed, 19 May 2004 19:42:10 +0300

How we make sure that XCAP will not get a very complex protocol with the 
addition of more and more features like this one?
It might be a good suggestion to enable protocol levels where the server 
and the client negotiate a level and then operate within
the features available within this level.
The basic level will enable only the basic operations that are important 
for most usages higher levels can implement more sophisticated operations.

Avshalom

Jari Urpalainen <[email-masked]> 
Sent by: [email-masked]
17/05/2004 10:50 AM

To
ext Jonathan Rosenberg <[email-masked]>
cc
"ext Joel M. Halpern" <[email-masked]>, Simple WG <[email-masked]>
Subject
Re: [Simple] XCAP issue 5: selecting multiple elements

BR,
Jari

---

From: Avshalom Houri <[email-masked]>
Date: Wed, 19 May 2004 19:42:10 +0300

Avshalom

To

BR,
Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 May 2004 11:15:04 -0400

Folks,

Joel sent me a note pointing out a problem in nesting:

> It is actually possible (but presumably accidental) for there to be nesting in a replacement case.
> Given a starting document fragment
> <a id="1">
>    <b id="2">
>        <c id="3"> V </c>
>    </b>
>    <b id="4">
>         <c id="5"> X </c>
>    </b>
> </a>
> 
> And given a put expression that days doc//a[@id="1"] | a[@id="1"]/b[@id="2"]
> And as the content
> <a id="1">
>    <b id="2">
>        <c id="3"> Y </c>
>    </b>
>    <b id="4">
>         <c id="5"> Z </c>
>    </b>
> </a>
> <b id="2">
>    <c id="3"> W </c>
> </b>
> 
> We need to define the order of application, and note that there is no order such 
 > that a get will produce the same thing as the put.  I am not sure 
what you think
 > should happen in this case, from your text.

This is a good point.

My conclusion was that there was never really a point in doing a PUT 
that was nested; you would only repeat data twice. As such, my 
preference would be to just not allow this.

The implication is, that when the server got the PUT, it would have to 
verify that none of the URI components were children of any of the 
others. This undoubtedly adds to the complexity of the server side 
processing.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 May 2004 11:15:04 -0400

Folks,

what you think

This is a good point.

-Jonathan R.