XML Patch Operations based on XPath selectors - PowerPoint PPT Presentation

jari urpalainen ietf62 minneapolis n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
XML Patch Operations based on XPath selectors PowerPoint Presentation
Download Presentation
XML Patch Operations based on XPath selectors

play fullscreen
1 / 12
XML Patch Operations based on XPath selectors
127 Views
Download Presentation
mercury
Download Presentation

XML Patch Operations based on XPath selectors

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Jari Urpalainen IETF62 Minneapolis XML Patch Operations based on XPath selectors

  2. 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 Short overview

  3. 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.

  4. 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

  5. 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

  6. <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

  7. 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> parameters

  8. 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>

  9. <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>

  10. <remove> • whitespace text nodes somewhat problematic A.<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"/>

  11. <?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>

  12. 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 Impact on xcap-diff & pidf-diff etc.