Copyright © OASIS Open 2012. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS’ procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/policies-guidelines/trademark for above guidance. __________________________________________________________________

Table of Contents

---

1 Introduction

The CMIS interface is designed to be layered on top of existing Content Management systems and their existing programmatic interfaces. It is not intended to prescribe how specific features should be implemented within those CM systems, nor to exhaustively expose all of the CM system’s capabilities through the CMIS interfaces. Rather, it is intended to define a generic/universal set of capabilities provided by a CM system and a set of services for working with those capabilities.

1.1 Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

1.2 Normative References

1.3 Non-Normative References

1.4 Examples

A set of request and response examples is attached to this specification document. These examples are non-normative and their sole purpose is to illustrate the data structures and bindings that are defined in this specification.

Boxes like the following point to appropriate example files throughout this document. There is usually a request file describing the request sent from a CMIS client to a CMIS repository and a matching response file that contains the content returned from the CMIS repository.

1.5 Changes for the CMIS 1.1 specification

This section provides a very brief description of each major new CMIS 1.1 feature along with links to the sections of this document for complete descriptions.

1.5.1 Type Mutability

Defines the services and protocol binding extensions that allow CMIS clients to create, modify and delete Type Definitions and Property Definitions for a given repository.

Please see section 2.1.10 Object-Type Creation, Modification and Deletion for a detailed discussion of this feature.

1.5.2 Repository Features

Defines additional schema for the getRepositoryInfo service that allows CMIS clients to discover any extensions or additional CMIS based standards supported on each repository.

Please see section 2.1.1.3 Repository Features for a detailed discussion of this feature.

1.5.3 Secondary object types

Defines named sets of properties that can be dynamically added and removed from CMIS objects.

Please see section 2.1.9 Secondary Object-Types for a detailed discussion of this feature.

1.5.4 Retention and Hold Support

Defines secondary types for formally representing Retentions and Holds on CMIS objects. These in turn can be used by the repository to protect objects from being deleted or modified. A Retention describes a period of time that a document must not be deleted, while a Hold marks the document as protected as long as the Hold is applied.

Please see section 2.1.16 Retentions and Holds for a detailed discussion of these features.

1.5.5 Browser Binding

A new optional binding specifically designed to support applications running in a web browser or other client without the need for any additional client libraries. Notable among the differences in this binding are the use of JSON (Java Script Object Notation, [RFC4627]) instead of XML and the exclusive use of HTTP GET and POST for all operations.

Please see section 5 Browser Binding for a detailed discussion of this feature.

1.5.6 New cmis:item Object Type

A new top level data model type that is an extension point for repositories that need to expose any other object types via CMIS that do not fit the model’s definition for document, folder, relationship or policy.

Please see section 2.1.8 Item Object for a detailed discussion of this feature.

1.5.7 Service bulkUpdateProperties

A method for supporting bulk property updates on a set of objects within a single service call.

Please see section 2.2.4.14 bulkUpdateProperties for a detailed discussion of this feature.

1.5.8 Append to a content stream

Support for appending to a content stream. Enables clients to break very large uploads of document content into numerous smaller calls.

Please see section 2.2.4.19 appendContentStream for a detailed discussion of this feature.

---

2 Domain Model

2.1 Data Model

CMIS provides an interface for an application to access a repository. To do so, CMIS specifies a core data model that defines the persistent information entities that are managed by the repository, and specifies a set of basic services that an application can use to access and manipulate these entities. In accordance with the CMIS objectives, this data model does not cover all the concepts that a full-function ECM repository typically supports. Specifically, transient entities (such as programming interface objects), administrative entities (such as user profiles), and extended concepts (such as compound or virtual document, work flow and business process, event and subscription) are not included.

However, when an application connects to a CMIS service endpoint, the same endpoint MAY provide access to more than one CMIS repository. (How an application obtains a CMIS service endpoint is outside the scope of CMIS. How the application connects to the endpoint is a part of the protocol that the application uses.) An application MUST use the CMIS getRepositories service to obtain a list of repositories that are available at that endpoint. The repository id MUST uniquely identify an available repository at this service endpoint. Both the repository name and the repository id are opaque to CMIS. Aside from the getRepositories service, all other CMIS services are single-repository-scoped, and require a repository id as an input parameter. In other words, except for the getRepositories service, multi-repository and inter-repository operations are not supported by CMIS.

2.1.1 Repository

The repository itself is described by the CMIS "Get Repository Information" service. The service output is fully described in section 2.2.2.2 getRepositoryInfo.

2.1.1.1 Optional Capabilities

Commercial ECM repositories vary in their designs. Moreover, some repositories are designed for a specific application domain and may not provide certain capabilities that are not needed for their targeted domain. Thus, a repository implementation may not necessarily be able to support all CMIS capabilities. A few CMIS capabilities are therefore "optional" for a repository to be compliant. A repository’s support for each of these optional capabilities is discoverable using the getRepositoryInfo service. The following is the list of these optional capabilities. All capabilities are "boolean" (i.e. the repository either supports the capability entirely or not at all) unless otherwise noted.

Navigation Capabilities

capabilityGetDescendants

Ability for an application to enumerate the descendants of a folder via the getDescendants service.
See section 2.2.3.2 getDescendants.

capabilityGetFolderTree

Ability for an application to retrieve the folder tree via the getFolderTree service.
See section 2.2.3.3 getFolderTree.

capabilityOrderBy

Indicates the ordering capabilities of the repository.
Valid values are:

none

Ordering is not supported.

common

Only common CMIS properties are supported. See section 2.2.1.2.7 Object Order for the list of properties.

custom

Common CMIS properties and custom object-type properties are supported.

See section 2.2.1.2.7 Object Order.

Object Capabilities

capabilityContentStreamUpdatability

Indicates the support a repository has for updating a documents content stream.
Valid values are:

none

The content stream may never be updated.

anytime

The content stream may be updated any time.

pwconly

The content stream may be updated only when checked out. Private Working Copy (PWC) is described in section 2.1.13 Versioning.

See section 2.1.4.1 Content Stream.

capabilityChanges

Indicates what level of changes (if any) the repository exposes via the getContentChanges service.
Valid values are:

none

The repository does not support the change log feature.

objectidsonly

The change log can return only the object ids for changed objects in the repository and an indication of the type of change, not details of the actual change.

properties

The change log can return properties and the object id for the changed objects.

all

The change log can return the object ids for changed objects in the repository and more information about the actual change.

See section 2.1.15 Change Log.

capabilityRenditions

Indicates whether or not the repository exposes renditions of document or folder objects.
Valid values are:

none

The repository does not expose renditions at all.

read

Renditions are provided by the repository and readable by the client.

