State Machine Notation for Control

Abstraction (original) (raw)

2 Overview

[This section is informative.]

This document outlines State Chart XML (SCXML), which is a general-purpose event-based state machine language that combines concepts from CCXML and Harel State Tables. CCXML [CCXML 1.0] is an event-based state machine language designed to support call control features in Voice Applications (specifically including VoiceXML but not limited to it). The CCXML 1.0 specification defines both a state machine and event handing syntax and a standardized set of call control elements. Harel State Tables are a state machine notation that was developed by the mathematician David Harel [Harel and Politi] and is included in UML[UML 2.3]. They offer a clean and well-thought out semantics for sophisticated constructs such as parallel states. They have been defined as a graphical specification language, however, and hence do not have an XML representation. The goal of this document is to combine Harel semantics with an XML syntax that is a logical extension of CCXML's state and event notation.

3 Core Constructs presents the core state machine concepts, while 4 Executable Content contains an extensible set of actions that the state machine can take in response to events. 5 Data Model and Data Manipulationdefines constructs for storing and modifying data, while 6 External Communicationsprovides the capability of communicating with external entities.

3 Core Constructs

3.1 Introduction

[This section is informative.]

3.1.1 Basic State Machine Notation

The most basic state machine concepts are 3.3 , 3.5 and event (3.12 SCXML Events). Each state contains a set of transitions that define how it reacts to events. Events can be generated by the state machine itself or by external entities. In a traditional state machine, the machine is always in a single state. This state is called the active state. When an event occurs, the state machine checks the transitions that are defined in the active state. If it finds one that matches the event, it moves from the active state to the state specified by the transition (called the "target" of the transition.) Thus the target state becomes the new active state.

The Harel state notation defines several extensions to these basic notions. First of all, the state machine may take actions (as defined in 4 Executable Content) while taking transitions. Specifically, each state may contain 3.8 and 3.9 actions. Transitions may also contain actions. If a state machine takes transition T from state S1 to state S2, it first performs the onexit actions in S1, then the actions in T, then the onentry actions in S2. Secondly, in addition to the 'event' attribute that specifies the event(s) that can trigger it, transitions also have a 'cond' attribute. If a transition has both 'event' and 'cond' attributes, it will be selected only if an event is raised whose name matches the 'event' attribute (see 3.12.1 Event Descriptors for details) and the 'cond' condition evaluates to true. If the 'event' attribute is missing, the transition is taken whenever the 'cond' evaluates to true. If more than one transition matches, the first one in document order will be taken. Thus, in the following example, the system will transition to s1 when event e (or e.foo, etc.) occurs if x is equal to 1, but will transition to s2 if event e (or e.foo, etc.) occurs and x is not equal to 1, and will go to s3 if any other event occurs.

<state id=s">

3.1.2 Compound States

One of the most powerful concepts in Harel notation is the idea that states may have internal structure. In particular, a element may contain nested elements. Such a state is called a compound state and we speak of it as the parent state, while the nested elements are child states. The child states may themselves have nested children and the nesting may proceed to any depth. Ultimately we will reach a state that does not contain any child states. Such a state is called an atomic state. When a compound state is active, one and only one of its child states is active. Conversely, when an child state is active, its parent state must be active too. Thus at any point we have a set of active states, containing an atomic state and all of its ancestors. (We will see in the next section that multiple atomic states can be active at the same time.)

Compound states also affect how transitions are selected. When looking for transitions, the state machine first looks in the most deeply nested active state(s), i.e., in the atomic state(s) that have no substates. If no transitions match in the atomic state, the state machine will look in its parent state, then in the parent's parent, etc. Thus transitions in ancestor states serve as defaults that will be taken if no transition matches in a descendant state. If no transition matches in any state, the event is discarded.

3.1.3 Parallel States

