idnits 2.17.1 draft-ietf-simple-xml-patch-ops-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1828. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1839. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1846. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1852. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1324 has weird spacing: '... Change in...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2007) is 5977 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-10) exists of draft-ietf-simple-partial-pidf-format-08 == Outdated reference: A later version (-14) exists of draft-ietf-simple-xcap-diff-06 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE WG J. Urpalainen 3 Internet-Draft Nokia 4 Intended status: Standards Track November 16, 2007 5 Expires: May 19, 2008 7 An Extensible Markup Language (XML) Patch Operations Framework Utilizing 8 XML Path Language (XPath) Selectors 9 draft-ietf-simple-xml-patch-ops-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 19, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Extensible Markup Language (XML) documents are widely used as 43 containers for the exchange and storage of arbitrary data in today's 44 systems. In order to send changes to an XML document, an entire copy 45 of the new version must be sent, unless there is a means of 46 indicating only the portions that have changed. This document 47 describes an XML patch framework utilizing XML Path language (XPath) 48 selectors. These selector values and updated new data content 49 constitute the basis of patch operations described in this document. 50 In addition to them, with basic , and 51 directives a set of patches can then be applied to update an existing 52 XML document. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Basic Features and Requirements . . . . . . . . . . . . . . . 5 59 4. Patch Operations . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Locating the Target of a Patch . . . . . . . . . . . . . . 7 61 4.2. Namespace Mangling . . . . . . . . . . . . . . . . . . . . 7 62 4.2.1. Namespaces used in selectors . . . . . . . . . . . . . 8 63 4.2.2. Departures from XPath Requirements . . . . . . . . . . 8 64 4.2.3. Namespaces and added/changed content . . . . . . . . . 9 65 4.3. Element . . . . . . . . . . . . . . . . . . . . . . 11 66 4.3.1. Adding an Element . . . . . . . . . . . . . . . . . . 12 67 4.3.2. Adding an Attribute . . . . . . . . . . . . . . . . . 12 68 4.3.3. Adding a Prefixed Namespace Declaration . . . . . . . 13 69 4.3.4. Adding Node(s) with the 'pos' Attribute . . . . . . . 13 70 4.3.5. Adding Multiple Nodes . . . . . . . . . . . . . . . . 13 71 4.4. Element . . . . . . . . . . . . . . . . . . . . 14 72 4.4.1. Replacing an Element . . . . . . . . . . . . . . . . . 15 73 4.4.2. Replacing an Attribute Value . . . . . . . . . . . . . 15 74 4.4.3. Replacing a Namespace Declaration URI . . . . . . . . 15 75 4.4.4. Replacing a Comment Node . . . . . . . . . . . . . . . 15 76 4.4.5. Replacing a Processing Instruction Node . . . . . . . 16 77 4.4.6. Replacing a Text Node . . . . . . . . . . . . . . . . 16 78 4.5. Element . . . . . . . . . . . . . . . . . . . . . 16 79 4.5.1. Removing an Element . . . . . . . . . . . . . . . . . 16 80 4.5.2. Removing an Attribute . . . . . . . . . . . . . . . . 17 81 4.5.3. Removing a Prefixed Namespace Declaration . . . . . . 17 82 4.5.4. Removing a Comment Node . . . . . . . . . . . . . . . 17 83 4.5.5. Removing a Processing Instruction Node . . . . . . . . 17 84 4.5.6. Removing a Text Node . . . . . . . . . . . . . . . . . 17 85 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 18 86 5.1. Error Elements . . . . . . . . . . . . . . . . . . . . . . 18 87 6. Usage of Patch Operations . . . . . . . . . . . . . . . . . . 20 88 7. Usage of Selector Values . . . . . . . . . . . . . . . . . . . 20 89 8. XML Schema Types of Patch Operation Elements . . . . . . . . . 20 90 9. XML Schema of Patch Operation Errors . . . . . . . . . . . . . 23 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 10.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 25 93 10.2. application/patch-ops-error+xml MIME Type . . . . . . . . 25 94 10.3. Patch-Ops-Types XML Schema Registration . . . . . . . . . 26 95 10.4. Patch-Ops-Error XML Schema Registration . . . . . . . . . 26 97 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 98 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 99 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 101 13.2. Informative References . . . . . . . . . . . . . . . . . . 29 102 Appendix A. Informative Examples . . . . . . . . . . . . . . . . 29 103 A.1. Adding an Element . . . . . . . . . . . . . . . . . . . . 29 104 A.2. Adding an Attribute . . . . . . . . . . . . . . . . . . . 30 105 A.3. Adding a Prefixed Namespace Declaration . . . . . . . . . 30 106 A.4. Adding a Comment Node with the 'pos' Attribute . . . . . . 31 107 A.5. Adding Multiple Nodes . . . . . . . . . . . . . . . . . . 32 108 A.6. Replacing an Element . . . . . . . . . . . . . . . . . . . 32 109 A.7. Replacing an Attribute Value . . . . . . . . . . . . . . . 33 110 A.8. Replacing a Namespace Declaration URI . . . . . . . . . . 33 111 A.9. Replacing a Comment Node . . . . . . . . . . . . . . . . . 34 112 A.10. Replacing a Processing Instruction Node . . . . . . . . . 34 113 A.11. Replacing a Text Node . . . . . . . . . . . . . . . . . . 35 114 A.12. Removing an Element . . . . . . . . . . . . . . . . . . . 36 115 A.13. Removing an Attribute . . . . . . . . . . . . . . . . . . 36 116 A.14. Removing a Prefixed Namespace Declaration . . . . . . . . 37 117 A.15. Removing a Comment Node . . . . . . . . . . . . . . . . . 37 118 A.16. Removing a Processing Instruction Node . . . . . . . . . . 38 119 A.17. Removing a Text Node . . . . . . . . . . . . . . . . . . . 38 120 A.18. Several Patches With Namespace Mangling . . . . . . . . . 39 121 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40 122 Intellectual Property and Copyright Statements . . . . . . . . . . 42 124 1. Introduction 126 Extensible Markup Language (XML) [W3C.REC-xml-20060816] documents are 127 widely used as containers for the exchange and storage of arbitrary 128 data in today's systems. In order to send changes to an XML 129 document, an entire copy of the new version must be sent, unless 130 there is a means of indicating only the portions that have changed 131 (patches). 133 This document describes an XML patch framework which utilizes XML 134 Path language (XPath) [W3C.REC-xpath-19991116] selectors. An XPath 135 selector is used to pinpoint the specific portion of the XML that is 136 the target for the change. These selector values and updated new 137 data content constitute the basis of patch operations described in 138 this document. In addition to them, with basic , and 139 directives a set of patches can be applied to update an 140 existing target XML document. With these patch operations, a simple 141 semantics for data oriented XML documents 142 [W3C.REC-xmlschema-2-20041028] is achieved, that is, modifications 143 like additions, removals or substitutions of elements and attributes 144 can easily be performed. This document does not describe a full XML 145 diff format, only basic patch operation elements which can be 146 embedded within a full format which typically has additional 147 semantics. 149 As a one concrete example, in the Session Initiation Protocol (SIP) 150 [RFC3903] based presence system a partial PIDF XML document format 151 [I-D.ietf-simple-partial-pidf-format] consists of the existing PIDF 152 document format combined with the patch operations elements described 153 in this document. In general, patch operations can be used in any 154 application that exchanges XML documents, for example within the SIP 155 Events framework [RFC3265]. Yet another example is XCAP-diff 156 [I-D.ietf-simple-xcap-diff] which uses this framework for sending 157 partial updates of changes to XCAP [RFC4825] resources. 159 2. Conventions 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC 2119, BCP 14 164 [RFC2119] and indicate requirement levels for compliant 165 implementations. 167 The following terms are used in this document: 169 Target XML document: A target XML document that is going to be 170 updated with a set of patches. 172 XML diff document: An XML document that contains patch operation 173 elements, namespace declarations and all the document content 174 changes that are needed in order to transform a target XML 175 document into a new patched XML document. 177 Patched XML document: An XML document that results after applying 178 one or more patch operations defined in the XML diff document to 179 the target XML document. 181 Patch operation: A single change, i.e. a patch that is being applied 182 to update a target XML document. 184 Patch operation element: An XML element that represents a single 185 patch operation. 187 Type definition for an element: A W3C Schema type definition for an 188 element that describes a patch operation content. 190 In-scope namespace declaration: A list of all in-scope namespace 191 declarations within a context node. The QName (qualified name) 192 expansion of a context node is based on mapping a prefix with one 193 of these declarations. For an element, one namespace binding may 194 have an empty prefix. 196 Positional constraint: A number enclosed with square brackets. It 197 can be used as a location step predicate. 199 Located target node: A node which was found from the target XML 200 document with the aid of an XPath selector value. 202 White space text node: A text node which contains only white space. 204 3. Basic Features and Requirements 206 In this framework, XPath selector values and new data content are 207 embedded within XML elements, the names of which specify the 208 modification to be performed: , or . These 209 elements (patch operations) are defined by schema types with the W3C 210 Schema language [W3C.REC-xmlschema-1-20041028]. XPath selectors 211 pinpoint the target for a change and they are expressed as attributes 212 of these elements. The child node(s) of patch operation elements 213 contain the new data content. In general when applicable, the new 214 content SHOULD be moved unaltered to the patched XML document. 216 XML documents which are equivalent for the purposes of many 217 applications MAY differ in their physical representation. The aim of 218 this document is to describe a deterministic framework where the 219 canonical form with comments [W3C.REC-xml-c14n-20010315] of an XML 220 document determines logical equivalence. For example, white space 221 text nodes MUST be processed properly in order to fulfil this 222 requirement as white space is by default significant 223 [W3C.REC-xml-c14n-20010315]. 225 The specifications referencing these element schema types MUST define 226 the full XML diff format with an appropriate MIME type [RFC3023] and 227 a character set, e.g. UTF-8 [RFC3629]. For example, the partial 228 PIDF format [I-D.ietf-simple-partial-pidf-format] includes this 229 schema and describes additional definitions to produce a complete XML 230 diff format for partial presence information updates. 232 As the schema defined in this document does not declare any target 233 namespace, the type definitions inherit the target namespace of the 234 including schema. Therefore, additional namespace declarations 235 within the XML diff documents can be avoided. 237 It is anticipated that applications using these types will define 238 , and elements based on the corresponding 239 type definitions in this schema. In addition, an application may 240 reference only a subset of these type definitions. A future 241 extension can introduce other operations, e.g. with document oriented 242 models [W3C.REC-xmlschema-2-20041028] a operation and a text 243 node patching algorithm combined with would undoubtedly 244 produce smaller XML diff documents. 246 The instance document elements based on these schema type definitions 247 MUST be well formed and SHOULD be valid. 249 The following XPath 1.0 data model node types can be added, replaced 250 or removed with this framework: elements, attributes, namespaces, 251 comments, texts and processing instructions. The full XML prolog 252 including e.g. XML entities [W3C.REC-xml-20060816] and the root node 253 of an XML document cannot be patched according to this framework. 254 However, patching of comments and processing instructions of the root 255 node is allowed. Naturally the removal or addition of a document 256 root element is not allowed as any valid XML document MUST always 257 contain a single root element. Also note that support for external 258 entities is beyond the scope of this framework. 260 4. Patch Operations 262 An XML diff document contains a collection of patch operation 263 elements, including one or more , and 264 elements. These patch operations will be applied sequentially in the 265 document order. After the first patch has been applied to update a 266 target XML document, the patched XML document becomes a new 267 independent XML document against which the next patch will be 268 applied. This procedure repeats until all patches have successfully 269 been processed. 271 4.1. Locating the Target of a Patch 273 Each patch operation element contains a 'sel' attribute. The value 274 of this attribute is an XPath selector with a restricted subset of 275 the full XPath 1.0 recommendation. The 'sel' value is used to locate 276 a single unique target node from the target XML document. This 277 located node pinpoints the target for a change and usually it is an 278 element, which is e.g. either updated itself or some child node(s) 279 are added into it. It MAY also be for instance a comment node, after 280 which some other sibling node(s) are inserted. In any case, it is an 281 error condition if multiple nodes are found during the evaluation of 282 this selector value. 284 The XPath selections of the 'sel' attribute always start from the 285 root node of a document. Thus relative location paths SHOULD be used 286 so that the starting root node selection "/" can be omitted. When 287 locating elements in a document tree, a node test can either be a "*" 288 character or a QName [W3C.REC-xml-names-20060816]. A "*" character 289 selects all element children of the context node. Right after the 290 node test, a location step can contain one or more predicates in any 291 order. An attribute value comparison is one of the most typical 292 predicates. The string value of the current context node or a child 293 element may alternatively be used to identify elements in the tree. 294 The character ".", which denotes a current context node selection, is 295 an abbreviated form of "self::node()". Lastly, positional 296 constraints like "[2]" can also be used as an additional predicate. 298 An XPath 1.0 "id()" node-set function MAY also be used to identify 299 unique elements from the document tree. The schema that describes 300 the content model of the document MUST then use an attribute with the 301 type ID [W3C.REC-xmlschema-2-20041028] or with non-validating XML 302 parsers, an "xml:id" [W3C.WD-xml-id-20041109] attribute MUST have 303 been used within an instance document. 305 4.2. Namespace Mangling 307 The normal model for namespace prefixes is that they are local in 308 scope. Thus, an XML diff document MAY have different prefixes for 309 the namespaces used in the target document. The agent parsing the 310 diff document MUST resolve prefixes separately in both documents in 311 order to match the resulting QNames (qualified name) from each. 313 The XML diff document MUST contain declarations for all namespaces 314 used in the diff document. The diff document declarations are always 315 used to determine what namespaces apply within the diff document. 317 4.2.1. Namespaces used in selectors 319 A selector in a diff document may use prefixes when naming elements. 320 If it does use a prefix, the prefix must be looked up in the diff 321 document namespace declarations. 323 For example, the patch operation element of a diff document has an 324 in-scope namespace declaration "xmlns:a='foo:'" with a selector 325 "sel='a:bar'". The agent processing this patch MUST then look for 326 a 'bar' element qualified with the 'foo:' namespace regardless of 327 whether the 'foo:' namespace has a prefix assigned in the target 328 document or what that prefix is. 330 Default namespaces make this model a little more complicated. When 331 the diff document has a default namespace declaration, any element 332 selector without a prefix MUST be evaluated using that namespace. 334 For example, the patch operation element of a diff document has an 335 in-scope namespace declaration "xmlns='foo:'" with a selector 336 "sel='bar'". The agent processing this patch MUST then look for a 337 'bar' element qualified with the 'foo:' namespace, regardless of 338 whether the 'foo:' namespace has a prefix assigned in the target 339 document or what that prefix is. 341 Unqualified names are also possible. If there is no default 342 namespace declared, and an element name appears without a prefix, 343 then it is an unqualified element name. If this appears in a 344 selector, it MUST match an unqualified element in the target 345 document. 347 For example, the patch operation element of a diff document has 348 only one in-scope namespace declaration "xmlns:a='foo:'" with a 349 selector "sel='bar'". Since the 'bar' element has no prefix, and 350 there is no default namespace declaration in scope, the agent 351 processing this patch can only match the selector against a 'bar' 352 element that has no prefix and also no default namespace in scope. 354 4.2.2. Departures from XPath Requirements 356 The prefix matching rules described previously in this section are 357 different from those required in XPath 1.0 and 2.0 358 [W3C.REC-xpath20-20070123]. In XPath 1.0 a "bar" selector always 359 locates an unqualified element. In XPath 2.0 a "bar" selector 360 not only matches an unqualified element, but also matches a 361 qualified element which is in scope of a default namespace 362 declaration. In contrast, in this specification, a selector without 363 a prefix only matches one element, and it may match an element with 364 or without a prefix but only if the namespace it's qualified with (or 365 none) is an exact match. 367 The XPath 1.0 recommendation specifies "namespace-uri()" and 368 "local-name()" node-set functions which can be used within 369 predicates. These functions may be utilized during XPath 370 evaluations if there are no other means to "register" prefixes 371 with associated namespace URIs. They can also be used when 372 handling selections where default namespaces are attached to 373 elements. However, this specification does not allow the usage of 374 these functions. 376 4.2.3. Namespaces and added/changed content 378 Elements within the changed data content are also in scope of 379 namespace declarations. For example, when adding a new namespace 380 qualified element to the target XML document, the diff document MUST 381 contain a namespace declaration that applies to the element. The 382 agent processing the diff document MUST ensure that the target 383 document also contains the same namespace declaration. Similar to 384 XPath, the same namespace declaration in this context means that the 385 namespace URIs MUST be equal but the prefixes MAY be different in the 386 diff and target documents. 388 For example, if a new added element has a namespace 389 declaration reference to "xmlns:a='foo:'" in the diff document and 390 the target document has only a single in-scope namespace 391 declaration "xmlns:b='foo:'" at the insertion point, the namespace 392 reference MUST be changed so that a element will then 393 exist in the patched document. The same rule applies although 394 default namespaces were used in either or both of the documents, 395 the namespace URIs determine what will be the correct references 396 (prefixes) in the patched document. 398 When the new or changed content has elements which declare new 399 namespaces (locally scoped), these declarations are copied unaltered 400 (prefix and everything) from the XML diff document to the target XML 401 document. Default namespace declarations can only be added by this 402 way but prefixed namespace declarations MAY be added or removed with 403 XPath namespace axis semantics shown later in this document (look 404 Section 4.3.3). 406 A fairly difficult use case for these rules is found when the target 407 document has several namespace declarations in scope for the same 408 namespace. A target document might declare several different 409 prefixes for the same namespace. Normally, the agent applying the 410 diff document chooses *the* appropriate prefix for adding new 411 elements to the target document, but in this special case there's 412 more than one. These requirements create deterministic behavior for 413 this special and in practice rare case: 415 - If the diff document happens to use a prefix which is one of the 416 prefixes declared for the same namespace in the evaluation context 417 node of the target document, this prefix MUST be used in the 418 resulting patched document. An empty evaluable prefix and an 419 existing in-scope default namespace declaration means that the 420 default namespace MUST be chosen. In other words, the expanded names 421 are then equal within the diff and patched documents. 423 In an operation, the evaluation context node is the parent 424 element of the inserted node, for example with a selector "sel='*/ 425 bar'" and without a 'pos' attribute directive (look Section 4.3), 426 it is the element of the root document element. With 427 modifications of elements, the evaluation context node is the 428 parent element of the modified element, and in the previous 429 example thus the root document element. 431 - Secondly, the prefix (also empty) of the evaluation context node 432 MUST be chosen if the namespace URIs are equal. 434 - Lastly if the above two rules still don't apply, first all in-scope 435 namespace prefixes of the evaluation context node are arranged 436 alphabetically in an ascending order. If a default namespace 437 declaration exists, it is interpreted as the first entry in this 438 list. The prefix from the list is then chosen which appear as the 439 closest and just before the compared prefix if it were inserted into 440 the list. If the compared prefix were to exist before the first 441 prefix, the first prefix in the list MUST be selected (i.e. there's 442 no default namespace). 444 For example, if the list of in-scope prefixes in the target 445 document is "x", "y" and the compared prefix in the diff document 446 is "xx", then the "x" prefix MUST be chosen. If an "a" prefix 447 were evaluated, the "x" prefix, the first entry MUST be chosen. 448 If there were also an in-scope default namespace declaration, an 449 evaluable "a" prefix would then select the default declaration. 450 Note that unprefixed attributes don't inherit the default 451 namespace declaration. When adding qualified attributes, the 452 default namespace declaration is then not on this matching list of 453 prefixes (look Section 4.3.2). 455 Note that these requirements might mean that a resulting patched 456 document could contain unused and/or superfluous namespace 457 declarations. The resulting patched document MUST NOT be "cleaned 458 up" such that these namespace declarations are removed. 460 Note: In practice, the agent constructing a diff document can 461 usually freely select the appropriate prefixes for the namespace 462 declarations and it doesn't need to know or care about the actual 463 prefixes in the target document unless there are overlapping 464 declarations. In other words, the diff format content is 465 typically independent of the target documents usage of namespace 466 prefixes. However, it may be very useful to know where namespaces 467 are declared in the target document. The most typical use-case is 468 such though, that the agent generating a diff has both the 469 previous (target) and new (patched) documents available and 470 namespace declarations are thus exactly known. Note also, that in 471 a case where the target document is not exactly known, it is 472 allowed to use locally scoped namespace declarations, the 473 consequences of which are larger and less human-readable patched 474 documents. 476 4.3. Element 478 The element represents the addition of some new content to the 479 target XML document: e.g. a new element can be appended into an 480 existing element. 482 The new data content exists as the child node(s) of the 483 element. When adding attributes and namespaces the child node of the 484 element MUST be a single text node. Otherwise, the 485 element MAY contain any mixture of element, text, comment or 486 processing instruction nodes in any order. All children of the 487 element are then copied into a target XML document. The described 488 namespace mangling procedure applies to added elements, which include 489 all of their attribute, namespace and descendant nodes. 491 The element type has three attributes: 'sel', 'type' and 'pos'. 493 The value of the optional 'type' attribute is only used when adding 494 attributes and namespaces. Then the located target node MUST be an 495 element into which new attributes and namespace declarations are 496 inserted. When the value of this 'type' attribute equals "@attr", 497 the string "attr" is the name of the actual attribute being added. 498 The value of this new 'attr' attribute is the text node content of 499 the element. The less frequently used prefixed (i.e. 500 namespace-qualified) attributes can also be added. If the value of 501 the 'type' attribute equals "namespace::pref", "pref" is the actual 502 prefix string to be used for the namespace declaration in the patched 503 document and the text node content of the element contains the 504 corresponding namespace URI. 506 Note: The 'type' attribute is thus also an XPath selector, but it 507 only locates attributes and namespaces. Attribute axis 508 "attribute" has an abbreviated form "@" unlike the "namespace" 509 axis which doesn't have an abbreviated form. Double colons "::" 510 are used as an axis separator in XPath. 512 The value of the optional 'pos' attribute indicates the positioning 513 of new data content. It is not used when adding attributes or 514 namespaces. When neither 'type' nor 'pos' attribute exist, the 515 children of the element are then appended as the last child 516 node(s) of the located target element. When the value of 'pos' 517 attribute is "prepend" the new node(s) are added as the first child 518 node(s) of the located target element. With the value of "before" 519 the added new node(s) MUST be the immediate preceding sibling node(s) 520 and with "after" the immediate following sibling node(s) of the 521 located target node. 523 Some examples follow which describe the use cases of these 524 element attributes. The nodes are not namespace qualified and 525 prefixes are therefore not used and the whole XML diff content is not 526 shown in these examples, only patch operation elements. Full 527 examples are given in an Appendix A. 529 4.3.1. Adding an Element 531 An example for an addition of an element: 533 This is a new child 535 Once the element has been found from the target XML document, a 536 new element is appended as the last child node of the 537 element. The located target node: the element is naturally the 538 root element of the target XML document. The new element 539 contains an 'id' attribute and a child text node. 541 4.3.2. Adding an Attribute 543 An example for an addition of an attribute: 545 Bob 547 This operation adds a new 'user' attribute to the element which 548 was located by using an 'id' attribute value predicate. The value of 549 this new 'user' attribute is "Bob". 551 A similar patched XML document is achieved when using a validating 552 XML parser, if the 'sel' selector value had been 'id("ert4773")' and 553 if the data type of the 'id' attribute is "ID" 554 [W3C.REC-xmlschema-2-20041028]. 556 Note that with namespace qualified attributes, the prefix matching 557 rules within the 'type' attribute are evaluated with similar rules 558 described before in Section 4.2.3. Also note that then the possible 559 default namespace declaration of the context element isn't 560 applicable. 562 Note: As the 'sel' selector value MAY contain quotation marks, 563 escaped forms: """ or "'" can be used within attribute 564 values. However, it is often more appropriate to use the 565 apostrophe (') character as shown in these examples. An 566 alternative is also to interchange the apostrophes and quotation 567 marks. 569 4.3.3. Adding a Prefixed Namespace Declaration 571 An example for an addition of a prefixed namespace declaration: 573 urn:ns:xxx 575 This operation adds a new namespace declaration to the element. 576 The prefix of this new namespace node is thus "pref" and the 577 namespace URI is "urn:ns:xxx". 579 4.3.4. Adding Node(s) with the 'pos' Attribute 581 An example for an addition of a comment node: 583 585 This operation adds a new comment node just before the element 586 as an immediate preceding sibling node. This is also an example how 587 a 'pos' attribute directive can be used. 589 4.3.5. Adding Multiple Nodes 591 Some complexity arises when so called white space text nodes exist 592 within a target XML document. The XPath 1.0 data model requires that 593 a text node MUST NOT have another text node as an immediate sibling 594 node. For instance, if an add operation is like this: 596 597 This is a new child 599 The element has then two child nodes: a white space text node 600 (a linefeed and two spaces) and a element. If the existing 601 last child of the element is a text node, its content and the 602 white space text node content MUST then be combined together. 603 Otherwise (white space) text nodes can be added just like elements 604 and thus, the canonical form of the patched XML document easily 605 remains deterministic. As several sibling nodes can be inserted with 606 a single operation, a "pretty printing" style can easily be 607 maintained. 609 Still another example about the handling of text nodes. Consider 610 this example: 612 newelem 614 The second text node child of the element is first located. 615 The added new content contains two text nodes and an element. As 616 there can not be immediate sibling text nodes, the located target 617 text node content and the first new text node content MUST be 618 combined together. In essence, if the 'pos' value had been "before", 619 the second new text node content would effectively have been 620 prepended to the located target text node. 622 Note: It is still worth noting that text nodes MAY contain CDATA 623 sections, the latter of which are not treated as separate nodes. 624 Once these CDATA sections exist within the new text nodes, they 625 SHOULD be moved unaltered to the patched XML document. 627 While XML entities [W3C.REC-xml-20060816] cannot be patched with this 628 framework, the references to other than predefined internal entities 629 can exist within text nodes or attributes when the XML prolog 630 contains those declarations. These references may then be preserved 631 if both the XML diff and the target XML document have identical 632 declarations within their prologs. Otherwise, references may be 633 replaced with identical text as long as the "canonically equivalent" 634 rule is obeyed. 636 4.4. Element 638 The element represents a replacement operation: e.g. an 639 existing element is updated with a new element or an attribute value 640 is replaced with a new value. This operation always 641 updates a single node or node content at a time. 643 The element type has only a 'sel' attribute. If the 644 located target node is an element, a comment or a processing 645 instruction, then the child of the element MUST also be of 646 the same type. Otherwise the element MUST have text 647 content or it MAY be empty when replacing an attribute value or a 648 text node content. 650 4.4.1. Replacing an Element 652 An example for a replacement of an element: 654 656 This will update the element which has an 'a' attribute with 657 value "1". The located target element is replaced with the 658 element. So all descendant nodes, namespace declarations and 659 attributes of the replaced element, if any existed, are thus 660 removed. 662 4.4.2. Replacing an Attribute Value 664 An example for a replacement of an attribute value: 666 new value 668 This will replace the 'a' attribute content of the element with 669 the value "new value". If the element is empty, the 'a' 670 attribute MUST then remain in the patched XML document appearing like 671 . 673 4.4.3. Replacing a Namespace Declaration URI 675 An example for a replacement of a namespace URI: 677 urn:new:xxx 679 This will replace the URI value of 'pref' prefixed namespace node 680 with "urn:new:xxx". The parent node of the namespace declaration 681 MUST be the element, otherwise an error occurs. 683 4.4.4. Replacing a Comment Node 685 An example for a replacement of a comment node: 687 690 This will replace a comment node. The located target node is the 691 first comment node child of the element. 693 4.4.5. Replacing a Processing Instruction Node 695 An example for a replacement of a processing instruction node: 697 700 This will replace the processing instruction node "test" whose parent 701 is the element. 703 4.4.6. Replacing a Text Node 705 An example for a replacement of a text node: 707 This is the new text content 710 This will replace the first text node child of the element. 711 The positional constraint "[1]" is not usually needed as the element 712 content is rarely of mixed type [W3C.REC-xmlschema-1-20041028] where 713 several text node siblings typically exist. 715 If a text node is updated and the element is empty, the 716 text node MUST thus be removed as a text node MUST always have at 717 least one character of data. 719 4.5. Element 721 The element represents a removal operation of e.g. an 722 existing element or an attribute. 724 The element type has two attributes: 'sel' and 'ws'. The 725 value of the optional 'ws' attribute is used to remove the possible 726 white space text nodes that exist either as immediate following or 727 preceding sibling nodes of the located target node. The usage of 728 'ws' attribute is only allowed when removing other types than text, 729 attribute and namespace nodes. If the value of 'ws' is "before", the 730 purpose is to remove the immediate preceding sibling node which MUST 731 be a white space text node and if the value is "after", the 732 corresponding following node. If the 'ws' value is "both", both the 733 preceding and following white space text nodes MUST be removed. 735 4.5.1. Removing an Element 737 An example for a removal of an element including all of its 738 descendant, attribute and namespace nodes: 740 741 This will remove the element as well as the immediate following 742 sibling white space text node of the element. If the immediate 743 following sibling node is not a white space text node, an error 744 occurs. 746 4.5.2. Removing an Attribute 748 An example for a removal of an attribute node: 750 752 This will remove the 'a' attribute node from the element. 754 4.5.3. Removing a Prefixed Namespace Declaration 756 An example for a removal of a prefixed namespace node: 758 760 This will remove the 'pref' prefixed namespace node from the 761 element. Naturally this prefix MUST NOT be associated with any node 762 prior to the removal of this namespace node. Also the parent node of 763 this namespace declaration MUST be the element. 765 4.5.4. Removing a Comment Node 767 An example for a removal of a comment node: 769 771 This will remove the first comment node child of the element. 773 4.5.5. Removing a Processing Instruction Node 775 An example for a removal of a processing instruction node: 777 779 This will remove the "test" processing instruction node child of the 780 element. 782 4.5.6. Removing a Text Node 784 An example for a removal of a text node: 786 788 This will remove the first text node child of the element. 790 When removing an element, a comment or a processing instruction node 791 which has immediate preceding and following sibling text nodes 792 without the 'ws' directive, the content of these two text nodes MUST 793 be combined together. The latter text node thus disappears from the 794 document. 796 5. Error Handling 798 It is an error condition if any of the patch operations can not be 799 unambiguously fulfilled. In other words, once a particular patch 800 operation fails, it is an error condition and processing of further 801 patch operations is hardly sensible. 803 A new MIME error format is defined for applications which require 804 deterministic error handling when patching can not be applied. It is 805 anticipated that these error elements can be used within other MIME 806 types which allow extension elements. 808 5.1. Error Elements 810 The root element of the error document is . The 811 content of this element is a specific error condition. Each error 812 condition is represented by a different element. This allows for 813 different error conditions to provide different data about the nature 814 of the error. All error elements support a "phrase" attribute, which 815 can contain text meant for rendering to a human user. The optional 816 "xml:lang" MAY be used to describe the language of the "phrase" 817 attribute. Most of the error condition elements are supposed to 818 contain the patch operation element which caused the patch to fail. 820 The following error elements are defined by this specification: 822 : The validity constraints of 'sel', 823 'type', 'ws' or 'pos' attribute values MAY be indicated with this 824 error, i.e. non-allowable content has been used. Also this error 825 can be used to indicate if an added or a modified attribute 826 content is not valid, for example CDATA sections were used when a 827 new attribute was intended to be added. 829 : The patch could not be applied because the 830 diff and the patched document use different character sets. 832 : This indicates that the diff body of the 833 request was not a well-formed XML document or a valid XML document 834 according to its schema. 836 : An entity reference was found but 837 corresponding declaration could not be located or resolved. 839 : The namespace URI for the given prefix 840 could not be located or resolved, e.g. within the 'sel' attribute 841 a prefix was used but its declaration is missing from the target 842 document. 844 : The namespace URI value is not valid or the 845 target document did not have this declaration. 847 : The node types of a operation did 848 not match, i.e. for example the 'sel' selector locates an element 849 but the replaceable content is of text type. Also a 850 operation may locate a unique element, but replaceable content had 851 multiple nodes. 853 : A patch directive could not be fulfilled 854 because the given directives were not understood. 856 : The root element of the document 857 cannot be removed or another sibling element for the document root 858 element cannot be added. 860 : Patch failure related to XML prolog 861 nodes. 863 : A operation requires a 864 removal of a whitespace node which doesn't exist in the target 865 document. 867 : A single unique node (typically an element) could 868 not be located with the 'sel' attribute value. Also the location 869 of multiple nodes can lead to this error. 871 : The nodeset function id() is not 872 supported and thus attributes with the ID type are not known. 874 : The attribute xml:id as an ID attribute in XML 875 documents is not supported. 877 Additional error elements can be indicated within the root element from any namespace. However, the IETF MAY specify 879 additional error elements in the 880 "urn:ietf:params:xml:ns:patch-ops-error" namespace. 882 As an example, the following document indicates that it was attempted 883 to add a new element with whitespace into a document, but the 884 parent element could not be located: 886 887 890 893 some text added 894 895 897 6. Usage of Patch Operations 899 An XML diff document SHOULD contain only the nodes which have been 900 modified as the intention is to try to reduce bandwidth/storage 901 requirements. However, when there's a large collection of changes it 902 can be desirable to exchange the full document content instead. How 903 this will be done in practice is beyond the scope of this document. 905 Some applications MAY require that the full versioning history MUST 906 be indicated although the history had superfluous changes. This 907 framework doesn't mandate any specific behavior, applications MAY 908 decide the appropriate semantics themselves. Also in practice, 909 applications are free to select the proper algorithms when generating 910 diff document content. 912 7. Usage of Selector Values 914 It is up to the application to decide what kind of selector values to 915 use. Positional element selectors like "*/*[3]/*[2]" provide the 916 shortest selectors, but care must to taken when using them. When 917 there are several removals of sibling elements, the positional 918 element indexes change after each update. Likewise these indexes 919 change when new elements are inserted into the tree. Using names 920 with possible attribute predicates like "doc[@sel='foo']" is usually 921 easier for an application, be it e.g. an auto diff tool but it leads 922 to larger diff documents. 924 8. XML Schema Types of Patch Operation Elements 926 The schema types for the patch operation elements. 928 929 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 ]> 949 953 954 955 957 958 960 961 962 964 965 967 968 969 970 971 972 973 975 976 977 978 979 981 982 983 984 985 987 988 990 991 992 993 994 996 997 998 999 1000 1002 1003 1004 1005 1006 1008 1009 1010 1011 1012 1013 1014 1016 1017 1018 1019 1021 1023 9. XML Schema of Patch Operation Errors 1025 The patch operation errors definitions. 1027 1028 1035 1036 1039 1040 1041 1042 1043 1045 1046 1047 1048 1050 1052 1054 1056 1058 1060 1062 1064 1066 1068 1070 1072 1074 1076 1078 1081 1082 1083 1084 1085 1086 1088 1089 1090 1091 1092 1093 1094 1095 1096 1098 1100 10. IANA Considerations 1102 This memo calls for IANA to: 1104 o register a new XML namespace URN according to the procedures of 1105 RFC 3688 [RFC3688]. 1107 o register a new MIME type 'application/patch-ops-error+xml' 1108 according to the procedures of RFC 4288 [RFC4288] and guidelines 1109 in RFC 3023 [RFC3023]. 1111 o register two XML Schemas according to the procedures of RFC 3688 1112 [RFC3688]. 1114 10.1. URN Sub-Namespace Registration 1116 This specification registers a new XML namespace, as per the 1117 guidelines in RFC 3688 [RFC3688]. 1119 URI: The URI for this namespace is 1120 urn:ietf:params:xml:ns:patch-ops-error 1122 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1123 Jari Urpalainen (jari.urpalainen@nokia.com). 1125 XML: 1127 BEGIN 1128 1129 1131 1132 1133 1135 Patch-Ops Error Namespace 1136 1137 1138

Namespace for Patch-Ops Error Documents

1139

urn:ietf:params:xml:ns:patch-ops-error

1140

See RFCXXXX [[NOTE 1141 TO RFC-EDITOR/IANA: Please replace XXXX with the RFC Number of 1142 this specification]].

1143 1144 1145 END 1147 10.2. application/patch-ops-error+xml MIME Type 1149 MIME media type name: application 1151 MIME subtype name: patch-ops-error+xml 1153 Mandatory parameters: none 1155 Optional parameters: Same as charset parameter application/xml as 1156 specified in RFC 3023 [RFC3023]. 1158 Encoding considerations: Same as encoding considerations of 1159 application/xml as specified in RFC 3023 [RFC3023]. 1161 Security considerations: See Section 10 of RFC 3023 [RFC3023]. 1163 Interoperability considerations: none. 1165 Published specification: RFC XXXX [[NOTE TO RFC EDITOR: Please 1166 replace XXXX with the published RFC number of this 1167 specification.]]. 1169 Applications which use this media type: This document type has been 1170 used to support transport of Patch-Ops errors in RFC XXXX [[NOTE 1171 TO RFC EDITOR: Please replace XXXX with the published RFC number 1172 of this specification.]]. 1174 Additional Information: 1176 Magic Number: None 1178 File Extension: .xer 1180 Macintosh file type code: "TEXT" 1182 Personal and email address for further information: Jari 1183 Urpalainen, jari.urpalainen@nokia.com 1185 Intended usage: COMMON 1187 Author/Change controller: The IETF. 1189 10.3. Patch-Ops-Types XML Schema Registration 1191 This section registers a new XML Schema, the sole content of which is 1192 shown in Section 8. 1194 URI: 1195 urn:ietf:params:xml:schema:patch-ops 1197 Registrant Contact: 1198 IETF, SIMPLE working group, 1199 Jari Urpalainen, 1201 10.4. Patch-Ops-Error XML Schema Registration 1203 This section registers a new XML Schema, the sole content of which is 1204 shown in Section 9. 1206 URI: 1207 urn:ietf:params:xml:schema:patch-ops-error 1209 Registrant Contact: 1210 IETF, SIMPLE working group, 1211 Jari Urpalainen, 1213 11. Security Considerations 1215 Security considerations depend very much on the application which 1216 utilizes this framework. Since each application will have different 1217 needs, threat models, and security features, it will be necessary to 1218 consider these on an application-by-application basis. 1220 However, this framework utilizes a limited subset of XPath 1.0. 1221 Applications may thus be vulnerable to XPath injection attacks which 1222 can reveal some non-allowable content of an XML document. Injection 1223 attacks are most likely with shareable resources where access to a 1224 resource is limited to only some specific parts for a user, contrary 1225 to a typical use-case of this framework. To defend against those 1226 attacks the input MUST be sanitized which can be done for example by 1227 validating the diff-formats with these restrictive schemas. 1229 12. Acknowledgments 1231 The author would like to thank Lisa Dusseault for her efforts 1232 including BoF arrangements, comments and editing assistance. The 1233 author would also like to thank Eva Leppanen, Mikko Lonnfors, Aki 1234 Niemi, Jonathan Rosenberg, Miguel A. Garcia, Anat Angel, Stephane 1235 Bortzmeyer, Dave Crocker, Joel Halpern, Jeffrey Hutzelman, David Ward 1236 and Chris Newman for their valuable comments and Ted Hardie for his 1237 input and support. 1239 13. References 1241 13.1. Normative References 1243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1244 Requirement Levels", BCP 14, RFC 2119, March 1997. 1246 [W3C.REC-xml-20060816] 1247 Maler, E., Paoli, J., Bray, T., Yergeau, F., and C. 1248 Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 1249 (Fourth Edition)", World Wide Web Consortium 1250 Recommendation REC-xml-20060816, August 2006, 1251 . 1253 [W3C.REC-xpath-19991116] 1254 DeRose, S. and J. Clark, "XML Path Language (XPath) 1255 Version 1.0", World Wide Web Consortium 1256 Recommendation REC-xpath-19991116, November 1999, 1257 . 1259 [W3C.REC-xml-names-20060816] 1260 Hollander, D., Bray, T., Layman, A., and R. Tobin, 1261 "Namespaces in XML 1.0 (Second Edition)", World Wide Web 1262 Consortium Recommendation REC-xml-names-20060816, 1263 August 2006, 1264 . 1266 [W3C.REC-xmlschema-1-20041028] 1267 Beech, D., Thompson, H., Maloney, M., and N. Mendelsohn, 1268 "XML Schema Part 1: Structures Second Edition", World Wide 1269 Web Consortium Recommendation REC-xmlschema-1-20041028, 1270 October 2004, 1271 . 1273 [W3C.REC-xml-c14n-20010315] 1274 Boyer, J., "Canonical XML Version 1.0", World Wide Web 1275 Consortium Recommendation REC-xml-c14n-20010315, 1276 March 2001, 1277 . 1279 [W3C.REC-xmlschema-2-20041028] 1280 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1281 Second Edition", World Wide Web Consortium 1282 Recommendation REC-xmlschema-2-20041028, October 2004, 1283 . 1285 [W3C.WD-xml-id-20041109] 1286 Veillard, D., Walsh, N., and J. Marsh, "xml:id Version 1287 1.0", W3C LastCall WD-xml-id-20041109, November 2004. 1289 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1290 10646", STD 63, RFC 3629, November 2003. 1292 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1293 Types", RFC 3023, January 2001. 1295 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1296 January 2004. 1298 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1299 Registration Procedures", BCP 13, RFC 4288, December 2005. 1301 13.2. Informative References 1303 [W3C.REC-xpath20-20070123] 1304 Berglund, A., Fernandez, M., Chamberlin, D., Boag, S., 1305 Robie, J., Kay, M., and J. Simeon, "XML Path Language 1306 (XPath) 2.0", World Wide Web Consortium 1307 Recommendation REC-xpath20-20070123, January 2007, 1308 . 1310 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 1311 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1313 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1314 Event Notification", RFC 3265, June 2002. 1316 [I-D.ietf-simple-partial-pidf-format] 1317 Lonnfors, M., "Presence Information Data format (PIDF) 1318 Extension for Partial Presence", 1319 draft-ietf-simple-partial-pidf-format-08 (work in 1320 progress), November 2006. 1322 [I-D.ietf-simple-xcap-diff] 1323 Urpalainen, J. and J. Rosenberg, "An Extensible Markup 1324 Language (XML) Document Format for Indicating A Change in 1325 XML Configuration Access Protocol (XCAP) Resources", 1326 draft-ietf-simple-xcap-diff-06 (work in progress), 1327 August 2007. 1329 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 1330 for Event State Publication", RFC 3903, October 2004. 1332 Appendix A. Informative Examples 1334 All following examples assume an imaginary XML diff document 1335 including these patch operation elements. 1337 A.1. Adding an Element 1339 An example target XML document: 1341 1342 1343 This is a sample document 1344 1345 An XML diff document: 1347 1348 1349 This is a new child 1350 1352 A result XML document: 1354 1355 1356 This is a sample document 1357 This is a new child 1359 A.2. Adding an Attribute 1361 An example target XML document: 1363 1364 1365 This is a sample document 1366 This is a new child 1368 An XML diff document: 1370 1371 1372 Bob 1373 1375 A result XML document: 1377 1378 1379 This is a sample document 1380 This is a new child 1382 A.3. Adding a Prefixed Namespace Declaration 1384 An example target XML document: 1386 1387 1388 This is a sample document 1389 This is a new child 1391 An XML diff document: 1393 1394 1395 urn:ns:xxx 1396 1398 A result XML document: 1400 1401 1402 This is a sample document 1403 This is a new child 1405 A.4. Adding a Comment Node with the 'pos' Attribute 1407 An example target XML document: 1409 1410 1411 This is a sample document 1412 This is a new child 1414 An XML diff document: 1416 1417 1418 1419 1421 A result XML document: 1423 1424 1425 This is a sample document 1426 This is a new child 1428 A.5. Adding Multiple Nodes 1430 An example target XML document: 1432 1433 1434 This is a sample document 1435 1437 An XML diff document: 1439 1440 1441 1442 This is a new child 1443 1445 A result XML document: 1447 1448 1449 This is a sample document 1451 This is a new child 1453 A.6. Replacing an Element 1455 An example target XML document: 1457 1458 1459 This is a sample document 1460 1462 An XML diff document: 1464 1465 1466 1467 1469 A result XML document: 1471 1472 1473 1474 1476 A.7. Replacing an Attribute Value 1478 An example target XML document: 1480 1481 1482 This is a sample document 1483 1485 An XML diff document: 1487 1488 1489 new value 1490 1492 A result XML document: 1494 1495 1496 This is a sample document 1497 1499 A.8. Replacing a Namespace Declaration URI 1501 An example target XML document: 1503 1504 1505 This is a sample document 1506 1508 An XML diff document: 1510 1511 1512 urn:new:xxx 1513 1514 A result XML document: 1516 1517 1518 This is a sample document 1519 1521 A.9. Replacing a Comment Node 1523 An example target XML document: 1525 1526 1527 This is a sample document 1528 1529 1531 An XML diff document: 1533 1534 1535 1537 1539 A result XML document: 1541 1542 1543 This is a sample document 1544 1546 1548 A.10. Replacing a Processing Instruction Node 1550 An example target XML document: 1552 1553 1554 This is a sample document 1555 1556 1557 An XML diff document: 1559 1560 1561 1563 1565 A result XML document: 1567 1568 1569 This is a sample document 1570 1571 1573 A.11. Replacing a Text Node 1575 An example target XML document: 1577 1578 1579 This is a sample document 1580 1582 An XML diff document: 1584 1585 1586 This is the new text content 1589 A result XML document: 1591 1592 1593 This is the new text content 1594 1596 A.12. Removing an Element 1598 An example target XML document: 1600 1601 1602 This is a sample document 1603 1605 An XML diff document: 1607 1608 1609 1610 1612 A result XML document: 1614 1615 1616 1618 A.13. Removing an Attribute 1620 An example target XML document: 1622 1623 1624 This is a sample document 1625 1627 An XML diff document: 1629 1630 1631 1632 1634 A result XML document: 1636 1637 1638 This is a sample document 1640 1642 A.14. Removing a Prefixed Namespace Declaration 1644 An example target XML document: 1646 1647 1648 This is a sample document 1650 1651 1653 An XML diff document: 1655 1656 1657 1658 1660 A result XML document: 1662 1663 1664 This is a sample document 1665 1666 1668 A.15. Removing a Comment Node 1670 An example target XML document: 1672 1673 1674 This is a sample document 1675 1676 1678 An XML diff document: 1680 1681 1682 1684 1686 A result XML document: 1688 1689 1690 This is a sample document 1691 1693 A.16. Removing a Processing Instruction Node 1695 An example target XML document: 1697 1698 1699 This is a sample document 1700 1701 1703 An XML diff document: 1705 1706 1707 1708 1710 A result XML document: 1712 1713 1714 This is a sample document 1716 1718 A.17. Removing a Text Node 1720 An example target XML document: 1722 1723 1724 This is a sample document 1725 1726 An XML diff document: 1728 1729 1730 1731 1733 A result XML document: 1735 1736 1737 1738 1740 A.18. Several Patches With Namespace Mangling 1742 An example target XML document where namespace qualified elements 1743 exist: 1745 1746 1748 This is a sample document 1749 1750 1751 1752 1753 1754 1755 1757 An imaginary XML diff document where prefix "p" corresponds the 1758 targetNamespace of this imaginary schema: 1760 1761 1765 1766 1767 1768 1769 1771 Patched doc 1773 1775 new attr 1777 1779 One possible form of the result XML document after applying the 1780 patches: 1782 1783 1785 Patched doc 1786 1787 1788 1789 1790 1791 1792 1793 1794 1796 The and removed element prefixes within the XML diff 1797 document are different than what are the "identical" namespace 1798 declarations in the target XML document. If the target XML document 1799 had used a prefixed namespace declaration instead of the default one, 1800 the XML diff document could still have been the same. The added new 1801 qualified elements would just have inherited that prefix. 1803 Author's Address 1805 Jari Urpalainen 1806 Nokia 1807 Itamerenkatu 11-13 1808 Helsinki 00180 1809 Finland 1811 Phone: +358 7180 37686 1812 Email: jari.urpalainen@nokia.com 1814 Full Copyright Statement 1816 Copyright (C) The IETF Trust (2007). 1818 This document is subject to the rights, licenses and restrictions 1819 contained in BCP 78, and except as set forth therein, the authors 1820 retain all their rights. 1822 This document and the information contained herein are provided on an 1823 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1824 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1825 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1826 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1827 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1828 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1830 Intellectual Property 1832 The IETF takes no position regarding the validity or scope of any 1833 Intellectual Property Rights or other rights that might be claimed to 1834 pertain to the implementation or use of the technology described in 1835 this document or the extent to which any license under such rights 1836 might or might not be available; nor does it represent that it has 1837 made any independent effort to identify any such rights. Information 1838 on the procedures with respect to rights in RFC documents can be 1839 found in BCP 78 and BCP 79. 1841 Copies of IPR disclosures made to the IETF Secretariat and any 1842 assurances of licenses to be made available, or the result of an 1843 attempt made to obtain a general license or permission for the use of 1844 such proprietary rights by implementers or users of this 1845 specification can be obtained from the IETF on-line IPR repository at 1846 http://www.ietf.org/ipr. 1848 The IETF invites any interested party to bring to its attention any 1849 copyrights, patents or patent applications, or other proprietary 1850 rights that may cover technology that may be required to implement 1851 this standard. Please address the information to the IETF at 1852 ietf-ipr@ietf.org. 1854 Acknowledgment 1856 Funding for the RFC Editor function is provided by the IETF 1857 Administrative Support Activity (IASA).