Второй документ, содержащий раздел 1.4 «Основные понятия», оказался уже интереснее, как в плане идей, которые не упоминались на первом этапе обсуждения, так и в плане замечаний.
Терминология
В документе появилась концепция «инвентаря» (inventory), представляющего собой набор объектов определенного типа (например, набор указаний по срокам хранения, или набор предопределенных типов объектов MoReq2010).
Другой терминологической новацией является отказ от именования модулей расширения ядра «опциональными», на том основании, что в отдельных странах и юрисдикциях эти модули могут оказаться обязательными.
Далее, авторы решили не пользоваться термином «дело» (file), «поскольку у него есть специфический смысл, не отраженных в требованиях ядра». Дела, как и другие наборы документов, теперь именуются агрегациями (aggregation).
Интероперабельность
Так, предусматривается, что все модули спецификаций MoReq2010 получат глобально-уникальные идентификаторы (universally unique identifiers, UUID), изменяющиеся при изменении версий (но не подверсий) модулей. Соответствующие спецификациям MoReq2010 системы должны будут при взаимодействии с другими системами сообщать идентификаторы тех модулей спецификаций, которые они поддерживают (раздел 1.4.1).
Глобально-уникальные идентификаторы предлагается присваивать каждой инсталляции каждой документной системы, чтобы по информации в метаданных документа можно было однозначно установить, через какие конкретно системы он прошёл. Лично мне кажется, что эта идея чревата риском раскрытия в ряде случаев конфиденциальной информации организаций (примеры такого рода уже известны, когда, например, по скрытым метаданным офисных файлов удавалось установить, какие лица и организации, в том числе внешние, участвовали в подготовке документа).
Далее, глобально-уникальными идентификаторами снабжаются все типы объектов, что позволяет один и тот же объект в одном программном продукте называть документом, а в другом, скажем, «досье». При взаимодействии систем типы определяются по глобально-уникальным идентификаторам.
Также снабжаются глобальными идентификаторами и функции, поддерживаемые MoReq2010-системой. Именно они записываются в протоколы событий, и, как считают разработчики, это позволит читать и анализировать сохраненную в метаданных историю событий каждого объекта даже после передачи его в другую систему. Такой подход призван заметить единый «журнал аудита», в котором документируются все действия и операции, но в формате, который способна понять только сама создавшая его система.
Вообще, интероперабельность систем позиционируется как один из основных приоритетов. Сообщается, что DLM-форум начал отдельный, более обширный по числу рассматриваемых вопросов проект по интероперабельности, в котором, например, рассматриваются вопросы взаимодействия документных и архивных систем в реальном времени, он-лайн передача и приём документов на архивное хранение. В определенном смысле, как пишут разработчики, MoReq2010 прокладывает дорогу для этого нового проекта.
Основным средством обеспечения интероперабельности в MoReq2010 будет лежащая в основе спецификаций XML-схема. Схема используется для экспорта документов и других взаимосвязанных объектов из одной документной системы и импорт их в другую систему, и ставится задача избежать при этом потери контекста, с тем, чтобы, например, начатый в одной системе жизненный цикл документа мог быть продолжен в другой – чего ранее достичь не удавалось. Спецификации исходят из того, что многие документы переживут свои документные системы, и их придется передавать из одной системы в другую несколько раз, и очень важно избежать каких-либо потерь при передаче.
Для достижения этой задачи, спецификации MoReq2010 будут существенно более жёсткими и предписывающими, чем предыдущие версии. В них не только устанавливается, какие процессы управления документами должны быть выполнены, но и как они должны быть выполнены, и это «зашито» в функциональную модель и в модель метаданных. Авторы подчёркивают, что недостаточно того, чтобы две системы использовали элементы метаданных с одним названием и со значениями, принадлежащими к одному типу данных – чтобы понимать данные друг друга, они должны опираться на единое применение и смысл значений этих метаданных. Разработчики надеются, что потери, связанные с налагаемыми на разработчиков более жёсткими ограничениями, будут с лихвой компенсированы благодаря стандартизации в масштабах отрасли и интероперабельности систем различных производителей.
Управление доступом
Несмотря на многочисленные протесты, раздававшиеся во время первого публичного обсуждения, авторы MoReq2010 предпочитают исходить из того, что документная система использует внешние средства управления группами и пользователями. Соответственно, MoReq2010 не содержит функциональных требований к управлению группами и пользователями (в отличие от ролей, которые рассматриваются как внутренние для документной системы) – см. 1.4.6.
В то же время не предполагается, что эти внешние службы будут обеспечивать долговременную сохранность информации, поэтому документная система должна сама регулярно опрашивать данные службы, отслеживать изменения и позаботиться о сохранении нужных ей сведений в составе метаданных.
Классификация
Цитируя авторов (п.1.4.7), «в отличие от предшествующих версий спецификаций, MoReq2010 рассматривает классификацию и агрегацию как два различных, но взаимосвязанных понятия». Коротко говоря, в целях классификации создается система рубрик (как правило, иерархическая, но не обязательно), и к рубрикам «привязываются» документы и их наборы-агрегации. Поскольку эта привязка логическая, то один и тот же документ, дело и т.д. могут появиться в нескольких рубриках. Это всё вроде бы неплохо и удобно.
Однако далее говорится, что если документ или набор документов «привязаны» к нескольким рубрикам, то обязательно будет выделена «первичная» рубрика (primary), а остальные будут считаться «вторичными» (secondary). Вот эту идею я считаю вредной, и у меня есть нехорошие подозрения относительно её появления: возможно, это следствие того, что в своей первоначальной концепции авторы запутались в механизме отслеживания сроков хранения объекта, если их несколько. Не спрашивайте меня, что в этом такого сложного :)
С моей точки зрения, такое разделение лишь усложнит управление документами и может быть в значительной мере потеряна та самая гибкость, которая возникает благодаря возможности помещать документ в несколько рубрик. Отказ от возможности устанавливать несколько сроков хранения одному объекту (и, соответственно, принятие во внимание только срока хранения, установленного для первичной рубрики) лишит специалистов по управлению документами гибкого и удобного инструмента управления сроками хранения в сложных ситуациях, часто встречающихся в современных условиях – и всё только потому, что разработчики не справились с простенькой (для программистов, конечно) задачкой.
С точки зрения разработчиков, концепция первичной классификации заменят концепцию типов документов, использовавшуюся ранее.
(Окончание следует, см. http://rusrim.blogspot.com/2010/12/moreq2010-ii.html )
Источник: сайт публичного обсуждения проекта MoReq2010
http://contribute2moreq.eu/portal/
