OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[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=29430#action_29430 ] 

Jay Brown commented on CMIS-723:
--------------------------------

Here is the update I promised in the last meeting:

Requirements:  
1. Give repositories the ability to expose any number of objects that are not one of the current 4 top level types (document, folder, relationship and policy)
2. Give clients the ability to perform all CRUD + Query operations on these new objects. 

Changes required to schema: None.  

Changes required to spec:
1. A single new optional 
    CreateObject(repositoryId, objectType, properties) 
method to the domain model.   (I will add this to the 1.1 wsdl once the TC has approved )  

2. A paragraph added to the spec clearly stating that a CMIS 1.1 client should be able to gracefully handle/ tolerate (default = ignore) classes of this new variety even if it does not include support for them.  Although support for them will not really require any additional logic over what is already present for CMIS 1.0 since there are no schema changes and a client can ignore the 1 additional method if they choose not to use it.    

Cost to Repositories that do not want to implement: None.
Cost to Clients that do not want to support: None.

If there are any concerns with this perhaps we can address them in this Jira issue between now and our next meeting.  If we can manage that then I propose we vote on this for inclusion into 1.1 during the March 5 meeting.    If anyone agrees or disagrees with this plan, please indicate here so I can get a feel for how much support we have for this. 

Thanks.

> 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]