[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=29709#action_29709 ]
Jay Brown commented on CMIS-723:
--------------------------------
Correction. The current proposal is no longer to create a 5th base type. That was my original proposal prior to our workgroup meetings. Discussed further up the thread. We have since streamlined this proposal to not need cmis:custom anymore. The current proposal == no change to the current data model whatsoever and just one additional createObject method. This is why it is completely backward compatible for servers and clients that do not support it. For servers that do support it, their new/additional top base object(s) will appear at the top level as peers along with the other four cmis legacy base objects.
Explanation of the cmis:object placeholder:
I was showing cmis:object as an abstract base class because that is effectively what we have done in the 1.0 spec without overtly calling attention to it. Section 2.1.3.2.1 'Attributes common to ALL Object-Type Definitions', defines attributes that belong to all cmis:objects. Semantics in IMHO. Have a look at the UML diagram that we have created to illustrate this for the CMIS 1.1 draft here: http://tools.oasis-open.org/version-control/browse/wsvn/cmis/trunk/cmis-v1.1/tex/images/cmis11-highlevel-uml.png?rev=248&sc=1
Another example: look to how Chemistry's OpenCMIS had to model their API with a common CmisObject Interface. This interface defines properties which are common on all of the top level objects. (i.e. cmis:object)
So to continue my example. Here is a proposed 1.1 CMIS server that has a class of object named xx:foo which was equivalent to cmis:object but perhaps with a couple additional properties. It could just as well have 2 or N top level additional objects if they were significantly different and necessary.
cmis:object - abstract and invisible but omnipresent :)
|
| ---------------------------------------------------------
| | |
xx:foo cmis:document cmis: ...
Lets compare this with your suggestion which is not backwardly compatible with 1.0.
Can you think of some common scenarios that your proposed model would accommodate that the workgroup's proposal (as illustrated ) would not?
> 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]