Еще два аспекта, которые явно не были явно помянуты в прошлом моем постинге (http://www.livejournal.com/users/ailev/279047.html) и на необходимость явной фиксации которых были пожелания в телефонных разговорах :
1. Новостную метафору можно распространять не только вовне, но и внутрь организации, а именно -- в документооборот. В "электронном документообороте" и тем более всяких там "воркфлоу" исчезают традиционные понятия "положить в папку сверху", "документ должен вылежаться" и прочие бюрократические техники. Но можно просто перейти на новостную метафору, когда совещание и его решения становятся событиями, а по поводу этих событий формулируются новости, заметки, запросы и т.д.. Добавляется маленькая надстройка: обязанность реагировать на определенные новости. Так в фирмах требуют, чтобы сотрудник был подписан на ряд рассылок и своевременно реагировал на проходящие в них материалы. Вот-вот: чиновник может быть подписан на ряд новостных фидов в обязательном порядке и должен реагировать на проходящие в этих (например, динамически возникающих) фидах материалы. В итоге -- при соединении с административным учетом -- возникает та самая помесь среды координации деятельности (groupware, поддерживается блоговой-новостной частью) и среды бюрократической фиксации императивов (собственно документооборот, поддерживается официальным учетом императивов, как "новостей административной жизни"). То есть метафора растет в сторону оборота выписок и поручений из учетных систем, как системы обмена новостями.
2. Учетная система может архитектурно использовать нотаризацию "новостей входа" и "новостей выхода". То есть мы можем нотаризовать или поручения на входе (оператор заполняет формочку-поручение на изменение состояния учета, и это является новостью), причем по этим поручениям формально может быть восстановлено состояние учета (юридически достоверное состояние базы данных учета) на любой момент времени. Или наоборот, мы нотаризуем не поручения, а выписки из состояния учетной системы на момент изменения. Разница там юридическая: в первом случае мы нотаризуем поручения и потом легко разбираемся, кто там чего нахомутал на входе, что у нас возникло странное итоговое сотояние учета (но формально юридический статус в этот момент еще не присвоен, учета не произошло), а во втором случае мы нотаризуем реальное состояние учета (нотаризуется выписка, а не поручение), что более корректно, но чуть сложнее цепочка по верификации произошедших "неожиданных" изменений. Далее задаются разные вопросы на предмет того, что ежели нотаризовать только поручения, то само состояние учета можно будет поправить "руками" так, что оно будет не соответствовать этим поручениям, и разница будет замечена очень не скоро и только в результате очень тяжелых операций накатки огромных логов. Впрочем, и по нотаризации по выпискам есть свои проблемы.
3. Ежели отвлечься от того, выписки или поручения нотаризуются, то учетная система предъявляет фид из новостей в формате "документа общего вида" (этот формат, учитывающий в XML особенности отечественного документооборота, уже внесен Минэкономразвития в ИАЭГ), который становится телом новости в формате NewsML. Дальше нотариус кушает этот фид, возвращая квитанцию о том, что он его скушал, а затем очищеный от закрытой информации фид с сохранением отметок нотариуса поступает в систему раскрытия информации, которая возвращает свои отметки о выполнении обязанностей по раскрытию. Итого закрытая информация хранится в двух местах, а раскрываемая -- в трех местах. Механизмы "отзыва дезинформации" (исправления ошибок) или "отзыва закрытой, но случайно раскрытой информации" делаются обычными новостевыми механизмами и штатными средствами NewsML. Этот механизм не накладывает никаких ограничений на архитектуру самой учетной системы, а вот вопросы по п.2 -- на эту архитектуру ой как влияют.
Но лёд тронулся, господа присяжные заседатели. Проект пошёл.