[OASIS Issue Tracker] Commented: (CMIS-723) Need to express othercmis:object types to clients.

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/CMIS-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=26167#action_26167 ] 

Jay Brown commented on CMIS-723:
--------------------------------

As requested in our June 28 meeting; here is one example of the type problem that I was trying to solve by suggesting a new base type to the domain model (aka: cmis:custom or cmis:data / cmis:any)  

Our customers production repositories today are populated with a mixture of documents (some exactly like cmis:document) and another type of object that in many ways are like documents except they are not versionable and do not permit content streams.   (they ARE fileable however)  Objects that can be linked to (e.g. by a cmis:relationship) and can be saved, retrieved and queried.  Note these are all attributes that are valid for the base cmis:object type thus they fit in the model, just not the parts we have chosen to expose so far. 

There are several reasons that these objects cannot be subclasses of cmis:document but I think the 3 most important are:
(Note that 1 and 2  can be addressed by secondary types if we were to factor these out of cmis:document and into  hasContent and isVersionable secondary interfaces respectively)
1.They do not inherit some of the properties that are present on our base document type. (e.g. Mime Type, etc.)
2.Since they do not support content or versioning, the client will not get the expected results when they try to perform inherited base cmis:document type content +  checkin/out operations on them. 
3.(very important) They are not in the same query scope as our documents.  (separate logical table)


In answer to David Churchland's question above: I was not suggesting that these new objects be container types. 

> 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
>
> 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