Кратко

  • Успех по RFC 5261 доказывает, что селектор нашёл ровно один узел в предъявленном XML и заданная операция дала результат; он не доказывает, что документ был нужной текущей базовой версией.
  • Защитимый чек патча должен связывать байты и версию основы, контекст селектора, все промежуточные состояния, место ошибки, правило транзакции, смысловую проверку и наблюдение окончательного хранения и публикации.

История началась раньше, чем сохранили первый патч

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

RFC 5261 признаёт, что некоторым приложениям нужна полная история версий, в том числе внешне избыточных изменений. При этом он не навязывает универсальную модель истории. Это обязанность системы, которая использует формат.

Отсутствие требования в транспортном механизме не превращает историю в необязательную роскошь. Для решений с последствиями она является частью доказательства.

Один узел — только в пределах предъявленного дерева

Каждая операция несёт sel из ограниченного подмножества XPath 1.0. Выражение обязано выбрать один узел; отсутствие совпадения или несколько совпадений являются ошибкой. Имена, предикаты, значения, позиции и, при наличии поддержки, id() уточняют выбор.

Но уникальность относится именно к этому снимку. Вставка соседнего элемента меняет позиционный путь. Значение атрибута может использоваться снова. Семантика id() зависит от схемы, xml:id и процессора. Ни один из этих механизмов сам по себе не связывает узел с устойчивым деловым объектом и текущей редакцией.

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

Каждая операция создаёт основу для следующей

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

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

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

Ошибка не задаёт единый откат для всех систем

RFC 5261 считает ошибкой операцию, которую нельзя выполнить однозначно, и отмечает, что дальнейшая обработка едва ли разумна. Он определяет подробные элементы ошибок: не найденный узел, недопустимый тип, проблему пространства имён, неподдерживаемый ID и другие случаи.

Однако стандарт не устанавливает одну транзакцию хранения для всех применений. К моменту поздней ошибки предыдущие состояния могли остаться только в памяти, попасть в постоянное хранилище или стать видимыми другому потребителю. Границы commit и rollback принадлежат окружающему протоколу и реализации.

Фраза «патч завершился ошибкой» не описывает состояние. Нужны номер сбойной операции, последний успешный промежуточный хеш, факт записи и наблюдённый результат отката или фиксации.

Префикс пространства имён — не его идентичность

Префиксы имеют локальную область действия. Diff и цель могут использовать разные префиксы для одного URI; при добавлении содержимого процессор может переписать их. Для пространства имён по умолчанию RFC 5261 в определённых случаях задаёт собственное поведение селектора.

Смена префикса способна полностью сохранить смысл в модели XML. Но потребитель, который ошибочно принимает написание за идентичность, всё равно может изменить поведение. Соответствие процессора стандарту и правильность потребителя — разные проверки.

Каноническое равенство не равно равенству решений

Для детерминированной обработки механизм опирается на Canonical XML с комментариями. Он тщательно определяет обращение с текстом и пробелами, поскольку модель данных объединяет соседние текстовые узлы.

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

Историю и актуальность проектирует приложение

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

Системе, которой нужна защита от конкурирующих изменений, следует добавить хеш источника, номер поколения, версию или ETag. Для атомарности надо определить commit. Для законности — связать проверенного субъекта и объём его полномочий с точной базой.

Чек, отделяющий исполнение от решения

Для значимых обновлений следует хранить:

  • идентичность объекта, точные базовые байты, хеш, версию, ETag или поколение;
  • байты и хеш diff, тип носителя, кодировку, схему и удостоверенного субъекта;
  • порядковый номер операции, текст селектора и раскрытые привязки пространств имён;
  • путь, тип и хеш узла до изменения;
  • содержимое операции и хеш каждого промежуточного документа;
  • элемент ошибки, сбойный шаг и последнее успешное состояние;
  • правило отката или фиксации и наблюдённый результат;
  • итоговый хеш, проверку схемы и прикладной семантики;
  • подтверждение хранения, репликацию и видимую публикацию.

Такой чек не даёт патчу полномочий. Он не позволяет превратить утверждение «селектор совпал» в утверждение «организация одобрила нужное изменение правильной версии».

Sources