Subject: RE: [Simple] Update to xcap package

From: [email-masked]
Date: Wed, 25 Feb 2004 17:19:40 +0200

Jonathan,

Apparently (according to Jari), the current solution in xcap supports this:

we have:

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

and I do an xcap addition operation:

PUT http://document/foo/bar[3]

<bar>c</bar>

We end up with (c replaces a):

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

This helps. There is the limitation that you can only add an element at the end, otherwise it is a replace. I'm ok with that.

One comment inline...

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 25.February.2004 06:53
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] Update to xcap package
> 
> 
> 
> 
> 
> [email-masked] wrote:
> 
> > 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>
> 
> No; the above request would fail since the URI identifies multiple 
> existing elements. It needs to identify one.
> 
> > 
> > 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.
> 
> 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.
> 
> > 
> > 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.
> 
> 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

1 and 2 at least, not sure about 3 and 4.

/Hisham

> 
> 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.
> 
> -- 
> 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: Wed, 25 Feb 2004 11:27:59 -0500

[email-masked] wrote:

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

Correct. c does not replace a; c is added at the end as you have shown.
XCAP currently allows selection by element name, element position, or
element filtered by value of an attribute.

> 
> This helps. There is the limitation that you can only add an element
> at the end, otherwise it is a replace. I'm ok with that.

OK, good. I think its also worth noting in xcap that this is a useful 
case for doing basic insertion operations. I also make sure to note the 
importance of designing the schema in a way that makes it efficient with 
xcap.

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

Can you provide some motivating cases for 1 and 2? Is there something in 
CPCP?

Thanks,
Jonathan R.

---

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

Thanks,
Jonathan R.