See section 2.1.4.2 Renditions.

Filing Capabilities

capabilityMultifiling

Ability for an application to file a document or other file-able object in more than one folder.
See section 2.1.5 Folder Object.

capabilityUnfiling

Ability for an application to leave a document or other file-able object not filed in any folder.
See section 2.1.5 Folder Object.

capabilityVersionSpecificFiling

Ability for an application to file individual versions (i.e., not all versions) of a document in a folder.
See section 2.1.13 Versioning.

Versioning Capabilities

capabilityPWCUpdatable

Ability for an application to update the "Private Working Copy" of a checked-out document.
See section 2.1.13 Versioning.

capabilityPWCSearchable

Ability of the Repository to include the "Private Working Copy" of checked-out documents in query search scope; otherwise PWC’s are not searchable.
See section 2.1.13 Versioning.

capabilityAllVersionsSearchable

Ability of the Repository to include all versions of document. If False, typically either the latest or the latest major version will be searchable.
See section 2.1.13 Versioning.

Query Capabilities

capabilityQuery

Indicates the types of queries that the Repository has the ability to fulfill. Query support levels are:

none

No queries of any kind can be fulfilled.

metadataonly

Only queries that filter based on object properties can be fulfilled. Specifically, the CONTAINS() predicate function is not supported.

fulltextonly

Only queries that filter based on the full-text content of documents can be fulfilled. Specifically, only the CONTAINS() predicate function can be included in the WHERE clause.

bothseparate

The repository can fulfill queries that filter EITHER on the full-text content of documents OR on their properties, but NOT if both types of filters are included in the same query.

bothcombined

The repository can fulfill queries that filter on both the full-text content of documents and their properties in the same query.

See section 2.1.14 Query.

capabilityJoin

Indicates the types of JOIN keywords that the Repository can fulfill in queries. Support levels are: 

none

The repository cannot fulfill any queries that include any JOIN clauses on two primary types. If the Repository supports secondary types, JOINs on secondary types SHOULD be supported, even if the support level is none.

inneronly

The repository can fulfill queries that include an INNER JOIN clause, but cannot fulfill queries that include other types of JOIN clauses.

innerandouter

The repository can fulfill queries that include any type of JOIN clause defined by the CMIS query grammar.

See section 2.1.14 Query.

Type Capabilities

capabilityCreatablePropertyTypes

A list of all property data types that can be used by a client to create or update an object-type definition. See sections 2.1.2.1 Property and 2.1.10.1 General Constraints on Metadata Changes.

capabilityNewTypeSettableAttributes

Indicates which object-type attributes can be set by a client when a new object-type is created. This capibility is a set of booleans; one for each of the following attributes:

• id
• localName
• localNamespace
• displayName
• queryName
• description
• creatable
• fileable
• queryable
• fulltextIndexed
• includedInSupertypeQuery
• controllablePolicy
• controllableACL

The repository MUST set the object-type attributes that cannot be set by a client or are not set by a client.
See section 2.1.10 Object-Type Creation, Modification and Deletion.

ACL Capabilities

capabilityACL

Indicates the level of support for ACLs by the repository.

none

The repository does not support ACL services.

discover

The repository supports discovery of ACLs (getACL and other services).

manage

The repository supports discovery of ACLs AND applying ACLs (getACL and applyACL services).

See section 2.1.12 Access Control.

2.1.1.2 Implementation Information

The getRepositoryInfo service MUST also return implementation information including vendor name, product name, product version, version of CMIS that it supports, the root folder id (see section 2.1.5.2 Folder Hierarchy), and MAY include other implementation-specific information. The version of CMIS that the repository supports MUST be expressed as a String that matches the specification version. For this version it is the string "1.1".

2.1.1.3 Repository Features

Repositories MAY provide information about additional features that are supported by the repository but that are outside the CMIS specification. This information is returned by the getRepositoryInfo service.

Clients that don’t understand this information SHOULD ignore it.

The repository MUST provide a unique id for each feature. This id SHOULD take the form of a URI (see [RFC3986]). The repository MAY also provide a version label as well as a human-readable common name and description for each feature.

Furthermore, each feature MAY supply an arbitrary number of key-value pairs. The semantics and rules for these key-value pairs are not defined by CMIS but MAY be constrained by other specifications.

2.1.2 Object

The entities managed by CMIS are modeled as typed objects. There are five primary base types of objects: document objects, folder objects, relationship objects, policy objects, and item objects.

• A document object represents a standalone information asset. Document objects are the elementary entities managed by a CMIS repository.
• A folder object represents a logical container for a collection of "file-able" objects, which include folder objects, document objects, policy objects, and item objects. Folder objects are used to organize file-able objects. Whether or not an object is file-able is specified in its object-type definition.
• A relationship object represents an instance of a directional relationship between two objects. The support for relationship objects is optional. The getTypeChildren service when asked for the base object-types MUST return the base relationship object-type if the repository supports relationships.
• A policy object represents an administrative policy, which may be "applied" to one or more "controllablePolicy" objects. Whether or not an object is controllable is specified in its object-type definition. The support for policy objects is optional. The getTypeChildren service when asked for the base object-types MUST return the base policy object-type if the repository supports policies.
• An item object represents a generic type of CMIS information asset. Item objects are not versionable and do not have content streams like documents but have properties like all other CMIS objects. The support for item objects is optional. The getTypeChildren service when asked for the base object-types MUST return the base item object-type if the repository supports items.

Additional object-types MAY be defined in a repository as subtypes of these base types. CMIS services are provided for the discovery of object-types that are defined in a repository. Furthermore, object-type management services are provided to create, modify and delete object-types if that is supported by the repository.

Every CMIS object has an opaque and immutable object id, which is assigned by the repository when the object is created. An id uniquely identifies an object within a repository regardless of the type of the object. Repositories SHOULD assign ids that are "permanent" – that is, they remain unchanged during the lifespan of the identified objects, and they are never reused or reassigned after the objects are deleted from the repository.

Every CMIS object has a set of named, but not explicitly ordered, properties. (However, a repository SHOULD always return object properties in a consistent order.) Within an object, each property is uniquely identified by its property definition id. The object properties are defined by the object-type.

An object must have one and only one primary object-type, which cannot be changed. An object’s primary object-type may be simply called its object-type. The primary object-type of an object classifies the object and defines the properties that the object must have.

An object MAY have zero or more secondary object types applied to it. A secondary type is a named marking that may add extra properties to an object in addition to the properties defined by the object’s primary type. That is, applying a secondary type to an object adds the properties defined by this type to the object. Removing a secondary type removes the properties. Secondary object-types can only be defined as subtypes or descendant types of the cmis:secondary base type. All other base object types and their descendant types are primary object-types.

