The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
Advanced Search
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

Cover Stories
Articles & Papers
Press Releases

XML Query

XML Applications
General Apps
Government Apps
Academic Apps

Technology and Society
Tech Topics
Related Standards
Created: October 30, 2009. Modified: November 11, 2009.
News: Cover StoriesPrevious News ItemNext News Item

OASIS Public Review: Content Management Interoperability Services (CMIS) v1.0.


On October 23, 2009, OASIS announced that the Content Management Interoperability Services (CMIS) Technical Committee had approved a Committee Draft of the Content Management Interoperability Services (CMIS) Version 1.0 specification and released it for public review through December 22, 2009. Feedback in the form of comments and implementation reports is now invited from potential users, developers, and all others, for the sake of improving interoperability and quality of this OASIS technical work.

The Content Management Interoperability Services (CMIS) standard "defines a domain model along with Web Services and Restful AtomPub bindings that can be used by applications to work with one or more Content Management repositories/systems. 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."

The CMIS specification of "23 September 2009" approved for public review as "Committee Draft 04" combines into one document the content from documents previously published as separate parts. The initial CMIS Version 0.5 (2008) consisted of separate documents: CMIS Part I: Introduction, General Concepts, Data Model, and Services; CMIS Part II: REST Protocol Binding, CMIS Part II: SOAP Protocol Binding; and CMIS Appendices: Open Issues, Informative Examples, and Important Decisions.

Formal work on standardization of CMIS began with the Technical Committee Call for Participation on October 6, 2008. The chartered work was based upon a contribution of draft version 0.5 from EMC Corporation, IBM Corporation, and Microsoft Corporation. On September 10, 2008, the three companies announced "a jointly developed specification that uses Web Services and Web 2.0 interfaces to enable applications to interoperate with multiple Enterprise Content Management (ECM) repositories by different vendors", with a declaration of intent to submit the CMIS specification to OASIS for advancement through its standards development process.

The ultimate goal of CMIS, according to the early announcement, is to "dramatically reduce the IT burden around multivendor, multirepository content management environments. Currently, customers must spend valuable time and money to create and maintain custom integration code and one-off integrations to get different ECM systems within their organizations to "talk" to one another. The specification will also benefit independent software vendors (ISVs) by enabling them to create specialized applications that are capable of running over a variety of content management systems. Working together since late 2006, the three companies were joined in the creation of the CMIS draft specification by other leading software providers including: Alfresco Software, Open Text, Oracle and SAP. A final gathering of all seven companies was recently held to validate interoperability of the specification before submission to OASIS..."

Since standardization work began on CMIS in Q3 2008, numerous plug-fest and interoperability events have been held to test prototype implementations and discover (potential) ambiguities in the specification. Draft versions of the CMIS specification are now supported in commercial and open-source software from several companies.

As of October 30, 2009, the CMIS technical work has received broad support through TC participation, industry analyst opinion, and declarations of interest from major companies. Some of these include Adobe, Adullact, AIIM, Alfresco, Amdocs, Anakeen, ASG Software Solutions, Booz Allen Hamilton, Capgemini, Citytech, Content Technologies, Day Software, dotCMS, Ektron, EMC, ESoCE-NET, Exalead, FatWire, Fidelity, Flatirons, fme AG, Genus Technologies, Greenbytes GmbH, Harris, IBM, KnowledgeTree, Lexmark, Liferay, Magnolia, Mekon, Microsoft, Nuxeo, Open Text, Oracle, Pearson, Quark, RSD, SAP, Saperion, Structured Software Systems (3SL), Sun Microsystems, Tanner AG, TIBCO Software, Vamosa, and Vignette. Early commentary from industry analysts and software engineers is positive about the value proposition in standardizing an enterprise content-centric management specification.

Bibliographic Information

Content Management Interoperability Services (CMIS) Version 1.0. Committee Draft 04, approved for Public Review. 23-September-2009. 226 pages. Edited by Al Brown (IBM), Ethan Gur-Esh (Microsoft), Ryan McVeigh (Oracle), and Florian Müller (OpenText). Produced by members of the OASIS Content Management Interoperability Services (CMIS) Technical Committee, under TC Chair David Choy (EMC).

