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