Consequently, each instance of a primary object-type corresponds to a distinct object, whereas each instance of a secondary object type does not. Therefore, the "creatable", "fileable", "controllablePolicy", and "controllableACL" object type attributes are not applicable to a secondary object type and must be set to FALSE.

The support for secondary types is optional, and may be discovered via the getTypeChildren service. See section 2.1.9 Secondary Object-Types.

In addition, a document object MAY have a content stream, which may be used to hold a raw digital asset such as an image or a word-processing document. A repository MUST specify, in each object-type definition, whether document objects of that type MAY, MUST, or MUST NOT have a content stream. A document MAY also have one or more renditions associated with it. A rendition can be a thumbnail or an alternate representation of the content stream.

Objects MAY have one Access Control List (ACL), which controls access to the object. A set of policy objects may also control access to the object. An ACL represents a list of Access Control Entries (ACEs). An ACE in turn represents one or more permissions being granted to a principal (a user, group, role, or something similar).

The notion of localization of the objects in the data model is entirely repository specific.

CMIS objects MAY expose additional information, such as vendor-specific workflow data, beyond the attributes described above. In this respect, the data model can be extended as desired. This specification does not standardize such extensions.

2.1.2.1 Property

A property MAY hold zero, one, or more typed data value(s). Each property MAY be single-valued or multi-valued. A single-valued property contains a single data value, whereas a multi-valued property contains an ordered list of data values of the same type. The ordering of values in a multi-valued property SHOULD be preserved by the repository.

A property, either single-valued or multi-valued, MAY be in a "not set" state. CMIS does not support "null" property value. If a multi-valued property is not in a "not set" state, its property value MUST be a non-empty list of individual values. Each individual value in the list MUST NOT be in a "not set" state and MUST conform to the property’s property-type.

A multi-valued property is either set or not set in its entirety. An individual value of a multi-valued property MUST NOT be in an individual "value not set" state and hold a position in the list of values. An empty list of values MUST NOT be allowed.

Every property is typed. The property-type defines the data type of the data value(s) held by the property. CMIS specifies the following property-types. They include the following data types defined by "XML Schema Part 2: Datatypes Second Edition" (see [XMLSchema]):

string

(xsd:string)

boolean

(xsd:boolean)

decimal

(xsd:decimal)
(see section 2.1.3.3.5 Attributes specific to Decmial Object-Type Property Definitions for attributes specific to Decimal object-type property definitions.)

integer

(xsd:integer)
(see section 2.1.3.3.3 Attributes specific to Integer Object-Type Property Definitions for attributes specific to Integer object-type property definitions.)

datetime

(xsd:dateTime)
(see section 2.1.3.3.4 Attributes specific to DateTime Object-Type Property Definitions for attributes specific to DateTime object-type property definitions.)

uri

(xsd:anyURI)

In addition, the following property-types are also specified by CMIS:

id

html

Individual protocol bindings MAY override or re-specify these property-types.

For single valued String, Id and HTML properties, a repository MAY support the distinction between a set value with an empty string (length = 0), and a "not set" value. In this case an empty value element (e.g. <cmis:value/>) inside of a property element will indicate a "set but empty" string property. A property element without a <cmis:value/> will indicate a property in a "not set" state. For repositories that do not support this distinction the latter example (absence of the <cmis:value> element) should be used for all cases.

2.1.2.1.1 Id Property

While all CMIS identities share the same property-type, they do not necessarily share the same address space. Unless explicitly specified, id properties NEED NOT maintain a referential integrity constraint. Therefore, storing the id of one object in another object NEED NOT constrain the behavior of either object. A repository MAY, however, support referential constraint underneath CMIS if the effect on CMIS services remains consistent with an allowable behavior of the CMIS model. For example, a repository MAY return a constraint exception when a CMIS service call violates an underlying referential constraint maintained by the repository. In that case, an error message SHOULD be returned to the application to describe the cause of the exception and suggest a remedial action. The content of such messages is outside the scope of CMIS.

2.1.2.1.2 HTML Property

2.1.2.1.3 Query Names

• whitespace " "
• comma ","
• double quotes ’"’
• single quotes "’"
• backslash "\"
• the period "."
• the open "(" or close ")" parenthesis characters

2.1.3 Object-Type

An object-type defines a fixed and non-hierarchical set of properties ("schema") that all objects of that type have. This schema is used by a repository to validate objects and enforce constraints, and is also used by a user to compose object-type-based (structured) queries.

All CMIS objects are strongly typed. If a property not specified in an object’s object-type definition is supplied by an application, an exception SHOULD be thrown.

Each object-type is uniquely identified within a repository by a system-assigned and immutable object-type identifier, which is of type Id.

A CMIS repository MUST expose exactly one collection of object-types via the "repository" services (getTypeChildren, getTypeDescendants, getTypeDefinition).

While a repository MAY define additional object-types beyond the CMIS base object-types, these object-types MUST NOT extend or alter the behavior or semantics of a CMIS service (for example, by adding new services). A repository MAY attach additional constraints to an object-type underneath CMIS, provided that the effect visible through the CMIS interface is consistent with the allowable behavior of CMIS.

2.1.3.1 Object-Type Hierarchy and Inheritance

Hierarchy and Inheritance for object-types are supported by CMIS in the following manner:

• A CMIS repository MUST have these base types:
  • cmis:document object-type
  • cmis:folder object-type
• A CMIS repository MAY have these base types:
  • cmis:relationship object-type
  • cmis:policy object-type
  • cmis:item object-type
  • cmis:secondary object-type
• Additional base types MUST NOT exist. Additional object-types MAY be defined as sub-types or descendant types of these six base types.
• A base type does not have a parent type.
• A non-base type has one and only one parent type. An object-type’s parent type is a part of the object-type definition.
• An object-type definition includes a set of object-type attribute values (e.g. fileable, queryable, etc.) and a property schema that will apply to objects of that type.
  • There is no inheritance of object-type attributes from a parent object-type to its sub-types.
• The properties of a CMIS base type MUST be inherited by its descendant types.
• A child type whose immediate parent is NOT its base type SHOULD inherit all the property definitions that are specified for its parent type. In addition, it MAY have its own property definitions.
  • If a property is NOT inherited by a subtype, the exhibited behavior for query MUST be as if the value of this property is "not set" for all objects of this sub-type.
• The scope of a query on a given object-type is automatically expanded to include all the descendant types of the given object-type with the attribute includedInSuperTypeQuery equals TRUE. This was added for synthetic types as well as to support different type hierarchies that are not necessarily the same as CMIS. Only the properties of the given object-type, including inherited ones, MUST be used in the query. Properties defined for its descendant types MAY NOT be used in the query, and CAN NOT be returned by the query.
  • If a property of its parent type is not inherited by this type, the property MUST still appear as a column in the corresponding virtual table in the relational view, but this column MUST contain a "not set" value for all objects of this type. (See section 2.1.14 Query)

