Subject: RE: [Simple] xcap and xpath

From: [email-masked]
Date: Tue, 5 Aug 2003 10:06:58 -0400

Hi Jonathan,

So you would define an XPath-like syntax, but wouldn't make the use of XPath mandatory?
Is it realistic (when it comes to deployments) to avoid XPath now but introduce its usage
in the future? 

I agree with Hisham that I don't see the problem relying on a limited set of XPath as long
as it is carved out properly in the document. With this, we restrict the options to realize
the desired functionality and most likely avoid problems in implementations?!

Dirk

>-----Original Message-----
>From: ext [email-masked] 
>[mailto:[email-masked]]
>Sent: Tuesday, August 05, 2003 9:48 AM
>To: [email-masked]; [email-masked]
>Subject: RE: [Simple] xcap and xpath
>
>
>Why not just use XPath? You can define the limited usage of 
>xpath in your document (as you have written it below) and 
>developers who don't have the time nor resources to implement 
>a full blown xpath API can implement the parts of xpath used 
>in the document. Others who already have an XPath 
>implementation can use that.
>
>/Hisham
>
>> -----Original Message-----
>> From: ext Jonathan Rosenberg [mailto:[email-masked]]
>> Sent: Tuesday, July 22, 2003 12:20 AM
>> To: Simple WG
>> Subject: [Simple] xcap and xpath
>> 
>> 
>> Folks,
>> 
>> During the meeting, Ted had suggested a potential simplification in 
>> xcap. Namely, don't use xpath at all. If we know ahead of times the 
>> specific "break points" in the schema where we know we will 
>do atomic 
>> operations (I.e., buddies), just define each buddy as a 
>resource, and 
>> define the buddy list as a separate resource, and specify 
>the objects 
>> returned by querying those specific types.
>> 
>> I thought about this a bit. The problem I ran into is that 
>> one devices 
>> atomic unit is not the same as anothers.
>> 
>> Consider a PC application which just wants to pull its entire buddy 
>> list in one pass. If information for each buddy is a separate 
>> resource, it has to issue N separate HTTP GETs, one for each 
>of the N 
>> buddies on the list. Worse yet, it would need to first fetch the 
>> "buddy list" resource, which presumably has references to the 
>> resources for each buddy.
>> 
>> Its more problematic when you want to update something. Lets say you 
>> want to add a buddy. A wireless client would need to PUT the XML 
>> document for this new buddy, and then modify the "buddy list" 
>> document 
>> to add a reference to the new buddy XML document. Thats two 
>> transactions, and one of them requires a GET/modify/PUT of a large 
>> document.
>> 
>> An optimization is to define a resource that actually returns 
>> the full 
>> buddy list with all of its buddies. If you think about it, this is 
>> exactly the optimiziation that xpath affords us.
>> 
>> So, I concluded that we want something like xpath, for buddy 
>> lists and 
>> for other usages we are likely to find.
>> 
>> However, xpath is quite a big spec, and way more than we 
>> need. What we 
>> really need is a way to identify a single XML element. We need to be 
>> able to identify it by its path from the root, where each branch is 
>> defined by element name or by the value of one of its 
>> attributes. That 
>> is a very, very small subset of xpath.
>> 
>> My recommendation, therefore, is to add a section to the spec 
>> which is 
>> a standalone definition of a string that can point to a single XML 
>> element, using the "/" notation of xpath, and using the 
>> "[@name=value]" mechanism in xpath for selecting an element by 
>> attribute name. This section would use Xpath as an informative 
>> reference only. The expressions defined by this section would be 
>> compliant xpath expressions, but we would not be using xpath. That 
>> would leave the door open in the future for full xpath support if we 
>> decide its needed.
>> 
>> What do people think of this simplification?
>> 
>> -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
>

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Aug 2003 19:59:50 -0400

The problem is "properly carving out". I had tried this kind of thing 
in the past, with caller prefs, and previously in this work with acap. 
Its really easy to use another spec wholesale. Once you try to subset 
it, the challenge is doing that so that there is a very, very clear 
definition about what the subset is. As an example, subsettting a 
grammar is really hard. If we don't use all of xpath, how do we 
specify the subset of the grammar to be supported?

Xpath in particular is full of things we don't need or want, I think - 
regular expressions, for example. What I am proposing is that the way 
to subset is to to explicitly specify what we want, rather than to 
start with xpath and take away until we get to what we want.

More inline.

> Is it realistic (when it comes to deployments) to avoid XPath now but introduce its usage

I'm not sure we would find its needed. More likely people would just 
use xpath libraries on the server side, even though most of it would 
never get exercised.

> the desired functionality and most likely avoid problems in implementations?!

The devil is in the details here. How would you define the subset 
grammar? How would you restrict the set of functions that are 
available? Xpath defines a fairly comprehensive model for an xml 
document, including nodes for things like namespaces and comments, 
which we dont need. How would you subset the document model they have 
proposed? I have no idea.

If you don't do a good job at defining the subset, you end up with 
interop problems between people who concluded on a different subset. 
Worse, people just assume that servers will use an xpath library 
anyway, so they write clients which go beyond the subset, and it works 
anyway. Very dangerous.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Aug 2003 19:59:50 -0400

More inline.

-Jonathan R.