XPath Data Model for SCXML

The underlying structure of the XPath data model follows the document syntax closely. In particular, the SCXML Processor MUST maintain the XPath data model as an XML document with a root element called <datamodel>. For each <data> element in the document, the SCXML Processor MUST create a child of <datamodel> called <data> with an 'id' attribute whose value is the same as that of the 'id' attribute of the document <data> element. The Processor MUST insert the value of the document <data> element as the child(ren) of the datamodel <data> element. The Processor MUST also bind an XPath variable of the same name to that datamodel <data> element.

If either the 'src' attribute or in-line content is provided in the document <data> element, then if the content (whether fetched or provided in-line) is an XML document or node set, the SCXML Processor MUST insert the XML as the child of the datamodel <data> element. Otherwise the Processor MUST treat the content as a space-normalized string literal and insert it as the child of the datamodel <data> element. If no value is assigned, the SCXML Processor MUST leave the datamodel <data> element empty, as follows:

<data xmlns=""></data>

The SCXML Processor MUST accept any XPath expression as a location expression. The following example illustrates this usage:

The SCXML Processor MUST allow any XPath expression to be used as a value expression. If the result of the value expression is a node-set, the Processor MUST make a deep copy of the subtree rooted at each node. The Processor MAY convert the expression result to a string In contexts where a string is expected.

Implementations supporting the XPath data model MUST support the following additional attributes for the <assign> element.

The SCXML Processor MUST modify the data model as directed by the 'type' attribute as described below. If it is unable to do so, it MUST place the error error.execution on the internal event queue:

• replacechildren. Replace all the children at 'location' with the value specified by 'expr'.
• firstchild. Insert the value specified by 'expr' before all of the children at 'location'.
• lastchild. Insert the value specified by 'expr' after all of the children at 'location'.
• previoussibling. Insert the value specified by 'expr' before the node specified by 'location', keeping the same parent.
• nextsibling. Insert the value specified by 'expr' after the node specified by 'location', keeping the same parent.
• replace. Replace the node specified by 'location' by the value specified by 'expr'.
• delete. Delete the node specified by 'location'. ('expr' is ignored.)
• addattribute. Add an attribute with the name specified by 'attr' and value specified by 'expr' to the node specified by 'location'.

If the specified location contains a node set, the Processor MUST perform the assignment to each node in the set. It MAY do so in any order it chooses, and MUST evaluate 'expr' only once.

Note that in the case of an XML data model, it is not required to assign to the root of a tree (i.e., the "name" value in a <data> tag), since the path expression can reach down into the tree to assign a new value to an internal node. The following examples show various aspects of assignment in the XPath data model. Suppose we have a data model of the following form:

<data id="cart">
  <myCart xmlns="">
    <books>
      <book>
        <title>The Zen Mind</title>
      </book>
      <book>
        <title>Freakonomics</title>
      </book>
    </books>
    <cds>
      <cd name="Something"/>
    </cds>
  </myCart>
</data>

Here is an example of assignment of a string to an element node.

 
<assign location="$cart/myCart/books/book[1]/title"  expr="'My favorite book'"/>

results in

<data id="cart">
  <myCart xmlns="">
    <books>
      <book>
        <title>My favorite book</title>
      </book>
      <book>
        <title>Freakonomics</title>
      </book>
      ...
</data>

Now suppose we assign an XML structure to an element node. The following assignment statement would have the effect of replacing the children of the element "$cart/myCart/books/book[1]" by the XML tree rooted in <bookinfo>.

<assign location="$cart/myCart/books/book[1]">
  <bookinfo xmlns="">
    <isbn>12334455</isbn>
    <author>some author</author>
  </bookinfo>
</assign>

results in

<data id="cart">
  <myCart xmlns="">
    <books>
      <book>
        <bookinfo>
          <isbn>12334455</isbn>
          <author>some author</author>
        </bookinfo>
      </book>
      <book>
        <title>Freakonomics</title>
      </book>
      ...
</data>

Here are examples of legal and illegal assignment to an attribute:

<!-- Legal assignment: -->
<assign location="$cart/myCart/cds/cd/@name" expr"'Something Else'"/>

<!-- Illegal assignment: -->
<assign  location="$cart/myCart/cds/cd/@name" >
  <foo>
    <bar/>
  </foo>
</assign>

Now suppose we assign a string to a nodeset. The following assignment statement would have the effect of replacing the children of each node in the nodeset $cart/myCart/books/book with the string "The Zen Mind":

<assign location="$cart/myCart/books/book" expr="'The Zen Mind'"/>

results in

<data id="cart">
  <myCart xmlns="">
    <books>
      <book>The Zen Mind</book>
      <book>The Zen Mind</book>
    </books>
    ...
</data>

Finally suppose we assign a structure to a nodeset. The following statement would iterate over the elements in the nodeset of <book> elements and replace their children with the <price> structure:

<assign location="$cart/myCart/books/book">
  <price>20.0</price>
</assign>

results in

<data id="cart">
  <myCart xmlns="">
    <books>
      <book>
        <price>20.0</price>
      </book>
      <book>
        <price>20.0</price>
      </book>
    </books>
    ...
</data>

If the evaluation of any of the expressions in an <assign> element causes an error to be raised, evaluation of the element terminates immediately and the <assign> has no effect. For example, the following assignment statement would raise an error because the sample data model we are using does not have an <ISBN> node as a child of <book>:

 
<assign location="$cart/myCart/books/book[1]/ISBN"  expr="'....'"/>

Suppose as part of executing a state machine named "myName" with a platform-assigned sessionid "12345", we are processing an event with the name "foo.bar" and the following XML payload:

<payload xmlns="">
    <answer>42</answer>
</payload>

Then the underlying XML data model would have the following form (not all the fields of the event are shown):

As an example, here is a sample transition that accesses the $_sessionid variable in that data model.

<state id="checkSessionid">
  <transition cond="$_sessionid = '12345'" target="nextState"/>
  ...
</state>

In certain circumstances, e.g. when including data in events sent via the BasicHTTP Event I/O Processor, the SCXML Processor is required to serialize data from the XPath data model for transmission to a remote entity. In such cases, the Processor MUST serialize the data as a string.

There is no scripting language.

In the XPath data model, the legal iterable collections are Node-Sets. The legal values for the 'item' attribute are legal XPath variable names. The iteration order is the order of the underlying Node-set, and goes from an index of 1 by increments of one to an index of count(node-set).