2.1.3.2 Object-Type Attributes

2.1.3.2.1 Attributes common to ALL Object-Type Definitions

2.1.3.3 Object-Type Property Definitions

Besides these object-type attributes, an object-type definition SHOULD contain inherited property definitions and zero or more additional property definitions. All the properties of an object, including inherited properties, MUST be retrievable through the "get" services, and MAY appear in the SELECT clause of a query.

2.1.3.3.1 Property Types

2.1.3.3.2 Attributes common to ALL Object-Type Property Definitions

2.1.3.3.3 Attributes specific to Integer Object-Type Property Definitions

2.1.3.3.4 Attributes specific to DateTime Object-Type Property Definitions

2.1.3.3.5 Attributes specific to Decmial Object-Type Property Definitions

2.1.3.3.6 Attributes specific to String Object-Type Property Definitions

2.1.4 Document Object

Document objects are the elementary information entities managed by the repository.

Depending on its object-type definition, a document object may be:

Version-able

Can be acted upon via the Versioning Services (for example: checkOut, checkIn).

File-able

Can be filed in zero, one, or more than one folder via the Multi-filing Services.

Query-able

Can be located via the Discovery Services (for example: query).

Controllable-Policy

Can have policies applied to it. (See section 2.1.7 Policy Object.)

Controllable-ACL

Can have an ACL applied to it. (See section 2.1.12 Access Control.)

Additionally, whether a document object MUST, MAY or MUST NOT have a content stream is specified in its object-type definition. A document object MAY be associated with zero or more renditions.

Note: When a document is versioned, each version of the document is a separate document object. Thus, for document objects, an object id actually identifies a specific version of a document.

2.1.4.1 Content Stream

A content stream is a binary stream. Its maximum length is repository specific. Each content stream has a MIME Media Type, as defined by [RFC2045] and [RFC2046]. A content stream’s attributes are represented as properties of the content stream’s containing document object. There is no MIME type specific attribute or name directly associated with the content stream outside of the document object.

CMIS provides basic CRUD¹ services for content stream, using the id of a content stream’s containing document object for identification. A content stream also has a contentStreamId which is used for access to the stream. The setContentStream service either creates a new content stream for a document object or replaces an existing content stream. The appendContentStream service either creates a new content stream or appends content to an existing content stream. The getContentStream service retrieves a content stream. The deleteContentStream service deletes a content stream from a document object. In addition, the createDocument and checkIn services MAY also take a content stream as an optional input. A content stream MUST be specified if required by the object-type definition. These are the only services that operate on content stream. The getObject and query services, for example, do not return a content stream.

setContentStream, appendContentStream and deleteContentStream services are considered modifications to a content stream’s containing document object, and SHOULD therefore change the object’s last modification date property upon successful completion.

The ability to set or delete a content stream is controlled by the capabilityContentStreamUpdatability capability.

2.1.4.2 Renditions

Some ECM repositories provide a facility to retrieve alternative representations of a document. These alternative representations are known as renditions. This could apply to a preview case which would enable the client to preview the content of a document without needing to download the full content. Previews are generally reduced fidelity representations such as thumbnails. Renditions can take on any general form, such as a PDF version of a word processing document.

A CMIS repository MAY expose zero or more renditions for a document or folder in addition to a document’s content stream. CMIS provides no capability to create or update renditions accessed through the rendition services. Renditions are specific to the version of the document or folder and may differ between document versions. Each rendition consists of a set of rendition attributes and a rendition stream. Rendition attributes are not object properties, and are not queryable. They can be retrieved using the getRenditions service. A rendition stream can be retrieved using the getContentStream service with the rendition’s streamId parameter.

2.1.4.2.1 Rendition Attributes

2.1.4.2.2 Rendition Kind

CMIS defines the following kind:

cmis:thumbnail

A rendition whose purpose is to provide an image preview of the document without requiring the client to download the full document content stream. Thumbnails are generally reduced fidelity representations.

2.1.4.3 Document Object-Type Definition

This section describes the definition of the document object-type’s attribute values and property definitions which must be present on document instance objects. All attributes and property definitions are listed by their id.

2.1.4.3.1 Attributes specific to Document Object-Types

2.1.4.3.2 Attribute Values

Notes:

• A value of <repository-specific> indicates that the value of the property MAY be set to any valid value for the attribute type.
• Unless explicitly stated otherwise, all values specified in the list MUST be followed for the object-type definition.

id
Value: cmis:document

localName
Value: <repository-specific>

localNamespace
Value: <repository-specific>

queryName
Value: cmis:document

displayName
Value: <repository-specific>

baseId
Value: cmis:document

parentId
Value: MUST NOT be set

description
Value: <repository-specific>

creatable
Value: <repository-specific>

fileable
Value: SHOULD be TRUE

queryable
Value: SHOULD be TRUE

controllablePolicy
Value: <repository-specific>

controllableACL
Value: <repository-specific>

includedInSupertypeQuery
Value: <repository-specific>

fulltextIndexed
Value: <repository-specific>

typeMutability.create
Value: <repository-specific>

typeMutability.update
Value: <repository-specific>

typeMutability.delete
Value: <repository-specific>

versionable
Value: <repository-specific>

contentStreamAllowed
Value: <repository-specific>

2.1.4.3.3 Property Definitions

2.1.5 Folder Object

A folder object serves as the anchor for a collection of file-able objects. The folder object has an implicit hierarchical relationship with each object in its collection, with the anchor folder object being the parent object and each object in the collection being a child object. This implicit relationship has specific containment semantics which MUST be maintained by the repository with implicit referential integrity. (That is, there will never be a dangling parent-relationship or a dangling child-relationship. Furthermore, object A is a parent of object B if and only if object B is a child of object A.) This system-maintained implicit relationship is distinct from an explicit relationship which is instantiated by an application-maintained relationship object. (See section 2.1.6 Relationship Object.)

A folder object does not have a content-stream and is not version-able. A folder object MAY be associated with zero or more renditions (see section 2.1.4.2 Renditions).

2.1.5.1 File-able Objects

A file-able object is one that MAY be "filed" into a folder. That is, it MAY be a child object of a folder object. The following list defines whether the base CMIS object-types are file-able:

cmis:folder

MUST be file-able

cmis:document

MAY be file-able

cmis:relationship

MUST NOT be file-able

cmis:policy

MAY be file-able

cmis:item

MAY be file-able

