Hi Florian, Thank you very much for your reply. So is valid to say?:
1. In most of the cases: - CMIS repository defines “cmis:rm_hold” as a type inherited from “cmis:secondary” - Applying a first hold to an object adds “cmis:rm_hold” value to "cmis:secondaryObjectTypeIds" property and adds “cmis:rm_holdIds” property containing first hold id as a value - Applying any additional hold adds hold id value to "cmis:rm_holdIds" - Removing the last hold from an object removes “cmis:rm_hold” value from "cmis:secondaryObjectTypeIds" and removes “cmis:rm_holdIds” property 2. In some rare cases: - CMIS repository defines “cmis:rm_hold” as a type inherited from “cmis:secondary” - CMIS repository may define many custom hold types inherited from “cmis:rm_hold” - Applying a first hold to an object adds “some_hold_type_id” value to "cmis:secondaryObjectTypeIds" and adds “cmis:rm_holdIds” property containing first hold id as a value - Applying any additional hold adds "another_hold_ids" to "cmis:secondaryObjectTypeIds" and “cmis:rm_holdIds” properties - Removing the last hold from an object removes “cmis:rm_hold” value from "cmis:secondaryObjectTypeIds" and removes “cmis:rm_holdIds” property I agree that the first scenario seems to be sufficient for most of the cases. I am just curious how to handle multiple "custom hold types" scenario and stay within CMIS specs. Regards, Vyacheslav Pascarel -----Original Message----- From: Florian Müller [mailto:f...@apache.org] Sent: Wednesday, June 29, 2016 3:36 AM To: dev@chemistry.apache.org Cc: Vyacheslav Pascarel <vpasc...@opentext.com> Subject: Re: Secondary Types - how to apply RM holds? Hi Vyacheslav, The idea is that secondary type cmis:rm_hold is sufficient to put an object under one or multiple holds. You apply the secondary type and set the multivalue property cmis:rm_holdIds. You can add and remove different holds on the object at any time by updating the property cmis:rm_holdIds. Usually, the hold IDs have a meaning in the context of the repository and an application. They can reference, for example, a lawsuit. But these semantics are out of the CMIS scope. A type derived from cmis:rm_hold is rather an exception. It allows repositories to provide additional information about holds. Because most CMIS clients don't understand the information (they can only display it), this not of much value. Nevertheless, the CMIS spec allows it to provide an easy data exchange between the repository and a specialized application. - Florian > Hi, > > The section “2.1.16 Retentions and Holds” in CMIS 1.1 specification > leaves a few gray areas. According to specs: > > 1. “cmis:rm_hold” is a type inherited from “cmis:secondary” type > > 2. “cmis:rm_hold” defines “cmis:rm_holdIds” property that > contains list of holds applied to an object instance > > 3. A repository MAY define its own secondary types for holds with > additional properties. Those types MUST be derived from “cmis:rm_hold” > > My confusion with the specification is that “cmis:rm_hold” and > inherited types are secondary types. If they are “regular” secondary > types then applying holds means that hold type ids should appear in > “cmis:secondaryObjectTypeIds” of object instance. In this case > “cmis:rm_holdIds” defined by “cmis:rm_hold” type seems to be > completely redundant. > > Can anybody clarify this confusion? > > Thanks, > > Vyacheslav Pascarel
