Not long ago I blogged about the newly announced Content Management Interoperability Services specification, which is a joint effort of EMC, IBM, Open Text, Oracle, SAP, Alfresco, and Microsoft. If you close your eyes and sniff, CMIS smells a bit like JCR minus the coffee aroma. It's a high-level spec aimed at making content repositories reachable via platform-neutral (RESTful and SOAP-based) protocols.

As such, CMIS opens the way (in theory, at least) to faster development, easier integrations between the ECM and enterprise-middleware worlds, less dependence on proprietary SDKs (thus less vendor lock-in), and so on.

At first glance, CMIS seems too good to be true. Certainly it seems well motivated (as was JSR 170, which failed to set the world on fire), and it has drawn considerable attention based on its use of technologies like Atom Publishing Protocol and REST.

But there are those who think it's all a bit strange... including Roy T. Fielding, the father of REST.

Fielding said in his blog yesterday: "I am getting tired of big companies making idiotic claims about REST and their so-called RESTful architectures. The only similarity between CMIS and REST is that they both have four-letter acronyms."

Fielding continues: "REST is an architectural style, not a protocol, and thus announcing it as a protocol binding is absurdly ignorant behavior for a group of technology companies."

In reality, Fielding says, CMIS is actually "a Web Services interface for document management." He adds wryly:  "It should be renamed WS-DMS and tossed on the same pile of other specs from that genre."

It's not just the non-RESTfulness of CMIS that perturbs Fielding, though. The real problem is the implied data model. According to Fielding, CMIS is just "a thin veneer on RDBMS-based data repositories that provides a data model for document-like objects within filesystem-like folders ... exactly the kind of document model one would expect within a legacy document management system that is backed by a large relational database and authored via Microsoft Office applications."

Some would argue that Fielding is not necessarily an unbiased observer, since he works for Day Software. But I think his analysis of CMIS in the context of "conventional CMS wisdom" (whether you agree with it 100 percent or not) offers a refreshing counterpoint to the breathless hype surrounding the original CMIS announcements. To have the merits of CMIS debated openly (after seeing IBM et al. present it to the world as a fait accompli) can only be a good thing.