CMIS I: AtomPub binding and AtomPub service documents

This is the beginning of a new series of posts on the still-nascent AtomPub binding of CMIS. Although, this spec has been seen by over 20 companies (led by IBM, Microsoft, and EMC that are participating in its TC) over six months now, I doubt anyone involved in writing this spec has ever written an AtomPub server or client.

The section 3.4.2 of the CMIS AtomPub “binding” specification is quite illogical if you follow through these arguments:

  1. A repository is represented by an Atom service document.
  2. Within the Atom service document, each workspace maps to a single repository.
Firstly, there is no such thing as an Atom service document. The spec is referring to an AtomPub service document.
Secondly, if Repository Service Document and Service Document contains multiple workspaces, then how can each workspaceRepository? May be the spec should have stated that the AtomPub service document corresponding to a CMIS repository MUST contain exactly one workspace.
Thirdly, the CMIS spec says nothing about the constraints on what kind of entries the server can accept into its various collections. This is information that is typically advertised in the AtomPub service document. Two things can be currently specified in this:
  1. What MIME type of data is acceptable to the server for adding to the collection
  2. What categories are acceptable to be used on entries being posted.
For a moment, disregard the second part since AtomPub’s use of categories is the worst thing about RFC 5023. At least the CMIS spec should state how the first part is to be addressed. Here’s what could be a decent CMIS service document:

<service xmlns="..." xmlns:cmis="...">
<workspace>
<collection cmis:collectionType="rootchildren">
<atom:title atom="...">Root children collection</atom:title>
<accept>application/atom+xml;type=entry</accept>
<accept>text/*</accept>
<accept>image/*</accept>
...
<collection>...</collection>
</workspace>
<service>
This example states that the collection can accept new entries (for example, creating new folders). Unless the CMIS spec requires this, there is no means to address introspection needs of AtomPub clients. The example above also shows how documents could be created as well that are either images or text.
CMIS TC has invited comments from the AtomPub community on this spec but the spec provides no examples of their use of AtomPub. If they went through this exercise, they would find a number of such illogical things that I am going to highlight in a multi-part blog series.
Stay tuned…

Leave a Reply

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