RFC 5261：补丁成功不等于基线版本正确

摘要

一套配置系统依次执行三项修改：增加新的策略节点、替换一个权限值、删除旧的例外项。前两项都在内存中的 XML 文档上成功，第三项却因为选择器同时命中两个节点而失败。系统写下“补丁失败”，值班人员于是以为没有任何东西发生。

RFC 5261 并没有替所有应用规定一个通用事务。规范说明，无法明确完成的操作构成错误，继续处理也几乎没有意义；但此前形成的中间文档是否已经写入、是否暴露给其他线程、是否能够回滚，仍由承载协议和实现决定。

这正是控制边界：停止后续运算，不等于撤销已经产生的状态。一个失败标签若没有操作序号、最后成功状态与持久化结果，就不是完整的事实记录。

每项操作都带有 sel。它使用受限的 XPath 1.0 子集，必须选出唯一目标。零个结果或多个结果都是错误。名称、通配符、谓词、字符串值、位置条件以及在数据模型支持时的 id()，都可以缩小范围。

这种唯一性只存在于当前输入树。它不能证明输入是最新修订，也不能证明节点对应一个跨版本不变的业务对象。插入一个兄弟节点会改变位置路径；属性值可能被复用；id() 又依赖模式、xml:id 与处理器是否真正提供 ID 语义。

因此，回执不能只保存选择器字符串。它还要保存基线字节、版本或 ETag、命中的展开命名空间路径与节点前像哈希。否则，日后能够重复的只是表达式，而不是当时的决策对象。

增加、替换和删除操作按顺序运行。每次成功得到的文档，会成为下一项操作的独立目标。若第一项在列表开头插入元素，第二项使用的位置编号就可能指向原先完全不同的节点；删除元素也可能让两段文本合并。

所以顺序不是装饰性的元数据。相同的几项操作，排列不同就可能命中不同对象，甚至产生不同的最终文档。只保存最终哈希会抹去这一因果链，只保存原始补丁又无法证明实现实际走过哪些中间状态。

对高后果变更，逐项操作序号和每个中间文档哈希应当成为回执的一部分。它们使审计者能够区分“规范允许的有序演算”与“实现跳步、重排或在错误后继续执行”。

XML 数据模型不允许相邻文本节点长期保持为两个独立节点。增加、替换或删除可能触发文本合并；RFC 5261 还提供对相邻空白文本进行处理的指令。这些规则让补丁能产生确定结果，却也意味着外观看似相同的排版变化可能改变后续选择器看到的树。

有些消费者错误地把空白或文本节点边界当成业务信号。补丁处理器可以完全合规，而下游程序仍因这种隐含假设而改变行为。需要验证的不是“XML 还能解析”，而是所有依赖它的应用不变量是否仍成立。

前缀只有局部作用域。补丁文档与目标文档可以用不同前缀表达相同的命名空间 URI，添加内容时处理器也可能重写前缀。RFC 5261 对默认命名空间还有经过定义的选择器行为，不能用未经检查的普通 XPath 直觉代替。

URI 相同而前缀不同，可以在 XML 模型中保持等价。可若下游代码把前缀拼写误当身份，合规重写仍可能触发故障。因此，回执应保存选择器当时展开后的命名空间绑定，而不仅是表面前缀。

RFC 5261 借助带注释的规范 XML 来界定其处理目标中的逻辑等价。这为可重复的 XML 运算提供了清晰坐标，却不会证明权限、价格、工作流阶段或签名范围仍然正确。

一份补丁可以保持良构、通过模式校验、得到稳定的规范化结果，同时把账户权限改到不该拥有的级别。XML 层的正确性是真实证据，但它只属于一个现实层。把它提升为业务批准，会把运算能力误写成决策权。

规范明确承认，有些应用需要包含冗余变更在内的完整版本历史，但并未规定一种通用做法。它也指出，简短的位置选择器会随插入和删除而变得脆弱。

这不是遗漏，而是责任分界。需要并发保护的系统必须增加源哈希、代际号、ETag 或其他前置条件；需要原子性的系统必须定义事务；需要授权的系统必须把主体、权限范围与目标基线绑在一起。

对安全策略、权利、计费、监管文件或其他重要对象，至少保留：

这张回执不会自动赋予补丁正当性。它的作用是阻止“选择器确实命中”被偷换成“组织批准了对正确版本的安全变更”。