[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Issue Comment Edited: (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=29768#action_29768 ]
Jay Brown edited comment on CMIS-723 at 4/3/12 2:23 PM:
--------------------------------------------------------
Regarding your comment about the properties of the new object being restricted to the following: (comment indicated by > prefix)
>* Properties:
>cmis:objectId, cmis:baseTypeId, cmis:objectTypeId, cmis:creationDate
>(That is, the following properties of cmis:document are excluded: cmis:name,
>cmis:createdBy, and all properties pertaining to update and content stream. There are
>lots of R/O content out there. For them, all the support for update are unnecessary.)
Although I don't feel strongly about this, I would lean towards having the same base properties ** that are currently present in the other 4 base object types similarly present in the new base type. There is a nice symmetry and simplicity to this. Also I don't believe any of these properties currently refer to content streams in any way. And with regard to R/O content, I would think the same could be said for the other objects types as well, yet repositories still can represent R/O objects without issues using the current model. For Example, IBM's CMOD repository exposes mainframe greenbar reports through CMIS as all R/O cmis:document objects, invisibly rendered as PDFs.
**See my previous comment on 09/Mar/12 12:00 PM for a list of these properties.
was (Author: jay.brown):
Regarding your comment about the properties of the new object being restricted to the following: (comment indicated by > prefix)
>* Properties:
>cmis:objectId, cmis:baseTypeId, cmis:objectTypeId, cmis:creationDate
>(That is, the following properties of cmis:document are excluded: cmis:name,
>cmis:createdBy, and all properties pertaining to update and content stream. There are
>lots of R/O content out there. For them, all the support for update are unnecessary.)
Although I don't feel strongly about this, I would lean towards having the same 10 base properties ** that are currently present in the other 4 base object types similarly present in the new base type. There is a nice symmetry and simplicity to this. Also I don't believe any of these properties currently refer to content streams in any way. And with regard to R/O content, I would think the same could be said for the other objects types as well, yet repositories still can represent R/O objects without issues using the current model. For Example, IBM's CMOD repository exposes mainframe greenbar reports through CMIS as all R/O cmis:document objects, invisibly rendered as PDFs.
**See my previous comment on 09/Mar/12 12:00 PM for a list of these properties.
> 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]