[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (CMIS-723) Need to express other cmis:object types to clients.
[ http://tools.oasis-open.org/issues/browse/CMIS-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30051#action_30051 ]
David Choy commented on CMIS-723:
---------------------------------
There are actually 9 system properties that are common to the 4 existing base types. The one missing in the above list of 8 is cmis:objectTypeId.
For these properties, it is stated in 1.0 that a "Repository MUST return this property with non-empty values ...". So, using cmis:object would still force a repository to generate artificial values for some properties that may not be applicable to an application (e.g. cmis:lastModifiedBy for read-only content). In that case, why content stream properties and versioning properties can't be treated the same? This would argue that the cmis:document type is sufficient. On the other hand, if we do want to allow a repository to create custom object type, then we should only mandate minimum properties that are needed for the data model to work correctly and nothing more, which leads to the 4 properties.
An argument to use cmis:object is to preserve the "symmetry" such that the new base type should also share the same set of common properties as the original base types do. But this is a wrong set for such symmetry. We are trying to broaden the application scope covered by the data model. In the new scope, the common properties should perhaps be just the 4 properties. IMHO, if we want to preserve symmetry, we should redefine cmis:object instead.
Yes, the spec benefited a great deal from the Chemistry implementation and I anticipate it will continue to do so. However, making the spec comply to the current Chemistry implementation is not our goal, especially if it weakens the spec. With all my respect and appreciation to Chemistry, we shouldn't put the cart before the horse.
One other thought.
Since the new base type is intended for customization, I think the following attributes should all be <repository-specific>: creatable, fileable, queryable, controllablePolicy, includedInSupertypeQuery, controllableACL, fulltextIndexed
> Need to express other cmis:object types to clients.
> ----------------------------------------------------
>
> Key: CMIS-723
> URL: http://tools.oasis-open.org/issues/browse/CMIS-723
> Project: OASIS Content Management Interoperability Services (CMIS) TC
> Issue Type: New Feature
> Components: Domain Model
> Affects Versions: V1.1
> Reporter: Jay Brown
> Fix For: Proposals for 2.0
>
>
> There are many use cases for expression of other object types that are neither cmis:folder, cmis:document, cmis:policy nor cmis:relationship. Examples include document-like types that do not permit versioning or do not permit a content stream (P8 has these), ancillary objects like annotations, or even objects that represent complex types which are currently not permitted in the CMIS 1.0 property model.
> I see two ways these could be expressed. The first is simply to have implementations show cmis:object as the top of the types collections instead of starting with cmis:object's proper children. The simplicity of this approach is cancelled out however by the fact this this would likely break most CMIS 1.0 clients. So I have a suggestion which expresses the same idea, not as elegantly but without the backward compatibility issues.
> In the object model, declare a new base object 'cmis:custom' which would serve as the base type for the entire genus of all of these currently CMIS/orphaned objects. It would have identical attributes to cmis:object
> (i.e. Id, localName, localNamespace, queryName, displayName, baseId, parentId, description, creatable, fileable, queryable, controllablePolicy, controllableACL, fulltextIndexed, includedInSupertypeQuery )
> though different values for those attributes of course. For example it would be recommended that the cmis:custom object be creatable=false since it is a more of an abstract class type. The implementation could optionally make cmis:custom queryable=true.
> Note: No xml schema changes needed.
> Thus 1.0 clients when querying types on a 1.1 server would just see 5 types instead of (4) as they do with 1.0 servers. The normal inheritance model would follow from there as is done with the other types. If cmis:custom was not supported then it would not appear in the type (children and descendants) feeds just like the optional cmis:relationship and cmis:policy behave today.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]