< draft-wilde-xml-patch-03.txt   draft-wilde-xml-patch-04.txt >
Network Working Group E. Wilde Network Working Group E. Wilde
Internet-Draft EMC Internet-Draft EMC
Intended status: Standards Track February 20, 2013 Updates: 5261 (if approved) February 21, 2013
Expires: August 24, 2013 Intended status: Standards Track
Expires: August 25, 2013
A Media Type for XML Patch Operations A Media Type for XML Patch Operations
draft-wilde-xml-patch-03 draft-wilde-xml-patch-04
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.
In addition to the media type registration, this specification also
updates RFC 5261 in some aspects, limiting these updates to cases
where RFC 5261 needed to be fixed, or was hard to understand.
Note to Readers Note to Readers
This draft should be discussed on the apps-discuss mailing list [14]. This draft should be discussed on the apps-discuss mailing list [14].
Online access to all versions and files is available on github [15]. 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.
skipping to change at page 1, line 42 skipping to change at page 1, line 47
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 24, 2013. This Internet-Draft will expire on August 25, 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
skipping to change at page 2, line 17 skipping to change at page 2, line 21
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. Patch Document Format . . . . . . . . . . . . . . . . . . . . 3 2. Patch Document Format . . . . . . . . . . . . . . . . . . . . 3
3. Patch Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Patch Examples . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Implementation Hints . . . . . . . . . . . . . . . . . . . . . 6
7. Implementation Hints . . . . . . . . . . . . . . . . . . . . . 6 6.1. Matching Namespaces . . . . . . . . . . . . . . . . . . . 6
7.1. Matching Namespaces . . . . . . . . . . . . . . . . . . . 7 6.2. Patching Namespaces . . . . . . . . . . . . . . . . . . . 7
7.2. Patching Namespaces . . . . . . . . . . . . . . . . . . . 8 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 9 8.1. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 10
8.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 9 8.2. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 10
8.3. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 10 8.3. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 10
8.4. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Non-Normative References . . . . . . . . . . . . . . . . . 10 9.2. Non-Normative References . . . . . . . . . . . . . . . . . 11
Appendix A. XSD from RFC 5261 . . . . . . . . . . . . . . . . . . 11 Appendix A. Updates to RFC 5261 . . . . . . . . . . . . . . . . . 12
Appendix B. ABNF for RFC 5261 . . . . . . . . . . . . . . . . . . 13 A.1. Section 4.2.2 . . . . . . . . . . . . . . . . . . . . . . 12
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 14 A.2. Section 4.4.3 . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 A.3. Section 8 . . . . . . . . . . . . . . . . . . . . . . . . 13
A.4. XSD for RFC 5261 . . . . . . . . . . . . . . . . . . . . . 14
A.5. ABNF for RFC 5261 . . . . . . . . . . . . . . . . . . . . 16
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
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.
Since RFC 5261 contains sections that need to be fixed, or are hard
to understand, this specification updates RFC 5261. The updates are
listed in Appendix A, and all references to RFC 5261 made in this
specification should be read as referring to the updated version.
The main reason for the changes are the problematic ways in which RFC
5261 relies on XPath as the expression language for selecting the
location of a patch, while at the same time XPath's data model does
not contain sufficient information to determine whether such a
selector indeed can be used for a patch operation, or should result
in an error. Specifically, the problem occurs with namespaces, where
XPath does not expose namespace decalration attributes, while the
patch model needs them to determine whether a namespace patch is
allowed or not. Section 6 contains more information about the
general problem, and Appendix A lists the resulting updates to RFC
5261 to make the model well-defined and the text easier to read and
understand.
2. Patch Document Format 2. 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 4, line 26 skipping to change at page 4, line 36
<p:add sel="*/elem[@a='bar']" type="@b">new attr</p:add> <p:add sel="*/elem[@a='bar']" type="@b">new attr</p:add>
</p:patch> </p:patch>
As this example demonstrates, both the document element "patch" and As this example demonstrates, both the document element "patch" and
the patch operation elements are in the same XML namespace. This is the patch operation elements are in the same XML namespace. This is
the result of RFC 5261 only defining types for the patch operation the result of RFC 5261 only defining types for the patch operation
elements, which then can be reused in schemas to define concrete elements, which then can be reused in schemas to define concrete
patch elements. patch elements.
RFC 5261 defines an XML Schema (XSD) [8] for the patch operation RFC 5261 defines an XML Schema (XSD) [8] for the patch operation
types, which is included for reference in Appendix A. The normative types, which is shown in Appendix A.4. The following schema for the
version of this schema is the one given in RFC 5261. The following XML Patch media type is based on the types defined in RFC 5261, which
schema for the XML Patch media type is based on the types defined in are imported as "rfc5261.xsd" in the following schema. The schema
RFC 5261, which are imported as "rfc5261.xsd" in the following defines a "patch" document element, and then allows an unlimited (and
schema. The schema defines a "patch" document element, and then possibly empty) sequence of the "add", "remove", and "replace"
allows an unlimited (and possibly empty) sequence of the "add", operation elements, which are directly based on the respective types
"remove", and "replace" operation elements, which are directly based from the schema defined in RFC 5261.
on the respective types from the schema defined in RFC 5261.
<xs:schema targetNamespace="urn:ietf:rfc:XXXX" <xs:schema targetNamespace="urn:ietf:rfc:XXXX"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:import schemaLocation="rfc5261.xsd"/> <xs:import schemaLocation="rfc5261.xsd"/>
<xs:element name="patch"> <xs:element name="patch">
<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>
skipping to change at page 5, line 28 skipping to change at page 5, line 47
Required parameters: none Required parameters: none
Optional parameters: Same as charset parameter for the media type Optional parameters: Same as charset parameter for the media type
"application/xml" as specified in RFC 3023 [1]. "application/xml" as specified in RFC 3023 [1].
Encoding considerations: Same as encoding considerations of media Encoding considerations: Same as encoding considerations of media
type "application/xml" as specified in RFC 3023 [1]. type "application/xml" as specified in RFC 3023 [1].
Security considerations: This media type has all of the security Security considerations: This media type has all of the security
considerations described in RFC 3023 [1] and RFC 5261 [2], plus considerations described in RFC 3023 [1] and RFC 5261 [2], plus
those listed in Section 6. those listed in Section 5.
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: RFC XXXX Published specification: RFC XXXX
Applications that use this media type: Applications that Applications that use this media type: Applications that
manipulate XML documents. manipulate XML documents.
Additional information: Additional information:
Magic number(s): N/A Magic number(s): N/A
File extension(s): XML documents should use ".xml" as the file File extension(s): XML documents should use ".xml" as the file
skipping to change at page 6, line 4 skipping to change at page 6, line 22
File extension(s): XML documents should use ".xml" as the file File extension(s): XML documents should use ".xml" as the file
extension. extension.
Macintosh file type code(s): TEXT Macintosh file type code(s): TEXT
Person & email address to contact for further information: Erik Person & email address to contact for further information: Erik
Wilde <erik.wilde@emc.com> Wilde <erik.wilde@emc.com>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author: Erik Wilde <erik.wilde@emc.com> Author: Erik Wilde <erik.wilde@emc.com>
Change controller: IETF Change controller: IETF
5. Implementation Status 5. Security Considerations
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 Parsing XML may entail including information from external sources
through XML's mechanism of external entities. Implementations through XML's mechanism of external entities. Implementations
therefore should be aware of the fact that standard parsers may therefore should be aware of the fact that standard parsers may
resolve external entities, and thus include external information as a resolve external entities, and thus include external information as a
result of applying patch operations to an XML document. result of applying patch operations to an XML document.
7. Implementation Hints 6. 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 implementers, 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
selectors in RFC 5261. selectors in RFC 5261.
7.1. Matching Namespaces 6.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 7, line 46 skipping to change at page 7, line 40
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
operation, 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 Please note that RFC 5261's Section 4.2.2 on namespace matching
XPath 2.0's rules incorrectly explains 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>. For this reason,
been filed Appendix A.1 updates Section 4.2.2 of RFC 5261.
<http://www.rfc-editor.org/errata_search.php?rfc=5261&eid=3477>
which, upon verification, will be linked to from here. ]]]
7.2. Patching Namespaces 6.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 resulting namespace attribute, is not accessible in XPath), but the resulting namespace
nodes are exposed recursively through the tree. nodes are exposed recursively through the tree.
skipping to change at page 9, line 29 skipping to change at page 9, line 22
Patch will fail to correctly address certain edge cases (such as the Patch will fail to correctly address certain edge cases (such as the
one shown above). one shown above).
Note that XPath's specific limitations do not mean that it is Note that XPath's specific limitations do not mean that it is
impossible to use XML technologies other than XPath. The Document impossible to use XML technologies other than XPath. The Document
Object Model (DOM) [13], for example, does expose namespace Object Model (DOM) [13], for example, does expose namespace
declaration attributes as regular attributes in the document tree, declaration attributes as regular attributes in the document tree,
and thus could be used to differentiate between the two variants and thus could be used to differentiate between the two variants
shown above. shown above.
[[[ Currently, RFC 5261's section on replacing namespaces mixes the Please note that RFC 5261's Section 4.4.3 on replacing namespaces
terms "namespace declaration" and "namespace" mixes the terms "namespace declaration" and "namespace". For this
<http://tools.ietf.org/html/rfc5261#section-4.4.3>. An erratum has reason, Appendix A.2 updates Section 4.4.3 of RFC 5261.
been filed <http://www.rfc-editor.org/errata_search.php?eid=3478>
which, upon verification, will be linked to from here. ]]] 7. 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 6.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>.
8. 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.
8.1. From -02 to -03 8.1. From -03 to -04
o Added section on "Implementation Status" (Section 5). o Added text and section Appendix A about updating RFC 5261 (instead
of relying on errata).
o Improved "Implementation Hints" (Section 7). 8.2. From -02 to -03
8.2. From -01 to -02 o Added section on "Implementation Status" (Section 7).
o Improved "Implementation Hints" (Section 6).
8.3. From -01 to -02
o Textual edits. o Textual edits.
o Added section on "Implementation Hints" (Section 7). o Added section on "Implementation Hints" (Section 6).
8.3. From -00 to -01 8.4. 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 A.5)
9. References 9. References
9.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)
skipping to change at page 11, line 39 skipping to change at page 12, line 11
Core Specification", World Wide Web Consortium Core Specification", World Wide Web Consortium
Recommendation REC-DOM-Level-3-Core-20040407, April 2004, Recommendation REC-DOM-Level-3-Core-20040407, April 2004,
<http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407>. <http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407>.
URIs URIs
[14] <https://www.ietf.org/mailman/listinfo/apps-discuss> [14] <https://www.ietf.org/mailman/listinfo/apps-discuss>
[15] <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. Updates to RFC 5261
For reference, this section contains a copy of the XML Schema (XSD) This section is normative. It contains a list of updates to RFC 5261
[8] defining the add, replace, and remove types in RFC 5261 [2]. [2]. These updates are limited to cases where RFC 5261 needed to be
This section is informational only, and the definitive version of the fixed, or was hard to understand.
schema is the one listed in RFC 5261.
A.1. Section 4.2.2
Section 4.2.2 of RFC 5261 [2] says:
In XPath 2.0, a "bar" selector not only matches an unqualified
<bar> element, but also matches a qualified <bar> element that is
in scope of a default namespace declaration. In contrast, in this
specification, a selector without a prefix only matches one
element, and it may match an element with or without a prefix but
only if the namespace it's qualified with (or none) is an exact
match.
It should say:
In XPath 2.0, a "bar" selector matches elements that have the URI
of the "default element/type namespace", which is part of an
XPath's static context. By setting this URI to the default
namespace of the diff document (or leave it empty, if there is
none), XPath 2.0's behavior matches the requirements of the
previous section.
Explanation: The original text is not easy to understand, but seems
to assume that an unprefixed name in XPath 2.0 matches both
unprefixed names, and prefixed ones that have the same namespace as
the default namespace of the XPath static context. This is not the
case: Matching depends on how the "default element/type namespace" of
the XPath static context is defined, and then matches either
namespace-less elements, or those in the "default element/type
namespace", but never both. This context, however, is defined by the
XPath itself, not by the document. Thus, it can be set externally
and could be set to the diff document's default namespace (if there
is one). In that case, XPath 2.0 can be used to evaluate XML Patch
selectors.
A.2. Section 4.4.3
Section 4.4.3 of RFC 5261 [2] says:
4.4.3. Replacing a Namespace Declaration URI
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.
It should say:
4.4.3. Replacing a Namespace URI
An example for a replacement of a namespace URI: <replace
sel="doc/namespace::pref">urn:new:xxx</replace> This will replace
the URI of the namespace associated with the 'pref' prefix with
"urn:new:xxx". The parent node of the namespace declaration MUST
be the <doc> element, otherwise an error occurs. Replacing the
namespace at the element where it is declared MUST also change all
namespace nodes derived from this declaration in descendant
elements.
Explanation: The spec uses the terms "namespace declaration" and
"namespace" almost interchangeably, which is incorrect. It is
impossible to select namespace declarations using XPath. When
selecting and replacing a namespace, then it should be taken into
account that its associated namespace declaration very likely has
resulted in numerous namespace nodes, attached to child elements of
the element where the namespace was declared. It is likely that RFC
5261 intended to specify a "recursive replace" of the resulting
namespace nodes of a namespace declaration, and this is what the
corrected text suggests. The original text is mixing terminology,
hard to read, and ambiguous in its meaning.
Side note: If the original text indeed tried to specify that really
only this one namespace node should be changed, then this could lead
to rather strange effects in the resulting document, since the XPath
tree now would have "orphan" namespace nodes, which then would need
to be serialized, and there would be resulting namespace declarations
in locations where previously no namespace declarations occurred.
A.3. Section 8
Section 8 of RFC 5261 [2] says:
<!ENTITY id "id\(('&ncname;')?\)|id\((&quot;&ncname;&quot;)?\)">
It should say:
<!ENTITY id "id\('&ncname;'\)|id\(&quot;&ncname;&quot;\)">
Explanation: The regex in the XSD suggests that "id()" would be a
valid selector for a patch, but it would not make sense to specify
such a selector, since it never would select a node (there's no
identifier to locate in the document). This means that while "id()"
is a valid XPath expression, it should not be allowed as a selector
expression within an XML patch document.
A.4. XSD for RFC 5261
This section contains a modified copy of the XML Schema (XSD) [8]
defining the add, replace, and remove types in RFC 5261 [2]. The
modification is based on the grammar change made in Appendix A.3.
<?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*">
<!ENTITY qname "(&ncname;:)?&ncname;"> <!ENTITY qname "(&ncname;:)?&ncname;">
<!ENTITY aname "@&qname;"> <!ENTITY aname "@&qname;">
<!ENTITY pos "\[\d+\]"> <!ENTITY pos "\[\d+\]">
<!ENTITY attr "\[&aname;='(.)*'\]|\[&aname;=&quot;(.)*&quot;\]"> <!ENTITY attr "\[&aname;='(.)*'\]|\[&aname;=&quot;(.)*&quot;\]">
<!ENTITY valueq "\[(&qname;|\.)=&quot;(.)*&quot;\]"> <!ENTITY valueq "\[(&qname;|\.)=&quot;(.)*&quot;\]">
<!ENTITY value "\[(&qname;|\.)='(.)*'\]|&valueq;"> <!ENTITY value "\[(&qname;|\.)='(.)*'\]|&valueq;">
<!ENTITY cond "&attr;|&value;|&pos;"> <!ENTITY cond "&attr;|&value;|&pos;">
<!ENTITY step "(&qname;|\*)(&cond;)*"> <!ENTITY step "(&qname;|\*)(&cond;)*">
<!ENTITY piq "processing-instruction\((&quot;&ncname;&quot;)\)"> <!ENTITY piq "processing-instruction\((&quot;&ncname;&quot;)\)">
<!ENTITY pi "processing-instruction\(('&ncname;')?\)|&piq;"> <!ENTITY pi "processing-instruction\(('&ncname;')?\)|&piq;">
<!ENTITY id "id\(('&ncname;')?\)|id\((&quot;&ncname;&quot;)?\)"> <!ENTITY id "id\('&ncname;'\)|id\(&quot;&ncname;&quot;\)">
<!ENTITY com "comment\(\)"> <!ENTITY com "comment\(\)">
<!ENTITY text "text\(\)"> <!ENTITY text "text\(\)">
<!ENTITY nspa "namespace::&ncname;"> <!ENTITY nspa "namespace::&ncname;">
<!ENTITY cnodes "(&text;(&pos;)?)|(&com;(&pos;)?)|((&pi;)(&pos;)?)"> <!ENTITY cnodes "(&text;(&pos;)?)|(&com;(&pos;)?)|((&pi;)(&pos;)?)">
<!ENTITY child "&cnodes;|&step;"> <!ENTITY child "&cnodes;|&step;">
<!ENTITY last "(&child;|&aname;|&nspa;)"> <!ENTITY last "(&child;|&aname;|&nspa;)">
]> ]>
<xsd:schema <xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"> elementFormDefault="qualified">
skipping to change at page 13, line 44 skipping to change at page 16, line 22
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:complexType name="remove"> <xsd:complexType name="remove">
<xsd:attribute name="sel" type="xpath" use="required"/> <xsd:attribute name="sel" type="xpath" use="required"/>
<xsd:attribute name="ws" type="ws"/> <xsd:attribute name="ws" type="ws"/>
</xsd:complexType> </xsd:complexType>
</xsd:schema> </xsd:schema>
Appendix B. ABNF for RFC 5261 A.5. ABNF for RFC 5261
RFC 5261 [2] does not contain an ABNF grammar for the allowed subset RFC 5261 [2] does not contain an ABNF grammar for the allowed subset
of XPath expressions, but includes an XSD-based grammar in its type of XPath expressions, but includes an XSD-based grammar in its type
definition for operation types (which is shown in Appendix A). In definition for operation types (which is shown in Appendix A.4). In
order to make implementation easier, this appendix contains an ABNF order to make implementation easier, this appendix contains an ABNF
grammar that has been derived from the XSD expressions given in RFC grammar that has been derived from the XSD expressions given in
5261. In the following grammar, "xpath" is the definition for the Appendix A.4. In the following grammar, "xpath" is the definition
allowed XPath expressions for remove and replace operations, and for the allowed XPath expressions for remove and replace operations,
"xpath-add" is the definition for the allowed XPath expressions for and "xpath-add" is the definition for the allowed XPath expressions
add operations. The names of all grammar productions are the ones for add operations. The names of all grammar productions are the
used in the XSD-based grammar of RFC 5261. ones used in the XSD-based grammar of RFC 5261.
ncname = 1*%x00-ffffffff ncname = 1*%x00-ffffffff
qname = [ ncname ":" ] ncname qname = [ ncname ":" ] ncname
aname = "@" qname aname = "@" qname
pos = "[" 1*DIGIT "]" pos = "[" 1*DIGIT "]"
attr = ( "[" aname "='" 1*%x00-ffffffff "']" ) / ( "[" aname "=" DQUOTE 1*%x00-ffffffff DQUOTE "]" ) attr = ( "[" aname "='" 1*%x00-ffffffff "']" ) / ( "[" aname "=" DQUOTE 1*%x00-ffffffff DQUOTE "]" )
valueq = "[" ( qname / "." ) "=" DQUOTE 1*%x00-ffffffff DQUOTE "]" valueq = "[" ( qname / "." ) "=" DQUOTE 1*%x00-ffffffff DQUOTE "]"
value = ( "[" ( qname / "." ) "='" 1*%x00-ffffffff "']" ) / valueq value = ( "[" ( qname / "." ) "='" 1*%x00-ffffffff "']" ) / valueq
cond = attr / value / pos cond = attr / value / pos
step = ( qname / "*" ) 0*( cond ) step = ( qname / "*" ) 0*( cond )
piq = "processing-instruction(" [ DQUOTE ncname DQUOTE ] ")" piq = "processing-instruction(" [ DQUOTE ncname DQUOTE ] ")"
skipping to change at page 14, line 30 skipping to change at page 17, line 26
id = ( "id(" [ "'" ncname "'" ] ")" ) / ( "id(" [ DQUOTE ncname DQUOTE ] ")" ) id = ( "id(" [ "'" ncname "'" ] ")" ) / ( "id(" [ DQUOTE ncname DQUOTE ] ")" )
com = "comment()" com = "comment()"
text = "text()" text = "text()"
nspa = "namespace::" ncname nspa = "namespace::" ncname
cnodes = ( text / com / pi ) [ pos ] cnodes = ( text / com / pi ) [ pos ]
child = cnodes / step child = cnodes / step
last = child / aname / nspa last = child / aname / nspa
xpath = [ "/" ] ( ( id [ 0*( "/" step ) "/" last ] ) / ( 0*( step "/" ) last ) ) xpath = [ "/" ] ( ( id [ 0*( "/" step ) "/" last ] ) / ( 0*( step "/" ) last ) )
xpath-add = [ "/" ] ( ( id [ 0*( "/" step ) "/" child ] ) / ( 0*( step "/" ) child ) ) xpath-add = [ "/" ] ( ( id [ 0*( "/" step ) "/" child ] ) / ( 0*( step "/" ) child ) )
Appendix C. Acknowledgements Appendix B. Acknowledgements
Thanks for comments and suggestions provided by Bas de Bakker. Thanks for comments and suggestions provided by Bas de Bakker.
Author's Address Author's Address
Erik Wilde Erik Wilde
EMC EMC
Email: erik.wilde@emc.com Email: erik.wilde@emc.com
 End of changes. 33 change blocks. 
91 lines changed or deleted 219 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/