Re: [xml-dev] RESTful operations on document fragments

["Simon St.Laurent" <simonstl@simonstl.com>]

Jim Ancona wrote:
> Simon St.Laurent wrote:
>> Wow.  I can barely look at the PATCH discussions without thinking 
>> "Wow, what an incredibly nasty hack," but it's definitely something 
>> worth thinking about.
>>
>> Maybe it's just my priorities, but a URI format that lets you identify 
>> parts of resources seems like a safer path to take than adding a new 
>> HTTP method and then having to come up with various formats for doing 
>> the patching.  (Not to mention upgrades to web servers.)
> 
> I agree that there seem to be two possible approaches:
> - Define a new verb (PATCH) and a suitable diff format or formats.
> - Use the verbs we have and identify parts of resources with their own 
> URIs (making them first-class resources).
> 
> Note that I phrased that second one differently than you did, because 
> once you come up with a way to assign a URI to a sub-resource, it become 
> a full-fledged resources. 

Yep - that's fine with me, so long as I can get to the partials.

 > Going back to your Old Testament example,
> there's no reason that you can't define a URI structure that allows more 
> granular updates,
> e.g. http://oldtestament.example.org/book/IISamuel/chapter/11/verse/2
> You could GET or PUT to that URI to update a single verse. The reason 
> people are pushing for PATCH is that they typically want to make many 
> such changes in a single operation. So if you wanted to change every 
> instance of "thou" to "you", sending the entire document would still be 
> quite inefficient, but so would issuing hundreds or thousands of PUTs to 
> individual verse URIs.

You could do the same thing, though, with XPath or XPointer fragment 
identifiers.  They aren't limited to targeting a single piece of a 
document.

> I don't see how fragment identifiers help at all--as you noted, they are 
> only processed client-side whereas the partial update is to take place 
> on the server. Updating web infrastructure to change that assumption 
> would be far harder than the allowing PATCH.

Fragment identifier syntax is designed specifically for pointing at 
parts of documents.  The only problem - which I think is easily solvable 
- is getting that fragment identification information to the server.

>> Maybe the 1997 XLink approach is worth further pursuit.  (And on 
>> reflection, that's probably why I asked the question here - this list 
>> has had related conversations in the past.)
> 
> I'm not familiar with the 1997 XLink approach. Could you elaborate?

I did up-thread, but here it is again, with slightly more material:

----------------------------------
http://www.w3.org/TR/WD-xml-link-970406#sec5.2

*  If the XPointer is provided, the designated resource is a 
"sub-resource" of the containing resource; otherwise the designated 
resource is the containing resource.

* If the connector is "#", this signals an intent that the containing 
resource is to be fetched as a whole from the host that provides it, and 
that the XPointer processing to extract the sub-resource is to be 
performed on the client, that is to say on the same system where the 
linking element is recognized and processed.

* If the connector is "?XML-XPTR=", this signals an intent that the 
entire locator is to be transmitted to the host providing the resource, 
and that the host should perform the XPointer processing to extract the 
sub-resource, and that only the sub-resource should be transmitted to 
the client.

* If the connector is "|", no intent is signaled as to what processing 
model is to be used to go about accessing the designated resource.

----------------------------------------------

My favorite bit, the '|' connector, was dropped because it wasn't 
compatible with the existing URI world.  The query string approach isn't 
necessarily pretty, but I do think it would be functional.

There are still lots of fun questions about how we'd know whether the 
server supports the query string, which fragment identifier syntax is 
appropriate to resources with multiple representations, and how a server 
should express "I don't know what you're talking about", but at least I 
think there's room for experimentation here.

Thanks,
Simon St.Laurent
Retired XML troublemaker
http://simonstl.com/