XML Patch Operations based on XPath selectors

Jari UrpalainenIETF62 Minneapolis

Short overview

● Purpose was to remove the overlapping parts of xcap-diff and partial-pidf which reference patch-ops

● ~XCAP PUT and DELETE semantics. Patch operations are embedded within a transported XML document

● Uses XPath 1.0 compatible selectors● Combines several requests: <add>, <replace> and

<remove> with optional data onto a single XML doc● XML Schema defines only types without any

targetNamespace -> the elements inherit the namespace of the including Schema

Changes

● The names in location steps are fully namespace qualified.

● The framing document (xcap-diff, pidf-diff etc.) carries all the namespace definitions that are needed to apply the patch requests

● The added or modified data content is also fully namespace qualified.

Open Issues/BUGS

● Whitespace text node handling in <add> and <remove>

● In addition to above lack of XPath data model nodes: namespaces, comments and processing instructions

● Lack of the ability to say: I want to add these nodes immediately before/after this element that already exist within the patched document

Adding namespace definitions

● namespace axis of XPath 1.0 does the trick<add sel="root" type="namespace::prefix">urn:xml:ns:something</add>

● value of “sel” selects the element where the namespace definition will be added (similar to adding an attribute with “@”)

<remove sel="root/namespace::prefix"/>

<replace sel="root/namespace::prefix">urn:xml:ns:something</replace>

● value of “sel” selects the namespace node

<add>● except attribute and namespace nodes this will

always (by default) append elements, text nodes, comments and processing instructions as the last child(ren)

<add sel="root">

<!-- This is a comment -->

<new-element a=”1”/><new-element a=”2”/></add>

● This allows an easy handling of whitespace text nodes as well as several siblings at the same time

<add> parameters

● the value of 'sel' attribute selects a single unique element from the patched doc● 'pos' attribute: “to” [default], “before”, “after”

● “before” = immediate preceding sibling node● “after” = immediate following sibling node● “to” = last child(ren) node or

attribute/namespace● 'type' attribute; values: node() [default], text(), @attr, namespace::prefix● child element(s) or text content of <add> = the new/updated XML fragment(s) or values for ns/attr

Add before and after● XPath 1.0 defines axises: preceding-sibling and

following-sibling which could be used:<add sel="root/elem[@a='1']" type="preceding-sibling::node()[1]

[self::comment()]">This is a comment</add>

● instead a much simpler model using “pos” attribute can be used:

<add sel="root/elem[@a='1']" pos=”before"><!-- This is a comment --></add>

<add sel="root/elem[@a='1']" pos=”after">

<!-- This is a new added node --><new-node a=”1”>

</add>

<replace>● Only one “sel” selector (must locate a unique node)● Last location step includes comment(), processing-

instruction(“x”) and text().<replace sel="root/elem[@a='1']"><update/></replace>

<replace sel="root/@a">new attr value</replace>

<replace sel="root/namespace::prefix">urn:new</replace>

<replace sel="root/comment()[1]">This is a new comment</replace>

<replace sel="root/processing-instruction('foo')">bar="foobar"</replace>

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

<remove>● whitespace text nodes somewhat problematicA.<remove sel="root/text()[1]"/>

<remove sel="root/elem[@a='1']"/>

B.<remove sel="root/text()[1] | root/elem[@a='1']"/>

C.<remove sel="root/elem[@a='1']/preceding-sibling::text()[1] | root/elem[@a='1']"/>

The proposed model (similar to C, but simpler): ● in addition to 'sel' an optional whitespace attribute

'ws': "before", "after", "both", "none" [default]<remove sel="root/elem[@a='1']" ws="before"/>

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE document [ <!ENTITY ncname "[^:\I][^:\C]*"> <!ENTITY qname "(&ncname;:)?&ncname;"> <!ENTITY aname "@&qname;"> <!ENTITY pos_t "\[\d+\]"> <!ENTITY attr_t "\[&aname;=('|&quot;)[.\n]*('|&quot;)\]"> <!ENTITY name_t "\[(&qname;|\.)=('|&quot;)[.\n]*('|&quot;)\]"> <!ENTITY cond "(&attr_t;|&name_t;)?(&pos_t;)?|(&pos_t;)?(&attr_t;|&name_t;)?"> <!ENTITY step "(&qname;|\*)(&cond;)?"> <!ENTITY pi "processing-instruction\((('|&quot;)&qname;('|&quot;))?\)"> <!ENTITY comm "comment\(\)"> <!ENTITY text "text\(\)"> <!ENTITY nspace "namespace::&ncname;"> <!ENTITY last "&step;|&aname;|&nspace;|(&comm;(&pos_t;)?)|&text;(&pos_t;)?|&pi;(&pos_t;)?">]><xsd:schema ... <xsd:simpleType name="xpath"> <xsd:restriction base="xsd:string"> <xsd:pattern value="(&step;/)*(&last;)"/> </xsd:restriction> </xsd:simpleType></xsd:schema>

Impact on xcap-diff & pidf-diff etc.

● Common model for applying XML changes● XML Schemas include patch-ops which is only a

framework for patch operations● Content-Types are defined according to the

including schema within xcap-diff and pidf-diff etc.

● As these operations describe the model to patch the full XPath 1.0 data model node types, applications may either extend or restrict these as desired