Independent Submission E. Wilde
Request for Comments: 7351 UC Berkeley
Category: Informational August 2014
ISSN: 2070-1721
Independent Submission E. Wilde
Request for Comments: 7351 UC Berkeley
Category: Informational August 2014
ISSN: 2070-1721
A Media Type for XML Patch Operations
用于XML修补程序操作的媒体类型
Abstract
摘要
The XML patch document format defines an XML document structure for expressing a sequence of patch operations to be applied to an XML document. The XML patch document format builds on the foundations defined in RFC 5261. This specification also provides the media type registration "application/xml-patch+xml", to allow the use of XML patch documents in, for example, HTTP conversations.
XML修补程序文档格式定义了一个XML文档结构，用于表示要应用于XML文档的修补程序操作序列。XML修补程序文档格式建立在RFC 5261中定义的基础之上。该规范还提供了媒体类型注册“application/xml patch+xml”，以允许在例如HTTP会话中使用xml补丁文档。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7351.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7351.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Patch Documents . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Patch Document Format . . . . . . . . . . . . . . . . . . 3
2.2. Patch Examples . . . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Implementation Hints . . . . . . . . . . . . . . . . 9
A.1. Matching Namespaces . . . . . . . . . . . . . . . . . . . 9
A.2. Patching Namespaces . . . . . . . . . . . . . . . . . . . 10
Appendix B. ABNF for RFC 5261 . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Patch Documents . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Patch Document Format . . . . . . . . . . . . . . . . . . 3
2.2. Patch Examples . . . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Implementation Hints . . . . . . . . . . . . . . . . 9
A.1. Matching Namespaces . . . . . . . . . . . . . . . . . . . 9
A.2. Patching Namespaces . . . . . . . . . . . . . . . . . . . 10
Appendix B. ABNF for RFC 5261 . . . . . . . . . . . . . . . . . 12
The Extensible Markup Language (XML) [RFC7303] is a common format for the exchange and storage of structured data. HTTP PATCH [RFC5789] extends HTTP [RFC7231] with a method to perform partial modifications to resources. HTTP PATCH requires that patch documents be sent along with the request, and it is therefore useful for there to be standardized patch document formats (identified by media types) for popular media types.
可扩展标记语言（XML）[RFC7303]是结构化数据交换和存储的常用格式。HTTP修补程序[RFC5789]使用对资源执行部分修改的方法扩展了HTTP[RFC7231]。HTTP修补程序要求随请求一起发送修补程序文档，因此，对于流行的媒体类型，有标准化的修补程序文档格式（由媒体类型标识）非常有用。
The XML patch media type "application/xml-patch+xml" is an XML document structure for expressing a sequence of operations to apply to a target XML document, suitable for use with the HTTP PATCH method. Servers can freely choose which patch formats they want to accept, and "application/xml-patch+xml" could be a simple default format that can be used unless a server decides to use a different (maybe more sophisticated) patch format for XML.
XML修补程序媒体类型“application/XML patch+XML”是一种XML文档结构，用于表示应用于目标XML文档的操作序列，适合与HTTP修补程序方法一起使用。服务器可以自由选择他们想要接受的补丁格式，“application/xml patch+xml”可以是一种简单的默认格式，除非服务器决定对xml使用不同（可能更复杂）的补丁格式，否则可以使用它。
The format for patch documents is based on the XML patch framework defined in RFC 5261 [RFC5261]. While RFC 5261 does define a concrete syntax as well as the media type "application/patch-ops-error+xml" for error documents, it only defines XML Schema (XSD) [W3C.REC-xmlschema-1-20041028] types for patch operations. The concrete document format and the media type for patch operations are defined in an XSD defined in this specification.
修补程序文档的格式基于RFC 5261[RFC5261]中定义的XML修补程序框架。虽然RFC 5261确实为错误文档定义了具体语法以及媒体类型“application/patch ops error+xml”，但它仅为补丁操作定义了xml模式（XSD）[W3C.REC-xmlschema-1-20041028]类型。补丁操作的具体文档格式和媒体类型在本规范中定义的XSD中定义。
This specification relies on RFC 5261 but also requires that errata reported to date are taken into account. The main reason for the errata is the problematic ways in which RFC 5261 relies on XML Path Language (XPath) as the expression language for selecting the location of a patch, while at the same time XPath's data model does
本规范依赖于RFC 5261，但也要求考虑到迄今为止报告的勘误表。勘误表的主要原因是RFC 5261依赖XML路径语言（XPath）作为选择修补程序位置的表达式语言的方式存在问题，而XPath的数据模型却不这样做
not contain sufficient information to determine whether such a selector indeed can be used for a patch operation or should result in an error. Specifically, the problem occurs with namespaces, where XPath does not expose namespace declaration attributes, while the patch model needs them to determine whether or not a namespace patch is allowed. Appendix A contains more information about the general problem and errata reports.
未包含足够的信息，无法确定此类选择器是否确实可用于修补程序操作或是否应导致错误。具体来说，问题发生在名称空间中，其中XPath不公开名称空间声明属性，而补丁模型需要它们来确定是否允许使用名称空间补丁。附录A包含有关一般问题和勘误表报告的更多信息。
The following sections describe and illustrate the XML patch document format.
以下各节描述并说明了XML修补程序文档格式。
The XML patch document format is based on a simple schema that uses a "patch" element as the document element and allows an arbitrary sequence of "add", "remove", and "replace" elements as the children of the document element. These children follow the semantics defined in RFC 5261, which means that each element is treated as an individual patch operation, and the result of each patch operation is a patched XML document that is the target XML document for the next patch operation.
XML修补程序文档格式基于一个简单的模式，该模式使用“patch”元素作为文档元素，并允许任意顺序的“add”、“remove”和“replace”元素作为文档元素的子元素。这些子元素遵循RFC 5261中定义的语义，这意味着每个元素都被视为一个单独的补丁操作，每个补丁操作的结果都是一个补丁XML文档，它是下一个补丁操作的目标XML文档。
The following simple example patch document contains a single patch operation. This operation adds a new attribute called "new-attribute" to the document element of the target XML document. An XML patch document always uses a "patch" element in the "urn:ietf:rfc:7351" namespace as the document element that contains zero or more patch operation elements, which are also in the "urn:ietf:rfc:7351" namespace.
下面的简单示例修补程序文档包含一个修补程序操作。此操作向目标XML文档的文档元素添加一个名为“new attribute”的新属性。XML修补程序文档始终使用“urn:ietf:rfc:7351”命名空间中的“patch”元素作为包含零个或多个修补程序操作元素的文档元素，这些元素也位于“urn:ietf:rfc:7351”命名空间中。
<p:patch xmlns:p="urn:ietf:rfc:7351">
<p:add sel="*" type="@new-attribute">value</p:add>
</p:patch>
<p:patch xmlns:p="urn:ietf:rfc:7351">
<p:add sel="*" type="@new-attribute">value</p:add>
</p:patch>
The following more complex example patch document uses the example from RFC 5261, Section A.18 (but changing the example namespaces to example.com URIs); it uses the same "patch" element and XML namespace as shown in the simpler example. It shows the general structure of an XML patch document with multiple operations, as well as an example of each operation.
以下更复杂的示例修补程序文档使用RFC 5261第A.18节中的示例（但将示例名称空间更改为example.com URI）；它使用相同的“补丁”元素和XML名称空间，如更简单的示例所示。它显示了包含多个操作的XML修补程序文档的一般结构，以及每个操作的示例。
<p:patch xmlns="http://example.com/ns1"
xmlns:y="http://example.com/ns2"
xmlns:p="urn:ietf:rfc:7351">
<p:add sel="doc/elem[@a='foo']">
<!-- This is a new child -->
<child id="ert4773">
<y:node/>
</child>
</p:add>
<p:replace sel="doc/note/text()">Patched doc</p:replace>
<p:remove sel="*/elem[@a='bar']/y:child" ws="both"/>
<p:add sel="*/elem[@a='bar']" type="@b">new attr</p:add>
</p:patch>
<p:patch xmlns="http://example.com/ns1"
xmlns:y="http://example.com/ns2"
xmlns:p="urn:ietf:rfc:7351">
<p:add sel="doc/elem[@a='foo']">
<!-- This is a new child -->
<child id="ert4773">
<y:node/>
</child>
</p:add>
<p:replace sel="doc/note/text()">Patched doc</p:replace>
<p:remove sel="*/elem[@a='bar']/y:child" ws="both"/>
<p:add sel="*/elem[@a='bar']" type="@b">new attr</p:add>
</p:patch>
As this example demonstrates, both the document element "patch" and the patch operation elements are in the same XML namespace. This is the result of RFC 5261 only defining types for the patch operation elements, which then can be reused in schemas to define concrete patch elements.
如本例所示，document元素“patch”和patch operation元素都位于同一个XML名称空间中。这是RFC 5261仅为补丁操作元素定义类型的结果，然后可以在模式中重用这些类型来定义具体的补丁元素。
RFC 5261 defines XSD [W3C.REC-xmlschema-1-20041028] for the patch operation types. The following schema for the XML patch media type is based on the types defined in RFC 5261, which are imported as "rfc5261.xsd" in the following schema. The schema defines a "patch" document element, and then allows an unlimited (and possibly empty) sequence of the "add", "remove", and "replace" operation elements, which are directly based on the respective types from the schema defined in RFC 5261.
RFC 5261为修补程序操作类型定义XSD[W3C.REC-xmlschema-1-20041028]。XML修补程序媒体类型的以下模式基于RFC 5261中定义的类型，这些类型在以下模式中作为“rfc5261.xsd”导入。模式定义了一个“补丁”文档元素，然后允许“添加”、“删除”和“替换”操作元素的无限（可能为空）序列，这些操作元素直接基于RFC 5261中定义的模式中的相应类型。
<xs:schema targetNamespace="urn:ietf:rfc:7351"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import schemaLocation="rfc5261.xsd"/>
<xs:element name="patch">
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="add" type="add"/>
<xs:element name="remove" type="remove"/>
<xs:element name="replace" type="replace"/>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:schema>
<xs:schema targetNamespace="urn:ietf:rfc:7351"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import schemaLocation="rfc5261.xsd"/>
<xs:element name="patch">
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="add" type="add"/>
<xs:element name="remove" type="remove"/>
<xs:element name="replace" type="replace"/>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:schema>
Since the semantics of the XML patch operations are defined by RFC 5261, please refer to the numerous examples in that specification for more XML patch document examples. All the examples in RFC 5261 can be taken as examples for the XML patch media type, when looking at them with two minor changes in mind.
由于XML修补程序操作的语义是由RFC 5261定义的，请参阅该规范中的众多示例，以了解更多XML修补程序文档示例。在考虑到两个小的变化时，RFC 5261中的所有示例都可以作为XML修补程序介质类型的示例。
The two differences are that XML patch documents always use the "patch" element as the document element and that both the "patch" element and the individual operation elements in XML patch documents have to be in the XML namespace with the URI "urn:ietf:rfc:7351".
两个不同之处在于，XML修补程序文档始终使用“patch”元素作为文档元素，并且“patch”元素和XML修补程序文档中的各个操作元素都必须位于URI为“urn:ietf:rfc:7351”的XML命名空间中。
For example, consider the patch example in RFC 5261, Appendix A.1, "Adding an Element". In this example, the patch is applied to the following XML document:
例如，考虑RFC 5261中的补丁示例，附录A.1，“添加元素”。在本例中，修补程序应用于以下XML文档：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
</doc>
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
</doc>
The patch example is based on the following patch document (with the element and namespace changes described above):
修补程序示例基于以下修补程序文档（具有上述元素和命名空间更改）：
<?xml version="1.0" encoding="UTF-8"?>
<p:patch xmlns:p="urn:ietf:rfc:7351">
<p:add sel="doc"><foo id="ert4773">This is a new child</foo></p:add>
</p:patch>
<?xml version="1.0" encoding="UTF-8"?>
<p:patch xmlns:p="urn:ietf:rfc:7351">
<p:add sel="doc"><foo id="ert4773">This is a new child</foo></p:add>
</p:patch>
Applying the patch results in the following XML document:
应用修补程序将导致以下XML文档：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<foo id="ert4773">This is a new child</foo></doc>
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<foo id="ert4773">This is a new child</foo></doc>
The Internet media type [RFC6838] for an XML patch document is application/xml-patch+xml.
XML修补程序文档的Internet媒体类型[RFC6838]为application/XML patch+XML。
Type name: application
类型名称：应用程序
Subtype name: xml-patch+xml
子类型名称：xml修补程序+xml
Required parameters: none
所需参数：无
Optional parameters:
可选参数：
charset: Same as charset parameter for the media type "application/xml" as specified in RFC 7303 [RFC7303].
字符集：与RFC 7303[RFC7303]中指定的媒体类型“application/xml”的字符集参数相同。
Encoding considerations: Same as encoding considerations of media type "application/xml" as specified in RFC 7303 [RFC7303].
编码注意事项：与RFC 7303[RFC7303]中指定的媒体类型“application/xml”的编码注意事项相同。
Security considerations: This media type has all of the security considerations described in RFC 7303 [RFC7303], RFC 5261 [RFC5261], and RFC 3470 [RFC3470], plus those listed in Section 4.
安全注意事项：此媒体类型具有RFC 7303[RFC7303]、RFC 5261[RFC5261]和RFC 3470[RFC3470]中描述的所有安全注意事项，以及第4节中列出的安全注意事项。
Interoperability considerations: N/A
互操作性注意事项：不适用
Published specification: RFC 7351
已发布规范：RFC 7351
Applications that use this media type: Applications that manipulate XML documents.
使用此媒体类型的应用程序：操作XML文档的应用程序。
Additional information:
其他信息：
Magic number(s): N/A
Magic number(s): N/A
File extension(s): XML documents often use ".xml" as the file extension, and this media type does not propose a specific extension other than this generic one.
文件扩展名：XML文档通常使用“.XML”作为文件扩展名，并且此媒体类型不建议使用此通用扩展名以外的特定扩展名。
Macintosh file type code(s): TEXT
Macintosh文件类型代码：文本
Person & email address to contact for further information: Erik
Wilde <dret@berkeley.edu>
Person & email address to contact for further information: Erik
Wilde <dret@berkeley.edu>
Intended usage: COMMON
预期用途：普通
Restrictions on usage: none
使用限制：无
Author: Erik Wilde <dret@berkeley.edu>
Author: Erik Wilde <dret@berkeley.edu>
Change controller: IETF
更改控制器：IETF
The security considerations from RFC 5261 [RFC5261] apply to the application/xml-patch+xml media type.
RFC 5261[RFC5261]中的安全注意事项适用于应用程序/xml修补程序+xml媒体类型。
In addition, parsing XML may entail including information from external sources through XML's mechanism of external entities. Implementations, therefore, should be aware of the fact that standard parsers may resolve external entities and thus include external information as a result of applying patch operations to an XML document.
此外，解析XML可能需要通过XML的外部实体机制包含来自外部源的信息。因此，实现应该意识到这样一个事实，即标准解析器可能解析外部实体，因此将补丁操作应用于XML文档时会包含外部信息。
Thanks for comments and suggestions provided by Bas de Bakker, Tony Hansen, Bjoern Hoehrmann, and Julian Reschke.
感谢Bas de Bakker、Tony Hansen、Bjoern Hoehrmann和Julian Reschke提供的意见和建议。
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC3470]Hollenbeck，S.，Rose，M.，和L.Masinter，“IETF协议中可扩展标记语言（XML）的使用指南”，BCP 70，RFC 3470，2003年1月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", RFC 5261, September 2008.
[RFC5261]Urpalainen，J.，“利用XML路径语言（XPath）选择器的可扩展标记语言（XML）修补程序操作框架”，RFC 52612008年9月。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“媒体类型规范和注册程序”，BCP 13，RFC 6838，2013年1月。
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, July 2014.
[RFC7303]Thompson，H.和C.Lilley，“XML媒体类型”，RFC7303，2014年7月。
[Err3477] RFC Errata, "Errata ID 3477", RFC 5261.
[Err3477]RFC勘误表，“勘误表ID 3477”，RFC 5261。
[Err3478] RFC Errata, "Errata ID 3478", RFC 5261.
[Err3478]RFC勘误表，“勘误表ID 3478”，RFC 5261。
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, March 2010.
[RFC5789]Dusseault，L.和J.Snell，“HTTP的补丁方法”，RFC 5789，2010年3月。
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7231]Fielding，R.和J.Reschke，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 72312014年6月。
[W3C.REC-DOM-Level-3-Core-20040407] Robie, J., Wood, L., Champion, M., Hegaret, P., Nicol, G., Le Hors, A., and S. Byrne, "Document Object Model (DOM) Level 3 Core Specification", World Wide Web Consortium Recommendation REC-DOM-Level-3-Core-20040407, April 2004, <http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407>.
[W3C.REC-DOM-Level-3-Core-20040407]Robie，J.，Wood，L.，Champion，M.，Hegaret，P.，Nicol，G.，Le Hors，A.，和S.Byrne，“文档对象模型（DOM）3级核心规范”，万维网联盟建议REC-DOM-Level-3-Core-20040407，2004年4月<http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407>.
[W3C.REC-xml-20081126] Sperberg-McQueen, C., Yergeau, F., Paoli, J., Maler, E., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-xml-20081126]Sperberg McQueen，C.，Yergeau，F.，Paoli，J.，Maler，E.，和T.Bray，“可扩展标记语言（xml）1.0（第五版）”，万维网联盟建议REC-xml-20081126，2008年11月<http://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-xml-names-20091208] Hollander, D., Layman, A., Bray, T., Tobin, R., and H. Thompson, "Namespaces in XML 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml-names-20091208, December 2009, <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[W3C.REC-xml-names-20091208]Hollander，D.，Layman，A.，Bray，T.，Tobin，R.，和H.Thompson，“xml 1.0中的名称空间（第三版）”，万维网联盟建议REC-xml-names-20091208，2009年12月<http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[W3C.REC-xmlschema-1-20041028] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-1-20041028]Thompson，H.，Beech，D.，Maloney，M.，和N.Mendelsohn，“XML模式第1部分：结构第二版”，万维网联盟建议REC-xmlschema-1-20041028，2004年10月<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xpath-19991116] DeRose, S. and J. Clark, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[W3C.REC-xpath-19991116]DeRose，S.和J.Clark，“XML路径语言（xpath）1.0版”，万维网联盟建议REC-xpath-19991116，1999年11月<http://www.w3.org/TR/1999/REC-xpath-19991116>.
[W3C.REC-xpath20-20101214] Boag, S., Berglund, A., Kay, M., Simeon, J., Robie, J., Chamberlin, D., and M. Fernandez, "XML Path Language (XPath) 2.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xpath20-20101214, December 2010, <http://www.w3.org/TR/2010/REC-xpath20-20101214>.
[W3C.REC-xpath20-20101214]Boag，S.，Berglund，A.，Kay，M.，Simeon，J.，Robie，J.，Chamberlin，D.，和M.Fernandez，“XML路径语言（XPath）2.0（第二版）”，万维网联盟建议REC-xpath20-20101214，2010年12月<http://www.w3.org/TR/2010/REC-xpath20-20101214>.
This section is informative. It describes some issues that might be interesting for implementers, but it might also be interesting for users of XML patch that want to understand some of the differences between standard XPath 1.0 processing and the processing model of selectors in RFC 5261.
本节内容丰富。它描述了实现人员可能感兴趣的一些问题，但XML修补程序的用户也可能感兴趣，他们希望了解标准XPath 1.0处理和RFC 5261中选择器的处理模型之间的一些差异。
Specifically, the issues described in the following two sections have been identified as technical issues with RFC 5261 and have been filed as errata. Implementers interested in using XML patch are encouraged to take those errata into account when implementing XML patch documents. The issue about "Matching Namespaces" described in Appendix A.1 has been filed as RFC Errata ID 3477 [Err3477]. The issue about "Patching Namespaces" described in Appendix A.2 has been filed as RFC Errata ID 3478 [Err3478].
具体而言，以下两节中描述的问题已被确定为RFC 5261的技术问题，并已作为勘误表提交。鼓励对使用XML修补程序感兴趣的实现人员在实现XML修补程序文档时考虑这些勘误表。附录A.1中描述的“匹配名称空间”问题已作为RFC勘误表ID 3477[Err3477]提交。附录A.2中描述的关于“修补名称空间”的问题已作为RFC勘误表ID 3478[Err3478]提交。
RFC 5261 defines standard rules for matching prefixed names in expressions: any prefixes are interpreted according to the namespace bindings of the diff document (the document that the expression is applied against). This means that each prefixed name can be interpreted in the context of the diff document.
RFC 5261定义了匹配表达式中前缀名称的标准规则：根据diff文档（应用表达式的文档）的命名空间绑定解释任何前缀。这意味着每个带前缀的名称都可以在diff文档的上下文中进行解释。
For unprefixed names in expressions, the rules depart from XPath 1.0 [W3C.REC-xpath-19991116]. XPath 1.0 defines that unprefixed names in expressions match namespace-less names (i.e., there is no "default namespace" for names used in XPath 1.0 expressions). RFC 5261 requires, however, that unprefixed names in expressions must use the default namespace of the diff document (if there is one). This means that it is not possible to simply take a selector from a patch document and evaluate it in the context of the diff document according to the rules of XPath 1.0 because this would interpret unprefixed names incorrectly. As a consequence, it is not possible to simply take an XPath 1.0 processor and evaluate XML patch selectors in the context of the diff document.
对于表达式中不固定的名称，规则与XPath1.0不同[W3C.REC-XPath-19991116]。XPath 1.0定义表达式中未固定的名称与无命名空间的名称匹配（即，XPath 1.0表达式中使用的名称没有“默认命名空间”）。但是，RFC 5261要求表达式中的非固定名称必须使用diff文档的默认名称空间（如果有）。这意味着，根据XPath 1.0的规则，不可能简单地从修补程序文档中获取选择器，并在diff文档的上下文中对其进行求值，因为这会错误地解释不固定的名称。因此，不可能简单地使用XPath1.0处理器并在diff文档的上下文中评估XML补丁选择器。
As an extension of XPath 1.0's simple model, XPath 2.0 [W3C.REC-xpath20-20101214] specifies different processing rules for unprefixed names: they are matched against the URI of the "default element/type namespace", which is defined as part of an expression's static context. In some XPath 2.0 applications, this can be set; XSL Transformations (XSLT) 2.0, for example, has the ability to define an "xpath-default-namespace", which then will be used to match unprefixed names in expressions. Thus, by using an XPath 2.0 implementation that allows one to set this URI, and setting it to the default namespace of the diff document (or leaving it undefined if
作为XPath 1.0简单模型的扩展，XPath 2.0[W3C.REC-xpath20-20101214]为非固定名称指定了不同的处理规则：它们与“默认元素/类型名称空间”的URI匹配，该名称空间定义为表达式静态上下文的一部分。在一些XPath 2.0应用程序中，可以设置此选项；例如，XSLTransformations（XSLT）2.0能够定义“xpath默认名称空间”，然后将使用该名称空间来匹配表达式中不固定的名称。因此，通过使用允许设置此URI的XPath 2.0实现，并将其设置为diff文档的默认名称空间（如果需要，则保留未定义的名称空间）
there is no such default namespace), it is possible to use an out-of-the-box XPath 2.0 implementation for evaluating XML patch selectors.
没有这样的默认名称空间），可以使用现成的XPath2.0实现来评估XML修补程序选择器。
Please keep in mind, however, that evaluating selectors is only one part of applying patches. When it comes to applying the actual patch operation, neither XPath 1.0 nor XPath 2.0 are sufficient because they do not preserve some of the information from the XML syntax (specifically namespace declarations) that is required to correctly apply patch operations. The following section describes this issue in more detail.
但是，请记住，评估选择器只是应用补丁的一部分。在应用实际的补丁操作时，XPath 1.0和XPath 2.0都不够，因为它们没有保留正确应用补丁操作所需的XML语法（特别是命名空间声明）中的一些信息。下一节将更详细地描述此问题。
Please note that [RFC5261], Section 4.2.2 on namespace matching explains XPath 2.0's rules incorrectly. For this reason, RFC Errata ID 3477 is available for Section 4.2.2 of RFC 5261.
请注意[RFC5261]，关于命名空间匹配的第4.2.2节错误地解释了XPath 2.0的规则。因此，RFC 5261第4.2.2节提供了RFC勘误表ID 3477。
One of the issues when patching namespaces based on XPath is that XPath exposes namespaces differently than the XML 1.0 [W3C.REC-xml-20081126] syntax for XML namespaces [W3C.REC-xml-names-20091208]. In the XML syntax, a namespace is declared with an attribute using the reserved name or prefix "xmlns", and this results in this namespace being available recursively through the document tree. In XPath, the namespace declaration is not exposed as an attribute (i.e., the attribute, although syntactically an XML attribute, is not accessible in XPath), but the resulting namespace nodes are exposed recursively through the tree.
基于XPath修补名称空间时的一个问题是XPath公开的名称空间与XML名称空间的XML 1.0[W3C.REC-XML-20081126]语法[W3C.REC-XML-names-20091208]不同。在XML语法中，使用保留名称或前缀“xmlns”用属性声明名称空间，这将导致通过文档树递归使用该名称空间。在XPath中，名称空间声明不作为属性公开（即，该属性虽然在语法上是XML属性，但在XPath中不可访问），但通过树递归地公开生成的名称空间节点。
RFC 5261 uses the terms "namespace declaration" and "namespace" almost interchangeably, but it is important to keep in mind that the namespace declaration is an XML syntax construct that is unavailable in XPath, while the namespace itself is a logical construct that is not visible in the XML syntax, but a result of a namespace declaration. The intent of RFC 5261 is to patch namespaces as if namespace declarations were patched; thus, it only allows patching namespace nodes on the element nodes where the namespace has been declared.
RFC 5261几乎可以互换地使用术语“名称空间声明”和“名称空间”，但必须记住，名称空间声明是XPath中不可用的XML语法构造，而名称空间本身是XML语法中不可见的逻辑构造，而是名称空间声明的结果。RFC 5261的目的是修补名称空间，就像修补名称空间声明一样；因此，它只允许在已声明名称空间的元素节点上修补名称空间节点。
Patching namespaces in XML patch is supposed to "emulate" the effect of actually changing the namespace declaration (which is why a namespace can only be patched at the element where it has been declared). Therefore, when patching a namespace, even though XPath's "namespace" axis is used, implementations have to make sure that not only the single selected namespace node is being patched but that all namespaces nodes resulting from the namespace declaration of this namespace are also patched accordingly.
在XML补丁中修补名称空间应该“模拟”实际更改名称空间声明的效果（这就是为什么只能在声明名称空间的元素处修补名称空间）。因此，在修补名称空间时，即使使用了XPath的“名称空间”轴，实现也必须确保不仅修补单个选定的名称空间节点，而且修补由此名称空间的名称空间声明生成的所有名称空间节点。
This means that an implementation might have to descend into the tree, matching all namespace nodes with the selected prefix/URI pair recursively, until it encounters leaf elements or namespace declarations with the same prefix it is patching. Determining this requires access to the diff document beyond XPath, because, in XPath itself, namespace declarations are not represented; thus, such a recursive algorithm wouldn't know when to stop. Consider the following document:
这意味着一个实现可能必须下降到树中，递归地将所有名称空间节点与所选前缀/URI对匹配，直到它遇到与它正在修补的前缀相同的叶元素或名称空间声明。确定这一点需要在XPath之外访问diff文档，因为在XPath本身中，名称空间声明不被表示；因此，这种递归算法不知道何时停止。考虑以下文件：
<x xmlns:a="tag:42">
<y xmlns:a="tag:42"/>
</x>
<x xmlns:a="tag:42">
<y xmlns:a="tag:42"/>
</x>
If this document is patched with a selector of /x/namespace::a, then only the namespace node on element x should be patched, even though the namespace node on element y has the same prefix/URI combination as the one on element x. However, determining that the repeated namespace declaration was present at all on element y is impossible when using XPath alone, which means that implementations must have an alternative way to determine the difference between the document above, and this one:
如果使用/x/namespace:：a选择器修补此文档，则只应修补元素x上的名称空间节点，即使元素y上的名称空间节点与元素x上的名称空间节点具有相同的前缀/URI组合。但是，当单独使用XPath时，不可能确定元素y上是否存在重复的名称空间声明，这意味着实现必须有另一种方法来确定上述文档与此文档之间的差异：
<x xmlns:a="tag:42">
<y/>
</x>
<x xmlns:a="tag:42">
<y/>
</x>
In this second example, patching with a selector of /x/namespace::a should indeed change the namespace nodes on elements x and y, because they both have been derived from the same namespace declaration.
在第二个示例中，使用/x/namespace:：a选择器进行修补确实应该更改元素x和y上的名称空间节点，因为它们都是从相同的名称空间声明派生的。
The conclusion of these considerations is that for implementing XML patch, access closer to the XML syntax (specifically access to namespace declarations) is necessary. As a result, implementations attempting to exclusively use the XPath model for implementing XML patch will fail to correctly address certain edge cases (such as the one shown above).
这些考虑的结论是，为了实现XML修补程序，需要更接近XML语法的访问（特别是访问命名空间声明）。因此，试图专门使用XPath模型实现XML修补程序的实现将无法正确处理某些边缘情况（如上图所示）。
Note that XPath's specific limitations do not mean that it is impossible to use XML technologies other than XPath. The Document Object Model (DOM) [W3C.REC-DOM-Level-3-Core-20040407], for example, does expose namespace declaration attributes as regular attributes in the document tree; thus, they could be used to differentiate between the two variants shown above.
请注意，XPath的特定限制并不意味着不可能使用XPath以外的XML技术。例如，文档对象模型（DOM）[W3C.REC-DOM-Level-3-Core-20040407]确实将名称空间声明属性公开为文档树中的常规属性；因此，它们可用于区分上述两种变体。
Please note that RFC 5261, Section 4.4.3 (on replacing namespaces) mixes the terms "namespace declaration" and "namespace". For this reason, RFC Errata ID 3478 is available for Section 4.4.3 of RFC 5261.
请注意，RFC 5261第4.4.3节（关于替换名称空间）混合了术语“名称空间声明”和“名称空间”。因此，RFC 5261第4.4.3节提供了RFC勘误表ID 3478。
RFC 5261 [RFC5261] does not contain an ABNF grammar for the allowed subset of XPath expressions but includes an XSD-based grammar in its type definition for operation types. In order to make implementation easier, this appendix contains an ABNF grammar that has been derived from the XSD expressions in RFC 5261. In the following grammar, "xpath" is the definition for the allowed XPath expressions for remove and replace operations, and "xpath-add" is the definition for the allowed XPath expressions for add operations. The names of all grammar productions are the ones used in the XSD-based grammar of RFC 5261.
RFC 5261[RFC5261]不包含允许的XPath表达式子集的ABNF语法，但在其操作类型的类型定义中包含基于XSD的语法。为了简化实现，本附录包含一个ABNF语法，该语法是从RFC5261中的XSD表达式派生而来的。在以下语法中，“xpath”是删除和替换操作所允许的xpath表达式的定义，“xpath add”是添加操作所允许的xpath表达式的定义。所有语法产品的名称都是RFC5261基于XSD的语法中使用的名称。
anychar = %x00-ffffffff
ncname = 1*%x00-ffffffff
qname = [ ncname ":" ] ncname
aname = "@" qname
pos = "[" 1*DIGIT "]"
attr = ( "[" aname "='" 0*anychar "']" ) /
( "[" aname "=" DQUOTE 0*anychar DQUOTE "]" )
valueq = "[" ( qname / "." ) "=" DQUOTE 0*anychar DQUOTE "]"
value = ( "[" ( qname / "." ) "='" 0*anychar "']" ) / valueq
cond = attr / value / pos
step = ( qname / "*" ) 0*cond
piq = %x70.72.6f.63.65.73.73.69.6e.67.2d
%x69.6e.73.74.72.75.63.74.69.6f.6e
; "processing-instruction", case-sensitive
"(" [ DQUOTE ncname DQUOTE ] ")"
pi = ( %x70.72.6f.63.65.73.73.69.6e.67.2d
%x69.6e.73.74.72.75.63.74.69.6f.6e
; "processing-instruction", case-sensitive
"(" [ "'" ncname "'" ] ")" ) / piq
id = ( %x69.64 ; "id", case-sensitive
"(" [ "'" ncname "'" ] ")" ) /
( %x69.64 ; "id", case-sensitive
"(" [ DQUOTE ncname DQUOTE ] ")" )
com = %x63.6f.6d.6d.65.6e.74 ; "comment", case-sensitive
"()"
text = %x74.65.78.74 ; "text", case-sensitive
"()"
nspa = %x6e.61.6d.65.73.70.61.63.65 ; "namespace", case-sensitive
"::" ncname
cnodes = ( text / com / pi ) [ pos ]
child = cnodes / step
last = child / aname / nspa
xpath = [ "/" ] ( ( id [ 0*( "/" step ) "/" last ] ) /
( 0*( step "/" ) last ) )
xpath-add = [ "/" ] ( ( id [ 0*( "/" step ) "/" child ] ) /
( 0*( step "/" ) child ) )
anychar = %x00-ffffffff
ncname = 1*%x00-ffffffff
qname = [ ncname ":" ] ncname
aname = "@" qname
pos = "[" 1*DIGIT "]"
attr = ( "[" aname "='" 0*anychar "']" ) /
( "[" aname "=" DQUOTE 0*anychar DQUOTE "]" )
valueq = "[" ( qname / "." ) "=" DQUOTE 0*anychar DQUOTE "]"
value = ( "[" ( qname / "." ) "='" 0*anychar "']" ) / valueq
cond = attr / value / pos
step = ( qname / "*" ) 0*cond
piq = %x70.72.6f.63.65.73.73.69.6e.67.2d
%x69.6e.73.74.72.75.63.74.69.6f.6e
; "processing-instruction", case-sensitive
"(" [ DQUOTE ncname DQUOTE ] ")"
pi = ( %x70.72.6f.63.65.73.73.69.6e.67.2d
%x69.6e.73.74.72.75.63.74.69.6f.6e
; "processing-instruction", case-sensitive
"(" [ "'" ncname "'" ] ")" ) / piq
id = ( %x69.64 ; "id", case-sensitive
"(" [ "'" ncname "'" ] ")" ) /
( %x69.64 ; "id", case-sensitive
"(" [ DQUOTE ncname DQUOTE ] ")" )
com = %x63.6f.6d.6d.65.6e.74 ; "comment", case-sensitive
"()"
text = %x74.65.78.74 ; "text", case-sensitive
"()"
nspa = %x6e.61.6d.65.73.70.61.63.65 ; "namespace", case-sensitive
"::" ncname
cnodes = ( text / com / pi ) [ pos ]
child = cnodes / step
last = child / aname / nspa
xpath = [ "/" ] ( ( id [ 0*( "/" step ) "/" last ] ) /
( 0*( step "/" ) last ) )
xpath-add = [ "/" ] ( ( id [ 0*( "/" step ) "/" child ] ) /
( 0*( step "/" ) child ) )
Please note that the "ncname" production listed above does not fully capture the constraints of the original XSD-based definition, where it is defined as "\i\c*". DIGIT and DQUOTE are defined by the ABNF specification [RFC5234].
请注意，上面列出的“ncname”产品没有完全捕获原始基于XSD的定义的约束，其中定义为“\i\c*”。数字和DQUOTE由ABNF规范[RFC5234]定义。
Author's Address
作者地址
Erik Wilde UC Berkeley
埃里克·王尔德加州大学伯克利分校
EMail: dret@berkeley.edu
URI: http://dret.net/netdret/
EMail: dret@berkeley.edu
URI: http://dret.net/netdret/