[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=29727#action_29727 ]
David Choy commented on CMIS-723:
---------------------------------
Currently, cmis:object is merely a set of reusable property definitions. We could formally make it an abstract CMIS object type and the root of all CMIS object types, if there is a need for it. If not, then it is better to leave it out of the CMIS data model. For an interop standard, "less" is often "more" (less constraint, more flexibility and easier to adopt).
If we do define a new base type, IMHO it should have the minimum properties, and the most flexible type attributes, for an object to function as a CMIS object. All other properties can be added through type extension (primary type or secondary type), and, a repository has the ability to define more restrictive/customized type attributes. We should avoid any need for yet another, even leaner, base type in the future. So, I'd suggest the following:
* Object type attributes:
id=cmis:item (or whatever it is to be called), baseId=cmis:item, parentId (not set), all other attributes are repository-specific.
* Properties:
cmis:objectId, cmis:baseTypeId, cmis:objectTypeId, cmis:creationDate
(That is, the following properties of cmis:document are excluded: cmis:name, cmis:createdBy, and all properties pertaining to update and content stream. There are lots of R/O content out there. For them, all the support for update are unnecessary.)
There is no clear-cut answer to whether or not we should make cmis:document a subtype of cmis:item. The PRO is that both types represent standalone info objects. If they share the same type tree, then a cmis:item object has a chance to become a cmis:document object later on. A user does not need to make a hard choice between the two types up-front. The CON is of course the backward compatibility that cmis:document would no longer be a base type. This affects its baseId and parentId attributes, and the cmis:baseTypeId property.
One possibility is to allow cmis:document to continue to be a base type when an existing CMIS repository deployment is upgraded to v1.1, but encourage new deployments to define cmis:document as a subtype of cmis:item. This is not an ideal solution, but it would accommodate both.
On the other hand, keeping cmis:document as a separate base type allows a simpler test to check whether or not an object is a Document object.
I'll stay neutral on this question and invite more comments.
> 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]