The element represents a state whose children execute in parallel. Like , the element contains , , , and or children. However, the semantics of are different. When a is active, exactly one of its children is active. When a element is active, all of its children are active. Specifically, when the state machine enters the parent state, it also enters each child state. The child states execute in parallel in the sense that any event that is processed is processed in each child state independently, and each child state may take a different transition in response to the event. (Similarly, one child state may take a transition in response to an event, while another child ignores it.) When all of the children reach final states, the element itself is considered to be in a final state, and a completion event done.state.id is generated, where id is the id of the element.

Transitions within the individual child elements operate normally. However whenever a transition is taken with a target outside the element, the element and all of its child elements are exited and the corresponding handlers are executed. The handlers for the child elements execute first, in document order, followed by those of the parent element, followed by an action expression in the element, and then the handlers in the "target" state.

In the following example, parallel state 'p' has two children S1 and S2. Suppose a transition takes S1's child S12 as a target. (Note that this is permitted even though S12 is not the default initial state for S1 and that S11 is not, in fact, visited in the course of this example). Upon this transition, the state machine, in addition to entering S1 and S12, will also enter S1's parallel sibling S2 and its initial state S21. Once the transition has been taken, p, S1, S2, S12, and S21 will all be active. If event 'e1' occurs, it will cause S12 to transition to S1Final, and S21 to transition to S22. Entering S1Final will cause the event done.state.S1 to be generated. At this point, S1 is in a final state, but S2 is still active. Now suppose event 'e2' occurs. This will cause S22 to transition to S2Final, and the event done.state.S2 will be generated. Furthermore, since all of p's children are now in final states, the event 'done.state.p' will be generated, which will cause the transition contained in p to be triggered, exiting the entire region.

<transition event="done.state.p" target="someOtherState"/>

<state id="S1" initial="S11">
    <state id="S11">
        <transition event="e4" target="S12"/>
    </state>
    <state id="S12">
        <transition event="e1" target="S1Final"/>
    </state>
    <final id="S1Final"/>
</state> 

<state id="S2" initial="S21">
    <state id=S21">
        <transition event="e1" target="S22"/>
    </state>
    <state id="S22">
        <transition event="e2" target="S2Final/>
    </state>
    <final id="S2Final"/>
</state>

Note that the semantics of the element does not call for multiple threads or truly concurrent processing. The children of execute in parallel in the sense that they are all simultaneously active and each one independently selects transitions for any event that is received. However, the parallel children process the event in a defined, serial order, so no conflicts or race conditions can occur. See D Algorithm for SCXML Interpretation for a detailed description of the semantics of and the rest of SCXML.

3.1.4 Initial, Final, and History States

In the presence of compound states, transitions no longer simply move from the current active state to a new active state, but from one set of active states to another. (See 3.11 Legal State Configurations and Specifications for details.) If the target of a transition is an atomic state, the state machine will enter not only the atomic state, but also any of its ancestor states that are not already active. Conversely, a transition may take a compound state as its target. In this case, one of the compound state's children must also become active, but the transition does not specify which one. In this case we look at the target state's 3.6 child which specifies the state's default initial state, that is, the child state to enter if the transition does not specify one. (If the default initial state is itself compound, the state machine will also enter its default initial state, and so on recursively until it reaches an atomic state.) The presence of default initial states provides a form of encapsulation, since a transition may select a compound state as its target without understanding its internal substate structure.

The default initial state of a compound state may also be specified via the 'initial' attribute. The only difference between the element and the 'initial' attribute is that the element contains a element which may in turn contain executable content which will be executed before the default state is entered. If the 'initial' attribute is specified instead, the specified state will be entered, but no executable content will be executed. (If neither the child or the 'initial' element is specified, the default initial state is the first child state in document order.) As an example, suppose that parent state S contains child states S1 and S2 in that order. If S specifies S1 as its default initial state via the 'initial' attribute (or fails to specify any initial state), then any transition that specifies S as its target will result in the state machine entering S1 as well as S. In this case, the result is exactly the same as if the transition had taken S1 as its target. If, on the other hand, S specifies S1 as its default initial state via an element containing a with S1 as its target, the can contain executable content which will execute before the default entry into S1. In this case, there is a difference between a transition that takes S as its target and one that takes S1 as its target. In the former case, but not in the latter, the executable content inside the transition will be executed.

