Subject: [Simple] XCAP issue 5: selecting multiple elements

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 May 2004 02:12:25 -0400

This is probably the second most significant open issue in xcap (second 
to PUT vs. POST).

Currently, XCAP has a major limitation that each URI can select only a 
single XML element or attribute at a time. So, if you want to delete 
more than one element, you need multiple DELETE operations. If you want 
to add more than one new element, you need to either do multiple PUTs, 
or do one PUT, but include in that put all of the existing siblings for 
the new elements.

The concern has been raised that this limitation is simply too 
prohibitive for a protocol whose purpose in life is to muck with lists 
of things.

So, I had, during the meeting, proposed a technique for doing this. The 
idea is that we would take on a few more of the features of Xpath, and 
allow boolean OR expressions inside of a predicate. The grammar for this 
(thanks to Jari for correcting me on it) would look like this:

PUT http://server.com/xcap-root/document/foo/bar[position()=4 or 
position()=5]

<bar id="first new one"/>
<bar id="second new one"/>

This selects the 4th and 5th bar elements, and replaces them with the 
two in the body of the request.

This change introduces some complexity, though its almost entirely in 
the selection operations. The rest of the protocol remains as it was. 
There is also some increased complexity in the grammar of the URIs and 
of their length. ALso we'll need to escape these in many cases, making 
the URIs uglier. The benefit is adding a major feature that many have 
expressed concerns about.

So, I'm somewhat on the fence, though leaning towards adding this 
functionality to the spec. Jari has indicated that he successfully 
implemented it, which is a good sign.

Thoughts?

-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: [email-masked]
Date: Mon, 10 May 2004 15:09:50 +0300

In my opinion, this is very useful and needed and should be introduced.

Thanks,
Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 10.May.2004 09:12
> To: Simple WG
> Subject: [Simple] XCAP issue 5: selecting multiple elements
> 
>

---

From: [email-masked]
Date: Mon, 10 May 2004 15:09:50 +0300

Thanks,
Hisham

---

From: [email-masked]
Date: Fri, 21 May 2004 09:39:46 +0300

> Sent: 20.May.2004 18:15
> To: Urpalainen Jari (Nokia-NRC/Helsinki)
> Cc: ext Joel M. Halpern; Simple WG
> Subject: Re: [Simple] XCAP issue 5: selecting multiple elements
> 
> 
> Folks,
> 
> Joel sent me a note pointing out a problem in nesting:
> 
> > It is actually possible (but presumably accidental) for 
> there to be nesting in a replacement case.
> > Given a starting document fragment
> > <a id="1">
> >    <b id="2">
> >        <c id="3"> V </c>
> >    </b>
> >    <b id="4">
> >         <c id="5"> X </c>
> >    </b>
> > </a>
> > 
> > And given a put expression that days doc//a[@id="1"] | 
> a[@id="1"]/b[@id="2"]
> > And as the content
> > <a id="1">
> >    <b id="2">
> >        <c id="3"> Y </c>
> >    </b>
> >    <b id="4">
> >         <c id="5"> Z </c>
> >    </b>
> > </a>
> > <b id="2">
> >    <c id="3"> W </c>
> > </b>
> > 
> > We need to define the order of application, and note that 
> there is no order such 
>  > that a get will produce the same thing as the put.  I am not sure 
> what you think
>  > should happen in this case, from your text.
> 
> This is a good point.
> 
> My conclusion was that there was never really a point in doing a PUT 
> that was nested; you would only repeat data twice. As such, my 
> preference would be to just not allow this.

I don't see why someone would do that and therefore don't see any reason to explicitly disallow it. A warning or a note will suffice, IMO.

/Hisham

> 
> The implication is, that when the server got the PUT, it 
> would have to 
> verify that none of the URI components were children of any of the 
> others. This undoubtedly adds to the complexity of the server side 
> processing.
> 
> 
> -Jonathan R.
> --