Kas Thomas wrote a post about how CMIS could be called DMIS as it is more for document management systems than content management systems. This hit me on two fronts. The first is with the concept of “CMS”.

Why is it that when I talk to people about “CMS”, they are almost always referring to Web Content Management? Seems to be a pretty narrow definition of the use of content. Along the same lines, many “Information Architects” that work with these “CMS” applications seem to be senior website designers. I’ve met Information Architects that I felt deserved the title, but they dealt with things beyond, though including, the web.  Enough of that, for now, on to the main course…

The second, is of course the slight to CMIS. That is the focus today. While I encourage criticism of CMIS as criticism is important for growth, I don’t want misconceptions to perpetuate themselves.

Sticks and Stones

I must say that I was a little disappointed with Kas’ post.  I was expecting a much more in-depth dissection of CMIS. It was mostly focused on nomenclature. In standards, the names of things are picked to be generic and in such a way that no one vendor looks to be the source of all.

That being said, the first observation is dead-on. Why does the CMIS standard have Document Objects and not Content Objects? Seems like a simple one-to-one mapping that should be there. It is just words, but words create the perception.  It is a valid criticism, but only semantically.

The next was folders. This is one that I tried to think through before CMIS was released for a side project. It is just a simple generic term. WCM systems may use other terms, but users of all systems understand folders from a hierarchical storage capability.

What’s more, if a repository supports the capability, CMIS allows for Document Objects to un-filed.  There is no need to throw everything into a folder at all.  This capability is defined by the combination of the repository and the object definition. Conversely, you can put documents in multiple folders, so you can store things however a supporting repository allows.

Beyond the Names

Did I mention that Kas correctly pointed out that WCM is NOT a supported use-case for CMIS. Check out slide 12 of John Newton’s AIIM presentation. Records Management and Digital Asset Management are also not use cases.  There are two things to note here…

The first is that the slide is titled Not This Time. The current iteration of CMIS is designed to reach quick agreement on a baseline standard. I have heard multiple players discuss the “next” version of CMIS. The scope is being kept manageable to get it out the door with basic functionality.  I know from talking to a few vendors that they are intensely interested in adding some of the use cases listed on the Not This Time slide.

The second is that just because they didn’t design it to support the use case doesn’t mean that the use cases listed can’t leverage CMIS. Looking at WCM specifically, there are lots of things that are standard in WCM systems that are not supported by CMIS. There are couple of things that are supported though.

• Relationships: An explicit, binary, directional, non-invasive, and typed relationship between a Source Object and a Target Object. This includes the ability of an object to reference itself.  With the typing, many  relationships can be utilized, depending on the underlying repository.
• Policies: An administrative policy that can be enforced by a repository, such as an Access Control List (ACL) or a retention management policy. Those are two examples, but any policy that the underlying repository designates in their CMIS implementation would work.  While Retention Policies is the usage that I am most excited about, there is no reason it couldn’t be leveraged for other functions.

Compound documents aren’t explicitly supported, but I see the foundation for it already in the specification.  I am hopeful that it will be fully supported in 2.0.

The point is that we are dealing with more than just simple CRUD here.

One Last Point…

Kas mentions the relational model used by CMIS and the resultant CMIS-SQL language based upon SQL-92.  It is a valid point, but it is important to note that the Query component is, itself, an overlay on the CMIS Object Model. The 0.61 specification says:

The relational view of a CMIS repository consists of a collection of virtual tables that are defined on top of the CMIS data model. This relational view is used for query purposes only.

In this relational view a Virtual Table is implicitly defined for each queryable Object-Type defined in the repository. (Non-queryable Object-Types are NOT exposed through this Relational View.)

I’m not sure what alternative approaches that should be used that would work across multiple repositories.  I would love to hear approaches and how they could be applied to all repositories that might support CMIS.