"Многоликий" документ
Как хранить различные представления документов в системе?
Как только документ попадает в СЭД, он перестает быть просто документом. Документ становится «стержнем», вокруг которого закручивается разнообразные данные, своеобразные слои: структурированная информация, права доступа, история работы и т.п. Одним из таких слоев является представление документа.
Довольно часто возникает потребность в работе с разными представлениями одного и того же документа. В повседневной жизни мы часто сталкиваемся c такими документами – любая html-страница например. Что касается документа в СЭД, то для него могут потребоваться, например, такие представления:
● версия в формате HTML для публикации на сайт;
● версия для печати (например, объединение многостраничных документов);
● версия в неизменяемом формате (например, PDF) для распространения электронных документов;
● версия для удобного редактирования самого текста;
● и многие другие для разнообразных производственных нужд.
Встает вопрос – в каком формате тогда хранить документы в СЭД? Какой формат хранения можно считать универсальным? Как осуществить механизм создания различных представлений (в тот же HTML например)?
Как решается проблема сейчас:
● Создается документ в любом удобном для преобразования формате (xml, plain text, Word ;-);
● По мере возникновения потребностей в других представлениях создается либо отдельный связанный документ в нужном представлении со своей структурированной информацией, либо создается версия документа;
● Преобразование происходит в рамках механизма Workflow с использованием сторонних инструментов (библиотек, API программ-редакторов, сторонних утилит);
● Созданный документ может быть сохранен в базе, а может удаляться после использования.
Возникает обычная дилемма – либо увеличивать объемы хранимых данных, либо увеличивать нагрузку на систему. В первом случае мы сталкиваемся с проблемами синхронизации различных представлений между собой. Во втором случае – теряем в масштабируемости системы.
Как хотелось бы организовать использование документа в идеале? Например, так: cам текст документа представляет собой «ядро», вокруг которого располагаются его различные представления, в которые ядро отражается по строго определенным правилам.
Пока единственный формат, который в какой-то степени подошел к этому – это XSL. Но и он не может удовлетворить следующие потребности:
● Удобное редактирование документа в формате, дружественному пользователю (WYSIWYG - What You See Is What You Get);
● Преобразование в «закрытые» форматы – далеко не все форматы поддерживают создания документов из XML;
● Полнотекстовый поиск.
Хотелось бы узнать, кто какие перспективы видит в этом направлении.
Комментарии 2
Другое дело, когда документ в процессе своего жизненного цикла меняется, приобретает новые характеристики, которые не могут быть сохранены в исходном формате. Например, в системе создали договор в формате Microsoft Word, далее документ был распечатан и передан контрагенту, контрагент подписал этот договор и передал его обратно. Отсканированный образ договора с подписями и печатями должен быть сохранен в системе на ряду с исходным документом Microsoft Word. При этом новое представление просто служит дополнительным подтверждением того, что документ был действительно подписан. Понятно, что оба такие представления должны быть каким-то образом связаны друг с другом в системе, чтобы предоставлять пользователям возможность, обращаясь к одному из документов, увидеть наличие другого.
Но в этом описанном примере, проблем с преобразованием, синхронизацией и т.п. не существует, т.к. оба представления могут существовать как отдельные документы обладающие своим набором характеристик.