CMIS 2.0, The Next Generation

image It has been a month since I talked about CMIS, and that was focused on celebrating the release of 1.0 and the AIIM Demo.  Well, the time has come to look to the future and start thinking what we need out of CMIS to help where we need it…the future.

Short List

I’m just throwing a list of business cases that we need support for in CMIS.  Specific features may not be all listed, but I will be listing some to give an idea.  The goal here is to stimulate everyone’s collective mind and think about what we need in the next version.

  • Semantic Support: I was working with some interested parties several months ago and realized that I could force many Semantic requirements into the current model.  What was missing was the ability to query off of relationships.  This will allow for more advanced relationship management.  Mind you, more support for that management directly off of the CMIS domain model would be nice as well.
  • Records Management: Right now, you can apply policies to a piece of content.  In theory, that policy could be a retention policy.  Some enhancements to policies might be nice in order to identify RM policies versus generic policies.
  • Support for Defined Data Models: One thing that was readily apparent when building the CMIS demo was the challenges in managing the same metadata model against different repository implementations of that model.  There were variations in naming and other details.  It would be a great advantage if I could query the repository to determine if they support the needed data model and then just use it.  This happens now when you use the field “cmis:id”. It maps to the real name underneath the hood which isn’t always “id”.  For example, “r_object_id” is the actual field name for “cmis:id” within Documentum.
  • Create Content Types: Component Content Application developers, this one is for you! Leveraging off of the previous item, it would be cool if you could, through CMIS, create a new object type based upon a document or folder.  This would allow custom applications to have a generic CMIS script that would create any custom types needed by the application.  This will add an important abstraction for those using CMIS for multi-repository purposes.
  • New Bindings: Heard several ideas in the last year.  WebDAV and JSON were two.  If I had to pick one, I’d lean to the latter for creating advanced apps, though WebDAV has the distinct advantage of working well with desktop applications.  The number of overall bindings is only limited by those working on them, so get involved if you want a new one.

I’m sure that there are more, but I think those are the important ones.  It helps the web-heads, the ECM types, and the solution providers.

More on CMIS Needs

While the above section was written based upon what is sitting at the top of my head as important.  I decided to look around and I found some of my notes on what is missing from my discussions with the aforementioned “interested parties”.  There is some more detail beyond what is listed above. Share and Enjoy.

  • Hierarchical metadata is not supported by CMIS.
  • Tagging is not supported. While an asset can have a multi-value field, it is set by the asset and not by the combination of user and asset.
  • An extension of the tagging is the concept of Authority assigned to the tags. This is a more advanced concept. As I have thought on this, the Authority could be handled behind the scenes as Authority can be assigned to a user.  CMIS doesn’t necessarily need to support this in 2.0 as support is needed for this feature in the underlying repository more.
  • Support for aspects, or something similar, is missing. While in many ways, this could be represented by a relationship or a policy, the ability to apply a domain map via an aspect to an asset would be valuable.
  • Semantic modeling can most likely be achieved through the use of Relationships. Folders is a possibility, but it feels like overloading and there could only be one type of “relationship” between a folder and an asset.
  • Given the use of relationships, the ability to Query relationships in the “Where” clause is missing. Something similar to the “In_Folder” command currently present for folders. This should handle most of the conditionals.
  • If tagging is added, there would need to be the ability to query not just on the presence of a tag, but on its strength. That would be either absolute (50% taggers used value “X”) or relational (“X” is one of the top 5 tags).
  • Aspects also need to be queryable.

Fun notes.  Thought I would add them here to share and build some thought basis.

Is something missing?  Well, then you need to get involved.  If you don’t speak-up and share, then you aren’t in a position to complain.  The CMIS standard’s future is only as strong as

5 thoughts on “CMIS 2.0, The Next Generation

  1. Hi,

    I like the ideas of the CMIS 2.0, but be aware of “Create Content Types”. If this one get into the wrong direction, you will lose several backends. One of the major problems of the JCR is, that it is to generic and that the data model is driven by the standard, not yet by the backend.
    This will lead to interoperability issues in the backends, because most of them have to change their business logic.
    So this way has to be at least optional. In most projects, the data model is defined their, so it should not be the problem to first create a model which is like the one needed.

    WebDAV: To implement WebDAV on top of the CMIS should be one of the easier ones, because WebDAV has more features, than CMIS and has the concepts of Metadatas, ACLs, … since several years. The only problem is, that there are not enough clients out there, because WebDAV is missing a complete Test Suite to test if somebody is compliant to the SPECs. I think it is time for a revival, that’s why we created an Open Source-Project, which could be perfect for the CMIS-Stacks. WebDAV for JAX-RS (

    JSON: This will be future, if you want to access such a Standard directly into your webapps. I also think it will be the end of SOAP. 😉 Most of the Web Services are switching from SOAP to http (I don’t call it REST 😉 because I don’t want discussions about it).

    Last but not least, I don’t think that the logic of Tags should be come into the standard. Tags are a feature of a Frontend, because it can be modelled in several ways.

    It is good, that CMIS is out now, but we should give him some time, so we have more experiences with it and shouldn’t as fast as possible create the Version 2, only to show that this one is still alive.



  2. Hi Laurence,

    I like your points. I will add two comments:

    Semantic or Defined Data models
    As part of the Advisory board of IKS (, a 8 mio Euro project funded by the EU which aims to semantize existing CMS, I am pushing them to contribute some of their deliverables to CMIS 2.0. Semantic gurus and CMS folks lived for the last decade in two distinct worlds. I think both could really mutually benefit from deeper relationships to bring CMS to the next level and CMIS could really act as this bridging technology. Moreover as CMIS gets a strong momentum in the “traditional” CMS industry, it could act as a “Semantic Trojan Horse” for existing CMS even if most CMS do not want to go the full semantic way. Far from all CMS developers are semantic experts (included myself) but enforcing some basic level of semanticity through a widely adopted CMS standard or delivering some cross-vendors core pre-defined data models could push the whole industry forward in the next years.

    I am more than convinced that IKS is willing to help in this area. We now have to work on the details. Perhaps a presentation to the Oasis CMIS TC board of what IKS could bring to CMIS 2.0 project could be setup in a few weeks. In all the cases it would be nice to have you as a keynote speaker on this subject for a next IKS Workshop.

    (A nice document was formalized on this subject by SRDC one of the IKS project founding member). More to come. Stay tuned.

    Cmis Delivery Networks (CDN)
    I am a bit concerned by R2R or FR use cases performance. Perhaps it would be nice to add some level of CDN-readiness at a content object level. The ESI standard was only done at the page fragment level. Perhaps some more granular content-oriented CDN caching services would now be required.



  3. Great list Laurence; the Support for Defined Data Models and Semantic Modelling in particular with ability to define and execute multi-layer queries based on some mapping would facilitate a lot of things; not least building complex documents in repositories that dont otherwise support them, building and supporting many types of functionality using relationship models which could then be leveraged to support not only a traditional relationship to other objects but relationships handling complex workflows etc.


Comments are closed.