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）XMLパス言語（XPath）セレクタを活用パッチOperations Frameworkの
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パッチのフレームワークについて説明します。これらセレクタ値と更新された新たなデータ内容は、本書に記載のパッチ操作の基礎を構成します。それらに加えて、基本的に<置き換え>、<追加>、および<削除>パッチのセットは、既存の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の特定の部分を特定するために使用されます。これらセレクタ値と更新された新たなデータ内容は、本書に記載のパッチ操作の基礎を構成します。それらに加えて、基本的に<置き換え>、<追加>、および<削除>パッチのセットは、既存のターゲットXML文書を更新するために適用することができますディレクティブ。これらのパッチ操作で、データ指向のXML文書[W3C.REC-XMLSCHEMAは-2から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.
一の具体例として、部分PIDF XML文書形式[RFC5262]は、この中に記載パッチ操作要素と組み合わせ既存のプレゼンス情報データフォーマット（PIDF）文書フォーマットで構成され、セッション開始プロトコル（SIP）の[RFC3903]基づくプレゼンスシステム資料。一般的に、パッチの操作は、例えば、SIPイベント・フレームワーク[RFC3265]内で、XML文書を交換する任意の用途に使用することができます。さらに別の例は、XCAP [RFC4825]リソースへの変更の部分的な更新を送信するため、このフレームワークを使用XCAP-diffの[SIMPLE-XCAP]は、です。
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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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文書にXML diffのドキュメントで定義された一つ以上のパッチ操作を適用した後の結果の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要素内で行われる変更を指定するの名前が埋め込まれています。これらの素子（パッチ操作が）W3Cスキーマ言語のスキーマ・タイプによって定義されている[W3C.REC-XMLSCHEMA-1から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-C14N-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.
これらの要素のスキーマタイプを参照する仕様がUTF-8 [RFC3629]、例えば、適切なMIMEタイプ[RFC3023]と文字セットで完全な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の差分文書内の追加の名前空間宣言を回避することができます。
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.
これらのタイプを使用しているアプリケーションは、<置き換える>、<追加>を定義し、このスキーマ内の対応するタイプ定義に基づいて要素<削除>をすることが予想されます。加えて、アプリケーションは、これらのタイプ定義のサブセットのみを参照することができます。将来の拡張は、ドキュメント指向のモデル[W3C.REC-XMLSCHEMA-2から20041028]を用いて、例えば、<移動>操作を他の操作を導入することができると<移動>と組み合わせたテキストノードパッチングアルゴリズムは、間違いなくより小さなXMLの差分文書を生成します。
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の差分文書は、一つ以上の<add>、<置き換え>、および<削除>要素を含むパッチ操作要素のコレクションを、含まれています。これらのパッチ操作は、ドキュメント順に順次適用されます。最初のパッチは、ターゲット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-名-20060816]のいずれかとすることができます。 「*」の文字は、文脈ノードの子要素すべてを選択します。右ノードテストの後、ロケーションステップは任意の順序で一つ以上の述語を含むことができます。属性値の比較が最も典型的な述語の一つです。現在のコンテキストノードまたは子要素の文字列値は、代替的に、ツリー内の要素を識別するために使用されてもよいです。文字「」、現在のコンテキストノードの選択を示し、 『自己::ノード（）』の省略形です。最後に、位置の制約は次のように「[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 XML」[W3C.WD-XML文書のコンテンツモデルを記述するスキーマは、次に型ID [W3C.REC-XMLSCHEMA-2から20041028]または非検証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の差分文書には、ターゲットドキュメントで使用される名前空間の異なるプレフィックスを持っているかもしれません。差分文書を解析エージェントは、それぞれの結果の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の差分文書は、差分文書で使用されるすべての名前空間の宣言を含まなければなりません。差分文書宣言は、常に差分ドキュメント内で適用されますどのような名前空間を決定するために使用されています。
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.
要素に名前を付けるときに差分文書内のセレクタは、接頭辞を使用することができます。それは接頭辞を使用しない場合、接頭辞は、差分文書の名前空間宣言に見上げなければなりません。
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.
「『バー』 SEL =」セレクタと、例えば、差分文書のパッチ操作要素は、スコープ内の名前空間宣言「：= 『FOO』のxmlns」を有します。名前空間がターゲットドキュメントまたは何という接頭辞があるに割り当てられたプレフィックスを持っていますかどうかにかかわらず、「foo」での名前空間：このパッチを処理するエージェントは、「FOO」で資格「バー」要素のために見なければなりません。
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.
デフォルトの名前空間は、このモデルはもう少し複雑になります。差分文書は、デフォルトの名前空間宣言を持っている場合は、接頭辞のない任意の要素セレクタは、その名前空間を使用して評価しなければなりません。
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.
セレクタ「SEL = 『バー』」と：例えば、差分文書のパッチ操作要素は、スコープ内の名前空間宣言「のxmlns = 『foo』を」を有します。かどうかに関係なく「FOO」の、名前空間名前空間がターゲットドキュメントまたは何その接頭辞があるに割り当てられたプレフィックスがあります。このパッチは、その後「バー」要素のために見なければならないエージェント処理は、「foo」でで修飾しました。
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.
セレクタ「SEL = 『バー』」と、例えば、差分文書のパッチ操作要素は、唯一のスコープ内の名前空間宣言「：= 『FOO』のxmlns」を有します。 「バー」要素は、接頭辞を有していない、および範囲内のデフォルトの名前空間宣言が存在しないので、このパッチを処理するエージェントは、接頭辞および範囲内にもないデフォルトの名前空間がありません「バー」要素に対してセレクタと一致することができます。
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の中で、「バー」セレクタは常に修飾されていない<バー>要素を配置します。 XPathの2.0では、「バー」セレクタは、修飾されていない<バー>要素に一致するだけでなく、デフォルトの名前空間宣言の範囲内にある修飾<バー>要素に一致するだけでなく。対照的に、本明細書では、接頭辞なしのセレクタは、唯一の要素と一致し、それはまたは接頭辞なしの要素と一致することができるが、それは（又はなし）で修飾名前空間が完全一致の場合のみ。
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の勧告は、述語内で使用できる「名前空間-URI（）」と「ローカル名（）」ノードセット関数を指定します。関連付けられた名前空間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文書に新しい名前空間で修飾要素を追加する場合、例えば、差分文書が要素に適用される名前空間宣言を含まなければなりません。差分文書を処理するエージェントは、対象文書も同じ名前空間宣言が含まれていることを確認しなければなりません。 XPathのと同様に、このコンテキストで同じ名前空間宣言は、名前空間URIが同じでなければならないことを意味するが、接頭辞は、差分とターゲット文書に異なる場合があります。
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.
例えば、新規追加した場合、<：バー>要素は、名前空間宣言への言及「：= 『FOO』のxmlns」を有する差分文書内および対象文書は、単一のスコープ内の名前空間宣言「のxmlnsを有する：Bを<：バーB>要素は、その後パッチを適用ドキュメントに存在する：=「FOO」ように」挿入点では、名前空間の参照を変更しなければなりません。デフォルトの名前空間は、ドキュメントのいずれかまたは両方で使用されていたが、同じルールが適用され、名前空間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文書にXML diffのドキュメントから変更されていない（接頭辞、すべてを）コピーされます。デフォルトの名前空間宣言にのみ、この方法で追加することができますが、プレフィックスの名前空間宣言は、この文書（見セクション4.3.3）で後述するXPath名前空間軸のセマンティクスを追加または除去することができます。
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:
ターゲット文書が同じ名前空間のスコープ内に複数の名前空間宣言を持っている場合、これらの規則のためにかなり困難なユースケースが発見されました。ターゲットドキュメントには、同じ名前空間のために、いくつかの異なるプレフィックスを宣言する可能性があります。通常、差分文書を適用するエージェントは*ターゲットドキュメントに新しい要素を追加するため*適切なプレフィックスを選択しますが、この特殊なケースでは複数あります。これらの要件は、この特別で、実際にはまれなケースのための確定的な動作を作成します。
- 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.
- 差分文書を対象文書の評価のコンテキストノード内の同じ名前空間の宣言された接頭辞の一つである接頭辞を使用する場合は、このプレフィックスは、得られたパッチを適用し、ドキュメントで使用されなければなりません。空の評価可能なプレフィックスと、既存のスコープ内のデフォルトの名前空間宣言は、デフォルトの名前空間を選ばなければなりませんことを意味しています。言い換えれば、拡大の名前は、差分パッチを適用し、ドキュメント内の同じです。
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.
- 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).
- 最後に、上記の二つのルールがまだ適用されない場合は、最初の評価のコンテキストノードの全てのスコープ内の名前空間接頭辞は、昇順にアルファベット順に配置されています。デフォルトの名前空間宣言が存在する場合は、このリストの最初のエントリとして解釈されます。リストからプレフィックスは、それがリストに挿入された場合は、最も近いとして、ちょうど比較接頭辞の前に表示される選択されています。比較プレフィックスが最初の接頭辞の前に存在した場合、リストの最初の接頭辞は（つまり、デフォルトの名前空間がありません）を選択する必要があります。
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).
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形式のコンテンツは、名前空間接頭辞の対象文書の使用一般的に独立しています。しかし、名前空間は、対象文書で宣言されている場所を知ることは非常に有用である可能性があります。最も典型的なユースケースは、差分を生成するエージェントは、以前の（ターゲット）の両方を持っていること、しかしようになっていると、新しい（パッチの適用）可能なドキュメント、および名前空間宣言は、このように正確に知られています。ターゲット文書は正確には知られていない場合には、ローカルスコープの名前空間宣言を使用することが許可されていることにも注意してください、結果はそのパッチを適用した文書大きく、少ない人間が読めるです。
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.
<追加>要素は、ターゲット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.
新しいデータコンテンツは、<追加>要素の子ノード（単数または複数）として存在します。属性と名前空間、<追加>要素でなければなりません単一のテキスト・ノードの子ノードを追加する場合。それ以外の場合は、<追加>要素は、任意の順序で要素、テキスト、コメントまたは処理命令ノードのいずれかの混合物を含有することができます。 <追加>要素のすべての子供たちは、その後、ターゲットXML文書にコピーされます。説明名前空間マングリング手順は、それらの属性、名前空間と子孫ノードの全てを含む追加の要素に適用されます。
The <add> element type has three attributes: 'sel', 'type', and 'pos'.
「SEL」、「タイプ」、および「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」に等しい場合には、文字列「attrが」追加されている実際の属性の名前です。この新しい「attrの」属性の値は、<追加>要素のテキストノードの内容です。あまり頻繁に使用される接頭辞（すなわち、名前空間で修飾）も添加することができる属性。 「タイプ」属性の値が「名前空間::県」に等しい場合は、「県は、」パッチを適用し、文書内の名前空間宣言とのテキストノードのコンテンツに使用される実際の接頭文字列がある要素が対応するが含まれている<追加>名前空間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のセレクタであるが、それは唯一の属性と名前空間を検索します。軸「属性」省略形を持っている属性の「@」省略形を持っていない「名前空間」の軸とは異なり。ダブルコロンは、「::」の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」属性が存在する場合、<追加>要素の子供たちは、その後位置する標的要素の最後の子ノード（複数可）として追加されます。 「POS」属性の値が「プリペンド」新しいノード（単数または複数）に位置するターゲット要素の最初の子ノード（単数または複数）として添加されます。 「前」の値が、追加される新しいノード（単数または複数）、および「後」の直前の兄弟ノード（単数または複数）である必要があり、配置対象ノードのノード（複数可）兄弟即時以下。
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.
いくつかの例は、要素の属性をそれはこれらのユースケースを記述従っ<追加します>。ノードは名前空間で修飾されていないとプレフィックスは、従って、使用されず、全体のXML差分内容は、これらの実施例にのみパッチ操作要素を示していません。完全な例は、付録Aに記載されています
An example for an addition of an element:
要素の付加の例：
<add sel="doc"><foo id="ert4773">This is a new child</foo></add>
これは、新しい子</ foo>の</追加>で<fooというidは= "ert4773"> <SEL = "ドキュメント" を追加>
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.
<ドキュメント>要素は、ターゲットXML文書から発見された後は、新しい<FOO>要素は、<ドキュメント>要素の最後の子ノードとして追加されます。位置ターゲットノード<DOC>要素は、自然に、ターゲットXML文書のルート要素です。新しい<foo>の要素は、「ID」属性と子テキストノードが含まれています。
An example for an addition of an attribute:
属性を付加するための例：
<add sel="doc/foo[@id='ert4773']" type="@user">Bob</add>
<SEL = "DOC / fooの[@ ID = 'ert4773']" タイプ= "@ユーザー" を追加>ボブ</追加>
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」属性値述語を使用して位置していた<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文書は、検証XMLパーサを使用する場合「SEL」セレクタ値があった場合は「ID（ 『ert4773』）」、達成されている「ID」属性のデータ・タイプは、[「ID」W3C.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;」または「'は、」属性値内で使用することができます。しかし、これらの例に示すようにアポストロフィ（ '）文字を使用することがしばしばより適切です。代替は、アポストロフィと引用符を交換することもあります。
An example for an addition of a prefixed namespace declaration:
接頭辞の名前空間宣言を追加するための例：
<add sel="doc" type="namespace::pref">urn:ns:xxx</add>
<追加SELは= "DOC" タイプ= "名前空間::県"> URN：NS：XXX </追加>
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".
この操作は、<ドキュメント>要素に新しい名前空間宣言を追加します。この新しい名前空間ノードの接頭辞は、このように「県」と名前空間URIが「：NS：XXX URN」です。
An example for an addition of a comment node:
コメントノードを追加するための例：
<add sel="doc/foo[@id='ert4773']" pos="before"><!-- comment --></add>
<！ - コメント - > </追加> < "の前に" POS = "DOC / fooの[@ ID = 'ert4773']" SEL =を追加します>
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>
これは、新しい子</ foo>の</追加>で<fooというidは= "ert4773"> <SEL = "ドキュメント" を追加>
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.
空白のテキストノード（改行と二つの空間）と、<foo>の要素：<追加>要素は、2つの子ノードを持っています。 <ドキュメント>の既存の最後の子要素がテキストノードである場合は、その内容と空白のテキストノードの内容は、その後、一緒に組み合わせる必要があります。そうでない場合、（空白）テキスト・ノードは、ちょうど同様の要素を追加することができ、したがって、パッチを適用したXML文書の正規形を容易に決定性のままです。いくつかの兄弟ノードが単一の操作を、<追加>を挿入することができますように、「かわいい印刷」スタイルを容易に維持することができます。
Still another example about the handling of text nodes. Consider this example:
テキストノードの処理に関するさらに別の例。この例を考えてみます。
<add sel="*/foo/text()[2]" pos="after">new<bar/>elem</add>
新しい<バー/> elemは<追加/> < "の後に" POS = SEL = "[2] * / fooの/テキスト（）" を追加します>
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プロローグは、これらの宣言が含まれている場合、事前定義された内部のエンティティ以外への参照は、テキスト・ノードまたは属性内に存在することができます。 XMLの差分とターゲット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.
<置き換え>要素は、交換作業を表します。たとえば、既存の要素は新しい要素で更新されたか、属性値が新しい値に置き換えられます。これは、<置き換え>操作は常に時間に単一のノードまたはノード内容を更新します。
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.
<置き換え>要素のタイプは「SEL」属性を持っています。位置ターゲットノードが要素、コメント、または処理命令である場合、子の<は置き換える>要素は、同じ型でなければなりません。それ以外の場合は、<置き換え>要素は、テキストコンテンツを持たなければならないか、属性値やテキストノードの内容を交換するとき、それは空であるかもしれません。
An example for a replacement of an element:
エレメントの交換のための例：
<replace sel="doc/foo[@a='1']"><bar a="2"/></replace>
< "[= '1' @]のdoc / foo" というSEL =を置き換える> <バーA = "2" /> </交換してください>
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」を持つ「」属性を持つ<foo>の要素を更新します。位置する標的要素は、<バー>要素に置き換えられています。いずれかが存在していたのであれば、すべての子孫ノード、名前空間宣言、および置き換え<FOO>要素の属性は、このように削除されます。
An example for a replacement of an attribute value:
属性値の置き換えのための例：
<replace sel="doc/@a">new value</replace>
新しい値</置き換えます> <SEL = "DOC / @ A" を交換してください>
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=""/>.
これは、値「新しい価値」を持つ<ドキュメント>要素の「」属性の内容を置き換えます。要素が空である<置き換える>、「」属性は、<ドキュメントのA =「」/>のように表示されるパッチを適用したXML文書に残っている必要があります。
An example for a replacement of a namespace URI:
名前空間URIの交換のための例：
<replace sel="doc/namespace::pref">urn:new:xxx</replace>
<SEL = "DOC /名前空間::県" 置き換え> URN：新しい：XXX </交換してください>
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.
これは「：新しい：XXX壷」と「県」接頭辞名前空間ノードのURI値を置き換えます。名前空間宣言の親ノードがそうでなければ、エラーが発生し、<DOC>要素でなければなりません。
An example for a replacement of a comment node:
コメントノードの交換のための例：
<replace sel="doc/comment()[1]"><!-- This is the new content --></replace>
<SEL =置き換え "）（DOC /コメントを[1]"> <！ - これは新しいコンテンツである - > </交換してください>
This will replace a comment node. The located target node is the first comment node child of the <doc> element.
これはコメントノードに置き換えられます。設置対象ノードは、<ドキュメント>要素の最初のコメントノードの子です。
An example for a replacement of a processing instruction node:
処理命令ノードの交換のための例：
<replace sel='doc/processing-instruction("test")'><?test bar="foobar" ?></replace>
< 'DOC /処理命令（ "テスト"）' SEL =を置き換える> <？テストバー= "foobarに"？> </交換してください>
This will replace the processing instruction node "test" whose parent is the <doc> element.
これは、その親の<ドキュメント>要素である処理命令ノード「test」を置き換えます。
An example for a replacement of a text node:
テキストノードの交換のための例：
<replace sel="doc/foo/text()[1]">This is the new text content</replace>
これは、新しいテキストコンテンツ</交換>は< "[1] DOC / FOO /テキスト（）" = SELを交換>
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>の要素の最初のテキストノードの子に置き換えられます。位置制約「[1]」は、通常、要素内容として必要とされないが、稀混合型のものである[W3C.REC-XMLSCHEMA-1から20041028]いくつかのテキストノードの兄弟は、典型的には、存在する場合。
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.
テキストノードが更新され、<置き換え>されている場合は要素が空のテキストノードは常にデータの少なくとも一つの文字を持たなければならないとして、テキストノードは、このように削除する必要があります。
The <remove> element represents a removal operation of, for example, an existing element or an attribute.
<削除>要素は、例えば、既存の要素または属性の除去操作を表します。
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.
「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"/>
<= WS "[= '1' @] DOC / FOO" SEL =を除去 "後" />
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.
これは、<foo>の要素だけでなく、<foo>の要素の空白テキストノードを兄弟すぐに次のように削除されます。すぐに次の兄弟ノードが空白のテキストノードでない場合は、エラーが発生します。
An example for a removal of an attribute node:
属性ノードを除去するための例：
<remove sel="doc/@a"/>
<SELを削除= "DOC / @" />
This will remove the 'a' attribute node from the <doc> element.
これは、<ドキュメント>要素から「」属性ノードを削除します。
An example for a removal of a prefixed namespace node:
接頭辞名前空間ノードを除去するための例：
<remove sel="doc/foo/namespace::pref"/>
</ SEL = "DOC / fooの/名前空間::県" を削除>
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>の要素から「県」接頭辞名前空間ノードを削除します。当然のことながら、この接頭辞は、この名前空間ノードを除去する前の任意のノードに関連付けられてはなりません。また、この名前空間宣言の親ノードは<FOO>要素でなければなりません。
An example for a removal of a comment node:
コメントノードを除去するための例：
<remove sel="doc/comment()[1]"/>
<SEL =取り除く "）（DOC /コメント[1]" />
This will remove the first comment node child of the <doc> element.
これは、<ドキュメント>要素の最初のコメントノードの子を削除します。
An example for a removal of a processing instruction node:
処理命令ノードの除去のための例：
<remove sel='doc/processing-instruction("test")'/>
< 'DOC /処理命令（ "試験"）' SEL =を除去/>
This will remove the "test" processing instruction node child of the <doc> element.
これは、<ドキュメント>要素の「テスト」処理命令ノードの子を削除します。
An example for a removal of a text node:
テキストノードを除去するための例：
<remove sel="doc/foo/text()[1]"/>
<削除SEL = "DOC / FOO /テキスト（）[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」指令なし兄弟テキストノードを前後した処理指示ノードを削除する場合、これらの二つのテキストノードの内容は、一緒に結合されなければなりません。後者のテキスト・ノードは、このようにドキュメントから消えます。
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.
エラー文書のルート要素は<パッチ-OPS-エラー>です。この要素の内容は、特定のエラー状態です。各エラー状態は、様々な要素によって表されます。これは、エラーの性質に関するさまざまなデータを提供するために、さまざまなエラー条件が可能になります。すべてのエラー要素がテキストを含めることができます「という句」属性は、人間のユーザにレンダリングするためのものでサポートされています。オプションの「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.
<無効属性値>：「SEL」、「タイプ」の妥当性制約は、「WS」、または「POS」の属性値、すなわち、非許容コンテンツが使用されている、このエラーで示されてもよいです。また、このエラーは示すために、追加または変更した属性の内容が有効でない場合、新しい属性を追加することを意図していたとき、例えば、CDATAセクションを使用した。使用することができます
<invalid-character-set>: The patch could not be applied because the diff and the patched document use different character sets.
<無効な文字セット>：差分とパッチを適用した文書は、異なる文字セットを使用しているため、パッチを適用することができませんでした。
<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.
<無効差分フォーマット>：これは、要求の差分本体は、そのスキーマに従って整形式XML文書または有効なXML文書ではなかったことを示しています。
<invalid-entity-declaration>: An entity reference was found but corresponding declaration could not be located or resolved.
<無効エンティティ宣言>：エンティティ参照が見つかったが、対応する宣言が配置または解決できませんでした。
<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.
<不正な名前空間接頭辞>：指定された接頭辞の名前空間URIが位置するか、または解決できませんでした、例えば、[SEL]内の接頭辞を使用したが、その宣言がターゲット文書から欠落している属性。
<invalid-namespace-uri>: The namespace URI value is not valid or the target document did not have this declaration.
<不正な名前空間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.
<無効ノードタイプ>のノード・タイプ、操作が一致しなかった<交換>すなわち、例えば、「SEL」セレクタ要素を配置するが、交換可能なコンテンツは、テキスト型です。また、<置き換え>操作は、ユニークな要素を探しますが、交換可能なコンテンツは、複数のノードを持っていました。
<invalid-patch-directive>: A patch directive could not be fulfilled because the given directives were not understood.
<無効パッチディレクティブ>：指定されたディレクティブを理解していなかったので、パッチディレクティブが成就することができませんでした。
<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-xml-prolog-operation>: Patch failure related to XML prolog nodes.
<無効-XML-プロローグ操作>：XMLプロローグノードに関連するパッチの失敗。
<invalid-whitespace-directive>: A <remove> operation requires a removal of a white space node that doesn't exist in the target document.
<無効空白ディレクティブ>：<削除>操作は、ターゲットドキュメントに存在しない空白ノードの除去を必要とします。
<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.
<位置未確認ノード>：単一の固有のノード（典型的には、要素は）「SEL」属性値で見つかりませんでした。また、複数のノードの位置は、このエラーにつながる可能性があります。
<unsupported-id-function>: The nodeset function id() is not supported, and thus attributes with the ID type are not known.
<サポートされていない-ID機能>：ノードセット関数ID（）サポート、及び従ってIDタイプと属性されていないが、知られていません。
<unsupported-xml-id>: The attribute xml:id as an ID attribute in XML documents is not supported.
<サポートされていない-XML-ID>：属性xml：XML文書内のID属性として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.
追加のエラー要素は、任意の名前空間からルート<パッチOPSエラー>要素内に表示することができます。 "：IETF：のparams：XML：NS：パッチ-OPS-エラーURN" 名前空間ただし、IETFは、追加のエラー要素を指定するかもしれません。
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:
例として、以下の文書は、文書の中にホワイトスペースを持つ新しい<ノート>要素を追加しようとしましたが、親要素が見つからなかったことを示します。
<?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>
<？xml version = "1.0" エンコード= "UTF-8"？> <パッチ-OPS-エラーのxmlns：P = "壷：IETF：のparams：XML：NS：PIDF-diffを" のxmlns = "壷：IETF：のparams ：XML：NS：パッチOPSエラー「> <位置未確認ノード語句=」一意のノードID（）関数を用いて配置することができませんでした」 > <P：追加SEL = 'ID（ "ert4773"）'> <pは：注意>テキストが追加</ P：注意> </ P：追加> </位置未確認ノード> </パッチOPSエラー>
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の差分文書は、意図は、帯域幅/ストレージ要件を削減しようとすることであるように変更されているノードのみを含むべきです。しかし、変化の大規模なコレクションがあるときではなく、完全な文書の内容を交換することが望ましいです。これは実際にはどのように行われます。このドキュメントの範囲を超えています。
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.
一部のアプリケーションでは、歴史は余計な変更を持っていたものの、完全なバージョン管理履歴が示されなければならないことを要求することができます。このフレームワークは、任意の特定の動作を強制しないアプリケーションでは、適切なセマンティクスを自分で決めることができます。また、実際には、アプリケーションは差分ドキュメントのコンテンツを生成するときに、適切なアルゴリズムを選択するのは自由です。
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.
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+\]">
！！！<？xmlのバージョン= "1.0" エンコード= "UTF-8"> <DOCTYPEスキーマ[<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">
<！ENTITY attrの "\; | \ [＆ANAME; =＆QUOT; *＆QUOT; \（。）] [＆ANAME = \ '*（。）']"> <ENTITYのvalueq「\ [（＆のqname！ ; |。。\）=＆QUOT;（）*＆QUOT; \] "> <ENTITY値！ "\ [（＆のqname; |。\）= '（）*。' \] |＆valueq;"> <！ENTITY指揮 "＆のattr; |＆値; |＆POS;"> <！ENTITYステップ "（＆のqname; | \ *）（＆指揮;）*"> <！ENTITYのPIQ「処理命令\（（ ＆QUOT;＆NCNameで;＆QUOT;）\） "> <ENTITYのパイ！ "処理命令\（（ '＆NCNameで;'？）\）|＆PIQ;"> <エンティティID：！" のid \（（」 ＆NCNameで; '）\）| ID \（（＆QUOT;？＆NCNameで;＆QUOT;）\） "> <！ENTITYコム "コメント\（\）"> <！ENTITYテキスト" テキスト\（\） "> <！ENTITYたNspA "名前空間::＆NCNameで;"> <ENTITYのCノード！"（＆テキスト;（＆POS;）？）|（＆COM;（＆POS;）？）|（（＆パイ;） ？ "> <！ENTITYの子 "; |;"> <！ENTITY最後の ";（＆POS））＆Cノード＆ステップ（＆子; |＆ANAME; |＆のNspA;）">]> <XSD：スキーマのxmlns ：XSD = "http://www.w3.org/2001/XMLSchema" のelementFormDefault = "資格">
<xsd:simpleType name="xpath"> <xsd:restriction base="xsd:string"> <xsd:pattern value="(/)?((&id;)((/&step;)*(/&last;))?|(&step;/)*(&last;))"/> </xsd:restriction> </xsd:simpleType>
<XSD：単純型名= "のXPath"> <XSD：制限ベース= "XSD：文字列"> <XSD：パターン値= "（/）（（＆ID;）（（/＆ステップ;）*（/＆ ？最後の;））|（＆ステップ; /）*（＆最後の;）） "/> </のxsd：制限> </の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：単純型名= "XPathに追加"> <XSD：制限ベース= "XSD：文字列"> <XSD：パターン値= "（/）（（＆ID;）（（/＆ステップ;）*（？ ？/＆子供;））|（＆ステップ; /）*（＆子供;）） "/> </のxsd：制限> </の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 </ "の後に" 列挙値= XSD>：<XSD：単純型名= "POS"> <XSD：制限ベース= "XSD：文字列"> </ "前" 列挙値= XSD>列挙値= "プリペンド" /> </のxsd：制限> </のxsd：simpleTypeの>
<xsd:simpleType name="type"> <xsd:restriction base="xsd:string"> <xsd:pattern value="&aname;|&nspa;"/> </xsd:restriction> </xsd:simpleType>
<XSD：単純型名= "タイプ"> <XSD：制限ベース= "XSD：文字列"> <XSD：パターン値= "＆ANAME; |＆たNspA;" /> </ XSD：制限> </のxsd：simpleTypeの>
<xsd:complexType name="add">
<XSD：complexTypeの名= "追加">
<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：complexContentを混在= "真"> <XSD：制限ベース= "XSD：anyType型"> <XSD：配列> <のxsd：任意のprocessContents = "緩い" 名前空間= "##いずれか" のminOccurs = "0" のmaxOccurs = "無制限" /> </のxsd：sequence>を<のxsd：属性名= "SEL" タイプ= "のxpath-追加" を使用= "必須" /> <XSD：属性名= "POS" タイプ= "POS" /> <XSD：属性名= "タイプ" タイプ= "タイプ" /> </のxsd：制限> </の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：complexTypeの名= "置き換え"> <のxsd：complexContentを混在= "真の"> <XSD：制限ベース= "のxsd：anyType型を"> <のxsd：sequence>を<のxsd：どんなのprocessContents = "緩い" 名前空間= "＃ #any」のminOccurs = "0" のmaxOccurs = "1" /> </ XSD：配列> <XSD：属性名= "SEL" タイプ= "XPathの" 使用= "必須" /> </ XSD：制限> </ 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 </ "の後に" 列挙値= XSD>：</ "前" 列挙値= XSD> <のxsd：simpleTypeの名前= "WS"> <XSD：制限ベース= "XSD文字列">列挙値= "共に" /> </ XSD：制限> </のxsd：simpleTypeの>
<xsd:complexType name="remove"> <xsd:attribute name="sel" type="xpath" use="required"/> <xsd:attribute name="ws" type="ws"/> </xsd:complexType>
<XSD：complexTypeの名前= "削除"> <XSD：属性名= "SEL" タイプ= "XPathの" 使用= "必要" /> <XSD：属性名= "WS" タイプ= "WS" /> </ XSD ：complexTypeの>
</xsd:schema>
</ XSD：スキーマ>
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">
<？xml version = "1.0" エンコード= "UTF-8"？> <XSD：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：パッチ-OPS-エラー" のxmlns：TNS = "壷：IETF：のparams ：XML：NS：パッチ-OPS-エラー」のxmlns：XSD = "http://www.w3.org/2001/XMLSchema" のelementFormDefault = "資格" attributeFormDefault = "" 修飾されていません>
<!-- 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"/>
<！ - このインポートは、XML言語の属性xmlにもたらします：LANG - > <XSD：インポート名前空間= "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>
<！ - パッチ-OPSのエラーを知らせるためのルート文書要素 - > <XSD：要素名= "パッチ-OPS-エラー"> <のxsd：complexTypeの> <のxsd：sequence>を<のxsd：任意の名前空間= "##任意の"のprocessContents =" 緩い」のminOccurs = "0" のmaxOccurs = "無制限" /> </ XSD：配列> <XSD：anyAttributeはのprocessContents = "緩い" /> </のxsd：complexTypeの> </ XSD：要素>
<!-- 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"/>
< - パッチ-OPSエラー要素：！ルートdocumnet要素として使用することを意図していない - > <XSD：要素名= "無効な属性値" タイプ= "TNS：パッチエラー" /> <のxsd：要素名前= "無効な文字セット" タイプ= "TNS：パッチ誤りシンプル" /> <XSD：要素名= "無効-diffのフォーマット" タイプ= "TNS：パッチ誤りシンプル" /> <XSD ：要素名=「無効なエンティティ宣言」タイプ=「TNS：パッチエラー」/> <XSD：要素名=「無効な名前空間接頭辞」タイプ=「TNS：パッチエラー」/> <のxsd：要素名前= "無効な名前空間-URI" タイプ= "TNS：パッチエラー" /> <XSD：要素名= "無効なノード・タイプ" TYPE = "TNS：パッチエラー" /> <XSD：要素名= 「無効なパッチ・ディレクティブ」タイプ=「TNS：パッチエラー」/> <XSD：要素名=「無効なルート要素操作」タイプ=「TNS：パッチエラー」/> <XSD：要素名= "無効なXML-プロローグ操作" タイプ= "TNS：パッチエラー" /> <XSD：要素名= "無効の空白ディレクティブ" タイプ= "TNS：パッチエラー" /> <XSD：要素名= "位置未確認ノード" タイプ= "TNS：パッチエラー" /> <XSD：要素名= "サポートされていない-ID機能" タイプ= "TNS：パッチエラー" />
<xsd:element name="unsupported-xml-id" type="tns:patch-error"/>
<XSD：要素名= "サポートされていない-XML-ID" タイプ= "TNS：パッチエラー" />
<!-- 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>
<！ - シンプルなパッチ-OPSのエラータイプ - > <XSD：complexTypeの名前= "パッチ誤りシンプル"> <XSD：属性名= "フレーズ" タイプ= "のxsd：文字列" /> <XSD：属性参照= "XML：LANG" /> <XSD：anyAttributeはのprocessContents = "緩い" /> </の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：complexTypeの名= "パッチ・エラー"> <のxsd：sequence>を<のxsd：任意の名前空間= "##あらゆる" のprocessContents = "緩いです" /> </ xsd：sequence>を<XSD：属性名= "フレーズ" タイプ= "のxsd：文字列" /> <XSD：属性REF = "XML：LANG" /> <XSD：anyAttributeはのprocessContents = "緩い" /> </のxsd： complexTypeの>
</xsd:schema>
</ XSD：スキーマ>
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 [RFC4288] RFC 4288の手順に従って新しいMIMEタイプ「アプリケーション/パッチOPSエラー+ XML」を登録し、RFC 3023のガイドライン[RFC3023]。
o registered two XML Schemas according to the procedures of RFC 3688 [RFC3688].
O [RFC3688] RFC 3688の手順に従って、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
URI：この名前空間のURIはURNです：IETF：のparams：XML：NS：パッチ-OPS-エラー
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jari Urpalainen (jari.urpalainen@nokia.com).
登録者連絡先：IETF、SIMPLEワーキンググループ、（simple@ietf.org）、ヤリ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
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-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset =イソパッチ・オプスエラー文書の8859-1" /> <タイトル>パッチオプスエラー名前空間</ TITLE> </ HEAD> <BODY> <H1>名前空間</ H1> <H2> URN：IETF：のparams：XML： NS：パッチ-OPS-エラー</ H2> <P> <a href="http://www.rfc-editor.org/rfc/rfc5261.txt"> RFC5261 </a>を参照してください。</ P> <。 / body> </ html>このEND
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: patch-ops-error+xml
MIMEサブタイプ名：パッチ-OPS-エラー+ xmlの
Mandatory parameters: none
必須パラメータ：なし
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [RFC3023].
オプションのパラメータ：RFC 3023で指定され、application / xmlのcharsetパラメータと同じです[RFC3023]。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
符号化の考慮事項：RFC 3023で指定されたアプリケーション/ XMLの考察をコードするものと同じ[RFC3023]。
Security considerations: See Section 10 of RFC 3023 [RFC3023].
セキュリティの考慮事項：RFC 3023 [RFC3023]のセクション10を参照してください。
Interoperability considerations: none.
相互運用性に関する注意事項：なし。
Published specification: RFC 5261
公開された仕様：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にパッチオプス・エラーの輸送をサポートするために使用されています。
Additional Information:
追加情報：
Magic Number: None
マジックナンバー：なし
File Extension: .xer
ファイル拡張子：.xer
Macintosh file type code: "TEXT"
Macintoshのファイルタイプコード：「TEXT」
Personal and email address for further information: Jari Urpalainen, jari.urpalainen@nokia.com
詳しくは、個人やメールアドレス：ヤリUrpalainen、jari.urpalainen@nokia.com
Intended usage: COMMON
意図している用法：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
URI：URN：IETF：のparams：XML：スキーマ：パッチ-OPS
Registrant Contact: IETF, SIMPLE working group, <simple@ietf.org> Jari Urpalainen, <jari.urpalainen@nokia.com>
登録者連絡先：IETF、SIMPLEワーキンググループ、<simple@ietf.org>ヤリ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
URI：URN：IETF：のparams：XML：スキーマ：パッチ-OPS-エラー
Registrant Contact: IETF, SIMPLE working group, <simple@ietf.org> Jari Urpalainen, <jari.urpalainen@nokia.com>
登録者連絡先：IETF、SIMPLEワーキンググループ、<simple@ietf.org>ヤリ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インジェクション攻撃に対して脆弱である可能性があります。インジェクション攻撃は、このフレームワークの典型的な使用の場合とは逆に、リソースへのアクセスは、ユーザのための唯一のいくつかの特定の部分に制限されている共有可能な資源、最も可能性があります。例えば、これらの制限のスキーマでデフの形式を検証することによって、行うことができ、入力が消毒されなければならないものを攻撃から守るために。
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の手配、コメントや編集支援を含む彼女の努力のためのリサDusseaultに感謝したいと思います。著者はまた、彼らの貴重なコメントのためにエヴァLeppanen、ミッコLonnfors、アキニエミ、ジョナサン・ローゼンバーグ、ミゲルA.ガルシア、アナトエンジェル、ステファンBortzmeyer、デイブ・クロッカー、ジョエル・ハルパーン、ジェフリーHutzelman、デビッド・ウォード、そしてクリス・ニューマンに感謝したいと彼の入力やサポートのためのテッドハーディー。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、パオリ、J.、ブレイ、T.、Yergeau、F.、及びC. Sperberg-マックイーン、 "拡張マークアップ言語（XML）1.0（第4版）"、 World Wide Web Consortium（W3C）の勧告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.クラーク、 "XMLパス言語（XPath）バージョン1.0"、World Wide Web Consortium（W3C）の勧告REC-のxpath-19991116、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-名-20060816]オランダ、D.、ブレイ、T.、素人、A.、およびR.トビン、 "XML 1.0での名前空間（第二版）"、ワールドワイドウェブコンソーシアム勧告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]ブナ、D.、トンプソン、H.、マロニー、M.、およびN.メンデルゾーン、 "XMLスキーマパート1：構造第二版"、ワールドワイドウェブコンソーシアム勧告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]ボイヤー、J.、 "標準的なXMLバージョン1.0"、World Wide Web Consortium（W3C）の勧告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]マルホトラ、A.、およびP.ビロン、 "XMLスキーマパート2：データ型第二版"、World Wide Web Consortium（W3C）の勧告REC-XMLSCHEMA-2から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-20041109] Veillard、D.、ウォルシュ、N.、およびJ.マーシュ、 "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]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、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]解放され、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]ベルグルンド、A.、フェルナンデス、M.、チェン、D.、ボーグ、S.、Robie、J.、ケイ、M.、およびJ.シメオン、「XMLパス言語（XPath ）2.0" 、World Wide Web Consortium（W3C）の勧告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]ローゼンバーグ、J.、 "拡張マークアップ言語（XML）設定アクセスプロトコル（XCAP）"、RFC 4825、2007年5月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、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.ローゼンバーグ、進歩、2008年5月で、作業「XMLコンフィギュレーションアクセスプロトコル（XCAP）リソースの変更を示すための拡張マークアップ言語（XML）ドキュメント・フォーマット」。
[RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903]ニエミ、A.編、 "セッション開始プロトコル・イベント状態の出版のための（SIP）拡張"、RFC 3903、2004年10月。
Appendix A. Informative Examples
付録A.参考例
All following examples assume an imaginary XML diff document including these patch operation elements.
すべての以下の例は、これらのパッチ操作要素を含む仮想XML diffのドキュメントを前提としています。
A.1. Adding an Element
A.1。要素の追加
An example target XML document:
例えば、対象のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc> <note>This is a sample document</note> </doc>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメント> <ノート>これはサンプル文書</ノート> </ DOC>
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <add sel="doc"><foo id="ert4773">This is a new child</foo></add> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分>の<add SEL = "DOC"> <= "ert4773" fooというid>は、これが新しい子</ foo>の<追加/> <です/デフ>
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメント> <注>これはサンプル文書</ノート> <= "ert4773" fooというid>は、これが新しい子</ foo>の<です/ドキュメント>
A.2. Adding an Attribute
A.2。属性の追加
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメント> <注>これはサンプル文書</ノート> <= "ert4773" fooというid>は、これが新しい子</ foo>の<です/ドキュメント>
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <add sel="doc/foo[@id='ert4773']" type="@user">Bob</add> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分> <追加SEL = "DOC / fooの[@ ID = 'ert4773']" タイプ= "@ユーザーが">ボブは<追加/> < /デフ>
A result XML document:
結果の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>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメント> <注>これはサンプル文書</ノート> <FOOのID = "ert4773" ユーザー= "ボブ">これは新しい子です</ foo>の</ DOC>
A.3. Adding a Prefixed Namespace Declaration
A.3。同一キーの名前空間宣言を追加
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメント> <注>これはサンプル文書</ノート> <= "ert4773" fooというid>は、これが新しい子</ foo>の<です/ドキュメント>
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <add sel="doc" type="namespace::pref">urn:ns:xxx</add> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分> <SELを追加= "DOC" タイプ= "名前空間::県"> URN：NS：XXX </追加> </差分>
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメントののxmlns：県= "壷：NS：XXX">を<注>これはサンプル文書</ノート> <FOOのID = "ert4773" >これは、新しい子</ foo>の</ docにあります>
A.4. Adding a Comment Node with the 'pos' Attribute
A.4。 「POS」属性とコメントノードの追加
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメント> <注>これはサンプル文書</ノート> <= "ert4773" fooというid>は、これが新しい子</ foo>の<です/ドキュメント>
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <add sel="doc/foo[@id='ert4773']" pos="before"><!-- comment --></add> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分> << "の前に" POS = "[ID = 'ert4773' @]のdoc / foo" というSEL =を追加> - ！コメント - > </追加> </差分>
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>
<？xml version = "1.0" エンコードは= "UTF-8"？> <ドキュメント>は<ノート>これはサンプル文書</ノート>である<！ - コメント - > <FOOのID = "ert4773">これは、新しい子</ foo>の</ DOC>
A.5. Adding Multiple Nodes
A.5。複数のノードの追加
An example target XML document:
例えば、対象のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc> <note>This is a sample document</note> </doc>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメント> <ノート>これはサンプル文書</ノート> </ DOC>
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <add sel="doc"> <foo id="ert4773">This is a new child</foo></add> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分>の<add SEL = "DOC"> <= "ert4773" fooというid>は、これが新しい子</ foo>の<追加/> <です/デフ>
A result XML document:
結果のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc> <note>This is a sample document</note>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメント> <ノート>これはサンプル文書です。</ノート>
<foo id="ert4773">This is a new child</foo></doc>
<FOO ID = "ert4773">これは新しい子</ foo>の</ docに>あります
A.6. Replacing an Element
A.6。エレメント交換
An example target XML document:
例えば、対象のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc> <foo a="1">This is a sample document</foo> </doc>
<？xml version = "1.0" エンコード= "UTF-8"？> <DOC> <FOO A = "1">これはサンプル文書</ FOO> </ DOC>
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <replace sel="doc/foo[@a='1']"><bar a="2"/></replace> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分> <置き換えSEL = "DOC / fooの[@ = '1']"> <バーA = "2" /> </置き換え> </差分>
A result XML document:
結果のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc> <bar a="2"/> </doc>
<？xmlのバージョン= "1.0" エンコード= "UTF-8"？> <DOC> <バー= "2" /> </ DOC>
A.7. Replacing an Attribute Value
A.7。属性値を交換します
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメンテーションA = "テスト"> <FOOのA = "1">これは、サンプル文書</ FOO> </ DOC>であります
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <replace sel="doc/@a">new value</replace> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分> <置き換えSEL = "DOC / @">新しい値</置き換え> </差分>
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメンテーションA = "新しい値"> <FOOのA = "1">これは、サンプル文書</ FOO> </ DOC>であります
A.8. Replacing a Namespace Declaration URI
A.8。名前空間宣言URIを交換します
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメンテーションのxmlns：県= "URN：試験"> <FOO Aが= "1">これは、サンプル文書が</ FOO> </ DOC>であります
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <replace sel="doc/namespace::pref">urn:new:xxx</replace> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分> URN <SEL = "DOC /名前空間::県" を置き換える>：新しい：XXX </置き換え> </差分>
A result XML document:
結果のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc xmlns:pref="urn:new:xxx"> <foo a="1">This is a sample document</foo> </doc>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメントののxmlns：県= "壷：新しい：XXX"> <FOO aは= "1">これはサンプル文書</ foo>の</ですドキュメント>
A.9. Replacing a Comment Node
A.9。コメントノードの交換
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>
<？xmlのバージョン= "1.0" エンコード= "UTF-8"> <DOCののxmlns：県= "壷：テスト"> <FOOのA = "1">これはサンプル文書</ foo>の<です - ！コメント - > </ DOC>
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <replace sel="doc/comment()[1]"><!-- This is the new content --></replace> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分> <SEL =置き換える "）のdoc /コメント（[1]"> <！ - これは新しいコンテンツである - > </置き換え> </差分>
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>
<？xmlのバージョン= "1.0" エンコード= "UTF-8"> <DOCののxmlns：県= "壷：テスト"> <FOOのA = "1">これはサンプル文書</ foo>の<です - ！これは、新しいコンテンツである - > </ DOC>
A.10. Replacing a Processing Instruction Node
A.10。処理命令ノードの交換
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>
<？xmlのバージョン= "1.0" エンコード= "UTF-8"？> <DOC> <FOO A = "1">これは、サンプル文書</ FOO>である<？試験FOO = "バー"？> </ DOC >
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <replace sel='doc/processing-instruction("test")' ><?test bar="foobar"?></replace> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分> <交換SEL = 'DOC /処理命令（ "試験"）'> <？試験バー= "foobarに"？> </交換> </差分>
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>
<？xmlのバージョン= "1.0" エンコード= "UTF-8"？> <DOC> <FOO A = "1">これは、サンプル文書</ FOO>である<？試験バー= "foobarに"？> </ DOC >
A.11. Replacing a Text Node
A.11。テキスト・ノードの交換
An example target XML document:
例えば、対象のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc> <foo a="1">This is a sample document</foo> </doc>
<？xml version = "1.0" エンコード= "UTF-8"？> <DOC> <FOO A = "1">これはサンプル文書</ FOO> </ DOC>
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <replace sel="doc/foo/text()[1]" >This is the new text content</replace></diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分>これは新しいテキストコンテンツである< "[1]）（DOC / FOO /テキスト" SEL =を交換> </交換> </差分>
A result XML document:
結果のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc> <foo a="1">This is the new text content</foo> </doc>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメント> <FOO A = "1">これは新しいテキストコンテンツ</ foo>の</ DOC>
A.12. Removing an Element
A.12。要素を削除します
An example target XML document:
例えば、対象のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc> <foo a="1">This is a sample document</foo> </doc>
<？xml version = "1.0" エンコード= "UTF-8"？> <DOC> <FOO A = "1">これはサンプル文書</ FOO> </ DOC>
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <remove sel="doc/foo[@a='1']" ws="after"/> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分> <SEL =取り除く "DOC / FOOを[= @ '1']" WS = / "の後に"> </差分>
A result XML document:
結果のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc> </doc>
<？xml version = "1.0" エンコード= "UTF-8"？> <DOC> </ DOC>
A.13. Removing an Attribute
A.13。属性を削除
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <DOC A = "FOO"> <FOO Aが= "1">これは、サンプル文書が</ FOO> </ DOC>であります
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <remove sel="doc/@a"/> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分> <削除SEL = "DOC / @" /> </差分>
A result XML document:
結果のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc> <foo a="1">This is a sample document</foo> </doc>
<？xml version = "1.0" エンコード= "UTF-8"？> <DOC> <FOO A = "1">これはサンプル文書</ FOO> </ DOC>
A.14. Removing a Prefixed Namespace Declaration
A.14。同一キーの名前空間宣言を削除します
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメント> <FOO A = "1" のxmlns：県= "壷：テスト">！これはサンプル文書</ foo>の<です - コメント - > </ DOC>
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <remove sel="doc/foo/namespace::pref"/> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分> <削除SEL = "DOC / fooの/名前空間::県" /> </差分>
A result XML document:
結果のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc> <foo a="1">This is a sample document</foo> <!-- comment --> </doc>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメント> <FOOのA = "1">これはサンプル文書</ foo>のある<！ - コメント - > </ DOC>
A.15. Removing a Comment Node
A.15。コメントノードの削除
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメント> <FOOのA = "1">これはサンプル文書</ foo>のある<！ - コメント - > </ DOC>
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <remove sel="doc/comment()[1]" ws="after"/> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分> <削除SEL = "DOC /コメント（）[1]" "後" のWS = /> </差分>
A result XML document:
結果のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc> <foo a="1">This is a sample document</foo> </doc>
<？xml version = "1.0" エンコード= "UTF-8"？> <DOC> <FOO A = "1">これはサンプル文書</ FOO> </ DOC>
A.16. Removing a Processing Instruction Node
A.16。処理命令ノードを削除します
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <DOC> <FOO A = "1">これはサンプル文書</ FOO> <？テスト？> </ DOC>
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <remove sel='doc/processing-instruction("test")'/> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分> <SEL =取り除く 'DOC /処理命令（ "試験"）を' /> </差分>
A result XML document:
結果のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc> <foo a="1">This is a sample document</foo> </doc>
<？xml version = "1.0" エンコード= "UTF-8"？> <DOC> <FOO A = "1">これはサンプル文書</ FOO> </ DOC>
A.17. Removing a Text Node
A.17。テキスト・ノードを削除します
An example target XML document:
例えば、対象のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc> <foo a="1">This is a sample document</foo> </doc>
<？xml version = "1.0" エンコード= "UTF-8"？> <DOC> <FOO A = "1">これはサンプル文書</ FOO> </ DOC>
An XML diff document:
XMLの差分文書：
<?xml version="1.0" encoding="UTF-8"?> <diff> <remove sel="doc/foo/text()[1]"/> </diff>
<？xml version = "1.0" エンコード= "UTF-8"？> <差分> <SEL =取り除く "DOC / FOO /テキスト（）[1]" /> </差分>
A result XML document:
結果のXML文書：
<?xml version="1.0" encoding="UTF-8"?> <doc> <foo a="1"/> </doc>
<？xml version = "1.0" エンコード= "UTF-8"？> <DOC> <FOO A = "1" /> </ DOC>
A.18. Several Patches With Namespace Mangling
A.18。ネームマングリングにはいくつかのパッチ
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメンテーションのxmlns = "URN：IETF：paramsは：XML：NS：XXX" のxmlns：Z = "URN：IETF：paramsは：XML：NS：YYY "> <注意>これはサンプル文書</ノート> <elemはAを=" foo "という> <子供/> </ elemは> <elemはA =" バー "> <Z：子供/> </ elemは> </ドキュメント>
An imaginary XML diff document where prefix "p" corresponds the targetNamespace of this imaginary schema:
接頭辞「p」は、この架空のスキーマのtargetNamespaceとを対応する仮想XML diffのドキュメント：
<?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">
<？xml version = "1.0" エンコード= "UTF-8"？> <P：差分のxmlns = "URN：IETF：paramsは：XML：NS：XXX" のxmlns：Y = "URN：IETF：paramsは：XML：NS ：YYY」のxmlns：P = "壷：IETF：のparams：XML：NS：差分">
<p:add sel="doc/elem[@a='foo']"> <!-- This is a new child --> <child id="ert4773"> <y:node/> </child> </p:add>
<P： "[= 'foo' で@]のdoc / elemは" SEL =を追加します> <！ - これは新しい子である - > <子ID = "ert4773"> <Y：ノード/> </子供> </ P：追加>
<p:replace sel="doc/note/text()">Patched doc</p:replace>
<P：交換するSEL = "DOC /ノート/テキスト（）">パッチが適用DOC </ P：交換してください>
<p:remove sel="*/elem[@a='bar']/y:child" ws="both"/>
<P：SEL =削除 "* / elemはを[= 'バー' @] / Y：子" WS = "両方" />
<p:add sel="*/elem[@a='bar']" type="@b">new attr</p:add>
新しいATTR：<pがタイプ= "@ bの" "[= 'bar' に@] * / elemは" SEL =を追加> </ P：追加します>
</p:diff>
</ P：デフ>
One possible form of the result XML document after applying the patches:
パッチを適用した後の結果の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>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>
<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメンテーションのxmlns = "URN：IETF：paramsは：XML：NS：XXX" のxmlns：Z = "URN：IETF：paramsは：XML：NS：YYY "> <ノート>パッチが適用DOC </ノート> <elemはA =" foo "という！> <子供/> < - これは新しい子 - > <子ID =" ert4773" > <Z：ノード/> < /子> </ elemは> <elemはAを= "バー" B = "新しいの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.
XMLの差分文書内の<ノード>と削除<子>要素のプレフィックスは、ターゲットXML文書内の「同一」の名前空間宣言されているものとは異なっています。ターゲットXML文書がデフォルトの代わりに接頭辞名前空間宣言を使用していた場合は、XMLの差分文書はまだ同じだったかもしれません。追加された新しい資格要素がちょうどその接頭辞を継承しているだろう。
Author's Address
著者のアドレス
Jari Urpalainen Nokia Itamerenkatu 11-13 Helsinki 00180 Finland
ヤリUrpalainenノキアItamerenkatu 11-13 00180ヘルシンキフィンランド
Phone: +358 7180 37686 EMail: jari.urpalainen@nokia.com
電話：+358 7180 37686電子メール：jari.urpalainen@nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。