Florian, thank you for clarification. Vyacheslav Pascarel
-----Original Message----- From: Florian Müller [mailto:[email protected]] Sent: Friday, July 1, 2016 5:27 AM To: Vyacheslav Pascarel <[email protected]> Cc: [email protected] Subject: RE: Secondary Types - how to apply RM holds? Hi Vyacheslav, the cases you have described are valid and covered by the CMIS spec. I guess most clients will only check the existence and then the values of the property cmis:rm_holdIds. In this case it doesn't matter if the cmis:rm_hold type was applied or a type derived from it. A generic client wouldn't notice. A derived type may add more properties that a generic client would ignore and a specialized application could work with. You can even add multiple secondary types derived from cmis:rm_hold to an object. They would all share the cmis:rm_holdIds property and they would add new properties. If this makes sense depends on the repository and the use-case. If all these secondary types share more properties, it could make sense to add them directly to the cmis:rm_hold type. The CMIS spec allows the extension of the the predefined types. - Florian > 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:[email protected]] > Sent: Wednesday, June 29, 2016 3:36 AM > To: [email protected] > Cc: Vyacheslav Pascarel <[email protected]> > 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
