Addressing Fragments in REST

REST offers a great way to build simple applications that Create, Read,
Update, and Delete resources. But what if you want to get at part of a
resource? A database row is a simple thing, even if it enables immense
complexity. It contains named fields - no more than one to a given name,
usually conforming to a rather predictable schema. There's nothing
floating between the fields, and every row contains the same set of
fields. (They may be empty, of course, but they're clearly defined. An
XML document - or even an XML document fragment - is potentially incredibly
complicated. While many XML documents are regular and relatively simple,
the ones that aren't simply holding data as it moves between databases
are often very complicated. XML elements are kind of like fields, sure,
but [not quite...] Nonetheless, it seems like the basic operations most
people would like to perform on these documents (and other loosely-structured
resources) are the same operations people want to perform on database
records: Create, Read, Update, Delete. CRUD is everywhere, and CRUD is
good. Typically, though, an XML document is treated as a single resource.
A book might assemble itself using entities or XIncludes that pull in
chapters, of course, and those chapters could be individually addressed
as resources, but that has limits. Though it's possible, I don't think
anyone wants to write paragraphs in which each sentence is included from
a separate file using one of those mechanisms. As soon as you hit mixed
content, the entity approach breaks down anyway. (Other formats, like JSON,
don't have entities but share a few of the same problems.) So how can
developers build RESTful applications that address parts of documents?
One approach that's getting a lot of discussion in the last few days is
to add a new verb, PATCH, to HTTP... It seems to me that the problem is
not that developers want to do something that can't be expressed with a
RESTful verb - in this case, probably UPDATE. The problem is that developers
can't address the resource on which they want to work with sufficient
granularity given their current set of tools and agreements. Though I've
inveighed against the many many sins of XPointer for years, that
incredibly broken process was at least working to solve the problem of
addressing XML documents at a very fine granularity, extending the tool
most commonly used on the client side for this: fragment identifiers...