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
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for
improvements. Plea 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
Extensible Markup Language (XML) documents are widely ud as
containers for the exchange and storage of arbitrary data in today’s systems. In order to nd changes to an XML document, an entire copy of the new version must be nt, 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) lectors. The lector 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 t of patches can then be applied to update an existing XML document.
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 Ud 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]
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)
drillbit
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]
1. Introduction
Extensible Markup Language (XML) [W3C.REC-xml-20060816] documents are widely ud as containers for the exchange and storage of arbitrary
data in today’s systems. In order to nd changes to an XML
雅思考试写作范文document, an entire copy of the new version must be nt, 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] lectors. An XPath
lector is ud to pinpoint the specific portion of the XML that is the target for the change. The lector 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 t of patches can be applied to update an
existing target XML document. With the patch operations, a simple mantics 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 mantics.
As one concrete example, in the Session Initiation Protocol (SIP)
police是什么意思
[RFC3903] bad prence system a partial PIDF XML document format
[RFC5262] consists of the existing Prence Information Data Format
(PIDF) document format combined with the patch operations elements
described in this document. In general, patch operations can be ud in any application that exchanges XML documents, for example, within the SIP Events framework [RFC3265]. Yet another example is XCAP-diff [SIMPLE-XCAP], which us this framework for nding partial updates of changes to XCAP [RFC4825] resources.
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
strain[RFC2119] and indicate requirement levels for compliant
implementations.
The following terms are ud in this document:
Target XML document: A target XML document that is going to be
updated with a t of patches.
Urpalainen Standards Track [Page 3]
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.
Patch operation: A single change, i.e., a patch that is being
grab
applied to update a target XML document.
Patch operation element: An XML element that reprents 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.
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 bad on mapping a prefix with one of the declarations. For an element, one namespace binding may have an empty prefix.
Positional constraint: A number enclod with square brackets. It
can be ud as a location step predicate.
Located target node: A node that was found from the target XML
document with the aid of an XPath lector value.
White space text node: A text node that contains only white space. 3. Basic Features and Requirements
In this framework, XPath lector values and new data content are
embedded within XML elements, the names of which specify the
modification to be performed: <add>, <replace>, or <remove>. The
elements (patch operations) are defined by schema types with the W3C Schema language [W3C.REC-xmlschema-1-20041028]. XPath lectors
pinpoint the target for a change and they are expresd as attributes of the 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 purpos of many
applications MAY differ in their physical reprentation. The aim of this document is to describe a deterministic framework where the Urpalainen Standards Track [Page 4]
canonical form with comments [W3C.REC-xml-c14n-20010315] of an XMLbordeaux
document determines logical equivalence. For example, white space
text nodes MUST be procesd properly in order to fulfill this
requirement as white space is by default significant
[W3C.REC-xml-c14n-20010315].
The specifications referencing the element schema types MUST define the full XML diff format with an appropriate MIME type [RFC3023] and a character t, 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
prence 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.
It is anticipated that applications using the types will define
<add>, <replace>, and <remove> elements bad on the corresponding
type definitions in this schema. In addition, an application may
reference only a subt of the 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 bad on the 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
toothless
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
An XML diff document contains a collection of patch operation
elements, including one or more <add>, <replace>, and <remove>
elements. The patch operations will be applied quentially 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]
independent XML document against which the next patch will be
applied. This procedure repeats until all patches have successfully been procesd.
4.1. Locating the Target of a Patch
Each patch operation element contains a ’l’ attribute. The value
of this attribute is an XPath lector with a restricted subt of
the full XPath 1.0 recommendation. The ’l’ value is ud 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 itlf 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 inrted. In any
ca, it is an error condition if multiple nodes are found during the evaluation of this lector value.
The XPath lections of the ’l’ attribute always start from theblackberry
root node of a document. Thus, relative location paths SHOULD be
ud so that the starting root node lection "/" 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 lects 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 ud to identify
elements in the tree. The character ".", which denotes a current
context node lection, is an abbreviated form of "lf::node()".
Lastly, positional constraints like "[2]" can also be ud as an
additional predicate.
An XPath 1.0 "id()" node-t function MAY also be ud to identify
unique elements from the document tree. The schema that describes
the content model of the document MUST then u an attribute with the type ID [W3C.REC-xmlschema-2-20041028] or with non-validating XML
parrs, an "xml:id" [W3C.WD-xml-id-20041109] attribute MUST have
been ud within an instance document.
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 ud in the target document. The agent parsing the
diff document MUST resolve prefixes parately in both documents in
order to match the resulting QNames (qualified name) from each. Urpalainen Standards Track [Page 6]
