[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=29690#action_29690 ]
David Choy commented on CMIS-723:
---------------------------------
This is an attempt to address the issue from a slightly broader perspective, not an entirely different proposal.
If I understood the requirements correctly, we are looking for a new base type to represent generic, standalone objects much like Document objects except that it is leaner than the Document type. Specifically,
(1) This base type has all the properties of the Document type except those that pertain to versioning and content stream.
(2) This type is unlike the other base types (Folder, Relationship, and Policy) which have special semantics associating a member object with other objects.
(BTW, a broader need for containment relationship was mentioned here earlier. It would open a different bag of worms, and should perhaps be dealt with as a separate issue.)
Each base type in v1.0 was created to support a different object semantics. The proposed cmis:custom type seemed semantically the same as the Document type. They only differ in representation. From typing standpoint, we seem to need the equivalent of a supertype for the Document type. Thus, IMHO, the "proper"(?) way to do this is simply to define such a supertype explicitly. CMIS is going to grow and expand. We should minimize any adhoc-ness we introduce along the way.
(On the other hand, I would avoid defining a single, concrete, root type for all object types. This may be a desirable design for implementing a standalone system, but it would be a mistake as an interop standard. A single abstract root type, however, is ok if we have a need for it.)
If we take this approach, the following are some considerations.
(a) Naming
All base types are intended for customization by repository through subtyping. So the name "cmis:custom" seemed a bit awkward. The new type is no more and no less "custom" than the other base types. How about using a more neutral name, such as "cmis:item" or something better? I'd stay away from "cmis:object" since "object" represents everything in CMIS.
(b) Services
All v1.0 methods that are applicable to Document objects should work for objects of this type and its subtypes, except createDocument, createDocumentFromSource, content-stream and rendition services, and versioning services. We do need a createItem(?) service though.
(c) An optional feature?
IMHO, the definition of this new base type must be supported, but it may be an abstract type. A repository may use the "creatable" type attribute to disallow user to create object instances, and control the creation of subtype for cmis:item. The minimum change to upgrade a v1.0 implementation is just to add a new type definition.
(d) Backward compatibility
All Document objects should appear and behave the same as they are today. The only question is whether or not the Document type is considered a base type when cmis:item is supported. This affects the "baseId" type attribute and the "baseTypeId" property. I propose that for v1.1 the Document type may (continue to) appear as a base type. However, all new deployments of CMIS 1.1 repository should set cmis:item as the base type for the Document type and for all Document objects. (That's why I suggest the definition of cmis:item should always exist, as the base type for Documents if nothing else.)
For v2.0, we may consider creating secondary types for versioning and for content stream. The data model would then allow any object to be versioned and/or to have a content stream (albeit under repository control), including "custom" objects that may not need versioning and content stream initially. The Document type can continue to exist as a useful subtype of cmis:item. This is not just for backward compatibility. The Document type is not the same as adding versioning and content stream secondary types to cmis:item at the object intance level, and it would therefore continue to have its value.
(This is slightly different from my earlier thought.)
> 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]