Subject: RE: [Simple] Update to xcap package

From: [email-masked]
Date: Thu, 19 Feb 2004 11:06:16 +0200

> -----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?

Thanks,
Hisham

> You need a proper "diff" format, I think. If you 
> want a pure 
> XML diff, XSLT is a choice, though you may not want to 
> process that on a 
> phone. A standard patch file format is another choice. I 
> welcome other 
> ideas.
> 
> -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: Sun, 22 Feb 2004 03:23:03 -0500

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
>> 
>> 
>> 
>> 
>> 
>>> 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.
>>> 
>> 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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 22 Feb 2004 03:23:03 -0500

inline.

<foo>
   <bar id="1"/>
   <bar id="2"/>
</foo>

<bar id="3"/>

<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>

Hope this clarifies.

-Jonathan R.

---

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

> in the notifications, we'd need to define a format like that.
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