[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (CMIS-714) Proposal to addRetention & Legal Hold Policies for next version of spec
[ http://tools.oasis-open.org/issues/browse/CMIS-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=26771#action_26771 ]
David Choy commented on CMIS-714:
---------------------------------
Additional comments on Proposal 0.3:
- Type hierarchy is normally used to define metadata extensions and inheritance. For "Repository Managed Retention", a type hierarchy is used to represent a File Plan, not for metadata inheritance. This is an unusual use of a type tree. First of all, a File Plan is a bit like a folder hierarchy which is an instance tree rather than a type tree. Secondly, if later on one wants to define metadata and inheritance, we will have a problem because the type hierarchy has already been used for another purpose.
- For "Client Managed Retention", instead of "expirationDate", how about specifying the "Duration of retention since startOfRetention"? Information-wise the two are equivalent but most business policies specify a retention duration instead of an actual expiration date (e.g. 7-year retention). For a chronological retention, the client would set both the Start and the Duration. For an event-based retention, the client would set the Duration but would leave the Start not set. When the event happens, the client would then set the Start which in turn triggers the Duration clock.
- Likewise, how about specifying a "Duration for Destruction" instead of a "destructionDate"?
- Should assignment rule and prolongation rule be repository-specific? Different repositories impose different constraints. Some allow a client to make correction if an error was made.
- How about changing "legal hold" to simply "hold"? There can be other reasons to put a hold on an object. The type name and the property name already reflect this.
- Need a description of the methods (and their precise effects) for applying/removing a retention or hold. For example, I am in favor of applyHold and removeHold methods instead of allowing a client to update holdIds directly.
> Proposal to add Retention & Legal Hold Policies for next version of spec
> ------------------------------------------------------------------------
>
> Key: CMIS-714
> URL: http://tools.oasis-open.org/issues/browse/CMIS-714
> Project: OASIS Content Management Interoperability Services (CMIS) TC
> Issue Type: New Feature
> Components: Domain Model
> Reporter: Martin Hermes
>
> A new Draft Version 0.2 of the proposal to add Retention & Legal Hold Policies has been uploaded. Main differences to the previous version:
> - A "Managed Retention Policy" has been added to support repository-determined retention periods (Thanks to Jens)
> - Previous Retention Policy with expiration date and optional destruction date has been split into two policies: Retention Policy and Destruction Policy
> Feedback appreciated
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]