I've been looking at the Google Documents API: http://code.google.com/apis/documents/docs/3.0/developers_guide_protocol.html
Here's the basic AtomPub model and the SWAPish model (ignoring copy): https://docs.google.com/drawings/pub?id=1GF5FErBkXng4T8Ms0T5wzhpUya6kl-nK5u_WylxpOQE&w=639&h=588 It seems obvious to me that the 'work' should be an atom collection (<feed>). The difficulty is how to create collections (=works) within Atom Pub and secondly how to modify the metadata of the collection (=work). Google's folders mechanism appears to solve this neatly by: POST(<atom:feed!workflow>/contents) -> <atom:entry!work> POST(<atom:entry!work/contents) -> <atom:entry!document/edit-link=file> (I've used '!' to indicate the model correspondence of the <atom> element) So I would take Google's AtomPub profile but constrain it to our model (work->document->bitstreams). POSTing an entry/file to the workflow contents will transparently create the entry->feed->entry and return the leaf <entry> (with it's edit-media file URI). POSTing an entry with a <atom:category> of 'work' will create the entry->feed and return the root <entry>. NB Google use parameters rather than headers to control server behaviour http://code.google.com/apis/documents/docs/3.0/developers_guide_protocol.html#OCR (I don't think there's a strong argument either way). User proxying is done through the URI: x/default/y - for the current user x/Bob/y - on behalf of Bob (Probably more RESTful because it keeps the URIs idempotent) All the best, Tim.