2.1.5.1.1 Document Version Series and Filing

When the child objects of a folder are retrieved, a specific version of a document MAY be returned. If the repository supports version-specific filing, the specific version filed in that folder is returned. If the repository does not support version-specific filing, the latest version or the latest major version of the document is returned.

Likewise, this version sensitivity in child-binding also affects the behavior of parent retrieval for a document object, as well as the scope of the IN_FOLDER() and IN_TREE() function calls in a query. For non-versionable fileable objects, their membership in a folder does not have version sensitivity.

2.1.5.1.2 Filing Restrictions by Object-Type

Because of these filing constraints, when a new folder object is created, an existing folder object MUST be specified as its parent.

When a non-file-able object is created, a parent folder MUST NOT be specified.

When a file-able object is deleted, it is removed from any folder collection in which the object is a member. In other words, when an object is deleted, all implicit parent-child relationships with the deleted object as a child cease to exist.

2.1.5.2 Folder Hierarchy

CMIS imposes the following constraints on folder objects:

• Every folder object, except for one which is called the root folder, MUST have one and only one parent folder. The root folder does not have a parent.
• A cycle in folder containment relationships is not allowed. That is, a folder object cannot have itself as one of its descendant objects.
• A child object that is a folder object can itself be the parent object of other file-able objects.

With these constraints, the folder objects in a CMIS repository necessarily form a strict hierarchy, with the root folder being the root of the hierarchy.

The child objects of a given folder object, their child objects, and grandchild objects, etc., are called descendant objects of the given folder object. A folder object together with all its descendant objects are collectively called a tree rooted at that folder object.

A non-folder object does not have any descendant objects. Thus, a folder graph that consists of all fileable objects as nodes, and all the implicit folder containment relationships as directed edges from parent to child, is a directed acyclic graph, possibly with some disconnected (orphan) nodes. It follows that the tree rooted at any given folder object is also a directed acyclic graph, although a non-folder object in the tree MAY have ancestors that are not ancestors of the rooted folder.

Folder objects are handled using the basic CRUD services for objects, and the folder graph is traversed using the navigation services.

The root folder is a special folder such that it cannot be created, deleted, or moved using CMIS services. Otherwise, it behaves like any other folder object.

2.1.5.3 Paths

A folder hierarchy MAY be represented in a canonical notation such as path. For CMIS, a path is represented by:

• ’/’ for the root folder.
• All paths start with the root folder.
• A set of the folder and object path segments separated by ’/’ in order of closest to the root.
• Folder and object path segments are specified by pathSegment tokens which can be retrieved by all services that take an includePathSegments parameter (for example getChildren).
• A pathSegment token MUST not include a ’/’ character.
  It is repository specific how a repository chooses the value for pathSegment. Repositories might choose to use cmis:name or content stream filename for pathSegment token.
• The pathSegment token for each item MUST uniquely identify the item in the folder.

That is, if folder A is under the root, and folder B is under A, then the path would be /A/B.

A path for an object may be calculated in the following way:

• If the object is the root folder, the path is ’/’.
• If the object is a direct child of the root folder, the path is the object’s pathSegment prefixed by ’/’.
• If the object is not a direct child of the root folder, the path is item’s parent folder cmis:path property appended by ’/’ and the object’s pathSegment.

This constructed path may be given as input to the getObjectByPath service for object by path retrieval.

The getObjectParents service returns relativePathSegment tokens. These tokens are the pathSegment of the input object relative to the parent folders.

2.1.5.4 Folder Object-Type Definition

This section describes the definition of the folder object-type’s attribute values and property definitions which must be present on folder instance objects. All attributes and property definitions are listed by their id.

2.1.5.4.1 Attribute Values

Notes:

• A value of <repository-specific> indicates that the value of the property MAY be set to any valid value for the attribute type.
• Unless explicitly stated otherwise, all values specified in the list MUST be followed for the object-type definition.

id
Value: cmis:folder

localName
Value: <repository-specific>

localNamespace
Value: <repository-specific>

queryName
Value: cmis:folder

displayName
Value: <repository-specific>

baseId
Value: cmis:folder

parentId
Value: MUST NOT be set

description
Value: <repository-specific>

creatable
Value: <repository-specific>

fileable
Value: TRUE

queryable
Value: SHOULD be TRUE

controllablePolicy
Value: <repository-specific>

controllableACL
Value: <repository-specific>

includedInSupertypeQuery
Value: <repository-specific>

fulltextIndexed
Value: <repository-specific>

typeMutability.create
Value: <repository-specific>

typeMutability.update
Value: <repository-specific>

typeMutability.delete
Value: <repository-specific>

2.1.5.4.2 Property Definitions

2.1.6 Relationship Object

A relationship object is semantically a dependent object. A relationship object MUST NOT have a content stream, and MUST NOT be versionable, MAY be queryable, and MUST NOT be fileable, although it MAY be controllable.

If a repository does not support relationship objects, the relationship base object-type SHOULD NOT be returned by a getTypeChildren service call.

A relationship object instantiates an explicit, binary, directional, non-invasive, and typed relationship between a source object and a target object. The source object and the target object MUST both be independent objects, such as a document object, a folder object, a policy object, or an item object. Whether a policy object is allowed to be the source or target object of a relationship object is repository-specific.

The relationship instantiated by a relationship object is explicit since it is explicitly represented by an object and is explicitly managed by application.

This relationship is non-invasive in the sense that creating or removing this relationship SHOULD NOT modify either the source or the target object. That is, it SHOULD NOT require an update capability (or permission) on either object; SHOULD NOT affect the versioning state of either object; and SHOULD NOT change their "Last Modification Date".

Explicit relationships can be used to create an arbitrary relationship graph among independent objects. Such a relationship graph is only structural in nature. No inheritance or transitive properties are attached to a relationship graph.

The notion of a source object and a target object of a relationship is used solely to indicate the direction of the relationship. No semantics or implementation bias is implied by this terminology.

The binding of a relationship object to a source document object or to a target document object MAY be either version-specific or version-independent. This version sensitivity is repository-specific, and is largely transparent to CMIS. An independent object MAY participate in any number of explicit relationships, as the source object for some and as the target object for others. Multiple relationships MAY exist between the same pair of source and target objects.

Referential integrity, either between the source object and the target object, or between the relationship object and the source or target object, is repository-specific. Therefore, creating an explicit relationship between two objects MAY impose a constraint on any of the three objects, and removing a relationship or deleting either the source or the target object MAY be restricted by such a constraint. If the source or the target object of a relationship is deleted, the repository MAY automatically delete the relationship object.

Like all CMIS objects, relationship objects are typed. Typing relationship allows them to be grouped, identified, and traversed by type id, and for properties to be defined for individual relationship types.

