CMIS has consumed a lot of my blog space for a good reason. Hierarchy is quite important to CMIS and we (Colm Divilly and I) have spent a great deal of time on it. Despite having pointed out several issues in this blog, I can’t beat the feeling that CMIS is determined to go its own way at the slightest hint of inconvenience.
Firstly, despite the futility of modeling Atom with an XSD, CMIS insists on it whether it is informational, mandatory, or illustrative for tooling. Additionally, when probed about AtomPub interoperability with the binding for CMIS, here’s what the editor has to say:
The spec states it is repository specific what happens when a non atom entry media type or atom entry media type without cmis info is POST'ed to a collection. It suggests that the repository may create an instance of a document of a default type.
What this means is that whether a CMIS server works with a non-CMIS client is upto the server to decide. This is what I posted about in CMIS II: (C)MISsing good old AtomPub.
If you leave it to individual CMIS servers to decide whether they support non-CMIS AtomPub clients, then this is not true interoperability.