[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cmis] Re: Note on CMIS utilizing COPY and MOVE verbs
>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.
Emerging Standards and Industry Frameworks
Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home
Office 714 327 3453
Mobile 714 263 6441
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:
Julian Reschke <email@example.com>
Al Brown/Costa Mesa/IBM@IBMUS
04/16/2009 02:58 AM
Re: [cmis] Re: Note on CMIS utilizing COPY and MOVE verbs