[要約] RFC 5261は、XMLパッチ操作フレームワークを提供するための仕様であり、XML Path Language（XPath）セレクタを使用して操作を行うことができます。このRFCの目的は、XML文書の特定の部分を効率的に変更するための標準化された手法を提供することです。
Network Working Group J. Urpalainen
Request for Comments: 5261 Nokia
Category: Standards Track September 2008
An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors
XML PATH言語（XPATH）セレクターを使用した拡張可能なマークアップ言語（XML）パッチ操作フレームワーク
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic <add>, <replace>, and <remove> directives a set of patches can then be applied to update an existing XML document.
拡張可能なマークアップ言語（XML）ドキュメントは、今日のシステムにおける任意のデータの交換と保存のためのコンテナとして広く使用されています。変更をXMLドキュメントに送信するには、変更された部分のみを示す手段がない限り、新しいバージョンのコピー全体を送信する必要があります。このドキュメントでは、XMLパス言語（XPath）セレクターを使用したXMLパッチフレームワークについて説明します。これらのセレクター値と更新された新しいデータコンテンツは、このドキュメントで説明されているパッチ操作の基礎を構成します。それらに加えて、Basic <add>、<plateg>、および<remove>ディレクティブを使用して、既存のXMLドキュメントを更新するために一連のパッチを適用できます。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions .....................................................3
3. Basic Features and Requirements .................................4
4. Patch Operations ................................................5
4.1. Locating the Target of a Patch .............................6
4.2. Namespace Mangling .........................................6
4.2.1. Namespaces Used in Selectors ........................7
4.2.2. Departures from XPath Requirements ..................7
4.2.3. Namespaces and Added/Changed Content ................8
4.3. <add> Element .............................................10
4.3.1. Adding an Element ..................................11
4.3.2. Adding an Attribute ................................11
4.3.3. Adding a Prefixed Namespace Declaration ............12
4.3.4. Adding Node(s) with the 'pos' Attribute ............12
4.3.5. Adding Multiple Nodes ..............................12
4.4. <replace> Element .........................................13
4.4.1. Replacing an Element ...............................14
4.4.2. Replacing an Attribute Value .......................14
4.4.3. Replacing a Namespace Declaration URI ..............14
4.4.4. Replacing a Comment Node ...........................14
4.4.5. Replacing a Processing Instruction Node ............15
4.4.6. Replacing a Text Node ..............................15
4.5. <remove> Element ..........................................15
4.5.1. Removing an Element ................................15
4.5.2. Removing an Attribute ..............................16
4.5.3. Removing a Prefixed Namespace Declaration ..........16
4.5.4. Removing a Comment Node ............................16
4.5.5. Removing a Processing Instruction Node .............16
4.5.6. Removing a Text Node ...............................16
5. Error Handling .................................................17
5.1. Error Elements ............................................17
6. Usage of Patch Operations ......................................19
7. Usage of Selector Values .......................................19
8. XML Schema Types of Patch Operation Elements ...................19
9. XML Schema of Patch Operation Errors ...........................21
10. IANA Considerations ...........................................23
10.1. URN Sub-Namespace Registration ...........................23
10.2. application/patch-ops-error+xml MIME Type ................24
10.3. Patch-Ops-Types XML Schema Registration ..................25
10.4. Patch-Ops-Error XML Schema Registration ..................25
11. Security Considerations .......................................26
12. Acknowledgments ...............................................26
13. References ....................................................26
13.1. Normative References .....................................26
13.2. Informative References ...................................28
Appendix A. Informative Examples .................................29
A.1. Adding an Element .........................................29
A.2. Adding an Attribute .......................................29
A.3. Adding a Prefixed Namespace Declaration ...................30
A.4. Adding a Comment Node with the 'pos' Attribute ............30
A.5. Adding Multiple Nodes .....................................31
A.6. Replacing an Element ......................................31
A.7. Replacing an Attribute Value ..............................32
A.8. Replacing a Namespace Declaration URI .....................32
A.9. Replacing a Comment Node ..................................33
A.10. Replacing a Processing Instruction Node ...................33
A.11. Replacing a Text Node .....................................34
A.12. Removing an Element .......................................34
A.13. Removing an Attribute .....................................35
A.14. Removing a Prefixed Namespace Declaration .................35
A.15. Removing a Comment Node ...................................36
A.16. Removing a Processing Instruction Node ....................36
A.17. Removing a Text Node ......................................37
A.18. Several Patches With Namespace Mangling ...................38
Extensible Markup Language (XML) [W3C.REC-xml-20060816] documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed (patches).
拡張可能なマークアップ言語（XML）[W3C.REC-XML-20060816]ドキュメントは、今日のシステムで任意のデータの交換と保存のためのコンテナとして広く使用されています。変更をXMLドキュメントに送信するには、変更された部分（パッチ）のみを示す手段がない限り、新しいバージョンのコピー全体を送信する必要があります。
This document describes an XML patch framework that utilizes XML Path language (XPath) [W3C.REC-xpath-19991116] selectors. An XPath selector is used to pinpoint the specific portion of the XML that is the target for the change. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic <add>, <replace>, and <remove> directives a set of patches can be applied to update an existing target XML document. With these patch operations, a simple semantics for data oriented XML documents [W3C.REC-xmlschema-2-20041028] is achieved, that is, modifications like additions, removals, or substitutions of elements and attributes can easily be performed. This document does not describe a full XML diff format, only basic patch operation elements that can be embedded within a full format that typically has additional semantics.
このドキュメントでは、XMLパス言語（XPATH）[W3C.REC-XPATH-19991116]セレクターを使用するXMLパッチフレームワークについて説明します。XPathセレクターを使用して、変化のターゲットであるXMLの特定の部分を特定します。これらのセレクター値と更新された新しいデータコンテンツは、このドキュメントで説明されているパッチ操作の基礎を構成します。それらに加えて、Basic <add>、<plateg>、および<remove>ディレクティブを使用して、既存のターゲットXMLドキュメントを更新するために一連のパッチを適用できます。これらのパッチ操作により、データ指向のXMLドキュメント[W3C.REC-XMLSCHEMA-20041028]の簡単なセマンティクスが達成されます。つまり、要素や属性の追加、除去、または代替品などの変更を簡単に実行できます。このドキュメントでは、完全なXML DIFF形式は説明されておらず、通常は追加のセマンティクスを持つ完全な形式に埋め込むことができる基本的なパッチ操作要素のみです。
As one concrete example, in the Session Initiation Protocol (SIP) [RFC3903] based presence system a partial PIDF XML document format [RFC5262] consists of the existing Presence Information Data Format (PIDF) document format combined with the patch operations elements described in this document. In general, patch operations can be used in any application that exchanges XML documents, for example, within the SIP Events framework [RFC3265]. Yet another example is XCAP-diff [SIMPLE-XCAP], which uses this framework for sending partial updates of changes to XCAP [RFC4825] resources.
1つの具体的な例として、セッション開始プロトコル（SIP）[RFC3903]ベースの存在システムでは、部分的なPIDF XMLドキュメント形式[RFC5262]は、これに記載されているパッチ操作要素と組み合わせた既存の存在情報データ形式（PIDF）ドキュメント形式で構成されています。書類。一般に、パッチ操作は、たとえばSIPイベントフレームワーク[RFC3265]内で、XMLドキュメントを交換するアプリケーションで使用できます。さらに別の例は、XCAP-Diff [Simple-XCAP]です。これは、このフレームワークを使用して、XCAP [RFC4825]リソースに変更の部分的な更新を送信します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, BCP 14 [RFC2119] and indicate requirement levels for compliant implementations.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119、BCP 14 [RFC2119]で説明されているように解釈され、準拠の実装の要件レベルを示します。
The following terms are used in this document:
このドキュメントでは、次の用語が使用されています。
Target XML document: A target XML document that is going to be updated with a set of patches.
ターゲットXMLドキュメント：パッチのセットで更新されるターゲットXMLドキュメント。
XML diff document: An XML document that contains patch operation elements, namespace declarations, and all the document content changes that are needed in order to transform a target XML document into a new patched XML document.
XML DIFFドキュメント：ターゲットXMLドキュメントを新しいパッチ付きXMLドキュメントに変換するために必要なすべてのドキュメントコンテンツの変更を含むXMLドキュメント。
Patched XML document: An XML document that results after applying one or more patch operations defined in the XML diff document to the target XML document.
パッチ付きXMLドキュメント：XML DIFFドキュメントでターゲットXMLドキュメントに定義された1つ以上のパッチ操作を適用した後に生じるXMLドキュメント。
Patch operation: A single change, i.e., a patch that is being applied to update a target XML document.
パッチ操作：単一の変更、つまりターゲットXMLドキュメントの更新に適用されているパッチ。
Patch operation element: An XML element that represents a single patch operation.
パッチ操作要素：単一のパッチ操作を表すXML要素。
Type definition for an element: A World Wide Web Consortium (W3C) Schema type definition for an element that describes a patch operation content.
要素のタイプ定義：パッチ操作コンテンツを記述する要素のWorld Wide Webコンソーシアム（W3C）スキーマタイプ定義。
In-scope namespace declaration: A list of all in-scope namespace declarations within a context node. The QName (qualified name) expansion of a context node is based on mapping a prefix with one of these declarations. For an element, one namespace binding may have an empty prefix.
スコープ内の名前空間宣言：コンテキストノード内のすべてのスコープ内の名前空間宣言のリスト。コンテキストノードのQNAME（適格名）拡張は、これらの宣言のいずれかでプレフィックスをマッピングすることに基づいています。要素の場合、1つの名前空間バインディングには空のプレフィックスがある場合があります。
Positional constraint: A number enclosed with square brackets. It can be used as a location step predicate.
位置の制約：正方形の括弧で囲まれた数。ロケーションステップの述語として使用できます。
Located target node: A node that was found from the target XML document with the aid of an XPath selector value.
ターゲットノードの位置：XPathセレクター値を使用してターゲットXMLドキュメントから見つかったノード。
White space text node: A text node that contains only white space.
ホワイトスペーステキストノード：ホワイトスペースのみを含むテキストノード。
In this framework, XPath selector values and new data content are embedded within XML elements, the names of which specify the modification to be performed: <add>, <replace>, or <remove>. These elements (patch operations) are defined by schema types with the W3C Schema language [W3C.REC-xmlschema-1-20041028]. XPath selectors pinpoint the target for a change and they are expressed as attributes of these elements. The child node(s) of patch operation elements contain the new data content. In general when applicable, the new content SHOULD be moved unaltered to the patched XML document.
このフレームワークでは、XPathセレクターの値と新しいデータコンテンツはXML要素に組み込まれており、その名前は実行する変更を指定します：<add>、<plateg>、または<remove>。これらの要素（パッチ操作）は、W3Cスキーマ言語[W3C.REC-XMLSCHEMA-20041028]のスキーマタイプによって定義されます。Xpathセレクターは、変更のターゲットを特定し、これらの要素の属性として表現されます。パッチ操作要素の子ノードには、新しいデータコンテンツが含まれています。一般に、該当する場合は、新しいコンテンツをパッチ付きXMLドキュメントに変更せずに移動する必要があります。
XML documents that are equivalent for the purposes of many applications MAY differ in their physical representation. The aim of this document is to describe a deterministic framework where the canonical form with comments [W3C.REC-xml-c14n-20010315] of an XML document determines logical equivalence. For example, white space text nodes MUST be processed properly in order to fulfill this requirement as white space is by default significant [W3C.REC-xml-c14n-20010315].
多くのアプリケーションの目的で同等のXMLドキュメントは、物理的な表現が異なる場合があります。このドキュメントの目的は、XMLドキュメントのコメント[W3C.REC-XML-C1N-20010315]を備えた標準形式が論理的等価性を決定する決定論的フレームワークを記述することです。たとえば、空白が重要であるため、この要件を満たすためには、空白のテキストノードを適切に処理する必要があります[W3C.REC-XML-C14N-20010315]。
The specifications referencing these element schema types MUST define the full XML diff format with an appropriate MIME type [RFC3023] and a character set, e.g., UTF-8 [RFC3629]. For example, the partial PIDF format [RFC5262] includes this schema and describes additional definitions to produce a complete XML diff format for partial presence information updates.
これらの要素スキーマタイプを参照する仕様は、適切なMIMEタイプ[RFC3023]とUTF-8 [RFC3629]などのキャラクターセットを使用して、完全なXML DIFF形式を定義する必要があります。たとえば、部分的なPIDF形式[RFC5262]にはこのスキーマが含まれており、部分的な存在情報更新用の完全なXML DIFF形式を作成するための追加の定義を説明します。
As the schema defined in this document does not declare any target namespace, the type definitions inherit the target namespace of the including schema. Therefore, additional namespace declarations within the XML diff documents can be avoided.
このドキュメントで定義されているスキーマは、ターゲットネームスペースを宣言していないため、タイプ定義は象徴スキーマのターゲットネームスペースを継承します。したがって、XML DIFFドキュメント内の追加の名前空間宣言は回避できます。
It is anticipated that applications using these types will define <add>, <replace>, and <remove> elements based on the corresponding type definitions in this schema. In addition, an application may reference only a subset of these type definitions. A future extension can introduce other operations, e.g., with document-oriented models [W3C.REC-xmlschema-2-20041028], a <move> operation and a text node patching algorithm combined with <move> would undoubtedly produce smaller XML diff documents.
これらのタイプを使用するアプリケーションは、このスキーマの対応するタイプ定義に基づいて<add>、<placter>、および<remove>要素を定義すると予想されます。さらに、アプリケーションは、これらのタイプ定義のサブセットのみを参照する場合があります。将来の拡張機能は、たとえば、ドキュメント指向モデル[W3C.REC-XMLSCHEMA-20041028]、<move>操作、および<move>を組み合わせたテキストノードパッチを組み合わせた他の操作を導入できます。。
The instance document elements based on these schema type definitions MUST be well formed and SHOULD be valid.
これらのスキーマタイプ定義に基づくインスタンスドキュメント要素は、適切に形成されている必要があり、有効である必要があります。
The following XPath 1.0 data model node types can be added, replaced, or removed with this framework: elements, attributes, namespaces, comments, texts, and processing instructions. The full XML prolog, including for example XML entities [W3C.REC-xml-20060816] and the root node of an XML document, cannot be patched according to this framework. However, patching of comments and processing instructions of the root node is allowed. Naturally, the removal or addition of a document root element is not allowed as any valid XML document MUST always contain a single root element. Also, note that support for external entities is beyond the scope of this framework.
次のXPath 1.0データモデルノードのタイプを追加、交換、またはこのフレームワークで削除できます：要素、属性、名前空間、コメント、テキスト、および処理手順。たとえば、XMLエンティティ[W3C.REC-XML-20060816]およびXMLドキュメントのルートノードを含む完全なXMLプロログは、このフレームワークに従ってパッチを適用することはできません。ただし、コメントのパッチとルートノードの処理手順は許可されています。当然のことながら、有効なXMLドキュメントには常に単一のルート要素が含まれている必要があるため、ドキュメントルート要素の削除または追加は許可されていません。また、外部エンティティのサポートはこのフレームワークの範囲を超えていることに注意してください。
An XML diff document contains a collection of patch operation elements, including one or more <add>, <replace>, and <remove> elements. These patch operations will be applied sequentially in the document order. After the first patch has been applied to update a target XML document, the patched XML document becomes a new independent XML document against which the next patch will be applied. This procedure repeats until all patches have successfully been processed.
XML DIFFドキュメントには、1つ以上の<add>、<plateg>、<remove>要素を含むパッチ操作要素のコレクションが含まれています。これらのパッチ操作は、ドキュメントの順序で順番に適用されます。ターゲットXMLドキュメントを更新するために最初のパッチが適用された後、パッチされたXMLドキュメントは、次のパッチが適用される新しい独立したXMLドキュメントになります。この手順は、すべてのパッチが正常に処理されるまで繰り返されます。
Each patch operation element contains a 'sel' attribute. The value of this attribute is an XPath selector with a restricted subset of the full XPath 1.0 recommendation. The 'sel' value is used to locate a single unique target node from the target XML document. This located node pinpoints the target for a change and usually it is an element, which is for example either updated itself or some child node(s) are added into it. It MAY also be, for instance, a comment node, after which some other sibling node(s) are inserted. In any case, it is an error condition if multiple nodes are found during the evaluation of this selector value.
各パッチ操作要素には、「SEL」属性が含まれています。この属性の値は、完全なXPath 1.0推奨の制限付きサブセットを備えたXPathセレクターです。「SEL」値は、ターゲットXMLドキュメントから単一の一意のターゲットノードを見つけるために使用されます。この配置されたノードは、変更のターゲットを特定し、通常は要素であり、たとえば自体を更新するか、一部の子ノードが追加されます。また、たとえば、コメントノードである可能性があり、その後、他の兄弟ノードが挿入されます。いずれにせよ、このセレクター値の評価中に複数のノードが見つかった場合、これはエラー条件です。
The XPath selections of the 'sel' attribute always start from the root node of a document. Thus, relative location paths SHOULD be used so that the starting root node selection "/" can be omitted. When locating elements in a document tree, a node test can either be a "*" character or a QName [W3C.REC-xml-names-20060816]. A "*" character selects all element children of the context node. Right after the node test, a location step can contain one or more predicates in any order. An attribute value comparison is one of the most typical predicates. The string value of the current context node or a child element may alternatively be used to identify elements in the tree. The character ".", which denotes a current context node selection, is an abbreviated form of "self::node()". Lastly, positional constraints like "[2]" can also be used as an additional predicate.
「SEL」属性のXPath選択は、常にドキュメントのルートノードから開始されます。したがって、開始ルートノードの選択 "/"を省略できるように、相対的な位置パスを使用する必要があります。ドキュメントツリーに要素を見つける場合、ノードテストは「*」文字またはQName [w3c.rec-xml-names-20060816]になります。「*」文字は、コンテキストノードのすべての要素の子供を選択します。ノードテストの直後、ロケーションステップには、任意の順序で1つ以上の述語を含めることができます。属性値の比較は、最も典型的な述語の1つです。現在のコンテキストノードまたは子要素の文字列値を使用して、ツリー内の要素を識別するために使用できます。現在のコンテキストノードの選択を示す文字「」は、「self :: node（）」の短縮形式です。最後に、「[2]」のような位置の制約は、追加の述語としても使用できます。
An XPath 1.0 "id()" node-set function MAY also be used to identify unique elements from the document tree. The schema that describes the content model of the document MUST then use an attribute with the type ID [W3C.REC-xmlschema-2-20041028] or with non-validating XML parsers, an "xml:id" [W3C.WD-xml-id-20041109] attribute MUST have been used within an instance document.
XPath 1.0 "ID（）"ノードセット関数を使用して、ドキュメントツリーから一意の要素を識別することもできます。ドキュメントのコンテンツモデルを記述するスキーマは、タイプID [W3C.REC-XMLSCHEMA-2-20041028]を使用して属性を使用するか、「XML：ID」[W3C.WD-XMLを検証するXMLパーサーを使用する必要があります。-id-20041109]属性は、インスタンスドキュメント内で使用されている必要があります。
The normal model for namespace prefixes is that they are local in scope. Thus, an XML diff document MAY have different prefixes for the namespaces used in the target document. The agent parsing the diff document MUST resolve prefixes separately in both documents in order to match the resulting QNames (qualified name) from each.
名前空間プレフィックスの通常のモデルは、それらが範囲がローカルであることです。したがって、XML DIFFドキュメントには、ターゲットドキュメントで使用されている名前空間に異なる接頭辞がある場合があります。DIFFドキュメントを解析するエージェントは、結果のQNAME（適格名）をそれぞれと一致させるために、両方のドキュメントでプレフィックスを個別に解決する必要があります。
The XML diff document MUST contain declarations for all namespaces used in the diff document. The diff document declarations are always used to determine what namespaces apply within the diff document.
XML DIFFドキュメントには、DIFFドキュメントで使用されるすべての名前空間の宣言を含める必要があります。DIFFドキュメント宣言は、常にDIFFドキュメント内に適用される名前空間を決定するために使用されます。
A selector in a diff document may use prefixes when naming elements. If it does use a prefix, the prefix must be looked up in the diff document namespace declarations.
DIFFドキュメントのセレクターは、要素を命名するときにプレフィックスを使用する場合があります。接頭辞を使用する場合、プレフィックスをDIFFドキュメント名空間宣言で調べる必要があります。
For example, the patch operation element of a diff document has an in-scope namespace declaration "xmlns:a='foo:'" with a selector "sel='a:bar'". The agent processing this patch MUST then look for a 'bar' element qualified with the 'foo:' namespace regardless of whether the 'foo:' namespace has a prefix assigned in the target document or what that prefix is.
たとえば、diffドキュメントのパッチ操作要素には、スコープ内の名前空間宣言 "xmlns： 'foo：'"セレクター "sel = 'a：bar'"があります。このパッチを処理するエージェントは、 'foo：' namespaceにターゲットドキュメントに割り当てられた接頭辞を持っているかどうか、またはそのプレフィックスが何であるかに関係なく、「foo： 'namespaceで適格な「bar」要素を探す必要があります。
Default namespaces make this model a little more complicated. When the diff document has a default namespace declaration, any element selector without a prefix MUST be evaluated using that namespace.
デフォルトの名前空間は、このモデルをもう少し複雑にします。DIFFドキュメントにデフォルトの名前空間宣言がある場合、プレフィックスのない要素セレクターをその名前空間を使用して評価する必要があります。
For example, the patch operation element of a diff document has an in-scope namespace declaration "xmlns='foo:'" with a selector "sel='bar'". The agent processing this patch MUST then look for a 'bar' element qualified with the 'foo:' namespace, regardless of whether the 'foo:' namespace has a prefix assigned in the target document or what that prefix is.
たとえば、diffドキュメントのパッチ操作要素には、スコープ内の名前空間宣言 "xmlns = 'foo：'"セレクター "sel = 'bar'"があります。このパッチを処理するエージェントは、「foo： '' namespaceがターゲットドキュメントに割り当てられた接頭辞またはそのプレフィックスが何であるかに関係なく、 'foo：' namespaceに適格な「bar」要素を探す必要があります。
Unqualified names are also possible. If there is no default namespace declared, and an element name appears without a prefix, then it is an unqualified element name. If this appears in a selector, it MUST match an unqualified element in the target document.
資格のない名前も可能です。デフォルトの名前空間が宣言されておらず、接頭辞なしで要素名が表示される場合、それは資格のない要素名です。これがセレクターに表示される場合、ターゲットドキュメントの資格のない要素と一致する必要があります。
For example, the patch operation element of a diff document has only one in-scope namespace declaration "xmlns:a='foo:'" with a selector "sel='bar'". Since the 'bar' element has no prefix, and there is no default namespace declaration in scope, the agent processing this patch can only match the selector against a 'bar' element that has no prefix and also no default namespace in scope.
たとえば、diffドキュメントのパッチ操作要素には、スコープ内の名前空間宣言「xmlns：a = 'foo：'」 "sel = 'bar'"を1つだけ持っています。「バー」要素には接頭辞がなく、スコープにデフォルトの名前空間宣言がないため、このパッチを処理するエージェントは、接頭辞がなく、スコープのデフォルトの名前空間がない「バー」要素とのみ一致させることができます。
The prefix matching rules described previously in this section are different from those required in XPath 1.0 and 2.0 [W3C.REC-xpath20-20070123]. In XPath 1.0, a "bar" selector always locates an unqualified <bar> element. In XPath 2.0, a "bar" selector not only matches an unqualified <bar> element, but also matches a qualified <bar> element that is in scope of a default namespace declaration. In contrast, in this specification, a selector without a prefix only matches one element, and it may match an element with or without a prefix but only if the namespace it's qualified with (or none) is an exact match.
このセクションで以前に説明したプレフィックスの一致ルールは、Xpath 1.0および2.0 [W3C.REC-XPATH20-20070123]で必要なルールとは異なります。Xpath 1.0では、「bar」セレクターは常に資格のない<bar>要素を見つけます。XPath 2.0では、「Bar」セレクターは、資格のない<bar>要素と一致するだけでなく、デフォルトの名前空間宣言の範囲内の適格な<bar>要素にも一致します。対照的に、この仕様では、プレフィックスのないセレクターは1つの要素と一致し、接頭辞の有無にかかわらず要素と一致する場合がありますが、名前空間が適格である（またはなし）が正確な一致である場合のみです。
The XPath 1.0 recommendation specifies "namespace-uri()" and "local-name()" node-set functions that can be used within predicates. These functions may be utilized during XPath evaluations if there are no other means to "register" prefixes with associated namespace URIs. They can also be used when handling selections where default namespaces are attached to elements. However, this specification does not allow the usage of these functions.
XPath 1.0の推奨事項は、述語内で使用できる「namespace-uri（）」および「local-name（）」ノードセット関数を指定します。これらの関数は、関連する名前空間URIを持つプレフィックスを「登録」する他の手段がない場合、XPath評価中に利用される場合があります。また、デフォルトの名前空間が要素に接続されている選択を処理するときにも使用できます。ただし、この仕様では、これらの機能の使用は許可されていません。
Elements within the changed data content are also in scope of namespace declarations. For example, when adding a new namespace qualified element to the target XML document, the diff document MUST contain a namespace declaration that applies to the element. The agent processing the diff document MUST ensure that the target document also contains the same namespace declaration. Similar to XPath, the same namespace declaration in this context means that the namespace URIs MUST be equal, but the prefixes MAY be different in the diff and target documents.
変更されたデータコンテンツ内の要素は、名前空間宣言の範囲にあります。たとえば、ターゲットXMLドキュメントに新しい名前空間認定要素を追加する場合、diffドキュメントには、要素に適用される名前空間宣言を含める必要があります。diffドキュメントを処理するエージェントは、ターゲットドキュメントに同じ名前空間宣言も含まれていることを確認する必要があります。XPathと同様に、このコンテキストで同じ名前空間宣言は、名前空間URIが等しくなければならないことを意味しますが、接頭辞はDIFFドキュメントとターゲットドキュメントで異なる場合があります。
For example, if a new added <a:bar> element has a namespace declaration reference to "xmlns:a='foo:'" in the diff document and the target document has only a single in-scope namespace declaration "xmlns:b='foo:'" at the insertion point, the namespace reference MUST be changed so that a <b:bar> element will then exist in the patched document. The same rule applies although default namespaces were used in either or both of the documents, the namespace URIs determine what will be the correct references (prefixes) in the patched document.
たとえば、新しい追加された<a：bar>要素に「xmlns：a = 'foo：'」への名前空間宣言の参照がある場合、diffドキュメントとターゲットドキュメントには単一のスコープ名前空間宣言 "xmlns：bのみがあります。= 'foo：' "挿入ポイントでは、パッチ付きドキュメントに<b：bar>要素が存在するように、名前空間参照を変更する必要があります。同じルールが適用されますが、デフォルトの名前空間はドキュメントのいずれかまたは両方で使用されていますが、名前空間URIは、パッチされたドキュメントの正しい参照（プレフィックス）とはどうなるかを決定します。
When the new or changed content has elements that declare new namespaces (locally scoped), these declarations are copied unaltered (prefix and everything) from the XML diff document to the target XML document. Default namespace declarations can only be added in this way, but prefixed namespace declarations MAY be added or removed with XPath namespace axis semantics shown later in this document (look Section 4.3.3).
新しいコンテンツまたは変更されたコンテンツに新しい名前空間（ローカルスコープ）を宣言する要素がある場合、これらの宣言はXML DIFFドキュメントからターゲットXMLドキュメントに変更されていない（プレフィックスおよびすべて）コピーされます。デフォルトの名前空間宣言はこの方法でのみ追加できますが、このドキュメントの後半に示されているXpath名空間軸セマンティクスでプレフィックス型の名前空間宣言を追加または削除することができます（セクション4.3.3を参照）。
A fairly difficult use case for these rules is found when the target document has several namespace declarations in scope for the same namespace. A target document might declare several different prefixes for the same namespace. Normally, the agent applying the diff document chooses *the* appropriate prefix for adding new elements to the target document, but in this special case there's more than one. These requirements create deterministic behavior for this special and in practice rare case:
これらのルールのかなり難しいユースケースは、ターゲットドキュメントに同じ名前空間の範囲のいくつかの名前空間宣言がある場合に見つかります。ターゲットドキュメントは、同じ名前空間のいくつかの異なるプレフィックスを宣言する場合があります。通常、DIFFドキュメントを適用するエージェントは、ターゲットドキュメントに新しい要素を追加するための *適切なプレフィックスを選択しますが、この特別なケースでは複数あります。これらの要件は、この特別および実際にはまれなケースの決定論的行動を生み出します。
- If the diff document happens to use a prefix that is one of the prefixes declared for the same namespace in the evaluation context node of the target document, this prefix MUST be used in the resulting patched document. An empty evaluable prefix and an existing in-scope default namespace declaration means that the default namespace MUST be chosen. In other words, the expanded names are then equal within the diff and patched documents.
- DIFFドキュメントが、ターゲットドキュメントの評価コンテキストノードで同じ名前空間に対して宣言されたプレフィックスの1つであるプレフィックスを使用している場合、このプレフィックスは、結果のパッチ付きドキュメントで使用する必要があります。空の評価可能なプレフィックスと既存のスコープ内デフォルトの名前空間宣言は、デフォルトの名前空間を選択する必要があることを意味します。言い換えれば、拡張された名前はdiffおよびパッチされたドキュメント内で等しくなります。
In an <add> operation, the evaluation context node is the parent element of the inserted node, for example, with a selector "sel='*/ bar'" and without a 'pos' attribute directive (look Section 4.3), it is the <bar> element of the root document element. With modifications of elements, the evaluation context node is the parent element of the modified element, and in the previous example thus the root document element.
<add>操作では、評価コンテキストノードは、たとえばセレクター「sel = '*/ bar'」を備えた挿入ノードの親要素であり、「POS」属性ディレクティブ（セクション4.3を参照）を使用して、ルートドキュメント要素の<bar>要素です。要素の変更により、評価コンテキストノードは変更された要素の親要素であり、前の例ではルートドキュメント要素です。
- Secondly, the prefix (also empty) of the evaluation context node MUST be chosen if the namespace URIs are equal.
- 第二に、名前空間URIが等しい場合は、評価コンテキストノードのプレフィックス（また空）を選択する必要があります。
- Lastly, if the above two rules still don't apply, first all in-scope namespace prefixes of the evaluation context node are arranged alphabetically in an ascending order. If a default namespace declaration exists, it is interpreted as the first entry in this list. The prefix from the list is then chosen that appears as the closest and just before the compared prefix if it were inserted into the list. If the compared prefix were to exist before the first prefix, the first prefix in the list MUST be selected (i.e., there's no default namespace).
- 最後に、上記の2つのルールがまだ適用されない場合、最初に評価コンテキストノードのすべてのスコープ内ネームスペースプレフィックスは、昇順でアルファベット順に配置されます。デフォルトの名前空間宣言が存在する場合、このリストの最初のエントリとして解釈されます。リストからの接頭辞は、リストに挿入された場合、比較プレフィックスの直前に最も近いものとして表示される選択されます。比較プレフィックスが最初のプレフィックスの前に存在する場合、リストの最初のプレフィックスを選択する必要があります（つまり、デフォルトの名前空間はありません）。
For example, if the list of in-scope prefixes in the target document is "x", "y" and the compared prefix in the diff document is "xx", then the "x" prefix MUST be chosen. If an "a" prefix were evaluated, the "x" prefix, the first entry MUST be chosen. If there were also an in-scope default namespace declaration, an evaluable "a" prefix would then select the default declaration. Note that unprefixed attributes don't inherit the default namespace declaration. When adding qualified attributes, the default namespace declaration is then not on this matching list of prefixes (see Section 4.3.2).
たとえば、ターゲットドキュメント内のスコープ内のプレフィックスのリストが「x」、「y」であり、diffドキュメントの比較プレフィックスが「xx」である場合、「x」プレフィックスを選択する必要があります。「a」プレフィックスが評価された場合、「x」プレフィックス、最初のエントリを選択する必要があります。スコープ内デフォルトの名前空間宣言もある場合、評価可能な「a」プレフィックスがデフォルトの宣言を選択します。未定の属性は、デフォルトの名前空間宣言を継承しないことに注意してください。適格な属性を追加すると、デフォルトの名前空間宣言は、このプレフィックスの一致するリストにはありません（セクション4.3.2を参照）。
Note that these requirements might mean that a resulting patched document could contain unused and/or superfluous namespace declarations. The resulting patched document MUST NOT be "cleaned up" such that these namespace declarations are removed.
これらの要件は、結果のパッチされたドキュメントに未使用および/または余分な名前空間宣言が含まれる可能性があることを意味する場合があることに注意してください。結果のパッチされたドキュメントを「クリーンアップ」してはならないため、これらの名前空間宣言が削除されるようにしてはなりません。
Note: In practice, the agent constructing a diff document can usually freely select the appropriate prefixes for the namespace declarations and it doesn't need to know or care about the actual prefixes in the target document unless there are overlapping declarations. In other words, the diff format content is typically independent of the target documents usage of namespace prefixes. However, it may be very useful to know where namespaces are declared in the target document. The most typical use case is such though, that the agent generating a diff has both the previous (target) and new (patched) documents available, and namespace declarations are thus exactly known. Note also, that in a case where the target document is not exactly known, it is allowed to use locally scoped namespace declarations, the consequences of which are larger and less human-readable patched documents.
注：実際には、DIFFドキュメントを構築するエージェントは通常、名前空間宣言の適切なプレフィックスを自由に選択でき、宣言が重複しない限り、ターゲットドキュメントの実際のプレフィックスを知ることも気にする必要もありません。言い換えれば、diff形式のコンテンツは、通常、名前空間プレフィックスのターゲットドキュメントの使用とは独立しています。ただし、ターゲットドキュメントの名前空間がどこで宣言されているかを知ることは非常に便利かもしれません。ただし、最も典型的なユースケースは、DIFFを生成するエージェントに以前の（ターゲット）ドキュメントと新しい（パッチされた）ドキュメントの両方が利用可能であるため、名前空間宣言が正確に知られています。また、ターゲットドキュメントが正確に知られていない場合、ローカルでスコープされた名前空間宣言を使用することが許可されていることに注意してください。
The <add> element represents the addition of some new content to the target XML document: for example, a new element can be appended into an existing element.
<add>要素は、ターゲットXMLドキュメントへの新しいコンテンツの追加を表します。たとえば、新しい要素を既存の要素に追加できます。
The new data content exists as the child node(s) of the <add> element. When adding attributes and namespaces, the child node of the <add> element MUST be a single text node. Otherwise, the <add> element MAY contain any mixture of element, text, comment or processing instruction nodes in any order. All children of the <add> element are then copied into a target XML document. The described namespace mangling procedure applies to added elements, which include all of their attribute, namespace and descendant nodes.
新しいデータコンテンツは、<add>要素の子ノードとして存在します。属性と名前空間を追加する場合、<add>要素の子ノードは単一のテキストノードでなければなりません。それ以外の場合、<add>要素には、要素、テキスト、コメント、または処理命令ノードの混合物が任意の順序で含まれている場合があります。<add>要素のすべての子供は、ターゲットXMLドキュメントにコピーされます。記載されている名前空間のマングリング手順は、すべての属性、名前空間、子孫ノードを含む追加された要素に適用されます。
The <add> element type has three attributes: 'sel', 'type', and 'pos'.
<add>要素タイプには、 'sel'、 'type'、および 'pos'の3つの属性があります。
The value of the optional 'type' attribute is only used when adding attributes and namespaces. Then, the located target node MUST be an element into which new attributes and namespace declarations are inserted. When the value of this 'type' attribute equals "@attr", the string "attr" is the name of the actual attribute being added. The value of this new 'attr' attribute is the text node content of the <add> element. The less frequently used prefixed (i.e., namespace-qualified) attributes can also be added. If the value of the 'type' attribute equals "namespace::pref", "pref" is the actual prefix string to be used for the namespace declaration in the patched document and the text node content of the <add> element contains the corresponding namespace URI.
オプションの「タイプ」属性の値は、属性と名前空間を追加するときにのみ使用されます。次に、配置されたターゲットノードは、新しい属性と名前空間宣言が挿入される要素でなければなりません。この「タイプ」属性の値が「@attr」に等しい場合、文字列「属性」は追加されている実際の属性の名前です。この新しい「属性」属性の値は、<add>要素のテキストノードコンテンツです。あまり頻繁に使用されていないプレフィックス（つまり、名前空間認定）属性も追加できます。「タイプ」属性の値が「namespace :: pref "、" pref "が等しい場合、パッチされたドキュメントの名前空間宣言に使用される実際のプレフィックス文字名前空間uri。
Note: The 'type' attribute is thus also an XPath selector, but it only locates attributes and namespaces. Attribute axis "attribute" has an abbreviated form "@" unlike the "namespace" axis, which doesn't have an abbreviated form. Double colons "::" are used as an axis separator in XPath.
注：「タイプ」属性はXPathセレクターでもありますが、属性と名前空間のみを見つけます。属性軸「属性」には、「名前空間」軸とは異なり、略式 "@"@"@"がありますが、これは略式形式のないものです。double Colons "::"は、Xpathの軸セパレーターとして使用されます。
The value of the optional 'pos' attribute indicates the positioning of new data content. It is not used when adding attributes or namespaces. When neither 'type' nor 'pos' attribute exist, the children of the <add> element are then appended as the last child node(s) of the located target element. When the value of 'pos' attribute is "prepend" the new node(s) are added as the first child node(s) of the located target element. With the value of "before", the added new node(s) MUST be the immediate preceding sibling node(s), and with "after", the immediate following sibling node(s) of the located target node.
オプションの「POS」属性の値は、新しいデータコンテンツの位置付けを示します。属性や名前空間を追加するときは使用されません。「タイプ」も「POS」属性が存在しない場合、<add>要素の子供は、配置されたターゲット要素の最後の子ノードとして追加されます。「POS」属性の値が「PREPEND」の場合、新しいノードが配置されたターゲット要素の最初の子ノードとして追加されます。「前」の値を使用すると、追加された新しいノードは、近くの兄弟ノード（s）であり、「後」にある兄弟ノードの即時の兄弟ノードの「後」でなければなりません。
Some examples follow that describe the use cases of these <add> element attributes. The nodes are not namespace qualified and prefixes are therefore not used, and the whole XML diff content is not shown in these examples, only patch operation elements. Full examples are given in an Appendix A.
これらの<add>要素属性のユースケースを説明するいくつかの例が続きます。ノードは名前空間の適格ではないため、プレフィックスは使用されません。XML DIFFコンテンツ全体は、これらの例には表示されず、パッチ操作要素のみが表示されます。完全な例は、付録Aに記載されています。
An example for an addition of an element:
要素を追加するための例：
<add sel="doc"><foo id="ert4773">This is a new child</foo></add>
Once the <doc> element has been found from the target XML document, a new <foo> element is appended as the last child node of the <doc> element. The located target node: the <doc> element is naturally the root element of the target XML document. The new <foo> element contains an 'id' attribute and a child text node.
Target XMLドキュメントから<doc>要素が見つかると、新しい<foo>要素が<doc>要素の最後の子ノードとして追加されます。配置されたターゲットノード：<doc>要素は、当然ターゲットXMLドキュメントのルート要素です。新しい<foo>要素には、「id」属性と子テキストノードが含まれています。
An example for an addition of an attribute:
属性を追加するための例：
<add sel="doc/foo[@id='ert4773']" type="@user">Bob</add>
This operation adds a new 'user' attribute to the <foo> element that was located by using an 'id' attribute value predicate. The value of this new 'user' attribute is "Bob".
この操作は、「ID」属性値のPRESTICEを使用して配置された<foo>要素に新しい「ユーザー」属性を追加します。この新しい「ユーザー」属性の値は「ボブ」です。
A similar patched XML document is achieved when using a validating XML parser, if the 'sel' selector value had been 'id("ert4773")' and if the data type of the 'id' attribute is "ID" [W3C.REC-xmlschema-2-20041028].
検証済みのXMLパーサーを使用する場合、「SEL」セレクター値が「ID（「ERT4773」）」であった場合、「ID」属性のデータ型が「ID」[W3C.REC.REC.REC.REC.REC.REC.REC.REC.REC.REC.REC.REC.REC.REC.REC.REC.REC.-xmlschema-2-20041028]。
Note that with namespace qualified attributes, the prefix matching rules within the 'type' attribute are evaluated with similar rules described in Section 4.2.3. Also, note that then the possible default namespace declaration of the context element isn't applicable.
名前空間認定属性を使用すると、「タイプ」属性内のプレフィックスマッチングルールは、セクション4.2.3で説明されている同様のルールで評価されることに注意してください。また、コンテキスト要素の可能なデフォルトの名前空間宣言は適用できないことに注意してください。
Note: As the 'sel' selector value MAY contain quotation marks, escaped forms: """ or "'" can be used within attribute values. However, it is often more appropriate to use the apostrophe (') character as shown in these examples. An alternative is also to interchange the apostrophes and quotation marks.
注：「SEL」セレクター値には引用符が含まれている可能性があるため、フォームは逃げます：「＆quot;」または「＆apos;」属性値内で使用できます。ただし、これらの例に示すように、アポストロフィ（ '）文字を使用する方が適切な場合がよくあります。別の方法は、アポストロフィと引用符を交換することでもあります。
An example for an addition of a prefixed namespace declaration:
接頭辞済みの名前空間宣言を追加する例：
<add sel="doc" type="namespace::pref">urn:ns:xxx</add>
This operation adds a new namespace declaration to the <doc> element. The prefix of this new namespace node is thus "pref" and the namespace URI is "urn:ns:xxx".
この操作は、新しい名前空間宣言を<doc>要素に追加します。したがって、この新しい名前空間ノードの接頭辞は「Pref」であり、名前空間URIは「urn：ns：xxx」です。
An example for an addition of a comment node:
コメントノードの追加の例：
<add
sel="doc/foo[@id='ert4773']" pos="before"><!-- comment --></add>
This operation adds a new comment node just before the <foo> element as an immediate preceding sibling node. This is also an example how a 'pos' attribute directive can be used.
この操作は、<foo>要素の直前の兄弟ノードの直前に新しいコメントノードを追加します。これは、「POS」属性ディレクティブをどのように使用できるかの例です。
Some complexity arises when so-called white space text nodes exist within a target XML document. The XPath 1.0 data model requires that a text node MUST NOT have another text node as an immediate sibling node. For instance, if an add operation is like this:
ターゲットXMLドキュメント内にいわゆるホワイトスペーステキストノードが存在する場合、ある程度の複雑さが生じます。XPath 1.0データモデルでは、テキストノードに即時の兄弟ノードとして別のテキストノードを持たないことが必要です。たとえば、追加操作が次の場合：
<add sel="doc">
<foo id="ert4773">This is a new child</foo></add>
The <add> element then has two child nodes: a white space text node (a linefeed and two spaces) and a <foo> element. If the existing last child of the <doc> element is a text node, its content and the white space text node content MUST then be combined together. Otherwise, (white space) text nodes can be added just like elements, and thus, the canonical form of the patched XML document easily remains deterministic. As several sibling nodes can be inserted with a single <add> operation, a "pretty printing" style can easily be maintained.
<add>要素には、ホワイトスペーステキストノード（ラインフィードと2つのスペース）と<foo>要素の2つの子ノードがあります。<doc>要素の既存の最後の子がテキストノードである場合、そのコンテンツとホワイトスペーステキストノードコンテンツを結合する必要があります。それ以外の場合、（ホワイトスペース）テキストノードは要素と同じように追加できます。したがって、パッチされたXMLドキュメントの標準形式は簡単に決定的なままです。いくつかの兄弟ノードを単一の<add>操作で挿入できるため、「きれいな印刷」スタイルを簡単に維持できます。
Still another example about the handling of text nodes. Consider this example:
テキストノードの処理に関するさらに別の例。この例を考えてみましょう。
<add sel="*/foo/text()[2]" pos="after">new<bar/>elem</add>
The second text node child of the <foo> element is first located. The added new content contains two text nodes and an element. As there cannot be immediate sibling text nodes, the located target text node content and the first new text node content MUST be combined together. In essence, if the 'pos' value had been "before", the second new text node content would effectively have been prepended to the located target text node.
<foo>要素の2番目のテキストノードの子が最初に配置されます。追加された新しいコンテンツには、2つのテキストノードと要素が含まれています。即時の兄弟テキストノードはないため、配置されたターゲットテキストノードコンテンツと最初の新しいテキストノードコンテンツを組み合わせる必要があります。本質的に、「POS」値が「前」だった場合、2番目の新しいテキストノードコンテンツは、特定のターゲットテキストノードに効果的に準備されていました。
Note: It is still worth noting that text nodes MAY contain CDATA sections, the latter of which are not treated as separate nodes. Once these CDATA sections exist within the new text nodes, they SHOULD be moved unaltered to the patched XML document.
注：テキストノードにはCDATAセクションが含まれている可能性があり、後者には個別のノードとして扱われないことはまだ注目に値します。これらのCDATAセクションが新しいテキストノード内に存在すると、パッチ付きXMLドキュメントに変更されていないように移動する必要があります。
While XML entities [W3C.REC-xml-20060816] cannot be patched with this framework, the references to other than predefined internal entities can exist within text nodes or attributes when the XML prolog contains those declarations. These references may then be preserved if both the XML diff and the target XML document have identical declarations within their prologs. Otherwise, references may be replaced with identical text as long as the "canonically equivalent" rule is obeyed.
XMLエンティティ[W3C.REC-XML-20060816]にこのフレームワークをパッチすることはできませんが、事前定義された内部エンティティ以外への参照は、XML Prologにそれらの宣言を含む場合、テキストノードまたは属性内に存在する可能性があります。これらの参照は、XML DIFFとターゲットXMLドキュメントの両方がプロログ内に同一の宣言を持っている場合、保存される場合があります。それ以外の場合、「標準的に同等の」ルールが従う限り、参照は同一のテキストに置き換えることができます。
The <replace> element represents a replacement operation: for example, an existing element is updated with a new element or an attribute value is replaced with a new value. This <replace> operation always updates a single node or node content at a time.
<plateg>要素は置換操作を表します。たとえば、既存の要素は新しい要素で更新されるか、属性値が新しい値に置き換えられます。この<telpless>操作は、常に単一のノードまたはノードのコンテンツを一度に更新します。
The <replace> element type only has a 'sel' attribute. If the located target node is an element, a comment or a processing instruction, then the child of the <replace> element MUST also be of the same type. Otherwise, the <replace> element MUST have text content or it MAY be empty when replacing an attribute value or a text node content.
<plateg>要素タイプには、「sel」属性のみがあります。配置されたターゲットノードが要素、コメント、または処理命令である場合、<telplect>要素の子も同じタイプでなければなりません。それ以外の場合、<telack>要素にはテキストコンテンツが必要な場合、または属性値またはテキストノードコンテンツを置き換えるときに空になる場合があります。
An example for a replacement of an element:
要素の交換の例：
<replace sel="doc/foo[@a='1']"><bar a="2"/></replace>
This will update the <foo> element that has an 'a' attribute with value "1". The located target element is replaced with the <bar> element. So all descendant nodes, namespace declarations, and attributes of the replaced <foo> element, if any existed, are thus removed.
これにより、値「1」を持つ「A」属性を持つ<foo>要素が更新されます。配置されたターゲット要素は、<bar>要素に置き換えられます。したがって、交換された<foo>要素のすべての子孫ノード、名前空間宣言、および属性が存在した場合、したがって、削除されます。
An example for a replacement of an attribute value:
属性値を置き換える例：
<replace sel="doc/@a">new value</replace>
This will replace the 'a' attribute content of the <doc> element with the value "new value". If the <replace> element is empty, the 'a' attribute MUST then remain in the patched XML document appearing like <doc a=""/>.
これにより、<doc>要素の「a」属性コンテンツを値「新しい値」に置き換えます。<telpless>要素が空の場合、 'a'属性は<doc a = ""/>のように表示されるパッチ付きxmlドキュメントに残る必要があります。
An example for a replacement of a namespace URI:
名前空間URIを交換する例：
<replace sel="doc/namespace::pref">urn:new:xxx</replace>
This will replace the URI value of 'pref' prefixed namespace node with "urn:new:xxx". The parent node of the namespace declaration MUST be the <doc> element, otherwise an error occurs.
これにより、「Pref」プレフィックス型の名前空間ノードのURI値が「urn：new：xxx」に置き換えられます。名前空間宣言の親ノードは<doc>要素でなければなりません。そうしないと、エラーが発生します。
An example for a replacement of a comment node:
コメントノードの交換の例：
<replace sel="doc/comment()[1]"><!-- This is the new content
--></replace>
This will replace a comment node. The located target node is the first comment node child of the <doc> element.
これにより、コメントノードが置き換えられます。配置されたターゲットノードは、<doc>要素の最初のコメントノードチャイルドです。
An example for a replacement of a processing instruction node:
処理命令ノードの交換の例：
<replace sel='doc/processing-instruction("test")'><?test bar="foobar"
?></replace>
This will replace the processing instruction node "test" whose parent is the <doc> element.
これは、親が<doc>要素である処理命令ノード「テスト」を置き換えます。
An example for a replacement of a text node:
テキストノードを置き換える例：
<replace
sel="doc/foo/text()[1]">This is the new text content</replace>
This will replace the first text node child of the <foo> element. The positional constraint "[1]" is not usually needed as the element content is rarely of mixed type [W3C.REC-xmlschema-1-20041028] where several text node siblings typically exist.
これは、<foo>要素の最初のテキストノードチャイルドを置き換えます。要素のコンテンツが混合型[W3C.REC-XMLSCHEMA-1-20041028]のめったにめったにないため、位置制約「[1]」は通常必要ありません。
If a text node is updated and the <replace> element is empty, the text node MUST thus be removed as a text node MUST always have at least one character of data.
テキストノードが更新され、<plateg>要素が空の場合、テキストノードは常に少なくとも1つの文字データを持つ必要があるため、テキストノードを削除する必要があります。
The <remove> element represents a removal operation of, for example, an existing element or an attribute.
<remove>要素は、たとえば既存の要素または属性の削除操作を表します。
The <remove> element type has two attributes: 'sel' and 'ws'. The value of the optional 'ws' attribute is used to remove the possible white space text nodes that exist either as immediate following or preceding sibling nodes of the located target node. The usage of 'ws' attribute is only allowed when removing other types than text, attribute and namespace nodes. If the value of 'ws' is "before", the purpose is to remove the immediate preceding sibling node that MUST be a white space text node and if the value is "after", the corresponding following node. If the 'ws' value is "both", both the preceding and following white space text nodes MUST be removed.
<remove>要素タイプには、「SEL」と「WS」の2つの属性があります。オプションの「WS」属性の値は、配置されたターゲットノードの即時または前の兄弟ノードとして存在する可能なホワイトスペーステキストノードを削除するために使用されます。「WS」属性の使用法は、テキスト、属性、名前空間ノード以外のタイプを削除する場合にのみ許可されます。「ws」の値が「前」の場合、目的は、ホワイトスペーステキストノードでなければならない直接の兄弟ノードを削除し、値が「後」の場合、対応する次のノードを削除することです。「WS」値が「両方」の場合、前のホワイトスペーステキストノードの両方を削除する必要があります。
An example of a removal of an element including all of its descendant, attribute, and namespace nodes:
その子孫、属性、名前空間ノードのすべてを含む要素の削除の例：
<remove sel="doc/foo[@a='1']" ws="after"/> This will remove the <foo> element as well as the immediate following sibling white space text node of the <foo> element. If the immediate following sibling node is not a white space text node, an error occurs.
<sel = "doc/foo [@a = '1']" ws = "afted"/>これにより、<foo>要素と<foo>要素の兄弟ホワイトスペースのテキストノードがすぐに削除されます。すぐに次の兄弟ノードがホワイトスペーステキストノードではない場合、エラーが発生します。
An example for a removal of an attribute node:
属性ノードの削除の例：
<remove sel="doc/@a"/>
This will remove the 'a' attribute node from the <doc> element.
これにより、<doc>要素から「a」属性ノードが削除されます。
An example for a removal of a prefixed namespace node:
接頭辞済みの名前空間ノードを削除する例：
<remove sel="doc/foo/namespace::pref"/>
This will remove the 'pref' prefixed namespace node from the <foo> element. Naturally, this prefix MUST NOT be associated with any node prior to the removal of this namespace node. Also, the parent node of this namespace declaration MUST be the <foo> element.
これにより、<foo>要素から「pref」prefixed namespaceノードが削除されます。当然のことながら、この名前空間ノードを削除する前に、このプレフィックスをノードに関連付けてはなりません。また、この名前空間宣言の親ノードは<foo>要素でなければなりません。
An example for a removal of a comment node:
コメントノードの削除の例：
<remove sel="doc/comment()[1]"/>
This will remove the first comment node child of the <doc> element.
これにより、<doc>要素の最初のコメントノードチャイルドが削除されます。
An example for a removal of a processing instruction node:
処理命令ノードの削除の例：
<remove sel='doc/processing-instruction("test")'/>
This will remove the "test" processing instruction node child of the <doc> element.
これにより、<doc>要素の「テスト」処理命令ノードの子が削除されます。
An example for a removal of a text node:
テキストノードの削除の例：
<remove sel="doc/foo/text()[1]"/>
This will remove the first text node child of the <foo> element.
これにより、<foo>要素の最初のテキストノードチャイルドが削除されます。
When removing an element, a comment, or a processing instruction node that has immediate preceding and following sibling text nodes without the 'ws' directive, the content of these two text nodes MUST be combined together. The latter text node thus disappears from the document.
要素、コメント、または「WS」指令なしで兄弟のテキストノードの前後に従った処理命令ノードを削除する場合、これら2つのテキストノードの内容を組み合わせる必要があります。したがって、後者のテキストノードはドキュメントから消えます。
It is an error condition if any of the patch operations cannot be unambiguously fulfilled. In other words, once a particular patch operation fails, it is an error condition and processing of further patch operations is hardly sensible.
パッチ操作のいずれかが明確に満たされない場合、これはエラー状態です。言い換えれば、特定のパッチ操作が失敗すると、それはエラー状態であり、さらなるパッチ操作の処理は賢明ではありません。
A new MIME error format is defined for applications that require deterministic error handling when patching cannot be applied. It is anticipated that these error elements can be used within other MIME types that allow extension elements.
新しいMIMEエラー形式は、パッチを適用できないときに決定論的エラー処理を必要とするアプリケーションに対して定義されます。これらのエラー要素は、拡張要素を可能にする他のMIMEタイプ内で使用できると予想されます。
The root element of the error document is <patch-ops-error>. The content of this element is a specific error condition. Each error condition is represented by a different element. This allows for different error conditions to provide different data about the nature of the error. All error elements support a "phrase" attribute, which can contain text meant for rendering to a human user. The optional "xml:lang" MAY be used to describe the language of the "phrase" attribute. Most of the error condition elements are supposed to contain the patch operation element that caused the patch to fail.
エラードキュメントのルート要素は<patch-ops-error>です。この要素の内容は、特定のエラー条件です。各エラー条件は、異なる要素で表されます。これにより、異なるエラー条件がエラーの性質に関する異なるデータを提供できるようになります。すべてのエラー要素は、「フレーズ」属性をサポートしています。これには、人間のユーザーへのレンダリング専用のテキストを含めることができます。オプションの「XML：Lang」を使用して、「フレーズ」属性の言語を記述できます。エラー条件要素のほとんどには、パッチが失敗したパッチ操作要素が含まれることになっています。
The following error elements are defined by this specification:
次のエラー要素は、この仕様で定義されています。
<invalid-attribute-value>: The validity constraints of 'sel', 'type', 'ws', or 'pos' attribute values MAY be indicated with this error, i.e., non-allowable content has been used. Also, this error can be used to indicate if an added or a modified attribute content is not valid, for example, CDATA sections were used when a new attribute was intended to be added.
<invalid-aTtribute-value>：「sel」、「type」、「ws」、または「pos」属性値の妥当性の制約は、このエラー、つまり、許容できないコンテンツが使用されている場合があります。また、このエラーを使用して、追加または変更された属性コンテンツが有効でないかどうかを示すことができます。たとえば、新しい属性を追加することを目的とした場合、CDATAセクションが使用されました。
<invalid-character-set>: The patch could not be applied because the diff and the patched document use different character sets.
<invalid-character-set>：diffとパッチされたドキュメントが異なる文字セットを使用しているため、パッチを適用できませんでした。
<invalid-diff-format>: This indicates that the diff body of the request was not a well-formed XML document or a valid XML document according to its schema.
<invalid-diff-format>：これは、リクエストのdiff本体が、そのスキーマに従って、よく形成されたXMLドキュメントまたは有効なXMLドキュメントではなかったことを示しています。
<invalid-entity-declaration>: An entity reference was found but corresponding declaration could not be located or resolved.
<invalid-entity-declaration>：エンティティの参照が見つかりましたが、対応する宣言は見つけることも解決できませんでした。
<invalid-namespace-prefix>: The namespace URI for the given prefix could not be located or resolved, e.g., within the 'sel' attribute a prefix was used but its declaration is missing from the target document.
<Invalid-namespace-prefix>：指定されたプレフィックスの名前空間URIは、「sel」属性内の接頭辞が使用されましたが、その宣言はターゲットドキュメントから欠落しています。
<invalid-namespace-uri>: The namespace URI value is not valid or the target document did not have this declaration.
<invalid-namespace-uri>：名前空間URI値は有効ではないか、ターゲットドキュメントにこの宣言がありませんでした。
<invalid-node-types>: The node types of a <replace> operation did not match, i.e., for example, the 'sel' selector locates an element but the replaceable content is of text type. Also, a <replace> operation may locate a unique element, but replaceable content had multiple nodes.
<Invalid-node-types>：a <efter>操作のノードタイプは一致しませんでした。たとえば、「sel」セレクターは要素を見つけますが、交換可能なコンテンツはテキストタイプです。また、<telpless>操作は一意の要素を見つける場合がありますが、交換可能なコンテンツには複数のノードがありました。
<invalid-patch-directive>: A patch directive could not be fulfilled because the given directives were not understood.
<invalid-patch-directive>：指定された指令が理解されていないため、パッチ指令を満たすことができませんでした。
<invalid-root-element-operation>: The root element of the document cannot be removed or another sibling element for the document root element cannot be added.
<Invalid-Root-Element-Operation>：ドキュメントのルート要素を削除できないか、ドキュメントルート要素の別の兄弟要素を追加できません。
<invalid-xml-prolog-operation>: Patch failure related to XML prolog nodes.
<invalid-xml-prolog-operation>：XMLプロログノードに関連するパッチ障害。
<invalid-whitespace-directive>: A <remove> operation requires a removal of a white space node that doesn't exist in the target document.
<invalid-whitespace-directive>：a <remove>操作には、ターゲットドキュメントに存在しない空白ノードを取り外す必要があります。
<unlocated-node>: A single unique node (typically an element) could not be located with the 'sel' attribute value. Also, the location of multiple nodes can lead to this error.
<Luncated-Node>：単一の一意のノード（通常、要素）は、「SEL」属性値を持つことはできませんでした。また、複数のノードの位置がこのエラーにつながる可能性があります。
<unsupported-id-function>: The nodeset function id() is not supported, and thus attributes with the ID type are not known.
<unsupported-id-function>：nodeset function id（）はサポートされていないため、IDタイプの属性は不明です。
<unsupported-xml-id>: The attribute xml:id as an ID attribute in XML documents is not supported.
<unsupported-xml-id>：xmlドキュメントのID属性としての属性XML：IDはサポートされていません。
Additional error elements can be indicated within the root <patch-ops-error> element from any namespace. However, the IETF MAY specify additional error elements in the "urn:ietf:params:xml:ns:patch-ops-error" namespace.
追加のエラー要素は、任意の名前空間からルート<パッチエラー>要素内で示すことができます。ただし、IETFは、「urn：ietf：params：xml：ns：patch-ops-error」ネームスペースに追加のエラー要素を指定する場合があります。
As an example, the following document indicates that it was attempted to add a new <note> element with white space into a document, but the parent element could not be located:
例として、次のドキュメントは、ドキュメントに白い空間を含む新しい<Note>要素を追加しようとしたことを示していますが、親要素は配置できませんでした。
<?xml version="1.0" encoding="UTF-8"?>
<patch-ops-error
xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
xmlns="urn:ietf:params:xml:ns:patch-ops-error">
<unlocated-node
phrase="a unique node could not be located with the id() function."
><p:add sel='id("ert4773")'>
<p:note>some text added</p:note>
</p:add></unlocated-node>
</patch-ops-error>
An XML diff document SHOULD contain only the nodes that have been modified as the intention is to try to reduce bandwidth/storage requirements. However, when there's a large collection of changes it can be desirable to exchange the full document content instead. How this will be done in practice is beyond the scope of this document.
XML DIFFドキュメントには、帯域幅/ストレージの要件を削減しようとする意図として変更されたノードのみを含める必要があります。ただし、変更の大規模なコレクションがある場合、代わりにドキュメントコンテンツ全体を交換することが望ましい場合があります。これが実際に行われる方法は、このドキュメントの範囲を超えています。
Some applications MAY require that the full versioning history MUST be indicated although the history had superfluous changes. This framework doesn't mandate any specific behavior, applications MAY decide the appropriate semantics themselves. Also, in practice, applications are free to select the proper algorithms when generating diff document content.
一部のアプリケーションでは、履歴には余分な変更があったが、完全なバージョンの履歴を示す必要がある場合があります。このフレームワークは特定の動作を義務付けるものではなく、アプリケーションは適切なセマンティクス自体を決定する場合があります。また、実際には、DIFFドキュメントコンテンツを生成するときに、適切なアルゴリズムを自由に選択できます。
It is up to the application to decide what kind of selector values to use. Positional element selectors like "*/*[3]/*[2]" provide the shortest selectors, but care must to taken when using them. When there are several removals of sibling elements, the positional element indexes change after each update. Likewise these indexes change when new elements are inserted into the tree. Using names with possible attribute predicates like "doc[@sel='foo']" is usually easier for an application, be it for example an auto diff tool, but it leads to larger diff documents.
使用するセレクター値の種類を決定するのはアプリケーション次第です。「*/*[3]/*[2]」のような位置要素セレクターは、最短セレクターを提供しますが、それらを使用するときは注意する必要があります。兄弟要素のいくつかの除去がある場合、各更新後に位置要素インデックスが変わります。同様に、これらのインデックスは、新しい要素がツリーに挿入されると変更されます。「doc [@sel = 'foo']」などの属性述語を可能にする名前を使用すると、通常、アプリケーションでは自動diffツールなどが簡単ですが、より大きなdiffドキュメントにつながります。
The schema types for the patch operation elements.
パッチ操作要素のスキーマタイプ。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE schema [
<!ENTITY ncname "\i\c*">
<!ENTITY qname "(&ncname;:)?&ncname;">
<!ENTITY aname "@&qname;">
<!ENTITY pos "\[\d+\]">
<!ENTITY attr "\[&aname;='(.)*'\]|\[&aname;="(.)*"\]">
<!ENTITY valueq "\[(&qname;|\.)="(.)*"\]">
<!ENTITY value "\[(&qname;|\.)='(.)*'\]|&valueq;">
<!ENTITY cond "&attr;|&value;|&pos;">
<!ENTITY step "(&qname;|\*)(&cond;)*">
<!ENTITY piq "processing-instruction\(("&ncname;")\)">
<!ENTITY pi "processing-instruction\(('&ncname;')?\)|&piq;">
<!ENTITY id "id\(('&ncname;')?\)|id\(("&ncname;")?\)">
<!ENTITY com "comment\(\)">
<!ENTITY text "text\(\)">
<!ENTITY nspa "namespace::&ncname;">
<!ENTITY cnodes "(&text;(&pos;)?)|(&com;(&pos;)?)|((π)(&pos;)?)">
<!ENTITY child "&cnodes;|&step;">
<!ENTITY last "(&child;|&aname;|&nspa;)">
]>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xsd:simpleType name="xpath">
<xsd:restriction base="xsd:string">
<xsd:pattern
value="(/)?((&id;)((/&step;)*(/&last;))?|(&step;/)*(&last;))"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="xpath-add">
<xsd:restriction base="xsd:string">
<xsd:pattern
value="(/)?((&id;)((/&step;)*(/&child;))?|(&step;/)*(&child;))"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="pos">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="before"/>
<xsd:enumeration value="after"/>
<xsd:enumeration value="prepend"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="type">
<xsd:restriction base="xsd:string">
<xsd:pattern value="&aname;|&nspa;"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="add">
<xsd:complexContent mixed="true">
<xsd:restriction base="xsd:anyType">
<xsd:sequence>
<xsd:any processContents="lax" namespace="##any"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="sel" type="xpath-add"
use="required"/>
<xsd:attribute name="pos" type="pos"/>
<xsd:attribute name="type" type="type"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="replace">
<xsd:complexContent mixed="true">
<xsd:restriction base="xsd:anyType">
<xsd:sequence>
<xsd:any processContents="lax" namespace="##any"
minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="sel" type="xpath" use="required"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:simpleType name="ws">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="before"/>
<xsd:enumeration value="after"/>
<xsd:enumeration value="both"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="remove">
<xsd:attribute name="sel" type="xpath" use="required"/>
<xsd:attribute name="ws" type="ws"/>
</xsd:complexType>
</xsd:schema>
The patch operation errors definitions.
パッチ操作エラー定義。
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
targetNamespace="urn:ietf:params:xml:ns:patch-ops-error"
xmlns:tns="urn:ietf:params:xml:ns:patch-ops-error"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- ROOT document element for signaling patch-ops errors -->
<xsd:element name="patch-ops-error">
<xsd:complexType>
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:anyAttribute processContents="lax"/>
</xsd:complexType>
</xsd:element>
<!-- patch-ops error elements:
not intended to be used as root documnet elements -->
<xsd:element name="invalid-attribute-value"
type="tns:patch-error"/>
<xsd:element name="invalid-character-set"
type="tns:patch-error-simple"/>
<xsd:element name="invalid-diff-format"
type="tns:patch-error-simple"/>
<xsd:element name="invalid-entity-declaration"
type="tns:patch-error"/>
<xsd:element name="invalid-namespace-prefix"
type="tns:patch-error"/>
<xsd:element name="invalid-namespace-uri"
type="tns:patch-error"/>
<xsd:element name="invalid-node-types"
type="tns:patch-error"/>
<xsd:element name="invalid-patch-directive"
type="tns:patch-error"/>
<xsd:element name="invalid-root-element-operation"
type="tns:patch-error"/>
<xsd:element name="invalid-xml-prolog-operation"
type="tns:patch-error"/>
<xsd:element name="invalid-whitespace-directive"
type="tns:patch-error"/>
<xsd:element name="unlocated-node"
type="tns:patch-error"/>
<xsd:element name="unsupported-id-function"
type="tns:patch-error"/>
<xsd:element name="unsupported-xml-id"
type="tns:patch-error"/>
<!-- simple patch-ops error type -->
<xsd:complexType name="patch-error-simple">
<xsd:attribute name="phrase" type="xsd:string"/>
<xsd:attribute ref="xml:lang"/>
<xsd:anyAttribute processContents="lax"/>
</xsd:complexType>
<!-- error type which includes patch operation -->
<xsd:complexType name="patch-error">
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax"/>
</xsd:sequence>
<xsd:attribute name="phrase" type="xsd:string"/>
<xsd:attribute ref="xml:lang"/>
<xsd:anyAttribute processContents="lax"/>
</xsd:complexType>
</xsd:schema>
IANA has completed the following actions:
IANAは次のアクションを完了しました。
o registered a new XML namespace URN according to the procedures of RFC 3688 [RFC3688].
o RFC 3688 [RFC3688]の手順に従って、新しいXMLネームスペースURNを登録しました。
o registered a new MIME type 'application/patch-ops-error+xml' according to the procedures of RFC 4288 [RFC4288] and guidelines in RFC 3023 [RFC3023].
o RFC 4288 [RFC4288]の手順とRFC 3023 [RFC3023]のガイドラインに従って、新しいMIMEタイプ「アプリケーション/PATCH-OPS-ERROR XML」を登録しました。
o registered two XML Schemas according to the procedures of RFC 3688 [RFC3688].
o RFC 3688 [RFC3688]の手順に従って2つのXMLスキーマを登録しました。
This specification registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688].
この仕様は、RFC 3688 [RFC3688]のガイドラインに従って、新しいXML名前空間を登録します。
URI: The URI for this namespace is
urn:ietf:params:xml:ns:patch-ops-error
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jari Urpalainen (jari.urpalainen@nokia.com).
登録者の連絡先：IETF、Simple Working Group、（simple@ietf.org）、Jari Urpalainen（jari.urpalainen@nokia.com）。
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Patch-Ops Error Namespace</title>
</head>
<body>
<h1>Namespace for Patch-Ops Error Documents</h1>
<h2>urn:ietf:params:xml:ns:patch-ops-error</h2>
<p>See <a
href="http://www.rfc-editor.org/rfc/rfc5261.txt">RFC5261</a>.</p>
</body>
</html>
END
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: patch-ops-error+xml
MIMEサブタイプ名：patch-ops-error XML
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [RFC3023].
オプションのパラメーター：RFC 3023 [RFC3023]で指定されているCharsetパラメーターアプリケーション/XMLと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
考慮事項のエンコード：RFC 3023 [RFC3023]で指定されているアプリケーション/XMLの考慮事項のエンコードと同じ。
Security considerations: See Section 10 of RFC 3023 [RFC3023].
セキュリティ上の考慮事項：RFC 3023 [RFC3023]のセクション10を参照してください。
Interoperability considerations: none.
相互運用性の考慮事項：なし。
Published specification: RFC 5261 Applications which use this media type: This document type has been used to support transport of Patch-Ops errors in RFC 5261.
公開された仕様：このメディアタイプを使用するRFC 5261アプリケーション：このドキュメントタイプは、RFC 5261でのパッチオップエラーの輸送をサポートするために使用されています。
Additional Information:
追加情報：
Magic Number: None
マジックナンバー：なし
File Extension: .xer
ファイル拡張子：.xer
Macintosh file type code: "TEXT"
Macintoshファイルタイプコード：「テキスト」
Personal and email address for further information: Jari Urpalainen, jari.urpalainen@nokia.com
個人および電子メールアドレス詳細情報：Jari Urpalainen、jari.urpalainen@nokia.com
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: The IETF
著者/変更コントローラー：IETF
This section registers a new XML Schema, the sole content of which is shown in Section 8.
このセクションでは、新しいXMLスキーマを登録します。その唯一のコンテンツはセクション8に示されています。
URI:
urn:ietf:params:xml:schema:patch-ops
Registrant Contact:
IETF, SIMPLE working group, <simple@ietf.org>
Jari Urpalainen, <jari.urpalainen@nokia.com>
This section registers a new XML Schema, the sole content of which is shown in Section 9.
このセクションでは、新しいXMLスキーマを登録します。その唯一のコンテンツはセクション9に示されています。
URI:
urn:ietf:params:xml:schema:patch-ops-error
Registrant Contact:
IETF, SIMPLE working group, <simple@ietf.org>
Jari Urpalainen, <jari.urpalainen@nokia.com>
Security considerations depend very much on the application that utilizes this framework. Since each application will have different needs, threat models, and security features, it will be necessary to consider these on an application-by-application basis.
セキュリティ上の考慮事項は、このフレームワークを利用するアプリケーションに大きく依存しています。各アプリケーションには異なるニーズ、脅威モデル、セキュリティ機能があるため、アプリケーションごとにこれらを考慮する必要があります。
However, this framework utilizes a limited subset of XPath 1.0. Applications may thus be vulnerable to XPath injection attacks that can reveal some non-allowable content of an XML document. Injection attacks are most likely with shareable resources where access to a resource is limited to only some specific parts for a user, contrary to a typical use case of this framework. To defend against those attacks the input MUST be sanitized which can be done, for example, by validating the diff formats with these restrictive schemas.
ただし、このフレームワークでは、Xpath 1.0の限られたサブセットを使用しています。したがって、アプリケーションは、XMLドキュメントの許容不可能なコンテンツを明らかにすることができるXPathインジェクション攻撃に対して脆弱である可能性があります。注入攻撃は、このフレームワークの典型的なユースケースに反して、リソースへのアクセスがユーザーの特定のパーツのみに制限される共有可能なリソースを使用する可能性が最も高いです。これらの攻撃を防御するには、これらの制限的なスキーマを使用してDIFF形式を検証することにより、入力をサニタイズする必要があります。
The author would like to thank Lisa Dusseault for her efforts including BoF arrangements, comments and editing assistance. The author would also like to thank Eva Leppanen, Mikko Lonnfors, Aki Niemi, Jonathan Rosenberg, Miguel A. Garcia, Anat Angel, Stephane Bortzmeyer, Dave Crocker, Joel Halpern, Jeffrey Hutzelman, David Ward, and Chris Newman for their valuable comments and Ted Hardie for his input and support.
著者は、BOFのアレンジメント、コメント、編集支援などの努力について、リサ・デュセールトに感謝したいと思います。著者はまた、エヴァ・レパネン、ミッコ・ロンフォース、アキ・ニーミ、ジョナサン・ローゼンバーグ、ミゲル・A・ガルシア、アナット・エンジェル、ステファン・ボルツマイヤー、デイブ・クロッカー、ジョエル・ハルパーン、ジェフリー・ハッツェルマン、デイヴィッド・ワード、そしてティルス・ニューマンの大規模なコメントとChris Newmanに感謝したいと思います。彼の意見とサポートのためにテッド・ハーディー。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[W3C.REC-xml-20060816] Maler, E., Paoli, J., Bray, T., Yergeau, F., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium Recommendation REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.
[W3C.REC-XML-20060816] Maler、E.、Paoli、J.、Bray、T.、Yergeau、F。、およびC. Sperberg-Mcqueen、「拡張可能なマークアップ言語（XML）1.0（第4版）」、World Wide Web Consortiumの推奨REC-XML-20060816、2006年8月、<http://www.w3.org/tr/2006/rec-xml-20060816>。
[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）バージョン1.0」、World Wide Web Consortiumの推奨REC-XPATH-1991116、1999年11月、<http：// www。w3.org/tr/1999/rec-xpath-19991116>。
[W3C.REC-xml-names-20060816] Hollander, D., Bray, T., Layman, A., and R. Tobin, "Namespaces in XML 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xml-names-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-names-20060816>.
[W3C.REC-XML-NAMES-20060816] Hollander、D.、Bray、T.、Layman、A。、およびR. Tobin、「XML 1.0の名前空間（第2版）」、World Wide Web Consortiumの推奨REC-XML-Names-20060816、2006年8月、<http://www.w3.org/tr/2006/REC-XML-NAMES-20060816>。
[W3C.REC-xmlschema-1-20041028] Beech, D., Thompson, H., 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] BEECH、D.、THOMPSON、H.、MALONEY、M。、およびN. MENDELSOHN、「XML Schema Part 1：Structures Second Edition」、World Wide Web Consortiumの推奨Rec-Xmlschema-1-20041028、2004年10月、<http://www.w3.org/tr/2004/rec-xmlschema-1-20041028>。
[W3C.REC-xml-c14n-20010315] Boyer, J., "Canonical XML Version 1.0", World Wide Web Consortium Recommendation REC-xml-c14n-20010315, March 2001, <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
[W3C.REC-XML-C14N-20010315] Boyer、J。、「Canonical XMLバージョン1.0」、World Wide Webコンソーシアムの推奨REC-XML-C14N-20010315、2001年3月、<http://www.w3.org/TR/2001/REC-XML-C14N-20010315>。
[W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[W3C.REC-XMLSCHEMA-2-20041028] Malhotra、A。およびP. Biron、「XML Schema Part 2：Datatypes Second Edition」、World Wide Web Consortiumの推奨REC-XMLSCHEMA-20041028、2004年10月、<http：//www.w3.org/tr/2004/rec-xmlschema-2-20041028>。
[W3C.WD-xml-id-20041109] Veillard, D., Walsh, N., and J. Marsh, "xml:id Version 1.0", W3C LastCall WD-xml-id-20041109, November 2004.
[W3C.WD-XML-ID-ID-20041109] Veillard、D.、Walsh、N。、およびJ. Marsh、 "XML：IDバージョン1.0"、W3C LastCall WD-XML-ID-20041109、2004年11月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[W3C.REC-xpath20-20070123] Berglund, A., Fernandez, M., Chamberlin, D., Boag, S., Robie, J., Kay, M., and J. Simeon, "XML Path Language (XPath) 2.0", World Wide Web Consortium Recommendation REC-xpath20-20070123, January 2007, <http://www.w3.org/TR/2007/REC-xpath20-20070123>.
[W3C.REC-XPATH20-20070123] Berglund、A.、Fernandez、M.、Chamberlin、D.、Boag、S.、Robie、J.、Kay、M.、およびJ. Simeon、 "XML Path Language（XPath）2.0 "、World Wide Web Consortiumの推奨rec-XPath20-20070123、2007年1月、<http://www.w3.org/tr/2007/rec-xpath20-20070123>。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825] Rosenberg、J。、「拡張可能なマークアップ言語（XML）構成アクセスプロトコル（XCAP）」、RFC 4825、2007年5月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[RFC5262] Lonnfors, M., Leppanen, E., Khartabil, H., and J. Urpalainen, "Presence Information Data format (PIDF) Extension for Partial Presence", RFC 5262, September 2008.
[RFC5262] Lonnfors、M.、Leppanen、E.、Khartabil、H。、およびJ. Urpalainen、「部分的存在のための存在情報データ形式（PIDF）拡張」、RFC 5262、2008年9月。
[SIMPLE-XCAP] Urpalainen, J. and J. Rosenberg, "An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources", Work in Progress, May 2008.
[Simple-XCap] Urpalainen、J。およびJ. Rosenberg、「XML構成アクセスプロトコル（XCAP）リソースの変更を示すための拡張可能なマークアップ言語（XML）ドキュメント形式」、2008年5月の作業。
[RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903] Niemi、A.、ed。、「セッション開始プロトコル（SIP）イベント州の出版物の拡張」、RFC 3903、2004年10月。
All following examples assume an imaginary XML diff document including these patch operation elements.
次のすべての例は、これらのパッチ操作要素を含む虚数XML DIFFドキュメントを想定しています。
An example target XML document:
ターゲットXMLドキュメントの例：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
</doc>
An XML diff document:
XML DIFFドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<add sel="doc"><foo id="ert4773">This is a new child</foo></add>
</diff>
A result 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>
An example target 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>
An XML diff document:
XML DIFFドキュメント：
<?xml version="1.0" encoding="UTF-8"?> <diff> <add sel="doc/foo[@id='ert4773']" type="@user">Bob</add> </diff> A result XML document:
<？xml version = "1.0" encoding = "utf-8"？> <diff> <add sel = "doc/foo [@id = 'ert4773']" type = "@user"> bob </add> </diff>結果XMLドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<foo id="ert4773" user="Bob">This is a new child</foo></doc>
An example target 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>
An XML diff document:
XML DIFFドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<add sel="doc" type="namespace::pref">urn:ns:xxx</add>
</diff>
A result XML document:
結果XMLドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns:pref="urn:ns:xxx">
<note>This is a sample document</note>
<foo id="ert4773">This is a new child</foo></doc>
An example target 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>
An XML diff document:
XML DIFFドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<add sel="doc/foo[@id='ert4773']" pos="before"><!-- comment --></add>
</diff>
A result XML document:
結果XMLドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<!-- comment --><foo id="ert4773">This is a new child</foo></doc>
An example target XML document:
ターゲットXMLドキュメントの例：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
</doc>
An XML diff document:
XML DIFFドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<add sel="doc">
<foo id="ert4773">This is a new child</foo></add>
</diff>
A result 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>
An example target XML document:
ターゲットXMLドキュメントの例：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
An XML diff document:
XML DIFFドキュメント：
<?xml version="1.0" encoding="UTF-8"?> <diff> <replace sel="doc/foo[@a='1']"><bar a="2"/></replace> </diff> A result XML document:
<？xmlバージョン= "1.0" encoding = "utf-8"？> <diff> <sel = "doc/foo [@a = '1']"> <bar a = "2"/> </cheplage> </diff>結果XMLドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<bar a="2"/>
</doc>
An example target XML document:
ターゲットXMLドキュメントの例：
<?xml version="1.0" encoding="UTF-8"?>
<doc a="test">
<foo a="1">This is a sample document</foo>
</doc>
An XML diff document:
XML DIFFドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<replace sel="doc/@a">new value</replace>
</diff>
A result XML document:
結果XMLドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<doc a="new value">
<foo a="1">This is a sample document</foo>
</doc>
An example target XML document:
ターゲットXMLドキュメントの例：
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns:pref="urn:test">
<foo a="1">This is a sample document</foo>
</doc>
An XML diff document:
XML DIFFドキュメント：
<?xml version="1.0" encoding="UTF-8"?> <diff> <replace sel="doc/namespace::pref">urn:new:xxx</replace> </diff> A result XML document:
<？xml version = "1.0" encoding = "utf-8"？> <diff> <celpless sel = "doc/namespace :: pref"> urn：new：xxx </falling> </diff> result xml document：
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns:pref="urn:new:xxx">
<foo a="1">This is a sample document</foo>
</doc>
An example target XML document:
ターゲットXMLドキュメントの例：
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns:pref="urn:test">
<foo a="1">This is a sample document</foo>
<!-- comment -->
</doc>
An XML diff document:
XML DIFFドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<replace sel="doc/comment()[1]"><!-- This is the new content
--></replace>
</diff>
A result XML document:
結果XMLドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns:pref="urn:test">
<foo a="1">This is a sample document</foo>
<!-- This is the new content
-->
</doc>
An example target XML document:
ターゲットXMLドキュメントの例：
<?xml version="1.0" encoding="UTF-8"?> <doc> <foo a="1">This is a sample document</foo> <?test foo="bar"?> </doc> An XML diff document:
<？xml version = "1.0" encoding = "utf-8"？> <doc> <foo a = "1">これはサンプルドキュメントです</foo> <？foo = "bar"？> </doc> XML DIFFドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<replace sel='doc/processing-instruction("test")'
><?test bar="foobar"?></replace>
</diff>
A result XML document:
結果XMLドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
<?test bar="foobar"?>
</doc>
An example target XML document:
ターゲットXMLドキュメントの例：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
An XML diff document:
XML DIFFドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<replace sel="doc/foo/text()[1]"
>This is the new text content</replace></diff>
A result XML document:
結果XMLドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is the new text content</foo>
</doc>
An example target XML document:
ターゲットXMLドキュメントの例：
<?xml version="1.0" encoding="UTF-8"?> <doc> <foo a="1">This is a sample document</foo> </doc> An XML diff document:
<？xml version = "1.0" encoding = "utf-8"？> <doc> <foo a = "1">これはサンプル文書です</foo> </doc> xml diffドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel="doc/foo[@a='1']" ws="after"/>
</diff>
A result XML document:
結果XMLドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
</doc>
An example target XML document:
ターゲットXMLドキュメントの例：
<?xml version="1.0" encoding="UTF-8"?>
<doc a="foo">
<foo a="1">This is a sample document</foo>
</doc>
An XML diff document:
XML DIFFドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel="doc/@a"/>
</diff>
A result XML document:
結果XMLドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
An example target XML document:
ターゲットXMLドキュメントの例：
<?xml version="1.0" encoding="UTF-8"?> <doc> <foo a="1" xmlns:pref="urn:test" >This is a sample document</foo> <!-- comment --> </doc> An XML diff document:
<？xml version = "1.0" encoding = "utf-8"？> <doc> <foo a = "1" xmlns：pref = "urn：test">これはサンプルドキュメントです</foo> <！ - コメント - > </doc> xml diffドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel="doc/foo/namespace::pref"/>
</diff>
A result XML document:
結果XMLドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
<!-- comment -->
</doc>
An example target XML document:
ターゲットXMLドキュメントの例：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
<!-- comment -->
</doc>
An XML diff document:
XML DIFFドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel="doc/comment()[1]" ws="after"/>
</diff>
A result XML document:
結果XMLドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
An example target XML document:
ターゲットXMLドキュメントの例：
<?xml version="1.0" encoding="UTF-8"?> <doc> <foo a="1">This is a sample document</foo> <?test?> </doc> An XML diff document:
<？xmlバージョン= "1.0" encoding = "utf-8"？> <doc> <foo a = "1">これはサンプルドキュメントです</foo> <？test？> </doc> xml diffドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel='doc/processing-instruction("test")'/>
</diff>
A result XML document:
結果XMLドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
An example target XML document:
ターゲットXMLドキュメントの例：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
An XML diff document:
XML DIFFドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel="doc/foo/text()[1]"/>
</diff>
A result XML document:
結果XMLドキュメント：
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1"/>
</doc>
An example target XML document where namespace qualified elements exist:
名前空間認定要素が存在するターゲットXMLドキュメントの例：
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns="urn:ietf:params:xml:ns:xxx"
xmlns:z="urn:ietf:params:xml:ns:yyy">
<note>This is a sample document</note>
<elem a="foo">
<child/>
</elem>
<elem a="bar">
<z:child/>
</elem>
</doc>
An imaginary XML diff document where prefix "p" corresponds the targetNamespace of this imaginary schema:
想像上のXML Diffドキュメント「P」がこの想像上のスキーマのターゲットネームスペースに対応する場合は、次のとおりです。
<?xml version="1.0" encoding="UTF-8"?>
<p:diff xmlns="urn:ietf:params:xml:ns:xxx"
xmlns:y="urn:ietf:params:xml:ns:yyy"
xmlns:p="urn:ietf:params:xml:ns:diff">
<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:diff> One possible form of the result XML document after applying the patches:
</p：diff>パッチを適用した後の結果xmlドキュメントの1つの考えられる形式：
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns="urn:ietf:params:xml:ns:xxx"
xmlns:z="urn:ietf:params:xml:ns:yyy">
<note>Patched doc</note>
<elem a="foo">
<child/>
<!-- This is a new child -->
<child id="ert4773">
<z:node/>
</child>
</elem>
<elem a="bar" b="new attr"/>
</doc>
The <node> and removed <child> element prefixes within the XML diff document are different than what are the "identical" namespace declarations in the target XML document. If the target XML document had used a prefixed namespace declaration instead of the default one, the XML diff document could still have been the same. The added new qualified elements would just have inherited that prefix.
<node>およびXML DIFFドキュメント内の<Child>要素のプレフィックスを削除し、ターゲットXMLドキュメントの「同一の」名前空間宣言とは異なります。ターゲットXMLドキュメントがデフォルトの名前の代わりにプレフィックス型の名前空間宣言を使用していた場合、XML DIFFドキュメントはまだ同じである可能性があります。追加された新しい資格のある要素は、そのプレフィックスを継承しただけです。
Author's Address
著者の連絡先
Jari Urpalainen Nokia Itamerenkatu 11-13 Helsinki 00180 Finland
Jari Urpalainen Nokia Itamerenkatu 11-13 Helsinki 00180フィンランド
Phone: +358 7180 37686
EMail: jari.urpalainen@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。