[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=30058#action_30058 ]
David Choy commented on CMIS-723:
---------------------------------
If we add a new base type to the data model, we certainly need to specify which verbs are applicable to that type. We need to do that whether the new type has 5 more or 5 fewer properties. I didn't quite get the point. Nevertheless, the suggestion that in order to make a verb n/a a new base type is needed seemed troublesome to me. For example, do we need another base type for objects that are versioned but do not have content stream? And yet another base type for objects with content stream but not versioned? We could end up with many base types just to accommodate different combinations of applicable verbs. But, in the end, no matter how many base types we have, if a not-applicable verb is applied to an object, the repository is going to throw an exception anyway.
I didn't get the "query scope" argument either. How does a query on this new type differ from a query on the document type?
Regarding object type attributes, Section 2.1.3.2.1 describes attributes common to all object types, which works fine for the new base type as well. However, the setting of each of these attributes is specified in the definition of each base object type (e.g. fileable is TRUE for document object and FALSE for relationship object). My comment was, those 7 attributes (which are among the common attributes) should be specified as <repository-specific> for the new base type. This was in response to the suggestion "queryable=yes, controllable=yes, fileable=yes". If we allow a repository define custom object type, why must the new object type be queryable, controllable, and fileable? Why can't we let a repository decide?
> 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]