view Side-By-Side changes

SIMPLE WG                                                  J. Urpalainen
Internet-Draft                                                     Nokia Research Center
Intended status: Standards Track                          August 9, 2007
Expires: September 7, 2006                                 March 6, 2006 February 10, 2008


An Extensible Markup Language (XML) Patch Operations Framework Utilizing
                  XML Path Language (XPath) Selectors
                   draft-ietf-simple-xml-patch-ops-02
                   draft-ietf-simple-xml-patch-ops-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 7, 2006. February 10, 2008.

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

Abstract

   Extensible Markup Language (XML) documents are widely used as
   containers for the exchange and storage of arbitrary data in today's
   systems.  Updates  In order to this data require transporting send changes to an XML document, an entire copy
   of the entire XML
   document between hosts, new version must be sent, unless there's there is a mechanism that allows
   exchanging means of
   indicating only the updates of XML documents. 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



Urpalainen              Expires February 10, 2008               [Page 1]

Internet-Draft              Patch Operations                 August 2007


   constitute the basis of patch operations described in this document.



Urpalainen              Expires September 7, 2006               [Page 1]

Internet-Draft              Patch Operations                  March 2006
   In addition to them, with basic <add>, <replace> and <remove>
   directives a set of patches can then be applied to update an existing
   XML document.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   3.  Basic Features and Requirements  . . . . . . . . . . . . . . .  4  5
   4.  Patch Operations . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Locating the Target for of a Patch . . . . . . . . . . . . .  6 .  7
     4.2.  Namespace Mangling . . . . . . . . . . . . . . . . . . . .  6  7
     4.3.  <add> Element  . . . . . . . . . . . . . . . . . . . . . .  8
     4.4.  <replace>  9
       4.3.1.  Adding an Element  . . . . . . . . . . . . . . . . . . 10
       4.3.2.  Adding an Attribute  . . . . . . . . . . . . . . . . . 10
       4.3.3.  Adding a Prefixed Namespace Declaration  . . . . . . . 11
     4.5.  <remove> Element
       4.3.4.  Adding Node(s) with the 'pos' Attribute  . . . . . . . 11
       4.3.5.  Adding Multiple Nodes  . . . . . . . . . . . . . . . . 11
     4.4.  <replace> Element  . . . . . . . . . . . . . . . . . . . . 12
   5.  Error Handling
       4.4.1.  Replacing an Element . . . . . . . . . . . . . . . . . 12
       4.4.2.  Replacing an Attribute Value . . . . . . . . 14
   6.  Usage of Patch Operations . . . . . 13
       4.4.3.  Replacing a Namespace Declaration URI  . . . . . . . . 13
       4.4.4.  Replacing a Comment Node . . . . . 14
   7.  Usage of Selector Values . . . . . . . . . . 13
       4.4.5.  Replacing a Processing Instruction Node  . . . . . . . 13
       4.4.6.  Replacing a Text Node  . . . 14
   8.  Full Example . . . . . . . . . . . . . 13
     4.5.  <remove> Element . . . . . . . . . . . . . . . . . . . . . 14
   9.  XML Schema
       4.5.1.  Removing an Element  . . . . . . . . . . . . . . . . . 14
       4.5.2.  Removing an Attribute  . . . . . . . . . 16
   10. IANA Considerations . . . . . . . 14
       4.5.3.  Removing a Prefixed Namespace Declaration  . . . . . . 15
       4.5.4.  Removing a Comment Node  . . . . . . . . 18
     10.1. XML Schema Registration . . . . . . . 15
       4.5.5.  Removing a Processing Instruction Node . . . . . . . . 15
       4.5.6.  Removing a Text Node . . 18
   11. Security Considerations . . . . . . . . . . . . . . . 15
   5.  Error Handling . . . . 18
   12. Acknowledgments . . . . . . . . . . . . . . . . . . . . 15
   6.  Usage of Patch Operations  . . . 19
   13. References . . . . . . . . . . . . . . . 16
   7.  Usage of Selector Values . . . . . . . . . . . 19
     13.1. Normative References . . . . . . . . 16
   8.  XML Schema . . . . . . . . . . . 19
     13.2. Informative References . . . . . . . . . . . . . . . 16
   9.  IANA Considerations  . . . 20
   Author's Address . . . . . . . . . . . . . . . . . . 18
     9.1.  XML Schema Registration  . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 22





















Urpalainen              Expires September 7, 2006               [Page 2]

Internet-Draft              Patch Operations                  March 2006


1.  Introduction 18
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     12.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Appendix A.  Informative Examples  . . . . . . . . . . . . . . . . 20
     A.1.  Adding an Element  . . . . . . . . . . . . . . . . . . . . 20
     A.2.  Adding an Attribute  . . . . . . . . . . . . . . . . . . . 21



Urpalainen              Expires February 10, 2008               [Page 2]

Internet-Draft              Patch Operations                 August 2007


     A.3.  Adding a Prefixed Namespace Declaration  . . . . . . . . . 21
     A.4.  Adding a Comment Node with the 'pos' Attribute . . . . . . 22
     A.5.  Adding Multiple Nodes  . . . . . . . . . . . . . . . . . . 22
     A.6.  Replacing an Element . . . . . . . . . . . . . . . . . . . 23
     A.7.  Replacing an Attribute Value . . . . . . . . . . . . . . . 24
     A.8.  Replacing a Namespace Declaration URI  . . . . . . . . . . 24
     A.9.  Replacing a Comment Node . . . . . . . . . . . . . . . . . 25
     A.10. Replacing a Processing Instruction Node  . . . . . . . . . 25
     A.11. Replacing a Text Node  . . . . . . . . . . . . . . . . . . 26
     A.12. Removing an Element  . . . . . . . . . . . . . . . . . . . 26
     A.13. Removing an Attribute  . . . . . . . . . . . . . . . . . . 27
     A.14. Removing a Prefixed Namespace Declaration  . . . . . . . . 28
     A.15. Removing a Comment Node  . . . . . . . . . . . . . . . . . 28
     A.16. Removing a Processing Instruction Node . . . . . . . . . . 29
     A.17. Removing a Text Node . . . . . . . . . . . . . . . . . . . 29
     A.18. Several Patches With Namespace Mangling  . . . . . . . . . 30
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
   Intellectual Property and Copyright Statements . . . . . . . . . . 33

































Urpalainen              Expires February 10, 2008               [Page 3]

Internet-Draft              Patch Operations                 August 2007


1.  Introduction

   Extensible Markup Language (XML) [2] documents are widely used as
   containers for 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 (patches).

   This document describes an XML patch framework which utilizes XML
   Path language (XPath) [3] selectors.  An XPath selector is used to
   pinpoint the specific portion of the XML that is the target for the
   change.  These selector values and updated new data content
   constitute the basis of patch operations described in this document.
   In addition to them, with basic <add>, <replace> and <remove>
   directives a set of patches can be applied to update an existing
   initial XML document.  With these patch operations, a simple
   semantics for data oriented XML documents [7] is achieved, that is,
   modifications like additions, removals or substitutions of elements
   and attributes can easily be performed.  This document does not
   describe a full XML diff format, only basic patch operation elements
   which can be embedded within a full format which typically has
   additional semantics.

   As a one concrete example, in the Session Initiation Protocol (SIP)
   [16] based presence system a partial PIDF XML document format [14]
   consists of the existing PIDF document format combined with the patch
   operations elements described in this document.  In general, patch
   operations can be used in any application that exchanges XML
   documents, for example within the SIP Events framework [13].  Yet
   another example is XCAP-diff [15] which uses this framework for
   sending partial updates of changes to XCAP [12] resources.


2.  Conventions

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119, BCP 14
   [1] and indicate requirement levels for compliant implementations.

   The following terms are used in this document:

   Initial XML document:  An initial XML document that is going to be
      updated with a set of patches.







Urpalainen              Expires February 10, 2008               [Page 4]

Internet-Draft              Patch Operations                 August 2007


   XML diff document:  An XML document that contains patch operation
      elements, namespace declarations and all the document content
      changes that are needed in order to transform an initial XML
      document into a new patched XML document.

   Patched XML document:  An XML document that results after applying
      one or more patch operations defined in the XML diff document to
      the initial XML document.

   Patch operation:  A single change, i.e. a patch that is being applied
      to update an initial XML document.

   Patch operation element:  An XML element that represents a single
      patch operation.

   Type definition for an element:  A W3C Schema type definition for an
      element that describes a patch operation content.

   In-scope namespace declaration:  A list of all in-scope namespace
      declarations within a context node.  The QName expansion of a
      context node is based on mapping a prefix with one of these
      declarations.  For an element, one namespace binding may have an
      empty prefix.

   Positional constraint:  A number enclosed with square brackets.  It
      can be used as a location step predicate.

   Located target node:  A node which was found from the initial XML
      document with the aid of an XPath selector value.

   White space text node:  A text node which contains only white space.


3.  Basic Features and Requirements

   In this framework, XPath selector values and new data content are
   embedded within XML elements, the exchange names of which specify the
   modification to be performed: <add>, <replace> or <remove>.  These
   elements (patch operations) are defined by schema types with the W3C
   Schema language [5].  XPath selectors pinpoint the target for a
   change and storage they are expressed as attributes of arbitrary these elements.  The
   child node(s) of patch operation elements contain the new data
   content.  In general when applicable, the new content SHOULD be moved
   unaltered to the patched XML document.

   XML documents which are equivalent for the purposes of many
   applications MAY differ in today's
   systems.  An example their physical representation.  The aim of such a system
   this document is to describe a deterministic framework where the Common Presence Profile
   (CPP) [16] compatible presence system,



