< draft-wilde-xml-patch-02.txt   draft-wilde-xml-patch-03.txt >
Network Working Group E. Wilde Network Working Group E. Wilde
Internet-Draft EMC Internet-Draft EMC
Intended status: Standards Track February 8, 2013 Intended status: Standards Track February 20, 2013
Expires: August 12, 2013 Expires: August 24, 2013
A Media Type for XML Patch Operations A Media Type for XML Patch Operations
draft-wilde-xml-patch-02 draft-wilde-xml-patch-03
Abstract Abstract
The XML Patch media type "application/xml-patch+xml" defines an XML The XML Patch media type "application/xml-patch+xml" defines an XML
document structure for expressing a sequence of patch operations that document structure for expressing a sequence of patch operations that
are applied to an XML document. The XML Patch document format's are applied to an XML document. The XML Patch document format's
foundations are defined in RFC 5261, this specification defines a foundations are defined in RFC 5261, this specification defines a
document format and a media type registration, so that XML Patch document format and a media type registration, so that XML Patch
documents can be labeled with a media type, for example in HTTP documents can be labeled with a media type, for example in HTTP
conversations. conversations.
Note to Readers Note to Readers
This draft should be discussed on the apps-discuss mailing list [13]. This draft should be discussed on the apps-discuss mailing list [14].
Online access to all versions and files is available at github [14]. Online access to all versions and files is available on github [15].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 12, 2013. This Internet-Draft will expire on August 24, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 2. Patch Document Format . . . . . . . . . . . . . . . . . . . . 3
3. Patch Document Format . . . . . . . . . . . . . . . . . . . . 4 3. Patch Examples . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Patch Examples . . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6
6. Implementation Hints . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6.1. Namespace Matching Rules . . . . . . . . . . . . . . . . . 6 7. Implementation Hints . . . . . . . . . . . . . . . . . . . . . 6
6.2. Patching Namespaces . . . . . . . . . . . . . . . . . . . 7 7.1. Matching Namespaces . . . . . . . . . . . . . . . . . . . 7
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.2. Patching Namespaces . . . . . . . . . . . . . . . . . . . 8
7.1. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 9 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 9 8.1. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.3. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 10
8.2. Non-Normative References . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. XSD from RFC 5261 . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
Appendix B. ABNF for RFC 5261 . . . . . . . . . . . . . . . . . . 12 9.2. Non-Normative References . . . . . . . . . . . . . . . . . 10
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Appendix A. XSD from RFC 5261 . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Appendix B. ABNF for RFC 5261 . . . . . . . . . . . . . . . . . . 13
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Extensible Markup Language (XML) [1] is a common format for the The Extensible Markup Language (XML) [1] is a common format for the
exchange and storage of structured data. HTTP PATCH [6] extends HTTP exchange and storage of structured data. HTTP PATCH [6] extends HTTP
[7] with a method to perform partial modifications to resources. [7] with a method to perform partial modifications to resources.
HTTP PATCH requires that patch documents are being sent along with HTTP PATCH requires that patch documents are being sent along with
the request, and it is therefore useful if there are standardized the request, and it is therefore useful if there are standardized
patch document formats (identified by media types) for popular media patch document formats (identified by media types) for popular media
types. types.
skipping to change at page 3, line 31 skipping to change at page 3, line 31
(maybe more sophisticated) patch format for XML. (maybe more sophisticated) patch format for XML.
The format for patch documents is based on the XML Patch Framework The format for patch documents is based on the XML Patch Framework
defined in RFC 5261 [2]. While RFC 5261 does define a concrete defined in RFC 5261 [2]. While RFC 5261 does define a concrete
syntax as well as the media type "application/patch-ops-error+xml" syntax as well as the media type "application/patch-ops-error+xml"
for error documents, it only defines XML Schema (XSD) [8] types for for error documents, it only defines XML Schema (XSD) [8] types for
patch operations, and thus the concrete document format and the media patch operations, and thus the concrete document format and the media
type for patch operations are defined in an XSD defined in this type for patch operations are defined in an XSD defined in this
specification. specification.
2. IANA Considerations 2. Patch Document Format
The Internet media type [3] for an XML Patch Document is application/
xml-patch+xml.
Type name: application
Subtype name: xml-patch+xml
Required parameters: none
Optional parameters: Same as charset parameter for the media type
"application/xml" as specified in RFC 3023 [1].
Encoding considerations: Same as encoding considerations of media
type "application/xml" as specified in RFC 3023 [1].
Security considerations: This media type has all of the security
considerations described in RFC 3023 [1] and RFC 5261 [2], plus
those listed in Section 5.
Interoperability considerations: N/A
Published specification: RFC XXXX
Applications that use this media type: Applications that
manipulate XML documents.
Additional information:
Magic number(s): N/A
File extension(s): XML documents should use ".xml" as the file
extension.
Macintosh file type code(s): TEXT
Person & email address to contact for further information: Erik
Wilde <erik.wilde@emc.com>
Intended usage: COMMON
Restrictions on usage: none
Author: Erik Wilde <erik.wilde@emc.com>
Change controller: IETF
3. Patch Document Format
The XML patch document format is based on a simple schema that uses a The XML patch document format is based on a simple schema that uses a
"patch" element as the document element, and allows an arbitrary "patch" element as the document element, and allows an arbitrary
sequence of "add", "remove", and "replace" elements as the children sequence of "add", "remove", and "replace" elements as the children
of the document element. These children follow the semantics defined of the document element. These children follow the semantics defined
in RFC 5261, which means that each element is treated as an in RFC 5261, which means that each element is treated as an
individual patch operation, and the result of each patch operation is individual patch operation, and the result of each patch operation is
a patched XML document that is the target XML document for the next a patched XML document that is the target XML document for the next
patch operation. patch operation.
skipping to change at page 5, line 48 skipping to change at page 4, line 48
<xs:complexType> <xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="add" type="add"/> <xs:element name="add" type="add"/>
<xs:element name="remove" type="remove"/> <xs:element name="remove" type="remove"/>
<xs:element name="replace" type="replace"/> <xs:element name="replace" type="replace"/>
</xs:choice> </xs:choice>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
4. Patch Examples 3. Patch Examples
Since the semantics of the XML patch operations are defined by RFC Since the semantics of the XML patch operations are defined by RFC
5261, please refer to the numerous examples in that specification for 5261, please refer to the numerous examples in that specification for
concrete XML patch document examples. Most importantly, the examples concrete XML patch document examples. Most importantly, the examples
in RFC 5261 can be taken literally as examples for the XML Patch in RFC 5261 can be taken literally as examples for the XML Patch
media type, as long as it is assumed that the XML namespace for the media type, as long as it is assumed that the XML namespace for the
operation elements in these examples is the URI "urn:ietf:rfc:XXXX". operation elements in these examples is the URI "urn:ietf:rfc:XXXX".
5. Security Considerations 4. IANA Considerations
... The Internet media type [3] for an XML Patch Document is application/
xml-patch+xml.
6. Implementation Hints Type name: application
Subtype name: xml-patch+xml
Required parameters: none
Optional parameters: Same as charset parameter for the media type
"application/xml" as specified in RFC 3023 [1].
Encoding considerations: Same as encoding considerations of media
type "application/xml" as specified in RFC 3023 [1].
Security considerations: This media type has all of the security
considerations described in RFC 3023 [1] and RFC 5261 [2], plus
those listed in Section 6.
Interoperability considerations: N/A
Published specification: RFC XXXX
Applications that use this media type: Applications that
manipulate XML documents.
Additional information:
Magic number(s): N/A
File extension(s): XML documents should use ".xml" as the file
extension.
Macintosh file type code(s): TEXT
Person & email address to contact for further information: Erik
Wilde <erik.wilde@emc.com>
Intended usage: COMMON
Restrictions on usage: none
Author: Erik Wilde <erik.wilde@emc.com>
Change controller: IETF
5. Implementation Status
Note to RFC Editor: Please remove this section before publication.
As explained in a draft currently under development
<http://tools.ietf.org/html/draft-sheffer-running-code>, this section
contains information about implementation status, so that reviews of
the draft document can take implementation reports into account as
well. If you are implementing this draft, please contact this
draft's author. Any implementation status reports are intended for
draft publications only; the section will be removed when the draft
is published in RFC form.
EMC: We have implemented the selector part of the spec, which is
the trickiest part (see Section 7.1 for an explanation). By
reusing an existing XPath 1.0 implementation and changing it to
match the changed default namespace processing model, the required
behavior is fairly easy to implement. This does, however, require
that the implementation is available in source code, and also does
require some changes to the implementation's code. The resulting
implementation is closed source and will be made available, if
released, as part of EMC's XML database product xDB
<http://www.emc.com/products/detail/software2/documentum-xdb.htm>.
6. Security Considerations
Parsing XML may entail including information from external sources
through XML's mechanism of external entities. Implementations
therefore should be aware of the fact that standard parsers may
resolve external entities, and thus include external information as a
result of applying patch operations to an XML document.
7. Implementation Hints
This section is informative. It described some issues that might be This section is informative. It described some issues that might be
interesting for implementors, but it might also be interesting for interesting for implementers, but it might also be interesting for
users of XML Patch that want to understand some of the differences users of XML Patch that want to understand some of the differences
between standard XPath 1.0 processing, and the processing model of between standard XPath 1.0 processing, and the processing model of
RFC 5261. selectors in RFC 5261.
6.1. Namespace Matching Rules 7.1. Matching Namespaces
RFC 5261 defines standard rules for matching prefixed names in RFC 5261 defines standard rules for matching prefixed names in
expressions: Any prefixes are interpreted according to the namespace expressions: Any prefixes are interpreted according to the namespace
bindings of the diff document (the document that the expression is bindings of the diff document (the document that the expression is
applied against). This means that each prefixed name can be applied against). This means that each prefixed name can be
interpreted in the context of the diff document. interpreted in the context of the diff document.
For unprefixed names in expressions, the rules depart from XPath 1.0 For unprefixed names in expressions, the rules depart from XPath 1.0
[9]. XPath 1.0 defines that unprefixed names in expressions match [9]. XPath 1.0 defines that unprefixed names in expressions match
namespace-less names (i.e., there is no "default namespace" for names namespace-less names (i.e., there is no "default namespace" for names
skipping to change at page 6, line 46 skipping to change at page 7, line 30
the context of the diff document according to the rules of XPath 1.0, the context of the diff document according to the rules of XPath 1.0,
because this would interpret unprefixed names incorrectly. As a because this would interpret unprefixed names incorrectly. As a
consequence, it is not possible to simply take an XPath 1.0 processor consequence, it is not possible to simply take an XPath 1.0 processor
and evaluate XMPL Patch selectors in the context of the diff and evaluate XMPL Patch selectors in the context of the diff
document. document.
As an extension of XPath 1.0's simple model, XPath 2.0 [10] specifies As an extension of XPath 1.0's simple model, XPath 2.0 [10] specifies
different processing rules for unprefixed names: They are matched different processing rules for unprefixed names: They are matched
against the URI of the "default element/type namespace", which is against the URI of the "default element/type namespace", which is
defined as part of an expression's static context. In some XPath 2.0 defined as part of an expression's static context. In some XPath 2.0
applications this can be set; XSLT 2.0 for example has the ability to applications, this can be set; XSLT 2.0 for example has the ability
define an "xpath-default-namespace", which then will be used to match to define an "xpath-default-namespace", which then will be used to
unprefixed names in expressions. Thus, by using an XPath 2.0 match unprefixed names in expressions. Thus, by using an XPath 2.0
implementation that allows to set this URI, and setting it to the implementation that allows to set this URI, and setting it to the
default namespace of the diff document (or leaving it undefined if default namespace of the diff document (or leaving it undefined if
there is no such default namespace), it is possible to use an out-of- there is no such default namespace), it is possible to use an out-of-
the-box XPath 2.0 implementation for evaluating XML Patch selectors. the-box XPath 2.0 implementation for evaluating XML Patch selectors.
Please keep in mind, however, that evaluating selectors is only one Please keep in mind, however, that evaluating selectors is only one
part of applying patches. When it comes to applying the actual patch part of applying patches. When it comes to applying the actual patch
operations, neither XPath 1.0 nor XPath 2.0 are sufficient, because operation, neither XPath 1.0 nor XPath 2.0 are sufficient, because
they are not preserving some of the information from the XML syntax they are not preserving some of the information from the XML syntax
(specifically: namespace declarations) that is required to correctly (specifically: namespace declarations) that is required to correctly
apply patch operations. The following section described this issue apply patch operations. The following section described this issue
in more detail. in more detail.
[[[ Currently, RFC 5261's section on namespace matching explains [[[ Currently, RFC 5261's section on namespace matching explains
XPath 2.0's rules incorrectly XPath 2.0's rules incorrectly
<http://tools.ietf.org/html/rfc5261#section-4.2.2>. An erratum has <http://tools.ietf.org/html/rfc5261#section-4.2.2>. An erratum has
been filed been filed
<http://www.rfc-editor.org/errata_search.php?rfc=5261&eid=3477> <http://www.rfc-editor.org/errata_search.php?rfc=5261&eid=3477>
which, upon verification, will be linked to from here. ]]] which, upon verification, will be linked to from here. ]]]
6.2. Patching Namespaces 7.2. Patching Namespaces
One of the issues when patching namespaces based on XPath is that One of the issues when patching namespaces based on XPath is that
XPath exposes namespaces different than the XML 1.0 [11] syntax for XPath exposes namespaces different than the XML 1.0 [11] syntax for
XML Namespaces [12]. In the XML syntax, a namespace is declared with XML Namespaces [12]. In the XML syntax, a namespace is declared with
an attribute using the reserved name or prefix "xmlns", and this an attribute using the reserved name or prefix "xmlns", and this
results in this namespace being available recursively through the results in this namespace being available recursively through the
document tree. In XPath, the namespace declaration is not exposed as document tree. In XPath, the namespace declaration is not exposed as
an attribute (i.e., the attribute, although syntactically an XML an attribute (i.e., the attribute, although syntactically an XML
attribute, is not accessible in XPath), but the namespace nodes are attribute, is not accessible in XPath), but the resulting namespace
exposed recursively through the tree. nodes are exposed recursively through the tree.
RFC 5261 uses the terms "namespace declaration" and "namespace" RFC 5261 uses the terms "namespace declaration" and "namespace"
almost interchangeably, but it is important to keep in mind that the almost interchangeably, but it is important to keep in mind that the
namespace declaration is an XML syntax construct that is unavailable namespace declaration is an XML syntax construct that is unavailable
in XPath, while the namespace itself is a logical construct that is in XPath, while the namespace itself is a logical construct that is
not visible in the XML syntax, but a result of a namespace not visible in the XML syntax, but a result of a namespace
declaration. The intent of RFC 5261 is to patch namespaces as if declaration. The intent of RFC 5261 is to patch namespaces as if
namespace declarations were patched, and thus it only allows to patch namespace declarations were patched, and thus it only allows to patch
namespace nodes on the element nodes where the namespace has been namespace nodes on the element nodes where the namespace has been
declared. declared.
Patching namespaces in XML Patch is supposed to "emulate" the effect Patching namespaces in XML Patch is supposed to "emulate" the effect
of actually changing the namespace declaration (which is why a of actually changing the namespace declaration (which is why a
namespace can only be patched at the element where it has been namespace can only be patched at the element where it has been
declared). Therefore, when patching a namespace, even though XPath's declared). Therefore, when patching a namespace, even though XPath's
"namespace" axis is used, implementations have to make sure that not "namespace" axis is used, implementations have to make sure that not
only the one selected namespace node is being patched, but that all only the single selected namespace node is being patched, but that
namespaces nodes resulting from the namespace declaration of this all namespaces nodes resulting from the namespace declaration of this
namespace are patched accordingly. namespace are also patched accordingly.
This means that an implementation might have to descend into the This means that an implementation might have to descend into the
tree, matching all namespace nodes with the selected prefix/URI pair tree, matching all namespace nodes with the selected prefix/URI pair
recursively, until it encounters namespace declarations with the same recursively, until it encounters leaf elements or namespace
prefix it is patching. Determining this requires access to the diff declarations with the same prefix it is patching. Determining this
document beyond XPath, because in XPath itself namespace declarations requires access to the diff document beyond XPath, because in XPath
are not represented, and thus such a recursive algorithm wouldn't itself namespace declarations are not represented, and thus such a
know when to stop. Consider the following document: recursive algorithm wouldn't know when to stop. Consider the
following document:
<x xmlns:a="tag:42"> <x xmlns:a="tag:42">
<y xmlns:a="tag:42"/> <y xmlns:a="tag:42"/>
</x> </x>
If this document is patched with a selector of /x/namespace::a, then If this document is patched with a selector of /x/namespace::a, then
only the namespace node on element x should be patched, even though only the namespace node on element x should be patched, even though
the namespace node on element y has the same prefix/URI combination the namespace node on element y has the same prefix/URI combination
than the one on element x. Determining that the repeated namespace than the one on element x. However, determining that the repeated
declaration was present at all on element y is impossible when using namespace declaration was present at all on element y is impossible
XPath alone, so implementations must have an alternative way to when using XPath alone, which means that implementations must have an
determine the difference between the document above, and this one: alternative way to determine the difference between the document
above, and this one:
<x xmlns:a="tag:42"> <x xmlns:a="tag:42">
<y/> <y/>
</x> </x>
In this second example, patching with a selector of /x/namespace::a In this second example, patching with a selector of /x/namespace::a
should indeed change the namespace nodes on elements x and y, because should indeed change the namespace nodes on elements x and y, because
they both have been derived from the same namespace declaration. they both have been derived from the same namespace declaration.
The conclusion of these considerations is that for implementing XML The conclusion of these considerations is that for implementing XML
Patch, access to the XML syntax (specifically: namespace Patch, access closer to the XML syntax (specifically: access to
declarations) is necessary. As a result, implementations attempting namespace declarations) is necessary. As a result, implementations
to exclusively use the XPath model for implementing XML Patch will attempting to exclusively use the XPath model for implementing XML
fail to correctly address certain edge cases (as the one shown Patch will fail to correctly address certain edge cases (such as the
above). one shown above).
Note that XPath's specific limitations do not mean that it is
impossible to use XML technologies other than XPath. The Document
Object Model (DOM) [13], for example, does expose namespace
declaration attributes as regular attributes in the document tree,
and thus could be used to differentiate between the two variants
shown above.
[[[ Currently, RFC 5261's section on replacing namespaces mixes the [[[ Currently, RFC 5261's section on replacing namespaces mixes the
terms "namespace declaration" and "namespace" terms "namespace declaration" and "namespace"
<http://tools.ietf.org/html/rfc5261#section-4.4.3>. An erratum has <http://tools.ietf.org/html/rfc5261#section-4.4.3>. An erratum has
been filed <http://www.rfc-editor.org/errata_search.php?eid=3478> been filed <http://www.rfc-editor.org/errata_search.php?eid=3478>
which, upon verification, will be linked to from here. ]]] which, upon verification, will be linked to from here. ]]]
7. Change Log 8. Change Log
Note to RFC Editor: Please remove this section before publication. Note to RFC Editor: Please remove this section before publication.
7.1. From -01 to -02 8.1. From -02 to -03
o Added section on "Implementation Status" (Section 5).
o Improved "Implementation Hints" (Section 7).
8.2. From -01 to -02
o Textual edits. o Textual edits.
o Added section on "Implementation Hints" (Section 6). o Added section on "Implementation Hints" (Section 7).
7.2. From -00 to -01 8.3. From -00 to -01
o Removed Mark Nottingham from author list. o Removed Mark Nottingham from author list.
o Changed media type name to application/xml-patch+xml (added suffix o Changed media type name to application/xml-patch+xml (added suffix
per draft-ietf-appsawg-media-type-suffix-regs) per draft-ietf-appsawg-media-type-suffix-regs)
o Added ABNF grammar derived from XSD (Appendix B) o Added ABNF grammar derived from XSD (Appendix B)
8. References 9. References
8.1. Normative References 9.1. Normative References
[1] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", [1] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001. RFC 3023, January 2001.
[2] Urpalainen, J., "An Extensible Markup Language (XML) Patch [2] Urpalainen, J., "An Extensible Markup Language (XML) Patch
Operations Framework Utilizing XML Path Language (XPath) Operations Framework Utilizing XML Path Language (XPath)
Selectors", RFC 5261, September 2008. Selectors", RFC 5261, September 2008.
[3] Freed, N., Klensin, J., and T. Hansen, "Media Type [3] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC 6838, Specifications and Registration Procedures", BCP 13, RFC 6838,
January 2013. January 2013.
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996. RFC 2045, November 1996.
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
8.2. Non-Normative References 9.2. Non-Normative References
[6] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789, [6] Dusseault, L. and J. Snell, "PATCH Method for HTTP", RFC 5789,
March 2010. March 2010.
[7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[8] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML [8] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML
Schema Part 1: Structures Second Edition", World Wide Web Schema Part 1: Structures Second Edition", World Wide Web
skipping to change at page 10, line 33 skipping to change at page 11, line 27
Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)",
World Wide Web Consortium Recommendation REC-xml-20081126, World Wide Web Consortium Recommendation REC-xml-20081126,
November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>. November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
[12] Hollander, D., Layman, A., Bray, T., Tobin, R., and H. [12] Hollander, D., Layman, A., Bray, T., Tobin, R., and H.
Thompson, "Namespaces in XML 1.0 (Third Edition)", World Wide Thompson, "Namespaces in XML 1.0 (Third Edition)", World Wide
Web Consortium Recommendation REC-xml-names-20091208, Web Consortium Recommendation REC-xml-names-20091208,
December 2009, December 2009,
<http://www.w3.org/TR/2009/REC-xml-names-20091208>. <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[13] Robie, J., Wood, L., Champion, M., Hegaret, P., Nicol, G., Le
Hors, A., and S. Byrne, "Document Object Model (DOM) Level 3
Core Specification", World Wide Web Consortium
Recommendation REC-DOM-Level-3-Core-20040407, April 2004,
<http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407>.
URIs URIs
[13] <https://www.ietf.org/mailman/listinfo/apps-discuss> [14] <https://www.ietf.org/mailman/listinfo/apps-discuss>
[14] <https://github.com/dret/I-D/tree/master/xml-patch> [15] <https://github.com/dret/I-D/tree/master/xml-patch>
Appendix A. XSD from RFC 5261 Appendix A. XSD from RFC 5261
For reference, this section contains a copy of the XML Schema (XSD) For reference, this section contains a copy of the XML Schema (XSD)
[8] defining the add, replace, and remove types in RFC 5261 [2]. [8] defining the add, replace, and remove types in RFC 5261 [2].
This section is informational only, and the definitive version of the This section is informational only, and the definitive version of the
schema is the one listed in RFC 5261. schema is the one listed in RFC 5261.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE schema [ <!DOCTYPE schema [
<!ENTITY ncname "\i\c*"> <!ENTITY ncname "\i\c*">
 End of changes. 32 change blocks. 
112 lines changed or deleted 162 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/