SIMPLE WG J. Urpalainen
Internet-Draft Nokia Research Center
Expires: May 29, 2006 November 25, 2005
An Extensible Markup Language (XML) Patch Operations Framework Utilizing
XML Path Language (XPath) Selectors
draft-ietf-simple-xml-patch-ops-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 29, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Extensible Markup Language (XML) documents are widely used as
containers for the exchange and storage of arbitrary data in today's
systems. Updates to this data require transporting of the entire XML
document between hosts, unless there's a mechanism that allows
exchanging only the updates of XML documents. This document
describes an XML patch framework utilizing XML Path language (XPath)
selectors. With the aid of these selector values and updated data
content a set of patches can then be applied to an existing initial
Urpalainen Expires May 29, 2006 [Page 1]
Internet-Draft Patch Operations November 2005
XML document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic features and requirements . . . . . . . . . . . . . . . 4
4. Patch operations . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. <add> element . . . . . . . . . . . . . . . . . . . . . . 7
4.2. <replace> element . . . . . . . . . . . . . . . . . . . . 9
4.3. <remove> element . . . . . . . . . . . . . . . . . . . . . 11
4.4. <patch> element . . . . . . . . . . . . . . . . . . . . . 12
5. Error handling . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Usage of patch operations . . . . . . . . . . . . . . . . . . 13
7. Full example . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. XML Schema Registration . . . . . . . . . . . . . . . . . 17
10. Security considerations . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative references . . . . . . . . . . . . . . . . . . . 18
12.2. Informative references . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Urpalainen Expires May 29, 2006 [Page 2]
Internet-Draft Patch Operations November 2005
1. Introduction
Extensible Markup Language (XML) [2] documents are widely used as
containers for the exchange and storage of arbitrary data in today's
systems. An example of such a system is the Common Presence Profile
(CPP) [14] compatible presence system, in which presence data is
represented using the XML based Presence Information Data Format
(PIDF) [15]. Updates to this data require transporting of the entire
XML document between hosts, unless there's a mechanism that allows
exchanging only the updates of a document.
This document describes an XML patch framework which utilizes XML
Path language (XPath) [3] selectors. With the aid of these selector
values and updated data content a set of patches can then be applied
to an existing initial XML document in order to transform it into a
new patched XML document. This document does not describe a full XML
diff format, only basic patch operations which can be included within
the full format.
An XPath selector is used to locate a single unique node from the
existing initial XML document. Once the XML node which pinpoints the
target for the modification has been found, modifications like
additions, removals or substitutions of e.g. elements and attributes
can be done.
As an example, in the Session Initiation Protocol (SIP) [16] based
presence system a partial PIDF XML document format [13] consists of
the existing PIDF document format combined with the patch operations
elements described in this document. In general, the patch
operations can be used in any application that exchanges XML
documents, e.g. in the SIP Events framework [12].
2. Conventions
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant implementations.
The following terms are used in this document:
Initial XML document: An initial XML document that is going to be
updated with a set of patches.
Urpalainen Expires May 29, 2006 [Page 3]
Internet-Draft Patch Operations November 2005
XML diff document: A frame XML document that contains patch operation
elements, namespace declarations and all the document content
changes that are needed in order to get a patched XML document
from the initial 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
initial XML document.
Patch operation: A single change, i.e., a patch that is being applied
to an initial XML document.
Patch operation element: An XML element that represents a single
patch operation.
Type definition for an element: A 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 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.
Located target node: A node which was found from the initial XML
document with the aid of an XPath selector value.
Whitespace text node: A text node which contains only whitespace.
3. Basic features and requirements
The changes of an XML document content, or synonymously patch
operations as used in this document, are described by defining schema
types for elements with the W3C Schema language [6]. The elements
defined according to these types MUST then be embedded within an
application specific XML diff document. The specifications utilizing
these element types MUST then define the full XML diff format with an
appropriate MIME type [11]. For example the partial PIDF format [13]
includes these schema element types.
As the schema defined in this document does not declare any target
namespace, elements defined according to these types inherit the
target namespace of the including schema. Therefore, additional
unnecessary namespace declarations within the instance XML diff
Urpalainen Expires May 29, 2006 [Page 4]
Internet-Draft Patch Operations November 2005
documents can be avoided.
It is anticipated that applications using these types will define
<add>, <replace>, <remove> and <patch> elements from the
corresponding types defined in this schema. As this specification
defines only types for elements, an application utilizing this
framework can easily omit some of these type definitions which it
doesn't need. With these basic operations a simple patch model for
data oriented documents [7] is produced. On the other hand, the
semantics described in this document can easily be extended as these
patch operations provide only the basic required features.
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 and
the root node of the initial 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 of
the document root element is not allowed as that would result in an
invalid XML document.
The aim of this document is to describe a deterministic framework
where only a single possible canonical form [4] of an XML document
exists once the patches have been applied onto it. Especially
whitespace text nodes MUST be processed properly in order to fulfil
this requirement as all whitespace is not insignificant [4].
4. Patch operations
A full XML diff document contains a collection of patch operation
elements: <add>, <replace>, <remove> and <patch> or a subset of these
operations. They will be applied sequentially to the initial XML
document in the given document order of the XML diff document. Other
elements than <patch> update the structure of the initial XML
document. The <patch> element MAY be used with document oriented
models [7] to update text content.
Each of these patch operation elements 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 value of the 'sel'
attribute is used to locate a single unique target node from the
initial XML document.
While the XPath recommendation specifies that prefixes can be used in
Urpalainen Expires May 29, 2006 [Page 5]
Internet-Draft Patch Operations November 2005
location steps, it does not specify how associated namespace URIs are
to be found during the XPath evaluations. In this framework QName
[5] expansion within a location step is evaluated according to the
namespace declarations of the XML diff document. Thus the namespace
URIs for the prefixes are easily found from the XML diff document.
XPath allows using "namespace-uri()" and "local-name()" node-set
functions within XPath predicates. For instance, these functions may
then be utilized if there are no other means to "register" prefixes
with associated namespace URIs. The schema type definitions for
these elements do not allow the usage of these node-set functions.
It should be emphasized that prefixes within the XPath selectors MAY
not have to be the same than that of the initial XML document because
the equivalence of nodes is based on the same namespace URIs and
local names.
If a patch operation element has an in-scope default namespace
declaration and a prefix is not used in a node test then that name is
interpreted as if it had had a prefixed name associated with this
default namespace URI. That is, unlike in XPath 1.0, a namespace
qualified element is being searched.
When locating the target node for a patch operation from the initial
XML document, all XPath selections start from the root node of the
document. Relative location paths SHOULD then be used so that the
starting root node selection "/" can be omitted. When locating
elements in the document tree, the node test can be either a "*"
character or a QName. A "*" character selects all element children
of the context node. Attribute value comparisons MAY be used as
predicates. Also text content 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()". Positional constraints MAY
also be used as an additional predicate. Ordering of these
positional constraints and value comparisons can interchange.
An XPath "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 [7] or with non-validating XML parsers, an "xml:id" [8]
attribute MUST have been used within the instance document.
As all the namespace declarations relevant to the patch operations
are included in the XML diff document, the elements within the
changed data content are usually namespace qualified. As with XPath
selectors, the prefixes of these nodes are not significant only the
namespace URIs MUST match. For example when adding a new qualified
element to the initial XML document, the namespace declaration which
Urpalainen Expires May 29, 2006 [Page 6]
Internet-Draft Patch Operations November 2005
has the same namespace URI is attached to this new element. However,
if overlapping in-scope namespaces exist within the evaluation
context, i.e., there are several in-scope namespaces with the same
namespace URI, then the namespace with the same prefix MUST be
selected. This kind of overlapping can happen when e.g. a qualified
attribute is added while elements are attached with an equal default
namespace declaration.
If the intention is to add new namespace declarations to the initial
XML document, the new namespaces MUST be declared within the added or
changed data content embedded as local declarations within elements,
or they MUST be explicitly added by using XPath namespace axis
semantics shown later in this document.
4.1. <add> element
The <add> element represents the addition of some new content to the
initial XML document: e.g., a new XML element or an attribute.
The <add> element type has three attributes: 'sel', 'type' and 'pos'.
The value of the 'sel' attribute is used to locate a single unique
element from the initial XML document. It is an error condition if
multiple elements are found during the evaluation of this selector
value.
The value of the optional 'type' attribute is used to describe the
type of the new data content. The new data content, which MUST not
be empty exists as the child node(s) of this <add> element. The
value of 'type' attribute is also an XPath 1.0 compatible selector
with a very limited set of XPath features. Once the new content
within the <add> element contains elements, they will include all the
attribute, namespace and descendant nodes. As the default value of
the 'type' attribute is "node()" the new content can be element,
text, comment or processing instruction nodes or a mixture of them.
The "node()" selector value is an abbreviated form of "child::
node()". A positional constraint MAY be used with the "node()"
selector when only a single node needs to be added. If the value of
the 'type' attribute equals "@attr" the purpose is to add a new
'attr' attribute. The value of the 'attr' attribute is then the text
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" the aim is to add a
new "pref" prefixed namespace declaration and the text content of the
<add> element is then the corresponding namespace URI.
The value of the optional 'pos' attribute indicates the positioning
of the new data content. As the default value is "to", the new
Urpalainen Expires May 29, 2006 [Page 7]
Internet-Draft Patch Operations November 2005
content is then simply added onto the located target element. For
other node types than attribute and namespace nodes, new content is
appended as the last child node(s). With the value of "before" the
new content MUST be the closest preceding sibling node(s) and with
"after" the closest following sibling node(s). Naturally the usage
of 'pos' attribute is not allowed when adding attributes and
namespaces. It can be used e.g. when a comment node or an element is
added just before or after an existing element.
Appending elements with all the descendant and attribute nodes is the
most typical operation. Because 'type' and 'pos' attributes have
convenient default values, the <add> element SHOULD then only contain
the 'sel' attribute with the added content.
Some examples without any prefixes in XPath selectors and elements
are also not namespace qualified. The initial XML document could be
like the full example shown later in this document. The full XML
diff content is not shown in these examples, only patch operation
elements because of simplicity reasons:
<add sel="doc"><foo id="ert4773">This is a new child</foo></add>
Once the <doc> element has been found from the initial XML document,
a new <foo> element is appended as the last child of the <doc>
element. The located target node: the <doc> element is naturally the
root element of the initial XML document. The <foo> element contains
an 'id' attribute and a child text node.
An example for an addition of an attribute:
<add sel="doc/foo[@id='ert4773']" type="@user">Bob</add>
This operation adds a new 'user' attribute to the <foo> element which
was located by using an 'id' attribute value predicate. The value of
this new 'user' attribute is "Bob".
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" [7].
It should be noted that as the 'sel' selector value MAY contain
quotation marks, escaped forms: """ or "'" can then 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.
An example for an addition of a namespace declaration:
Urpalainen Expires May 29, 2006 [Page 8]
Internet-Draft Patch Operations November 2005
<add sel="doc" type="namespace::pref">urn:ns:xxx</add>
This operation adds a new namespace declaration to the <doc> element.
The prefix of this new namespace node is thus "pref" and the
namespace URI is "urn:ns:xxx".
An example for an addition of a comment node:
<add sel="doc/foo[@id='ert4773']" pos="before"><!-- comment --></add>
This operation adds a new comment node just before the <foo> element
as the closest preceding sibling node. This shows how a 'pos'
attribute directive MAY be used.
Some complexity arises when so called whitespace text nodes exist
within the initial XML document. The XPath 1.0 data model requires
that a text node MUST not have another text node as a sibling node.
For instance, if an add operation is like this:
<add sel="doc">
<foo id="ert4773">This is a new child</foo></add>
The <add> element in this example has then two child nodes: a
whitespace 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 whitespace text node content MUST then be combined
together. Otherwise whitespace 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.
If text nodes contain other than pre-defined entities [2] their
declarations MUST typically be within the prolog of the XML diff
document if the initial XML document is also referencing these
entities.
4.2. <replace> element
The <replace> element represents a replacement operation: e.g. an
existing XML element is updated with a new XML element or an
attribute value is replaced with a new value. This <replace>
operation always updates a single node or node content at a time.
The <replace> element type has an attribute: 'sel'. The value of
this attribute is used to select a single unique node from the
initial XML document. If the located target node is an element, a
comment or a processing instruction, then the child of the <replace>
Urpalainen Expires May 29, 2006 [Page 9]
Internet-Draft Patch Operations November 2005
element MUST also be of the same type. Otherwise the <replace>
element MUST have text content or it MAY be empty, i.e. it does not
have any child node.
Examples for replace operations, first a replacement of an element:
<replace sel="doc/foo[@a='1']"><bar a="2"/></replace>
This will update the <foo> element which has an 'a' attribute with
value "1", i.e. 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.
An example for a replacement of an attribute value:
<replace sel="doc/@a">new content</replace>
This will replace the attribute 'a' content of the <doc> element with
the value "new content". If the <replace> element has not a child
text node, i.e. not any content, the 'a' attribute MUST then remain
in the patched XML document appearing like <doc a=""/>.
An example for a replacement of a namespace URI:
<replace sel="doc/namespace::pref">urn:new:xxx</replace>
This will replace the URI value of 'pref' prefixed namespace node
with "urn:new:xxx". The parent node of the namespace declaration
MUST be the <doc> element, otherwise an error occurs.
An example for a replacement of a comment node:
<replace sel="doc/comment()[1]"><!-- This is the new content
--></replace>
This will replace the comment node. The located target node is the
first child comment node of the <doc> element.
An example for a replacement of a processing instruction node:
<replace sel='doc/processing-instruction("test")'><?test bar="foobar"
?></replace>
This will replace the processing instruction node "test" whose parent
is the <doc> element.
An example for a replacement of a text node:
Urpalainen Expires May 29, 2006 [Page 10]
Internet-Draft Patch Operations November 2005
<replace sel="doc/foo/text()[1]">This is the new text content</
replace>
This will replace the first child text node of the <foo> element.
The positional constraint e.g. "[1]" is not usually needed as the
element content is rarely of mixed type [6] where several child text
nodes typically exist.
If a text node is being updated and the <replace> element has not any
child node, the text node MUST thus be removed.
4.3. <remove> element
The <remove> element represents a removal operation of e.g. an
existing XML element or an attribute from the initial XML document.
The <remove> element type has two attributes: 'sel' and 'ws'. The
value of the 'sel' attribute is used to select a single unique node
from the initial XML document. The value of the optional 'ws'
attribute is used to remove the possible whitespace text nodes that
exist either as the closest following or preceding sibling node(s) of
the located target node. The usage of 'ws' attribute is only allowed
when removing other types than text, attribute and namespace nodes.
As the default value of 'ws' attribute is "none", removal of
whitespace nodes is thus not requested. If the value of 'ws' is
"before", the purpose is to remove the closest preceding sibling node
which MUST be a whitespace text node and if the value is "after", the
corresponding following node. If the 'ws' value is "both", both the
preceding and following whitespace text nodes MUST be removed.
Examples for remove operations, first a removal of an element
including all descendants, attributes and namespape nodes:
<remove sel="doc/foo[@a='1']" ws="after"/>
This will remove the <foo> element as well as the closest following
sibling whitespace text node of the <foo> element. If the following
sibling node is not a whitespace text node, an error occurs.
An example for a removal of an attribute node:
<remove sel="doc/@a"/>
This will remove the 'a' attribute node from the <doc> element.
An example for a removal of a namespace node:
<remove sel="doc/foo/namespace::pref"/>
Urpalainen Expires May 29, 2006 [Page 11]
Internet-Draft Patch Operations November 2005
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.
An example for a removal of a comment node:
<remove sel="doc/comment()[1]"/>
This will remove the first child comment node of the <doc> element.
An example for a removal of a processing instruction node:
<remove sel='doc/processing-instruction("test")'/>
This will remove the child processing instruction node "test" of the
<doc> element.
An example for a removal of a text node:
<remove sel="doc/foo/text()[1]"/>
This will remove the first child text node of the <foo> element.
If an element, a comment node or a processing instruction node which
has a whitespace text node as both the closest preceding and
following node, is removed without a request to remove whitespace
nodes, the content of these two nodes MUST be combined together. The
other whitespace text node thus disappears from the initial XML
document.
4.4. <patch> element
This element type describes patching of a text node content or an
attribute value. There are several text patching algorithms
available. The <patch> element type shows how these algorithms can
be integrated with this framework.
The <patch> element type has two attributes: 'sel' and 'method'. The
value of the 'sel' attribute is used to select a single unique text
node or an attribute from the initial XML document. The 'method'
value indicates the patch algorithm one of which could be e.g.
"vcdiff" [9]. As XML is not good at embedding binary data the text
diffing content MUST be included with BASE64 encoding [10].
An example for a text node patch operation:
<patch sel="doc/foo/text()"
Urpalainen Expires May 29, 2006 [Page 12]
Internet-Draft Patch Operations November 2005
>1sPEAAAAFhAAEAEAcmVsYXggbmcgaXMgY29vbBGA</patch>
After locating the child text node of the <foo> element, BASE64 diff
content is decoded and a relevant patch is applied to the target
node.
5. Error handling
It is an error condition if any of the given operations can not be
unambiguously fulfilled. However, it is beyond the scope of this
document to describe a generic error response.
6. Usage of patch operations
The XML diff document SHOULD contain only the nodes which have been
modified. However, when there's a large collection of changes it MAY
be desirable to transport the full document content instead. How
this will be done in practice is beyond the scope of this document.
7. Full example
An example initial XML document where namespace qualified elements
exist:
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns="urn:ietf:params:xml:ns:xxx"
xmlns:z="urn:ietf:params:xml:ns:yyy">
<note>This is a sample document</note>
<elem a="foo">
<child/>
</elem>
<elem a="bar">
<z:child/>
</elem>
</doc>
An imaginary XML diff document where prefix "p" corresponds the
targetNamespace of this imaginary schema:
Urpalainen Expires May 29, 2006 [Page 13]
Internet-Draft Patch Operations November 2005
<?xml version="1.0" encoding="UTF-8"?>
<p:diff xmlns="urn:ietf:params:xml:ns:xxx"
xmlns:y="urn:ietf:params:xml:ns:yyy"
xmlns:p="urn:ietf:params:xml:ns:diff">
<p:add sel="doc/elem[@a='foo']"> <!-- This is a new child -->
<child id="ert4773">
<y:node/>
</child>
</p:add>
<p:replace sel="doc/note/text()">Patched doc</p:replace>
<p:remove sel="*/elem[@a='bar']/y:child" ws="both"/>
<p:add sel="*/elem[@a='bar']" type="@b">new attr</p:add>
</p:diff>
One possible form of the result XML document after applying the
patches:
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns="urn:ietf:params:xml:ns:xxx"
xmlns:z="urn:ietf:params:xml:ns:yyy">
<note>Patched doc</note>
<elem a="foo">
<child/>
<!-- This is a new child -->
<child id="ert4773">
<z:node/>
</child>
</elem>
<elem a="bar" b="new attr"/>
</doc>
The <node> element prefix within the XML diff document is different
than what is the same namespace declaration in the initial XML
document. If the initial XML document had used a prefixed namespace
declaration instead of the default one, the XML diff document could
still have been the same. The updated qualified elements would then
have inherited the prefixes of the initial XML document.
8. XML Schema
Urpalainen Expires May 29, 2006 [Page 14]
Internet-Draft Patch Operations November 2005
The element schema types for the patch operations.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE schema [
<!ENTITY ncname "[^:\I][^:\C]*">
<!ENTITY qname "(&ncname;:)?&ncname;">
<!ENTITY aname "@&qname;">
<!ENTITY pos_t "\[\d+\]">
<!ENTITY attr_t "\[&aname;=('|")(.)*('|")\]">
<!ENTITY name_t "\[(&qname;|\.)=('|")(.)*('|")\]">
<!ENTITY cond "(&attr_t;|&name_t;)?(&pos_t;)?|(&pos_t;)?(&attr_t;|&name_t;)?">
<!ENTITY step "(&qname;|\*)(&cond;)?">
<!ENTITY pi "processing-instruction\((('|")&qname;('|"))?\)">
<!ENTITY id "id\((('|")&ncname;('|"))?\)">
<!ENTITY comm "comment\(\)">
<!ENTITY text "text\(\)">
<!ENTITY nspace "namespace::&ncname;">
<!ENTITY last "&step;|&aname;|&nspace;|(&comm;(&pos_t;)?)|&text;(&pos_t;)?|π(&pos_t;)?">
<!ENTITY patch "(&text;(&pos_t;)?)|&aname;">
]>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xsd:simpleType name="xpath">
<xsd:restriction base="xsd:string">
<xsd:pattern value="(/)?(&step;/)*(&last;)"/>
<xsd:pattern value="(/)?&id;((/&step;)*(/&last;))?"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="xpath-elem">
<xsd:restriction base="xsd:string">
<xsd:pattern value="(/)?(&step;/)*(&step;)"/>
<xsd:pattern value="(/)?&id;(/&step;)*"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="xpath-text">
<xsd:restriction base="xsd:string">
<xsd:pattern value="(/)?(&step;/)*&patch;"/>
<xsd:pattern value="(/)?&id;(/&step;)*/&patch;"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="pos">
<xsd:restriction base="xsd:string">
Urpalainen Expires May 29, 2006 [Page 15]
Internet-Draft Patch Operations November 2005
<xsd:enumeration value="to"/>
<xsd:enumeration value="before"/>
<xsd:enumeration value="after"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="type">
<xsd:restriction base="xsd:string">
<xsd:pattern value="node\(\)(&pos_t;)?"/>
<xsd:pattern value="&aname;"/>
<xsd:pattern value="&nspace;"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="add">
<xsd:complexContent mixed="true">
<xsd:restriction base="xsd:anyType">
<xsd:sequence>
<xsd:any processContents="lax" namespace="##any"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="sel" type="xpath-elem"
use="required"/>
<xsd:attribute name="pos" type="pos"
default="to"/>
<xsd:attribute name="type" type="type"
default="node()"/>
</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="none"/>
Urpalainen Expires May 29, 2006 [Page 16]
Internet-Draft Patch Operations November 2005
<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" default="none"/>
</xsd:complexType>
<xsd:complexType name="patch">
<xsd:simpleContent>
<xsd:extension base="xsd:base64Binary">
<xsd:attribute name="sel" type="xpath-text"
use="required"/>
<xsd:attribute name="method" type="xsd:string"
default="vcdiff"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:schema>
9. IANA Considerations
9.1. XML Schema Registration
This section registers a new XML Schema.
URI:
urn:ietf:params:xml:schema:xml-patch-ops
Registrant Contact:
IETF, SIMPLE working group, <simple@ietf.org>
Jari Urpalainen, <jari.urpalainen@nokia.com>
10. Security considerations
Information exchanged within these patch operations can be highly
sensitive. Thus systems need to protect the integrity and
confidentiality of this data. Especially, the transport protocol
SHOULD have capabilities to protect from possible threats.
Urpalainen Expires May 29, 2006 [Page 17]
Internet-Draft Patch Operations November 2005
11. Acknowledgments
The author would like to thank Eva Leppanen, Mikko Lonnfors, Aki
Niemi, Jonathan Rosenberg and Miguel A. Garcia for their valuable
comments.
12. References
12.1. Normative references
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C
Recommendation REC-xml-20040204 , February 2004.
[3] "XML Path Language (XPath) Version 1.0", W3C Recommendation
REC-xpath-19991116 , November 1999.
[4] "Canonical XML 1.0", W3C Recommendation REC-xml-c14n-20010315 ,
March 2001.
[5] "Namespaces in XML", W3C Recommendation REC-xml-names-
19990114 , January 1999.
[6] "XML Schema Part 1: Structures Second Edition", W3C
Recommendation REC-xmlschema-1-20041028 , October 2004.
[7] "XML Schema Part 2: Datatypes Second Edition", W3C
Recommendation PER-xmlschema-2-20040318 , October 2004.
[8] "xml:id Version 1.0 W3C Recommendation 9 September 2005", W3C
Recommendation PR-xml-id-20050712 , September 2005.
[9] Korn, D., MacDonald, J., Mogul, J., and K. Vo, "The VCDIFF
Generic Differencing and Compression Data Format", RFC 3284,
June 2002.
[10] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
12.2. Informative references
[11] Murata, M., "XML media types", RFC 3023, January 2001.
[12] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
Urpalainen Expires May 29, 2006 [Page 18]
Internet-Draft Patch Operations November 2005
[13] Lonnfors, M., Leppanen, E., Khartabil, H., and J. Urpalainen,
"Presence Information Data format (PIDF) Extension for Partial
Presence", draft-ietf-simple-partial-pidf-format-05 (work in
progress), September 2005.
[14] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
August 2004.
[15] Sugano, H., "CPIM presence information data format", RFC 3863,
May 2003.
[16] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
Urpalainen Expires May 29, 2006 [Page 19]
Internet-Draft Patch Operations November 2005
Author's Address
Jari Urpalainen
Nokia Research Center
Itamerenkatu 11-13
Helsinki 00180
Finland
Phone: +358 7180 37686
Email: jari.urpalainen@nokia.com
Urpalainen Expires May 29, 2006 [Page 20]
Internet-Draft Patch Operations November 2005
Intellectual Property Statement
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.
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.
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Urpalainen Expires May 29, 2006 [Page 21]