Urpalainen              Expires February 10, 2008               [Page 5]

Internet-Draft              Patch Operations                 August 2007


   canonical form with comments [6] of an XML document determines
   logical equivalence.  For example, white space text nodes MUST be
   processed properly in which presence data order to fulfil this requirement as white space
   is
   represented using by default significant [6].

   The specifications referencing these element schema types MUST define
   the full XML based Presence Information Data Format
   (PIDF) [17].  Updates to diff format with an appropriate MIME type [11] and a
   character set, e.g.  UTF-8 [9].  For example, the partial PIDF format
   [14] includes this data require transporting of schema and describes additional definitions to
   produce a complete XML diff format for partial presence information
   updates.

   As the entire
   XML schema defined in this document between hosts, unless there's a mechanism that allows
   exchanging only does not declare any target
   namespace, the updates type definitions inherit the target namespace of an XML document.

   This document describes an XML patch framework which utilizes the
   including schema.  Therefore, additional namespace declarations
   within the XML
   Path language (XPath) [3] selectors.  An XPath selector diff documents can be avoided.

   It is used to
   pinpoint the target for a change.  These selector values anticipated that applications using these types will define
   <add>, <replace> and updated
   new data content constitute <remove> elements based on the basis of patch operations described corresponding
   type definitions in this document. schema.  In addition to them, with basic <add>, <replace>
   and <remove> directives addition, an application may
   reference only a set subset of patches can be applied to update an
   existing initial XML document.  With these patch type definitions.  A future
   extension can introduce other operations, a simple
   semantics for data e.g. with document oriented XML documents
   models [7] is achieved, that is,
   modifications like additions, removals or substitutions of elements
   and attributes can easily be performed.  This document does not
   describe a full XML diff format, only basic patch <move> operation elements
   which can be embedded within a full format.

   As an example, in the Session Initiation Protocol (SIP) [18] based
   presence system and a partial PIDF XML document format [13] consists of
   the existing PIDF document format text node patching algorithm
   combined with the patch operations <move> would undoubtedly produce smaller XML diff
   documents.

   The instance document elements described in this document.  In general, patch operations based on these schema type definitions
   MUST be well formed and SHOULD be valid.

   The following XPath 1.0 data model node types can be used in any application that exchanges added, replaced
   or removed with this framework: elements, attributes, namespaces,
   comments, texts and processing instructions.  The full XML documents, for
   example within prolog
   including e.g.  XML entities [2] and the SIP Events framework [12].  Another example is
   XCAP-diff [14] which uses this framework for sending partial updates root node of changes an XML document
   cannot be patched according to XCAP [15] resources.


2.  Conventions

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", framework.  However, patching of
   comments and "OPTIONAL" are to be interpreted processing instructions of the root node is allowed.
   Naturally the removal or addition of a document root element is not
   allowed as described in RFC 2119, BCP 14
   [1] and indicate requirement levels for compliant implementations.

   The following terms are used in this document:

   Initial XML document: An initial any valid XML document MUST always contain a single root
   element.  Also note that support for external entities is going to be
      updated with a set beyond the
   scope of patches.






Urpalainen              Expires September 7, 2006               [Page 3]

Internet-Draft this framework.


4.  Patch Operations                  March 2006

   An XML diff document: A frame XML document that contains a collection of patch operation
   elements, namespace declarations and all the document content
      changes that are needed in order to transform an initial XML
      document into a new patched XML document.

   Patched XML document: An XML document that results after applying including one or more <add>, <replace> and <remove>
   elements.  These patch operations defined in the XML diff document to the
      initial XML document.

   Patch operation: A single change, i.e. a will be applied sequentially in the
   document order.  After the first patch that is being has been applied to update an
   initial XML document. document, the patched XML document becomes a new



Urpalainen              Expires February 10, 2008               [Page 6]

Internet-Draft              Patch operation element: An Operations                 August 2007


   independent XML document against which the next patch will be
   applied.  This procedure repeats until all patches have successfully
   been processed.

4.1.  Locating the Target of a Patch

   Each patch operation element that represents contains a 'sel' attribute.  The value
   of this attribute is an XPath selector with a restricted subset of
   the full XPath 1.0 recommendation.  The 'sel' value is used to locate
   a single
      patch operation.

   Type definition unique target node from the initial XML document.  This
   located node pinpoints the target for a change and usually it is an element: A W3C Schema type definition
   element, which is e.g. either updated itself or some child node(s)
   are added into it.  It MAY also be for instance a comment node, after
   which some other sibling node(s) are inserted.  In any case, it is an
      element
   error condition if multiple nodes are found during the evaluation of
   this selector value.

   The XPath selections of the 'sel' attribute always start from the
   root node of a document.  Thus relative location paths SHOULD be used
   so that describes the starting root node selection "/" can be omitted.  When
   locating elements in a patch operation content.

   In-scope namespace declaration: document tree, a node test can either be a "*"
   character or a QName.  A list "*" character selects all element children
   of the context node.  Right after the node test, a location step can
   contain one or more predicates in any order.  An attribute value
   comparison is one of all in-scope namespace
      declarations within a context node. the most typical predicates.  The QName expansion string value
   of a the current context node is based on mapping or a prefix with one of these
      declarations.  For an element, one namespace binding child element may have alternatively be
   used to identify elements in the tree.  The character ".", which
   denotes a current context node selection, is an
      empty prefix.

   Positional constraint: A number enclosed with square brackets.  It abbreviated form of
   "self::node()".  Lastly, positional constraints like "[2]" can also
   be used as a location step an additional predicate.

   Located target node: A node which was found

   An XPath 1.0 "id()" node-set function MAY also be used to identify
   unique elements from the initial XML document with tree.  The schema that describes
   the aid of an XPath selector value.

   White space text node: A text node which contains only white space.


3.  Basic Features and Requirements

   In this framework, XPath selector values and new data content are
   embedded within XML elements, the names model of which imply the document MUST then use an attribute with the
   type of a
   modification: <add>, <replace> or <remove>.  These elements, ID [7] or
   synonymously patch operations as with non-validating XML parsers, an "xml:id" [8]
   attribute MUST have been used within an instance document.

4.2.  Namespace Mangling

   While the XPath recommendation specifies that prefixes can be used in this document,
   location steps, it does not specify how associated namespace URIs are described
   by defining their schema types with
   discovered during these evaluations.  In the patch operation
   framework QName [4] expansion within a location step is evaluated
   according to the namespace declarations of the W3C Schema language [6].
   XPath selectors pinpoint XML diff document.
   Thus the target namespace URIs for a change and they are
   expressed as attributes of these elements.  The child node(s) prefixes are found from the in-
   scope namespaces of the patch operation elements contain the new data content. element.  In general
   when applicable, the new content SHOULD be moved unaltered to other words, the
   patched
   XML document.

   The specifications utilizing these element types MUST define diff document contains all needed information for QName
   expansions in order to perform XPath searches from the full initial XML diff format with an appropriate MIME type [11] and a character



Urpalainen              Expires September 7, 2006 February 10, 2008               [Page 4] 7]

Internet-Draft              Patch Operations                  March 2006


   set, e.g.  UTF-8 [9].  The partial PIDF format [13] includes this
   schema                 August 2007


   document.

      Note: It should be emphasized that prefixes within the XPath
      selectors MAY be different than those of the initial XML document
      because the matching of nodes is based on expanded names, i.e. a
      prefix maps to a namespace URI and describes additional definitions these URIs and local names MUST
      be identical.  For example, with a selector "p:foo", "p" maps to produce a complete XML
   diff format for partial presence information updates.

   As
      namespace URI and "foo" is the schema defined in local name.

   In this document does not declare any target
   namespace, framework, when a node test is "foo" and the type definitions inherit patch operation
   element has an in-scope default namespace declaration, a qualified
   <foo> element from the initial XML document is being searched.  That
   is, the target namespace URI of the
   including schema.  Therefore, additional expanded name of the located <foo>
   element MUST then be identical compared to this default namespace declarations
   declaration.  If there's not an in-scope default namespace
   declaration within the XML diff documents can be avoided.

   It evaluation context, an unqualified <foo>
   element is anticipated that applications using these types will define
   <add>, <replace> and <remove> elements based on the corresponding
   type definitions located.

      Note: By contrast, in this schema.  In addition, an application may
   reference only a subset of these type definitions.  A future
   extension can introduce other operations, e.g. with document oriented
   models [7] XPath 1.0 a <move> operation and "foo" selector always locates an
      unqualified <foo> element but in XPath 2.0 [10] also a text node patching algorithm
   combined qualified
      one which is attached with <move> would undoubtedly produce smaller XML diff
   documents.

   The instance document elements based on these schema type definitions
   MUST be well formed and SHOULD be valid. the default namespace declaration.

      Note: The following XPath 1.0 data model node types recommendation specifies "namespace-uri()" and
      "local-name()" node-set functions which can be added, replaced
   or removed used within
      predicates.  These functions may be utilized during XPath
      evaluations if there are no other means to "register" prefixes
      with this framework: elements, attributes, namespaces,
   comments, texts and processing instructions.  The full XML prolog
   including e.g.  XML entities [2] and the root node of an XML document
   cannot associated namespace URIs.  They can also be patched according used when
      handling selections where default namespaces are attached to this framework.
      elements.  However, patching of
   comments and processing instructions of the root node is allowed.
   Naturally schema type definitions for these patch
      operation elements do not allow the removal or addition usage of these functions.

   Also elements within the changed data content are usually namespace
   qualified.  For example, when adding a document root new namespace qualified
   element is not
   allowed as any valid to the initial XML document MUST always contain a single root
   element.  Also note that support for external entities is beyond document, the
   scope namespace declaration
   reference of this framework.

      Note: Implementations must thus be based on XML parsers and XPath
      interpreters that support all XPath 1.0 data model node types
      except new element belongs first to the root node of an XML diff document.  In addition
   Naturally after copying or moving this element, the attached
   namespace MUST refer to a declaration within the
      location capability of patched XML
   document.  If this namespace is declared in the patch operation
   element or within its ascendants, these nodes, some application programming
      interfaces are needed for their manipulation references MUST thus be
   changed.  Like in practice.

   XML documents which are equivalent for XPath, the purposes mapping of many
   applications MAY differ in their physical representation. these references is based on
   identical namespace URIs, not prefixes.  The aim namespace with an
   identical URI from the in-scope namespaces of
   this document is to describe a deterministic framework where the
   canonical form with comments [4] context node of an the
   initial XML document determines
   logical equivalence.  For example, white space text nodes MUST be
   processed properly in order to fulfil chosen.  However, if overlapping in-
   scope namespaces exist, i.e., there are several in-scope namespaces
   with an identical namespace URI, then the namespace with the same
   prefix MUST be chosen.  If an equivalent prefix is not then found, an
   error occurs.  For instance, this requirement as white space kind of overlapping can happen when
   a namespace qualified attribute is by default significant [4]. added while elements are attached



