[OASIS Issue Tracker] (CMIS-772) Version-independent object identifier

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://tools.oasis-open.org/issues/browse/CMIS-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=37297#comment-37297 ] 

Peter Monks commented on CMIS-772:
----------------------------------

Florian, this is a statement of the requirements for this mechanism.  Proposals were explicitly out of scope - until we have broad agreement on the requirements, proposals for a solution are premature at best and misguided at worst.

> Version-independent object identifier
> -------------------------------------
>
>                 Key: CMIS-772
>                 URL: https://tools.oasis-open.org/issues/browse/CMIS-772
>             Project: OASIS Content Management Interoperability Services (CMIS) TC
>          Issue Type: Improvement
>          Components: Domain Model
>    Affects Versions: Proposals for 2.0
>         Environment: n/a
>            Reporter: Peter Monks
>             Fix For: Proposals for 2.0
>
>
> Background
> ----------------------------------------
> This document distills the work undertaken by Peter Monks, Ken Baclawski and Eric Chan, initially as part of CMIS-731.  It was determined that this proposal is orthogonal to CMIS-731 (though may benefit that work, when/if implemented).
> Document Scope
> ----------------------------------------
> This document captures, at a high level, the functional requirements for ubiquitous, version-independent identifiers for CMIS objects.
> Non-functional requirements, including, but not limited to:
> * Backwards compatibility with existing versions of the CMIS specification
> * Minimising implementation cost for the various extant CMIS servers
> are explicitly out of scope for this document (but will need to be considered during evaluation of any proposed solutions).
> A precise definition for the concept of a “latest state” of a versioned cmis:document is out of scope for this document (in fact the CMIS 1.1 specification is ambiguous on this point, specifically in the presence of Private Working Copies).  Such a definition is a prerequisite for a proposed solution, but is orthogonal to the requirements stated here.
> Problem Statement
> ----------------------------------------
> Virtually all CMIS client applications perform the fundamental file/folder operations of create, read, update and delete (“CRUD”), in a version-independent manner.  Effectively, the 80% usage case for a CMIS repository is as a filesystem alternative.
> Some, but not all, CMIS client applications go beyond these basic file/folder CRUD operations with metadata manipulation, version operations, creation and management of primary working copies, execution of queries, records management and so on, but even in such “advanced” client applications a majority of the operations that are executed are basic file/folder CRUD operations.
> There is one primary difference between how CMIS is used and how filesystems are typically used however.  Many CMIS client applications need to store references to CMIS objects for their own purposes - either temporarily (e.g. while an end user session is in progress) or permanently (e.g. in their own persistent data store).  Uses cases here range from needing to temporarily “remember” the id of the document a user is in the process of manipulating in the client application, to storing persistent references to CMIS managed documents for later use (use cases here include things like long running content processing applications, applications that allow the user to bookmark or favourite CMIS objects, and many more).
> Note that the objects referred to in these use cases aren’t just cmis:documents - they could be *any* of the CMIS object types (cmis:document, cmis:folder, cmis:item, cmis:relationship or cmis:policy), in any state (versioned, unversioned, etc.).
> As has been described in detail elsewhere (e.g. http://blogs.alfresco.com/wp/pmonks/2014/02/07/a-case-of-mistaken-identity/), these needs are not directly met by CMIS v1.0 or v1.1:
> * cmis:objectId does not “track” to the latest version of a versioned document - they are always version specific
> * cmis:versionSeriesId is not ubiquitous - it is only mandatory for versioned cmis:document objects, not unversioned cmis:documents or other CMIS object types
> Requirements
> ----------------------------------------
> The requirements follow directly from this problem statement.  CMIS, to properly support CMIS client applications, requires an identifier that:
> 1. “tracks” the latest state of the object i.e. the latest version when an object has versions but otherwise just the latest state of the object as it exists in the repository.
> 2. is ubiquitous...
>     a. ...in the domain model i.e. all objects, regardless of type, have this identifier
>     b. ...in the services i.e. all services that accept identifiers (typically those that operate on singleton objects) can be invoked with this new identifier
> Non-requirements
> ----------------------------------------
> The following are not requirements of a solution to the problem statement:
> 1. New CMIS data types or object types
> 2. New copies or views of CMIS objects
> This identifier is solely a reference to CMIS objects that are already supported by the specification.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)