[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=29726#action_29726 ]
Jay Brown edited comment on CMIS-723 at 4/3/12 2:23 PM:
--------------------------------------------------------
Good eye Florian! I missed the baseTypeId problem. In light of this issue I agree that we need placeholder base type. I don't care what the name is, but I think that David's cmis:item moniker is a pretty good one so I will just use that for now.
So comically that brings us all the way back to my original proposal at the start of this thread. Plus the additional BaseObjectTypeId I suggested on (16/Feb/12 03:51 PM).
re-copying it here and changing the name to cmis:item so as not to confuse things further.
<xs:simpleType name="enumBaseObjectTypeIds">
<xs:restriction base="xs:string">
<xs:enumeration value="cmis:document" />
<xs:enumeration value="cmis:folder" />
<xs:enumeration value="cmis:relationship" />
<xs:enumeration value="cmis:policy" />
<xs:enumeration value="cmis:item" />
</xs:restriction>
Each of these corresponds to a real object in the model. Support for cmis:item would be optional just like policy and relationship are today.
Item would not need to add any additional properties to cmis:object like the other base objects must.
To answer your questions about the properties of this object I would say they should be the same as cmis:object (* if cmis:object were actually in the model).
So listing them here for clarity:
cmis:objectId
cmis:baseTypeId
cmis:name
cmis:createdBy
cmis:creationDate
cmis:lastModifiedBy
cmis:lastModificationDate
cmis:changeToken
Attributes:
Queryable - Yes*.
Controllable - Yes*.
Fileable - Yes*.
*A given repository may expose cmis:item with any combination of these attributes that fit its own implementation. Eg. Queryable=true, Controllable=true,Fileable=false
was (Author: jay.brown):
Good eye Florian! I missed the baseTypeId problem. In light of this issue I agree that we need placeholder base type. I don't care what the name is, but I think that David's cmis:item moniker is a pretty good one so I will just use that for now.
So comically that brings us all the way back to my original proposal at the start of this thread. Plus the additional BaseObjectTypeId I suggested on (16/Feb/12 03:51 PM).
re-copying it here and changing the name to cmis:item so as not to confuse things further.
<xs:simpleType name="enumBaseObjectTypeIds">
<xs:restriction base="xs:string">
<xs:enumeration value="cmis:document" />
<xs:enumeration value="cmis:folder" />
<xs:enumeration value="cmis:relationship" />
<xs:enumeration value="cmis:policy" />
<xs:enumeration value="cmis:item" />
</xs:restriction>
Each of these corresponds to a real object in the model. Support for cmis:item would be optional just like policy and relationship are today.
Item would not need to add any additional properties to cmis:object like the other base objects must.
To answer your questions about the properties of this object I would say they should be the same as cmis:object (* if cmis:object were actually in the model).
So listing them here for clarity:
cmis:objectId
cmis:baseTypeId
cmis:secondatyObjectTypeIds
cmis:name
cmis:description
cmis:createdBy
cmis:creationDate
cmis:lastModifiedBy
cmis:lastModificationDate
cmis:changeToken
Attributes:
Queryable - Yes*.
Controllable - Yes*.
Fileable - Yes*.
*A given repository may expose cmis:item with any combination of these attributes that fit its own implementation. Eg. Queryable=true, Controllable=true,Fileable=false
> 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]