This week has seen REST experts Roy Fielding and Sam Ruby comment on CMIS. As someone directly involved in CMIS, I wanted to acknowledge both Roy’s remarks and Sam’s remarks, which follow onto Roy’s.
The standards effort based in OASIS that is CMIS is indeed just getting started, as Sam notes. There is a lot of work to be done, and CMIS needs timely, constructive feedback from the wider community if it is to become widely adopted.
9 responses so far ↓
1 billycripe // Oct 2, 2008 at 10:27 am
So you acknowledged the comments but what do you think? The “it’s a proposal not yet a spec” is the least of the critiques. In fact I’m not even sure there is a critique in Fielding’s comments beyond don’t call it REST. The interoperability point of the proposal seems intact.
2 Craig Randall // Oct 2, 2008 at 11:13 am
Hi Billy. Thanks for asking.
I mostly wanted to acknowledge the wider perspective forming around this standards effort. But since you asked…
Yes, the whole point of CMIS is very much intact: interoperability. The details of how interoperability should be achieved are under debate, and this is both expected and healthy.
Setting aside the HTTP-is-the-protocol-and-REST-is-an-approach gripe–OK, the documents need some naming tweaks–I still believe that there is value in two bindings for CMIS (i.e. SOAP/RPC and REST/Atom).
As I’ve said elsewhere, both bindings are derived from a common domain model. I believe that this domain model is not the subject of current debate–if it is, I hope that those with concerns will clarify.
I do believe that at least the REST binding, as currently specified, has received some fair criticism, and I am confident that the OASIS TC will take all feedback seriously.
Oracle is represented on the TC, too–via its acquisition of BEA, I believe. You’ve seen (Oracle ACE Director) Bex’s post and comments–(AtomPub editor) Bill de hÓra did, too, today.
What do you (and the wider Fusion ECM team) think (in more detail) about CMIS?
3 Nirmal // Oct 7, 2008 at 11:13 pm
I think CMIS should provide a standard query type and instance of query type can act just like a document in system
for eg : http://cmis/casestudies/green
Here ‘green’ could be a query object which queries casestudies (documentum could implement as a dql and sharepoint as caml or free text)
In addition to efficient management of these queries - this mechanism will also help in REST - ful access of resources - Document aggregation is just another document from applications perspective ..
4 Craig Randall // Oct 8, 2008 at 6:59 am
CMIS already specifies query support. Via the proposed REST binding, for example, query is the act of posting a query document to a collection resource (e.g. http://localhost/somepath/checkedout, which represents the collection of checked out documents by the authenticated user and this resource can accept POST requests).
5 Nirmal // Oct 8, 2008 at 7:33 pm
From the specs, i thought “checkedout” is collection mandated by specs.
I was talking about something like stored procedures in RDBMS - does spec mandate CMS systems to have object types like stored procs which act like a document ? - may be its already in specs and i am just not able to read it properly .
6 Craig Randall // Oct 8, 2008 at 7:52 pm
Yes checkedout is a named collection in the spec. I could have used a folder as another collection resource example (or content repository or queries or…).
CMIS doesn’t mandate stored procedures. In the REST binding, a query request is represented by a CMIS-specific XML payload. I don’t understand your analogy to stored procedures either.
7 Nirmal // Oct 8, 2008 at 8:29 pm
All i intented to say was it would be nicer for applications ( and REST ful) to access query results just like a resource in a collection of CMS insted of giving a custom SQL or DQL language
How to represent the object in CMS could be specific to CMS implementation -thats where i related them to stored procs in RDBMS.
8 Craig Randall // Oct 8, 2008 at 9:43 pm
A specific content repository likely does have a unique way of representing objects. However, CMIS is intentionally not about capturing each unique representation across the set of unique representations. Rather CMIS is focused on interoperability and therefore how to represent common aspects of ECM objects. ECM systems that leverage a relational database for object types tend to specify objects in tables (state). They may, in turn, leverage stored procedures and/or ORM for behavior.
BTW, I do see value in supporting a “stored query” (”saved search”) resource (e.g. http://localhost/path/queries/12345, where 12345 represents the id of specific stored query and queries is the collection resource that represents all stored queries, including none).
Update 10/9/2008: I would also remind you of Roy’s constructive criticism in his post where revisiting the nature of query support is concerned.
9 Nirmal // Oct 8, 2008 at 11:12 pm
Thank you for your explanation on core objective of CMIS , that was helpful.
My suggestion on “stored query” objects would be to leave it open to implementations instead of defining if it need to be constructed by a certain query syntax. queries could be a specialized collection resource that represents a stored query object - and each implementation can decide best way for it to implement them.
Leaving definition of such object open will also help vendors to provide increased search capabilities not limited by syntax barrier ( related documents, faceted navigational queries ) .
Additionaly getRepositoryInfo call could return if queries collection resource supports notion of stored queries . CMIS spec could also mandate that if stored query is supported - CMS should at the minimum support authoring that using CMS - SQL , but not limited to .
May be im thinking too narrow ( just from how typically web apps access information from a WCM system ) .
You must log in to post a comment.