Re: [cmis] [DRAFT REVIEW] V1.1 Working Draft 03

[David Choy <david.choy500@gmail.com>]

Regarding query for secondary type, I don't quite like the "Secondary Type Projection" (2.1.14.1.2). It seemed very muddy to me. If an object's primary type is not queryable, then the object would not appear in the relational view. There is no virtual table corresponding to that primary type. If a secondary type could somehow make a non-queryable primary type queryable, we will have problems. Does this mean by applying a queryable secondary type to a non-queryable object, all of a sudden the object becomes queryable? Also, by following the same logic, does this imply a queryable property of a non-queryable primary type could override the type attribute? Furthermore, does the return list for "SELECT *" include all secondary type properties defined in the repository? etc.

For these reasons, I suggested that we let the primary type control an object's queryability. But if we do want to allow queryability on secondary type regardless of the queryability of primary type, then we would need a cleaner query model for secondary type. The following may work. Corresponding to each queryable secondary type there is a separate virtual table in the relational view. This virtual table consists of a column corresponding to the cmis:objectId property, and one column corresponding to each property defined by the secondary type. The rows in this virtual table correspond to objects that this secondary type is applied to. They are heterogeneous objects of various primary types which may or may not be queryable. But they appear homogeneously in this table and are queryable through this specific projection. Applying a queryable secondary type to an object would not alter the queryability of the object's primary type. The rest of the query model follows the v1.0 query model. Note, in the relational veiw, this virtual table is distinct and separate from the virtual tables corresponding to the primary types. If one wants to combine primary type properties and secondary type properties in a query, or properties from different secondary types, a table JOIN on the cmis:objectId column must be used. A query such as "SELECT ... FROM T WHERE P1=... AND P2=...", where P1 is a primary type property and P2 is a secondary type property, would be invalid. With this model, there is no problem to make the "queryable" and "includedInSupertypeQuery" attributes of a secondary type <repository specific>.

On Fri, Jun 8, 2012 at 4:25 AM, Mueller, Florian <florian.mueller02@sap.com> wrote:

Thanks David. I have updated the draft [1].

I have two comments.

> Do we need to mention Approved Errata for v1.0?

That's a question for the OASIS staff.

> Therefore, the "creatable", "fileable", "queryable", "controllablePolicy", "controllableACL", "fulltextIndexed", and "includedInSupertypeQuery" object type attributes are not applicable to a secondary object type and must be set to FALSE.

We should discuss the "queryable" and "includedInSupertypeQuery" aspects. A secondary type can be queryable, even if the primary type of an object is not queryable. A repository might have different indices for primary and secondary types. I think the "queryable" flag makes sense for secondary types. The "includedInSupertypeQuery" makes also sense for hierarchies of secondary types. 

Florian

[1] https://tools.oasis-open.org/version-control/svn/cmis/trunk/cmis-v1.1/tex/cmis-v1.1-wd04.pdf

From: David Choy <david.choy500@gmail.com>
To: "cmis@lists.oasis-open.org" <cmis@lists.oasis-open.org>
Subject: [cmis] [DRAFT REVIEW] V1.1 Working Draft 03

Comments on V1.1 WD 03:

Cover page, "Previous version": Do we need to mention Approved Errata for v1.0?

2.1.3.1 third bullet (p.23): "four base types" - should be six?

2.1.3.3.2 "required" subsection (p.27): typo "non-sytem"

2.1.3.3.6 (p.30): "larger than" should be "longer than"?

2.1.2 and 2.1.3: It may be helpful to cover the following points up front for secondary type. Currently the description is very brief.

 * An object must have one and only one primary object type, which cannot be changed.  An object's primary object type may be simply called its object type. The primary object type of an object classifies the object and defines the properties that the object must have.

 * An object may have zero or more secondary object types applied to it.  A secondary type is a named marking that may add extra properties to an object in addition to the properties defined by the object's primary type.

 * Consequently, each instance of a primary object type corresponds to a distinct object, whereas each instance of a secondary object type does not.  Therefore, the "creatable", "fileable", "queryable", "controllablePolicy", "controllableACL", "fulltextIndexed", and "includedInSupertypeQuery" object type attributes are not applicable to a secondary object type and must be set to FALSE.

 * Secondary object types can only be defined as subtypes or descendant types of the cmis:secondary base type.  All other base object types and their descendant types are primary object types.

2.1.9 3rd paragraph (p.73): "CMIS only provides a way to add and remove additional properties on an object." -> CMIS provides a way to apply and remove secondary types to/from an object.

2.1.9 4th AND 5th paragraphs (p.73):  "base object-type" -> "base object-type cmis:secondary"

2.1.9.2.1 (p.75) "queryable", "includedInSupertypeQuery", "fulltextIndexed": Should be FALSE. These attributes characterize the object instance which is governed by object's primary type.  This comment applies to all the retention secondary types in 2.1.16 as well.