[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=29198#action_29198 ]
Jay Brown commented on CMIS-723:
--------------------------------
As a starting point for our conversations in the working group meeting tomorrow I would like to re-iterate what I am now advocating for this new 5th object type. The name for this object will be cmis:foo for this discussion since the official name can be determined later and I don't want to prejudice anyone against this object based on a hastily suggested temporary name.
Attributes and Verbs ******
1.cmis:foo is direct descendent of cmis:object (a peer to document, relationship, policy and folder) with no additional properties, attributes necessary. Thus the new object will have an Id property and a arbitrary collection of cmis property values.
2.Attributes: cmis:foo will have the same 16 attributes that are defined in the 1.0 spec for cmis:object in section 2.1.3.2 (e.g. id, localName, queryName, etc)
3.The following (already existing ) verbs will apply naturally (i.e. without any modification to the methods as currently defined) to cmis:foo:
[GetObject, deleteObject, moveObject, addObjectToFolder, removeObjectFromFolder, applyPolicy, removePolicy, *getACL, *applyACL]
4.The following new verb(s) will be created exclusively for this new object type:
[CreateObject ()- which will have the parameters as 1.0 createRelationship]
Symbiosis with Secondary types ******
Use and extension of cmis:foo is meant to go hand and hand with the implementation of secondary types. When used in combination with secondary types cmis:foo will make it possible for a repository to have CMIS supported objects that have a mixture of all of the other four 1.0 base type's attributes without violation of the rules of inheritance. For example if a repository has defined secondary types for fileable, versionable and hasContent: It could then create a new subclass of foo named metadataOnlyDoc with the fileable type secondary type but that was not versionable nor had any content streams. This would have been impossible with just secondary types (for example) since a subclass of document requires that documents have these attributes.
This allows us to extend this functionality while preserving complete backward compatibility with 1.0.
> 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]