[OASIS Issue Tracker] Commented: (CMIS-669) add CMIS TypeMutability for next version of spec

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/CMIS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21851#action_21851 ] 

Jay Brown commented on CMIS-669:
--------------------------------

Thanks for the feedback Florian.  This is very useful.  Responses below.

CreateType: 
Understood. 
I still want to be able to name my new 'Invoice' type and have its ID to be something 'like' invoice if at all possible;  so how about this as an alternative:
The name submitted by the client is not guaranteed to be used by the server.  It will be treated as a recommendation only.   So for example.   We could have 3 typical outcomes when the client submits 'Invoice' as the id. 
1.  The server may return a new type with id='Invoice'
2.  The server may return a new type with an entirely different id, e.g. (FAF5D0C5-BBE9-4E47-BB17-C9FE63B4EE20)
3.  Server may tweak the recommendation to be something that looks like the recommended value but still compatible with the servers internal naming (i.e. 'Invoice_FAF5D0C5-BBE9-4E47-BB17-C9FE63B4EE20' )

Either way the client MUST always defer to the returned ID from the server. 
Sound ok?

deleteType:
Agreed.  Any restrictions that make this even simpler to implement are ok by me. 
We can say one of two things. 
1.  Deletion of a type will fail if there are any objects of that type present in the repository.  (I prefer this one for simplicity)
2.  Deletion of a type implies deletion of any corresponding types.  (i.e. If you delete type 'Invoice' the implementation will delete the type and any instances in one operation for you)


deleteTypeTree:
Since I was already on the fence on this one to begin with, I'm fine with killing it now. 
No deleteTypeTree. (will remove in next rev)


The capabilityTypeMutability enum suggestion:
I am fine with this as well.   
capabilityTypeMutability enum
can move to the scope of the individual types with one caveat.  Since this is now at the type level we will expressly NOT permit setting of these attributes on creation.   This capability will be assumed to flow by inheritance or something like it.    I.e.  If the type that I am extending is mutable, then it follows that my newly created type will be mutable too (in the same way). 

> add CMIS Type Mutability for next version of spec
> -------------------------------------------------
>
>                 Key: CMIS-669
>                 URL: http://tools.oasis-open.org/issues/browse/CMIS-669
>             Project: OASIS Content Management Interoperability Services (CMIS) TC
>          Issue Type: New Feature
>          Components: Domain Model
>         Environment: n/a
>            Reporter: Jay Brown
>
> Have submitted a draft to the TC documents, to get this discussion started.   See proposal for URL. 

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