Re: [Simple] new partial PIDF format proposal

[Aki Niemi <aki.niemi at nokia.com>]

Hi,

Naturally, I'm in favor of this change. It handles the new data model
much better now that there are the <person> and <device> elements as
siblings of <tuple>. I think this new approach also makes the benefits
of partial updates much more apparent than before. For example, changing
a simple thing like status from OPEN to CLOSED takes up much less
bandwidth than before when the entire tuple needed to change as a result
of this update.

The only issue I can come up with would be the NIT problems, if
processing these updates takes a long time for the composer.

Cheers,
Aki

On Mon, 2004-10-11 at 19:48, Jari Urpalainen wrote:
> Hi all !
> 
> While there seems to be a need for a more flexible partial PIDF format (i.e. refering to the new presence data model) and while we have had some discussions with the current authors here is a proposal for a new format. I would like to emphasize that compared to the current partial PUBLISH/NOTIFY semantics mostly the data format will change. The motivation here is that we'll have a flexible model where we would have a very fine-grained but not too complicated updates. Furthermore, the semantics in partial PUBLISH/NOTIFY would be very clear so that the server or client does not have to have any strange composition magic.
> 
> First this interface resembles typical xml database API's, i.e. you can <add>, <replace> and <remove> elements and attributes. Also, some ideas are borrowed from XCAP and especially from the XCAP event package. However, the format is simplified and shorter.
> 
> <add> always appends data, so it never replaces. <add> is being done by giving two attributes and actual content. The parent selector "parent" selects the parent of the added content. This has to select a single element, otherwise it is an error. The "parent" selector is an absolute location path of the document. The second selector "sel" is a relative selector that is used within the found parent node context. 
> An example:
> <add parent="/presence" sel="tuple[ at id="dasa"]"><![CDATA[<tuple id="dasa"...>]]></add>
> 
> Here the content of the "parent" attribute selects <presence> element, after appending also the "sel" has to uniquely identify the newly inserted node. The second selector is there to identify either an attribute or you can request that the newly added element will be inserted at a specified 
> position e.g. 
> <add parent="/presence" sel="tuple[3]"><![CDATA[<tuple id="dasa"...>]]></add>.
>  
> An attribute can be added by e.g.
> <add parent="/presence/tuple[ at id="foo"]/contact" sel="@priority">0.8</add>
>  
> Likewise adding text node content:
> <add parent="/presence/tuple[ at id="dasa"]/status" sel="basic">open</add>
> 
> Then <replace> has only one selector "sel" that uniquely identifies the node:
> <replace sel="/presence/tuple[ at id="dasa"]/status/basic">closed</replace>
>  
> Finally <remove> also has only one attribute "sel":
> <remove sel="/presence/tuple[ at id="dasa"]"/>
>  
> The selector sel="/" or sel="/presence" could be used when sending the whole document content. However, it would be probably more reasonable to send the whole pidf-document instead. 
> 
> <add>, <replace> and <remove> requests can be combined together and they are applied in the given order. "version" number is used as previously to provide integrity index. Presence entity attribute is included in the document. An example:
> 
> <?xml version="1.0" encoding="UTF-8"?>  
> <pidf-partial xmlns="urn:ietf:params:xml:ns:pidf-partial" 
>               version="1" 
>               entity="pres:fellow at example.com">
> <add>....</add>
> <add>....</add>
> <remove .../>
> <replace>...</replace>
> </pidf-partial>
>  
> XPATH-selector bnf could be the same as in XCAP.  QName expansion will be done by using document-context when traversing the xml-tree as otherwise that would increase unnecessarily "pidf-partial" content.
> 
> This change might be quite challenging for the server as it e.g. may have to keep the last published content per subcriber and to calculate appropriate "xml-diffs" when sending notifies. However, it is still up to the server how fine-grained data it is sending. So the server may e.g. send only tuple level changes which is then virtually the same logic as what we'll have currently in the drafts.
>  
> For the client these updates are simple and straigthforward as long as you'll have this sort of very limited XPath-parser (which btw. can be made e.g. with a couple of hundred C-lines). Furthermore, the logic would be similar to what we'll have with XCAP event package.
> 
> Any comments or objections why we wouldn't proceed with this ?
> BR,
> Jari
> 

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple