Кратко

  • Самодельный «облегчённый» парсер часто принимает только форму собственного генератора и отвергает допустимые варианты XML, превращая деталь реализации в скрытый протокол.
  • Совместимость требует отдельных квитанций для байтов, кодировки, конфигурации парсера, infoset, валидации, пространств имён, канонизации, подписи, авторизации и результата.

Пока обе стороны использовали один генератор, система казалась совместимой. Затем партнёр переставил атрибуты, выбрал другие кавычки и вынес объявление пространства имён выше. Документ оставался законным XML, но частный парсер его отклонил.

Проблема возникла не из-за неоднозначности стандарта. Реализация молча объявила один способ сериализации единственным протоколом. Тесты проверяли совпадение с собственным выводом, а не способность принимать общий язык.

RFC 3470 вышел в январе 2003 года как Best Current Practice 70. Он не продвигает XML как лучший формат для любого протокола. Он требует от уже выбравших XML не подменять общий контракт удобствами одного стека.

Хорошо сформированный документ должен приниматься целиком

XML определяет базовые правила символов, элементов и атрибутов. Нехорошо сформированный документ нельзя частично интерпретировать: RFC 3470 допускает повторную передачу или остановку по правилам протокола, но не выбор понятных фрагментов.

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

Парсер преобразует октеты в XML Information Set. На пути участвуют кодировка, окончания строк, сущности, пространства имён и нормализация. Дерево приложения уже не является копией входного потока.

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

Частное подмножество создаёт двухуровневый стандарт

Разработчики часто ограничивают XML ради простоты: запрещают допустимые кодировки, требуют определённый порядок атрибутов, не принимают объявление XML или поддерживают только одну форму пустого элемента. Такое решение может быть внутренним профилем, но становится проблемой, когда не объявлено в протоколе и противоречит общим требованиям.

RFC 3470 советует избегать импровизированных синтаксических ограничений. Если нужна единая форма для сравнения или подписи, существует Canonical XML. Канонизация — общий алгоритм преобразования, а не повод заставить каждого отправителя копировать вывод одного генератора.

Совместимость проверяется негативными и вариантными тестами: иной порядок атрибутов, допустимые формы пространства имён, разные разрешённые кодировки, комментарии, инструкции обработки и пробелы в пределах контракта. Один круговой тест «наш генератор — наш парсер» доказывает только самосогласованность.

Минимальная общая спецификация должна фиксировать действительно необходимые инварианты. Всё остальное остаётся локальным выбором реализации.

Пространства имён требуют развёрнутых имён

URI пространства имён обозначает словарь. Его не обязательно загружать, и он не удостоверяет право отправителя представлять организацию из имени домена.

Пространство имён по умолчанию действует на элементы без префикса, но не на атрибуты без префикса. Частный парсер, который сравнивает текстовые префиксы или наследует namespace для атрибута визуально, меняет модель XML.

Неизвестные расширения требуют явной политики: игнорировать, сохранить, передать, отклонить или считать обязательными для понимания. Законность синтаксиса не выбирает поведение.

Инструкции обработки и комментарии не должны нести нормативные структуры. Нормальная обработка должна уметь их игнорировать, иначе скрытый канал становится ещё одной частной грамматикой.

Валидация зависит от указанного профиля

DTD, XML Schema и другие языки выражают разные ограничения. RFC 3470 подчёркивает, что часть синтаксических и семантических требований неизбежно остаётся в тексте спецификации и приложении.

Результат валидации должен называть профиль, версию, источник и параметры. Схема может добавить атрибут по умолчанию, которого не было в пакете. Тогда анализатор трафика и приложение видят разные данные без подделки.

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

Если две реализации используют разные версии схемы, их расхождение нельзя приписывать сообщению. Источником решения стал профиль.

Внешняя ссылка расширяет вход и сеть

Внешние сущности, удалённые схемы и относительные URI могут добавить материал, которого нет во входных октетах. Парсер способен инициировать запрос из более привилегированной сети, чем отправитель.

RFC 3470 рекомендует избегать объявлений сущностей в протоколах и запрещать произвольный внешний доступ при обработке недоверенного XML. Пять предопределённых сущностей и числовые ссылки на символы остаются локальными средствами.

xml:base требует правила приоритета относительно базы транспорта или контейнера. Иначе один относительный адрес у разных участников ведёт к разным объектам.

Для повторяемости сохраняют политику доступа, разрешённые URI и точное содержимое либо доказательство отключённой сети. Повторная загрузка адреса сегодня не воспроизводит вчерашнюю среду.

Канонизация не заменяет выбор объекта подписи

RFC 3076 задаёт Canonical XML для воспроизводимой сериализации набора узлов. RFC 3275 определяет ссылки и преобразования XML Signature. Успех относится только к выбранным данным.

Криптографическая квитанция включает ссылки, разрешение, преобразования, алгоритм канонизации, ключ и личность. Затем её область сравнивают с узлами, которые фактически использовало приложение.

Подписанное поддерево не защищает соседний неподписанный элемент или значение, добавленное другим профилем. Подлинная личность также не получает автоматического разрешения на действие.

Смысл, авторизация, предыдущее состояние, commit и подтверждённый результат следуют отдельными этапами.

Пробел может быть данными

XML передаёт символьную информацию, если протокол или схема не задают иную обработку. Красивое форматирование может изменить текст и вход подписи.

Порядок атрибутов, напротив, незначим, а их значения могут нормализоваться. Частный парсер часто ошибается сразу в обе стороны: игнорирует значимый пробел и требует незначимый порядок.

Контракт должен определить пробелы, смешанное содержимое, порядок элементов, применение атрибутов и сохранение расширений. Визуальное сходство не является тестом.

Ограничения ресурсов принадлежат реализации

XML не предоставляет встроенных конфиденциальности, целостности, аутентификации и авторизации. Код парсера обрабатывает управляемые противником глубину, длину, сущности и ссылки.

Следует фиксировать пределы размера, глубины, расширения, времени, памяти и сетевого доступа, а также полный откат при ошибке. Грамматически законный документ может требовать недопустимой работы.

RFC 8996 позже обновил контекст защиты, отказавшись от TLS 1.0 и 1.1. Современный транспорт не исправляет частную XML-грамматику и не доказывает прикладное разрешение.

Проверка совместимости по всей цепочке

Сохраните октеты и кодировку, парсер и настройки, решение о сформированности и полный отказ. Зафиксируйте сущности, базовый URI, внешние ресурсы и infoset. Укажите схему и валидацию.

Запишите развёрнутые имена, решение по расширениям, канонизацию, ссылки подписи и подтверждённую личность. После этого идут семантика, авторизация, исходное состояние, commit и конечный результат.

Заявление о совместимости требует повторения без внешней сети и на второй независимой реализации. Набор законных вариантов важнее совпадения с одним эталонным файлом.

Граница доказательства

Статья не обвиняет конкретный продукт или библиотеку и не утверждает, что всякое профилирование XML неверно. Профиль допустим, если он явный, общий, обоснованный и протестированный.

Она не повторяет материал BTW о YANG/XML, где рассматриваются эффективное дерево YANG, defaults, ревизии схемы, mount-контекст, datastore и сетевой эффект. Здесь предмет — общая граница между реализацией и языком протокола.

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

Итог прост: парсер, который понимает только собственный генератор, проверяет не XML-протокол, а замкнутую пару инструментов.

Sources