CMIS vs. AtomPub Hierarchy I-D

Led by Microsoft, IBM, and EMC, OASIS has been working on a modern standard for content management systems, called CMIS. This group has started from a submission made by the above three vendors called CMIS v0.5.

This standard also includes a “binding for REST/Atom”. In layman terms a binding is an adaptation of the abstract standard to a specific network protocol and format.Julian Reschke suggested that we hash out the overlap between CMIS AtomPub extensions and theAtomPub hierarchy-ID. Here’s a summary of the most important areas of disconnect.
CMIS genuinely tries to provide a good AtomPub extension, but fails on at least three counts:
  1. Link relations defined by CMIS cannot be used by a client that does not understand CMIS. So if you would like to have parent-child relations but don’t want to put a cmis:id attribute (yes, that is a SHOULD level requirement), then you are out of luck. On the contrary, rel=master and rel=detail from hierarchy-ID do not impose any additional requirements.
  2. There is no way to auto-discover the POST url for a feed. For example, you obtained a list of documents in a folder and now want to add another document to that folder. Without understanding rel=repositoryand cmis:collectionType, there is no way to do that. On the contrary, hierarchy-ID will be understood even by existing AtomPub clients, and these clients will be able to add another item next to the existing document.
  3. The CMIS spec defines PUT and DELETE methods on an atom:feed type resource (yes, see Section 3.4.5.4 and 3.4.5.6). I would imagine that the CMIS spec would need to go to IETF for doing something like this because they are in effect extending the semantics of the application/atom+xml;type=feed MIME type. No such extraordinary extension is going on in hierarchy-ID and this ID is before the IETF for consideration.
Now, we have every intention of engaging the CMIS to help them understand the consequences of these issues, namely a monolith hanging off a lean protocol that can only be used for content management and improving the use of existing AtomPub metadata for doing simple things like discovering the URL for modifying a feed. Whether that will have any useful outcome is anyone’s guess.

Leave a Reply

Your email address will not be published. Required fields are marked *