Object identifier for "latest state" of an object

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.