Subject: RE: [Simple] Update to xcap package

From: [email-masked]
Date: Tue, 24 Feb 2004 14:11:21 +0200

Something else occured to me. Modifying your example not to include id attribute, we have:

<foo>
   <bar>a</bar>
   <bar>b</bar>
</foo>

and I do an xcap addition operation:

PUT http://document/foo/bar

<bar>c</bar>

We end up with (c replaces a):

<foo>
   <bar>c</bar>
   <bar>b</bar>
</foo>

The desire was to add a 3rd <bar> element, but instead the first one was replaced. Oops.

Now I do a GET:

GET http://document/foo/bar

What does that return? <bar>c</bar>, <bar>b</bar> or both? It is not guaranteed to return what you put using PUT.

At the moment, the only way to add c is to replace the whole of <foo>. Is this good enough and acceptable? Of course we can give ids to every <bar>, but that's too much, IMO.

The other thing we can do is something like:

PUT http://document/foo/bar="c"

<bar>c</bar>

But there's no point in having a PUT content in this case, and it doesn't work if bar has sub-elements.

/Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 22.February.2004 10:23
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] Update to xcap package
> 
> 
> 
> inline.
> 
> [email-masked] wrote:
> 
> > 
> >> -----Original Message----- From: ext Jonathan Rosenberg
> >> [mailto:[email-masked]] Sent: 19.February.2004 06:48 To:
> >> Khartabil Hisham (Nokia-TP-MSW/Helsinki) Cc: [email-masked];
> >> [email-masked] Subject: Re: [Simple] Update to xcap package
> >> 
> >> 
> >> 
> >> 
> >> 
> >> [email-masked] wrote:
> >> 
> >> 
> >>> I had the use case in my mind that if we have a list that is
> >>> shared amongst 100 or even 10000 employees and one modifies it,
> >>> then this will result in 100 NOTIFYs. Each then might generate a
> >>> GET.
> >> 
> >> OK.
> >> 
> >> 
> >>> Also for a conference using XCAP, it might be true that there is
> >>> one creator, but there could be many privileged users who have
> >>> read rights and can subscribe to the changes in the conference
> >>> policy.
> >>> 
> >>> I'm not sure if the cost of sending the changes in a NOTIFY as 
> >>> opposed to just sending the etag is so great.
> >> 
> >> One thing we need to figure out is the format for the NOTIFY. WHats
> >> in the event package at the moment won't work, because there are 
> >> many valid results that can be obtained from applying the xcap
> >> operations to a document.
> > 
> > 
> > I'm sorry, I don't understand what you mean by saying that 
> many valid
> > results can be obtained. Can you elaborate?
> 
> Sorry for being unclear on it.
> 
> Lets say I have a document like this:
> 
> <foo>
>    <bar id="1"/>
>    <bar id="2"/>
> </foo>
> 
> and I do an xcap addition operation:
> 
> PUT http://document/foo/bar[@id="3"]
> 
> <bar id="3"/>
> 
> 
> XCAP requires that the server create this element such that a 
> GET to the 
> same URI returns the same body. However, there are three ways 
> that the 
> server could do such an insertion and still meet that definition:
> 
> <foo>
>    <bar id="3"/>
>    <bar id="1"/>
>    <bar id="2"/>
> </foo>
> 
> OR
> 
> <foo>
>    <bar id="1"/>
>    <bar id="3"/>
>    <bar id="2"/>
> </foo>
> 
> OR
> 
> <foo>
>    <bar id="1"/>
>    <bar id="2"/>
>    <bar id="3"/>
> </foo>
> 
> 
> The current xcap-package includes a hash in the notify, to allow the 
> client to match what they did against what the server has. I believe 
> that, in this hash, ordering of elements and attributes is 
> signficiant. 
> As a result, the hash computed by the server might not match the one 
> computed by the client, since both client and server did the insert 
> separately.
> 
> A different "diff" format can be defined which is more precise about 
> where the server did the insertion. For any element, specifying its 
> parent and previous sibling is sufficient. If we want the 
> hash to remain 
> in the notifications, we'd need to define a format like that.
> 
> Hope this clarifies.
> 
> -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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Feb 2004 23:53:10 -0500

> We end up with (c replaces a):

No; the above request would fail since the URI identifies multiple 
existing elements. It needs to identify one.

> What does that return? <bar>c</bar>, <bar>b</bar> or both? It is not guaranteed to return what you put using PUT.

Neither, because of the above constraint, this would also return an 
error (again - unless we modify xcap to allow multiple elements in get/put).

