С точки зрения различных стандартов, законов и положений документ определяется примерно одинаково. Так или иначе, это информация на материальном носителе с реквизитами, позволяющими ее зафиксировать и идентифицировать, а также использовать в деловой практике. С точки зрения бумажного документа — достаточно, с точки зрения электронного — вроде бы тоже (но споры неизбежны), но вот с точки зрения логической программной схемы документа, позволяющей наиболее эффективно использовать его при хранении и обработке в электронных архивах, в СЭД, в других информационных системах, при передаче из одной точки в другую по каналам связи, единого взгляда нет.
Наиболее важный фактор, который определяет логическую программную схему документа — это задачи, которые будут решаться относительно документа. Будет ли это хранение, будет ли это активная обработка документа, нужно ли системе работать с содержимым документа, будет ли схема документа служить задаче обмена документами. Отсюда вытекают потребности: каким образом решать задачу сочетания тела и метаданных документа, как типизировать и классифицировать документы, каким образом строить версионность (и строить ли вообще). Есть ли необходимость вводить понятие жизненного цикла документа, нужно ли обеспечивать многоформатность документов, надо ли создавать сложные агрегации документов. Всплывают сотни факторов, включая многоязычность, аудит и связь электронного документа и его бумажного аналога.
Обычно ECM-система оказывается в роли этакого "крайнего" в данном вопросе, принимая на себя задачу создания такого "контейнера" для тела (тел) документа, чтобы обеспечить разрешение самых разнообразных ситуаций. В отличие от ECM-систем системам других классов приходится значительно легче, ведь они решают лишь подмножество задач: архивы (даже если это подмножество ECM-системы) — хранение единственно верного варианта документа, ERP — работа с структурированным телом, системы обмена и EDI-системы — маршрутизация документов и гарантия неизменности их значимой информации.
Даже стандарты не стремятся — и, на мой взгляд, это правильно — дать единственно верный путь для программной модели документа. Например, MoReq определяет документ больше с позиции его учета, CMIS — с позиции гарантированного доступа к разным репозиториям (ограничиваясь довольно упрощенной схемой доступа и допуская неслабую вариативность реализации). Стандарт, разработанный Гильдией Управляющих документацией, определяет модель сообщения, которая оперирует ограниченной моделью документа. Всё определяется задачами и ситуациями использования и реализуется в соответствии с принципом "лучше меньше да лучше".
Отсюда я делаю один довольно очевидный вывод. Со временем мы перейдем к электронным документам (т.е. в преобладающем большинстве случаев будем оперировать именно таким понятием в наших транзакциях). При этом останутся разные наследники текущих форматов с сотнями вариаций модели документов. Документ будет вынужденно преобразовываться, мигрируя от одной системы или организации к другой, проецируясь на разные программные схемы документов. Набор байтов, составляющих документ в одном месте и в одно время, будет гарантированно отличаться от набора байтов, составляющих тот же документ в другом месте и в другое время. Речь, оговорюсь, не только и не столько о формате документа, сколько о способе его восприятия информационной системой и доступности сведений о нем (истории, версий, различных метаданных, включая подписи) конечному пользователю.