One document matched: draft-wilde-xml-patch-10.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY files 'draft-wilde-xml-patch-10-files'>
]>
<?xml-stylesheet type="text/xsl" href="../../XIPr/xipr-1-0.xsl"?>
<!-- XIPr is used for XInclude processing; you can use any XInclude processor to include the files referenced from within this document. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="yes" ?>
<rfc category="info" ipr="trust200902" docName="draft-wilde-xml-patch-10" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="XML Patch">A Media Type for XML Patch Operations</title>
<author initials="E." surname="Wilde" fullname="Erik Wilde">
<organization>UC Berkeley</organization>
<address>
<email>dret@berkeley.edu</email>
<uri>http://dret.net/netdret/</uri>
</address>
</author>
<date day="10" month="June" year="2014"/>
<abstract>
<t>The XML Patch document format defines an XML document structure for expressing a sequence of patch operations to be applied to an XML document. The XML Patch document format builds on the foundations defined in RFC 5261. This specification also provides the media type registration "application/xml-patch+xml", to allow the use of XML Patch documents in, for example, HTTP conversations.</t>
</abstract>
<note title="Note to Readers">
<t>This draft should be discussed on the <eref target="https://www.ietf.org/mailman/listinfo/apps-discuss">apps-discuss mailing list</eref>.</t>
<t>Online access to all versions and files is available on <eref target="https://github.com/dret/I-D/tree/master/xml-patch">github</eref>.</t>
</note>
</front>
<middle>
<section title="Introduction" toc="default">
<t>The Extensible Markup Language (XML) <xref target="RFC3023" pageno="false" format="default"/> is a common format for the exchange and storage of structured data. HTTP PATCH <xref target="RFC5789" pageno="false" format="default"/> extends HTTP <xref target="RFC2616" pageno="false" format="default"/> with a method to perform partial modifications to resources. HTTP PATCH requires that patch documents be sent along with the request, and it is therefore useful for there to be standardized patch document formats (identified by media types) for popular media types.</t>
<t>The XML Patch media type "application/xml-patch+xml" is an XML document structure for expressing a sequence of operations to apply to a target XML document, suitable for use with the HTTP PATCH method. Servers can freely choose which patch formats they want to accept, and "application/xml-patch+xml" could be a simple default format that can be used unless a server decides to use a different (maybe more sophisticated) patch format for XML.</t>
<t>The format for patch documents is based on the XML Patch Framework defined in RFC 5261 <xref target="RFC5261" pageno="false" format="default"/>. While RFC 5261 does define a concrete syntax as well as the media type "application/patch-ops-error+xml" for error documents, it only defines XML Schema (XSD) <xref target="W3C.REC-xmlschema-1-20041028" pageno="false" format="default"/> types for patch operations. The concrete document format and the media type for patch operations are defined in an XSD defined in this specification.</t>
<t>This specification relies on RFC 5261, but also requires that the known errata are taken into account. The main reason for the errata 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 declaration attributes, while the patch model needs them to determine whether a namespace patch is allowed or not. <xref target="implementation-hints" pageno="false" format="default"/> contains more information about the general problem, and the errata themselves are available through the regular IETF errata system.</t>
</section>
<section title="Patch Documents" anchor="patch-documents" toc="default">
<t>The following section describe and illustrate the XML patch document format.</t>
<section title="Patch Document Format" anchor="schema" toc="default">
<t>The XML patch document format is based on a simple schema that uses a "patch" element as the document element, and allows an arbitrary sequence of "add", "remove", and "replace" elements as the children of the document element. These children follow the semantics defined in RFC 5261, which means that each element is treated as an individual patch operation, and the result of each patch operation is a patched XML document that is the target XML document for the next patch operation.</t>
<t>The following simple example patch document contains a single patch operation. This operation adds a new attribute called "new-attribute" to the document element of the target XML document. An XML patch document always uses a "patch" element in the "urn:ietf:rfc:XXXX" namespace as the document element, which then contains zero or more patch operation elements, which are also in the "urn:ietf:rfc:XXXX" namespace.</t>
<figure title="" align="left" alt="" width="" height="">
<artwork type="xml" xml:space="preserve" name="" align="left" alt="" width="" height=""><p:patch xmlns:p="urn:ietf:rfc:XXXX">
<p:add sel="*" type="@new-attribute">value</p:add>
</p:patch></artwork>
</figure>
<t>The following more complex example patch document uses the example from RFC 5261 section A.18 (but changing the example namespaces to example.com URIs); it uses the same "patch" element and XML namespace as shown in the simpler example. It shows the general structure of an XML patch document with multiple operations, as well as an example of each operation.</t>
<figure title="" align="left" alt="" width="" height="">
<artwork type="xml" xml:space="preserve" name="" align="left" alt="" width="" height=""><p:patch xmlns="http://example.com/ns1"
xmlns:y="http://example.com/ns2"
xmlns:p="urn:ietf:rfc:XXXX">
<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:patch></artwork>
</figure>
<t>As this example demonstrates, both the document element "patch" and the patch operation elements are in the same XML namespace. This is the result of RFC 5261 only defining types for the patch operation elements, which then can be reused in schemas to define concrete patch elements.</t>
<t>RFC 5261 defines an XML Schema (XSD) <xref target="W3C.REC-xmlschema-1-20041028" pageno="false" format="default"/> for the patch operation types. The following schema for the XML Patch media type is based on the types defined in RFC 5261, which are imported as "rfc5261.xsd" in the following schema. The schema defines a "patch" document element, and then allows an unlimited (and possibly empty) sequence of the "add", "remove", and "replace" operation elements, which are directly based on the respective types from the schema defined in RFC 5261.</t>
<figure title="" align="left" alt="" width="" height="">
<artwork type="xml" xml:space="preserve" name="" align="left" alt="" width="" height=""><xs:schema targetNamespace="urn:ietf:rfc:XXXX"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import schemaLocation="rfc5261.xsd"/>
<xs:element name="patch">
<xs:complexType>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="add" type="add"/>
<xs:element name="remove" type="remove"/>
<xs:element name="replace" type="replace"/>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:schema></artwork>
</figure>
</section>
<section title="Patch Examples" anchor="examples" toc="default">
<t>Since the semantics of the XML patch operations are defined by RFC 5261, please refer to the numerous examples in that specification for more XML patch document examples. All the examples in RFC 5261 can be taken as examples for the XML Patch media type, when looking at them with two minor changes in mind:</t>
<t>The two differences are that XML patch documents always use the "patch" element as the document element, and that both the "patch" element as well as the individual operation elements in XML patch documents have to be in the XML namespace with the URI "urn:ietf:rfc:XXXX".</t>
<t>For example, consider the patch example in RFC 5621 "Appendix A.1: Adding an Element". In this example, the patch is applied to the following XML document:</t>
<figure title="" align="left" alt="" width="" height="">
<artwork type="xml" xml:space="preserve" name="" align="left" alt="" width="" height=""><?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
</doc></artwork>
</figure>
<t>The patch example is based on the following patch document (with the element and namespace changes described above):</t>
<figure title="" align="left" alt="" width="" height="">
<artwork type="xml" xml:space="preserve" name="" align="left" alt="" width="" height=""><?xml version="1.0" encoding="UTF-8"?>
<p:patch xmlns:p="urn:ietf:rfc:XXXX">
<p:add sel="doc"><foo id="ert4773">This is a new child</foo></p:add>
</p:patch></artwork>
</figure>
<t>Applying the patch results in the following XML document:</t>
<figure title="" align="left" alt="" width="" height="">
<artwork type="xml" xml:space="preserve" name="" align="left" alt="" width="" height=""><?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<foo id="ert4773">This is a new child</foo></doc></artwork>
</figure>
</section>
</section>
<section title="IANA Considerations" anchor="iana" toc="default">
<t>The Internet media type <xref target="RFC6838" pageno="false" format="default"/> for an XML Patch Document is application/xml-patch+xml.</t>
<t>
<list>
<t>Type name: application</t>
<t>Subtype name: xml-patch+xml</t>
<t>Required parameters: none</t>
<t>Optional parameters:
<list>
<t>charset: Same as charset parameter for the media type "application/xml" as specified in RFC 3023 <xref target="RFC3023" pageno="false" format="default"/>.</t>
</list></t>
<t>Encoding considerations: Same as encoding considerations of media type "application/xml" as specified in RFC 3023 <xref target="RFC3023" pageno="false" format="default"/>.</t>
<t>Security considerations: This media type has all of the security considerations described in RFC 3023 <xref target="RFC3023" pageno="false" format="default"/>, RFC 5261 <xref target="RFC5261" pageno="false" format="default"/>, and RFC 3470 <xref target="RFC3470" pageno="false" format="default"/>, plus those listed in <xref target="security-considerations" pageno="false" format="default"/>.</t>
<t>Interoperability considerations: N/A</t>
<t>Published specification: RFC XXXX</t>
<t>Applications that use this media type: Applications that manipulate XML documents.</t>
<t>Additional information:
<list>
<t>Magic number(s): N/A</t>
<t>File extension(s): XML documents often use ".xml" as the file extension, and this media type does not propose a specific extension other than this generic one.</t>
<t>Macintosh file type code(s): TEXT</t>
</list>
</t>
<t>Person & email address to contact for further information: Erik Wilde <dret@berkeley.edu></t>
<t>Intended usage: COMMON</t>
<t>Restrictions on usage: none</t>
<t>Author: Erik Wilde <dret@berkeley.edu></t>
<t>Change controller: IETF</t>
</list>
</t>
</section>
<section title="Security Considerations" anchor="security-considerations" toc="default">
<t>The Security Considerations from RFC 5261 <xref target="RFC5261" pageno="false" format="default"/> apply to the application/xml-patch+xml media type.</t>
<t>In addition, 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.</t>
</section>
<section title="Change Log" anchor="change-log" toc="default">
<t>Note to RFC Editor: Please remove this section before publication.</t>
<section title="From -09 to -10" toc="default">
<t>
<list style="symbols">
<t>Fixed abstract.</t>
</list>
</t>
</section>
<section title="From -08 to -09" toc="default">
<t>
<list style="symbols">
<t>Editorial changes suggested by Tony Hansen.</t>
</list>
</t>
</section>
<section title="From -07 to -08" toc="default">
<t>
<list style="symbols">
<t>Updated author address.</t>
<t>Removed rfc/@updates (this draft no longer updates RFC 5261).</t>
<t>Added simple example of an XML patch document.</t>
<t>No more open issues, thus removed the "open issues" section.</t>
</list>
</t>
</section>
<section title="From -06 to -07" toc="default">
<t>
<list style="symbols">
<t>Moving category back to "info" (from "std"), because the errata to RFC 5261 are now approved separately.</t>
<t>Removing the section with "Updates to RFC 5261" because that's done via errata now.</t>
<t>Adding reference to RFC 3470 to "Security Considerations".</t>
<t>Updating the ABNF to correctly only allow lowercase characters in the string parts.</t>
</list>
</t>
</section>
<section title="From -05 to -06" toc="default">
<t>
<list style="symbols">
<t>Updating "Implementation Status" section to refer to RFC 6982 <xref target="RFC6982" pageno="false" format="default"/>.</t>
<t>Properly listing "charset" as an optional media type parameter (was ill-formatted before).</t>
<t>Adding corrections from Tony Hansen's review, including document structure (section/appendix order), and improvements of the ABNF grammar.</t>
<t>Moving category back to "std" (from "info"), because that's was needed for an RFC that is updating an RFC that has been published on the standards track.</t>
</list>
</t>
</section>
<section title="From -04 to -05" toc="default">
<t>
<list style="symbols">
<t>Improved formatting of XML/XSD and ABNF code.</t>
<t>Moving category from "std" to "info" (intended to become an informational RFC).</t>
</list>
</t>
</section>
<section title="From -03 to -04" toc="default">
<t>
<list style="symbols">
<t>Added text and section "Updates to RFC 5261" about updating RFC 5261 (instead of relying on errata).</t>
</list>
</t>
</section>
<section title="From -02 to -03" toc="default">
<t>
<list style="symbols">
<t>Added section on "Implementation Status" (<xref target="implementation-status" pageno="false" format="default"/>).</t>
<t>Improved "Implementation Hints" (<xref target="implementation-hints" pageno="false" format="default"/>).</t>
</list>
</t>
</section>
<section title="From -01 to -02" toc="default">
<t>
<list style="symbols">
<t>Textual edits.</t>
<t>Added section on "Implementation Hints" (<xref target="implementation-hints" pageno="false" format="default"/>).</t>
</list>
</t>
</section>
<section title="From -00 to -01" toc="default">
<t>
<list style="symbols">
<t>Removed Mark Nottingham from author list.</t>
<t>Changed media type name to application/xml-patch+xml (added suffix per draft-ietf-appsawg-media-type-suffix-regs)</t>
<t>Added ABNF grammar derived from XSD (<xref target="rfc5261-abnf" pageno="false" format="default"/>)</t>
</list>
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2045">
<front>
<title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
<author initials="N." surname="Freed" fullname="Ned Freed">
<organization>Innosoft International, Inc.</organization>
<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>
<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>
<author initials="N. S." surname="Borenstein" fullname="Nathaniel S. Borenstein">
<organization>First Virtual Holdings</organization>
<address>
<postal>
<street>25 Washington Avenue</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>
<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email>
</address>
</author>
<date month="November" year="1996"/>
</front>
<seriesInfo name="RFC" value="2045"/>
</reference>
<reference anchor="RFC2046">
<front>
<title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
<author initials="N." surname="Freed" fullname="Ned Freed">
<organization>Innosoft International, Inc.</organization>
<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country>
</postal>
<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email>
</address>
</author>
<author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
<organization>First Virtual Holdings</organization>
<address>
<postal>
<street>25 Washington Avenue</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country>
</postal>
<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email>
</address>
</author>
<date month="November" year="1996"/>
</front>
<seriesInfo name="RFC" value="2046"/>
</reference>
<reference anchor="RFC3023">
<front>
<title>XML Media Types</title>
<author initials="M." surname="Murata" fullname="M. Murata">
<organization/></author>
<author initials="S." surname="St. Laurent" fullname="S. St. Laurent">
<organization/></author>
<author initials="D." surname="Kohn" fullname="D. Kohn">
<organization/></author>
<date year="2001" month="January"/>
<abstract>
<t>This document standardizes five new media types - text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd - for use in exchanging network entities that are related to the Extensible Markup Language (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet Mail Extensions) entities. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="3023"/>
<format type="TXT" octets="86011" target="http://www.rfc-editor.org/rfc/rfc3023.txt"/>
</reference>
<reference anchor="RFC3470">
<front>
<title abbrev="XML Within IETF Protocols">Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols</title>
<author initials="S." surname="Hollenbeck" fullname="Scott Hollenbeck">
<organization>VeriSign, Inc.</organization>
<address>
<postal>
<street>21345 Ridgetop Circle</street>
<city>Dulles</city>
<region>VA</region>
<code>20166-6503</code>
<country>US</country></postal>
<phone>+1 703 948 3257</phone>
<email>shollenbeck@verisign.com</email>
</address>
</author>
<author initials="M." surname="Rose" fullname="Marshall T. Rose">
<organization>Dover Beach Consulting, Inc.</organization>
<address>
<postal>
<street>POB 255268</street>
<city>Sacramento</city>
<region>CA</region>
<code>95865-5268</code>
<country>US</country></postal>
<phone>+1 916 483 8878</phone>
<email>mrose@dbc.mtview.ca.us</email>
</address>
</author>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization>Adobe Systems Incorporated</organization>
<address>
<postal>
<street>Mail Stop W14</street>
<street>345 Park Ave.</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>US</country></postal>
<phone>+1 408 536 3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net</uri>
</address>
</author>
<date year="2003" day="23" month="January"/>
<area>General</area>
<keyword>BCP</keyword>
<keyword>Best Current Practice</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>The Extensible Markup Language (XML) is a framework for structuring data. While it evolved from Standard Generalized Markup Language (SGML) -- a markup language primarily focused on structuring documents -- XML has evolved to be a widely-used mechanism for representing structured data.</t>
<t>There are a wide variety of Internet protocols being developed; many have need for a representation for structured data relevant to their application. There has been much interest in the use of XML as a representation method. This document describes basic XML concepts, analyzes various alternatives in the use of XML, and provides guidelines for the use of XML within IETF standards-track protocols.</t></abstract>
<note title="Conventions Used In This Document">
<t>This document recommends, as policy, what specifications for Internet protocols -- and, in particular, IETF standards track protocol documents -- should include as normative language within them. The capitalized keywords "SHOULD", "MUST", "REQUIRED", etc. are used in the sense of how they would be used within other documents with the meanings as specified in BCP 14, RFC 2119 .</t></note></front>
<seriesInfo name="BCP" value="70"/>
<seriesInfo name="RFC" value="3470"/>
<format type="TXT" octets="64252" target="http://www.rfc-editor.org/rfc/rfc3470.txt"/>
<format type="HTML" octets="114435" target="http://xml.resource.org/public/rfc/html/rfc3470.html"/>
<format type="XML" octets="107496" target="http://xml.resource.org/public/rfc/xml/rfc3470.xml"/>
</reference>
<reference anchor="RFC6838">
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author initials="N." surname="Freed" fullname="N. Freed">
<organization/>
</author>
<author initials="J." surname="Klensin" fullname="J. Klensin">
<organization/>
</author>
<author initials="T." surname="Hansen" fullname="T. Hansen">
<organization/>
</author>
<date year="2013" month="January"/>
<abstract>
<t>This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="13"/>
<seriesInfo name="RFC" value="6838"/>
<format type="TXT" octets="72942" target="http://www.rfc-editor.org/rfc/rfc6838.txt"/>
</reference>
<reference anchor="RFC5261">
<front>
<title>An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors</title>
<author initials="J." surname="Urpalainen" fullname="J. Urpalainen">
<organization/>
</author>
<date year="2008" month="September"/>
<abstract>
<t>Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic &lt;add&gt;, &lt;replace&gt;, and &lt;remove&gt; directives a set of patches can then be applied to update an existing XML document. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5261"/>
<format type="TXT" octets="78036" target="http://www.rfc-editor.org/rfc/rfc5261.txt"/>
</reference>
<reference anchor="RFC5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials="D." surname="Crocker" fullname="D. Crocker">
<organization/>
</author>
<author initials="P." surname="Overell" fullname="P. Overell">
<organization/>
</author>
<date year="2008" month="January"/>
<abstract>
<t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<format type="TXT" octets="26359" target="http://www.rfc-editor.org/rfc/rfc5234.txt"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC2616">
<front>
<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="UC Irvine">Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email>
</address>
</author>
<author initials="J." surname="Gettys" fullname="James Gettys">
<organization abbrev="Compaq/W3C">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email>
</address>
</author>
<author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
<organization abbrev="Compaq">Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code></postal>
<email>mogul@wrl.dec.com</email>
</address>
</author>
<author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email>
</address>
</author>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization abbrev="Xerox">Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<email>masinter@parc.xerox.com</email>
</address>
</author>
<author initials="P." surname="Leach" fullname="Paul J. Leach">
<organization abbrev="Microsoft">Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code></postal>
<email>paulle@microsoft.com</email>
</address>
</author>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email>
</address>
</author>
<date year="1999" month="June"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.</t>
<t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2616"/>
<format type="TXT" octets="422317" target="http://www.rfc-editor.org/rfc/rfc2616.txt"/>
<format type="PS" octets="5529857" target="http://www.rfc-editor.org/rfc/rfc2616.ps"/>
<format type="PDF" octets="550558" target="http://www.rfc-editor.org/rfc/rfc2616.pdf"/>
<format type="HTML" octets="637302" target="http://xml.resource.org/public/rfc/html/rfc2616.html"/>
<format type="XML" octets="493420" target="http://xml.resource.org/public/rfc/xml/rfc2616.xml"/>
</reference>
<reference anchor="RFC5789">
<front>
<title>PATCH Method for HTTP</title>
<author initials="L." surname="Dusseault" fullname="L. Dusseault">
<organization/></author>
<author initials="J." surname="Snell" fullname="J. Snell">
<organization/></author>
<date year="2010" month="March"/>
<abstract>
<t>Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5789"/>
<format type="TXT" octets="21706" target="http://www.rfc-editor.org/rfc/rfc5789.txt"/>
</reference>
<reference anchor="W3C.REC-xml-names-20091208" target="http://www.w3.org/TR/2009/REC-xml-names-20091208">
<front>
<title>Namespaces in XML 1.0 (Third Edition)</title>
<author initials="D." surname="Hollander" fullname="Dave Hollander">
<organization/>
</author>
<author initials="A." surname="Layman" fullname="Andrew Layman">
<organization/>
</author>
<author initials="T." surname="Bray" fullname="Tim Bray">
<organization/>
</author>
<author initials="R." surname="Tobin" fullname="Richard Tobin">
<organization/>
</author>
<author initials="H." surname="Thompson" fullname="Henry S. Thompson">
<organization/>
</author>
<date month="December" day="8" year="2009"/>
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-names-20091208"/>
<format type="HTML" target="http://www.w3.org/TR/2009/REC-xml-names-20091208"/>
</reference>
<reference anchor="W3C.REC-xml-20081126" target="http://www.w3.org/TR/2008/REC-xml-20081126">
<front>
<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author initials="C." surname="Sperberg-McQueen" fullname="C. M. Sperberg-McQueen">
<organization/>
</author>
<author initials="F." surname="Yergeau" fullname="Francois Yergeau">
<organization/>
</author>
<author initials="J." surname="Paoli" fullname="Jean Paoli">
<organization/>
</author>
<author initials="E." surname="Maler" fullname="Eve Maler">
<organization/>
</author>
<author initials="T." surname="Bray" fullname="Tim Bray">
<organization/>
</author>
<date month="November" day="26" year="2008"/>
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-20081126"/>
<format type="HTML" target="http://www.w3.org/TR/2008/REC-xml-20081126"/>
</reference>
<reference anchor="W3C.REC-xpath-19991116" target="http://www.w3.org/TR/1999/REC-xpath-19991116">
<front>
<title>XML Path Language (XPath) Version 1.0</title>
<author initials="S." surname="DeRose" fullname="Steven DeRose">
<organization/>
</author>
<author initials="J." surname="Clark" fullname="James Clark">
<organization/>
</author>
<date month="November" day="16" year="1999"/>
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xpath-19991116"/>
<format type="HTML" target="http://www.w3.org/TR/1999/REC-xpath-19991116"/>
</reference>
<reference anchor="W3C.REC-xpath20-20101214" target="http://www.w3.org/TR/2010/REC-xpath20-20101214">
<front>
<title>XML Path Language (XPath) 2.0 (Second Edition)</title>
<author initials="S." surname="Boag" fullname="Scott Boag">
<organization/>
</author>
<author initials="A." surname="Berglund" fullname="Anders Berglund">
<organization/>
</author>
<author initials="M." surname="Kay" fullname="Michael Kay">
<organization/>
</author>
<author initials="J." surname="Simeon" fullname="Jerome Simeon">
<organization/>
</author>
<author initials="J." surname="Robie" fullname="Jonathan Robie">
<organization/>
</author>
<author initials="D." surname="Chamberlin" fullname="Don Chamberlin">
<organization/>
</author>
<author initials="M." surname="Fernandez" fullname="Mary F. Fernandez">
<organization/>
</author>
<date month="December" day="14" year="2010"/>
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xpath20-20101214"/>
<format type="HTML" target="http://www.w3.org/TR/2010/REC-xpath20-20101214"/>
</reference>
<reference anchor="W3C.REC-xmlschema-1-20041028" target="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028">
<front>
<title>XML Schema Part 1: Structures Second Edition</title>
<author initials="H." surname="Thompson" fullname="Henry S. Thompson">
<organization/>
</author>
<author initials="D." surname="Beech" fullname="David Beech">
<organization/>
</author>
<author initials="M." surname="Maloney" fullname="Murray Maloney">
<organization/>
</author>
<author initials="N." surname="Mendelsohn" fullname="Noah Mendelsohn">
<organization/>
</author>
<date month="October" day="28" year="2004"/>
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xmlschema-1-20041028"/>
<format type="HTML" target="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028"/>
</reference>
<reference anchor="W3C.REC-DOM-Level-3-Core-20040407" target="http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407">
<front>
<title>Document Object Model (DOM) Level 3 Core Specification</title>
<author initials="J." surname="Robie" fullname="Jonathan Robie">
<organization/>
</author>
<author initials="L." surname="Wood" fullname="Lauren Wood">
<organization/>
</author>
<author initials="M." surname="Champion" fullname="Mike Champion">
<organization/>
</author>
<author initials="P." surname="Hegaret" fullname="Philippe Le Hegaret">
<organization/>
</author>
<author initials="G." surname="Nicol" fullname="Gavin Nicol">
<organization/>
</author>
<author initials="A." surname="Le Hors" fullname="Arnaud Le Hors">
<organization/>
</author>
<author initials="S." surname="Byrne" fullname="Steve Byrne">
<organization/>
</author>
<date month="April" day="7" year="2004"/>
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-DOM-Level-3-Core-20040407"/>
<format type="HTML" target="http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407"/>
</reference>
<reference anchor="RFC6982">
<front>
<title>Improving Awareness of Running Code: The Implementation Status Section</title>
<author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
<organization/></author>
<author initials="A." surname="Farrel" fullname="A. Farrel">
<organization/></author>
<date year="2013" month="July"/>
<abstract>
<t>This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. The process in this document is offered as an experiment. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6982"/>
<format type="TXT" octets="19358" target="http://www.rfc-editor.org/rfc/rfc6982.txt"/>
</reference>
</references>
<section title="Implementation Hints" anchor="implementation-hints" toc="default">
<t>This section is informative. It describes some issues that might be interesting for implementers, but it might also be interesting for users of XML Patch that want to understand some of the differences between standard XPath 1.0 processing, and the processing model of selectors in RFC 5261.</t>
<t>Specifically, the issues described in the following two sections have been identified as technical issues with RFC 5261, and have been filed as errata. Implementers interested in implementing XML Patch are encouraged to take those errata into account when implementing XML patch documents. The issue about "Matching Namespaces" described in <xref target="namespace-matching" pageno="false" format="default"/> has been filed as RFC erratum 3477. The issue about "Patching Namespaces" described in <xref target="namespace-patching" pageno="false" format="default"/> has been filed as RFC erratum 3478.</t>
<section title="Matching Namespaces" anchor="namespace-matching" toc="default">
<t>RFC 5261 defines standard rules for matching prefixed names in expressions: Any prefixes are interpreted according to the namespace bindings of the diff document (the document that the expression is applied against). This means that each prefixed name can be interpreted in the context of the diff document.</t>
<t>For unprefixed names in expressions, the rules depart from XPath 1.0 <xref target="W3C.REC-xpath-19991116" pageno="false" format="default"/>. XPath 1.0 defines that unprefixed names in expressions match namespace-less names (i.e., there is no "default namespace" for names used in XPath 1.0 expressions). RFC 5261 requires, however, that unprefixed names in expressions must use the default namespace of the diff document (if there is one). This means that it is not possible to simply take a selector from a patch document and evaluate it in the context of the diff document according to the rules of XPath 1.0, because this would interpret unprefixed names incorrectly. As a consequence, it is not possible to simply take an XPath 1.0 processor and evaluate XML Patch selectors in the context of the diff document.</t>
<t>As an extension of XPath 1.0's simple model, XPath 2.0 <xref target="W3C.REC-xpath20-20101214" pageno="false" format="default"/> specifies different processing rules for unprefixed names: They are matched 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 applications, this can be set; XSLT 2.0 for example has the ability to define an "xpath-default-namespace", which then will be used to match unprefixed names in expressions. Thus, by using an XPath 2.0 implementation that allows to set this URI, and setting it to the 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-the-box XPath 2.0 implementation for evaluating XML Patch selectors.</t>
<t>Please keep in mind, however, that evaluating selectors is only one part of applying patches. When it comes to applying the actual patch operation, neither XPath 1.0 nor XPath 2.0 are sufficient because they do not preserve some of the information from the XML syntax (specifically: namespace declarations) that is required to correctly apply patch operations. The following section describes this issue in more detail.</t>
<t>Please note that RFC 5261's Section 4.2.2 on namespace matching explains XPath 2.0's rules incorrectly <eref target="http://tools.ietf.org/html/rfc5261#section-4.2.2"/>. For this reason, RFC erratum 3477 is available for Section 4.2.2 of RFC 5261.</t>
</section>
<section title="Patching Namespaces" anchor="namespace-patching" toc="default">
<t>One of the issues when patching namespaces based on XPath is that XPath exposes namespaces differently than the XML 1.0 <xref target="W3C.REC-xml-20081126" pageno="false" format="default"/> syntax for XML Namespaces <xref target="W3C.REC-xml-names-20091208" pageno="false" format="default"/>. In the XML syntax, a namespace is declared with an attribute using the reserved name or prefix "xmlns", and this results in this namespace being available recursively through the document tree. In XPath, the namespace declaration is not exposed as an attribute (i.e., the attribute, although syntactically an XML attribute, is not accessible in XPath), but the resulting namespace nodes are exposed recursively through the tree.</t>
<t>RFC 5261 uses the terms "namespace declaration" and "namespace" almost interchangeably, but it is important to keep in mind that the namespace declaration is an XML syntax construct that is unavailable in XPath, while the namespace itself is a logical construct that is not visible in the XML syntax, but a result of a namespace declaration. The intent of RFC 5261 is to patch namespaces as if namespace declarations were patched, and thus it only allows patching namespace nodes on the element nodes where the namespace has been declared.</t>
<t>Patching namespaces in XML Patch is supposed to "emulate" the effect of actually changing the namespace declaration (which is why a namespace can only be patched at the element where it has been declared). Therefore, when patching a namespace, even though XPath's "namespace" axis is used, implementations have to make sure that not only the single selected namespace node is being patched, but that all namespaces nodes resulting from the namespace declaration of this namespace are also patched accordingly.</t>
<t>This means that an implementation might have to descend into the tree, matching all namespace nodes with the selected prefix/URI pair recursively, until it encounters leaf elements or namespace declarations with the same prefix it is patching. Determining this requires access to the diff document beyond XPath, because in XPath itself namespace declarations are not represented, and thus such a recursive algorithm wouldn't know when to stop. Consider the following document:</t>
<figure title="" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><x xmlns:a="tag:42">
<y xmlns:a="tag:42"/>
</x></artwork>
</figure>
<t>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 the namespace node on element y has the same prefix/URI combination as the one on element x. However, determining that the repeated namespace declaration was present at all on element y is impossible when using XPath alone, which means that implementations must have an alternative way to determine the difference between the document above, and this one:</t>
<figure title="" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><x xmlns:a="tag:42">
<y/>
</x></artwork>
</figure>
<t>In this second example, patching with a selector of /x/namespace::a should indeed change the namespace nodes on elements x and y, because they both have been derived from the same namespace declaration.</t>
<t>The conclusion of these considerations is that for implementing XML Patch, access closer to the XML syntax (specifically: access to namespace declarations) is necessary. As a result, implementations attempting to exclusively use the XPath model for implementing XML Patch will fail to correctly address certain edge cases (such as the one shown above).</t>
<t>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) <xref target="W3C.REC-DOM-Level-3-Core-20040407" pageno="false" format="default"/>, 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.</t>
<t>Please note that RFC 5261's Section 4.4.3 on replacing namespaces mixes the terms "namespace declaration" and "namespace". For this reason, RFC erratum 3478 is available for Section 4.4.3 of RFC 5261.</t>
</section>
</section>
<section title="Implementation Status" anchor="implementation-status" toc="default">
<t>Note to RFC Editor: Please remove this section before publication.</t>
<t>This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 6982 <xref target="RFC6982" pageno="false" format="default"/>. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.</t>
<t>According to RFC 6982, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".</t>
<t>
<!--
RFC 6982: This section, if it appears, should be located just before the "Security Considerations" section and contain, for each existing implementation, some or all of the following:
- The organization responsible for the implementation, if any.
- The implementation's name and/or a link to a web page describing the implementation.
- A brief general description.
- The implementation's level of maturity: research, prototype, alpha, beta, production, widely used, etc.
- Coverage: which parts of the protocol specification are implemented and which versions of the Internet-Draft were implemented.
- Licensing: the terms under which the implementation can be used. For example: proprietary, royalty licensing, freely distributable with acknowledgement (BSD style), freely distributable with requirement to redistribute source (General Public License (GPL) style), and other (specify).
- Implementation experience: any useful information the implementers want to share with the community.
- Contact information: ideally a person's name and email address, but possibly just a URL or mailing list.
-->
<list>
<t>EMC: EMC's IIG unit has implemented the selector part of the specification, which is the trickiest part (see <xref target="namespace-matching" pageno="false" format="default"/> 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 <eref target="http://www.emc.com/products/detail/software2/documentum-xdb.htm"/>.</t>
</list>
</t>
</section>
<section title="ABNF for RFC 5261" anchor="rfc5261-abnf" toc="default">
<t>RFC 5261 <xref target="RFC5261" pageno="false" format="default"/> does not contain an ABNF grammar for the allowed subset of XPath expressions, but includes an XSD-based grammar in its type definition for operation types). In order to make implementation easier, this appendix contains an ABNF grammar that has been derived from the XSD expressions in RFC 5261. In the following grammar, "xpath" is the definition for the allowed XPath expressions for remove and replace operations, and "xpath-add" is the definition for the allowed XPath expressions for add operations. The names of all grammar productions are the ones used in the XSD-based grammar of RFC 5261.</t>
<figure title="" align="left" alt="" width="" height="">
<artwork type="abnf" xml:space="preserve" name="" align="left" alt="" width="" height="">anychar = %x00-ffffffff
ncname = 1*%x00-ffffffff
qname = [ ncname ":" ] ncname
aname = "@" qname
pos = "[" 1*DIGIT "]"
attr = ( "[" aname "='" 0*anychar "']" ) /
( "[" aname "=" DQUOTE 0*anychar DQUOTE "]" )
valueq = "[" ( qname / "." ) "=" DQUOTE 0*anychar DQUOTE "]"
value = ( "[" ( qname / "." ) "='" 0*anychar "']" ) / valueq
cond = attr / value / pos
step = ( qname / "*" ) 0*cond
piq = %x70.72.6f.63.65.73.73.69.6e.67.2d
%x69.6e.73.74.72.75.63.74.69.6f.6e
; "processing-instruction", case-sensitive
"(" [ DQUOTE ncname DQUOTE ] ")"
pi = ( %x70.72.6f.63.65.73.73.69.6e.67.2d
%x69.6e.73.74.72.75.63.74.69.6f.6e
; "processing-instruction", case-sensitive
"(" [ "'" ncname "'" ] ")" ) / piq
id = ( %x69.64 ; "id", case-sensitive
"(" [ "'" ncname "'" ] ")" ) /
( %x69.64 ; "id", case-sensitive
"(" [ DQUOTE ncname DQUOTE ] ")" )
com = %x63.6f.6d.6d.65.6e.74 ; "comment", case-sensitive
"()"
text = %x74.65.78.74 ; "text", case-sensitive
"()"
nspa = %x6e.61.6d.65.73.70.61.63.65 ; "namespace", case-sensitive
"::" ncname
cnodes = ( text / com / pi ) [ pos ]
child = cnodes / step
last = child / aname / nspa
xpath = [ "/" ] ( ( id [ 0*( "/" step ) "/" last ] ) /
( 0*( step "/" ) last ) )
xpath-add = [ "/" ] ( ( id [ 0*( "/" step ) "/" child ] ) /
( 0*( step "/" ) child ) )</artwork>
</figure>
<t>Please note that the "ncname" production listed above does not fully capture the constraints of the original XSD-based definition, where it is defined as "\i\c*". DIGIT and DQUOTE are defined by the ABNF specification <xref target="RFC5234" pageno="false" format="default"/>.</t>
</section>
<section title="Acknowledgements" toc="default">
<t>Thanks for comments and suggestions provided by Bas de Bakker, Tony Hansen, Bjoern Hoehrmann, and Julian Reschke.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:22:00 |