You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Vyacheslav Pascarel <vp...@opentext.com> on 2016/06/28 18:21:26 UTC
Secondary Types - how to apply RM holds?
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
RE: Secondary Types - how to apply RM holds?
Posted by Vyacheslav Pascarel <vp...@opentext.com>.
Florian, thank you for clarification.
Vyacheslav Pascarel
-----Original Message-----
From: Florian Müller [mailto:fmui@apache.org]
Sent: Friday, July 1, 2016 5:27 AM
To: Vyacheslav Pascarel <vp...@opentext.com>
Cc: dev@chemistry.apache.org
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:fmui@apache.org]
> Sent: Wednesday, June 29, 2016 3:36 AM
> To: dev@chemistry.apache.org
> Cc: Vyacheslav Pascarel <vp...@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
RE: Secondary Types - how to apply RM holds?
Posted by Florian Müller <fm...@apache.org>.
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 \u201ccmis:rm_hold\u201d as a type inherited from
> \u201ccmis:secondary\u201d
> - Applying a first hold to an object adds \u201ccmis:rm_hold\u201d value to
> "cmis:secondaryObjectTypeIds" property and adds \u201ccmis:rm_holdIds\u201d
> 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 \u201ccmis:rm_hold\u201d value
> from "cmis:secondaryObjectTypeIds" and removes \u201ccmis:rm_holdIds\u201d
> property
>
> 2. In some rare cases:
> - CMIS repository defines \u201ccmis:rm_hold\u201d as a type inherited from
> \u201ccmis:secondary\u201d
> - CMIS repository may define many custom hold types inherited from
> \u201ccmis:rm_hold\u201d
> - Applying a first hold to an object adds \u201csome_hold_type_id\u201d value to
> "cmis:secondaryObjectTypeIds" and adds \u201ccmis:rm_holdIds\u201d property
> containing first hold id as a value
> - Applying any additional hold adds "another_hold_ids" to
> "cmis:secondaryObjectTypeIds" and \u201ccmis:rm_holdIds\u201d properties
> - Removing the last hold from an object removes \u201ccmis:rm_hold\u201d value
> from "cmis:secondaryObjectTypeIds" and removes \u201ccmis:rm_holdIds\u201d
> 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 <vp...@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 \u201c2.1.16 Retentions and Holds\u201d in CMIS 1.1 specification
>> leaves a few gray areas. According to specs:
>>
>> 1. \u201ccmis:rm_hold\u201d is a type inherited from \u201ccmis:secondary\u201d type
>>
>> 2. \u201ccmis:rm_hold\u201d defines \u201ccmis:rm_holdIds\u201d property that
>> contains list of holds applied to an object instance
>>
>> 3. A repository MAY de\ufb01ne its own secondary types for holds with
>> additional properties. Those types MUST be derived from \u201ccmis:rm_hold\u201d
>>
>> My confusion with the specification is that \u201ccmis:rm_hold\u201d and
>> inherited types are secondary types. If they are \u201cregular\u201d secondary
>> types then applying holds means that hold type ids should appear in
>> \u201ccmis:secondaryObjectTypeIds\u201d of object instance. In this case
>> \u201ccmis:rm_holdIds\u201d defined by \u201ccmis:rm_hold\u201d type seems to be
>> completely redundant.
>>
>> Can anybody clarify this confusion?
>>
>> Thanks,
>>
>> Vyacheslav Pascarel
RE: Secondary Types - how to apply RM holds?
Posted by Vyacheslav Pascarel <vp...@opentext.com>.
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 <vp...@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
Re: Secondary Types - how to apply RM holds?
Posted by Florian Müller <fm...@apache.org>.
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 \u201c2.1.16 Retentions and Holds\u201d in CMIS 1.1 specification
> leaves a few gray areas. According to specs:
>
> 1. \u201ccmis:rm_hold\u201d is a type inherited from \u201ccmis:secondary\u201d type
>
> 2. \u201ccmis:rm_hold\u201d defines \u201ccmis:rm_holdIds\u201d property that
> contains list of holds applied to an object instance
>
> 3. A repository MAY de\ufb01ne its own secondary types for holds with
> additional properties. Those types MUST be derived from \u201ccmis:rm_hold\u201d
>
> My confusion with the specification is that \u201ccmis:rm_hold\u201d and
> inherited types are secondary types. If they are \u201cregular\u201d secondary
> types then applying holds means that hold type ids should appear in
> \u201ccmis:secondaryObjectTypeIds\u201d of object instance. In this case
> \u201ccmis:rm_holdIds\u201d defined by \u201ccmis:rm_hold\u201d type seems to be
> completely redundant.
>
> Can anybody clarify this confusion?
>
> Thanks,
>
> Vyacheslav Pascarel