|
JIRA #723 proposes adding another base object type, tentatively named cmis:item, to the CMIS data model to allow a repository to create new object types without inheriting unnecessary properties from the Document Object Type (cmis:document), such as properties pertaining to content stream or versioning. A major motivation for this proposal is to lower the barrier for various industry groups to use CMIS as a base for defining industry-specific interoperability standards via CMIS object subtyping. To maximize interoperability, if a subtype adds back a property that serves the same function as one of the properties defined by cmis:document, then the subtype should reuse the corresponding "cmis:xxx" property defined by cmis:document. The cmis:item type shall have the same common attributes described by v1.0 Section 2.1.3.2.1. Among them, the value of the following 7 attributes shall be specified as "repository-specific": creatable, fileable, queryable, controllablePolicy, includedInSupertypeQuery, controllableACL, fulltextIndexed. A new "create" service shall also be added for creating object instance of the cmis:item type or its subtypes. The four v1.0 base types remain unchanged.
For reference, system (spec-defined cmis:xxx) properties common to all object types in CMIS v1.0:
cmis:name
cmis:objectId
cmis:baseTypeId
cmis:objectTypeId
cmis:createdBy
cmis:creationDate
cmis:lastModifiedBy
cmis:lastModificationDate
cmis:changeToken
There are two variations of this proposal: (a) and (b). They differ in the properties cmis:item is to contain.
Approach (a): The set of properties that are common to all CMIS v1.0 objects shall all be used for cmis:item. (See the 9 properties listed above.)
Rationale for Approach (a):
Although cmis:object does not appear in the spec as a real object, having all CMIS objects share the same base properties makes it convenient for applications and frameworks to model CMIS as a hierarchy. (See Figure 2.2 in the draft 1.1 spec for a UML model of this representation.) For example, this commonality has been leveraged by multiple libraries in Apache Chemistry today. Approach (a) maintains this tradition keeping the model homogeneous where all CMIS objects share a common base set of characteristics as they do in v1.0.
Approach (b): The cmis:item type shall have only the following 4 properties (out of the above set of 9): cmis:objectId, cmis:baseTypeId, cmis:objectTypeId, cmis:creationDate.
Rationale for Approach (b):
Only the minimum set of properties required for proper functioning of CMIS is mandated. Other properties can be added by a repository as needed. Fixing minimum properties allows maximum customization. A major consideration for an industry group to leverage CMIS is to assess how well the CMIS data model matches their need. Any mismatch discourages adoption. Compared to Approach (a), this approach removed cmis:name, cmis:createdBy, and 3 properties pertaining to object modification. cmis:name and cmis:createdBy are unnecessary for transactional applications. It is often painful to generate artificial object names just for the sake of compliance. Properties that support object modification are unnecessary for read-only applications, which include, for example, most archival content (e.g. e-mail archive) and public-facing information sources. Since we are broadening the scope of CMIS to cover unforeseen applications, the common properties among the five base types would now be just these 4 properties, which can be used in a hierarchy in the same manner.
This ballot is to determine whether the TC should (1) accept #723 for v1.1 with Approach (a), or (2) accept #723 for v1.1 with Approach (b), or (3) reject #723 for v1.1. A simple majority shall prevail. Please use the comment field for any qualification for your vote, or any suggestion, that you may have.
|
