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