[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://tools.oasis-open.org/issues/browse/CMIS-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=37405#comment-37405 ]
Jay Brown commented on CMIS-772:
--------------------------------
Regarding the statement:
“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. “
Issue:
I think there is a fundamental problem with this part. That is that given the exact same ‘latest state’ ID requested; user A may see a different document than user B! For example I send you an email with an ID of a document I have been working on asking for you to comment. (I have it checked out) You retrieve the doc by its latest ID and get a different document (i.e. in a different state). Now its ok for one user to see an ID and another user to get access denied for that ID. But for the system to silently return a different document for the same ID would not be an acceptable outcome.
> Object identifier for "latest state" of an object
> -------------------------------------------------
>
> 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 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]