CMIS II: (C)MISsing good old AtomPub

In my earlier post on AtomPub vs. CMIS, I expressed concern that new constraints on Atom syntax introduced by CMIS go so far as to rule out using a standard AtomPub client with a CMIS AtomPub server. In theory, one could say that adding a new required element to Atom’s schema is a non-starter. However, if there is a desire for CMIS servers tosupport standard AtomPub clients, then the current spec is quite far from that goal.

Let’s see the consequences of new constraints on the AtomPub and Atom syntax used by CMIS servers. A non-CMIS client will be unable to talk to CMIS even for use cases so simple as adding a document to a folder. Consider the following request to the root folder of a CMIS repository:
POST /folder
Content-Type: application/atom+xml
Content-Length: nnn

<entry xmlns="...">
<content type="text">
Can I live inside CMIS?

Even though the CMIS AtomPub “binding” doesn’t state this clearly, and is a fantastic example of how NOT to write a RESTful specification, in my understanding the above request will fail with a 400 status code (not clear which one). This isbecause:
  1. CMIS doesn’t state acceptable content in an AtomPub understandable manner anywhere.
  2. Even if it were to advertise accepted content, a compliant CMIS AtomPub server could reject a POSTed entry if it did not meet CMIS expectations. Thus you could not expect the serverto take the text from the atom:content elementand save it as the document content. I am basing this on reading the following paragraph in Section
    • The behavior is repository specific when a non-(atom/cmis)-entry document is posted to a folder URI. For example, the repository MAY auto-create a document with a specific type (document) the client could edit. The repository MAY also throw an exception.
  3. Nowhere does the document state what makes a valid CMIS/Atom entry document. As a saving grace, the specification package includes an example document entry. This example usesout-of-linecontent and an edit-media link element.
  4. Let’s assume that the server allows our entry through and creates a new document using it. Now the entry that is stored is full of duplicate information.
    1. The content stream location is in two places: atom:entry/atom:content@src and atom:entry/atom:link[rel=stream]@href
    2. The time when the entry was created is in two places: atom:entry/atom:published and atom:entry/cmis:object/cmis:properties/cmis:propertyDateTime[cmis:name=CreationDate]/cmis:value
    3. Also repeated is information such as atom:entry/atom:id, atom:entry/atom:author and atom:entry/atom:updated
There is more material for many more posts. So stay tuned…

Leave a Reply

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