Re: [cmis] Re: Note on CMIS utilizing COPY and MOVE verbs

[Julian Reschke <julian.reschke@greenbytes.de>]

Al Brown wrote:
>  >Sure, that's the APP behavior, but APP is designed for posting items to
>  >news feeds, not for document management. So what I wanted to know what
>  >*CMIS* assumes.
> 
> Sure - CMIS Domain model provides/specifies:
> - addObjectToFolder(object, folder)
> - removeObjectFromFolder(object, folder)
> - moveObject(object, targetFolder[, sourceFolder])
> 
> REST App binding (currently) specifies:
> 
> - CMIS Folder is modeled as an APP Collection for 
> folder-membership/containment
> - CMIS Objects (Folder, document, relationship, policy) are modelled as 
> Atom Entries
> 
> - POST of an Atom Entry document to APP Collection is:
> - (if no cmis:objectId) createDocument/Folder/Relationship based on Atom 
> Entry
> - If post of something besides atom entry, createDocument with default 
> values with default document class
> - (if valid cmis:objectId) addObjectToFolder - adds object POST'ed to 
> the collection (folder)
> - Optionally if removeFrom is specified, also remove the specified 
> object from specified folder

OK, understood. Though I wonder how people want to interface *that* with 
other systems that do have collection-local names, such as JCR -- always 
use the object's unique id as local name?

> Nothing in the CMIS rest binding has collection-local names. Nothing in 
> the CMIS Domain model as folder-local names. CMIS domain model only 
> provides properties on an object, not properties on an object in a 
> particular folder.

That's not really different from other systems, which usually consider 
the collection-children binding as part of the collection's state.

>  > > removeObjectFromFolder?  
>  > How is that a problem?
> How can this be expressed with COPY/MOVE?

What do you mean by "this", in this case? Why wouldn't DELETE work here?

> MOVE - Add in Source-Collection header?
> COPY - Add in RemoveFrom-Collection header?
> 
>  >By defining a precondition code that can be sent back if
>  >Destination-Collection is absent, and by defining a new WebDAV feature
>  >to be returned in the "DAV" response header.
> COPY and MOVE verbs to me do not sound like a good fit.  And to get them 
> to work, it sounds like way too much effort - DAV header, new RFC most 
> likely, potentially other parts of DAV, etc.

I think they could be made to work, but it would involve spending some 
time on discussing how the containment model of CMIS can be mapped to 
WebDAV (or JCR) collections.

> Also, getting the required tooling to support the updated COPY/MOVE for 
> CMIS seems problematic.  Especially, if we want AJAX apps to be able to 
> provide these functions.  Not all JS clients can specify headers on POST.
> 
> I think it would be simpler to leave as-is or POST a new document type 
> (application/cmis-copyrequest, application/cmis-moverequest) to a 
> specific collection and a request resource created from that.  However, 
> the latter proposal is very RPCish messaging style in a RESTish pattern.

Probably. It's good that we have at least discussed this, and found it 
to be too complicated.

BR, Julian