Additionally, a relationship object-type MAY specify that only objects of a specific object-type can participate as the source object or target object for relationship objects of that type. If no such constraints are specified, then an independent object of any type MAY be the source or the target of a relationship object of that type.

When a relationship object is created, the source object id and the target object id MUST reference valid non-relationship CMIS objects. When a relationship object is retrieved, its source object or target object MAY no longer exist, since referential integrity MAY not be maintained by a repository.

In addition to object CRUD services, a getObjectRelationships service may be used to return a set of relationship objects in which a given independent object is identified as the source or the target object, according to the binding semantics maintained by the repository (i.e., either a version-specific or a version-independent binding as described above).

2.1.6.1 Relationship Object-Type Definition

This section describes the definition of the relationship object-type’s attribute values and property definitions which must be present on relationship instance objects. All attributes and property definitions are listed by their id.

2.1.6.1.1 Attributes specific to Relationship Object-Types

2.1.6.1.2 Attribute Values

Notes:

• A value of <repository-specific> indicates that the value of the property MAY be set to any valid value for the attribute type.
• Unless explicitly stated otherwise, all values specified in the list MUST be followed for the object-type definition.

id
Value: cmis:relationship

localName
Value: <repository-specific>

localNamespace
Value: <repository-specific>

queryName
Value: cmis:relationship

displayName
Value: <repository-specific>

baseId
Value: cmis:relationship

parentId
Value: MUST NOT be set

description
Value: <repository-specific>

creatable
Value: <repository-specific>

fileable
Value: FALSE

queryable
Value: <repository-specific>

controllablePolicy
Value: <repository-specific>

controllableACL
Value: <repository-specific>

includedInSupertypeQuery
Value: <repository-specific>

fulltextIndexed
Value: <repository-specific>

typeMutability.create
Value: <repository-specific>

typeMutability.update
Value: <repository-specific>

typeMutability.delete
Value: <repository-specific>

allowedSourceTypes
Value: <repository-specific>

allowedTargetTypes
Value: <repository-specific>

2.1.6.1.3 Property Definitions

2.1.7 Policy Object

A policy object represents an administrative policy that can be enforced by a repository. CMIS does not specify what kinds of administrative policies that are specifically supported, nor attempts to model administrative policy of any particular kind. Only a base object-type is specified for policy objects. Each policy object holds the text of an administrative policy as a repository-specific string, which is opaque to CMIS and which may be used to support policies of various kinds. A repository may create subtypes of this base type to support different kinds of administrative policies more specifically. If a repository does not support policy objects, the policy base object-type SHOULD NOT be returned by a getTypeChildren service call. This is an extension point for repositories that want to expose other capabilities via CMIS that are not supported directly in CMIS.

Aside from allowing an application to create and maintain policy objects, CMIS allows an application to "apply" a policy to an object, and to remove an applied policy from an object. An object to which a policy may be applied is called a controllable object. A policy MAY be applied to multiple controllable objects. Conversely, a repository MAY allow multiple policies applied to a controllable object. (A repository may, for example, impose constraints such as only one policy of each kind can be applied to an object.) Whether or not an object is controllable is specified by the object’s type definition. Applying a policy to an object is to place the object under the control of that policy (while the object may also be under the control of other policies at the same time), and removing an applied policy from one of its controlled objects is to remove the corresponding control from that object. This control may change the state of the object, may impose certain constraints on service calls operating on this object, or may cause certain management actions to take place. The effect of this control, when this effect takes place, and how this control interacts with other controls, are repository-specific. Only directly/explicitly applied policies are covered by CMIS. Indirectly applying policy to an object, e.g. through inheritance, is outside the scope of CMIS.

A policy object does not have a content stream and is not versionable. It may be fileable, queryable or controllable. Policy objects are handled using the basic CRUD services for objects. If a policy is updated, the change may alter the corresponding control on objects that the policy is currently applied to. If a controlled object is deleted, all the policies applied to that object, if there are any, are removed from that object. A policy object that is currently applied to one or more controllable objects CAN NOT be deleted. That is, there is an implicit referential constraint from a controlled object to its controlling policy object(s). Besides the basic CRUD services, the applyPolicy and the removePolicy services may be used to apply a policy object to a controllable object and respectively to remove an applied policy from one of its controlled objects. In addition, the getAppliedPolicies service may be used to obtain the policy objects that are currently applied to a controllable object.

2.1.7.1 Policy Object-Type Definition

This section describes the definition of the policy object-type’s attribute values and property definitions which must be present on policy instance objects. All attributes and property definitions are listed by their id.

2.1.7.1.1 Attribute Values

Notes:

• A value of <repository-specific> indicates that the value of the property MAY be set to any valid value for the attribute type.
• Unless explicitly stated otherwise, all values specified in the list MUST be followed for the object-type definition.

id
Value: cmis:policy

localName
Value: <repository-specific>

localNamespace
Value: <repository-specific>

queryName
Value: cmis:policy

displayName
Value: <repository-specific>

baseId
Value: cmis:policy

parentId
Value: MUST NOT be set

description
Value: <repository-specific>

creatable
Value: <repository-specific>

fileable
Value: <repository-specific>

queryable
Value: <repository-specific>

controllablePolicy
Value: <repository-specific>

controllableACL
Value: <repository-specific>

includedInSupertypeQuery
Value: <repository-specific>

fulltextIndexed
Value: <repository-specific>

typeMutability.create
Value: <repository-specific>

typeMutability.update
Value: <repository-specific>

typeMutability.delete
Value: <repository-specific>

2.1.7.1.2 Property Definitions

2.1.8 Item Object

The item object is an extension point for repositories that want to expose other object types via CMIS that do not fit the definition for document, folder, relationship or policy. For example an independently persistable collection of properties that was not versionable and did not have content. Another example could be a base identity object for users and groups.

A repository may create subtypes of this base type to support different kinds of generic base objects more specifically. If a repository does not support item objects, the item base object-type SHOULD NOT be returned by a getTypeChildren service call. Like the other CMIS objects (folder, policy and relationship), item objects are not versionable and do not have content. Item objects are manipulated with the basic CRUD operations as well as with query if the repository has them marked as queryable.

2.1.8.1 Item Object-Type Definition

This section describes the definition of the item object-type’s attribute values and property definitions which must be present on item instance objects. All attributes and property definitions are listed by their id.

2.1.8.1.1 Attribute Values

Notes:

• A value of <repository-specific> indicates that the value of the property MAY be set to any valid value for the attribute type.
• Unless explicitly stated otherwise, all values specified in the list MUST be followed for the object-type definition.

id
Value: cmis:item

