RFC5261 日本語訳
5261 An Extensible Markup Language (XML) Patch Operations FrameworkUtilizing XML Path Language (XPath) Selectors. J. Urpalainen. September 2008. (Format: TXT=78036 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Urpalainen Request for Comments: 5261 Nokia Category: Standards Track September 2008
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
An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors
Status of This Memo
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.
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.
Abstract
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.
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.
Table of Contents
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
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
Urpalainen Standards Track [Page 1] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 1] RFC 5261 Patch Operations September 2008
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
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
Urpalainen Standards Track [Page 2] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 2] RFC 5261 Patch Operations September 2008
1. Introduction
1. Introduction
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).
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).
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.
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.
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.
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.
2. Conventions
2. Conventions
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.
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.
The following terms are used in this document:
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.
Target XML document: A target XML document that is going to be updated with a set of patches.
Urpalainen Standards Track [Page 3] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 3] RFC 5261 Patch Operations September 2008
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 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.
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.
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.
Patch operation: A single change, i.e., a patch that is being
applied to update a target XML document.
Patch operation: A single change, i.e., a patch that is being applied to update a target XML document.
Patch operation element: An XML element that represents a single
patch operation.
Patch operation element: An XML element that represents a single patch operation.
Type definition for an element: A World Wide Web Consortium (W3C)
Schema type definition for an element that describes a patch
operation content.
Type definition for an element: A World Wide Web Consortium (W3C) Schema type definition for an element that describes a patch operation content.
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.
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.
Positional constraint: A number enclosed with square brackets. It
can be used as a location step predicate.
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.
Located target node: A node that was found from the target XML document with the aid of an XPath selector value.
White space text node: A text node that contains only white space.
White space text node: A text node that contains only white space.
3. Basic Features and Requirements
3. Basic Features and Requirements
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.
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.
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
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
Urpalainen Standards Track [Page 4] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 4] RFC 5261 Patch Operations September 2008
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].
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].
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.
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.
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.
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.
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.
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.
The instance document elements based on these schema type definitions MUST be well formed and SHOULD be valid.
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.
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.
4. Patch Operations
4. Patch Operations
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
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
Urpalainen Standards Track [Page 5] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 5] RFC 5261 Patch Operations September 2008
independent XML document against which the next patch will be applied. This procedure repeats until all patches have successfully been processed.
independent XML document against which the next patch will be applied. This procedure repeats until all patches have successfully been processed.
4.1. Locating the Target of a Patch
4.1. Locating the Target of a Patch
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.
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.
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.
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.
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.
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.
4.2. Namespace Mangling
4.2. Namespace Mangling
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.
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.
Urpalainen Standards Track [Page 6] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 6] RFC 5261 Patch Operations September 2008
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.
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.
4.2.1. Namespaces Used in Selectors
4.2.1. Namespaces Used in Selectors
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.
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.
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.
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.
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.
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.
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.
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.
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.
4.2.2. Departures from XPath Requirements
4.2.2. Departures from XPath Requirements
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
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
Urpalainen Standards Track [Page 7] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 7] RFC 5261 Patch Operations September 2008
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.
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.
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.
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.
4.2.3. Namespaces and Added/Changed Content
4.2.3. Namespaces and Added/Changed Content
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.
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.
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.
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.
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).
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).
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
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
Urpalainen Standards Track [Page 8] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 8] RFC 5261 Patch Operations September 2008
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:
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.
- 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.
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.
- Secondly, the prefix (also empty) of the evaluation context node MUST be chosen if the namespace URIs are equal.
- 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).
- 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).
例えば、目標ドキュメントの範囲の接頭語のリストが「x」、「y」であり、デフドキュメントの比較された接頭語が"xx"であるなら、「x」接頭語を選ばなければなりません。 “a"接頭語が評価されたなら、「x」接頭語、初記入を選ばなければなりません。 また、範囲でのデフォルト名前空間宣言があれば、evaluable “a"接頭語はデフォルト宣言を選択するでしょうに。 「非-前に置」かれた属性がデフォルト名前空間宣言を引き継がないことに注意してください。 適切な属性を加えるとき、デフォルト名前空間宣言がそして、接頭語のどんなこの合っているリストにもありません(セクション4.3.2を見てください)。
Urpalainen Standards Track [Page 9] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[9ページ]RFC5261は、操作9月が2008であるとパッチします。
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.
以下に注意してください。 実際には、通常、デフドキュメントを構成しているエージェントが名前空間宣言のために自由に適切な接頭語を選択できて、それは、目標ドキュメントの実際の接頭語を知っているか、または重なっている宣言がない場合、心配する必要はありません。 言い換えれば、デフ形式内容は名前空間接頭語の目標ドキュメント用法から通常独立しています。 しかしながら、名前空間が目標ドキュメントでどこで宣言されるかを知るのは非常に役に立つかもしれません。 もっとも、典型的な使用がケースに入れる大部分はそのようなものです、そして、デフを生成するエージェントは前の(目標)と利用可能な新しい(パッチされる)ドキュメントの両方を持っています、そして、名前空間宣言はまさにこのようにして知られています。 また、目標ドキュメントがまさに知られていなくて、それがそれの結果が、より大きくて、人間それほど読み込み可能でない局所的に見られた名前空間宣言を使用できる場合におけるそれがドキュメントにパッチしたことに注意してください。
4.3. <add> Element
4.3. <は>要素を加えます。
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'.
<は、>要素型には3つの属性があると言い足します: 'sel'、'タイプ'、および'pos'。
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
属性と名前空間を加えるときだけ、任意の'タイプ'属性の値は使用されます。 そして、見つけられた目標ノードは新しい属性と名前空間宣言が挿入される要素であるに違いありません。 この'タイプ'属性の値が"@attr"と等しいときに、ストリング"attr"は加えられる実際の属性の名前です。 この新しい'attr'属性の値は<のテキストノード内容が>要素を加えるということです。 また、より少ない(すなわち、名前空間は資格を得ました)頻繁に使用された前に置かれた属性を加えることができます。 'タイプ'属性同輩の値である、「名前空間:、:、」"pref"、"pref"は実際です。
Urpalainen Standards Track [Page 10] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[10ページ]RFC5261は、操作9月が2008であるとパッチします。
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.
パッチしているドキュメントにおける名前空間宣言に使用されるべき接頭語ストリングと<のテキストノード内容は、>要素が対応する名前空間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'属性の値が"prepend"であるときに、新しいノードは見つけられた目標要素の最初の子供ノードとして加えられます。 即座の前の兄弟ノードであり、“before"の値、(s)がそうしなければならない付記された新しいノードをもって“after"(見つけられた目標ノードの即座の次の兄弟ノード)で
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デフ内容はこれらの例(パッチ操作要素だけ)に示されません。 完全な例はAppendix Aで出されます。
4.3.1. Adding an Element
4.3.1. 要素を加えます。
An example for an addition of an element:
要素の追加のための例:
<add sel="doc"><foo id="ert4773">This is a new child</foo></add>
<がselに=を加える、「doc、「><fooイド=、「ert4773、「>Thisによる新しい子供</fooな></が>を加えるということです」。
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ドキュメントから<doc>要素をいったん見つけると、<doc>要素の最後の子供ノードとして新しい<foo>要素を追加します。 見つけられた目標ノード: <doc>要素は自然にそうです。目標XMLドキュメントの根の要素。 新しい<foo>要素は'イド'属性と子供テキストノードを含んでいます。
4.3.2. Adding an Attribute
4.3.2. 属性を加えます。
An example for an addition of an attribute:
属性の追加のための例:
<add sel="doc/foo[@id='ert4773']" type="@user">Bob</add>
「<は、= 「doc/foo[@idは'ert4773'と等しい]」タイプが」 @user「>ボブ</は>を加えること」と等しいとselに言い足します。
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".
この操作は'イド'属性値述部を使用することによって見つけられた<foo>要素に新しい'ユーザ'属性を追加します。 この新しい'ユーザ'属性の値は「ボブ」です。
Urpalainen Standards Track [Page 11] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[11ページ]RFC5261は、操作9月が2008であるとパッチします。
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'セレクタ価値が'イド("ert4773")'であり、'イド'属性に関するデータ型が「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'セレクタとして、値は引用符、逃げられたフォームを含むかもしれません: 「」 """かapos」 属性値の中で使用できます。 しかしながら、アポストロフィを使用するのがしばしばより適切である、('、)、これらの例に示されるキャラクタ、' 代替手段はまた、アポストロフィと引用符を交換することです。
4.3.3. Adding a Prefixed Namespace Declaration
4.3.3. 前に置かれた名前空間宣言を加えます。
An example for an addition of a prefixed namespace declaration:
前に置かれた名前空間宣言の追加のための例:
<add sel="doc" type="namespace::pref">urn:ns:xxx</add>
<がselに="doc"タイプ=を加える、「名前空間:、:、」pref、「>つぼ:ナノ秒: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".
この操作は<doc>要素に新しい名前空間宣言を追加します。 その結果、この新しい名前空間ノードの接頭語は"pref"です、そして、名前空間URIは「つぼ:ナノ秒:xxx」です。
4.3.4. Adding Node(s) with the 'pos' Attribute
4.3.4. 'pos'属性でノードを加えます。
An example for an addition of a comment node:
コメントノードの追加のための例:
<add
sel="doc/foo[@id='ert4773']" pos="before"><!-- comment --></add>
<は、「doc/foo[@idは'ert4773'と等しい]」pos="before">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'属性指示を使用できる例です。
4.3.5. Adding Multiple Nodes
4.3.5. 複数のノードを加えます。
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ドキュメントの中に存在すると、何らかの複雑さが起こります。 XPath1.0データモデルは、テキストノードには即座の兄弟ノードとして別のテキストノードがあってはいけないのを必要とします。 例えば、操作がこの似ていると言い足してください:
<add sel="doc">
<foo id="ert4773">This is a new child</foo></add>
<がselに=を加える、「doc、「><fooイド=、「ert4773、「>Thisによる新しい子供</fooな></が>を加えるということです」。
Urpalainen Standards Track [Page 12] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[12ページ]RFC5261は、操作9月が2008であるとパッチします。
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.
<は、次に、>要素には2つの子供ノードがあると言い足します: 余白テキストノード(ラインフィードと2つの空間)と<foo>要素。 そして、<doc>要素の最後の既存の子供がテキストノードであるなら、内容と余白テキストノード内容を一緒に結合しなければなりません。 さもなければ、まさしく要素のように(余白)テキストノードを加えることができます、そして、その結果、パッチしているXMLドキュメントの標準形は容易に決定論的に残っています。 単一の<でいくつかの兄弟ノードを挿入できるように、>操作を加えてください、そして、容易に「きれいな印刷」スタイルは維持できます。
Still another example about the handling of text nodes. Consider this example:
テキストノードの取り扱いに関するまだ別の例。 この例を考えてください:
<add sel="*/foo/text()[2]" pos="after">new<bar/>elem</add>
「<は、selが」 */foo/text()[2]と等しいと言い足し」pos="after"の>の新しい<バー/>elem</を>を加えます。
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つのテキストノードと要素を含んでいます。 ノード、見つけられた目標テキストノード内容、および最初の新しいテキストノード内容がそうしなければならない即座の兄弟テキストがあるはずがないように、一緒に結合されてください。 本質では、事実上、2番目の新しいテキストノード内容は'pos'値が“before"であったなら、見つけられた目標テキストノードにprependedされたでしょうに。
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部は新しいテキストノードの中に存在して、それらはSHOULDです。パッチしている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ドキュメントの両方がそれらのプロローグの中に同じ宣言を持っているなら、これらの参照は保存されるかもしれません。 さもなければ、「正準に同等な」規則が従われる限り、参照を同じテキストに取り替えるかもしれません。
4.4. <replace> Element
4.4. <は>要素を置き換えます。
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.
<は>を取り替えます。要素は交換操作を表します: 例えば、新しい要素で既存の要素をアップデートするか、または属性値を新しい値に取り替えます。 この<は一度に、aただ一つのノードかノード満足していた状態で操作がいつもアップデートする>を取り替えます。
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
<は要素型が'sel'に結果と考えさせるだけである>を取り替えます。 見つけられた目標ノードが要素、コメントまたは処理命令であるなら、<の子供は要素が取り替えなければならない>を取り替えます、また、同じタイプにはいてください。 さもなければ、<が要素が持たなければならない>を取り替える、テキスト
Urpalainen Standards Track [Page 13] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[13ページ]RFC5261は、操作9月が2008であるとパッチします。
content or it MAY be empty when replacing an attribute value or a text node content.
属性値かテキストノード内容を置き換えるとき、内容かそれが空であるかもしれません。
4.4.1. Replacing an Element
4.4.1. 要素を置き換えます。
An example for a replacement of an element:
要素の交換のための例:
<replace sel="doc/foo[@a='1']"><bar a="2"/></replace>
<はselに=「2インチ/>の</が取り替えるdoc/foo[@a='1']「><バーa=」>」を取り替えます。
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.
これは値で'a'属性を持っている<foo>要素を「1インチ」アップデートするでしょう。 見つけられた目標要素を<バー>要素に取り替えます。 それで、いずれか存在したなら、取り替えられた<foo>要素のすべての派生ノード、名前空間宣言、および属性はこのようにして取り除かれます。
4.4.2. Replacing an Attribute Value
4.4.2. 属性値を取り替えます。
An example for a replacement of an attribute value:
属性値の交換のための例:
<replace sel="doc/@a">new value</replace>
<がselに=" doc/@a "を取り替える、gt;、新しい値の</は>を取り替えます。
This will replace the 'a' attribute content of the <doc> element with the value "new value". If the <replace> element is empty, the 'a' attribute MUST then remain in the patched XML document appearing like <doc a=""/>.
これは「新しい値」という値に従った<doc>要素の'a'属性内容を置き換えるでしょう。 「<が>を取り替えるなら要素が空である、そして、'a'属性は<doc a=のように見えながら、パッチしているXMLドキュメントに残らなければなりません」。」 />。
4.4.3. Replacing a Namespace Declaration URI
4.4.3. 名前空間宣言URIを取り替えます。
An example for a replacement of a namespace URI:
名前空間URIの交換のための例:
<replace sel="doc/namespace::pref">urn:new:xxx</replace>
<がselに=を取り替える、「doc/名前空間:、:、」pref、「>つぼ: 新しく、: 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.
これが'pref'の値が名前空間ノードを前に置いたURIを取り替える、「つぼ: 新しい:、xxx、」 名前空間宣言の親ノードが<doc>要素であるに違いない、さもなければ、誤りは発生します。
4.4.4. Replacing a Comment Node
4.4.4. コメントノードを置き換えます。
An example for a replacement of a comment node:
コメントノードの交換のための例:
<replace sel="doc/comment()[1]"><!-- This is the new content --></replace>
<がselに=を取り替える、「() [1] 「><!--これは新しい内容です--></は>を取り替える」というdoc/コメント
This will replace a comment node. The located target node is the first comment node child of the <doc> element.
これはコメントノードを置き換えるでしょう。 見つけられた目標ノードは<doc>要素の最初のコメントノード子供です。
Urpalainen Standards Track [Page 14] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[14ページ]RFC5261は、操作9月が2008であるとパッチします。
4.4.5. Replacing a Processing Instruction Node
4.4.5. 処理命令ノードを置き換えます。
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.
これは親が<doc>要素である「テスト」という処理命令ノードを置き換えるでしょう。
4.4.6. Replacing a Text Node
4.4.6. テキストノードを置き換えます。
An example for a replacement of a text node:
テキストノードの交換のための例:
<replace sel="doc/foo/text()[1]">This is the new text content</replace>
<がselに=を取り替える、「doc/foo/テキスト、() [1] 「>Thisによる新しいテキスト内容</が>を取り替えるということです」。
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>要素の最初のテキストノード子供を取り替えるでしょう。 Mixedタイプ[W3C. REC-xmlschema-1-20041028]には要素含有量が数人のテキストノード兄弟が通常存在するところにめったになくて、通常、位置の規制"[1]"は必要ではありません。
If a text node is updated and the <replace> element is empty, the text node MUST thus be removed as a text node MUST always have at least one character of data.
テキストノードをアップデートして、<が>を取り替えるなら要素が空である、その結果、テキストノードにデータの少なくとも1つのキャラクタがいつもなければならないとき、テキストノードを取り除かなければなりません。
4.5. <remove> Element
4.5. <は>要素を取り除きます。
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.
<は取り外されます。>要素型には、2つの属性があります: 'sel'と'ws'。 任意の'ws'属性の値は、見つけられた目標ノードの兄弟ノードに従うか、または先行する即座であるとして存在する可能な余白テキストノードを取り除くのに使用されます。 テキスト、属性、および名前空間ノード以外のタイプを外すときだけ、'ws'属性の用法は許容されています。 'ws'の値が“before"であるなら、目的は余白テキストノードと値が“after"(対応する次のノード)であるかどうかということであるに違いない即座の前の兄弟ノードを取り除くことです。 'ws'値が「両方」であるなら、両方の前の、そして、次の余白テキストノードを取り除かなければなりません。
4.5.1. Removing an Element
4.5.1. 要素を取り除きます。
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"/>
<はsel=「doc/foo[@a='1']」ws="after"/>を取り外します。
Urpalainen Standards Track [Page 15] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[15ページ]RFC5261は、操作9月が2008であるとパッチします。
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>要素を取り除くでしょう。 即座の次の兄弟ノードが余白テキストノードでないなら、誤りは発生します。
4.5.2. Removing an Attribute
4.5.2. 属性を取り除きます。
An example for a removal of an attribute node:
属性ノードの取り外しのための例:
<remove sel="doc/@a"/>
<がselに=" doc/@a "/を取り除く、gt。
This will remove the 'a' attribute node from the <doc> element.
これは<doc>要素から'a'属性ノードを取り除くでしょう。
4.5.3. Removing a Prefixed Namespace Declaration
4.5.3. 前に置かれた名前空間宣言を取り除きます。
An example for a removal of a prefixed namespace node:
前に置かれた名前空間ノードの取り外しのための例:
<remove sel="doc/foo/namespace::pref"/>
<がselに=を取り除く、「doc/foo/名前空間:、:、」"pref"/>。
This will remove the 'pref' prefixed namespace node from the <foo> element. Naturally, this prefix MUST NOT be associated with any node prior to the removal of this namespace node. Also, the parent node of this namespace declaration MUST be the <foo> element.
これは<foo>要素から'pref'前に置かれた名前空間ノードを取り除くでしょう。 当然、この接頭語はこの名前空間ノードの取り外しの前のどんなノードにも関連しているはずがありません。 また、この名前空間宣言の親ノードは<foo>要素であるに違いありません。
4.5.4. Removing a Comment Node
4.5.4. コメントノードを取り除きます。
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.
これは<doc>要素の最初のコメントノード子供を外すでしょう。
4.5.5. Removing a Processing Instruction Node
4.5.5. 処理命令ノードを取り除きます。
An example for a removal of a processing instruction node:
処理命令ノードの取り外しのための例:
<remove sel='doc/processing-instruction("test")'/>
<はsel='doc/処理命令(「テスト」)'/>を取り外します。
This will remove the "test" processing instruction node child of the <doc> element.
これは<doc>要素の「テスト」処理命令ノード子供を外すでしょう。
4.5.6. Removing a Text Node
4.5.6. テキストノードを取り除きます。
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>要素の最初のテキストノード子供を外すでしょう。
Urpalainen Standards Track [Page 16] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[16ページ]RFC5261は、操作9月が2008であるとパッチします。
When removing an element, a comment, or a processing instruction node that has immediate preceding and following sibling text nodes without the 'ws' directive, the content of these two text nodes MUST be combined together. The latter text node thus disappears from the document.
'ws'指示なしで要素か、コメントか、即座の先行を持っている処理命令ノードと次の兄弟テキストノードを取り除くとき、これらの2つのテキストノードの中身を一緒に結合しなければなりません。 その結果、後者のテキストノードはドキュメントから見えなくなります。
5. Error Handling
5. エラー処理
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の種類の中でこれらの誤り要素を使用できると予期されます。
5.1. Error Elements
5.1. 誤り要素
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.
誤りドキュメントの根の要素は<パッチオプアート誤り>です。 この要素の内容は特定のエラー条件です。 各エラー条件は異なった要素によって表されます。 これは、異なったエラー条件が誤りの本質に関する異なったデータを提供するのを許容します。 すべての誤り要素が「句」属性をサポートします。(それは、レンダリングのために人間のユーザに意味されたテキストを含むことができます)。 任意「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'属性値の正当性規制はこの誤りで示されるかもしれません、すなわち、許容できる非内容が使用されました。 また、加えられるかa変更された属性内容が有効でないかどうかを示すのにこの誤りを使用できました、新しい属性が加えられることを意図したとき、例えば、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.
<の無効の実体の宣言の>: 実体参照が見つけられましたが、対応する宣言を見つけることができなかったか、決議できませんでした。
Urpalainen Standards Track [Page 17] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[17ページ]RFC5261は、操作9月が2008であるとパッチします。
<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.
<のサポートされないイドの機能している>: nodeset機能イド()はサポートされません、そして、その結果、IDタイプがある属性は知られていません。
<unsupported-xml-id>: The attribute xml:id as an ID attribute in XML
documents is not supported.
<のサポートされないxml-イドの>: 属性xml: XMLドキュメントのID属性としてのイドはサポートされません。
Additional error elements can be indicated within the root <patch-ops-error> element from any namespace. However, the IETF MAY specify additional error elements in the "urn:ietf:params:xml:ns:patch-ops-error" namespace.
オプアート誤りにパッチしている根の<>要素の中にどんな名前空間からも追加誤り要素を示すことができます。 しかしながら、IETF MAYは「つぼ:ietf:params:xml:ナノ秒: オプアートが誤りであるとパッチしてください」という名前空間で追加誤り要素を指定します。
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:
例として、以下のドキュメントは、それが余白がある新しい<注意>要素をドキュメントに追加するために試みられましたが、親元素の見つけることができなかったのを示します:
Urpalainen Standards Track [Page 18] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[18ページ]RFC5261は、操作9月が2008であるとパッチします。
<?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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><パッチオプアート誤りxmlns: p=「つぼ:ietf:params:xml:ナノ秒: pidfデフ」xmlnsは「つぼ:ietf:params:xml:ナノ秒: パッチオプアート誤り「>の<の「非-場所を見つけ」られたノードの句=」aユニークなノードのイド()機能で見つけることができなかったこと」と等しいです。 ><p: selが'イド("ert4773")'><p: 何らかのテキストが</pを加えたという注意>: ></pに注意してください: >の「非-場所を見つけ」られた</ノード></パッチ-オプアート誤り>を加えてください'と等しいと言い足してください。
6. Usage of Patch Operations
6. パッチ操作の用法
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.
試みる唯一の意志が変更されたノードですが、SHOULDが含む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.
いくつかのアプリケーションが、歴史には余計な変化がありましたが、完全なversioning歴史を示さなければならないのを必要とするかもしれません。 このフレームワークは少しの特異的行動も強制しないで、アプリケーションは自分たちで適切な意味論について決めるかもしれません。 また、デフドキュメント内容を生成するとき、実際には、アプリケーションは無料で適切なアルゴリズムを選択できます。
7. Usage of Selector Values
7. セレクタ値の用法
It is up to the application to decide what kind of selector values to use. Positional element selectors like "*/*[3]/*[2]" provide the shortest selectors, but care must to taken when using them. When there are several removals of sibling elements, the positional element indexes change after each update. Likewise these indexes change when new elements are inserted into the tree. Using names with possible attribute predicates like "doc[@sel='foo']" is usually easier for an application, be it for example an auto diff tool, but it leads to larger diff documents.
セレクタ値のどんな種類を使用したらよいかを決めるのがアプリケーションまで達しています。 「位置の要素セレクタは」 */*[3]/*[2]が好きであること」を最も短いセレクタを提供しますが、それらを使用するとき、注意は取られるのに提供しなければなりません。 兄弟要素のいくつかの取り外しがあるとき、位置の要素インデックスは各アップデートの後に変化します。 同様にこれらのインデックスは、新しい要素がいつ木に挿入されるかを変えます。 アプリケーションには、「doc[@selは'foo'と等しい]」のような可能な属性述部の名前を使用するのは例えば、それが自動デフツールであったなら通常より簡単ですが、それは、より大きいデフドキュメントに通じます。
8. XML Schema Types of Patch Operation Elements
8. パッチOperation ElementsのXML図式タイプ
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バージョン=、「=「UTF-8インチ?」をコード化する1インチ「><!DOCTYPE図式、[<!ENTITY ncname、」 \i\c*、「><!ENTITY qname、「(ncname;、:、)、ncname; 「><!ENTITY aname」@とqname; 「><!ENTITY pos」\[\d+\]">"
Urpalainen Standards Track [Page 19] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[19ページ]RFC5261は、操作9月が2008であるとパッチします。
<!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;='(.)*'\]|\[&aname;="(.)*"\]"> <!ENTITY valueq "\[(&qname;|\.)="(.)*"\]"> <!ENTITY value "\[(&qname;|\.)='(.)*'\]|&valueq;"> <!ENTITY cond "&attr;|&value;|&pos;"> <!ENTITY step "(&qname;|\*)(&cond;)*"> <!ENTITY piq "processing-instruction\(("&ncname;")\)"> <!ENTITY pi "processing-instruction\(('&ncname;')?\)|&piq;"> <!ENTITY id "id\(('&ncname;')?\)|id\(("&ncname;")?\)"> <!ENTITY com "comment\(\)"> <!ENTITY text "text\(\)"> <!ENTITY nspa "namespace::&ncname;"> <!ENTITY cnodes "(&text;(&pos;)?)|(&com;(&pos;)?)|((π)(&pos;)?)"> <!ENTITY child "&cnodes;|&step;"> <!ENTITY last "(&child;|&aname;|&nspa;)"> ]> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xsd:simpleType name="xpath">
<xsd:restriction base="xsd:string">
<xsd:pattern
value="(/)?((&id;)((/&step;)*(/&last;))?|(&step;/)*(&last;))"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="xpath"> <xsd:restriction base="xsd:string"> <xsd:pattern value="(/)?((&id;)((/&step;)*(/&last;))?|(&step;/)*(&last;))"/> </xsd:restriction> </xsd:simpleType>
<xsd:simpleType name="xpath-add">
<xsd:restriction base="xsd:string">
<xsd:pattern
value="(/)?((&id;)((/&step;)*(/&child;))?|(&step;/)*(&child;))"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="xpath-add"> <xsd:restriction base="xsd:string"> <xsd:pattern value="(/)?((&id;)((/&step;)*(/&child;))?|(&step;/)*(&child;))"/> </xsd:restriction> </xsd:simpleType>
<xsd:simpleType name="pos">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="before"/>
<xsd:enumeration value="after"/>
<xsd:enumeration value="prepend"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="pos"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="before"/> <xsd:enumeration value="after"/> <xsd:enumeration value="prepend"/> </xsd:restriction> </xsd:simpleType>
<xsd:simpleType name="type">
<xsd:restriction base="xsd:string">
<xsd:pattern value="&aname;|&nspa;"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="type"> <xsd:restriction base="xsd:string"> <xsd:pattern value="&aname;|&nspa;"/> </xsd:restriction> </xsd:simpleType>
<xsd:complexType name="add">
<xsd:complexType name="add">
Urpalainen Standards Track [Page 20] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 20] RFC 5261 Patch Operations September 2008
<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 mixed="true"> <xsd:restriction base="xsd:anyType"> <xsd:sequence> <xsd:any processContents="lax" namespace="##any" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="sel" type="xpath-add" use="required"/> <xsd:attribute name="pos" type="pos"/> <xsd:attribute name="type" type="type"/> </xsd:restriction> </xsd:complexContent> </xsd:complexType>
<xsd:complexType name="replace">
<xsd:complexContent mixed="true">
<xsd:restriction base="xsd:anyType">
<xsd:sequence>
<xsd:any processContents="lax" namespace="##any"
minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="sel" type="xpath" use="required"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="replace"> <xsd:complexContent mixed="true"> <xsd:restriction base="xsd:anyType"> <xsd:sequence> <xsd:any processContents="lax" namespace="##any" minOccurs="0" maxOccurs="1"/> </xsd:sequence> <xsd:attribute name="sel" type="xpath" use="required"/> </xsd:restriction> </xsd:complexContent> </xsd:complexType>
<xsd:simpleType name="ws">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="before"/>
<xsd:enumeration value="after"/>
<xsd:enumeration value="both"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ws"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="before"/> <xsd:enumeration value="after"/> <xsd:enumeration value="both"/> </xsd:restriction> </xsd:simpleType>
<xsd:complexType name="remove">
<xsd:attribute name="sel" type="xpath" use="required"/>
<xsd:attribute name="ws" type="ws"/>
</xsd:complexType>
<xsd:complexType name="remove"> <xsd:attribute name="sel" type="xpath" use="required"/> <xsd:attribute name="ws" type="ws"/> </xsd:complexType>
</xsd:schema>
</xsd:schema>
9. XML Schema of Patch Operation Errors
9. XML Schema of Patch Operation Errors
The patch operation errors definitions.
The patch operation errors definitions.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
targetNamespace="urn:ietf:params:xml:ns:patch-ops-error"
<?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="urn:ietf:params:xml:ns:patch-ops-error"
Urpalainen Standards Track [Page 21] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 21] RFC 5261 Patch Operations September 2008
xmlns:tns="urn:ietf:params:xml:ns:patch-ops-error"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
xmlns:tns="urn:ietf:params:xml:ns:patch-ops-error" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- This import brings in the XML language attribute xml:lang--> <xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- ROOT document element for signaling patch-ops errors -->
<xsd:element name="patch-ops-error">
<xsd:complexType>
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:anyAttribute processContents="lax"/>
</xsd:complexType>
</xsd:element>
<!-- ROOT document element for signaling patch-ops errors --> <xsd:element name="patch-ops-error"> <xsd:complexType> <xsd:sequence> <xsd:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:anyAttribute processContents="lax"/> </xsd:complexType> </xsd:element>
<!-- patch-ops error elements:
not intended to be used as root documnet elements -->
<xsd:element name="invalid-attribute-value"
type="tns:patch-error"/>
<xsd:element name="invalid-character-set"
type="tns:patch-error-simple"/>
<xsd:element name="invalid-diff-format"
type="tns:patch-error-simple"/>
<xsd:element name="invalid-entity-declaration"
type="tns:patch-error"/>
<xsd:element name="invalid-namespace-prefix"
type="tns:patch-error"/>
<xsd:element name="invalid-namespace-uri"
type="tns:patch-error"/>
<xsd:element name="invalid-node-types"
type="tns:patch-error"/>
<xsd:element name="invalid-patch-directive"
type="tns:patch-error"/>
<xsd:element name="invalid-root-element-operation"
type="tns:patch-error"/>
<xsd:element name="invalid-xml-prolog-operation"
type="tns:patch-error"/>
<xsd:element name="invalid-whitespace-directive"
type="tns:patch-error"/>
<xsd:element name="unlocated-node"
type="tns:patch-error"/>
<xsd:element name="unsupported-id-function"
type="tns:patch-error"/>
<!-- 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"/>
Urpalainen Standards Track [Page 22] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 22] RFC 5261 Patch Operations September 2008
<xsd:element name="unsupported-xml-id"
type="tns:patch-error"/>
<xsd:element name="unsupported-xml-id" type="tns:patch-error"/>
<!-- simple patch-ops error type -->
<xsd:complexType name="patch-error-simple">
<xsd:attribute name="phrase" type="xsd:string"/>
<xsd:attribute ref="xml:lang"/>
<xsd:anyAttribute processContents="lax"/>
</xsd:complexType>
<!-- simple patch-ops error type --> <xsd:complexType name="patch-error-simple"> <xsd:attribute name="phrase" type="xsd:string"/> <xsd:attribute ref="xml:lang"/> <xsd:anyAttribute processContents="lax"/> </xsd:complexType>
<!-- error type which includes patch operation -->
<xsd:complexType name="patch-error">
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax"/>
</xsd:sequence>
<xsd:attribute name="phrase" type="xsd:string"/>
<xsd:attribute ref="xml:lang"/>
<xsd:anyAttribute processContents="lax"/>
</xsd:complexType>
<!-- error type which includes patch operation --> <xsd:complexType name="patch-error"> <xsd:sequence> <xsd:any namespace="##any" processContents="lax"/> </xsd:sequence> <xsd:attribute name="phrase" type="xsd:string"/> <xsd:attribute ref="xml:lang"/> <xsd:anyAttribute processContents="lax"/> </xsd:complexType>
</xsd:schema>
</xsd:schema>
10. IANA Considerations
10. IANA Considerations
IANA has completed the following actions:
IANA has completed the following actions:
o registered a new XML namespace URN according to the procedures of
RFC 3688 [RFC3688].
o registered a new XML namespace URN according to the procedures of RFC 3688 [RFC3688].
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 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 registered two XML Schemas according to the procedures of RFC 3688
[RFC3688].
o registered two XML Schemas according to the procedures of RFC 3688 [RFC3688].
10.1. URN Sub-Namespace Registration
10.1. URN Sub-Namespace Registration
This specification registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688].
This specification registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688].
URI: The URI for this namespace is
urn:ietf:params:xml:ns:patch-ops-error
URI: The URI for this namespace is urn:ietf:params:xml:ns:patch-ops-error
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jari Urpalainen (jari.urpalainen@nokia.com).
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jari Urpalainen (jari.urpalainen@nokia.com).
Urpalainen Standards Track [Page 23] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 23] RFC 5261 Patch Operations September 2008
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-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
10.2. application/patch-ops-error+xml MIME Type
10.2. application/patch-ops-error+xml MIME Type
MIME media type name: application
MIME media type name: application
MIME subtype name: patch-ops-error+xml
MIME subtype name: patch-ops-error+xml
Mandatory parameters: none
Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [RFC3023].
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [RFC3023].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [RFC3023].
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
Security considerations: See Section 10 of RFC 3023 [RFC3023].
Security considerations: See Section 10 of RFC 3023 [RFC3023].
Interoperability considerations: none.
Interoperability considerations: none.
Published specification: RFC 5261
Published specification: RFC 5261
Urpalainen Standards Track [Page 24] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 24] RFC 5261 Patch Operations September 2008
Applications which use this media type: This document type has been
used to support transport of Patch-Ops errors in RFC 5261.
Applications which use this media type: This document type has been used to support transport of Patch-Ops errors in RFC 5261.
Additional Information:
Additional Information:
Magic Number: None
Magic Number: None
File Extension: .xer
File Extension: .xer
Macintosh file type code: "TEXT"
Macintosh file type code: "TEXT"
Personal and email address for further information: Jari
Urpalainen, jari.urpalainen@nokia.com
Personal and email address for further information: Jari Urpalainen, jari.urpalainen@nokia.com
Intended usage: COMMON
Intended usage: COMMON
Author/Change controller: The IETF
Author/Change controller: The IETF
10.3. Patch-Ops-Types XML Schema Registration
10.3. Patch-Ops-Types XML Schema Registration
This section registers a new XML Schema, the sole content of which is shown in Section 8.
This section registers a new XML Schema, the sole content of which is shown in Section 8.
URI:
urn:ietf:params:xml:schema:patch-ops
URI: urn:ietf:params:xml:schema:patch-ops
Registrant Contact:
IETF, SIMPLE working group, <simple@ietf.org>
Jari Urpalainen, <jari.urpalainen@nokia.com>
Registrant Contact: IETF, SIMPLE working group, <simple@ietf.org> Jari Urpalainen, <jari.urpalainen@nokia.com>
10.4. Patch-Ops-Error XML Schema Registration
10.4. Patch-Ops-Error XML Schema Registration
This section registers a new XML Schema, the sole content of which is shown in Section 9.
This section registers a new XML Schema, the sole content of which is shown in Section 9.
URI:
urn:ietf:params:xml:schema:patch-ops-error
URI: urn:ietf:params:xml:schema:patch-ops-error
Registrant Contact:
IETF, SIMPLE working group, <simple@ietf.org>
Jari Urpalainen, <jari.urpalainen@nokia.com>
Registrant Contact: IETF, SIMPLE working group, <simple@ietf.org> Jari Urpalainen, <jari.urpalainen@nokia.com>
Urpalainen Standards Track [Page 25] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 25] RFC 5261 Patch Operations September 2008
11. Security Considerations
11. Security Considerations
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.
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.
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.
12. Acknowledgments
12. Acknowledgments
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.
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.
13. References
13. References
13.1. Normative References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[W3C.REC-xml-20060816]
Maler, E., Paoli, J., Bray, T., Yergeau, F., and C.
Sperberg-McQueen, "Extensible Markup Language (XML) 1.0
(Fourth Edition)", World Wide Web Consortium
Recommendation REC-xml-20060816, August 2006,
<http://www.w3.org/TR/2006/REC-xml-20060816>.
[W3C.REC-xml-20060816] Maler, E., Paoli, J., Bray, T., Yergeau, F., 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-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. 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>.
Urpalainen Standards Track [Page 26] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 26] RFC 5261 Patch Operations September 2008
[W3C.REC-xml-names-20060816]
Hollander, D., Bray, T., Layman, A., and R. Tobin,
"Namespaces in XML 1.0 (Second Edition)", World Wide Web
Consortium Recommendation REC-xml-names-20060816, August
2006,
<http://www.w3.org/TR/2006/REC-xml-names-20060816>.
[W3C.REC-xml-names-20060816] Hollander, D., Bray, T., Layman, A., 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-xmlschema-1-20041028]
Beech, D., Thompson, H., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-1-20041028] Beech, D., Thompson, H., Maloney, M., 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-xml-c14n-20010315]
Boyer, J., "Canonical XML Version 1.0", World Wide Web
Consortium Recommendation REC-xml-c14n-20010315, March
2001,
<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
[W3C.REC-xml-c14n-20010315] Boyer, J., "Canonical XML 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-xmlschema-2-20041028]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Recommendation
REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[W3C.REC-xmlschema-2-20041028] Malhotra, A. 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.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., Walsh, N., and J. Marsh, "xml:id Version 1.0", W3C LastCall WD-xml-id-20041109, November 2004.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
Urpalainen Standards Track [Page 27] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 27] RFC 5261 Patch Operations September 2008
13.2. Informative References
13.2. Informative References
[W3C.REC-xpath20-20070123]
Berglund, A., Fernandez, M., Chamberlin, D., Boag, S.,
Robie, J., Kay, M., and J. Simeon, "XML Path Language
(XPath) 2.0", World Wide Web Consortium Recommendation
REC-xpath20-20070123, January 2007,
<http://www.w3.org/TR/2007/REC-xpath20-20070123>.
[W3C.REC-xpath20-20070123] Berglund, A., Fernandez, M., Chamberlin, D., Boag, S., Robie, J., Kay, M., 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>.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[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., and J. Urpalainen, "Presence Information Data format (PIDF) Extension for Partial Presence", RFC 5262, September 2008.
[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. 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.
[RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP)
Extension for Event State Publication", RFC 3903, October
2004.
[RFC3903] Niemi, A., Ed., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
Urpalainen Standards Track [Page 28] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 28] RFC 5261 Patch Operations September 2008
Appendix A. Informative Examples
Appendix A. Informative Examples
All following examples assume an imaginary XML diff document including these patch operation elements.
All following examples assume an imaginary XML diff document including these patch operation elements.
A.1. Adding an Element
A.1. Adding an Element
An example target XML document:
An example target XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
</doc>
<?xml version="1.0" encoding="UTF-8"?> <doc> <note>This is a sample document</note> </doc>
An XML diff document:
An XML diff document:
<?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" encoding="UTF-8"?> <diff> <add sel="doc"><foo id="ert4773">This is a new child</foo></add> </diff>
A result XML document:
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<foo id="ert4773">This is a new child</foo></doc>
<?xml version="1.0" encoding="UTF-8"?> <doc> <note>This is a sample document</note> <foo id="ert4773">This is a new child</foo></doc>
A.2. Adding an Attribute
A.2. Adding an Attribute
An example target XML document:
An example target XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<foo id="ert4773">This is a new child</foo></doc>
<?xml version="1.0" encoding="UTF-8"?> <doc> <note>This is a sample document</note> <foo id="ert4773">This is a new child</foo></doc>
An XML diff document:
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<add sel="doc/foo[@id='ert4773']" type="@user">Bob</add>
</diff>
<?xml version="1.0" encoding="UTF-8"?> <diff> <add sel="doc/foo[@id='ert4773']" type="@user">Bob</add> </diff>
Urpalainen Standards Track [Page 29] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 29] RFC 5261 Patch Operations September 2008
A result XML document:
A result XML document:
<?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" encoding="UTF-8"?> <doc> <note>This is a sample document</note> <foo id="ert4773" user="Bob">This is a new child</foo></doc>
A.3. Adding a Prefixed Namespace Declaration
A.3. Adding a Prefixed Namespace Declaration
An example target XML document:
An example target XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<foo id="ert4773">This is a new child</foo></doc>
<?xml version="1.0" encoding="UTF-8"?> <doc> <note>This is a sample document</note> <foo id="ert4773">This is a new child</foo></doc>
An XML diff document:
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<add sel="doc" type="namespace::pref">urn:ns:xxx</add>
</diff>
<?xml version="1.0" encoding="UTF-8"?> <diff> <add sel="doc" type="namespace::pref">urn:ns:xxx</add> </diff>
A result XML document:
A result XML document:
<?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" 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>
A.4. Adding a Comment Node with the 'pos' Attribute
A.4. Adding a Comment Node with the 'pos' Attribute
An example target XML document:
An example target XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<foo id="ert4773">This is a new child</foo></doc>
<?xml version="1.0" encoding="UTF-8"?> <doc> <note>This is a sample document</note> <foo id="ert4773">This is a new child</foo></doc>
An XML diff document:
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?> <diff> <add sel="doc/foo[@id='ert4773']" pos="before"><!-- comment --></add> </diff>
<?xml version="1.0" encoding="UTF-8"?> <diff> <add sel="doc/foo[@id='ert4773']" pos="before"><!-- comment --></add> </diff>
Urpalainen Standards Track [Page 30] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 30] RFC 5261 Patch Operations September 2008
A result XML document:
A result XML document:
<?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" encoding="UTF-8"?> <doc> <note>This is a sample document</note> <!-- comment --><foo id="ert4773">This is a new child</foo></doc>
A.5. Adding Multiple Nodes
A.5. Adding Multiple Nodes
An example target XML document:
An example target XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
</doc>
<?xml version="1.0" encoding="UTF-8"?> <doc> <note>This is a sample document</note> </doc>
An XML diff document:
An XML diff document:
<?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" encoding="UTF-8"?> <diff> <add sel="doc"> <foo id="ert4773">This is a new child</foo></add> </diff>
A result XML document:
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<?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>
<foo id="ert4773">This is a new child</foo></doc>
A.6. Replacing an Element
A.6. Replacing an Element
An example target XML document:
An example target XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
<?xml version="1.0" encoding="UTF-8"?> <doc> <foo a="1">This is a sample document</foo> </doc>
An XML diff document:
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<replace sel="doc/foo[@a='1']"><bar a="2"/></replace>
</diff>
<?xml version="1.0" encoding="UTF-8"?> <diff> <replace sel="doc/foo[@a='1']"><bar a="2"/></replace> </diff>
Urpalainen Standards Track [Page 31] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 31] RFC 5261 Patch Operations September 2008
A result XML document:
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<bar a="2"/>
</doc>
<?xml version="1.0" encoding="UTF-8"?> <doc> <bar a="2"/> </doc>
A.7. Replacing an Attribute Value
A.7. Replacing an Attribute Value
An example target XML document:
An example target XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc a="test">
<foo a="1">This is a sample document</foo>
</doc>
<?xml version="1.0" encoding="UTF-8"?> <doc a="test"> <foo a="1">This is a sample document</foo> </doc>
An XML diff document:
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<replace sel="doc/@a">new value</replace>
</diff>
<?xml version="1.0" encoding="UTF-8"?> <diff> <replace sel="doc/@a">new value</replace> </diff>
A result XML document:
A result XML document:
<?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" encoding="UTF-8"?> <doc a="new value"> <foo a="1">This is a sample document</foo> </doc>
A.8. Replacing a Namespace Declaration URI
A.8. Replacing a Namespace Declaration URI
An example target XML document:
An example target XML document:
<?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" encoding="UTF-8"?> <doc xmlns:pref="urn:test"> <foo a="1">This is a sample document</foo> </doc>
An XML diff document:
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<replace sel="doc/namespace::pref">urn:new:xxx</replace>
</diff>
<?xml version="1.0" encoding="UTF-8"?> <diff> <replace sel="doc/namespace::pref">urn:new:xxx</replace> </diff>
Urpalainen Standards Track [Page 32] RFC 5261 Patch Operations September 2008
Urpalainen Standards Track [Page 32] RFC 5261 Patch Operations September 2008
A result XML document:
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns:pref="urn:new:xxx">
<foo a="1">This is a sample document</foo>
</doc>
<?xml version="1.0" encoding="UTF-8"?> <doc xmlns:pref="urn:new:xxx"> <foo a="1">This is a sample document</foo> </doc>
A.9. Replacing a Comment Node
A.9. Replacing a Comment Node
An example target XML document:
An example target XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns:pref="urn:test">
<foo a="1">This is a sample document</foo>
<!-- comment -->
</doc>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc xmlns: prefは「つぼ: 1インチのテスト「><foo a=」>Thisはサンプルドキュメント</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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><デフ><がselに=を取り替える、「() [1] 「><!--これは新しい内容です--></は></デフ>を取り替える」というdoc/コメント
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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc xmlns: prefは「つぼ: 1インチのテスト「><foo a=」>Thisはサンプルドキュメント</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バージョン=、「=「UTF-8インチ?」をコード化する1インチ「= 「1インチの>Thisはサンプルドキュメント</foo><です--テストfoo=」という><doc><foo aバー」?></doc>。
Urpalainen Standards Track [Page 33] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[33ページ]RFC5261は、操作9月が2008であるとパッチします。
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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><デフ><は'doc/処理命令(「テスト」)'>sel=<を取り替えます--バー="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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc><foo a=「1インチの>Thisはサンプルドキュメント</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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc><foo a=「1インチの>Thisはサンプルドキュメント</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バージョン=、「=「UTF-8インチ?」をコード化する1インチ「doc/foo/テキスト()[1]」>><がselに取り替える><デフ=Thisによる新しいテキスト内容</が></デフ>を取り替えるということです。
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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc><foo a=「1インチの>Thisは新しいテキスト内容</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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc><foo a=「1インチの>Thisはサンプルドキュメント</foo></doc>です」。
Urpalainen Standards Track [Page 34] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[34ページ]RFC5261は、操作9月が2008であるとパッチします。
An XML diff document:
XMLデフドキュメント:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel="doc/foo[@a='1']" ws="after"/>
</diff>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><デフ><は「doc/foo[@a='1']」ws="after"/></デフsel=>を取り外します。
A result XML document:
結果XMLドキュメント:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
</doc>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc a=「1インチのfoo「><foo a=」>Thisはサンプルドキュメント</foo></doc>です」。
An XML diff document:
XMLデフドキュメント:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel="doc/@a"/>
</diff>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><デフ<がselに取り外す>=" doc/@a "/、gt;、</デフ>。
A result XML document:
結果XMLドキュメント:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc><foo a=「1インチの>Thisはサンプルドキュメント</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バージョン=、「=「UTF-8インチ?」をコード化する1インチ「><doc><foo aは「1インチのxmlns: pref=」つぼと等しいです: テストしてください」>Thisはサンプルドキュメント</foo><です!--コメントしてください--></は>をdocします。
Urpalainen Standards Track [Page 35] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[35ページ]RFC5261は、操作9月が2008であるとパッチします。
An XML diff document:
XMLデフドキュメント:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel="doc/foo/namespace::pref"/>
</diff>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><デフ><がselに=を取り除く、「doc/foo/名前空間:、:、」"pref"/></デフ>。
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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc><foo aは「1インチの>Thisはサンプルドキュメント</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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc><foo aは「1インチの>Thisはサンプルドキュメント</foo><です!--コメントしてください--></は>をdocすること」と等しいです。
An XML diff document:
XMLデフドキュメント:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel="doc/comment()[1]" ws="after"/>
</diff>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><デフ><はsel=「doc/コメント()[1]」ws="after"/></デフ>を取り外します。
A result XML document:
結果XMLドキュメント:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc><foo a=「1インチの>Thisはサンプルドキュメント</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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc><foo a=「1インチの>Thisはサンプルドキュメント</foo><(テスト)です」。></doc>。
Urpalainen Standards Track [Page 36] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[36ページ]RFC5261は、操作9月が2008であるとパッチします。
An XML diff document:
XMLデフドキュメント:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel='doc/processing-instruction("test")'/>
</diff>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><デフ><は'doc/処理命令(「テスト」)'/></デフsel=>を取り外します。
A result XML document:
結果XMLドキュメント:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc><foo a=「1インチの>Thisはサンプルドキュメント</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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc><foo a=「1インチの>Thisはサンプルドキュメント</foo></doc>です」。
An XML diff document:
XMLデフドキュメント:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel="doc/foo/text()[1]"/>
</diff>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><デフ><は「doc/foo/テキスト()[1]」/></デフsel=>を取り外します。
A result XML document:
結果XMLドキュメント:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1"/>
</doc>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc><foo aは「1インチ/>の</doc>」と等しいです。
Urpalainen Standards Track [Page 37] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[37ページ]RFC5261は、操作9月が2008であるとパッチします。
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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc xmlns=「つぼ:ietf:params:xml:ナノ秒: xxx」xmlns: zが等しい、「つぼ:ietf:params:xml:ナノ秒: yyy、「><注意>Thisがサンプルドキュメント</注意><elem a=である、「foo「><子供/></elem><elem a=」バー「><z: 子供/></elem></doc>」
An imaginary XML diff document where prefix "p" corresponds the targetNamespace of this imaginary schema:
接頭語「p」が対応する想像するXMLデフドキュメント、この想像する図式のtargetNamespace:
<?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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><p: デフxmlns=「つぼ:ietf:params:xml:ナノ秒: xxx」xmlns: y=「つぼ:ietf:params:xml:ナノ秒: yyy」xmlns: pが等しい、「つぼ:ietf:params:xml:ナノ秒: デフ">"
<p:add sel="doc/elem[@a='foo']"> <!-- This is a new child -->
<child id="ert4773">
<y:node/>
</child>
</p:add>
<p: sel=を加えてください、「doc/elem[@aは'foo'と等しい]、「><!--これは新しい子供です--、><子供イド=、「ert4773、「><y: ノード/></子供></p: >を加えてください」
<p:replace sel="doc/note/text()">Patched doc</p:replace>
<p: sel=を取り替えてください、「() 「>Patched doc</p: >を取り替えてください」というdoc/注意/テキスト
<p:remove sel="*/elem[@a='bar']/y:child" ws="both"/>
「<p: sel=を取り外してください」*/elem[@aは'バー'と等しい]/y: 」 子供wsは「両方」/>と等しいです。
<p:add sel="*/elem[@a='bar']" type="@b">new attr</p:add>
「<p: selが」 */elemと等しいと[@aは'バー'と等しいです]言い足してください」というタイプは」 @b「>の新しいattr</p: >を加えてください」と等しいです。
</p:diff>
</p: デフ>。
Urpalainen Standards Track [Page 38] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[38ページ]RFC5261は、操作9月が2008であるとパッチします。
One possible form of the result XML document after applying the patches:
パッチを適用した後の結果XMLドキュメントの1つの可能なフォーム:
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns="urn:ietf:params:xml:ns:xxx"
xmlns:z="urn:ietf:params:xml:ns:yyy">
<note>Patched doc</note>
<elem a="foo">
<child/>
<!-- This is a new child -->
<child id="ert4773">
<z:node/>
</child>
</elem>
<elem a="bar" b="new attr"/>
</doc>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><doc xmlns=「つぼ:ietf:params:xml:ナノ秒: xxx」xmlns: zが等しい、「つぼ:ietf:params:xml:ナノ秒: yyy、「><注意>Patched doc</注意><elem aが等しい、「foo、「><子供/><!--これは新しい子供です--><子供イド=「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ドキュメントがデフォルト1の代わりに前に置かれた名前空間宣言を使用したなら、XMLデフドキュメントはまだ同じであったかもしれないでしょうに。 加えられた新しい適切な要素はちょうどその接頭語を引き継いだでしょう。
Author's Address
作者のアドレス
Jari Urpalainen Nokia Itamerenkatu 11-13 Helsinki 00180 Finland
ヤリUrpalainenノキアItamerenkatu11-13ヘルシンキ00180フィンランド
Phone: +358 7180 37686 EMail: jari.urpalainen@nokia.com
以下に電話をしてください。 +358 7180 37686はメールされます: jari.urpalainen@nokia.com
Urpalainen Standards Track [Page 39] RFC 5261 Patch Operations September 2008
Urpalainen標準化過程[39ページ]RFC5261は、操作9月が2008であるとパッチします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Urpalainen Standards Track [Page 40]
Urpalainen標準化過程[40ページ]
一覧
スポンサーリンク
