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

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

• Jari Urpalainen
• IETF64

2
Why ?

• 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

3
General features/requirements

• 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 -gt reuse that logic as much as
  possible
• DELETE is similar, but PUT is separated into
  ltaddgt and ltreplacegt, 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.

4
General features continue

• 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

5
Framework properties

• It doesnt 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 -gt 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 ltaddgt, ltremovegt and ltreplacegt elements
  based on these schema types

6
Namespace challenges

• XPath location paths usually contain qualified
  elements
• The body contains also usually qualified
  elements
• -gt define namespace declarations within the
  framing patch document
• xmlns"urnfoo"
• ltadd sel"root"gtltbar xmlnspurnbar/gtlt/addgt
• The namespace URI of the ltbargt element is thus
  urnfoo (the default namespace declaration
  URI)
• Unlike XPath 1.0, the root selection above
  means thus in XPath 1.0 semantics
  local-name()rootnamespace-uri()urnfoo
  
• The urnbar declaration appears as is within
  the patched document after the patch has been
  applied.

7
Namespace challenges continue

• The receiver adds ltbar/gt as the last child
  node(element) of the ltrootgt element (default
  behavior)
• The target document context namespace is used for
  the ltbargt element, i.e. the in-scope namespace
  from the patched document which has the urnfoo
  namespace URI is selected for the ltbargt 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
• xmlnspre"urnfoo"
• ltadd sel"preroot"gtltprebar xmlnspurnbar/gtlt/
  addgt

8
Patching namespace declarations

• 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
• ltadd sel"" type"namespacef"gturnfoolt/addgt

9
Whitespace handling

• Not all whitespace is insignificant -gt 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 theres 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.

10
XML patch-ops examples

• ltadd sel""gtltfoo/gtlt/addgt
• ltadd sel"/foo" type"_at_a"gt1lt/addgt
• ltadd sel"" type"namespacef"gturnfoolt/addgt
• ltadd sel"/foo1" pos"before"gt
• ltfoo b'bar'gt
• lt!--comment node --gt
• ltbar xmlid"r123"/gt
• lt/foogt
• lt/addgt
• ltreplace sel"/foo"gtltbar/gtlt/replacegt
• ltreplace sel"/foo_at_a'1'/_at_a"gt2lt/replacegt
• ltreplace sel""gtltroot xmlns"urnns"/gtlt/replacegt
• ltreplace sel"/foo/text()"gtNew textlt/replacegt
• ltremove sel"/foo1"/gt
• ltremove sel"/foo_at_a'1'/_at_a"/gt
• ltremove sel'id("r123")' wsbefore/gt

11
ISSUES ?

• xmlid and xsid 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-xm
  l-patch-00.txt
• http//www.ietf.org/internet-drafts/draft-rosenber
  g-simple-xcap-change-log-00.txt
• Several other xml-patching models in IETF specs
  that arent based on XPath
• Running code
• On-line tool http//validate.openlaboratory.net/p
  atch/
• Open source (LGPL) C-implementation
  http//xmlpatch.sourceforge.net/