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

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

Robert Koberg wrote:
> Fragment identifiers seem pretty limited. Does the modifiable node need
> to have an ID attribute?

No - the various XPointer schemes, of which I think xpath1() should be 
sufficient, let you go beyond IDs.  (They may, of course, let you go too 
far to make sense in this usage.)

> Is it a complete replacement, a modification, a
> deletion of a small part of the target? How would you (the server)
> know? 

I'd stick with the usual meanings of GET/PUT/POST/DELETE in the REST 
environment.  The complete fragment would be gotten, put, posted, or 
deleted.  (I'd expect an error if I tried to address a fragment that 
didn't yet exist, or couldn't be resolved.  There are around a billion 
questionable cases involving identifiers that point to more than one 
location, of course.)

> But, if you are working off the file system, you would need to
> load/parse the entire file to find what you want to modify. 

I'm thinking of something smarter than that, though I haven't reached 
those details yet.  Without a way to communicate from client to server 
that "I want to do X on Y fragment", the back end doesn't matter much.

> It seems like XQuery and an XML DB would be the way to go.
> 
> http://www.w3.org/TR/xquery-update-10-requirements/

That's an option in the back end of the application, but since XQuery 
wasn't built with full Create-Read-Update-Delete (CRUD), it doesn't map 
neatly to what I'd like to do.

> But I like working off the file system too. It is great for distributed
> collaboration and version control. Perhaps some kind of combination of
> SAX and XSL is a way to go. Run through the document using some kind of
> XML writer until you find the target (sent as a request parameter that
> is an XPath along with the type of modification). When you find it pipe
> it, along with the update, into a transformation that does a merge.
> Probably something like this exists?

In various pieces and parts, yes - but I think that coming up with a 
clean approach that could work reliably across applications is more 
important right now than figuring out what the inside of the app looks like.

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