Urpalainen              Expires September 7, 2006 February 10, 2008               [Page 5] 8]

Internet-Draft              Patch Operations                  March 2006


4.  Patch Operations

   An XML diff document contains a collection of patch operation
   elements, including one                 August 2007


   with an identical default namespace declaration.

   When the new added or more <add>, <replace> and <remove>
   elements.  These patch operations will be applied sequentially in updated elements contain namespace
   declarations, the
   document order.  After namespace nodes move unaltered from the first patch has been applied to update an
   initial XML document, diff
   document to the patched XML document becomes a new initial
   XML document.  This procedure repeats until all patches have
   successfully been processed.  In other words,  Default namespace declarations
   can only be added by this framework does not
   allow "apply all occurrences" way but prefixed namespace declarations MAY
   be added or removed with XPath namespace axis semantics shown later
   in one pass.

4.1.  Locating the Target for a Patch

   Each patch operation element contains a 'sel' attribute.  The value
   of this attribute is document.

      Note: In practice, this namespace mangling means that an XPath selector with a restricted subset XML diff
      document MUST only know the namespace URIs of qualified nodes, the full XPath 1.0 recommendation.  The 'sel' value is used to locate
   a single unique target node from
      prefixes of the initial XML document.  This
   located node pinpoints the target for a change and usually it is an
   element, which is e.g. either updated itself or some child node(s)
   are added into it.  It may also be for instance a comment node, after
   which some other sibling node(s) document are inserted.  In any case, it is an
   error condition if multiple nodes not significant unless
      there are found during those overlapping namespace declarations.  In other
      words, regardless whether the evaluation prefixes of
   this selector value.

   The XPath selections qualified elements of
      the 'sel' attribute always start from initial XML document are empty (default namespace attached) or
      not, the
   root node XML diff document may remain the same.

4.3.  <add> Element

   The <add> element represents the addition of a document.  Thus relative location paths SHOULD be used
   so that some new content to the starting root node selection "/" can be omitted.  When
   locating elements in a document tree,
   initial XML document: e.g. a node test new element can either be a "*"
   character or a QName.  A "*" character selects all element children appended into an
   existing element.

   The new data content exists as the child node(s) of the context node.  Right after <add>
   element.  When adding attributes and namespaces the child node test, of the
   <add> element MUST be a location step can single text node.  Otherwise, the <add>
   element MAY contain one any mixture of element, text, comment or more predicates
   processing instruction nodes in any order.  An attribute  All children of the <add>
   element are then copied into an initial XML document.  The described
   namespace mangling procedure applies to added elements, which include
   all of their attribute, namespace and descendant nodes.

   The <add> element type has three attributes: 'sel', 'type' and 'pos'.

   The value
   comparison of the optional 'type' attribute is one only used when adding
   attributes and namespaces.  Then the located target node MUST be an
   element into which new attributes and namespace declarations are
   inserted.  When the value of this 'type' attribute equals "@attr" the most typical predicates.
   purpose is to add a new attribute node with the name 'attr'.  The string
   value of this new 'attr' attribute is the current context text node or a child element may alternatively be
   used to identify elements in content of the tree.
   <add> element.  The character ".", which
   denotes a current context node selection, is an abbreviated form of
   "self::node()".  Lastly, positional constraints like "[2]" less frequently used, prefixed, i.e. namespace
   qualified attributes can also be used as an additional predicate.

   An XPath 1.0 "id()" node-set function MAY also be used to identify
   unique elements from the document tree.  The schema that describes added.  If the content model value of the document MUST then use an 'type'
   attribute with equals "namespace::pref" the
   type ID [7] or with non-validating XML parsers, an "xml:id" [8]
   attribute MUST have been used within an instance document.

4.2.  Namespace Mangling

   While aim is to add a new "pref"
   prefixed namespace declaration and the XPath recommendation specifies that prefixes can be used in
   location steps, it does not specify how associated text node content of the <add>
   element contains the corresponding namespace URIs are URI.






Urpalainen              Expires September 7, 2006 February 10, 2008               [Page 6] 9]

Internet-Draft              Patch Operations                  March 2006


   discovered during these evaluations.  In                 August 2007


      Note: The 'type' attribute is thus also an XPath selector, but it
      only locates attributes and namespaces.  Attribute axis
      "attribute" has an abbreviated form "@" unlike the patch operation
   framework QName [5] expansion within a location step "namespace"
      axis which doesn't have an abbreviated form.  Double colons "::"
      are used as an axis separator in XPath.

   The value of the optional 'pos' attribute indicates the positioning
   of new data content.  It is evaluated
   according to not used when adding attributes or
   namespaces.  When neither 'type' nor 'pos' attribute exist, the namespace declarations
   children of the XML diff document.
   Thus <add> element are then appended as the namespace URIs for these prefixes last child
   node(s) of the located target element.  When the value of 'pos'
   attribute is "prepend" the new node(s) are found from added as the in-
   scope namespaces first child
   node(s) of the patch operation located target element.  In other words,  With the
   XML diff document contains all needed information for QName
   expansions in order to perform XPath searches from value of "before"
   the initial XML
   document.

      Note: It should added new node(s) MUST be emphasized that prefixes within the XPath
      selectors MAY be different than those immediate preceding sibling node(s)
   and with "after" the immediate following sibling node(s) of the initial XML document
      because
   located target node.

   Some examples follow which describe the matching use cases of these <add>
   element attributes.  The nodes is based on expanded names, i.e. a
      prefix maps to a are not namespace URI and these URIs qualified and local names MUST
      be identical.  For example, with a selector "p:foo", "p" maps to a
      namespace URI
   prefixes are therefore not used and "foo" is the local name.

   In this framework, when a node test whole XML diff content is "foo" and the not
   shown in these examples, only patch operation
   element has elements.  Full
   examples are given in an in-scope default namespace declaration, Appendix A.

4.3.1.  Adding an Element

   An example for an addition of an element:

   <add sel="doc"><foo id="ert4773">This is a qualified
   <foo> new child</foo></add>

   Once the <doc> element has been found from the initial XML document document,
   a new <foo> element is being searched.  That
   is, appended as the namespace URI last child node of the expanded name <doc>
   element.  The located target node: the <doc> element is naturally the
   root element of the located initial XML document.  The new <foo> element MUST then be identical compared to this default namespace
   declaration.  If there's not an in-scope default namespace
   declaration within the evaluation context,
   contains an unqualified <foo>
   element is located.

      Note: By contrast, in XPath 1.0 'id' attribute and a "foo" selector always locates child text node.

4.3.2.  Adding an
      unqualified Attribute

   An example for an addition of an attribute:

   <add sel="doc/foo[@id='ert4773']" type="@user">Bob</add>

   This operation adds a new 'user' attribute to the <foo> element but in XPath 2.0 [10] also a qualified
      one which
   was located by using an 'id' attribute value predicate.  The value of
   this new 'user' attribute is attached with "Bob".

   A similar patched XML document is achieved when using a validating
   XML parser, if the default namespace declaration.

      Note: The XPath 1.0 recommendation specifies "namespace-uri()" 'sel' selector value had been 'id("ert4773")' and
      "local-name()" node-set functions which
   if the data type of the 'id' attribute is "ID" [7].



Urpalainen              Expires February 10, 2008              [Page 10]

