Network Working GroupIndependent Submission E. WildeInternet-DraftRequest for Comments: 7351 UC BerkeleyIntended status:Category: InformationalJune 10, 2014 Expires: December 12,August 2014 ISSN: 2070-1721 A Media Type for XML Patch Operationsdraft-wilde-xml-patch-10Abstract The XMLPatchpatch document format defines an XML document structure for expressing a sequence of patch operations to be applied to an XML document. The XMLPatchpatch 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 XMLPatchpatch documents in, for example, HTTP conversations.Note to Readers This draft should be discussed on the apps-discuss mailing list [1]. Online access to all versions and files is available on github [2].Status ofthisThis Memo ThisInternet-Draftdocument issubmitted in full conformance withnot an Internet Standards Track specification; it is published for informational purposes. This is a contribution to theprovisionsRFC Series, independently ofBCP 78any other RFC stream. The RFC Editor has chosen to publish this document at its discretion andBCP 79. Internet-Draftsmakes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor areworking documentsnot a candidate for any level oftheInternetEngineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The listStandard; see Section 2 of RFC 5741. Information about the currentInternet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximumstatus ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 12, 2014.http://www.rfc-editor.org/info/rfc7351. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .. 32 2. Patch Documents . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Patch Document Format . . . . . . . . . . . . . . . . . .43 2.2. Patch Examples . . . . . . . . . . . . . . . . . . . . .. 54 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . .65 4. Security Considerations . . . . . . . . . . . . . . . . . . .76 5.Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. From -09 to -10 . . . . . . . . . . . . . . . . . . . . . 7 5.2. From -08 to -09 . . . . . . . . . . . . . . . . . . .Acknowledgements . .7 5.3. From -07 to -08 .. . . . . . . . . . . . . . . . . . . . 75.4. From -06 to -07 . . . . . . . . . . . . . . . . . . . . . 8 5.5. From -05 to -06 . . . . . . . . . . . . . . . . . . . . . 8 5.6. From -04 to -05 . . . . . . . . . . . . . . . . . . . . . 8 5.7. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 8 5.8. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 9 5.9. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 9 5.10. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 96. References . . . . . . . . . . . . . . . . . . . . . . . . .. 97 6.1. Normative References . . . . . . . . . . . . . . . . . .. 97 6.2. Informative References . . . . . . . . . . . . . . . . .. 107 Appendix A. Implementation Hints . . . . . . . . . . . . . . . .11 A.1. Matching Namespaces . . . . . . . . . . . . . . . . . . . 11 A.2. Patching Namespaces . . . . . . . . . . . . . . . . . . . 12 Appendix B. Implementation Status . . . . . . . . . . . . . . . . 14 Appendix C. ABNF for RFC 5261 . . . . . . . .9 A.1. Matching Namespaces . . . . . . . . . . .15 Appendix D. Acknowledgements. . . . . . . . 9 A.2. Patching Namespaces . . . . . . . . . .16 Author's Address. . . . . . . . . 10 Appendix B. ABNF for RFC 5261 . . . . . . . . . . . . . . . . .1712 1. Introduction The Extensible Markup Language (XML)[RFC3023][RFC7303] is a common format for the exchange and storage of structured data. HTTP PATCH [RFC5789] extends HTTP [RFC2616] 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. The XMLPatchpatch 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. The format for patch documents is based on the XMLPatch Frameworkpatch framework defined in RFC 5261 [RFC5261]. 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) [W3C.REC-xmlschema-1-20041028] types for patch operations. The concrete document format and the media type for patch operations are defined in an XSD defined in this specification. This specification relies on RFC5261,5261 but also requires thatthe knownerrata reported to date are taken into account. The main reason for the errataareis the problematic ways in which RFC 5261 relies onXPathXML Path Language (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 patchoperation,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 or not a namespace patch isallowed or not.allowed. Appendix A contains more information about the generalproblem,problem andtheerratathemselves are available through the regular IETF errata system.reports. 2. Patch Documents The followingsectionsections describe and illustrate the XML patch document format. 2.1. Patch Document Format The XML patch document format is based on a simple schema that uses a "patch" element as the documentelement,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. The following simple example patch document contains a single patch operation. This operation adds a new attribute called"new- attribute""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. <p:patch xmlns:p="urn:ietf:rfc:XXXX"> <p:add sel="*" type="@new-attribute">value</p:add> </p:patch> The following more complex example patch document uses the example from RFC5261 section5261, 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. <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> 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. RFC 5261 definesan XML Schema (XSD)XSD [W3C.REC-xmlschema-1-20041028] for the patch operation types. The following schema for the XMLPatchpatch 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. <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> 2.2. Patch Examples 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 XMLPatchpatch media type, when looking at them with two minor changes inmind:mind. The two differences are that XML patch documents always use the "patch" element as the documentelement,element and that both the "patch" elementas well asand the individual operation elements in XML patch documents have to be in the XML namespace with the URI "urn:ietf:rfc:XXXX". For example, consider the patch example in RFC5621 "Appendix A.1: Adding5261, Appendix A.1, "Adding an Element". In this example, the patch is applied to the following XML document: <?xml version="1.0" encoding="UTF-8"?> <doc> <note>This is a sample document</note> </doc> The patch example is based on the following patch document (with the element and namespace changes described above): <?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> Applying the patch results in the following XML document: <?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> 3. IANA Considerations The Internet media type [RFC6838] for an XMLPatch Documentpatch document is application/xml-patch+xml. Type name: application Subtype name: xml-patch+xml Required parameters: none Optional parameters: charset: Same as charset parameter for the media type "application/xml" as specified in RFC3023 [RFC3023].7303 [RFC7303]. Encoding considerations: Same as encoding considerations of media type "application/xml" as specified in RFC3023 [RFC3023].7303 [RFC7303]. Security considerations: This media type has all of the security considerations described in RFC3023 [RFC3023],7303 [RFC7303], RFC 5261 [RFC5261], and RFC 3470 [RFC3470], plus those listed in Section 4. Interoperability considerations: N/A Published specification: RFCXXXX7351 Applications that use this media type: Applications that manipulate XML documents. Additional information: Magic number(s): N/A 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. Macintosh file type code(s): TEXT Person & email address to contact for further information: Erik Wilde <dret@berkeley.edu> Intended usage: COMMON Restrictions on usage: none Author: Erik Wilde <dret@berkeley.edu> Change controller: IETF 4. Security Considerations TheSecurity Considerationssecurity considerations from RFC 5261 [RFC5261] apply to the application/xml-patch+xml media type. In addition, parsing XML may entail including information from external sources through XML's mechanism of external entities.Implementations thereforeImplementations, therefore, should be aware of the fact that standard parsers may resolve externalentities,entities and thus include external information as a result of applying patch operations to an XML document. 5.Change Log Note to RFC Editor: Please remove this section before publication. 5.1. From -09 to -10 o Fixed abstract. 5.2. From -08 to -09 o Editorial changes suggested by Tony Hansen. 5.3. From -07 to -08 o Updated author address. o Removed rfc/@updates (this draft no longer updates RFC 5261). o Added simple example of an XML patch document. o No more open issues, thus removed the "open issues" section. 5.4. From -06 to -07 o Moving category back to "info" (from "std"), because the errata to RFC 5261 are now approved separately. o Removing the section with "Updates to RFC 5261" because that's done via errata now. o Adding reference to RFC 3470 to "Security Considerations". o Updating the ABNF to correctly only allow lowercase characters in the string parts. 5.5. From -05 to -06 o Updating "Implementation Status" section to refer to RFC 6982 [RFC6982]. o Properly listing "charset" as an optional media type parameter (was ill-formatted before). o Adding corrections from Tony Hansen's review, including document structure (section/appendix order), and improvements of the ABNF grammar. o Moving category back to "std" (from "info"), because that's was neededAcknowledgements Thanks foran RFC that is updating an RFC that has been published on the standards track. 5.6. From -04 to -05 o Improved formatting of XML/XSDcomments andABNF code. o Moving category from "std" to "info" (intended to become an informational RFC). 5.7. From -03 to -04 o Added textsuggestions provided by Bas de Bakker, Tony Hansen, Bjoern Hoehrmann, andsection "Updates to RFC 5261" about updating RFC 5261 (instead of relying on errata). 5.8. From -02 to -03 o Added section on "Implementation Status" (Appendix B). o Improved "Implementation Hints" (Appendix A). 5.9. From -01 to -02 o Textual edits. o Added section on "Implementation Hints" (Appendix A). 5.10. From -00 to -01 o Removed Mark Nottingham from author list. o Changed media type name to application/xml-patch+xml (added suffix per draft-ietf-appsawg-media-type-suffix-regs) o Added ABNF grammar derived from XSD (Appendix C)Julian Reschke. 6. References 6.1. Normative References [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", RFC 5261, September 2008. [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013. [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, July 2014. 6.2. Informative References [Err3477] RFC Errata, "Errata ID 3477", RFC 5261, . [Err3478] RFC Errata, "Errata ID 3478", RFC 5261, . [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC5789] Dusseault, L. and J. Snell, "PATCH Method forHTTP", RFC 5789, March 2010. [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section",HTTP", RFC6982, July 2013.5789, March 2010. [W3C.REC-DOM-Level-3-Core-20040407] 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>. [W3C.REC-xml-20081126] Sperberg-McQueen, C., Yergeau, F., Paoli, J., Maler, E., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC- xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>. [W3C.REC-xml-names-20091208] Hollander, D., Layman, A., Bray, T., Tobin, R., and H. Thompson, "Namespaces in XML 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml-names-20091208, December 2009, <http://www.w3.org/TR/2009/REC-xml-names-20091208>. [W3C.REC-xmlschema-1-20041028] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. [W3C.REC-xpath-19991116] DeRose, S. and J. Clark, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>. [W3C.REC-xpath20-20101214] Boag, S., Berglund, A., Kay, M., Simeon, J., Robie, J., Chamberlin, D., and M. Fernandez, "XML Path Language (XPath) 2.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xpath20-20101214, December 2010, <http://www.w3.org/TR/2010/REC-xpath20-20101214>.URIs [1] <https://www.ietf.org/mailman/listinfo/apps-discuss> [2] <https://github.com/dret/I-D/tree/master/xml-patch>Appendix A. Implementation Hints This section is informative. It describes some issues that might be interesting for implementers, but it might also be interesting for users of XMLPatchpatch that want to understand some of the differences between standard XPath 1.0processing,processing and the processing model of selectors in RFC 5261. Specifically, the issues described in the following two sections have been identified as technical issues with RFC5261,5261 and have been filed as errata. Implementers interested inimplementingusing XMLPatchpatch are encouraged to take those errata into account when implementing XML patch documents. The issue about "Matching Namespaces" described in Appendix A.1 has been filed as RFCerratum 3477.Errata ID 3477 [Err3477]. The issue about "Patching Namespaces" described in Appendix A.2 has been filed as RFCerratum 3478.Errata ID 3478 [Err3478]. A.1. Matching Namespaces RFC 5261 defines standard rules for matching prefixed names in expressions:Anyany 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. For unprefixed names in expressions, the rules depart from XPath 1.0 [W3C.REC-xpath-19991116]. 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 XPath1.0,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 XMLPatchpatch selectors in the context of the diff document. As an extension of XPath 1.0's simple model, XPath 2.0 [W3C.REC-xpath20-20101214] specifies different processing rules for unprefixed names:Theythey 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.0XSL Transformations (XSLT) 2.0, forexampleexample, has the ability to define an"xpath-default- namespace","xpath-default-namespace", which then will be used to match unprefixed names in expressions. Thus, by using an XPath 2.0 implementation that allows one 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 anout-of-the-boxout-of- the-box XPath 2.0 implementation for evaluating XMLPatchpatch selectors. 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:(specifically namespace declarations) that is required to correctly apply patch operations. The following section describes this issue in more detail. Please note thatRFC 5261's[RFC5261], Section 4.2.2 on namespace matching explains XPath 2.0's rulesincorrectly <http://tools.ietf.org/html/rfc5261#section-4.2.2>.incorrectly. For this reason, RFCerratumErrata ID 3477 is available for Section 4.2.2 of RFC 5261. A.2. Patching Namespaces One of the issues when patching namespaces based on XPath is that XPath exposes namespaces differently than the XML 1.0 [W3C.REC-xml-20081126] syntax for XMLNamespacesnamespaces [W3C.REC-xml-names-20091208]. 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. 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 werepatched, and thuspatched; thus, it only allows patching namespace nodes on the element nodes where the namespace has been declared. Patching namespaces in XMLPatchpatch 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 beingpatched,patched but that all namespaces nodes resulting from the namespace declaration of this namespace are also patched accordingly. 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,becausebecause, in XPathitselfitself, namespace declarations are notrepresented, and thusrepresented; thus, such a recursive algorithm wouldn't know when to stop. Consider the following document: <x xmlns:a="tag:42"> <y xmlns:a="tag:42"/> </x> 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: <x xmlns:a="tag:42"> <y/> </x> 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. The conclusion of these considerations is that for implementing XMLPatch,patch, access closer to the XML syntax(specifically:(specifically access to namespace declarations) is necessary. As a result, implementations attempting to exclusively use the XPath model for implementing XMLPatchpatch will fail to correctly address certain edge cases (such as the 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) [W3C.REC-DOM-Level-3-Core-20040407], for example, does expose namespace declaration attributes as regular attributes in the documenttree, and thustree; thus, they could be used to differentiate between the two variants shown above. Please note that RFC5261's5261, Section 4.4.3on(on replacingnamespacesnamespaces) mixes the terms "namespace declaration" and "namespace". For this reason, RFCerratumErrata ID 3478 is available for Section 4.4.3 of RFC 5261. Appendix B.Implementation Status Note to RFC Editor: Please remove this section before publication. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this [RFC6982]. 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. 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". EMC: EMC's IIG unit has implemented the selector part of the specification, which is the trickiest part (see Appendix A.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>. Appendix C.ABNF for RFC 5261 RFC 5261 [RFC5261] does not contain an ABNF grammar for the allowed subset of XPathexpressions,expressions but includes an XSD-based grammar in its type definition for operationtypes).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. 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 ) ) 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 [RFC5234].Appendix D. Acknowledgements Thanks for comments and suggestions provided by Bas de Bakker, Tony Hansen, Bjoern Hoehrmann, and Julian Reschke.Author's Address Erik Wilde UC BerkeleyEmail:EMail: dret@berkeley.edu URI: http://dret.net/netdret/