localName
Value: <repository-specific>

localNamespace
Value: <repository-specific>

queryName
Value: cmis:item

displayName
Value: <repository-specific>

baseId
Value: cmis:item

parentId
Value: MUST NOT be set

description
Value: <repository-specific>

creatable
Value: <repository-specific>

fileable
Value: <repository-specific>

queryable
Value: <repository-specific>

controllablePolicy
Value: <repository-specific>

controllableACL
Value: <repository-specific>

includedInSupertypeQuery
Value: <repository-specific>

fulltextIndexed
Value: <repository-specific>

typeMutability.create
Value: <repository-specific>

typeMutability.update
Value: <repository-specific>

typeMutability.delete
Value: <repository-specific>

2.1.8.1.2 Property Definitions

2.1.9 Secondary Object-Types

A secondary type defines a set of properties that can be dynamically added to and removed from objects. That is, an object can get and lose additional properties that are not defined by its primary type during its lifetime. Multiple secondary types can be applied to the same object at the same time.

Secondary types can be simple markers without properties. Alternatively, they can contain technical information about an object. For example, a repository might analyze the content of a document, detects a photo and adds a secondary type that adds EXIF data to the document. Applications might want to attach temporary data to an object such the state of the object in a workflow. Secondary types may also change the behaviour of the repository.

The CMIS specification does not define the semantics of secondary types with the exception of secondary types for retentions and holds (see section 2.1.16 Retentions and Holds). CMIS provides a way to apply and remove secondary types to/from an object. Additionally, CMIS provides an optional ability to create, update and remove secondary types.

If a repository does not support secondary types, the secondary type base object-type cmis:secondary SHOULD NOT be returned by a getTypeChildren service call.

The base object-type does not specify any property definitions and its sole purpose is to be the root type of all other secondary object-types. Repositories MAY provide property definitions on the base type that are then inherited by other secondary object-types.

Secondary types can be applied to and removed from an object at any time. An object MAY have zero or more secondary types assigned to it. When a secondary type is applied, the object provides the properties that are defined by the secondary type. When a secondary type is removed, it loses these properties and its values.

A repository MAY not allow applying or removing certain secondary object-types to certain objects based on rules that are not determined in this specification. The repository SHOULD throw a constraint exception if such an operation is not allowed. Secondary object-types CAN NOT be used as primary object-types. That is, when an object is created, its object-type has to be either one of the other base types or an object-type that is derived from the other base types. Hence, a secondary object-type MUST NOT be creatable.

Whether an object is fileable, versionable or controllable is determined by its primary object-type.

2.1.9.1 Secondary Type Application

Secondary types can be applied at creation time by populating the multi-value property cmis:secondaryObjectTypeIds with the ids of the secondary types. All properties defined by these secondary types can be set as well.

Secondary types can be added and removed later by changing the cmis:secondaryObjectTypeIds property, either through the updateProperties service or the checkIn service. Adding the id of a secondary type to this multi value property adds the secondary type. Removing the id of a secondary type from this multi value property removes the type and all associated properties and values.

A repository MUST throw a constraint exception if a secondary type cannot be added or removed.

Adding a secondary type and providing values for the associated properties of this secondary type MAY be done in the same operation.

2.1.9.2 Secondary Object-Type Definition

This section describes the definition of the secondary object-type’s attribute values. All attributes are listed by their id.

2.1.9.2.1 Attribute Values

Notes:

• A value of <repository-specific> indicates that the value of the property MAY be set to any valid value for the attribute type.
• Unless explicitly stated otherwise, all values specified in the list MUST be followed for the object-type definition.

id
Value: cmis:secondary

localName
Value: <repository-specific>

localNamespace
Value: <repository-specific>

queryName
Value: cmis:secondary

displayName
Value: <repository-specific>

baseId
Value: cmis:secondary

parentId
Value: MUST NOT be set

description
Value: <repository-specific>

creatable
Value: FALSE

fileable
Value: FALSE

queryable
Value: <repository-specific>

controllablePolicy
Value: FALSE

controllableACL
Value: FALSE

includedInSupertypeQuery
Value: <repository-specific>

fulltextIndexed
Value: <repository-specific>
Note: This attribute defines if the properties of this secondary type are full-text indexed. It does not make a statement about the content.

2.1.9.2.2 Property Definitions

2.1.10 Object-Type Creation, Modification and Deletion

A repository MAY support the creation, modification and deletion of primary and secondary object-types.

Each object-type definition SHOULD include a set of flags that indicate if the object-type can be used as a parent type or if the object-type can be modified or deleted. Please see section 2.1.3.2.1 Attributes common to ALL Object-Type Definitions for details.

These flags are not to be interpreted as the rights for the current user. These are the rights that would apply to an administrator user or a user that has sufficient rights to modify metadata. For example, a non-administrator would see that an object-type is extendable (the type mutability capabilities create flag is set to TRUE) even though they would not be allowed to actually perform the operation. If a user tries to create, modify or delete a type definition and does not have the required permissions, the repository MUST return a permissionDenied error.

A repository MAY also place additional restrictions on these operations where necessary. These restrictions are repository specific.

2.1.10.1 General Constraints on Metadata Changes

The optional capabilities capabilityNewTypeSettableAttributes and capabilityCreatablePropertyTypes SHOULD indicate which object-type attributes can be set by a client and which properties data types can be used to create or extend an object-type.

Note, that the client CANNOT define whether a new object-type can be used as a parent type, or can be updated or deleted. How the repository determines a given object-type’s mutability capabilities is repository specific.

When an object-type is created the client MUST suggest a type id for the new object-type. The repository may do the following with this suggested value:

• Use it exactly as specified.
  e.g. input = invoice : returned value = invoice
• Modify it with the addition of a prefix, suffix or both.
  e.g. input = invoice : returned value = invoice_FAF5D0C5-BBE9
• Return a completely different value.
  e.g. input = invoice : returned value = FAF5D0C5-BBE9-4E47-BB17-C9FE63B4EE20

When a property definition is created the client MUST suggest a property definition id for the new property. The repository may do the following with this suggested value:

• Use it exactly as specified.
  e.g. input = amount : returned value = amount
• Modify it with the addition of a prefix, suffix or both.
  e.g. input = amount: returned value = amount_12AB
• Return a completely different value.
  e.g. input = amount: returned value = 12AB-23CD

When an object-type is created or updated, the repository MUST return the created or updated type definition whereby the order of ALL newly created property definitions MUST match the order of the input. This is so that there will be no ambiguity for clients who need to know which property matches a specific suggested Id value for a new property definition. This special ordering is only required for the return value for createType and updateType. There is no special ordering of the properties returned for subsequent calls to getTypeDefinition for this new or modified type.