Internet-Draft              Patch Operations                 August 2007


      Note: As the 'sel' selector value MAY contain quotation marks,
      escaped forms: "&quot;" or "&apos;" can be used within
      predicates.  These functions may be utilized during XPath
      evaluations if there are no other means attribute
      values.  However, it is often more appropriate to "register" prefixes
      with associated namespace URIs.  They can use the
      apostrophe (') character as shown in these examples.  An
      alternative is also be used when
      handling selections where default namespaces are attached to
      elements.  However, interchange the schema type definitions apostrophes and quotation
      marks.

4.3.3.  Adding a Prefixed Namespace Declaration

   An example for these patch
      operation elements do not allow the usage an addition of these functions.

   Also elements within the changed data content are usually a prefixed namespace
   qualified.  For example, when adding declaration:

   <add sel="doc" type="namespace::pref">urn:ns:xxx</add>

   This operation adds a new namespace qualified
   element declaration to the initial XML document, the namespace declaration
   reference <doc> element.
   The prefix of this new element belongs first to the XML diff document.
   Naturally after copying or moving this element, namespace node is thus "pref" and the attached
   namespace MUST refer to URI is "urn:ns:xxx".

4.3.4.  Adding Node(s) with the 'pos' Attribute

   An example for an addition of a declaration within comment node:

   <add sel="doc/foo[@id='ert4773']" pos="before"><!-- comment --></add>

   This operation adds a new comment node just before the patched <foo> element
   as an immediate preceding sibling node.  This is also an example how
   a 'pos' attribute directive can be used.

4.3.5.  Adding Multiple Nodes

   Some complexity arises when so called white space text nodes exist
   within an initial XML document.  If this namespace  The XPath 1.0 data model requires
   that a text node MUST not have another text node as an immediate
   sibling node.  For instance, if an add operation is declared in like this:

   <add sel="doc">
     <foo id="ert4773">This is a new child</foo></add>

   The <add> element has then two child nodes: a white space text node
   (a linefeed and two spaces) and a <foo> element.  If the patch operation existing
   last child of the <doc> element or within is a text node, its ascendants, these references content and the
   white space text node content MUST thus then be combined together.
   Otherwise (white space) text nodes can be added just like elements
   and thus, the canonical form of the patched XML document easily
   remains deterministic.  As several sibling nodes can be inserted with
   a single <add> operation, a "pretty printing" style can easily be
   changed.  Like in XPath,
   maintained.

   Still another example about the mapping handling of these references is based on
   identical namespace URIs, not prefixes.  The namespace with an text nodes.  Consider



Urpalainen              Expires September 7, 2006 February 10, 2008              [Page 7] 11]

Internet-Draft              Patch Operations                  March 2006


   identical URI from the in-scope namespaces of a context                 August 2007


   this example:

   <add sel="*/foo/text()[2]" pos="after">new<bar/>elem</add>

   The second text node child of the
   initial XML document MUST be chosen.  However, if overlapping in-
   scope namespaces exist, i.e., there are several in-scope namespaces
   with an identical namespace URI, then the namespace with the same
   prefix MUST be chosen.  If an equivalent prefix is not then found, an
   error occurs.  For instance, this kind of overlapping can happen when
   a namespace qualified attribute <foo> element is first located.
   The added while elements are attached
   with new content contains two text nodes and an identical default namespace declaration.

   When element.  As
   there can not be immediate sibling text nodes, the located target
   text node content and the first new added or updated elements contain namespace
   declarations, text node content MUST be
   combined together.  In essence, if the namespace nodes move unaltered from 'pos' value had been "before",
   the XML diff
   document second new text node content would effectively have been
   prepended to the patched XML document.  Default namespace declarations
   can only be added by this way but prefixed namespace declarations MAY
   be added or removed with XPath namespace axis semantics shown later
   in this document. located target text node.

      Note: In practice, this namespace mangling means It is still worth noting that an XML diff
      document MUST only know text nodes MAY contain CDATA
      sections, the namespace URIs latter of qualified which are not treated as separate nodes.
      Once these CDATA sections exist within the new text nodes, they
      SHOULD be moved unaltered to the
      prefixes of patched XML document.

   While XML entities [2] cannot be patched with this framework, the
   references to other than predefined internal entities can exist
   within text nodes or attributes when the initial XML document are not significant unless
      there are prolog contains those overlapping namespace
   declarations.  In other
      words, regardless whether the prefixes of qualified elements of  These references may then be preserved if both the initial XML document are empty (default namespace attached) or
      not,
   diff and the initial XML diff document have identical declarations within
   their prologs.  Otherwise, references may remain be replaced with identical
   text as long as the same.

4.3.  <add> "canonically equivalent" rule is obeyed.

4.4.  <replace> Element

   The <add> <replace> element represents the addition of some new content to the
   initial XML document: a replacement operation: e.g. an
   existing element is updated with a new element can be appended into or an
   existing element.

   The attribute value
   is replaced with a new data content exists as the child node(s) of the <add>
   element.  When adding attributes and namespaces the child node of the
   <add> element MUST be value.  This <replace> operation always
   updates a single text node.  Otherwise, the <add>
   element can contain any mixture of element, text, comment node or
   processing instruction nodes in any order.  All children of the <add>
   element are then copied into an initial XML document.  The described
   namespace mangling procedure applies to added elements, which include
   all of their attribute, namespace and descendant nodes. node content at a time.

   The <add> <replace> element type has three attributes: 'sel', 'type' and 'pos'.

   The value of the optional 'type' attribute is only used when adding
   attributes and namespaces.  Then a 'sel' attribute.  If the
   located target node MUST be an
   element into which new attributes and namespace declarations are
   inserted.  When the value of this 'type' attribute equals "@attr" the
   purpose is to add an element, a new attribute node with the name 'attr'.  The
   value of this new 'attr' attribute is comment or a processing
   instruction, then the text node content child of the
   <add> element.  The less frequently used, prefixed, i.e. namespace



Urpalainen              Expires September 7, 2006               [Page 8]

Internet-Draft              Patch Operations                  March 2006


   qualified attributes can <replace> element MUST also be added.  If the value of
   the 'type'
   attribute equals "namespace::pref" the aim is to add a new "pref"
   prefixed namespace declaration and same type.  Otherwise the <replace> element MUST have text node
   content of the <add>
   element contains the corresponding namespace URI.

      Note: The 'type' or it MAY be empty when replacing an attribute is thus also value or a
   text node content.

4.4.1.  Replacing an XPath selector, but it
      only locates attributes and namespaces.  Attribute axis
      "attribute" has Element

   An example for a replacement of an abbreviated form "@" unlike element:

   <replace sel="doc/foo[@a='1']"><bar a="2"/></replace>

   This will update the "namespace"
      axis <foo> element which doesn't have an abbreviated form.  Double colons "::"
      are used as has an axis separator in XPath.

   The value of the optional 'pos' 'a' attribute indicates the positioning
   of new data content.  It with
   value "1".  The located target element is not used when adding replaced with the <bar>
   element.  So all descendant nodes, namespace declarations and



Urpalainen              Expires February 10, 2008              [Page 12]

Internet-Draft              Patch Operations                 August 2007


   attributes or
   namespaces.  When neither 'type' nor 'pos' attribute exist, the
   children of the <add> element replaced <foo> element, if any existed, are then appended as thus
   removed.

4.4.2.  Replacing an Attribute Value

   An example for a replacement of an attribute value:

   <replace sel="doc/@a">new value</replace>

   This will replace the last child
   node(s) 'a' attribute content of the located target element.  When <doc> element with
   the value of 'pos'
   attribute "new value".  If the <replace> element is "prepend" empty, the new node(s) are added as 'a'
   attribute MUST then remain in the first child
   node(s) patched XML document appearing like
   <doc a=""/>.

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 located target element.  With the URI value of "before" 'pref' prefixed namespace node
   with "urn:new:xxx".  The parent node of the added new node(s) namespace declaration
   MUST be the immediate preceding sibling node(s)
   and with "after" the immediate following sibling node(s) <doc> element, otherwise an error occurs.

4.4.4.  Replacing a Comment Node

   An example for a replacement of a comment node:

   <replace sel="doc/comment()[1]"><!-- This is the
   located target new content
   --></replace>

   This will replace a comment node.

   Some examples follow where nodes are not namespace qualified and
   prefixes are therefore not used.  The whole XML diff content located target node is not
   shown in these examples, only patch operation elements because the
   first comment node child of
   simplicity reasons:

   <add sel="doc"><foo id="ert4773">This the <doc> element.

4.4.5.  Replacing a Processing Instruction Node

   An example for a replacement of a processing instruction node:

   <replace sel='doc/processing-instruction("test")'><?test bar="foobar"
   ?></replace>

   This will replace the processing instruction node "test" whose parent
   is the <doc> element.

4.4.6.  Replacing a Text Node

   An example for a replacement of a text node:




Urpalainen              Expires February 10, 2008              [Page 13]

Internet-Draft              Patch Operations                 August 2007


   <replace sel="doc/foo/text()[1]">This is a new child</foo></add>

   Once the <doc> element has been found from the initial XML document,
   a new <foo> element is appended as text content</
   replace>

   This will replace the last child first text node child of the <doc> <foo> element.
   The located target node: positional constraint "[1]" is not usually needed as the <doc> element
   content is naturally rarely of mixed type [5] where several text node siblings
   typically exist.

   If a text node is updated and the
   root <replace> element of is empty, the initial XML document.
   text node MUST thus be removed as a text node MUST always have at
   least one character of data.

4.5.  <remove> Element

   The new <foo> <remove> element
   contains an 'id' attribute and represents a child text node.

   An example for an addition removal operation of e.g. an attribute:

   <add sel="doc/foo[@id='ert4773']" type="@user">Bob</add>

   This operation adds a new 'user' attribute to the <foo>
   existing element which
   was located by using or an 'id' attribute value predicate. attribute.

   The <remove> element type has two attributes: 'sel' and 'ws'.  The
   value of
   this new 'user' the optional 'ws' attribute is "Bob".

   A similar patched XML document is achieved when using a validating
   XML parser, if the 'sel' selector value had been 'id("ert4773")' and
   if used to remove the data type possible
   white space text nodes that exist either as immediate following or
   preceding sibling nodes of the 'id' located target node.  The usage of
   'ws' attribute is "ID" [7].





Urpalainen              Expires September 7, 2006               [Page 9]

