Subject: RE: [Simple] XCAP Issue 2 Interim Summary: Positional Insertions

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 21 Jun 2004 10:44:07 +0100

My view at the moment is "keep it simple" and not do positional insertions in XCAP.

If there is a need for an enhanced capability, then there would appear to be other ways of modifying XML documents that could be brought into play outside the use of XCAP, and I suspect that at the most, IETF SIMPLE should just allow these other mechanisms to be used.

That keeps XCAP at a low level where the majority of user applications will work perfectly well, and leaves the high level stuff to the 1% that can use something else to do the more sophisticated things.

Additionally, to do some of these high level things, I am not sure I would start from XCAP in the first place.

regards

Keith

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 17 June 2004 13:07
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Simple] XCAP Issue 2 Interim Summary: Positional
> Insertions
> 
> 
> 
> 
> [email-masked] wrote:
> 
> > Jonathan,
> > 
> > Thanks for the analysis.
> > 
> > Reading your analysis actually brings me to the opposite conclusion
> > to the one you made. That is, we need positional insertions.  There
> > are so many rules, restriction, and guide lines that need to be
> > educated to current and future designers of XCAP friendly schemas.
> > Wouldn't it be a much better investment if we allow positional
> > insertions now and avoid schema misdesign?
> 
> I don't think any of the guidelines represent a schema mis-design.
> 
> > 
> > You haven't explicitly listed the issues with positional insertions,
> > but instead you listed the problems that it solves. Can you please
> > educate the rest of us what the real problems are with positional
> > insertions?
> 
> It was just complexity. Positional insertions would require us to 
> support multiple predicates (i.e., more than one [] rule). We could 
> restrict it to just two in our case, and indeed, restrict the first 
> predicate to be a positional selector only. I think that 
> might help the 
> complexity a bit. However, there is definitely more logic and code 
> required to support it than not. How much exactly? Depends on the 
> implementation. I'll send a separate note in the next day or 
> so with a 
> pseudo-code view of what a minimal implementation would be, 
> so folks can 
> get a sense of it.
> 
> The meta-issue was that the whole idea with xcap is that what we are 
> generally doing is reading and writing a document from a 
> server (like a 
> buddy list), but sometimes, you need to read or write a piece 
> of it as 
> an optimization, so we have the notion of sub-document 
> addressing. When 
> you view the design goal as reading and writing of entire 
> documents with 
> sub-document operations as a performance optimization, things like 
> positional inserts teeter on the boundary between this view, and the 
> view of xcap as an XML database protocol. I think that, if we are 
> defining an XML database protocol, we would probably start from a 
> different approach, along the lines of XUpdate.
> 
> I must say that, on the issue of positional inserts, I am on 
> the fence. 
> I do see the "keep it barebones simple" argument, especially as it 
> relates to the view of xcap as an optimization around reading and 
> writing of documents. On the other hand, from a code perspective, I 
> don't think positional inserts is actually that complicated, and it 
> does, as Hisham pointed out, remove a lot of "schema design 
> guidelines" 
> that I would otherwise need to introduce to deal with it.
> 
> Comments from others? Even a "do positional inserts" or "dont do it" 
> response is helpful.
> 
> Thanks,
> 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
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 29 Jun 2004 17:10:10 -0400

Of the folks participating in the list discussion, there was nearly an 
even split between those who wanted the feature, and those who don't. 
I'm personally on the fence.

Objectively weighing the arguments that were made, when you get down to 
the details, the complexity of this particular feature is actually small 
(I sent pseudocode to demonstrate that). It buys us useful functions. It 
would actually make the spec smaller, since I could exclude a lot of 
text on schema design guidelines which would otherwise need to be there.
So, the conclusion would seem to lean towards including it.

I'd really, really like to close on this issue, so we can finish this 
specification, as its long overdue.

So, is there anyone who simply cannot deal with the inclusion of this 
feature in the spec?

Thanks,
Jonathan R.

Drage, Keith (Keith) wrote:

> If there is a need for an enhanced capability, then there would
> appear to be other ways of modifying XML documents that could be
> brought into play outside the use of XCAP, and I suspect that at the
> most, IETF SIMPLE should just allow these other mechanisms to be
> used.
> 
> That keeps XCAP at a low level where the majority of user
> applications will work perfectly well, and leaves the high level
> stuff to the 1% that can use something else to do the more
> sophisticated things.
> 
> Additionally, to do some of these high level things, I am not sure I
> would start from XCAP in the first place.
> 
> regards
> 
> Keith
> 
> 
>> -----Original Message----- From: Jonathan Rosenberg
>> [mailto:[email-masked]] Sent: 17 June 2004 13:07 To:
>> [email-masked] Cc: [email-masked] Subject: Re:
>> [Simple] XCAP Issue 2 Interim Summary: Positional Insertions
>> 
>> 
>> 
>> 
>>> Reading your analysis actually brings me to the opposite
>>> conclusion to the one you made. That is, we need positional
>>> insertions.  There are so many rules, restriction, and guide
>>> lines that need to be educated to current and future designers of
>>> XCAP friendly schemas. Wouldn't it be a much better investment if
>>> we allow positional insertions now and avoid schema misdesign?
>> 
>>> You haven't explicitly listed the issues with positional
>>> insertions, but instead you listed the problems that it solves.
>>> Can you please educate the rest of us what the real problems are
>>> with positional insertions?
>> 
>>  restrict it to just two in our case, and indeed, restrict the
>> first predicate to be a positional selector only. I think that 
>> might help the complexity a bit. However, there is definitely more
>> logic and code required to support it than not. How much exactly?
>> Depends on the implementation. I'll send a separate note in the
>> next day or so with a pseudo-code view of what a minimal
>> implementation would be, so folks can get a sense of it.
>> 
>> The meta-issue was that the whole idea with xcap is that what we
>> are generally doing is reading and writing a document from a server
>> (like a buddy list), but sometimes, you need to read or write a
>> piece of it as an optimization, so we have the notion of
>> sub-document addressing. When you view the design goal as reading
>> and writing of entire documents with sub-document operations as a
>> performance optimization, things like positional inserts teeter on
>> the boundary between this view, and the view of xcap as an XML
>> database protocol. I think that, if we are defining an XML database
>> protocol, we would probably start from a different approach, along
>> the lines of XUpdate.
>> 
>> I must say that, on the issue of positional inserts, I am on the
>> fence. I do see the "keep it barebones simple" argument, especially
>> as it relates to the view of xcap as an optimization around reading
>> and writing of documents. On the other hand, from a code
>> perspective, I don't think positional inserts is actually that
>> complicated, and it does, as Hisham pointed out, remove a lot of
>> "schema design guidelines" that I would otherwise need to introduce
>> to deal with it.
>> 
>> Comments from others? Even a "do positional inserts" or "dont do
>> it" response is helpful.
>> 
>> Thanks, 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
>> 
> 
>