A compound state may also have final and history states as children. 3.7 is used to signify that the parent state is in some sense "done" with its processing. When a state machine enters a substate of a compound state, the parent state remains active, but the event "done.state.id" is generated, where id is the state id of the parent state. This event can trigger a transition in any ancestor state (including the parent). If the transition takes a target outside the parent state, the "done.state.id" event in effect serves as a signal that it is time to leave the parent state. 3.10 allows for pause and resume semantics in compound states. Before the state machine exits a compound state, it records the state's active descendants. If the 'type' attribute of the state is set to "deep", the state machine saves the state's full active descendant configuration, down to the atomic descendant(s). If 'type' is set to "shallow", the state machine remembers only which immediate child was active. After that, if a transition takes a child of the state as its target, the state machine re-enters not only the parent compound state but also the state(s) in the saved configuration. Thus a transition with a deep history state as its target returns to exactly where the state was when it was last exited, while a transition with a shallow history state as a target re-enters the previously active child state, but will enter the child's default initial state (if the child is itself compound.)

3.1.5 'Type' and Transitions

In the case of a transition located in a compound state, the 'type' attribute is significant. The behavior of a transition with 'type' of "external" (the default) is defined in terms of the transition's source state (which is the state that contains the transition), the transition's target state(or states), and the Least Common Compound Ancestor (LCCA) of the source and target states (which is the closest compound state that is an ancestor of all the source and target states). When a transition is taken, the state machine will exit all active states that are proper descendants of the LCCA, starting with the innermost one(s) and working up to the immediate descendant(s) of the LCCA. (A 'proper descendant' of a state is a child, or a child of a child, or a child of a child of a child, etc.) Then the state machine enters the target state(s), plus any states that are between it and the LCCA, starting with the outermost one (i.e., the immediate descendant of the LCCA) and working down to the target state(s). As states are exited, their handlers are executed. Then the executable content in the transition is executed, followed by the handlers of the states that are entered. If the target state(s) of the transition is not atomic, the state machine will enter their default initial states recursively until it reaches an atomic state(s).

In the example below, assume that state s11 is active when event 'e' occurs. The source of the transition is state s1, its target is state s21, and the LCCA is state S. When the transition is taken, first state S11 is exited, then state s1, then state s2 is entered, then state s21. Note that the LCCA S is neither entered nor exited. For more details see 3.13 Selecting and Executing Transitions and D Algorithm for SCXML Interpretation.

 <state id="s11">
    <onexit>
       <log expr="'leaving s11'"/>
    </onexit>
 </state>
 
 <transition event="e" target="s21">
    <log expr="'executing transition'"/>
 </transition>

==== log output will be ======>

leaving s11 leaving s1 executing transition entering s2 entering s21

The behavior of transitions with 'type' of "internal" is identical, except in the case of a transition whose source state is a compound state and whose target(s) is a descendant of the source. In such a case, an internal transition will not exit and re-enter its source state, while an external one will, as shown in the example below.

 <state id="s11">
   <onentry>
    <log expr="entering s11"/>
   </onentry>
    <onexit>
       <log expr="'leaving s11'"/>
    </onexit>
 </state>
 
 <transition event="e" target="s11" type="internal">
    <log expr="'executing transition'"/>
 </transition>

==== log output will be ======>

leaving s11 executing transition entering s11

=== if transition were external, log output would be ====>

leaving s11 leaving s1 executing transition entering s1 entering s11

If the 'target' on a is omitted, then the value of 'type' does not have any effect and taking the transition does not change the state configuration but does invoke the executable content that is included in the transition. Note that this is different from a whose 'target' is its source state. In the latter case, the state is exited and reentered, triggering execution of its and executable content.

