chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <f...@apache.org>
Subject RE: Secondary Types - how to apply RM holds?
Date Fri, 01 Jul 2016 09:27:04 GMT
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:fmui@apache.org]
> Sent: Wednesday, June 29, 2016 3:36 AM
> To: dev@chemistry.apache.org
> Cc: Vyacheslav Pascarel <vpascare@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

Mime
View raw message