CMIS and Moreq2010: Good Match Or Just Overlap?

Overview

CMIS deals with accessing content in repositories for Enterprise Content Management and given that it tries to cover a broad spectrum of different kinds of repositories. One of the design goals was the capability of exposing existing functionality without the need for changing the underlying implementation.  CMIS has built-in flexibility and mechanisms to discover the set of available features. You can even implement CMIS on top of a traditional file system. MoReq2010 on the other side is much more specific in scope. MoReq2010 deals with managing records and this has a bunch of implications on a repository. To perform records management tasks you will need functions that are not available in every CMIS implementation. For example CMIS 1.0 does not know about holds, classification or disposal schedules. On the other side MoReq2010 restricts certain operations or forbids them completely (update or delete operations for example). But still they have some design principles in common: Both standards define a set of services, sets of metadata and type definitions. Both standards also rely on XML for formal data representations. They differ in that CMIS defines two protocol bindings for SOAP and AtomPub as wire protocol. But there is no counterpart in MoReq2010. As primary mechanism for data exchange MoReq2010 defines interfaces and a data format for exporting and importing data (including mass transfers). Specific interfaces for export/import are not covered in CMIS. Let us first look at some more details and derive some options for potential use cases to get synergies from both standards.

Comparing the services

The second part [Part 2] of my blog series gave an introduction about the services in MoReq2010. Refer to this for an introductory explanation. Here we will start comparing what is available in CMIS, what is available in MoReq2010 and how it matches.

There is no counterpart for the UserGroupService in CMIS. User Management was considered to be out of scope for CMIS 1.0, because this is a complex topic on its own and there exist other standards for user management. Obviously this leads to some gaps. There is currently a discussion in the CMIS TC around this, so it may change in a future version of the spec [1]. MoReq2010 has specific requirements like unique ids for users and restrictions how to preserve information after removing users.

The ModelRoleService deals with permissions and defines a concrete permission model based on Access Control Lists (ACLs). CMIS has two concepts for permissions: PolicyService and ACLService. The ACL Service is designed to be open for different implementations and only defines some basic rights. The MoReq2010 model is dynamic in the sense that an administrator can define roles (and assign a set of callable methods in that role). The MoReq2010 permission model could be exposed via CMIS. However the dynamic nature of Moreq210 roles is a bit tricky and may lead to confusion for some CMIS clients.

The Classification service, Disposal Scheduling Service and Disposal Holding Service cover specific requirements for records management and do not have a counterpart in CMIS. However not every use case will require the full functionality of these services. Some of the more common use cases can also be covered via CMIS (see below).

The ModelMetadataService deals with metadata and property definitions which are Type Definitions in CMIS. In CMIS 1.0 each object has exactly one type. Moreq2010 is more flexible and also has a concept for templates. The CMIS Repository Service allows only read access to the types, but type creation is on the roadmap [2]. Another proposed extension called "Secondary Types" will give more flexibility in CMIS [3]. This would allow exposing even more of the MoReq2010 model. It would be possible and useful to have common and standardized type definitions for the MoReq2010 system metadata. Not all property definition fields can be exposed via CMIS (e.g. RetainOnDestruction, PresentationOrder, …) but this should not be a blocker and could be covered through CMIS extensions.

The SearchingReportingServices of MoReq2010 is covered by the CMIS Discovery Services, but both have different functionalities. MoReq2010 does not define a query language, CMIS does. Reporting capabilities are not covered in CMIS but could be built on top of the existing service. CMIS also does not have saved searches, but a specific object type might be used as a replacement. It would be interesting to build a MoReq2010 compliant implementation of the SearchingReportingService that relies only on the CMISDiscoveryService for the implementation. In this way one implementation could cover a wider set of existing repositories. This an area where open source implementations would be interesting.

Export and import is a similar story. There is no direct mapping in CMIS for this, but you can implement these services based on CMIS services. MoReq2010 has a lot of requirements on the completeness of data (event history, users, types, etc.).  You would need a set of standardized MoReq2010 types in CMIS and it would be interesting to investigate how far you can get providing a common implementation. Probably it will be hard to get full compliance for any existing repository but also a sample implementation as template could be helpful.
For the CMIS RelationshipService there is no counterpart in MoReq2010. However there are concepts in MoReq2010 that can be modeled very well in CMIS using the RelationshipService. An example is the event history. The event history of an object could be modeled as an "EventHistory" relationship type. Having standardized types in CMIS would give us generic functionality in multiple repositories.
MoReq2010 does not support versioning. There are surprisingly little requirements in the specification about content handling in general. The notion of content parts is not supported in CMIS. CMIS only has one content element, but the standard is designed for more flexibility in future extensions.

Overlap or perfect match?

While records management standards covers all the functionality needed for a full blown records system there are many use cases requiring only a small subset of this functionality. Sometimes scenarios in an enterprise require interaction between multiple systems and involve records, but are restricted to certain aspects of a record.
A common example might be an ERP system producing records like invoices, personnel files, financial reports etc. The customer of such a system is interested in managing these records in a compliant way. The ERP system has the business context but is not necessarily itself also a records management system. In this case the ERP system has all the information to assign a MoReq2010 classification ("Invoices are kept for 7 years and use classification INV7") and can pass the invoice as a PDF file with metadata and classification to a MoReq2010 compliant repository. The ERP in this case never might be interested in applying a hold or scheduling a disposition. All the records functionality is exposed from the records system and the business system provides the context.
For use cases like this both standards can complement each other. CMIS is already available for many repositories and applications and has the advantage of providing a binding. Using the binding you simply can plug both systems together. Another system might just need read access to the document (let's say a call center where customers ask questions about their invoices). The list of available classifications might not change that frequently and can be exported and imported (or transferred as another CMIS type).

If a company has more systems managing records in place then they have to be kept in sync to guarantee the company's record policy. Here are many more aspects of a record are involved and the MoReq2010 standard addresses them much better than a generic standard like CMIS can. Such an application for example might want to list all holds, display pending disposal schedules or generate a report with statistics (all covered in MoReq2010).
CMIS may also help in another scenario as an intermediate step if a customer wants to start with classifying today but adds the record management system later. These are only a few examples but there are many use cases where CMIS can be used as a vehicle between applications and repositories where MoReq2010 guarantees the compliance.

Conclusion

There are overlaps between the two standards but this is not harmful. Instead it can help solving use cases based on existing CMIS implementations or taking benefit from the bindings. MoReq2010 then deals with the advanced records management scenarios requiring more knowledge about records management and guaranteeing compliance of the underlying back-end. Many ideas of these articles should be considered being initial ideas inspiring more thoughts and perhaps some objections as well. Nothing of this is written in stone. It will require more investigation and sometimes a deeper understanding of the spec. But I am sure that we will see a lot more interesting articles and use cases within the next weeks and months. Let's make the best out of the two standards by focusing on their strengths where it makes sense.

[Part 1] MoReq2010 And The New RM Debate http://blogs.opentext.com/vca/blog/1.11.623/article/1.26.933/2011/7/7
[Part 2] MoReq2010 A Look Into The Specification http://blogs.opentext.com/vca/blog/1.11.623/article/1.26.935/2011/7/7

[1] User Management in CMIS: http://tools.oasis-open.org/issues/browse/CMIS-724
[2] CMIS Type Mutability: http://tools.oasis-open.org/issues/browse/CMIS-699
[3] CMIS Secondary types proposal: http://tools.oasis-open.org/issues/browse/CMIS-713