Internet-Draft              Patch Operations                  March 2006


      Note: As the 'sel' selector value MAY contain quotation marks,
      escaped forms: "&quot;" or "&apos;" can be used within only allowed when removing other types than text,
   attribute
      values.  However, it and namespace nodes.  If the value of 'ws' is often more appropriate to use "before", the
      apostrophe (') character as shown in these examples.  An
      alternative
   purpose is also to interchange remove the apostrophes and quotation
      marks.

   An example for an addition of a prefixed namespace declaration:

   <add sel="doc" type="namespace::pref">urn:ns:xxx</add>

   This operation adds immediate preceding sibling node which MUST
   be a new namespace declaration to the <doc> element.
   The prefix of this new namespace white space text node is thus "pref" and if the
   namespace URI value is "urn:ns:xxx". "after", the
   corresponding following node.  If the 'ws' value is "both", both the
   preceding and following white space text nodes MUST be removed.

4.5.1.  Removing an Element

   An example for a removal of an addition element including all of a comment node:

   <add sel="doc/foo[@id='ert4773']" pos="before"><!-- comment --></add> its
   descendant, attribute and namespace nodes:

   <remove sel="doc/foo[@a='1']" ws="after"/>

   This operation adds a new comment node just before will remove the <foo> element as an well as the immediate preceding following
   sibling node.  This white space text node of the <foo> element.  If the immediate
   following sibling node is also an example how not a 'pos' attribute directive can be used.

   Some complexity arises when so called white space text nodes exist
   within node, an initial XML document.  The XPath 1.0 data model requires
   that error
   occurs.

4.5.2.  Removing an Attribute

   An example for a text removal of an attribute node:

   <remove sel="doc/@a"/>

   This will remove the 'a' attribute node from the <doc> element.




Urpalainen              Expires February 10, 2008              [Page 14]

Internet-Draft              Patch Operations                 August 2007


4.5.3.  Removing a Prefixed Namespace Declaration

   An example for a removal of a prefixed namespace node:

   <remove sel="doc/foo/namespace::pref"/>

   This will remove the 'pref' prefixed namespace node from the <foo>
   element.  Naturally this prefix MUST not have another text be associated with any node as an immediate
   sibling
   prior to the removal of this namespace node.  For instance, if an add operation is like this:

   <add sel="doc">
     <foo id="ert4773">This is a new child</foo></add>

   The <add> element has then two child nodes: a white space text  Also the parent node
   (a linefeed and two spaces) and a of
   this namespace declaration MUST be the <foo> element.  If

4.5.4.  Removing a Comment Node

   An example for a removal of a comment node:

   <remove sel="doc/comment()[1]"/>

   This will remove the existing
   last first comment node child of the <doc> element is element.

4.5.5.  Removing a text node, its content and Processing Instruction Node

   An example for a removal of a processing instruction node:

   <remove sel='doc/processing-instruction("test")'/>

   This will remove the
   white space text "test" processing instruction node content MUST then be combined together.
   Otherwise (white space) text nodes can be added just like elements
   and thus, the canonical form child of the patched XML document easily
   remains deterministic.  As several sibling nodes can be inserted with
   a single <add> operation,
   <doc> element.

4.5.6.  Removing a "pretty printing" style can easily be
   maintained.

   Still another Text Node

   An example about the handling for a removal of a text nodes.  Consider
   this example:

   <add sel="*/foo/text()[2]" pos="after">new<bar/>elem</add>

   The second node:

   <remove sel="doc/foo/text()[1]"/>

   This will remove the first text node child of the <foo> element is first located.
   The added new content contains two text nodes and an element.  As



Urpalainen              Expires September 7, 2006              [Page 10]

Internet-Draft              Patch Operations                  March 2006


   there can not be

   When removing an element, a comment or a processing instruction node
   which has immediate preceding and following sibling text nodes, nodes
   without the located target
   text node content and 'ws' directive, the first new text node content of these two text nodes MUST
   be combined together.  In essence, if the 'pos' value had been "before",
   the second new  The latter text node content would effectively have been
   prepended to thus disappears from the located target text node.

      Note:
   document.


5.  Error Handling

   It is still worth noting that text nodes MAY contain CDATA
      sections, the latter an error condition if any of which are not treated as separate nodes.
      Once these CDATA sections exist within the new text nodes, they
      SHOULD be moved unaltered to the patched XML document.

   While XML entities [2] cannot be patched with this framework, the
   references to other than predefined internal entities patch operations can exist
   within text nodes or attributes when the XML prolog contains those
   declarations.  These references may then be preserved if both the XML
   diff and the initial XML document have identical declarations within
   their prologs.  Otherwise, references may not be replaced with identical
   text as long as the "canonically equivalent" rule is obeyed.

4.4.  <replace> Element

   The <replace> element represents
   unambiguously fulfilled.  In other words, once a replacement operation: e.g. an
   existing element particular patch
   operation fails, it is updated with a new element or an attribute value error condition and processing of further



Urpalainen              Expires February 10, 2008              [Page 15]

Internet-Draft              Patch Operations                 August 2007


   patch operations is replaced with a new value.  This <replace> operation always
   updates a single node or node content at hardly sensible.  Also it is beyond the scope of
   this document to describe a time.

   The <replace> element type has generic error response.


6.  Usage of Patch Operations

   An XML diff document SHOULD contain only the nodes which have been
   modified.  However, when there's a 'sel' attribute.  If large collection of changes it
   could be desirable to exchange the
   located target node full document content instead.
   How this will be done in practice is an element, a comment or a processing
   instruction, then beyond the child scope of this
   document.


7.  Usage of Selector Values

   It is up to the <replace> element MUST also be application to decide what kind of selector values to
   use.  Positional element selectors like "*/*[3]/*[2]" provide the same type.  Otherwise
   shortest selectors, but care must to taken when using them.  When
   there are several removals of sibling elements, the <replace> positional
   element MUST have text
   content or it MAY be empty indexes change after each update.  Likewise these indexes
   change when replacing an new elements are inserted into the tree.  Using names
   with possible attribute value or a
   text node content.

   Examples predicates like "doc[@sel='foo']" is usually
   easier for replace operations, first a replacement of an element:

   <replace sel="doc/foo[@a='1']"><bar a="2"/></replace>

   This will update the <foo> element which has application, be it e.g. an 'a' attribute with
   value "1". auto diff tool but it leads
   to larger diff documents.


8.  XML Schema

   The located target element is replaced with the <bar>
   element.  So all descendant nodes, namespace declarations and
   attributes of the replaced <foo> element, if any existed, are thus
   removed.

   An example schema types for a replacement of an attribute value:

   <replace sel="doc/@a">new value</replace>

   This will replace the 'a' attribute content of the <doc> element with patch operation elements.

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE schema [
    <!ENTITY ncname "\i\c*">
    <!ENTITY qname  "(&ncname;:)?&ncname;">
    <!ENTITY aname  "@&qname;">
    <!ENTITY pos    "\[\d+\]">
    <!ENTITY attr   "\[&aname;='(.)*'\]|\[&aname;=&quot;(.)*&quot;\]">
    <!ENTITY valueq "\[(&qname;|\.)=&quot;(.)*&quot;\]">
    <!ENTITY value  "\[(&qname;|\.)='(.)*'\]|&valueq;">
    <!ENTITY cond   "&attr;|&value;|&pos;">
    <!ENTITY step   "(&qname;|\*)(&cond;)*">
    <!ENTITY piq    "processing-instruction\((&quot;&ncname;&quot;)?\)">
    <!ENTITY pi     "processing-instruction\(('&ncname;')?\)|&piq;">
    <!ENTITY id     "id\(('&ncname;')?\)|id\((&quot;&ncname;&quot;)?\)">
    <!ENTITY com    "comment\(\)">
    <!ENTITY text   "text\(\)">
    <!ENTITY nspa   "namespace::&ncname;">
    <!ENTITY cnodes "(&text;(&pos;)?)|(&com;(&pos;)?)|(&pi;(&pos;)?)">



Urpalainen              Expires September 7, 2006 February 10, 2008              [Page 11] 16]

Internet-Draft              Patch Operations                  March 2006


   the value "new value".  If the <replace> element is empty, the 'a'
   attribute MUST then remain in the patched                 August 2007


    <!ENTITY child  "&cnodes;|&step;">
    <!ENTITY last   "&child;|&aname;|&nspa;">
   ]>
   <xsd:schema
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified">

     <xsd:simpleType name="xpath">
       <xsd:restriction base="xsd:string">
         <xsd:pattern value="(/)?(&step;/)*(&last;)"/>
         <xsd:pattern value="(/)?&id;((/&step;)*(/&last;))?"/>
       </xsd:restriction>
     </xsd:simpleType>

     <xsd:simpleType name="xpath-add">
       <xsd:restriction base="xsd:string">
         <xsd:pattern value="(/)?(&step;/)*(&child;)"/>
         <xsd:pattern value="(/)?&id;((/&step;)*(/&child;))?"/>
       </xsd:restriction>
     </xsd:simpleType>

     <xsd:simpleType name="pos">
       <xsd:restriction base="xsd:string">
         <xsd:enumeration value="before"/>
         <xsd:enumeration value="after"/>
         <xsd:enumeration value="prepend"/>
       </xsd:restriction>
     </xsd:simpleType>

     <xsd:simpleType name="type">
       <xsd:restriction base="xsd:string">
         <xsd:pattern value="&aname;"/>
         <xsd:pattern value="&nspa;"/>
       </xsd:restriction>
     </xsd:simpleType>

     <xsd:complexType name="add">
       <xsd:complexContent mixed="true">
         <xsd:restriction base="xsd:anyType">
           <xsd:sequence>
             <xsd:any processContents="lax" namespace="##any"
                      minOccurs="0" maxOccurs="unbounded"/>
           </xsd:sequence>

           <xsd:attribute name="sel" type="xpath-add"
                          use="required"/>
           <xsd:attribute name="pos" type="pos"/>
           <xsd:attribute name="type" type="type"/>



