xml-patch-ops-01 An XML Patch operations framework

1. Jari Urpalainen IETF64 xml-patch-ops-01An XML Patch operations framework

2. Major concern in IETF-61: partial-pidf-format-02 and xcap-package had some overlapping Other event packages that describe xml-patching with their own semantics: watcher-info, conference-info, presence filtering etc. How about describing common semantics so that implementations actually need less code ? Why a framework ? Applications utilizing these patch operations may need more features (or probably even less) Easy to “include” these semantics into the framing document Why ?

3. Preserves a predictable canonical format of the patched document. Tries to produce human readable and as short and simple patch documents as possible. XCAP has approximately similar semantics embedded within the spec -> reuse that logic as much as possible: DELETE is similar, but PUT is separated into <add> and <replace>, however. element, attribute, text, namespace, PI and comment nodes (no root) can be patched. Updated/added elements contain all the namespace declarations, attribute and descendant nodes. General features/requirements

4. Based on a very restricted set of XPath 1.0 (schema patterns) Patch model: first the single unique target node for the patch is located and then the relevant change is being done. The changed/added content should appear as it is given Child node(s) of the patch-operation elements are equivalent of the (PUT) body of the XCAP request The verbosity of the selector model (i.e. *[2]) is chosen by the client If * with a positional constraint is used, a conditional patch is a necessity General features continue

5. Framework properties • It doesn’t describe any transport layer or a content-type, but it is targeted to be used in SIP (event packages/PUBLISH); especially partial PIDF. • No targetNamespace in the schema -> the types are intended to be included within the framing XML schema (a chameleon namespace design), i.e. no need for a new namespace declaration. • Operations easily extensible or they can be restricted. • The framing schema can also define new operations • Otherwise the framing schema just needs to simply define <add>, <remove> and <replace> elements based on these schema types

6. XPath location paths usually contain qualified elements The “body” contains also usually qualified elements -> define namespace declarations within the framing patch document: xmlns="urn:foo" <add sel="root"><bar xmlns:p=”urn:bar”/></add> The namespace URI of the<bar> element is thus “urn:foo” (==the default namespace declaration URI) Unlike XPath 1.0, the “root” selection above means thus in XPath 1.0 semantics: ‘*[local-name()=”root”][namespace-uri()=”urn:foo”]’ The “urn:bar” declaration appears as is within the patched document after the patch has been applied. Namespace challenges

7. The receiver adds <bar/> as the last child node(element) of the <root> element (default behavior) The target document context namespace is used for the <bar> element, i.e. the in-scope namespace from the patched document which has the ”urn:foo” namespace URI is selected for the <bar> element. The namespace URIs must be equal, only when there are several similar in-scope declarations, the declaration with the same prefix is selected. Thus the operation below produces exactly the same result than the previous example: xmlns:pre="urn:foo" <add sel="pre:root"><pre:bar xmlns:p=”urn:bar”/></add> Namespace challenges continue

8. Some documents (e.g. PIDF) can contain very many namespace declarations, thus the same declaration should not be repeated several times within the document Namespace declarations can be added using XPath namespace axis semantics <add sel="*" type="namespace::f">urn:foo</add> Patching namespace declarations

9. Not all whitespace is insignificant -> preserve the given whitespace nodes that exist within the “body” of the request XPath data model requires that a text node cannot have another text node as a sibling node. Thus text node contents must be combined together: if e.g. an element is removed between two text nodes when adding a text node when there’s an existing text node (as a sibling). Maintains easily “pretty printing” style (if so desired): during the removal of e.g. elements, the following or preceding sibling whitespace node may need to be removed. the model allows adding several sibling nodes at the same time, e.g. element + whitespace node. Whitespace handling

10. <add sel="*"><foo/></add> <add sel="*/foo" type="@a">1</add> <add sel="*" type="namespace::f">urn:foo</add> <add sel="*/foo[1]" pos="before"> <foo b='bar'> <!--comment node --> <bar xml:id="r123"/> </foo> </add> <replace sel="*/foo"><bar/></replace> <replace sel="*/foo[@a='1']/@a">2</replace> <replace sel="*"><root xmlns="urn:ns"/></replace> <replace sel="*/foo/text()">New text</replace> <remove sel="*/foo[1]"/> <remove sel="*/foo[@a='1']/@a"/> <remove sel='id("r123")' ws=”before”/> XML patch-ops examples

11. xml:id and xs:id type usage with id(“x123”) selector: some clarification text needed Somewhat overlapping proposals/rivals: http://xmldb-org.sourceforge.net/xupdate http://www.ietf.org/internet-drafts/draft-mouat-xml-patch-00.txt http://www.ietf.org/internet-drafts/draft-rosenberg-simple-xcap-change-log-00.txt Several other “xml-patching” models in IETF specs that aren’t based on XPath Running code On-line tool: http://validate.openlaboratory.net/patch/ Open source (LGPL) C-implementation: http://xmlpatch.sourceforge.net/ ISSUES ?