[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=29675#action_29675 ] Bram de Kruijff commented on CMIS-723: -------------------------------------- {quote} . If we can manage that then I propose we vote on this for inclusion into 1.1 during the March 5 meeting. If anyone agrees or disagrees with this plan, please indicate here so I can get a feel for how much support we have for this. {quote} Still +1 from me. Below some considerations and question marks that popped up while reviewing the cmis-v1.1-wd02 1) This proposal suggest that custom types can be added by extending an abstract cmis:object just like existing core base types do. At the same time secondary objecttypes proposes the new "marker interface" type cmis:secondary, which to me feels a little asymmetric. Why would a secondary type not just be a regular type with properties indicating it can not be instantiated and can be mixed in (creatable=false;isSecondaryType=true)? 2) In more detail this proposal will probably also affect some spec constraints on repository services. Eg. createType states "Creates a new type definition that is a subtype of an existing specified parent type" which may be no longer true? Also . I'm not realy sure where we stand on content streams and versioning. > 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]