When an object-type is updated the following rules MUST be obeyed:

• Inherited properties MUST NOT be modified. This includes constraints of any kind.
• Properties defined by the CMIS specification MUST NOT be modified. This includes constraints of any kind.
• Only leaf types may be modified. That is, if a type already has child types defined then it (and all of its properties and constraints) MUST be considered read only.
• Any added properties marked as "required" MUST have a default value.
• Required properties MAY be changed to optional.
• Optional properties MUST NOT be changed to required.
• Property definitions MUST NOT be removed.
• Property choice constraints MAY be changed in the following manner:
  • ’Open choice’ MAY change from FALSE to TRUE.
  • ’Open choice’ MUST NOT change from TRUE to FALSE.
  • Choices MAY be added or removed if ’open choice’ is TRUE.
  • Choices MUST NOT be removed if ’open choice’ is FALSE.
• Validation constraints (min/max length, min/max value, etc.) on existing properties MAY be relaxed but they MUST NOT be further restricted. For example, an integer property value that originally had a minimum constraint of 100 and a maximum constraint of 1000 could change as follows:
  • A new minimum could be changed to 50 but could not be changed to 150.
  • A new maximum could be changed to 1100 but could not be changed to 900.

  This ensures that the new constraints will not leave any existing data out of the permitted constraint range.

• An existing property type’s data type and cardinality MUST NOT be changed. For example, an Integer property type MUST NOT be changed to a String.

The execution of the createType and updateType services MUST not affect the definition of any other types or any other type’s current property definitions. For example, any properties on the type being created must not place constraints on other type’s properties when/if other properties ’share’ property definitions.

An object-type can only be deleted if there are no objects of this type and the object-type has no sub-types. The deleteType service MUST return a constraint error if an instance of the object-type exists or the object-type is a parent type of another object-type.

2.1.11 Object-Type Summary

The following diagrams illustrate the CMIS object model. Please note that they only reflect the logical model. The CMIS bindings use slightly different data structures.

2.1.12 Access Control

A repository can support either a base set of CMIS-defined permissions and/or its own set of repository specific permissions.

The getACL service allows the requestor to specify that the result be expressed using only the CMIS defined permissions. Without this restriction, the response may include, or be solely expressed in repository specific permissions. The applyACL service permits either CMIS permissions or repository permissions, or a combination of both, to be used.

2.1.12.1 ACL, ACE, Principal, and Permission

An Access Control List (ACL) is a list of Access Control Entries (ACEs) and MAY hold zero or more ACEs. If an ACL has no ACEs, the behavior is the same as if the ACL is not set.

An ACE holds:

• A principal that represents a user management object, e.g. a user, group, or role. It holds one string with the principalId.
• One or more strings with the names of the permissions.
• A boolean flag direct which indicates if TRUE that the ACE is directly assigned to the object. If FALSE, that the ACE is somehow derived or inherited.

2.1.12.2 CMIS Permissions

There are three basic permissions predefined by CMIS:

cmis:read

Expresses the "permission to read" properties AND content of an object.

cmis:write

Expresses the "permission to write" properties AND content of an object. It MAY include the cmis:read permission.

cmis:all

SHOULD express all the permissions of a repository. It SHOULD include all other basic CMIS permissions.

How these basic permissions are mapped to the allowable actions is repository specific. However, the actual repository semantics for the basic permissions with regard to allowable actions can be discovered by the mappings parameter returned by the getRepositoryInfo service.

Repositories MAY extend this set with repository-specific permissions.

2.1.12.3 ACL Capabilities

Whether a repository supports ACLs at all, may be discovered via capabilityACL attribute returned by the getRepositoryInfo service (see section 2.1.1.1 Optional Capabilities). If the value of the capabilityACL attribute is none, ACLs are not supported by the repository.

If the value of the capabilityACL attribute is discover or manage, additional information about the repository’s permission model and how ACL modifications are handled are provided by the getRepositoryInfo service:

Enum propagation

specifies how non-direct ACEs can be handled by the repository using the following values (see section 2.2.10.1 applyACL):

objectonly

indicates that the repository is able to apply ACEs to an object without changing the ACLs of other objects.

propagate

indicates that the ACEs might be inherited by other objects. propagate includes the support for objectonly.

repositorydetermined

indicates that the repository has its own mechanism of computing how changing an ACL for an object influences the non-direct ACEs of other objects.

<Array> PermissionDefinition repositoryPermissions

A list of names and descriptions of the supported permissions.

<Array> PermissionMapping mappings

Contains a list of basic CMIS permissions to allowable actions mapping.

2.1.12.3.1 Supported Permissions

A PermissionDefinition holds:

String permission

The (technical) name of the permission. Permission names MUST be unique within the permission definition list.

String description

An optional description of the permission that SHOULD be used as the permission’s name to be presented to the user.

2.1.12.3.2 AllowableActions and Permission Mapping

The set of allowable actions on an object at a point in time are affected not only by CMIS ACLs, but also by other factors such as:

• Constraints inherent in the CMIS Domain Model based on the object’s base type or current versioning state.
• Policies or other control mechanisms that are opaque to CMIS.

CMIS defines several services that applications can use at run-time to discover the allowable actions for an object.

If a repository supports ACLs, then the repository MUST provide a mapping table that defines how the permissions supported by the repository interact with the CMIS allowable actions, i.e. which permissions are necessary for a principal to have on one or more objects in order to potentially perform each action, subject to the other constraints on allowable actions mentioned above.

This section defines both the allowable actions as well as how those actions are presented in the permission mapping table.

The permission mapping table contains a set of key–permissions pairs:

String key

Since several allowable actions require permissions on more than one object, the mapping table is defined in terms of permission "keys". (For example, moving a document from one folder to another may require permissions on the document and each of the folders.) Each key combines the name of the allowable action and the object for which the principal needs the required permission.
For example, the canMoveObject.Source key indicates the permissions that the principal must have on the "source folder" to move an object from that folder into another folder.

<Array> String permissions

The name of one or more permissions that the principal MUST have. If more than one permission is specified, then the principal MUST be allowed to perform the operation if they have ANY of the listed permissions.

The following list defines all mapping keys, as well as a permissions mapping that repositories SHOULD use. Repositories MAY require additional permissions.

For convenience, the list groups all mapping entries by the underlying allowable actions, and includes descriptive information. For each allowable action the following information is given:

Description

The description and name of the service the allowable action enables.

Base Type

The base object-types for which the allowable action MAY be TRUE.

Operand

The object the permission applies to.

Key

The permission mapping key.

Permissions

The permission values.

2.1.12.3.2.1 Navigation Services

2.1.12.3.2.2 Object Services