Proposal: Secondary Object Types

A CMIS 1.0 object has one (primary) object type that defines the properties of this object and cannot be changed. However, many repositories support secondary object types (mix-ins/aspects/categories/…) that can be attached to and removed from an object during its lifetime.

There are three main use cases for secondary types:

- Additional metadata has to be attached after the document has been created. Adding a new set of properties is necessary for some business cases. Also, some technical metadata derived from the content can only be added after the repository has analyzed the content.

- Some common and crosscutting concepts such as tags, comments and ratings can be implemented with secondary types.

- Properties of secondary types can also reveal (and control?) the status of an object. Examples are legal holds, workflows, storage/archiving information, publishing information, etc.

See also http://wiki.oasis-open.org/cmis/Mixin_Proposal .

This proposal describes how secondary types can be introduced in CMIS 1.1.

Additions to CMIS 1.0

- Add a new base type “Mixin”. By default, this type has no properties and its sole propose is to be the root type of all secondary object types. This type and types derived from it cannot be used as primary object type. The Mixin base type is optional.

- All other base types get an additional property cmis:secondaryObjectTypeIds (property type: id, cardinality: multi-value, updatablility: ). Similar to cmis:objectTypeId it holds the type ids of the secondary object types. If a repository does not support secondary types for a base type, the property definition is not exposed in the type definition. Therefore, CMIS 1.1 clients see CMIS 1.0 repositories as repositories without secondary type support.

- Secondary types can be applied as part of the object creation and by updating the cmis:secondaryObjectTypeIds property. A repository must return an error if the secondary type(s) cannot be applied.

- Secondary types can be removed by removing its id from the cmis:secondaryObjectTypeIds property list. All associated properties disappear as well. A repository must return an error if the secondary type(s) cannot be removed.

- Properties get a new attribute “typeDefinitionId”. It holds the type id that defines the property. If this attribute is missing, the primary type of the object is assumed.

- Properties of secondary types are delivered by default. In property filters the syntax . must be used.

- In queries secondary type properties are addressed in this way: [.].

Examples:

SELECT cmis:name, pic:exif.xResolution, pic:exif.yResolution, FROM cmis:document WHERE pic:exif.exposureTime < 0.002

where pic:exif is a secondary type.

SELECT cmis:objectId, cmis:name, tagging.tags FROM cmis:document WHERE ANY tagging.tags IN ("dog", "cat")

where tagging is a secondary type.

SELECT y.claim_mun, x.property_addrss, y.damage_estimates, x.risk.level FROM policy as x JOIN claims as y ON (x.policy_num = y.policy_num) WHERE (100000 = ANY y.damge_estimates) AND x.risk.level > 3

where risk is a secondary type.

- If secondary type properties are used in a SELECT or a WHERE clause and an object does not have this secondary type applied to it, all secondary type property values are assumed as not-set.