Urpalainen              Expires February 10, 2008              [Page 17]

Internet-Draft              Patch Operations                 August 2007


         </xsd:restriction>
       </xsd:complexContent>
     </xsd:complexType>

     <xsd:complexType name="replace">
       <xsd:complexContent mixed="true">
         <xsd:restriction base="xsd:anyType">
           <xsd:sequence>
             <xsd:any processContents="lax" namespace="##any"
                      minOccurs="0" maxOccurs="1"/>
           </xsd:sequence>

           <xsd:attribute name="sel" type="xpath" use="required"/>
         </xsd:restriction>
       </xsd:complexContent>
     </xsd:complexType>

     <xsd:simpleType name="ws">
       <xsd:restriction base="xsd:string">
         <xsd:enumeration value="before"/>
         <xsd:enumeration value="after"/>
         <xsd:enumeration value="both"/>
       </xsd:restriction>
     </xsd:simpleType>

     <xsd:complexType name="remove">
       <xsd:attribute name="sel" type="xpath" use="required"/>
       <xsd:attribute name="ws" type="ws"/>
     </xsd:complexType>

   </xsd:schema>



9.  IANA Considerations

9.1.  XML document appearing like
   <doc a=""/>.

   An example for a replacement of Schema Registration

   This section registers a namespace new XML Schema.

      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
      urn:ietf:params:xml:schema:xml-patch-ops

      Registrant Contact:
      IETF, SIMPLE working group, <simple@ietf.org>
      Jari Urpalainen, <jari.urpalainen@nokia.com>





Urpalainen              Expires February 10, 2008              [Page 18]

Internet-Draft              Patch Operations                 August 2007


10.  Security Considerations

   Information exchanged within these patch operations can be highly
   sensitive.  Thus systems need to protect the <doc> element, otherwise an error occurs.

   An example for a replacement of a comment node:

   <replace sel="doc/comment()[1]"><!-- This is the new content
   --></replace>

   This will replace a comment node.  The located target node is the
   first comment node child of the <doc> element.

   An example for a replacement integrity and
   confidentiality of a processing instruction node:

   <replace sel='doc/processing-instruction("test")'><?test bar="foobar"
   ?></replace>

   This will replace this data.  Especially, the processing instruction node "test" whose parent transport protocol
   once it is the <doc> element.

   An example for a replacement of used SHOULD have capabilities to protect from possible
   threats.  For example, a text node:

   <replace sel="doc/foo/text()[1]">This is the new text content</
   replace>

   This will replace malicious man-in-the-middle attack could
   easily give misinformation.  However, all the first text node child of security considerations
   depend very much on the <foo> element. application which utilizes this framework.


11.  Acknowledgments

   The positional constraint "[1]" is not usually needed as the element
   content is rarely of mixed type author would like to thank Eva Leppanen, Mikko Lonnfors, Aki
   Niemi, Jonathan Rosenberg, Miguel A. Garcia, Anat Angel, Stephane
   Bortzmeyer and Dave Crocker for their valuable comments and Ted
   Hardie for his input and support.


12.  References

12.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C
         Recommendation REC-xml-20060816 , August 2006.

   [3]   "XML Path Language (XPath) Version 1.0", W3C Recommendation
         REC-xpath-19991116 , November 1999.

   [4]   "Namespaces in XML (Second Edition)", W3C Recommendation REC-
         xml-names-20060816 , August 2006.

   [5]   "XML Schema Part 1: Structures Second Edition", W3C
         Recommendation REC-xmlschema-1-20041028 , October 2004.

   [6] where several text node siblings
   typically exist.

   If a text node is updated and the <replace> element is empty, the
   text node MUST thus be removed as a text node MUST always have at
   least one character of data.

4.5.  <remove> Element

   The <remove> element represents   "Canonical XML 1.0", W3C Recommendation REC-xml-c14n-20010315 ,
         March 2001.

   [7]   "XML Schema Part 2: Datatypes Second Edition", W3C
         Recommendation PER-xmlschema-2-20040318 , October 2004.

   [8]   "xml:id Version 1.0 W3C Recommendation 9 September 2005", W3C
         Recommendation PR-xml-id-20050712 , September 2005.

   [9]   Yergeau, F., "UTF-8, a removal operation transformation format of e.g. an
   existing element or an attribute.

   The <remove> element type has two attributes: 'sel' and 'ws'.  The ISO 10646",



Urpalainen              Expires September 7, 2006 February 10, 2008              [Page 12] 19]

Internet-Draft              Patch Operations                  March 2006


   value of the optional 'ws' attribute is used to remove the possible
   white space text nodes that exist either as immediate following or
   preceding sibling nodes of the located target node.  The usage of
   'ws' attribute is only allowed when removing other types than text,
   attribute and namespace nodes.  If the value of 'ws' is "before", the
   purpose is to remove the immediate preceding sibling node which MUST
   be a white space text node and if the value is "after", the
   corresponding following node.  If the 'ws' value is "both", both the
   preceding                 August 2007


         RFC 2279, January 1998.

12.2.  Informative References

   [10]  "XML Path Language (XPath) Version 2.0", W3C Recommendation
         23 , January 2007.

   [11]  Murata, M., "XML media types", RFC 3023, January 2001.

   [12]  Rosenberg, J., "The Extensible Markup Language (XML)
         Configuration Access Protocol (XCAP)", RFC 4825, May 2007.

   [13]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [14]  Lonnfors, M., Leppanen, E., Khartabil, H., and following white space text nodes MUST be removed.

   Examples J. Urpalainen,
         "Presence Information Data format (PIDF) Extension for remove operations, first a removal of Partial
         Presence",  draft-ietf-simple-partial-pidf-format-08 (work in
         progress), November 2006.

   [15]  Rosenberg, J., "An Extensible Markup Language (XML) Document
         Format For Indicating Changes in XML Configuration Access
         Protocol (XCAP) Resources",  draft-ietf-simple-xcap-diff-05,
         March 2007.

   [16]  Niemi, A., "Session Initiation Protocol (SIP) Extension for
         Event State Publication", RFC 3903, October 2004.


Appendix A.  Informative Examples

   All following examples assume an element imaginary XML diff document
   including all of its descendant, attribute and namespace nodes:

   <remove sel="doc/foo[@a='1']" ws="after"/>

   This will remove the <foo> element as well as the immediate following
   sibling white space text node of the <foo> element.  If the immediate
   following sibling node is not a white space text node, these patch operation elements.

A.1.  Adding an error
   occurs. Element

   An example for a removal of an attribute node:

   <remove sel="doc/@a"/>

   This will remove the 'a' attribute node from the initial XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc> element.

   An example for a removal of
     <note>This is a namespace node:

   <remove sel="doc/foo/namespace::pref"/>

   This will remove the 'pref' prefixed namespace node from the <foo>
   element.  Naturally this prefix MUST not be associated with any node
   prior to the removal of this namespace node.  Also the parent node of
   this namespace declaration MUST be the <foo> element. sample document</note>
   </doc>


   An XML diff document:






Urpalainen              Expires February 10, 2008              [Page 20]

Internet-Draft              Patch Operations                 August 2007


   <?xml version="1.0" encoding="UTF-8"?>
   <diff>
     <add sel="doc"><foo id="ert4773">This is a new child</foo></add>
   </diff>


   A result 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>


A.2.  Adding an Attribute

   An example for initial XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <note>This is a removal of sample document</note>
   <foo id="ert4773">This is a comment node:

   <remove sel="doc/comment()[1]"/>

   This will remove the first comment node child of the new child</foo></doc>


   An XML diff document:

   <?xml version="1.0" encoding="UTF-8"?>
   <diff>
     <add sel="doc/foo[@id='ert4773']" type="@user">Bob</add>
   </diff>


   A result XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc> element.
     <note>This is a sample document</note>
   <foo id="ert4773" user="Bob">This is a new child</foo></doc>


A.3.  Adding a Prefixed Namespace Declaration

   An example for initial XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <note>This is a removal of sample document</note>
   <foo id="ert4773">This is a processing instruction node:

   <remove sel='doc/processing-instruction("test")'/>

   This will remove the "test" processing instruction node child of the
   <doc> element. new child</foo></doc>



Urpalainen              Expires September 7, 2006 February 10, 2008              [Page 13] 21]

Internet-Draft              Patch Operations                  March 2006                 August 2007


   An example for a removal of XML diff document:

   <?xml version="1.0" encoding="UTF-8"?>
   <diff>
     <add sel="doc" type="namespace::pref">urn:ns:xxx</add>
   </diff>


   A result XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc xmlns:pref="urn:ns:xxx">
     <note>This is a text node:

   <remove sel="doc/foo/text()[1]"/>

   This will remove the first text node child of the <foo> element.

   When removing an element, sample document</note>
   <foo id="ert4773">This is a comment or new child</foo></doc>


A.4.  Adding a processing instruction node
   which has immediate preceding and following sibling text nodes
   without the 'ws' directive, the content of these two text nodes MUST
   be combined together.  The latter text node thus disappears from the
   document.


5.  Error Handling

   It is an error condition if any of Comment Node with the patch operations can not be
   unambiguously fulfilled.  In other words, once a particular patch
   operation fails, it 'pos' Attribute

   An example initial XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <note>This is an error condition and processing of further
   patch operations a sample document</note>
   <foo id="ert4773">This is hardly sensible.  Also it a new child</foo></doc>


   An XML diff document:

 <?xml version="1.0" encoding="UTF-8"?>
 <diff>
   <add sel="doc/foo[@id='ert4773']" pos="before"><!-- comment --></add>
 </diff>


   A result XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <note>This is beyond the scope of
   this document to describe a generic error response.


