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

[Al Brown <albertcbrown@us.ibm.com>]

>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

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.

> > removeObjectFromFolder?  
> How is that a problem?
How can this be expressed with COPY/MOVE?  
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.

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.

-Al

Al Brown
Emerging Standards and Industry Frameworks
CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home
Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home

Office 714 327 3453
Mobile 714 263 6441
Email albertcbrown@us.ibm.com
CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation.

Julian Reschke ---04/15/2009 11:56:24 AM---Al Brown wrote:

From:	Julian Reschke <julian.reschke@greenbytes.de>
To:	Al Brown/Costa Mesa/IBM@IBMUS
Cc:	cmis@lists.oasis-open.org
Date:	04/15/2009 11:56 AM
Subject:	Re: [cmis] Re: Note on CMIS utilizing COPY and MOVE verbs

---

Al Brown wrote:
>  >Is the assumption that the server will assign the collection-local name?
> That is the APP behavior - After POST, Content-Location header is 
> returned with the location of the [new] resource [in that collection]. 
>  The server may specify the new location as a collection-local name.  Or 
> it may not.  The FileNet prototype does not use collection-local names, 
> but rather bases the URI off of the underlying object id.

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.

>  >If we wanted to use COPY/MOVE, we'd need an extension (such as
>  >"Destination-Collection" instead of "Destination"). On the other hand,
>  >we could standardize the "Allow-Rename" header
>  >(<http://msdn.microsoft.com/en-us/library/aa142703(EXCHG.65).aspx>),
>  >which apparently is already supported in some Microsoft products.
> I would prefer Destination-Collection.  However, how do we advertise to 
> clients that COPY/MOVE does not support Destination but 
> Destination-Collection header?  Also, how do we map 

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.

> removeObjectFromFolder?  

How is that a problem?

> We could either add a new header (e.g., removeFrom) or a new verb. 
>  However, I do not get a warm feeling from this approach so far.  I 
> think it would be cleaner to have new verbs or have those verbs 
> clarified in an rfc for this use case first.

Of course, whatever is needed here should be done in the IETF Apps Area.

BR, Julian

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php