[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (CMIS-723) Need to express othercmis:object types to clients.
[ http://tools.oasis-open.org/issues/browse/CMIS-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=26334#action_26334 ]
Bram de Kruijff commented on CMIS-723:
--------------------------------------
From the comment above I see some consensus on the idea that there are types that do not fit cmis:document. Exposing cmis:object to be able to extend from that seems lo me. It provides a very flexible mechanisms and also the logical extension point for defined types (base or mixin) within the spec like for example groups/users etc.
I assume (and got from the meeting) that the cmis:custom/any/data proposals all come from a backward compatibility concern right? In an ideal world all would just extend from cmis:object but exposing this would break 1.0 clients. Still, I think I think David Choy suggested maybe even stripping cmis:document by moving stuff to mixins (like content-stream?). A question I have is whether this concern is still valid for 2.0 and whether it would be possible/desirable to version the entire api?
Our use-cases do require custom types to be in some way (quoting Florent) folderish. Basically our "web content domain" (let's call it WCM) has composite content, that due to lifecycle and granularity, can not be naturally contained in one content-stream. So for example I need type Page that has a one to many relation on objects of type Version (which itself is versionable). That means that Page is folderish or we can in some way use relationships with different semantics. Eg a Relationship with parent-child semantics would allow me to express that deleting an object of type Page implies the deletion of it objects of type Version attached.
Furthermore I think that the current Relationship, being non-invasive, not covers our needs as ideally adding an object of type Version to and object of type Page would effect the versioning state of the Page object.. I would like to be able to extend gx:page from cmis:object (because it has no content-stream) and add a named relationship property that contains one or more references to other cmis:object instance with implicit/explicit defined semantics. As a result I would be able to "add" a Version to a Page, affecting versioning state of the Page and when deleting the Page it would imply deleting the Version instances as well.
Again I think this is basically a more generic way of expressing the implicit folder to file relationships, but would allow for more different types of semantics to be expressed defined partially by the spec and possibly as vendor (or even application) specific extensions.
I'm sure that this use-case goes beyond the scope of this issue, but I wanted to paint a complete picture of why I am interested in it. In my view the combination of cmis:object exposure, mixins and a revisit of relationships could really open up CMIS up to a wider range of applications.
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]