3.3

[This section is normative.]

Holds the representation of a state.

3.3.2 Children

[Definition: An atomic state is a that has no , or children.]

[Definition: A compound state is a that has , , or children (or a combination of these).]

[Definition: The default initial state(s) of a compound state are those specified by the 'initial' attribute or element, if either is present. Otherwise it is the state's first child state in document order. ]

In a conformant SCXML document, a compound state MAY specify either an "initial" attribute or an element, but not both. See 3.6 for a discussion of the difference between the two notations.

3.7

[This section is normative.]

represents a final state of an or compound element.

3.7.2 Children

When the state machine enters the child of a element, the SCXML Processor MUST generate the event done.state.id after completion of the elements, where id is the id of the parent state. Immediately thereafter, if the parent is a child of a element, and all of the 's other children are also in final states, the Processor MUST generate the event done.state._id_where id is the id of the element.

When the state machine reaches the child of an element, it MUST terminate. See D Algorithm for SCXML Interpretation for details. If the SCXML session was triggered as the result by an element in another session, the SCXML processor MUST generate the event done.invoke.id after termination and return it to the other session, where id is the unique identifier generated when the element was executed. See 6.4 for details.

3.10

The pseudo-state allows a state machine to remember its state configuration. A taking the state as its target will return the state machine to this recorded configuration.

3.10.2 Children

If the 'type' of a element is "shallow", the SCXML processor MUST record the immediately active children of its parent before taking any transition that exits the parent. If the 'type' of a element is "deep", the SCXML processor MUST record the active atomic descendants of the parent before taking any transition that exits the parent. After the parent state has been visited for the first time, for each element, we define the set of states that the processor has recorded to be the 'stored state configuration' for that history state. We also define the states specified by the 'target' of the element's child to be the 'default stored state configuration' for that element. If a transition is executed that takes the state as its target, the behavior depends on whether the parent state has been visited before. If it has, the SCXML processor MUST behave as if the transition had taken the stored state configuration for that history state as its target. If it has not, the SCXML processor MUST behave as if the transition had taken the default stored state configuration for that history state as its target. The Process MUST execute any executable content in the transition after the parent state's onentry handlers, and, in the case where the history pseudo-state is the target of an transition, the executable content inside the transition. (Note that in a conformant SCXML document, a or element MAY have both "deep" and "shallow" children.)

[This section is normative.]

[Definition: A or element is active if it has been entered by a transition and has not subsequently been exited.]

[Definition: The state configuration of a state machine is the set of currently active states. ]

An SCXML document places the state machine in an initial state configuration at initialization time (via the 'initial' attribute of the element). Each transition that the state machine takes thereafter places the state machine in another state configuration (which need not be distinct from the former one.) A conformant SCXML document MUST place the state machine only in legal state configurations, where a legal state configuration is one that meets the following conditions:

It follows from this definition that if a state machine is in more than one atomic state, the atomic states can be traced back through a chain of or ancestors to a single ancestor.

The 'target' attribute of a (or the 'initial' attribute of a or element) do not in the general case specify a full legal state configuration since 1) they can contain or non-atomic elements 2) they do not contain the ancestors of the states in the list. We therefore define a legal state specification to be a set of states such that 1) no state is an ancestor of any other state on the list, and 2) a full legal state configuration results when all ancestors and default initial descendants have been added. (Note that the process of adding default initial descendants is recursive, since the 'initial' value may itself be non-atomic.) In a conformant SCXML document, the value of an 'initial' attribute or the 'target' of a MUST either be empty or contain a legal state specification.

In a conformant SCXML document, there is an additional requirement on the value of the 'initial' attribute of a and on the 'target' of a inside an or element: all the states MUST be descendants of the containing or element.

3.12 SCXML Events

[This section is normative.]

