Subject: Re: [Simple] Update to xcap package

From: Jari Urpalainen <[email-masked]>
Date: Thu, 26 Feb 2004 10:04:18 +0200

On Sun, 2004-02-22 at 10:23, ext Jonathan Rosenberg wrote:

> 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.
> 
IMO you could simply define in the base spec that when appending
node(sets) or attributes with conditions like this, the insertion will
take place to the end of siblings. This would then behave similarly when
adding by using index-numbers (bar[3]) unless you want to enable "real"
inserts like in XUpdate http://www.xmldb.org/xupdate/. Btw. the
xml-libraries that I am aware of, behave like this anyway.

If ordered inserts are really required (which I doubt, at least
currently there seem to be no AU cases for that) one possibility could
be that you'll give additionally also the index for insertion like

PUT http://document/foo/bar[@id="3"][2]

BR,
Jari

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Feb 2004 17:21:41 -0500

inline.

[email-masked] wrote:

> 
>> -----Original Message----- From: ext Jonathan Rosenberg
>> [mailto:[email-masked]] Sent: 25.February.2004 18:28 To:
>> Khartabil Hisham (Nokia-TP-MSW/Helsinki) Cc: [email-masked];
>> [email-masked] Subject: Re: [Simple] Update to xcap package

>> Can you provide some motivating cases for 1 and 2? Is there 
>> something in CPCP?
> 
> 
> In CPCP, you might need to replace a resource in the ACL, or change
> its access-type from allowed to blocked. The way XCAP is specified
> now, as we discussed, you need to know the exact position for the
> resource you want replace (they don't have unique IDs besides the URI
> they carry). This might be ok, if we always assume that the client
> has an exact copy of what is on the server. I.e. The client MUST
> always know the number of elements present and provide the position
> where to insert the new element as the last element, and therefore
> knows the exact position of the element to replace.

This is really an important assumption to verify or reject.

Things can get a lot easier and more flexible if we can generally assume 
that the client has a copy of the data its modifying, so that it can use 
position to effect insertions and modifications.

If its not possible, then I think we need to insist on unique attributes 
or it just gets really out of hand.

> 
> If that can't be guaranteed then we need 1 and 2 above for CPCP.
> 
> My proposal is:
> 
> a. If there is an attribute that uniquely identifies an element, then
> the client uses that to insert and/or replace. b. If there is no
> attribute that uniquely identifies an element, then the client can
> only insert an element as the last one in a list.

In both cases, I think that insertion should take place at the end of 
the list. This vastly simplifies subsequent position based operations on 
the document.

> 
> It would also be nice if, for a, the client can indicate the position
> it wants to insert, for hashing reasons.

This appears hard to do. I was unable to come up with a specific reason 
it would be needed. What do you mean by hashing?

-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