6.  Usage of sample document</note>
   <!-- comment --><foo id="ert4773">This is a new child</foo></doc>


A.5.  Adding Multiple Nodes

   An example initial XML document:






Urpalainen              Expires February 10, 2008              [Page 22]

Internet-Draft              Patch Operations                 August 2007


   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <note>This is a sample document</note>
   </doc>


   An XML diff document SHOULD contain only the nodes which have been
   modified.  However, when there's document:

   <?xml version="1.0" encoding="UTF-8"?>
   <diff>
     <add sel="doc">
     <foo id="ert4773">This is a large collection of changes it MAY
   be desirable to exchange the full document content instead.  How this
   will be done in practice new child</foo></add>
   </diff>


   A result XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <note>This is beyond the scope of this document.


7.  Usage of Selector Values

   It a sample document</note>

     <foo id="ert4773">This is up to the application to decide the verbosity model for
   selector values.  Positional element selectors like "*/*[3]/*[2]"
   provide the shortest selectors, but care must to taken when using
   them.  When there are several removals of sibling elements, the
   positional element indexes change after each update.  Likewise these
   indexes change when a new elements are inserted into the tree.  Using
   names with possible attribute predicates like "doc[@sel='foo']" is
   usually easier for an application, be it e.g. child</foo></doc>


A.6.  Replacing an auto diff tool but
   it leads to larger diff documents.


8.  Full Example Element

   An example initial XML document where namespace qualified elements
   exist: document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <foo a="1">This is a sample document</foo>
   </doc>


   An XML diff document:

   <?xml version="1.0" encoding="UTF-8"?>
   <diff>
     <replace sel="doc/foo[@a='1']"><bar a="2"/></replace>
   </diff>


   A result XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <bar a="2"/>
   </doc>



Urpalainen              Expires September 7, 2006 February 10, 2008              [Page 14] 23]

Internet-Draft              Patch Operations                  March 2006                 August 2007


A.7.  Replacing an Attribute Value

   An example initial XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc xmlns="urn:ietf:params:xml:ns:xxx"
        xmlns:z="urn:ietf:params:xml:ns:yyy">
     <note>This a="test">
     <foo a="1">This is a sample document</note>
     <elem a="foo">
       <child/>
     </elem>
     <elem a="bar">
       <z:child/>
     </elem> document</foo>
   </doc>


   An imaginary XML diff document where prefix "p" corresponds the
   targetNamespace of this imaginary schema: document:

   <?xml version="1.0" encoding="UTF-8"?>
   <p:diff xmlns="urn:ietf:params:xml:ns:xxx"
           xmlns:y="urn:ietf:params:xml:ns:yyy"
           xmlns:p="urn:ietf:params:xml:ns:diff">

   <p:add sel="doc/elem[@a='foo']">  <!-- This
   <diff>
     <replace sel="doc/@a">new value</replace>
   </diff>


   A result XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc a="new value">
     <foo a="1">This is a new child -->
       <child id="ert4773">
         <y:node/>
       </child>
     </p:add>

   <p:replace sel="doc/note/text()">Patched doc</p:replace>

   <p:remove sel="*/elem[@a='bar']/y:child" ws="both"/>

   <p:add sel="*/elem[@a='bar']" type="@b">new attr</p:add>

   </p:diff>


   One possible form of the sample document</foo>
   </doc>


A.8.  Replacing a Namespace Declaration URI

   An example initial XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc xmlns:pref="urn:test">
     <foo a="1">This is a sample document</foo>
   </doc>


   An XML diff document:

   <?xml version="1.0" encoding="UTF-8"?>
   <diff>
     <replace sel="doc/namespace::pref">urn:new:xxx</replace>
   </diff>


   A result XML document after applying the
   patches: document:






Urpalainen              Expires September 7, 2006 February 10, 2008              [Page 15] 24]

Internet-Draft              Patch Operations                  March 2006                 August 2007


   <?xml version="1.0" encoding="UTF-8"?>
   <doc xmlns="urn:ietf:params:xml:ns:xxx"
        xmlns:z="urn:ietf:params:xml:ns:yyy">
     <note>Patched doc</note>
     <elem a="foo">
       <child/>
       <!-- This xmlns:pref="urn:new:xxx">
     <foo a="1">This is a new child sample document</foo>
   </doc>


A.9.  Replacing a Comment Node

   An example initial XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc xmlns:pref="urn:test">
     <foo a="1">This is a sample document</foo>
     <!-- comment -->
       <child id="ert4773">
         <z:node/>
       </child>
     </elem>
     <elem a="bar" b="new attr"/>
   </doc>


   The <node> and removed <child> element prefixes within the


   An XML diff
   document are different than what are document:

   <?xml version="1.0" encoding="UTF-8"?>
   <diff>
     <replace sel="doc/comment()[1]"><!-- This is the "identical" namespace
   declarations in new content
      --></replace>
   </diff>


   A result XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc xmlns:pref="urn:test">
     <foo a="1">This is a sample document</foo>
     <!-- This is the new content
      -->
   </doc>


A.10.  Replacing a Processing Instruction Node

   An example initial XML document.  If the document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <foo a="1">This is a sample document</foo>
     <?test foo="bar"?>
   </doc>


   An XML diff document:



Urpalainen              Expires February 10, 2008              [Page 25]

Internet-Draft              Patch Operations                 August 2007


   <?xml version="1.0" encoding="UTF-8"?>
   <diff>
     <replace sel='doc/processing-instruction("test")'
       ><?test bar="foobar"?></replace>
   </diff>


   A result XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <foo a="1">This is a sample document</foo>
     <?test bar="foobar"?>
   </doc>


A.11.  Replacing a Text Node

   An example initial XML
   document had used document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <foo a="1">This is a prefixed namespace declaration instead of the
   default one, the sample document</foo>
   </doc>


   An XML diff document could still have been document:

   <?xml version="1.0" encoding="UTF-8"?>
   <diff>
    <replace sel="doc/foo/text()[1]"
      >This is the same.
   The added new qualified elements would just have inherited that
   prefix.


9. text content</replace></diff>


   A result XML Schema

   The schema types for the patch operation elements. document:

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE schema [
    <!ENTITY ncname "[^:\I][^:\C]*">
    <!ENTITY qname  "(&ncname;:)?&ncname;">
    <!ENTITY aname  "@&qname;">
    <!ENTITY pos    "\[\d+\]">
    <!ENTITY attr   "\[&aname;='(.)*'\]|\[&aname;=&quot;(.)*&quot;\]">
    <!ENTITY valueq "\[(&qname;|\.)=&quot;(.)*&quot;\]">
    <!ENTITY value  "\[(&qname;|\.)='(.)*'\]|&valueq;">
    <!ENTITY cond   "&attr;|&value;|&pos;">
    <!ENTITY step   "(&qname;|\*)(&cond;)*">
    <!ENTITY piq    "processing-instruction\((&quot;&ncname;&quot;)?\)">
    <!ENTITY pi     "processing-instruction\(('&ncname;')?\)|&piq;">
    <!ENTITY id     "id\(('&ncname;')?\)|id\((&quot;&ncname;&quot;)?\)">
    <!ENTITY com    "comment\(\)">
    <!ENTITY
   <doc>
     <foo a="1">This is the new text   "text\(\)">
    <!ENTITY nspa   "namespace::&ncname;">
    <!ENTITY child  "&step;|&com;(&pos;)?|&text;(&pos;)?|&pi;(&pos;)?">
    <!ENTITY last   "&child;|&aname;|&nspa;">
   ]> content</foo>
   </doc>


A.12.  Removing an Element

   An example initial XML document:






Urpalainen              Expires September 7, 2006 February 10, 2008              [Page 16] 26]

Internet-Draft              Patch Operations                  March 2006


   <xsd:schema
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        elementFormDefault="qualified">

     <xsd:simpleType name="xpath">
       <xsd:restriction base="xsd:string">
         <xsd:pattern value="(/)?(&step;/)*(&last;)"/>
         <xsd:pattern value="(/)?&id;((/&step;)*(/&last;))?"/>
       </xsd:restriction>
     </xsd:simpleType>

     <xsd:simpleType name="xpath-add">
       <xsd:restriction base="xsd:string">
         <xsd:pattern value="(/)?(&step;/)*(&child;)"/>
         <xsd:pattern value="(/)?&id;((/&step;)*(/&child;))?"/>
       </xsd:restriction>
     </xsd:simpleType>

     <xsd:simpleType name="pos">
       <xsd:restriction base="xsd:string">
         <xsd:enumeration value="before"/>
         <xsd:enumeration value="after"/>
         <xsd:enumeration value="prepend"/>
       </xsd:restriction>
     </xsd:simpleType>

     <xsd:simpleType name="type">
       <xsd:restriction base="xsd:string">
         <xsd:pattern value="&aname;"/>
         <xsd:pattern value="&nspa;"/>
       </xsd:restriction>
     </xsd:simpleType>

     <xsd:complexType name="add">
       <xsd:complexContent mixed="true">
         <xsd:restriction base="xsd:anyType">
           <xsd:sequence>
             <xsd:any processContents="lax" namespace="##any"
                      minOccurs="0" maxOccurs="unbounded"/>
           </xsd:sequence>

           <xsd:attribute name="sel" type="xpath-add"
                          use="required"/>
           <xsd:attribute name="pos" type="pos"/>
           <xsd:attribute name="type" type="type"/>
         </xsd:restriction>
       </xsd:complexContent>
     </xsd:complexType>                 August 2007


   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <foo a="1">This is a sample document</foo>
   </doc>


   An XML diff document:

   <?xml version="1.0" encoding="UTF-8"?>
   <diff>
    <remove sel="doc/foo[@a='1']" ws="after"/>
   </diff>


   A result XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     </doc>


