[cmis-comment] on property definitions / query object resolving /and others

["JOERIS, Gregor" <gregor.joeris@ser.de>]

Hi!

I like to provide some comments on CMIS as well - even if I am a bit late. I studied the CMIS v0.5 draft sometimes ago and had no time to look at v1.0 so far. I really appreciate the work done by the OAIS TC and the progress from 0.5 to 1.0!

Maybe some of my comments are valuable either (otherwise it's just for the archive):


Required tag vs. "MUST be set on the object vs. read-only
=========================================================
First of all, I was also a bit confused on the meaning of the "required" tag. E.g. "createdBy", "creationDate" etc. should be always required on the level of the data model. It seems, that the "required" tag is defined on API level and not on persistency / repository level, i.e. the application programmer is not enforced to (or must not) set this value. In my opinion, this distinction is not clearly defined. Moreover, the "updateability" tag with read_only defines the same on the API level (=> must not set on API level) so that I would prefer to have the properties like creationDate etc as required instead of the comment "MUST be set on the object".

However, "MUST be set on the object" is listed also in (2.1.4.3.3) for those tag which "always have a value"



Small errata in description of atom entries for result sets
==============================================================

5462 The feed returned MUST contain a set of atom entries representing the result set from the query.

5464 The atom entries should contain the bare minimum necessary for Atom compliance [RFC4287]. The
5465 atom entries MUST contain the CMIS extension element (cmis:object) containing the properties specified
5466 by the query in the select clause of the query statement.

=> I guess "cmisra:object" instead of "cmis:object" would be correct.


How to provide Object-related information in Queries which do not result in list of objects?
============================================================================================
Though the virtual relational mapping of the CMIS data model is an interesting approach, it causes some confusion to me when I looked deeper into the SQL syntax and the Atom(Pub) mapping. The result of the SQL query is not a list of (queryable) objects but just a relation of properties ("pseudo objects"). Since JOINs are allowed, the resulting relation may contain properties from different objects in one row.

Let's take the following sample from the spec:

2464 SELECT Y.CLAIM_NUM, X.PROPERTY_ADDRESS, Y.DAMAGE_ESTIMATES
2465 FROM POLICY AS X JOIN CLAIMS AS Y ON ( X.POLICY_NUM = Y.POLICY_NUM )
2466 WHERE ( 100000 = ANY Y.DAMAGE_ESTIMATES )

How to resolve 
- includeAllowableActions
- includeRelationships
- renditionFilter
in this case?
Is it always empty because the SELECT clause does not refer to one object per row?
Is it the intersection (or union) of all objects which are virtually part of the row?
Or it is not allowed to use includeAllowableActions etc. in such a query (i.e. error status code will be returned)

In general, this query approach may cause problems with permission control (when to check what ACLs?). 


Is it a design goal that the CMIS REST binding provides only a subset of the CMIS functionality?
================================================================================================
I do not find any create methods and also e.g. discardCheckout is not provided (maybe I am blind to see)

I guess there have been several discussion on this topic but I do not find any explanation in chapter 3 that the RESTful binding does not support any service and operation of part I. In contrast, chapter 4 for the WS binding explicitly states that "ALL services and operations defined in part I of the CMIS specification are presented in this Web Services binding." (line 9372)

I am not a friend of RESTful services in case the service has no RESTful style (but this is another discussion). Therefore, I would appreciate when the CMIS REST binding focuses only on a subset of the functionality, BUT this circumstance should be clearly mentioned - Which is not so far.
 
By the way, the introduction does not even mention the WebService binding (ok, nobody reads the introduction typically...)

2 The Content Management Interoperability Services (CMIS) ReSTful AtomPub binding specification
3 defines a specification based on AtomPub that can be used by applications to work with one or more
4 Content Management Repositories.


Best regards
Gregor


Dr. Gregor Joeris | Product Manager  
SER Solutions Deutschland GmbH
Innovationspark Rahms | D-53577 Neustadt/Wied
Tel: +49 (0)2683 984-352 | Fax: +49 (0)2683 984-222
gregor.joeris@ser.de | www.ser.de
SER Solutions Deutschland GmbH * Innovationspark Rahms *  D-53577 Neustadt/Wied