In a previous post, I complained that I miss good old AtomPub when working with CMIS servers. One of the reasons is duplication of key information items of Atom in a CMIS property set. One of my colleagues reported an issue to the CMIS TC for CMIS properties that duplicate APP/ATOM information. Duplication produces two problems as any good DBA will tell you:
- Wasted resources
- Missed updates
Let me illustrate what would happen if the editor’s proposal to resolve the issue (to which the TC agreed) (emphasis mine) were to be applied:
I’d like to keep the duplicated info. Originally we did remove the duplicated fields: id, createdby, etc. However, that made some properties special and could not be updated in the same way – by setting a cmis property field. Also, it became less obvious on how to search on those fields.
I do think an order of processing should be stated: cmis:property is authoritative if present, then atompub (or vice-versa).
The bandwidth cost of having that info in two places is not that significant in my opinion.
Now take the case where a vanilla AtomPub client is working with a CMIS server. It attempts to update an existing document entry and changes the content of the atom:entry/atom:updated field but does not change the atom:entry/atom:published andatom:entry/cmis:object/cmis:properties/cmis:propertyDateTime[cmis:name=UpdateDate]/cmis:value then, the server will silently ignore the update if CMIS comes first.
However, version 0.61c1 of the AtomPub bindings for CMIS states:
When POSTing an Atom Document, the atom fields take precedence over the CMIS property field for writeable properties. For example, atom:title will overwrite cmis:name
If this does make it to the final version of the spec, then all will be forgotten, although I do think that this little footnote deserves greater attention.
I hope the lessons from my analysis of CMIS prove useful for the numerous activities (e.g., SunCloud, GData, Netflix) currently underway to develop AtomPub interfaces to various applications.