[要約] RFC 7351は、XMLパッチ操作のためのメディアタイプを定義しています。目的は、XML文書の変更を表現し、効率的なデータ交換を可能にすることです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
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.
Extensible Markup Language（XML）[RFC7303]は、構造化データの交換と保存のための一般的な形式です。 HTTP PATCH [RFC5789]は、HTTP [RFC7231]を拡張して、リソースに対して部分的な変更を行うメソッドを備えています。 HTTP PATCHでは、要求とともにパッチドキュメントを送信する必要があるため、一般的なメディアタイプ用に標準化されたパッチドキュメントフォーマット（メディアタイプによって識別される）があると便利です。
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 PATCHメソッドでの使用に適しています。サーバーは受け入れたいパッチ形式を自由に選択できます。「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 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.
この仕様はRFC 5261に依存していますが、これまでに報告されたエラッタも考慮する必要があります。エラッタの主な理由は、RFC 5261がパッチの場所を選択するための式言語としてXMLパス言語（XPath）に依存する問題のある方法であると同時に、XPathのデータモデルには、このようなセレクターは実際にパッチ操作に使用できますが、エラーが発生するはずです。具体的には、問題はネームスペースで発生し、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パッチドキュメント形式は、「パッチ」要素をドキュメント要素として使用し、「追加」、「削除」、および「置換」要素の任意のシーケンスをドキュメント要素の子として許可する単純なスキーマに基づいています。これらの子は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.
次の簡単なパッチドキュメントの例には、単一のパッチ操作が含まれています。この操作により、「new-attribute」と呼ばれる新しい属性がターゲットXMLドキュメントのドキュメント要素に追加されます。 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>
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に変更しています）。より単純な例に示すように、同じ「patch」要素と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>
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.
この例が示すように、ドキュメント要素「patch」とパッチ操作要素の両方が同じ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>
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のすべての例は、2つの小さな変更を考慮して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".
2つの違いは、XMLパッチドキュメントは常に「patch」要素をドキュメント要素として使用することと、「patch」要素とXMLパッチドキュメントの個々の操作要素の両方が、URIが「urn：ietf」のXML名前空間にある必要があることです。 ：rfc：7351 "。
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>
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>
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>
The Internet media type [RFC6838] for an XML patch document is application/xml-patch+xml.
XMLパッチドキュメントのインターネットメディアタイプ[RFC6838]は、application / xml-patch + xmlです。
Type name: application
タイプ名：アプリケーション
Subtype name: xml-patch+xml
サブタイプ名：xml-patch + xml
Required parameters: none Optional parameters:
必須パラメーター：なしオプションパラメーター：
charset: Same as charset parameter for the media type "application/xml" as specified in RFC 7303 [RFC7303].
charset：RFC 7303 [RFC7303]で指定されているメディアタイプ「application / xml」のcharsetパラメータと同じです。
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
相互運用性に関する考慮事項：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
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ファイルタイプコード：TEXT
Person & email address to contact for further information: Erik
Wilde <dret@berkeley.edu>
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: none
使用上の制限：なし
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]のセキュリティに関する考慮事項は、application / xml-patch + 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プロトコル内でのExtensible Markup Language（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 5261、2008年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 Media Types」、RFC 7303、2014年7月。
[Err3477] RFC Errata, "Errata ID 3477", RFC 5261.
[Err3477] RFC Errata、「Errata ID 3477」、RFC 5261。
[Err3478] RFC Errata, "Errata ID 3478", RFC 5261.
[Err3478] RFC Errata、「Errata ID 3478」、RFC 5261。
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, March 2010.
[RFC5789] Dusseault、L.およびJ. Snell、「PATCH Method for 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、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、2014年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.、and S. Byrne 、「Document Object Model（DOM）Level 3 Core Specification」、World Wide Web Consortium Recommendation 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、「Extensible Markup Language（XML）1.0（Fifth Edition）」、 World Wide Web Consortium Recommendation 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.、and H. Thompson、 "Namespaces in XML 1.0（Third Edition）"、World Wide Webコンソーシアム勧告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 Schema Part 1：Structures Second Edition」、World Wide Web Consortium Recommendation 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 Path Language（XPath）Version 1.0」、World Wide Web Consortium Recommendation 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.、and M. Fernandez、 "XML Path Language（XPath ）2.0（Second Edition）」、World Wide Web Consortium Recommendation 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.
このセクションは参考情報です。実装者にとって興味深いかもしれないいくつかの問題について説明しますが、標準のXPath 1.0処理とRFC 5261のセレクターの処理モデルの違いのいくつかを理解したいXMLパッチのユーザーにとっても興味深いかもしれません。
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].
具体的には、次の2つのセクションで説明する問題は、RFC 5261の技術的な問題として識別されており、エラッタとして提出されています。 XMLパッチドキュメントを実装する場合は、XMLパッチの使用に関心のある実装者がそれらのエラッタを考慮することをお勧めします。付録A.1で説明されている「名前空間の一致」に関する問題は、RFC Errata ID 3477 [Err3477]として提出されています。付録A.2で説明されている「パッチング名前空間」に関する問題は、RFC Errata 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.
式の接頭辞のない名前の場合、ルールはXPath 1.0 [W3C.REC-xpath-19991116]から逸脱しています。 XPath 1.0は、式の接頭辞なしの名前が名前空間のない名前に一致することを定義しています（つまり、XPath 1.0式で使用される名前には「デフォルトの名前空間」はありません）。ただし、RFC 5261では、式の接頭辞のない名前には、diffドキュメントのデフォルトのネームスペース（存在する場合）を使用する必要があります。つまり、接頭辞のない名前が誤って解釈されるため、パッチドキュメントからセレクタを取得して、XPath 1.0のルールに従ってdiffドキュメントのコンテキストでそれを評価することは不可能です。その結果、XPath 1.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 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.
XPath 1.0の単純なモデルの拡張として、XPath 2.0 [W3C.REC-xpath20-20101214]は、接頭辞なしの名前に対してさまざまな処理規則を指定します。これらは、次のように定義される「デフォルトの要素/タイプの名前空間」のURIと照合されます。式の静的コンテキストの一部。一部のXPath 2.0アプリケーションでは、これを設定できます。たとえば、XSL Transformations（XSLT）2.0には「xpath-default-namespace」を定義する機能があり、これを使用して式の接頭辞のない名前を照合します。したがって、このURIを設定できるXPath 2.0実装を使用し、それをdiffドキュメントのデフォルトの名前空間に設定する（または、そのようなデフォルトの名前空間がない場合は未定義のままにする）ことで、out-of -XMLパッチセレクターを評価するためのボックスXPath 2.0実装。
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 Errata ID 3477はRFC 5261のセクション4.2.2で利用できます。
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に基づいて名前空間にパッチを適用するときの問題の1つは、XPathがXML 1.0 [W3C.REC-xml-20081126] XML名前空間[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自体では名前空間宣言が表されないため、これを決定するには、XPathを超えてdiffドキュメントにアクセスする必要があります。したがって、そのような再帰的アルゴリズムでは、いつ停止するかがわかりません。次のドキュメントを検討してください。
<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のセレクターでパッチされている場合、要素yの名前空間ノードに要素xのプレフィックスとURIの組み合わせと同じであっても、要素xの名前空間ノードのみにパッチを適用する必要があります。 。ただし、XPathだけを使用する場合、繰り返し名前空間宣言が要素yに存在することを確認することは不可能です。つまり、実装には、上記のドキュメントとこのドキュメントの違いを判断する別の方法が必要です。
<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.
この2番目の例では、/ 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構文により近いアクセス（特に名前空間宣言へのアクセス）が必要であるということです。その結果、XMLパッチを実装するためにXPathモデルのみを使用しようとする実装は、特定のエッジケース（上記の例など）に正しく対処できません。
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]は、名前空間宣言属性をドキュメントツリーの通常の属性として公開します。したがって、上記の2つのバリアントを区別するために使用できます。
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 Errata ID 3478はRFC 5261のセクション4.4.3で利用できます。
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ベースの文法が含まれています。実装を容易にするために、この付録には、RFC 5261のXSD式から派生したABNF文法が含まれています。次の文法では、「xpath」は、削除および置換操作で許可されるXPath式の定義であり、「xpath -add "は、追加操作で許可されるXPath式の定義です。すべての文法プロダクションの名前は、RFC 5261の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 ) )
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」プロダクションは、「\ i \ c *」として定義されている元のXSDベースの定義の制約を完全にはキャプチャしていません。 DIGITとDQUOTEは、ABNF仕様[RFC5234]で定義されています。
Author's Address
著者のアドレス
Erik Wilde UC Berkeley
エリックワイルドUCバークレー
EMail: dret@berkeley.edu
URI: http://dret.net/netdret/