Specification resources:

CMIS Specification XML Namespace URIs

Particiants. Acknowledged CMIS TC members as participants in specification development: Philippe Allart (Adullact), Florian Bartels (fme AG), Fred Boiscuvier (Exalead Inc), Al Brown (IBM), Jay Brown (IBM), Mark Carlson (Sun Microsystems), Derek Carr (IBM), David Caruana (Alfresco Software), Eric Chan (Oracle Corporation), Sameer Charles (Magnolia International AG), David Choy (EMC Corporation), Scott Conroy (Individual), Cornelia Davis (EMC Corporation), Kevin Dorr (Flatirons Solutions Corporation), Betsy Fanning (AIIM), Steffen Frederiksen (Content Technologies ApS), Stephan Friedl (Quark), Dustin Friesenhahn (Microsoft Corporation), Gary Gershon (Individual), Paul Goetz (SAP AG), Gregory Grefenstette (Exalead Inc.), Florent Guillaume (Nuxeo), Ethan Gur-esh (Microsoft Corporation), Martin Hermes (SAP AG), Jens Huebel (Open Text Corporation), David Izatt (Structured Software Systems Limited - 3SL), Gershon Janssen (Individual), Volker John (Saperion AG), Shane Johnson (Citytech Inc.), Christophe Kijewska (Adullact), Ijonas Kisselbach (Vamosa), Mark Klamerus (Individual), Stephan Klevenz (SAP AG), Boris Kraft (Magnolia International AG), Alison Macmillan (Oracle Corporation), Michael Marth (Day Software), Ryan McVeigh (Oracle Corporation), Juerg Meier (fme AG), Gregory Melahn (IBM), Pat Miller (Microsoft Corporation), Florian Mueller (Open Text Corporation), Thomas Mueller (Day Software), John Newton (Alfresco Software), David Nuescheler (Day Software), Dominique Pfister (Day Software), Peeter Piegaze (Day Software), David Pitfield (Oracle Corporation), Norrie Quinn (EMC Corporation), Craig Randall (Adobe Corporation), Celso Rodriguez (ASG Software Solutions), Steve Roth (Oracle Corporation), Patrick Ryan (IBM), Angela Schreiber (Day Software), Spencer Shearer (Exalead Inc), Madi Solomon (Pearson PLC), Wojciech Specht (fme AG), Maik Uhlenberg (fme AG), Oliver Walthard (Day Software), and Patrick Ward (Booz Allen Hamilton.

Specification Excerpts

The following excerpts, adapted from the CD 04 CMIS specification text, are intended to provide an overview of selected features. In no case should this text be used or referenced as official: it is not.

CMIS Domain Model

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..."

Restful AtomPub Binding for CMIS

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:

Web Services Binding

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..."

IANA Considerations

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 Conformance

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..."

Blogs and Commentary

  • [December 02, 2009] "Advanced CMIS." By Florent Guillaume. From Nuxeo Developers Blog.

    "The upcoming CMIS standard is approaching its final 1.0 version... time to present some of its most advanced features. As to basics, I mention quickly for completeness: CMIS stores folders, documents and relationship — collectively called objects; each object has a unique id; objects have 'object types' detailing the properties they're allowed to have; properties have the usual basic 'property types' — strings, numbers, dates, lists, etc; you can create, retrieve, update and delete objects — CRUD; documents may have an associated content stream — an attachment; you can search documents using a SQL-based language; clients talk to CMIS servers using AtomPub or SOAP.


    Below I will detail the more advanced features of CMIS. (1) Unfiling, Multi-filing: While most people are used to storing documents inside a navigation tree, where the intermediate tree nodes are folders, there are other ways to deal with content, which CMIS exposes through the concepts of 'unfiling' and 'multi-filing' — the term 'filing' expresses the idea that a document is stored in a place, much like in the real world. The first alternative way of storing a document is to not file it anywhere: the document is not held in a folder, it just exists: it is then said to be unfiled. This model of unfiled documents is quite common in the world of record management, where what is important is the 'record' (the content and metadata), and not a folder in which it may live. The record itself carries all the metadata you need to find it (dates, keywords, tags, etc.)... The second alternative way provided by CMIS to store a document is to allow it to live in several folders at the same time: this is called multi-filing... (2) Renditions: A rendition is an alternate way of viewing or representing a master document. For instance from an OpenDocument file you may derive a PDF rendition, a 100x140 pixels image rendition of the cover page, a Microsoft Word rendition, a rendition as a series of high-resolution images for each page, an HTML rendition, a pure text rendition... CMIS exposes a way to discover and retrieve renditions; documents and folders can both have renditions, each rendition being seen as an alternate content stream....

    (3) Versioning: In CMIS a document (if its type supports it) can be versioned, which means that 'old' versions are retained by the system. A version can be 'major' or not, but CMIS doesn't impose any semantics on this, it's just a useful abstraction. To create new versions, a model of checkin/checkout is used: after checkout from a version, a private working copy (PWC) is created, which can be modified and then checked back in, creating a new version... In the most complete scenario, the repository allows read and write access to all versions, including the PWC, and allows all versions and the PWC to be searched. The versions can also be filed independently in the same (or different) folders, several versions being then accessible at the same time. (4) Security through ACLs: a basic (and optional) set of permission management operations has been defined in CMIS, based on access control lists (ACLs). The ACL on a document is a list of basic assignment of permissions to users, defining what they can do on this document. CMIS defines three basic permissions: Read, Write, and All. It's up to each repository to define exactly the semantics of these permissions.. The CMIS repository exposes exactly what individual CMIS operations are allowed for each of these permissions. A repository can also define additional non-standard permissions... Optionally, a repository may allow a client to not only check but also change the ACL on a document... (5) Change Log: CMIS has an (optional) change log service that can be queried to discover the past operations that have been done in the repository after a specified date. The change log service returns a list of basic operations that have happened in the repository: object creation, modification or deletion, as well as security changes on an object..."

  • [November 09, 2009] "CMIS Management Interoperability Services (CMIS) — Public Review of Version 1.0 Begins." By Ethan Gur-esh. From Microsoft Enterprise Content Management (ECM) Team Blog. "[In May 2006] my counterparts at IBM and EMC and I started discussing the need to form a group to create an open services standard for interacting with Enterprise Content Management systems (like SharePoint, IBM FileNet P8, EMC Documentum, etc.) in a uniform way. An earlier blog post explained the full rationale — but in short many customers and partners made it apparent that having to create one-off 'connectors' between each application (like eDiscovery applications, Portals or Business Process Management systems) and ECM system was making it hard for customers to use more than one ECM system and for partners to build great applications that could 'just work' with whatever systems a customer is using... To truly make it simple for ECM systems to interoperate, we need a standard set of ECM interoperability interfaces; that way, every system could support the same interfaces and they could work together without the need for special purpose 'connectors' between each pair of systems. And that's exactly what the CMIS standards effort attempts to define... And now, after working with many other vendors like Alfresco, Nuxeo, OpenText, Oracle, SAP, and others on the CMIS specification, forming a Technical Committee at OASIS to deliver that specification as a truly open standard, and having four 'plug-fest' events where we've tested actual (prototype) implementations of the spec together to make sure it would work in the real-world — I'm thrilled to announce that on October 23, 2009, Version 1.0 of the CMIS specification entered OASIS' public review process...

    At this point, pretty much every vendor in the ECM space is really motivated to start supporting CMIS in their respective products... For Microsoft's part, we announced at the ARMA 2009 Conference and at our own SharePoint Conference in the last two weeks that we are planning to deliver support for CMIS within SharePoint 2010... Until the CMIS 1.0 specification is final, we can't realistically commit to exact dates when our CMIS support would be ready. This means that our plans need to be flexible to balance the following needs: (1) Not rushing the finalization of the CMIS 1.0 specification in a way that would compromise its quality, and (2) Releasing CMIS support as soon as possible for SharePoint 2010 that meets the interoperability needs of our customers and partners..."

  • See also: Commentary in the main CMIS reference document

Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation


XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Bottom Globe Image

Document URI:  —  Legal stuff
Robin Cover, Editor: