CMIS Specification Section 2. Domain Model presents the CMIS Data Model (Repository, Object, Object-Type, Document Object, Folder Object, Relationship Object, Policy Object, Access Control, Versioning, Query, and Change Log) and CMIS Services (Common Service Elements, Repository Services, Navigation Services, Object Services, Multi-filing Services, Discovery Services, Versioning Services, Relationship Services, Policy Services, and ACL Services).

"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 'Get Repositories' service (getRepositories) to obtain a list of repositories that are available at that endpoint. The Repository Identity MUST uniquely identify an available repository at this service endpoint. Both the repository name and the repository identity are opaque to CMIS. Aside from the 'Get Repositories' service, all other CMIS services are single-repository-scoped, and require a Repository Identity as an input parameter. In other words, except for the 'Get Repositories' service, multi-repository and inter-repository operations are not supported by CMIS..."

From Section 2.1.2 Object

"The entities managed by CMIS are modeled as typed Objects. There are four base types of objects: Document Objects, Folder Objects, Relationship Objects, and Policy 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 and document 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 directional relationship between two objects. The support for relationship objects is optional, and may be discovered via the 'Get Type Children' service.
• 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, and may be discovered via the 'Get Type Children' service.

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. However, object-type management services, such as the creation, modification, and deletion of an object-type, are outside the scope of CMIS.

