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