[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=30052#action_30052 ]
Jay Brown commented on CMIS-723:
--------------------------------
Thanks for noticing that extra 9th property. I will update my earlier comment to include it after posting this.
To address your next point. If all that were in involved were just properties, then you could just fill in those inherited cmis:document properties with static system values and move on. However there is much more than just properties to consider. Verbs that apply to documents, and query scope; to name two. For example; the new object cannot be a subtype of document because:
- You cannot call Set/GetContent stream on them. (as you can with document)
- You cannot perform checkin/checkout on them (as you can with document)
- If they were treated as documents that would mean that a query of documents must return these other (not document) objects. Many vendors may not be able to scope these objects with documents in their queries because they are as different from Documents as Relationship objects. That is certainly the case for us.
I appreciate your second point about not bending to make this easy on Chemistry but rather to make this spec as useful and flexible as we can. I would be very happy with the new object whether it has 9 or 4 system properties. I just have a very-slight preference for the more homogeneous model. I think it is easier to build interfaces for. But I definitely see and appreciate your point about trimming the object down even further.
Finally to your last point about attributes. I was intending the new object to inherit all of the attributes that are common to all CMIS objects today. See section 2.1.3.2.1
'Attributes common to ALL Object-Type Definitions'
(in the new 1.1 draft) for a list of all 18 of these.
Do you mean that these (creatable, fileable, queryable, controllablePolicy, includedInSupertypeQuery, controllableACL, fulltextIndexed ) would be optional on the new type? If so I would lean towards keeping these the same as well. If you left them out then we would have to define what the default is for each in their absence. For example if queryable was not present, we would need to state that this meant (queryable = false). Seems more clear to have it explicitly set for each type definition.
> 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]