[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (CMIS-772) Object identifier for "latest state" of an object
[ https://issues.oasis-open.org/browse/CMIS-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=38340#comment-38340 ]
Florian Müller commented on CMIS-772:
-------------------------------------
Here is my view on the current state of the discussion:
* We identified that we need a new ID property. This ID MUST be stable over the lifetime of an object and MUST be identical across all version objects in a version series. A repository MUST always provide a value for this property.
* This ID can be used in all CMIS operations instead of the object ID. In case of a versioned document, the repository picks the appropriate version object and performs the operation on this object. (See open questions below.)
* The definition of this property will become a CMIS 1.0/1.1 feature extension and replaces the version series ID property in CMIS 2.0.
Open questions:
1. Is this ID property present on all objects types or only on document types?
2. If the ID identifies a version series, which version object should the repository use? Options:
a. Always the latest version is chosen. If the user is not allowed to access the latest version, a permissionDenied exception is thrown.
b. If the document is checked out and the current user can access the PWC, then the PWC is chosen. Otherwise the latest version is chosen or a permissionDenied exception is thrown if the current user is not allowed to access the latest version.
c. The latest version (including the PWC) that current user is allowed to access is chosen or an objectNotFound exception is thrown if the user isn't allowed to see any version.
d. We don't define it (repository specific).
e. Something else...
3. How should we call that property?
I guess there is no point in discussing the first question again. There will be no additional arguments. We should just vote on it.
Regarding the second question, I prefer the third option, but we should discuss it again.
The property name depends a bit on the result of the second question. We should defer this question.
Did I miss anything?
> Object identifier for "latest state" of an object
> -------------------------------------------------
>
> Key: CMIS-772
> URL: https://issues.oasis-open.org/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 an ubiquitous identifier that identifies the "latest state" of any CMIS object.
> 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).
> The definition for the concept of a “latest state” of an object depends on a number of factors:
> * For unversioned cmis:documents and other object types, it would simply be the latest persisted state of the object
> * For versioned cmis:documents, it would equate to the latest version (as defined in CMIS 1.1, sections 2.1.13.2 and 2.13.5) of that document, *EXCEPT* if a Private Working Copy (PWC) exists.
> If a versioned cmis:document has a PWC checked out, the "latest state" would equate to that PWC, if the authenticated user has access to the PWC. If the authenticated user does _not_ have access to the PWC, the "latest state" would be equivalent to the latest version.
> Note: further thought may be needed regarding PWCs that were checked out from documents other than the latest version in a version series (see CMIS 1.1 section 2.1.13.5.1, 1st paragraph, 3rd sentence for details on this optional capability).
> 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 the "latest state" of 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). Use 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 state of a versioned document - they are always version specific
> * cmis:versionSeriesId is not ubiquitous - it is only mandatory for versioned cmis:document objects, and may not exist for 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 (see earlier definition of "latest state")
> 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]