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 ) .

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.

How to represent the object in CMS could be specific to CMS implementation -thats where i related them to stored procs in RDBMS.

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.

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 .

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 ..

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?