[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=29201#action_29201 ]
Jay Brown commented on CMIS-723:
--------------------------------
Notes from the working group on this subject held January 18, 2012
Attendees: Jay Brown, Bram de Kruijff, Alexander Haag, Karsten Eberding
We only had 4 attendees so we need to reschedule for a time when some of the other vendors can be represented but we did have a good 30 minutes discussion. Will send another email out to schedule the next meeting.
General notes:
It was noted that the new CreateObject () method which is the only new method required for this particular design could also be used to create all object types and this would be a more powerful way to do so than the current createXXX methods.
Noted that although this design works well with secondary types; it does not require implementation of secondary types to be used. It merely makes secondary types more powerful.
Alexander mentioned that he has a customer who is implementing their own custom P8 CMIS implementation where 'p8:custom' objects are modeled as subclasses of documents. Since this violates many rules it breaks their client when they encounter these objects. So we have a real world instance of a problem this would solve already.
Karsten suggested that this new base object type would be extremely useful for standards that used the new CMIS Repository Extensions mechanism.
http://tools.oasis-open.org/issues/browse/CMIS-693
(which is included in the 1.1 draft) Since now they would have a place to put their extension objects that do not conform to the other 4 base objects.
We all agreed that we need to hear from all of the vendors on this to see who can, and can not foresee a need for this in their own implementations. Hopefully everyone having an opinion on this can either attend the next working group or comment on this Jira Issue.
> 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]