Cart
[Home] [By Thread] [By Date] [Recent Entries]
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
