Публичное обсуждение MoReq2010, четвертый тур: Сроки хранения, передача и уничтожение документов - часть V

(Продолжение, предыдущую часть см. по адресу http://rusrim.blogspot.com/2010/09/moreq2010-iv.html )

6 Установление даты истечения срока хранения (см.
http://contribute2moreq.eu/portal/conceptpart4?pointId=1282666973501 )

Событие-триггер

MoReq1 (требование 5.1.11) и MoReq2 (требование 5.1.25) предусматривали использование одного из следующих событий-триггеров, от которых отсчитываются сроки хранения и определяется дата истечения срока хранения:

• Фиксированная дата, установленная в указаниях по срокам хранения,
• Дата открытия коллекции,
• Дата закрытия коллекции (например, дела – Н.Х.),
• Дата последнего пополнения коллекции,
• Дата последнего доступа к коллекции,
• Дата внешнего события, вводимая администратором.

Мы хотели бы узнать Ваше мнение о том, достаточно ли этих событий-триггеров, все ли они нужны, или же в ядро MoReq2010 нужно включить какие-то дополнительные события-триггеры.

Сроки хранения

MoReq1 и MoReq2 допускали только такие сроки хранения, в которых, начиная с даты события-триггера, отсчитывался точно определенный период времени. Предшествующие версии спецификации MoReq не позволяют отсчитывать сроки хранения с учётом годовых, квартальных, месячных или еженедельных циклов, в дополнение к событию-триггеру,

Например, можно было установить срок хранения типа «Уничтожить через 5 лет после даты события-триггера», но не было возможности определить срок хранения «Уничтожить через 5 лет после окончания календарного года, в котором произошло событие-триггер».

Мы хотели бы узнать Ваше мнение относительно того, насколько необходимо включить периодические циклы в раздел MoReq2010 о сроках хранения, и если их включать, то должны ли они быть частью ядра, или же включаться в составе модуля расширения.

7 Остаточные метаданные (stubs) (см.
http://contribute2moreq.eu/portal/conceptpart4?pointId=1282666988242 )

Общие положения

Когда коллекция уничтожается, от неё остаётся набор остаточных метаданных (в оригинале – просто «остаток» (stub) – Н.Х.). Точно так остаточные метаданные остаются от каждого документа, содержавшегося в коллекции.

Остаточные метаданные и контрольная информация

Существуют разногласия относительно того, насколько большая часть контрольной информации об объекте должна попасть в число его остаточных метаданных.

Если в остаточные метаданные включить всю контрольную информацию, то по этим данным документ по существу можно будет восстановить даже после его уничтожения.

Даже название документа может содержать существенную информацию, которая может быть отыскана и представлена в суд или контролирующим органам. Существуют также проблемы, связанные с ресурсами, необходимыми для хранения данных, и с законодательством о защите персональных данных.

В MoReq2010 мы намерены решить этот вопрос, предоставляя администраторам дополнительные возможности по конфигурированию контрольной информации (журнала аудита) СЭД. Администраторы не только смогут указать, какие события должны быть зафиксированы в составе контрольной информации об объекте,  но и будут иметь возможность указать, информация о каких из этих событий должна быть сохранена после уничтожения объекта.

Остаточные метаданные и пользовательские метаданные

В MoReq2010 будет явно указано, какие метаданные объекта сохраняются в составе остаточных метаданных, а какие не будут сохранены. Это, однако, будет относиться только к метаданным, определённым в MoReq2010.

Спецификации будут допускать возможность поддержки СЭД-решениями дополнительных пользовательских метаданных.

В MoReq2010 будет предусмотрено, что в случае уничтожения документа или коллекция, все их пользовательские метаданные также будут уничтожены, если только они не были специально отмечены как сохраняемые в составе остаточных метаданных после уничтожения объекта.

(Окончание следует, см. http://rusrim.blogspot.com/2010/09/moreq2010-vi.html )

Источник: Портал для публичного обсуждения MoReq2010
http://contribute2moreq.eu/portal/