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
