This week, over in Seattle, the OASIS CMIS Technical Committee is getting together for face-to-face meetings complete with plugfests every afternoon. It promises to be fun, but they are trying to accomplish some real work during all of this. The largest piece is the thought they are giving to what is going to be in the next version of CMIS.
Now I have some definite opinions which I am going to share. In order to facilitate disagreements, I am publishing the list of items they are taking under advisement. I have added bold to the ones that I care about the most.
- Browser binding
- Cross-Site Request Forgery (CSRF) defense
- Secondary type, type mutability
- Retention policy, legal hold
- Query: templated, virtual folder, Lucene syntax
- External content
- Rendition
- More definition of Users and some associated services
- Annotations
I was going to talk about my favorites, but I realized that I wrote that post last year! Back in June of 2010, I talked about CMIS 2.0, The Next Generation. That actually covers what I want a fair bit and I highly recommend viewing it. I’m going to reproduce one of the two lists here and add some additional commentary.
- Semantic Support: We need 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 but being able to query against relationships may suffice for now.
- Records Management: Scale this down to retention management. We aren’t trying to build a complete DoD 5015.2 system using CMIS. All we really need to support the standard Application-to-Repository model is the ability to apply retention policies and legal holds to content. This is important to enable so that users can do this from their business applications. Retrieving the Retention Policies and Holds applied to content would also be critical so the end-user knows what is happening.
- Support for Defined Data Models: Would love this, but it can wait until the next item is implemented.
- Create Content Types: Here is the basic problem. Using CMIS, companies can develop a specialized application that can leverage any content repository without writing multiple integrations. The problem is that they still have to write vendor specific installation applications to create their specialized object types. That is a pain. While this feature isn’t required for true interoperability, it is something that would help spur-on adoption by those developing Composite Content Applications.
- New Bindings: Creation of a browser binding is more important every month as we start aggregating information from more and more sources.
That’s it. I could come up with things all day, but I think these are the more important ones.
Word of Pie 
Would you say that you are asking for ECM systems to be wrapped into a single interface that basically makes them a pure backend functionality?
That is clearly NOT in the interest of most of the vendors, espacially the large ones who promote openness via CMIS. Also, some of the features that you ask for do not only require vendor specific coding on the backend, they rather simply DO NOT EXIST in the systems of these vendors. Sharepoint for example.
On top of that many of those features I would rate as not ECM specific, such as user functionality.
LikeLike
Definitely not asking for that. But if I have content surfaced in my CRM system and I need to declare the entire collection of data and content as a record, it is easier to do it there. This supports current needs, not just pushing Content Management completely to the back-end. That said, I see it moving that way. Historically, Content Management vendors have made poor interfaces. When they manage to create a good one, it expires and dies over time. Without going much deeper, because I’m slightly worn-out on the topic (not from you), CMIS needs to support application developers to write solid business applications, such as CRM or Correspondence Management. Business process engines need to be able to reach into the repository and apply those things that are necessary, like retention once a piece of content is approved.
Keep in mind, CMIS is a standard not of the lowest common denominator. Not every feature is fully supported by all vendors. Take relationships. Not all vendors, including SharePoint, support relationships. However, relationships are already in the CMIS model. That request is simple asking it to be added to the query language as well.
None of these things should hurt vendors. When taken from the perspective of the larger standard, most of these are just natural extensions of what is already there.
LikeLike
My top two:
1. JSON (“browser” ack!) binding
2. Workflow instance APIs (list tasks for user, action tasks, etc. – not workflow definition though
#1 is way more important than anything else on the list (AtomPub is painful).
I see requests for #2 from CMIS client developers a lot more frequently than the other items on the list (particularly the RM-related items – I almost never hear requests for that). For reasons similar to RM, it seems unlikely to me that the committee members will be able to agree on a common domain model and operation set for workflow however.
LikeLike
Thanks. I think the task listing may be a more challenging undertaking, but I see why it would be important. You also have a fair pulse of the people, so we actually have to take your thought very seriously. Very strange.
LikeLike
Well keep in mind most of the CMIS clients I’ve worked with are interactive end-user apps. I could easily see how declaring a record would be a welcome addition for CMIS clients that wish to use a repository for archiving the end state of a larger process (CRM springs to mind).
LikeLike