Events are one of the basic concepts in SCXML since they drive most transitions. The internal structure of events is platform-specific as long as the following external interface is observed:

For the most part, the set of events raised during the execution of an SCXML document is application-specific and generated under author control by use of the and elements. However, certain events are mandatory and generated automatically by the interpreter. These are described in 3.12.3 List of Errors and Events. Platforms MAY extend the names of these automatically generated events by adding a suffix. For example, a platform could extend done.state.id with a timestamp suffix and generate done.state.id.timestamp instead. Because any prefix of done.state.id is also a prefix of done.state.id.timestamp, any transition that matches the former event will also match the latter.

3.12.1 Event Descriptors

Like an event name, an event descriptor is a series of alphanumeric characters segmented into tokens by the "." character. The 'event' attribute of a transition consists of one or more such event descriptors separated by spaces.

[Definition: A transition_matches_ an event if at least one of its event descriptors matches the event's name. ]

[Definition: An event descriptor matches an event name if its string of tokens is an exact match or a prefix of the set of tokens in the event's name. In all cases, the token matching is case sensitive. ]

For example, a transition with an 'event' attribute of "error foo" will match event names "error", "error.send", "error.send.failed", etc. (or "foo", "foo.bar" etc.) but would not match events named "errors.my.custom", "errorhandler.mistake", "error.send" or "foobar".

For compatibility with CCXML, and to make the prefix matching possibly more clear to a reader of the SCXML document, an event descriptor MAY also end with the wildcard '.*', which matches zero or more tokens at the end of the processed event's name. Note that a transition with 'event' of "error", one with "error.", and one with "error.*" are functionally equivalent since they are token prefixes of exactly the same set of event names.

An event designator consisting solely of "*" can be used as a wildcard matching any sequence of tokens, and thus any event. Note that this is different from a transition lacking the 'event' attribute altogether. Such an eventless transition does not match any event, but will be taken whenever its 'cond' attribute evaluates to 'true'. As shown in D Algorithm for SCXML Interpretation, the SCXML interpreter will check for such eventless transitions when it first enters a state, before it looks for transitions driven by internal or external events.

3.12.3 List of Errors and Events

The following events are generated automatically by the SCXML implementation under conditions defined elsewhere in this document.

Name Description Defined in See also
done.state.id Indicates that the state machine has entered a final substate of state id.

3.7

3.1 Introduction

done.invoke.id

Indicates that the invoked process with invokeid _id_has completed processing.

6.4

3.7 , exitInterpreter procedure in D Algorithm for SCXML Interpretation

error.communication

Indicates that an error has occurred while trying to communicate with an external entity.

3.12.2 Errors

6.2 , C.1 SCXML Event I/O Processor, C.2 Basic HTTP Event I/O Processor

error.execution

Indicates that an error internal to the execution of the document has occurred, such as one arising from expression evaluation.

3.12.2 Errors

4.6 , 5.4 , 5.7 , 5.9.1 Conditional Expressions, 5.9.2 Location Expressions, 5.9.3 Legal Data Values and Value Expressions, 5.9.4 Errors in Expressions, 5.10 System Variables, 6.2 , B.2.4 Location Expressions, B.2.7

error.platform

Indicates that a platform- or application-specific error has occurred.

3.12.2 Errors

3.13 Selecting and Executing Transitions

[This section is normative.]

To simplify the following definitions, we introduce the event NULL. NULL has no name and is used only in these definitions. It never occurs in the event queues of an SCXML Processor. All other events have names and are distinct from NULL. (In effect, NULL is a pseudo-event that is used in these definitions as a trigger for eventless transitions.)

[Definition: A transition T is_enabled_ by named event E in atomic state S if a) T's source state is S or an ancestor of S,and b) T matches E's name (see 3.12.1 Event Descriptors) and c) T lacks a 'cond' attribute or its 'cond' attribute evaluates to "true". A transition is_enabled_ by NULL in atomic state S if a) T lacks an 'event' attribute, and b) T's source state is S or an ancestor of S and c) T lacks an 'cond' attribute or its 'cond' attribute evaluates to "true". (Note that such a transition can never be enabled by any named event.)]

