Кратко

  • RFC 1197 описывал ODA как абстрактную архитектуру составных документов. Для практического обмена требовались document application profile и отдельное отображение его сущностей в модель каждой системы.
  • Финансируемый NSF проект EXPRES использовал NIST DAP и возможности Andrew, Diamond и Interleaf. RFC указывает участников и задачу, но не публикует метрики точности, round trip или распространения.
  • Последующие правила MIME/X.400 переносили тело ODA, profile и class раздельно. Неизменные байты не доказывали одинаковое понимание, отображение или редактирование документа.

Обмен начинался не с универсального редактора, а с границы

Office Document Architecture задумывался шире внутреннего формата одного текстового процессора. По RFC 1197, ISO 8613 и CCITT T.410 могли представлять многошрифтовый текст, растровые изображения и геометрическую графику. ODA применялся и в связанных стандартах, включая X.400.

Широта требовала абстракции. RFC приводит composite logical object classes как пример сущностей ODA и противопоставляет им привычные сущности вроде абзацев. Это не утверждение, будто ODA физически не мог нести похожую структуру. Общая архитектура сама не выбрала абзац как обязательный объект прикладного соглашения.

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

Профиль сужал обещание, карта соединяла его с программой

RFC 1197 называл необходимый слой document application profile, DAP. Профиль определял общие сущности внутри ODA. После этого каждой системе требовалось отобразить их на собственные сущности.

Владельцы решений здесь разные. Составитель профиля выбирает переносимое подмножество. Разработчик продукта решает, как оно становится локальным paragraph, style, page или graphic object.

Поэтому фраза «поддерживает ODA» слишком груба. Два продукта могут читать семейство формата и использовать разные DAP. Они могут заявлять один DAP, но по-разному реализовать optional property или extension. Проверяемая совместимость должна называть profile, version, class, расширения и обе карты.

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

EXPRES работал именно с различием краёв

National Science Foundation финансировал EXPRES для исследования электронной подачи научных предложений в виде ODA-документов. Группы Carnegie Mellon University и University of Michigan сотрудничали с McDonnell-Douglas Aerospace Information Systems, NIST и Interleaf.

В основе стратегий лежали NIST DAP и функции Andrew, Diamond и Interleaf. Перечень важен: профиль связывал не три одинаковых приложения, а три разных набора возможностей.

Mark Sherman опубликовал RFC в декабре 1990 года. Запись RFC Editor и запись IETF Datatracker относят его к категории Informational. Это не Internet Standard и не отчёт о массовом внедрении.

Документ занимает две страницы и отправляет читателя за полными стратегиями к отдельной книге 1991 года, которой нет в данном наборе источников. Поэтому нельзя придумывать проценты сохранённых объектов, визуальные сравнения, скорость, round trip или судьбу конкретной заявки.

Участники устанавливают происхождение опыта, а не бессрочную гарантию продуктов. Disclaimer также отделяет мнения авторов книги от политики организаций.

MIME понадобился profile рядом с типом

RFC 1341 в 1992 году определил ранний MIME subtype application/oda. Он указывал, что body содержит ODA в представлении ODIF. В Content-Type следовало также назвать DAP параметром profile; пример использовал profile=Q112.

Subtype и параметр отвечали на разные вопросы. Первый называл семейство представления, второй — выбранный прикладной контракт внутри семейства. Если бы имя ODA завершало смысл, второе поле не требовалось бы.

Header помогал выбрать обработчик. Он не подтверждал правильную реализацию Q112, отсутствие неизвестных сущностей, одинаковый layout или сохранённую редактируемую структуру. RFC 1341 сейчас obsolete; здесь он служит историческим свидетельством границы, не современной инструкцией.

Шлюз копировал тело и отдельно преобразовывал заявления

В 1993 году RFC 1494 определил эквивалентности между X.400 и MIME body parts. Для ODA conversion type назывался “Byte copy”: данные тела не нужно было перекодировать.

Одновременно X.400 object identifier для document-application-profile отображался в MIME profile, а document-architecture-class — в formatted, processable или formatted-processable. Тело, профиль и класс имели разные правила и разное происхождение.

При отсутствии параметров в направлении MIME к X.400 спецификация подставляла Q112 и formatted-processable. Шлюз мог искать характеристики внутри документа, но не был обязан: внутренние поля были optional.

Default устранял неопределённость исполнения, но не восстанавливал намерение отправителя. Аудит должен сохранять, было ли значение declared, extracted или defaulted.

Byte copy ограничивал доказательство конкретным шагом: gateway не изменил body bytes. Способность приёмника, толкование profile и точность локального отображения оставались отдельными вопросами.

“Conversion: None” не означало одинаковый результат

RFC 2161 в январе 1998 года вынес определения ODA для MIME/X.400 в отдельный Experimental RFC. Документ прямо говорит, что не является Internet Standard любого вида. Он сохранил profile, class, Q112 и три класса.

Для данных была указана “Conversion: None”. Это означало, что body остаётся ODA. Параметры, defaults, envelope identifiers и интерпретация программой никуда не исчезали. Два приложения могли получить один файл и построить разные native structures.

В разделе безопасности сказано, что сложные ODA structures затрудняют определение возможностей частей документа. Extensibility позволяет добавлять контент и менять угрозу со временем. Там же отмечено отсутствие известных тогда рисков, специфичных для ODA. Источник требует инвентаризации и повторной оценки, а не выдуманного исторического exploit.

Outer media type может не меняться годами, тогда как profile, extension set, parser и adapter обновляются. Поддержка должна быть привязана к версии и наблюдаемому результату.

Доказательство продолжалось после успешного разбора

Полная последовательность включает ODIF bytes, type, происхождение profile, class, действие gateway, возможности приёмника и local map. Затем идут rendering, сохранённая структура, editability, round trip и институциональный исход.

Hash доказывает целостность файла. Profile ограничивает заявленное подмножество. Версия adapter показывает правила. Сравнение результата отвечает, что произошло со страницей и структурой. Ранний факт нельзя повысить до позднего вывода.

Абзац из RFC 1197 не обесценивает абстрактный стандарт. Он показывает честное распределение труда. Архитектура несёт общую форму, профиль выбирает общий язык, края выполняют перевод, а получатель наблюдает, подходит ли документ задаче.

Источники и пределы

Источники не доказывают нынешнее использование, рыночную долю, качество продукта, измеренную точность EXPRES, известный инцидент или успех отдельной заявки.