Every CMIS object has an opaque and immutable Object Identity (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.

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.

Document or folder objects MAY have one Access Control List (ACL), which controls access to the document or folder. A policy object may also control access to the document or folder. 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 Specification Section 3 presents the Restful AtomPub Binding, based upon the Atom (The Atom Syndication Format — IETF RFC 4287) and [The] Atom Publishing Protocol (RFC 5023). Implementations of CMIS MUST be compliant with RFC 4287 and RFC 5023.

"In this binding, the client interacts with the repository by acquiring the service document. The client will request the service document by the URI provided by the vendor. The client will then choose a CMIS collection, and then start accessing the repository by following the references in the returned documents.

This binding consists of a service document specifying at least CMIS service collections, atom collections, feeds and entry documents. CMIS extends the Atom and AtomPub documents utilizing the Atom and AtomPub extension mechanism. CMIS also leverages link tags to specify additional resources related to the requested resource. When requesting a resource, optional parameters may be specified to change default behavior via query parameters..."

Note: Atom, as defined in IETF RFC 4287, is an XML-based document format that describes lists of related information known as 'feeds'. Feeds are composed of a number of items, known as 'entries', each with an extensible set of attached metadata. For example, each entry has a title. The primary use case that Atom addresses is the syndication of Web content such as weblogs and news headlines to Web sites as well as directly to user agents." The Atom Publishing Protocol (AtomPub), as defined in RFC 5023 "is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format."

Specification Section 3.4.3 presents "CMIS Link Relations." These CMIS link relation types are used in addition to the link relations specified by Atom and Atom Publishing Protocol; see the IANA registry for Atom Link Relations e.g., alternate, current, describedby, edit, edit-media, enclosure, first, last, license, next, next-archive, payment, prev-archive, previous, related, replies, self, service, up, via. Certain 'Hierarchy Navigation Internet Draft Link Relations' are taken from the IETF Internet Draft Hierarchy Relations for Atom: up and down. Three 'Versioning Internet Draft Link Relations' are taken from the I-D Link Relations for Simple Version Navigation: version-history, current-version, working-copy.

In addition, several 'CMIS Specific Link Relations' are defined:

• http://docs.oasis-open.org/ns/cmis/link/200908/allowableactions — this link relation MUST point to a resource containing a CMIS AllowableActions document for the CMIS resource containing this link relation, with Media Type application/cmisallowableactions+xml
• http://docs.oasis-open.org/ns/cmis/link/200908/relationships — this link relation MUST point to a resource containing an Atom Feed of CMIS relationship resources for the CMIS resource containing this link relation, with Media Type application/atom+xml;type=feed
• http://docs.oasis-open.org/ns/cmis/link/200908/source — when used on a CMIS Relationship resource, this link relation MUST point to an atom entry document for the CMIS Resource specified by the cmis:sourceId property on the relationship, with Media Type application/atom+xml;type=entry
• http://docs.oasis-open.org/ns/cmis/link/200908/target — when used on a CMIS Relationship resource, this link relation MUST point to an atom entry document for the CMIS Resource specified by the cmis:targetId property on the relationship, with Media Type application/atom+xml;type=entry
• http://docs.oasis-open.org/ns/cmis/link/200908/policies — this link relation MUST point to a resource containing an Atom Feed of CMIS Policy resources for the CMIS resource containing this link relation, with Media Type application/atom+xml;type=feed
• http://docs.oasis-open.org/ns/cmis/link/200908/acl — this link relation MUST point to a resource containing a CMIS ACL document for the CMIS resource containing this link relation, with Media Type application/cmisacl+xml
• http://docs.oasis-open.org/ns/cmis/link/200908/changes — this link relation MUST point to an Atom Feed containing the set of changes, with Media Type application/atom+xml;type=feed
• http://docs.oasis-open.org/ns/cmis/link/200908/foldertree — used in AtomPub Service Document to identify the folder tree for a specified folder, with Media Type application/atom+xml;type=feed
• http://docs.oasis-open.org/ns/cmis/link/200908/typedescendants — used in AtomPub Service Document to identify the base types descendants, with Media Type application/atom+xml;type=feed
• http://docs.oasis-open.org/ns/cmis/link/200908/rootdescendants — used in AtomPub Service Document to identify the root folder descendants, with Media Type application/atom+xml;type=feed

CMIS Specification Section 4 presents the Web Services Binding. "All services and operations defined in part I of the CMIS specification are presented in this Web Services binding. The WSDL for these services reference two XSD documents. One [CMIS-Core] defines elements for the primary data types of documents, folders, relationships, and policies as well as collections of these types of objects. The second XSD [CMIS-Messaging] defines the message formats for each of the CMIS services; the messages often refer to the data types defined in the first XSD schema. The WSDL presents exactly the abstract services defined in the services section of Part I of the CMIS specification.

The normative CMIS Web Services binding is defined by the WSDL and XSD as well as the details given here in this part of the CMIS specification except the examples.

WS-I: A CMIS Web Services binding MUST comply with WS-I Basic Profile 1.1 [which provides interoperabilty guidance for basic SOAP messaging for Web services] and WS-I Basic Security Profile 1.0 [which provides guidance on the use of WS-Security and the REL, Kerberos, SAML, UserName and X.509 security token formats].

Authentication: A CMIS Web Services binding SHOULD support WS-Security 1.1 for Username Token Profile 1.1 and MAY also support other authentication mechanisms. A CMIS repository MAY grant access to all or a subset of the CMIS services to unauthenticated clients.

Content Transfer: A CMIS Web Services binding SHOULD support MTOM [SOAP Message Transmission Optimization Mechanism] content transfers. It MUST accept content that is base64 encoded.

Reporting Errors: Services MUST report errors via SOAP faults. The CMIS-Messaging.xsd defines a basic fault structure that includes an error code and an error message and the WSDL for each service defines specific messages that have the basic fault format.

Web Services Binding Mapping: The Domain Model in Part I of the CMIS specification defines all services, operations, parameters and objects of CMIS. The Web Services binding is an exact one-to-one mapping of this definition with small exceptions that are explained in the next section. Operations and parameters are named exactly after their counterparts in Part I. All rules and exceptions defined in Part I apply to the Web Services binding. Optional parameters and optional return values are not set if they are missing or their value is NULL..."

CMIS Specification Section 5 IANA Considerations declares IANA Content-Type Registration for several MIME media types/subtypes used by CMIS:

• CMIS Query: A CMIS Query Document, when serialized as XML 1.0, can be identified with the media type application/cmisquery+xml, using a file extension .cmisquery
• CMIS AllowableActions: A CMIS Allowable Actions Document, when serialized as XML 1.0, can be identified with the media type application/cmisallowableactions+xml, using a file extension .cmisallowableactions
• CMIS Tree: A CMIS Tree Document, when serialized as XML 1.0, can be identified with the media type application/cmistree+xml, using a file extension .cmistree
• CMIS Atom: A CMIS Atom Document, when serialized as XML 1.0, can be identified with the media type application/cmisatom+xml, using a file extension .cmisatom
• CMIS ACL: A CMIS ACL Document, when serialized as XML 1.0, can be identified with the media type application/cmisacl+xml, using a file extension .cmisacl

CMIS Specification Section 6 Conformance was drafted to satisfy the requirments of the OASIS TC Process, Section 2.18 Specification Quality: "A specification that is approved by the TC at the Public Review Draft, Committee Specification or OASIS Standard level must include a separate section, listing a set of numbered conformance clauses, to which any implementation of the specification must adhere in order to claim conformance to the specification (or any optional portion thereof)..."

CD 04: An implementation of CMIS "conforms to this specification if it satisfies all of the MUST or REQUIRED level requirements defined within this specification. Specification: This specification references a number of other specifications (see the table). In order to comply with this specification, an implementation MUST implement the portions of referenced specifications necessary to comply with the required provisions of this specification. Additionally, the implementation of the portions of the referenced specifications that are specifically cited in this specification MUST comply with the rules for those portions as established in the referenced specification. An implementation conforms to this specification if it satisfies all of the MUST or REQUIRED level requirements defined within this specification...

Domain Model: Normative text within this specification takes precedence over the CMIS Core XML Schema. That is, the normative text in this specification further constrains the schemas and/or WSDL that are part of this specification; and this specification contains further constraints on the elements defined in referenced schemas... [For] Clients: Client implementations MAY implement either Restful AtomPub Binding or the Web Services Binding. [For] Repositories: Repositories MUST implement the following CMIS protocol bindings: (1) Restful AtomPub Binding, (2) Web Services Binding...

Rest Binding: This specification references a number of other specifications. In order to comply with this specification, an implementation MUST implement the portions of referenced specifications necessary to comply with the required provisions of this specification. Additionally, the implementation of the portions of the referenced specifications that are specifically cited in this specification MUST comply with the rules for those portions as established in the referenced specification. Additionally normative text within this specification takes precedence over the CMIS RestAtom XML Schema. That is, the normative text in this specification further constrains the schemas and/or WSDL that are part of this specification; and this specification contains further constraints on the elements defined in referenced schemas. The CMIS RestAtom XML takes precedence over any examples or non-normative outlines included either in this document or as standalone examples...

Web Services Binding: Normative text within this specification takes precedence over the CMIS Messaging XML and CMIS WSDL. That is, the normative text in this specification further constrains the schemas and WSDL that are part of this specification; and this specification contains further constraints on the elements defined in referenced schemas. The CMIS Messaging XML and CMIS WSDL takes precedence over any examples or non-normative outlines included either in this document or as standalone examples..."