[Definition: The source state of a transition is the or element that it occurs in. The effective target state(s) of the transition is the state or set of states specified by its 'target' attribute, with any history states being replaced by the corresponding stored state configuration or default stored state configuration. The_complete target set_ of a transition consists of all the states that will be active after the transition is taken. It contains the effective target states of the transition plus all their ancestors, expanded by the recursive application of the following two operations: 1) if any element is a member of the set, any of its children that are not members of the set must be added 2) if any compound is in the set and none of its children is in the set, its default initial state(s) are added to the set. Any state whose child(ren) are added to the complete target set by clause 2 is called a default entry state. ]

[Definition: The_exit set_ of a transition in configuration C is the set of states that are exited when the transition is taken when the state machine is in C. If the transition does not contain a 'target', its exit set is empty. Otherwise (i.e., if the transition contains a 'target'), if its 'type' is "external", its exit set consists of all active states in C that are proper descendants of the Least Common Compound Ancestor (LCCA) of the source and target states. Otherwise, if the transition has 'type' "internal", its source state is a compound state, and all its target states are proper descendants of its source state, the exit set consists of all active states in C that are proper descendants of its source state. (If a transition has 'type' of "internal", but its source state is not compound or its target states are not all proper descendants of its source state, its exit set is defined as if it had 'type' of "external". The exit set of a set of transitions is the union of the exit sets of the individual transitions. ]

[Definition: The_entry set_ of a transition in configuration C is the set of states that are entered when the transition is taken. If a transition does not contain a 'target', its entry set is empty. Otherwise, it consists of all members of the transition's complete target set that that are not currently active or are in the exit set. (Thus the entry set consists of all members of the transition's complete target set that will not be active once the states in the exit set have been exited.) The entry set of a set of transitions is the union of the entry sets of the individual transitions.]

[Definition: A transition T is_optimally enabled_ by event E in atomic state S if a) T is enabled by E in S and b) no transition that precedes T in document order in T's source state is enabled by E in S and c) no transition is enabled by E in S in any descendant of T's source state.]

[Definition: Two transitions T1 and T2 conflict in state configuration C if their exit sets in C have a non-null intersection.]

N.B. If two transitions conflict, then taking them both may lead to an illegal configuration. Hence, only one of the transitions may safely be taken. In order to resolve conflicts between transitions, we assign priorities to transitions as follows: let transitions T1 and T2 conflict, where T1 is optimally enabled in atomic state S1, and T2 is optimally enabled in atomic state S2, where S1 and S2 are both active. We say that T1 has a higher priority than T2 if a) T1's source state is a descendant of T2's source state, or b) S1 precedes S2 in document order.

[Definition: The optimal transition set enabled by event E in state configuration C is the largest set of transitions such that a) each transition in the set is optimally enabled by E in an atomic state in C b) no transition conflicts with another transition in the set c) there is no optimally enabled transition outside the set that has a higher priority than some member of the set. ]

[Definition: A_microstep_ consists of the execution of the transitions in an optimal enabled transition set.]

[Definition: A_macrostep_ is a series of one or more microsteps ending in a configuration where the internal event queue is empty and no transitions are enabled by NULL. ]

To execute a microstep, the SCXML Processor MUST execute the transitions in the corresponding optimal enabled transition set. To execute a set of transitions, the SCXML Processor MUST first exit all the states in the transitions' exit set in exit order. It MUST then execute the executable content contained in the transitions in document order. It MUST then enter the states in the transitions' entry set in entry order.

To exit a state, the SCXML Processor MUST execute the executable content in the state's handler. Then it _MUST_cancel any ongoing invocations that were triggered by that state. Finally, the Processor MUST remove the state from the active state's list.

