Subject: Re: [Simple] xcap and xpath

From: Cullen Jennings <[email-masked]>
Date: Sat, 09 Aug 2003 12:34:22 -0700

This sounds reasonable but I'm not fully seeing why you need it yet.

Say the url foo/buddy/a returned 1 and foo/buddy/b returned 2. If I do a get
of foo/buddy the server can return anything it wants including a document
that contains a composite of 1 and 2 plus some other information that wraps
it.

If I do a post of foo/buddy/c and c exists it modifies the data. If c does
not exist, it creates c, if the posted data is empty, it deletes c. Since
this changes the document would return if foo/buddy was request, anyone
subscribed to foo/buddy will get notified when this is done.

I'm sure I wrong on this and it has all been considered before but I have
forgotten what the issues are.

Thanks, Cullen

On 7/21/03 14:19, "Jonathan Rosenberg" <[email-masked]> wrote:

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

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

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 09 Aug 2003 12:34:22 -0700

Thanks, Cullen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Aug 2003 23:43:12 -0400

> This sounds reasonable but I'm not fully seeing why you need it yet.

Sorry - by "this" you mean my proposal on the xpath subset?

> that contains a composite of 1 and 2 plus some other information that wraps

No, the server would return the XML element addressed by foo/buddy. 
This would obviously contain elements a and b, but possibly others too.

> subscribed to foo/buddy will get notified when this is done.

Correct. That is my proposal on how to support both insert and modify.

> forgotten what the issues are.

THe issue I am talking about below is that xpath has reams of other 
stuff in it - regular expressions, for example, and the ability to 
select multiple elements across a tree, none of which we need. So, the 
idea was to specify a mini xpath as part of xcap.

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 11 Aug 2003 23:43:12 -0400

-Jonathan R.

---

From: [email-masked]
Date: Tue, 12 Aug 2003 09:42:21 -0700

>Correct. That is my proposal on how to support both insert and modify.

Just as a clarification, do you mean POST or PUT?  PUT can obviously
be used for create and modify; it is less clear that PUTting an empty
document does exactly what you want.  Note, however, that DELETE
is a valid method in HTTP 1.x, and the combination of PUT (to create
or modify) and DELETE (to, well, delete) probably covers the ground.
			regards,
				Ted Hardie

---

From: [email-masked]
Date: Tue, 12 Aug 2003 09:42:21 -0700

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Aug 2003 13:01:02 -0400

inline.

[email-masked] wrote:

> Just as a clarification, do you mean POST or PUT?

PUT. The plan is to not make use of POST at all.

>  PUT can obviously
> document does exactly what you want.

My original intent, and the way the current xcap doc is written, is 
with DELETE in fact. I hadnt considered PUT of an empty doc, but after 
Cullen mention it, it seemed reasonable to me. The desire is that it 
should work as it does for any other kind of resource. So, the real 
question is - what IS the HTTP semantic for PUT of an empty document? 
Does the spec say?

>  Note, however, that DELETE

Right. Per above that was the original intent, though we should say 
something about PUT of empty documents I suspect, whether to forbid 
it, or to say its allowed, really only clarifying for us what the http 
intent is.

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Aug 2003 13:01:02 -0400

inline.

Thanks,
Jonathan R.

---

From: [email-masked]
Date: Tue, 12 Aug 2003 10:46:20 -0700

>with DELETE in fact. I hadnt considered PUT of an empty doc, but 
>after Cullen mention it, it seemed reasonable to me. The desire is 
>that it should work as it does for any other kind of resource. So, 
>the real question is - what IS the HTTP semantic for PUT of an empty 
>document? Does the spec say?

My reading is that an empty document is updated content and creates a modified
version under the rules set out in Section 9.6.  Here's the text:

>   The PUT method requests that the enclosed entity be stored under the
>    supplied Request-URI. If the Request-URI refers to an already
>    existing resource, the enclosed entity SHOULD be considered as a
>    modified version of the one residing on the origin server. If the
>    Request-URI does not point to an existing resource, and that URI is
>    capable of being defined as a new resource by the requesting user
>    agent, the origin server can create the resource with that URI. If a
>    new resource is created, the origin server MUST inform the user agent
>    via the 201 (Created) response. If an existing resource is modified,
>    either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
>    to indicate successful completion of the request. If the resource
>    could not be created or modified with the Request-URI, an appropriate
>    error response SHOULD be given that reflects the nature of the
>    problem. The recipient of the entity MUST NOT ignore any Content-*
>    (e.g. Content-Range) headers that it does not understand or implement
>    and MUST return a 501 (Not Implemented) response in such cases.

Note that the "No Content" response does not mean that the resource
has been specified to contain no content, it means that the server
does not need to return an entity-body, but MAY return updated
metainformation (a new e-tag, for example).

>    If the request passes through a cache and the Request-URI identifies
>    one or more currently cached entities, those entries SHOULD be
>    treated as stale. Responses to this method are not cacheable.
>
>    The fundamental difference between the POST and PUT requests is
>    reflected in the different meaning of the Request-URI. The URI in a
>    POST request identifies the resource that will handle the enclosed
>    entity. That resource might be a data-accepting process, a gateway to
>    some other protocol, or a separate entity that accepts annotations.
>    In contrast, the URI in a PUT request identifies the entity enclosed
>    with the request -- the user agent knows what URI is intended and the
>    server MUST NOT attempt to apply the request to some other resource.
>    If the server desires that the request be applied to a different URI,
>    it MUST send a 301 (Moved Permanently) response; the user agent MAY
>    then make its own decision regarding whether or not to redirect the
>    request.
>
>    A single resource MAY be identified by many different URIs. For
>    example, an article might have a URI for identifying "the current
>    version" which is separate from the URI identifying each particular
>    version. In this case, a PUT request on a general URI might result in
>    several other URIs being defined by the origin server.
>
>    HTTP/1.1 does not define how a PUT method affects the state of an
>    origin server.
>
>    PUT requests MUST obey the message transmission requirements set out
>    in section 8.2.
>
>    Unless otherwise specified for a particular entity-header, the
>    entity-headers in the PUT request SHOULD be applied to the resource
>    created or modified by the PUT.

>it, or to say its allowed, really only clarifying for us what the 
>http intent is.

If you want the resource to continue to exist but to have zero-length content,
updating it with a PUT of an empty resource would be the right 
choice; if you want
the resource to cease to exist, using DELETE would be the right choice.

			regards,
				Ted Hardie

---

From: [email-masked]
Date: Tue, 12 Aug 2003 10:46:20 -0700

regards,
				Ted Hardie

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 12 Aug 2003 11:11:02 -0700

At the bottom ...

> it, or to say its allowed, really only clarifying for us what the http

I did not have any reason for preferring the empty document vs. DELETE. I
think either would work for me.

Cullen

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 12 Aug 2003 11:11:02 -0700

At the bottom ...

Cullen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Aug 2003 14:38:10 -0400

[email-masked] wrote:

> updating it with a PUT of an empty resource would be the right choice; 
> if you want

OK. DELETE is definitely what we want. I'll be sure to clarify that.

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Aug 2003 14:38:10 -0400

Thanks,
Jonathan R.