A.13.  Removing an Attribute

   An example initial XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc a="foo">
     <foo a="1">This is a sample document</foo>
   </doc>


   An XML diff document:

   <?xml version="1.0" encoding="UTF-8"?>
   <diff>
    <remove sel="doc/@a"/>
   </diff>


   A result XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <foo a="1">This is a sample document</foo>
   </doc>






Urpalainen              Expires September 7, 2006 February 10, 2008              [Page 17] 27]

Internet-Draft              Patch Operations                  March 2006


     <xsd:complexType name="replace">
       <xsd:complexContent mixed="true">
         <xsd:restriction base="xsd:anyType">
           <xsd:sequence>
             <xsd:any processContents="lax" namespace="##any"
                      minOccurs="0" maxOccurs="1"/>
           </xsd:sequence>

           <xsd:attribute name="sel" type="xpath" use="required"/>
         </xsd:restriction>
       </xsd:complexContent>
     </xsd:complexType>

     <xsd:simpleType name="ws">
       <xsd:restriction base="xsd:string">
         <xsd:enumeration value="before"/>
         <xsd:enumeration value="after"/>
         <xsd:enumeration value="both"/>
       </xsd:restriction>
     </xsd:simpleType>

     <xsd:complexType name="remove">
       <xsd:attribute name="sel" type="xpath" use="required"/>
       <xsd:attribute name="ws" type="ws"/>
     </xsd:complexType>

   </xsd:schema>



10.  IANA Considerations

10.1.                 August 2007


A.14.  Removing a Prefixed Namespace Declaration

   An example initial XML Schema Registration

   This section registers document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <foo a="1" xmlns:pref="urn:test"
      >This is a new sample document</foo>
     <!-- comment -->
   </doc>


   An XML Schema.

      URI:
      urn:ietf:params:xml:schema:xml-patch-ops

      Registrant Contact:
      IETF, SIMPLE working group, <simple@ietf.org>
      Jari Urpalainen, <jari.urpalainen@nokia.com>


11.  Security Considerations

   Information exchanged within these patch operations can be highly
   sensitive.  Thus systems need to protect the integrity and diff document:

   <?xml version="1.0" encoding="UTF-8"?>
   <diff>
     <remove sel="doc/foo/namespace::pref"/>
   </diff>


   A result XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <foo a="1">This is a sample document</foo>
     <!-- comment -->
   </doc>


A.15.  Removing a Comment Node

   An example initial XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <foo a="1">This is a sample document</foo>
     <!-- comment -->
   </doc>


   An XML diff document:

   <?xml version="1.0" encoding="UTF-8"?>
   <diff>
     <remove sel="doc/comment()[1]" ws="after"/>
   </diff>





Urpalainen              Expires February 10, 2008              [Page 28]

Internet-Draft              Patch Operations                 August 2007


   A result XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <foo a="1">This is a sample document</foo>
     </doc>


A.16.  Removing a Processing Instruction Node

   An example initial XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <foo a="1">This is a sample document</foo>
     <?test?>
   </doc>


   An XML diff document:

   <?xml version="1.0" encoding="UTF-8"?>
   <diff>
     <remove sel='doc/processing-instruction("test")'/>
   </diff>


   A result XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <foo a="1">This is a sample document</foo>

   </doc>


A.17.  Removing a Text Node

   An example initial XML document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <foo a="1">This is a sample document</foo>
   </doc>


   An XML diff document:




Urpalainen              Expires September 7, 2006 February 10, 2008              [Page 18] 29]

Internet-Draft              Patch Operations                  March 2006


   confidentiality of this data.  Especially, the transport protocol
   once it is used SHOULD have capabilities to protect from possible
   threats.  For example, a malicious man-in-the-middle attack could
   easily give misinformation.  However, all the security considerations
   depend very much on the application which utilizes this framework.


12.  Acknowledgments

   The author would like to thank Eva Leppanen, Mikko Lonnfors, Aki
   Niemi, Jonathan Rosenberg, Miguel A. Garcia, Anat Angel and Stephane
   Bortzmeyer for their valuable comments and Ted Hardie for his input
   and support.


13.  References

13.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C
        Recommendation REC-xml-20040204 , February 2004.

   [3]  "XML Path Language (XPath) Version 1.0", W3C Recommendation REC-
        xpath-19991116 , November 1999.

   [4]  "Canonical                 August 2007


   <?xml version="1.0" encoding="UTF-8"?>
   <diff>
     <remove sel="doc/foo/text()[1]"/>
   </diff>


   A result XML 1.0", W3C Recommendation REC-xml-c14n-20010315 ,
        March 2001.

   [5]  "Namespaces in XML", W3C Recommendation REC-xml-names-19990114 ,
        January 1999.

   [6]  "XML Schema Part 1: Structures Second Edition", W3C
        Recommendation REC-xmlschema-1-20041028 , October 2004.

   [7]  "XML Schema Part 2: Datatypes Second Edition", W3C
        Recommendation PER-xmlschema-2-20040318 , October 2004.

   [8]  "xml:id Version 1.0 W3C Recommendation 9 September 2005", W3C
        Recommendation PR-xml-id-20050712 , September 2005.

   [9]  Yergeau, F., "UTF-8, document:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc>
     <foo a="1"/>
   </doc>


A.18.  Several Patches With Namespace Mangling

   An example initial XML document where namespace qualified elements
   exist:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc xmlns="urn:ietf:params:xml:ns:xxx"
        xmlns:z="urn:ietf:params:xml:ns:yyy">
     <note>This is a transformation format sample document</note>
     <elem a="foo">
       <child/>
     </elem>
     <elem a="bar">
       <z:child/>
     </elem>
   </doc>


   An imaginary XML diff document where prefix "p" corresponds the
   targetNamespace of ISO 10646",
        RFC 2279, January 1998. this imaginary schema:

















Urpalainen              Expires September 7, 2006 February 10, 2008              [Page 19] 30]

Internet-Draft              Patch Operations                  March 2006


13.2.  Informative References

   [10]  "XML Path Language (XPath) Version 2.0", W3C Candidate
         Recommendation 3 20051103 , November 2005.

   [11]  Murata, M., "XML media types", RFC 3023, January 2001.

   [12]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [13]  Lonnfors, M., Leppanen, E., Khartabil, H.,                 August 2007


   <?xml version="1.0" encoding="UTF-8"?>
   <p:diff xmlns="urn:ietf:params:xml:ns:xxx"
           xmlns:y="urn:ietf:params:xml:ns:yyy"
           xmlns:p="urn:ietf:params:xml:ns:diff">

   <p:add sel="doc/elem[@a='foo']">  <!-- This is a new child -->
       <child id="ert4773">
         <y:node/>
       </child>
     </p:add>

   <p:replace sel="doc/note/text()">Patched doc</p:replace>

   <p:remove sel="*/elem[@a='bar']/y:child" ws="both"/>

   <p:add sel="*/elem[@a='bar']" type="@b">new attr</p:add>

   </p:diff>


   One possible form of the result XML document after applying the
   patches:

   <?xml version="1.0" encoding="UTF-8"?>
   <doc xmlns="urn:ietf:params:xml:ns:xxx"
        xmlns:z="urn:ietf:params:xml:ns:yyy">
     <note>Patched doc</note>
     <elem a="foo">
       <child/>
       <!-- This is a new child -->
       <child id="ert4773">
         <z:node/>
       </child>
     </elem>
     <elem a="bar" b="new attr"/>
   </doc>


   The <node> and J. Urpalainen,
         "Presence Information Data format (PIDF) Extension for Partial
         Presence",  draft-ietf-simple-partial-pidf-format-06 (work in
         progress), March 2006.

   [14]  Rosenberg, J., "An Extensible Markup Language (XML) Document
         Format For Indicating Changes in removed <child> element prefixes within the XML Configuration Access
         Protocol (XCAP) Resources",  draft-ietf-simple-xcap-diff-0x
         (work diff
   document are different than what are the "identical" namespace
   declarations in progress), ? 2006.

   [15]  Rosenberg, J., "The Extensible Markup Language (XML)
         Configuration Access Protocol (XCAP)",
          draft-ietf-simple-xcap-08, October 2005.

   [16]  Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
         August 2004.

   [17]  Sugano, H., "CPIM presence information data format", RFC 3863,
         May 2003.

   [18]  Niemi, A., "Session Initiation Protocol (SIP) Extension for
         Event State Publication", RFC 3903, October 2004. the initial XML document.  If the initial XML
   document had used a prefixed namespace declaration instead of the
   default one, the XML diff document could still have been the same.
   The added new qualified elements would just have inherited that
   prefix.






Urpalainen              Expires September 7, 2006 February 10, 2008              [Page 20] 31]

Internet-Draft              Patch Operations                  March 2006                 August 2007


Author's Address

   Jari Urpalainen
   Nokia Research Center
   Itamerenkatu 11-13
   Helsinki  00180
   Finland

   Phone: +358 7180 37686
   Email: jari.urpalainen@nokia.com









































Urpalainen              Expires September 7, 2006 February 10, 2008              [Page 21] 32]

Internet-Draft              Patch Operations                  March 2006                 August 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society. IETF
   Administrative Support Activity (IASA).





Urpalainen              Expires September 7, 2006 February 10, 2008              [Page 22] 33]

----