To enter a state, the SCXML Processor MUST add the state to the active state's list. Then it MUST execute the executable content in the state's handler. If the state is a default entry state and has an child, the SCXML Processor MUST then execute the executable content in the child's .

At startup, the SCXML Processor MUST place the state machine in the configuration specified by the 'initial' attribute of the element.

After entering the initial configuration, and after executing each microstep, the SCXML Processor MUST check the state configuration for states that it has entered during the microstep. If it has entered a state that is a child of , it MUST halt processing. If it has entered a state that is a child of a compound state, it MUST generate the event done.state.id, where id is the id of the compound state. If the compound state is itself the child of a element, and all the element's other children are in final states, the Processor MUST generate the event done.state.id, where id is the id of the elements.

After checking the state configuration, the Processor MUST select the optimal transition set enabled by NULL in the current configuration. If the set is not empty, it MUST execute it as a microstep. If the set is empty, the Processor MUST remove events from the internal event queue until the queue is empty or it finds an event that enables a non-empty optimal transition set in the current configuration. If it finds such a set, the processor_MUST_ then execute it as a microstep. (Otherwise the internal event queue is empty and the Processor has completed a macrostep.)

After completing a macrostep, the SCXML Processor MUST execute in document order the handlers in all states that have been entered since the completion of the last macrostep. Then the Processor MUST remove events from the external event queue, waiting till events appear if necessary, until it finds one that enables a non-empty optimal transition set in the current configuration. The Processor MUST then execute that set as a microstep.

4 Executable Content

4.3

[This section is normative.]

is a container for conditionally executed elements.

4.3.2 Children

The behavior of is defined in terms of partitions of executable content. The first partition consists of the executable content between the and the first , or tag. Each tag defines a partition that extends from it to the next , or tag. The tag defines a partition that extends from it to the closing tag. In a conformant SCXML document, a partition MAY be empty. In a conformant SCXML document, MUST occur after all tags.

When the element is executed, the SCXML processor MUST execute the first partition in document order that is defined by a tag whose 'cond' attribute evaluates to true, if there is one. Otherwise, it MUST execute the partition defined by the tag, if there is one. Otherwise it _MUST NOT_execute any of the executable content.

Here is an example:

5 Data Model and Data Manipulation

5.1 Introduction

[This section is informative.]

The Data Model offers the capability of storing, reading, and modifying a set of data that is internal to the state machine. This specification does not mandate any specific data model, but instead defines a set of abstract capabilities that can be realized by various languages, such as ECMAScript or XML/XPath. Implementations may choose the set of data models that they support. In addition to the underlying data structure, the data model defines a set of expressions as described in 5.9 Expressions. These expressions are used to refer to specific locations in the data model, to compute values to assign to those locations, and to evaluate boolean conditions. Finally, the data model includes a set of system variables, as defined in 5.10 System Variables, which are automatically maintained by the SCXML processor.

The data model is defined via the 5.2 element, which contains zero or more 5.3 elements, each of which defines a single data element and assigns an initial value to it. These values may be specified in-line or loaded from an external source. They can then be updated via the 5.4 element. The 5.5 , 5.6 , and 5.7 elements can be used to incorporate data into communications with external entities. Finally, the 5.8

....

B Data Models

[This section is normative.]

The 'datamodel' attribute on defines the data model that the document uses. The data model includes the underlying data structure plus languages for boolean expressions, location expressions, value expressions, and scripting. A conformant SCXML document MAY specify the data model it uses. Conformant SCXML processors MUST support the null data model, and MAY support other data models, including the ECMAScript and XPath data models. The ECMAScript and XPath model definitions given here are normative in the sense that they define how implementations that support one of these languages MUST behave. The intent is to ensure interoperability among all processors that support ECMAScript, and all those that support XPath, without requiring all implementations to support either of those data model languages.

The definition of a data model MUST: