[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RESTful operations on document fragments

• From: "Simon St.Laurent" <simonstl@s...>
• To: "xml-dev@l..." <xml-dev@l...>
• Date: Fri, 22 Feb 2008 17:32:32 -0500

Friday evening is usually a bad time to start a conversation, but this 
may be kind of appropriate to a Friday evening.

I've been enjoying working with RESTful operations in Ruby on Rails and 
some of the XML they can generate [1].  At the same time, I'm thinking 
about various projects I'd like to work with that use XML documents as a 
foundation rather than relational databases - it'd be great to have 
something like ActiveTreebranch to go with ActiveRecord.

Before I even think about the Ruby side, though - and I'm a long ways 
from that - I'm wondering about a more basic problem.

RESTful operations are performed on resources identified by URIs.  Those 
URIs can - if I'm reading HTTP 1.1 [2] right - include a query string 
even when they're used with PUT, POST or DELETE.  (I need to do some 
experiments to verify that this actually works - I hadn't considered 
doing it before.)

However, document fragments are typically identified through the 
fragment identifier, the #xxxx that is the usual domain of tools like 
XPointer.  The fragment identifier is not normally sent to the server, 
and is supposed to be processed on the client side, depending on the 
MIME type of the response. [3]

That makes good sense in the GET context which has been typical of most 
Web operations.  However, it raises a challenge in the RESTful 
processing context.

Am I required to perform RESTful operations only against a complete 
resource?

For example, if I want to fix a typo in one verse of the Old Testament 
XML file, should I really send the entire 3.3MB document, or is there a 
way to convey in RESTful parlance that an update is only for a portion 
of a document?

I'd love to be able to issue GET, PUT, POST, and DELETE against document 
fragments, but the fragment identifier approach isn't going to work, and 
I've not (yet) found anything nearly as expressive that goes into the 
URL outside of the fragment identifier space.

To give a practical example, having even simple RESTful access to 
fragments using a subset of XPath would make it much simpler to write 
Web-based editors for manipulating (writing, editing, etc.) book content.

I did find some very simple recent work from Joe Gregorio [4]. That 
seems both to have gotten pushback and limited itself to id-based 
fragments.

The problem of resource granularity seems like a question that is 
starting to need a more general and at least somewhat flexible solution.

(Rails' current RESTfulness can dodge this because each database record 
is treated as a resource, and that's the usual granularity developers 
work at.  It only gets weird when you look beyond regular tables to 
irregular documents.)

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

[1] - 
<http://www.oreillynet.com/xml/blog/2008/01/rails_rest_and_anarchist_xml_1.html>

[2] - <http://www.faqs.org/rfcs/rfc2616.html>

[3] - <http://www.w3.org/DesignIssues/Fragment.html>

[4] - <http://bitworking.org/news/296/How-To-Do-RESTful-Partial-Updates>