> At the moment, the only way to add c is to replace the whole of <foo>. Is this good enough and acceptable? Of course we can give ids to every <bar>, but that's too much, IMO.

You need a way to uniquely identify it. Its no different than adding a 
file to a directory - it has to be unique amongst other files.

> But there's no point in having a PUT content in this case, and it doesn't work if bar has sub-elements.

Something like this would work, yes. The proper syntax you are looking 
for is http://example.com/document/foo/bar[text()="c"]. Yes, its 
redundant, but if you want to use text content to uniquely identify 
elements, then thats what you would have to do.

If an element has sub-elements, you can also select based on the 
sub-elements. For example, if your doc is:

<?xml version="1.0" encoding="UTF-8"?>
  <foo>
    <bar id="1"><foo2></foo2></bar>
    <bar id="2"><foo1></foo1></bar>
  </foo>

then this would get the second bar:

GET http://example.com/document/foo/bar[foo1]

So, the question is - what kind of information do we want to allow xcap 
to use to uniquely identify an element for deletion, insertion or 
creation? Right now, the spec focuses on element names and attributes. 
One would need to design one's schema to make sure that these existed as 
unique identifiers. It is easy to add any of the following:

1. text content
2. names of child elements
3. boolean operators (i.e., a child exists)
4. existence of attributes

Its just a complexity/flexibility trade off. I would be willing to 
expand the scope of xcap a bit here; I suspect names of child elements 
and text content might also be useful. If we start adding more and more, 
we may as well go back to full xpath support and just reference the spec.

And again, I view that as different from the scope of the notification 
format, where we may want to use more functionality in order to 
guarantee that we have a way to specify a unique insertion point.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Feb 2004 23:53:10 -0500

1. text content

-Jonathan R.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Feb 2004 08:19:51 -0500

Thinking both about the "SIMPLE" case, and about other things that might 
use XCAP, I think this is a mistake.  XCAP is not about modifying arbitrary 
documents.  It is about modifying documents that have been designed to be 
used in conjunction with XCAP.  As such, it seems to me perfectly 
reasonable to say that all repeated elements of all such documents must 
have uniquely identifying attributes.  In fact, such attributes are a good 
idea anyway.  (Otherwise, one amplifies the confusion associated with 
replacing keying material, for example.)

Yours,
Joel M. Halpern

At 11:53 PM 2/24/2004 -0500, Jonathan Rosenberg wrote:
>So, the question is - what kind of information do we want to allow xcap to 
>use to uniquely identify an element for deletion, insertion or creation? 
>Right now, the spec focuses on element names and attributes. One would 
>need to design one's schema to make sure that these existed as unique 
>identifiers. It is easy to add any of the following:
>
>1. text content
>Its just a complexity/flexibility trade off. I would be willing to expand 
>the scope of xcap a bit here; I suspect names of child elements and text 
>content might also be useful. If we start adding more and more, we may as 
>well go back to full xpath support and just reference the spec.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Feb 2004 08:19:51 -0500

Yours,
Joel M. Halpern

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Feb 2004 11:14:25 -0500

Joel,

You are mostly right. However, we already have a spec in place which 
proposes XCAP modification of a document not originally designed for xcap:

http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap-pidf-manipulation-usage-00.txt

this one modifies PIDF.

In this case, I still think we're OK; tuples already have unique ID 
elements, and within a tuple you usually won't see repeats of the same 
element, I dont think.

That said, I don't think adding a bit more expressive selection 
capabilities HURTS per se.

-Jonathan R.

Joel M. Halpern wrote:

> use XCAP, I think this is a mistake.  XCAP is not about modifying 
> arbitrary documents.  It is about modifying documents that have been 
> designed to be used in conjunction with XCAP.  As such, it seems to me 
> perfectly reasonable to say that all repeated elements of all such 
> documents must have uniquely identifying attributes.  In fact, such 
> attributes are a good idea anyway.  (Otherwise, one amplifies the 
> confusion associated with replacing keying material, for example.)
> 
> Yours,
> Joel M. Halpern
> 
>> So, the question is - what kind of information do we want to allow 
>> xcap to use to uniquely identify an element for deletion, insertion or 
>> One would need to design one's schema to make sure that these existed 
>> as unique identifiers. It is easy to add any of the following:
>>
>> 1. text content
>> and text content might also be useful. If we start adding more and 
>> more, we may as well go back to full xpath support and just reference 
>> the spec.
> 
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Feb 2004 11:14:25 -0500

Joel,

this one modifies PIDF.

-Jonathan R.