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

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

>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?
IBM has a variety of repositories.  One at least does not have collection local names, and is predominately imaging.  Others do.  For the one that does not, we use URIs like /resource/document/<id> for the document regardless of folder it is in.  For the ones that do have collection local names, we chose not to expose this additional information through CMIS.

One of the main problems of collection-local names in ECM have been when exposing the repository as a FileSystem, when to use the collection-local name vs the filename on the document.  Typically the local names are either the same as the filename (loanapp.doc) or they are the same as the name property (My Loan Application) on the document.  If implementation leverages the name property (My Loan Application), they typically do not have the extension which confuse certain windows-based applications.

ECM systems tend to treat documents (objects) as their own independent object regardless of containment.  This leads ECM systems to typically implement the containment relationship as a separate entity (more modern) or on the document (older style).  

The other style which is not used (or not frequently?) in ECM systems (at least in the 4+ IBM has) is hierarchy-based where each document is specific to each location in the hierarchy.  That has been more common model for XML and WCM-centric repositories.  Based on the majority of ECM vendors not having this model during the start of the effort, CMIS chose the more typical ECM model:   Documents are separate objects that may be part of 1 or more folders.  

This leads to a potential misunderstanding (both are valid depending on how you define your resources).  If you understand that the link self of an atom entry refers to the resource in that folder (n-uris for a single resource|n=#offolders) vs the link self refers to the resource who happens to be in that feed/folder (1 uri per resource).  If you prefer the n-uri model (uri specific to collection-local) you will have issues deleting the document.

DELETE of a resource in CMIS, deletes the resource [in all folders] as the resource is the underlying object.  

If DELETE only removed the object from the feed/collection, you would have:
- issues modelling delete capability in CMIS domain model
- sub-optimal caching strategy as the client now thinks there are n resources instead of 1 and must cache n.

So back to your question, the easiest answer to systems that have collection-local names is to not present that information through CMIS and on create/add to folder/etc use a default such as the name property or atom title.

>What do you mean by "this", in this case? Why wouldn't DELETE work here?
This was removeObjectFromFolder functionality.  Resources in CMIS REST/APP are the underlying [CMIS] object and not a [synthetic] resource based on the combination of [CMIS] object+folder and thus would delete the object in all folders.

>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.
It sounds complex to me, but I would like (happy) to see a proposal if you come up with one.  
>Probably. It's good that we have at least discussed this, and found it
>to be too complicated.
Agreed.  I originally thought COPY/MOVE would be a good fit with the con of lack of support from some tooling.

-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/16/2009 02:58:12 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/16/2009 02:58 AM
Subject:	Re: [cmis] Re: Note on CMIS utilizing COPY and MOVE verbs

---

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


---------------------------------------------------------------------
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