Кратко

  • RFC 3076 не канонизировал нетронутый файл. XML-процессор сначала превращал поток октетов в набор узлов XPath, уже выполняя нормализацию и раскрытие данных.
  • Совпадение канонических байтов точно подтверждало результат для данного моделя, режима комментариев и алгоритма, но не восстанавливало оригинал и не сохраняло автоматически DTD, базовый URI или прикладную семантику.

Стабильное представление начиналось в середине цепочки

В марте 2001 года RFC 3076 и Рекомендация W3C Canonical XML Version 1.0 решали практическую проблему. XML допускал разные физические записи информации, которую многие приложения считали одинаковой. Могли различаться порядок атрибутов, кодировка, краткая форма пустого элемента, ссылки на символы и сущности. Подписи и сравнения целостности нуждались в общем воспроизводимом представлении.

Метод выдавал UTF-8, удалял XML-декларацию и DTD, раскрывал пустые элементы в начальный и конечный теги, задавал кавычки, экранирование, удаление лишних объявлений пространств имён и сортировку пространств и атрибутов. Включение комментариев было отдельным выбором. Повторное применение того же метода к корректной канонической форме ничего не меняло.

Однако формальным объектом был набор узлов XPath. Если поступал поток октетов, его требовалось сначала разобрать. Канонизатор получал документ после построения модели.

Парсер уже создал объект сравнения

XML-процессор нормализовал окончания строк и значения атрибутов, заменял CDATA содержимым, разрешал ссылки на символы и разбираемые сущности, мог добавлять атрибуты по умолчанию из DTD. Пространства имён становились узлами, последовательные символы — текстовыми узлами.

Поэтому разные источники намеренно сходились. Литеральный символ и его числовая ссылка, внутренняя сущность и её текст замены, <e/> и <e></e> могли создать одну модель. В этом состояла польза стандарта.

Но результат не позволял восстановить исходную запись. Первоначальная кодировка исчезала в UTF-8, XML-декларация и DTD удалялись, границы сущностей и CDATA растворялись, исходный порядок атрибутов заменялся заданным. Каноническая форма отвечала, как сериализовать модель, а не какие байты, ресурсы и правила её создали.

Цепочка доказательств должна начинаться раньше: хеш полученных октетов, URI и время получения, объявленная кодировка, версия и настройки парсера, режим валидации, политика внешнего подмножества и сущностей, фактические байты зависимостей, базовый URI и добавленные атрибуты. Из конечного хеша этого не восстановить.

Одинаковые байты могли утратить поведение

RFC перечислял сведения, которых нет в модели XPath: базовый URI, особенно для текста внешней разбираемой сущности; нотации и внешние неразбираемые сущности; типы атрибутов, объявленные в DTD.

Внешняя сущность может содержать относительный URI. Когда парсер вставляет её текст в основной документ, ссылка при потере исходной базы может разрешиться относительно другого места. Канонические байты остаются стабильными, а приложение получает другой ресурс. RFC рекомендовал использовать подходящий xml:base или заранее преобразовывать относительные URI в абсолютные.

DTD создаёт другую асимметрию. Атрибут по умолчанию уже может присутствовать в узле и выходе, хотя породившее его объявление удалено. Типы ID, IDREF, перечисление и NOTATION больше не сопровождают файл. Следующий парсер видит значение, но не обязательно первоначальный типовой контракт.

Нотации и неразбираемые сущности могли связывать внешние данные с приложением. Модель не сохраняла все такие связи. Редкость случая не делает происхождение ненужным там, где система от него зависит.

Набор узлов не был автоматически полной ветвью

Для фрагмента XPath передавал отдельные узлы. Выбор элемента не включал автоматически атрибуты, текст и потомков. Исключённый узел не печатался только потому, что присутствовал его родитель. При этом пропущенный предок мог влиять на пространство имён или наследуемые XML-атрибуты.

RFC возлагал на создателя набора ответственность за сохранение нужной семантики. Канонический вывод подмножества мог даже не быть корректным XML-документом. Слово «канонический» не означало полноту или автономность.

Эта граница предшествует вопросу RFC 3075. Там рассматриваются Reference и преобразования, покрытые подписью. Здесь — объект, созданный парсером до появления байтов. Корректная подпись не восполняет незафиксированное происхождение разбора.

Канонический не означал любую возможную эквивалентность

RFC не делал форму критерием «тогда и только тогда» для всех смыслов. Приложение могло игнорировать часть пробелов или считать black и rgb(0,0,0) одним цветом. Другие спецификации могли добавлять правила. Разные формы иногда оставались эквивалентными для конкретной задачи.

Общей нормализации модели символов Unicode тоже не было. Префиксы пространств имён сохранялись, поскольку их переписывание могло повредить XPath или QName-подобные значения в тексте и атрибутах. Получился ограниченный исполнимый договор, а не универсальная машина смысла.

Позднейшая работа снова показала роль контекста

Записка W3C 2006 года описала, как C14N 1.0 мог скопировать относительный xml:base на выбранного потомка, не составив путь пропущенных предков, и тем самым изменить действующий URI. Появление xml:id также показало, что идентификатор нельзя наследовать как обычный атрибут пространства XML.

Canonical XML 1.1 исправил оба правила в 2008 году: запретил наследование xml:id и специально обрабатывал путь xml:base. Это доказательство эволюции, а не отказа каждой прежней реализации. Exclusive XML Canonicalization решал проблему пространства имён перемещённого фрагмента. RFC 3275 применил C14N 1.0 в XML Signature. Ни один слой не превратил результат в доказательство исходных байтов или полномочия.

Что сохранять

Нужно хранить исходные октеты, источник, кодировку и хеш; парсер и настройки; валидацию; использованные DTD, каталоги и сущности; базовый URI; атрибуты по умолчанию; выбор XPath и результат; режим комментариев; метод и версию; канонический вывод. Затем идут результат сравнения или подписи, прикладное правило эквивалентности, решение и наблюдаемый эффект.

Позднейшие идеи Lu Heng о работающем коде и слоях реальности служат явно обозначенной аналитической линзой. Воспроизводимые байты сильнее ярлыка, но квитанция исполнения не присваивает историю источника, власть или результат.

Источники