W3C

State Chart XML (SCXML): State Machine Notation for Control Abstraction

W3C Working Draft 7 29 May October 2009

This version:
http://www.w3.org/TR/2009/WD-scxml-20090507/ http://www.w3.org/TR/2009/WD-scxml-20091029/
Latest version:
http://www.w3.org/TR/scxml/
Previous version:
http://www.w3.org/TR/2008/WD-scxml-20080516/ http://www.w3.org/TR/2009/WD-scxml-20090507/
Editors:
Jim Barnett, Genesys (Editor-in-Chief)
Rahul Akolkar, IBM
RJ Auburn, Voxeo
Michael Bodell, Microsoft
Daniel C. Burnett, Voxeo
Jerry Carter, Nuance (until 2008, when at Nuance)
Scott McGlashan, HP
Torbjörn Lager, Invited Expert
Mark Helbing, (until 2006, when at Nuance)
Rafah Hosn, (until 2008, when at IBM)
T.V. Raman, (until 2005, when at IBM)
Klaus Reifenrath, (until 2006, when at Nuance)
No'am Rosenthal, Nokia

Abstract

This document describes SCXML, or the "State Chart extensible Markup Language". SCXML provides a generic state-machine based execution environment based on CCXML and Harel State Tables.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is the fifth sixth Public Working Draft of SCXML published on 7 May 29 October 2009 for review by W3C Members and other interested parties, and has been developed by the Voice Browser Working Group as part of the W3C Voice Browser Activity . The main differences difference from the previous draft are a revision of the <send> and <invoke> elements and is the introduction correction of Event I/O processors to support them. various inconsistencies. A diff-marked version of this document is also available for comparison purposes.

Comments for this specification are welcomed to www-voice@w3.org ( archives ).

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Table of Contents

1 Terminology
2 Overview
3 Core Module
    3.1 <scxml>
        3.1.1 Attribute Details
        3.1.2 Children
    3.2 <state>
        3.2.1 Attribute Details
        3.2.2 Children
    3.3 <transition>
        3.3.1 Attribute Details
        3.3.2 Children
        3.3.3 Selecting and Executing Transitions
    3.4 <parallel>
        3.4.1 Attribute Details
        3.4.2 Children
    3.5 <initial>
        3.5.1 Attribute Details
        3.5.2 Children
    3.6 <final>
        3.6.1 Attribute Details
        3.6.2 Children
    3.7 <donedata>
        3.7.1 Attribute Details
        3.7.2 Children
    3.8 <content>
        3.8.1 Attribute Details
        3.8.2 Children
    3.9 <onentry>
        3.9.1 Attribute Details
        3.9.2 Children
    3.10 <onexit>
        3.10.1 Attribute Details
        3.10.2 Children
    3.11 <history>
        3.11.1 Attribute Details
        3.11.2 Children
    3.12 Executable Content
        3.12.1 <raise>
            3.12.1.1 Attribute Details
            3.12.1.2 Children
        3.12.2 <if>
            3.12.2.1 Attribute Details
            3.12.2.2 Children
        3.12.3 <elseif>
            3.12.3.1 Overview
            3.12.3.2 Attribute Details
        3.12.4 <else>
            3.12.4.1 Overview
            3.12.4.2 Attribute Details
        3.12.5 <log>
            3.12.5.1 Overview
            3.12.5.2 Attribute Details
        3.12.6 Extensibility of Executable Content
    3.13 Referencing External Files
    3.14 SCXML Events
4 External Communications Module
    4.1 <send>
        4.1.1 Overview
        4.1.2 Attribute Details
        4.1.3 Children
        4.1.4 The Target of Send
        4.1.5 The Type of Send
        4.1.6 Message Content
        4.1.7 Send Errors
    4.2 <cancel>
        4.2.1 Attribute Details
        4.2.2 Children
    4.3 <invoke>
        4.3.1 Attribute Details
        4.3.2 Children
        4.3.3 Data Sharing
        4.3.4 Implementation
    4.4 <finalize>
        4.4.1 Attribute Details
        4.4.2 Children
5 Data Module
    5.1 <datamodel>
        5.1.1 Attribute Details
        5.1.2 Children
    5.2 <data>
        5.2.1 Attribute Details
        5.2.2 Children
    5.3 <assign>
        5.3.1 Attribute Details
        5.3.2 Children
    5.4 <validate>
        5.4.1 Attribute Details
        5.4.2 Children
    5.5 <param>
        5.5.1 Attribute Details
        5.5.2 Children
    5.6 System Variables
        5.6.1 The Internal Structure of Events
6 Script Module
    6.1 <script>
        6.1.1 Attribute Details
        6.1.2 Children
7 Anchor Module
    7.1 <anchor>
        7.1.1 Attribute Details
        7.1.2 Children
8 Expressions
    8.1 Conditional Expressions
    8.2 Location Expressions
    8.3 Legal Data Values and Value Expressions
    8.4 Errors in Expressions
9 IDs
10 Profiles
    9.1     10.1 The Minimal Profile
        9.1.1         10.1.1 Conformance
        9.1.2         10.1.2 Core Module Requirements
            9.1.2.1             10.1.2.1 Conditional Expressions
    9.2     10.2 The ECMAScript Profile
        9.2.1         10.2.1 Conformance
        9.2.2         10.2.2 Core Module Requirements
            9.2.2.1             10.2.2.1 Conditional Expressions
        9.2.3         10.2.3 Data Module Requirements
            9.2.3.1             10.2.3.1 Location Expressions
            9.2.3.2             10.2.3.2 Value Expressions
            9.2.3.3             10.2.3.3 System Variables
        9.2.4         10.2.4 Script Module Requirements
        9.2.5         10.2.5 Additional Requirements
            9.2.5.1             10.2.5.1 The In() predicate
        9.2.6         10.2.6 Examples
    9.3     10.3 The XPath Profile
        9.3.1         10.3.1 Conformance
        9.3.2         10.3.2 Core Module Requirements
            9.3.2.1             10.3.2.1 Conditional Expressions
        9.3.3         10.3.3 Data Module Requirements
            9.3.3.1             10.3.3.1 Location Expressions
            9.3.3.2             10.3.3.2 Value Expressions
            9.3.3.3             10.3.3.3 System Variables
        9.3.4         10.3.4 Additional Requirements
            9.3.4.1             10.3.4.1 The scxml:In() predicate
        9.3.5         10.3.5 Examples
10 11 Related Work

Appendices

A Open Issues
    A.1 Removing Restrictions on <invoke>
    A.2 Iterative Construct
    A.2     A.3 Alternative Notation
    A.3     A.4 parallel transition order
    A.4     A.5 error handling
    A.5 Initial transition leading to a history state     A.6 Simplification of <send> and <raise>
B Algorithm for SCXML Interpretation
    B.1 Semantics of <anchor>
C Probabilistic State Machines
D Schemas
    D.1 Utility Schemas
    D.2 Schema for Core Module
    D.3 Schema for External Module
    D.4 Schema for Data Module
    D.5 Schema for Script Module
    D.6 Anchor Module Schema
    D.7 Minimal Profile Schema
    D.8 ECMAScript Profile Schema
    D.9 XPath Profile Schema
    D.10 SCXML Message Schema
E Examples
    E.1 Language Overview
    E.2 Shale Microwave Example
    E.3 Microwave Example (Using parallel)
    E.4 Calculator Example
    E.5 Shale Example
    E.6 Examples of Invoke and finalize
    E.4     E.7 Custom Action Elements
F Conformance
G SCXML Event I/O Processor
    G.1 Examples
H Basic HTTP Event I/O Processor
    H.1 Access URI
    H.2 Receiving Events
    H.3 Sending Events
I References


1 Terminology

[ Definition : The key words must , must not , required , shall , shall not , should , should not , recommended , may , and optional in this specification are to be interpreted as described in [IETF RFC 2119] .]

The terms base URI and relative URI are used in this specification as they are defined in [IETF RFC 2396] .

2 Overview

This document outlines State Chart XML (SCXML), which is a general-purpose event-based state machine language that can be used in many ways, including:

SCXML combines concepts from CCXML and Harel State Tables. CCXML [W3C 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.0] . They offer a clean and well-thought out semantics for sophisticated constructs such as a 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.

SCXML is defined in terms of modules, which define logical units of functionality. Modules are customized and combined into profiles, each of which can be thought of as defining a variant of the language. This modularity allows implementations flexibility in selecting the features that they want to support. It is particularly intended to allow them the choice of which data manipulation language (e.g., ECMAScript, XPath) to embed. At this point, only support for the most limited profile (see 9.1 10.1 The Minimal Profile ) is mandatory. Support for all other profiles is optional, though this may change in future versions of the specification.

3 Core Module

The Core Module contains the elements that define the basic Harel state machine. The Core Module can be used by itself (see 9.1 10.1 The Minimal Profile ), but it will not be able to communicate with external entities or maintain an internal data model. The schema for the core module can be found at D.2 Schema for Core Module .

3.1 <scxml>

The top-level root state, wrapper element, which carries version information information. The actual state machine consists of its children. etc.

3.1.1 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description
initial false IDREFS none The IDs of one or more state or parallel elements contained in this state machine. If the IDs of multiple states or parallel elements are specified, they must all be children of a common <parallel> ancestor. The id of the initial state(s) for the document. This attribute is shorthand for an <initial> child with a transition containing an unconditional transition.
name false NMTOKEN none Any valid NMTOKEN The name of this state machine. It is for purely informational purposes.
xmlns false URI none If specified, the value must be "http://www.w3.org/2005/07/scxml".
version true decimal none The only legal value is "1.0"
profile false NMTOKEN none "minimal" "minimum", "minimal", "ecmascript", "xpath" or other platform-defined values. The SCXML profile that this document requires. "min" "minimal" denotes the Minimal Profile, "ecma" "ecmascript" the ECMAScript Profile, and "xpath" the XPath Profile, as defined in 9 10 Profiles .
exmode false NMTOKEN "lax" "lax" or "strict" The execution mode of the interpreter. This defines how the interpreter should behave if it encounters an element or attribute that it does not understand. If exmode is "lax", the interpreter will silently ignore element or attribute. If exmode is "strict", the interpreter still shall not process the element or attribute, but will also raise the error error.unsupportedelement.

3.1.2 Children

  • <initial> An optional child which identifies the initial state for the state machine. The state machine will take the transition contained in this element as the last step in document initialization. Occurs zero or one times. See 3.5 <initial>
  • <state> A compound or atomic state. Occurs zero or more times. See 3.2 <state> for details.
  • <parallel> A parallel state. Occurs zero or more times. See 3.4 <parallel> for details.
  • <final> A top-level final state in the state machine. Occurs zero or more times. When the state machine reaches a top-level final state (i.e., one that is an immediate child of <scxml>), it has finished processing and will terminate. See 3.6 <final> for details.

A state machine must An <scxml> document may specify either an "initial" attribute or an <initial> element, but not both. Either notation can be used to specify the state that the machine will transition to at the start of processing. The only difference between the two notations is that the <initial> element contains a <transition> element which may in turn contain executable content which will be executed before the initial state is entered. If neither the "initial" attribute nor an <initial> element is specified, the default initial state is the first child state in document order.

3.2 <state>

Holds the representation of a state.

3.2.1 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description
id true false ID none A valid id as defined in [XML Schema] The identifier for this state. It MUST be unique within the document. src false URI none Any URI URI of a file containing material to be inserted into this state. See 3.13 Referencing External Files 9 IDs for details.
initial false IDREFS none The IDs of one or more state or parallel elements contained in this state. If the IDs of multiple states or parallel elements are specified, they must all be children of a common <parallel> ancestor. The id of the default initial state (or states) for this state. This attribute is shorthand for an <initial> child containing an unconditional transition.

3.2.2 Children

  • <onentry> Optional element holding executable content to be run upon entering this <state>. Occurs 0 or 1 times. See 3.12 Executable Content
  • <onexit> Optional element holding executable content to be run when exiting this <state>. Occurs 0 or 1 times. See 3.12 Executable Content
  • <transition> Defines an outgoing transition from this state. Occurs 0 or more times. See 3.3 <transition>
  • <initial> In states that have substates, an optional child which identifies the default initial state. Any transition which takes the parent state as its target will result in the statemachine also taking the transition contained inside the <initial> element. See 3.5 <initial>
  • <state> Defines a sequential substate of the parent state. Occurs 0 or more times.
  • <parallel> Defines a parallel substate. Occurs 0 or more times. See 3.4 <parallel>
  • <final>. Defines a final substate. Occurs 0 or more times. When the state machine enters a final substate, an event done.state. parentid is generated, where parentid is the id of the final state's parent state. This event indicates that the parent state has reached completion. See 3.6 <final> .
  • <history> A child which represents the descendant state that the parent state was in the last time the system transitioned from the parent. A transition with this state as its target is in fact a transition to one of the other descendant states of the parent. May occur 0 or more times. See 3.11 <history> .

A complex state, namely one that has <state> or <parallel> children, must may specify either an "initial" attribute or am <initial> element, but not both. Either notation can be used to specify the state's default initial state. See 3.5 <initial> for a discussion of the difference between the two notations. If neither the "initial" attribute nor an <initial> element is specified, the default initial state is the first child state in document order.

3.3 <transition>

Transitions between states are triggered by events and conditionalized via guard-conditions. The optional attribute "target" specifies the destination of the transition, which may be a <state> or a <parallel> region.

3.3.1 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description
event false NMTOKEN none Any event name. The wildcard '*' is permitted. See 3.14 SCXML Events for details. The event trigger for this transition. The transition will be taken only when the event is generated. An event matches a trigger if the trigger is a perfect match or a prefix of the event's name (see 3.14 SCXML Events for details.) Also see B Algorithm for SCXML Interpretation for details on how transitions are selected.
cond false Boolean expression none Any boolean expression. Guard condition for this transition. If it is present, the transition is taken only if the guard condition evaluates to true . See 8.1 Conditional Expressions for details.
target false IDREFS none Whitespace separated list of state IDs in the current state machine. If multiple states are specified all must be descendants of the same <parallel> element. The identifier(s) of the state or parallel region to transition to. If it is omitted, the transition will not cause a change in the state configuration when it is executed. The executable content contained in the transition will still be executed, so the transition will function as a simple event handler. If the target is present and equal to the state containing the transition element, the transition will cause the state machine to leave and then re-enter this state.
anchor false NMTOKEN none Any anchor type The type of the anchor to transition to. See 7.1 <anchor> for details.

Only one of "target" and "anchor" may be specified.

3.3.2 Children

  • Immediate children of <transition> above are executable content that is run after the <onexit> handler for this state and before the <onentry> handler in the target state. See 3.12 Executable Content

3.3.3 Selecting and Executing Transitions

If a transition has both "event" and "cond" attributes, it will be taken only if an event is raised whose name matches the "event" attribute (see 3.14 SCXML Events for details) and the "cond" condition evaluates to true. If the "event" clause is missing, the transition is taken whenever the "cond" evaluates to true. If the "cond" clause is also empty, the transition is taken as soon as the state is entered.

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. If in any state 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 occurs if x is equal to 1, but will transition to s2 if event e occurs and x is not equal to 1, and will go to s3 if any event other than e occurs.

<state id=s">
   <transition event="e" cond="x==1" target="s1"/>
   <transition event="e" target="s2"/>
   <transition event="*" target="s3"/>
</state>

Note that the data model can be changed only by the execution of <invoke> or executable content. Therefore transitions with empty "event" conditions need be checked only 1) upon arrival into a state, after the completion of all <onentry> handlers and 2) after an event has been processed (since it may have triggered executable content which could have updated the data model). See B Algorithm for SCXML Interpretation for details.

The behavior of a transition is defined in terms of the set of active states, the transition's source state, which is the state that contains the transition, and the transition's target state(or states). (If the transition's target is inside a <parallel> region, it may have multiple target states, otherwise it will have a single one.) The least common ancestor (LCA) of a transition is defined to be the innermost <state>, <parallel> <state> or <scxml> <parallel> element that is a proper ancestor of the transition's source state and its target state(s). If there is no such element, the LCA is defined to be the wrapper <scxml> element. (This will be the case if one or more of the source and target states is a top-level state, i.e., one that is a direct descendent of <scxml>.) When a transition is taken, all active states that are proper descendants of the LCA are exited, starting with the innermost one(s) and working up to the immediate descendant(s) of the LCA. Then the state machine enters the target state(s), plus any states that are between it and the LCA, starting with the outermost one (i.e., the immediate descendant of the LCA) and working down to the target state(s). As states are exited, their <onexit> handlers are executed. Then the executable content in the transition is executed, followed by the <onentry> handlers of the states that are entered.

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 LCA is state S. When the transition is taken, first state S11 is exited, then state s1, then state s1 s2 is entered, then state s21. Note that the LCA S is neither entered nor exited. For more details see B Algorithm for SCXML Interpretation .

<state id="S" initial="s1">
   <state id="s1" initial="s11">
      <onexit>
         <log expr="'leaving s1'"/>
     </onexit>
     
     <state id="s11">
        <onexit>
           <log expr="'leaving s11'"/>
        </onexit>
     </state>
     
     <transition event="e" target="s21">
        <log expr="'executing transition'"/>
     </transition>
   </state>
  
   <state id="s2" initial="s21">
      <state id="s21">
         <onentry>
            <log expr="'entering s21'"/>
         </onentry>
      </state>
      <onentry>
         <log expr="'entering s2'"/>
      </onentry>
   </state>
   <onentry>
     <log expr="'entering S'"/>
   <onentry>   
   <onexit>
     <log expr="'leaving S'"/>
   <onexit>
</state>
==== log output will be ======>
leaving s11
leaving s1
executing transition
entering s2
entering s21

If the "target" on a <transition> is omitted, then taking the transition has the effect of leaving the machine in the same state after invoking any executable content that is included in the transition. Such a transition is equivalent to an 'event' handler in Harel State Table notation. Note that this is different from a <transition> whose "target" is its source state. In the latter case, the state is exited and reentered, triggering execution of its <onentry> and <onexit> executable content.

3.4 <parallel>

A state that encapsulates a set of parallel states . The <parallel> element has <onentry> and <onexit> and <transition> elements analogous to <state>. In addition, the <parallel> element holds a set of <state> elements that execute in parallel and join at the <onexit> handler of the <parallel> element. In particular, when all of the parallel substates reach final states, a completion event done.state. id is generated, where id is the id of the <parallel> element. Either the <parallel> element or one of its ancestors can trigger a transition off this event, at which time the <onexit> handler of the element will be executed.

When the state machine enters the parent <parallel> state, it simultaneously enters each child state. Transitions within the individual child elements operate normally. However any of the child elements may take a transition outside the <parallel> element. When this happens, the <parallel> element and all of its child elements are exited and the corresponding <onexit> handlers are executed. The handlers for the child elements execute first, in document order , followed by those of the parent <parallel> element, followed by an action expression in the <transition> element, and then the <onentry> handlers in the "target" state.

Note that the semantics of the <parallel> does not call for multiple threads or truly concurrent processing. The children of <parallel> execute in parallel in the sense that they are all simultaneously active and each one independently selects transitions for any event that is received. In particular, when an event is processed, it is possible that each of the parallel children takes a separate transition on it. However, the parallel children process the event in a defined, serial order, so no conflicts or race conditions can occur. See B Algorithm for SCXML Interpretation for a detailed description of the semantics <parallel> and the rest of SCXML.

3.4.1 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description
id true false ID none A valid id as defined in [XML Schema] The identifier for this state. It MUST be unique within the document. src false URI none Any URI URI of a file containing material to be inserted into this state. See 3.13 Referencing External Files 9 IDs for details.

3.4.2 Children

  • <onentry> Holds executable content to be run upon entering the <parallel> element. Occurs 0 or one times . See 3.12 Executable Content
  • <onexit> Holds executable content to be run when exiting this element. Occurs 0 or one times . See 3.12 Executable Content
  • <transition> Defines an outgoing transition from this state. Occurs 0 or more times. See 3.3 <transition>
  • <state> Defines a parallel substate region. Occurs 0 or more times.
  • <parallel> Defines a nested set of parallel regions. Occurs 0 or more times.
  • <history> A child which represents the state configuration that this state was in the last time the system transitioned from it. A transition with this history pseudo-state as its target is in fact a transition to the set of descendant states that were active the last time this state was exited. Occurs 0 or more times. See 3.11 <history> .

3.5 <initial>

This element represents the default initial state for a complex state with sequential substates. Suppose <state> S1 has child states S11, S12, and S13. If the system is in S1, it must also be in one (and only one) of S11, S12, or S13. A <transition> in a distinct <state> S2 may take S11, S12, or S13 as its "target", but it may also simply specify the parent S1. In that case, the <initial> child of S1 specifies which of S11, S12, or S13 the system should transition to.

The only difference between the <initial> element and the 'initial' attribute is that the <initial> element contains a <transition> 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. As an example, suppose that parent state S contains child states S1 and S2. If S specifies S1 as its default initial state via the "initial" attribute, then any transition that specifies S as its target will result in S 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 the <initial> tag containing a <transition> with S1 as its target, the <transition> 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 <initial> transition will be executed.

3.5.1 Attribute Details

None

3.5.2 Children

  • <transition> A conditionless transition (i.e., one without a "cond" or "event" attribute). Such a transition is always enabled and will be taken as soon as the state is entered. The "target" of the transition must be a descendant of the <initial> element's parent <state>.

3.6 <final>

<final> repesents a final state of a compound state. When the state machine reaches a <final> child of a compound state, it means that the compound state has completed its activity. Upon entry to the final state, after completion of the <onentry> elements, the event done.state. parentid is generated, where parentid is the id of the parent compound state. Note that even though the parent state has run to completion, more remote ancestors may still be active. When the state machine reaches a top-level final state (namely one that is a child of <scxml>), it has finished processing and will terminate. In this case, no event is generated unless the session was triggered as the result of an <invoke> element in another session. In this case, the event done.invoke.state. invokeid is generated and returned to the other session, where invokeid is the unique identifier generated when the <invoke> element was executed. See 4.3 <invoke> for details.

3.6.1 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description
id true false ID none A valid id as defined in [XML Schema] The identifier for this state. It MUST be unique within the document. See 9 IDs for details.

3.6.2 Children

  • <onentry> Optional element holding executable content to be run upon entering this state. Occurs 0 or 1 times. See 3.12 Executable Content
  • <onexit> Optional element holding executable content to be run when exiting this state. Occurs 0 or 1 times. See 3.12 Executable Content
  • <donedata> Optional element specifying data to be included in the done.state. parentid or done.invoke. invokeid event, if one is generated. In cases where neither of these events is generated, the data will be returned to the calling context in a platform-dependent manner.

3.7 <donedata>

A wrapper element holding data to be included in the 'done' event that is generated when a <final> state is entered. The data specified by this element will be placed in the _event.data field of the resulting event, but exact format of the that data will be determined by the profile (see 9 10 Profiles for details). <param> may not occur in documents whose profile does not contain the Data Module.

3.7.1 Attribute Details

None.

3.7.2 Children

  • <param> Extracts data from the data model to include in the event. See 5.5 <param> for details. May occur 0 or more times.
  • <content>. Specifies in-line data to include in the event. May occur 0 or 1 times.

<donedata> may have one or more <param> children or a single <content> child, but not both.

3.8 <content>

The <content> element provides a general way of specifying in-line data. It can be used to identify data to be included in an event or to be passed to an external service.

3.8.1 Attribute Details

None.

3.8.2 Children

The child elements of <content> consist of arbitrary markup which will be passed unmodified. The markup may consist of text, XML from any namespace, or a mixture of both.

Profiles that contain the Data Module may also use 5.5 <param> to compute such data dynamically.

3.9 <onentry>

3.9.1 Attribute Details

None.

3.9.2 Children

The children of the <onentry> handler consist of executable content as defined in 3.12 Executable Content

3.10 <onexit>

3.10.1 Attribute Details

None.

3.10.2 Children

The children of the <onexit> handler consist of executable content as defined in 3.12 Executable Content

3.11 <history>

The <history> pseudo-state allows for 'pause and resume' control flow. Whenever a complex <state> is exited, its <history> pseudo-state, if present, records the state configuration at exit. Later a <transition> taking the <history> state as its "target" allows the <state> to pick up where it left off. If the state containing the <history> state is a compound state, then the history value will be a single state. However, if the parent state is a <parallel> state, the history value will be a set of states, one for each parallel child region.

3.11.1 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description
id true false ID none A valid id as defined in [XML Schema] Identifier for this pseudo-state. It MUST be unique within the document. See 9 IDs for details.
type false NMTOKEN shallow "deep" or "shallow" If the value is 'shallow' then this state records only the immediate children of the parent <state>. In this case a <transition> with the history pseudo-state as its "target" will end up in the immediate child state that the parent was in the last time it was exited. On the other hand, if this attribute is set to 'deep', the history pseudo-state will remember nested states. In this case a <transition> with the history pseudo-state as its "target" will end up in the most deeply nested descendant <state> the parent was in the last time it was exited.

3.11.2 Children

  • <transition> A conditionless transition (i.e., one without a "cond" or "event"; attribute). Such a transition is always enabled and may be taken as soon as the state is entered. This <transition> represents the default history state and indicates the <state> to transition to if the parent <state> has never been entered before. if "type" is 'shallow', then the "target" of this <transition> must be an immediate child of the parent <state>. Otherwise it can be any descendant <state>. If the parent of the <history> state is a <parallel> state, then this transition may take multiple targets (each much be in a distinct parallel child state). Occurs once.

3.12 Executable Content

Executable content consists of actions that are performed as part of taking transitions and entering and leaving states (<onentry> and <onexit>, etc.) Executable content occurs in blocks, meaning that wherever executable content may occur, an arbitrary number of elements may occur. These elements in a block are processed in document order. If the processing of an element causes an error to be raised, the remaing elements of the block are not processed and the error event is placed on the internal event queue and processed like any other event (see B Algorithm for SCXML Interpretation ). In particular, the error event will not be removed from the queue and processed until all events preceeding it in the queue have been processed.

Note that 4 External Communications Module , 5 Data Module and 6 Script Module all define additional elements of executable content beyond those listed here. Thus the exact set of executable content available depends on the profile (see 9 10 Profiles for examples).

3.12.1 <raise>

The <raise> element may be used to raise an event in the current SCXML session. The event will be added to the session's internal event queue, but will not be processed until later, following the algorithm specified in B Algorithm for SCXML Interpretation . Note in particular that the event cannot be processed until all current executable content has been executed. For example, if the <raise> element occurs in the the <onentry> handlers of a state, at the very least the event will not be processed until all the executable content in the <onentry> handler has completed.

3.12.1.1 Attribute Details
Name Required Attribute Constraints Type Default Value Valid Values Description
event true NMTOKEN none Specifies the name of the event. This will be matched against the 'event' attribute of transitions.
3.12.1.2 Children
  • <param> Extracts data from the data model to include in the event. See 5.5 <param> for details. May occur 0 or more times.
  • <content>. Specifies in-line data to include in the event. May occur 0 or 1 times.

<raise> may have one or more <param> children or a single <content> child, but not both. The data specified by these elements will be placed in the _event.data field of the resulting event, but exact format of the that data included in the event will be determined by the profile (see 9 10 Profiles for details). <param> may not occur in documents whose profile does not contain the Data Module.

The 4.1 <send> element may also be used to raise internal events in an SCXML session. The <send> is a general-purpose message element, while <raise> has a simpler syntax. Furthermore, because the 'event' attribute of <raise> is of type NMTOKEN rather than a dynamically evaluated value expression, markup using <raise> may be analyzed statically.

3.12.2 <if>

<if> is a container for conditionally executed elements. <elseif> and <else> can optionally appear within an <if> as immediate children, and serve to partition the elements within the <if>. <else> and <elseif> have no content. <else/> is equivalent to an <elseif > element whose "cond" always evaluates to true.<else> must occur after all <elseif> tags.

Each partition within an <if> is preceded by an element having a "cond" attribute. The initial partition is preceded by the <if> and subsequent partitions by <elseif>s (or <else>). The first partition in document order with a "cond" that evaluates to true is selected. <else> always evaluates to true. A partition MAY be empty.

If an <if> has no immediate <elseif> or <else> children, the full contents of the <if> will be selected when the "cond" attribute evaluates to true.

<else> was chosen to match similar concepts in other languages, and supports examples such as

<if cond="cond1">
  <!-- selected when "cond1" is true -->
<elseif cond="cond2"/>
  <!-- selected when "cond1" is false and "cond2" is true -->
<elseif cond="cond3"/>
  <!-- selected when "cond1" and "cond2" are false and "cond3" is true -->
<else/>
  <!-- selected when "cond1", "cond2", and "cond3" are false -->
</if>
            
3.12.2.1 Attribute Details
Name Required Attribute Constraints Type Default Value Valid Values Description
cond true Conditional expression none A valid conditional expression A boolean expression. See 8.1 Conditional Expressions for details.
3.12.2.2 Children
  • <elseif> Occurs 0 or more times. See 3.12.3 <elseif>
  • <else> Occurs 0 or 1 times. See 3.12.4 <else>
  • The other children of <if> consist of executable content. The value of the conditions in the <if> and <elseif> determine which elements actually get executed.

3.12.3 <elseif>

3.12.3.1 Overview

An <elseif> partitions the content of an <if>, and provides a condition that determines the selection of the partition it begins. The executable content following the <elseif> will be executed if the <elseif>'s "cond" evaluates to true and all preceding "cond"s evaluate to false.

3.12.3.2 Attribute Details
Name Required Attribute Constraints Type Default Value Valid Values Description
cond true Conditional expression none A valid conditional expression An boolean expression. See 8.1 Conditional Expressions for details.

3.12.4 <else>

3.12.4.1 Overview

<else> is equivalent to an <elseif/> with a "cond" that always evaluates to true. Thus the executable content in an <else>'s partition will be executed if and only if all preceding "cond"s evaluate to false. <else> must occur after all <elseif> partitions.

3.12.4.2 Attribute Details

None. <else> is a synonym for <elseif cond="true">.

3.12.5 <log>

3.12.5.1 Overview

<log> allows an application to generate a logging or debug message which a developer can use to help in application development or post-execution analysis of application performance. The manner in which the message is displayed or logged is platform-dependent. The usage of label is platform-dependent. The use of <log> MUST have no other side-effects on interpretation. <log>is an empty element.

3.12.5.2 Attribute Details
Name Required Attribute Constraints Type Default Value Valid Values Description
label false string none A character string which may be used to indicate the purpose of the log.
expr true Value expression none An expression returning the value to be logged. See 8.3 Legal Data Values and Value Expressions for details. The nature of the logging mechanism is implementation-dependent, so the platform may convert this value to a convenient format before logging it.
level false positiveInteger 1 This information will be logged only if the system's log level is at this level or higher. The mechanism for specifying the log level and its legal values will be specified in a future version of this document.

3.12.6 Extensibility of Executable Content

The content presented in this specification represents a flexible, powerful, minimum set that all applications can rely on. Platforms are free to provide additional executable content corresponding to special features of their implementations. The functionality of such platform-specific content is not restricted, except that it may not cause transitions or any form of change of state, except indirectly, by raising events that are then caught by transitions. It is important to remember that SCXML treats executable content as a single blocking atomic operation and that no events are processed until all executable content has completed. For example, upon entering a state, the SCXML processor will not process any events or take any transitions until all <onentry> handlers have finished. Thus all executable content, including platform-specific extensions, SHOULD complete quickly under all circumstances. A general method for implementing extensions using the <send> element is presented in E.4 E.7 Custom Action Elements below.

Platform-specific extensions to executable content SHOULD be defined in a separate namespace, not in the 'scxml' namespace. Note that the schema D Schemas allows elements from arbitrary namespaces inside blocks of executable content. The following example shows the incorporation of CCXML functionality (see [W3C CCXML 1.0] ) into SCXML. In particular an <accept> element in the 'ccxml' namespace is invoked as executable content inside a transition.

<transition event="ccxml:connection.alerting">
  <ccxml:accept connectionid="eventdata.connectionid"/>

  <ccxml:accept connectionid="_event.data.connectionid"/>

</transition>

This markup is legal on any SCXML interpreter, but the interpretation of the <accept> element is platform-dependent. Platforms that do not support the element will either ignore it or signal an error, depending on the value of the 'exmode' attribute on the <scxml> element (see 3.1.1 Attribute Details ).

3.13 Referencing External Files

The "src" [Editor's Note: Earlier versions of this specification included a 'src' attribute on <state> and <parallel> contains a URL which is used to reference an external file containing all or part of the definition of the state. The file must contain a document that matches the SCXML schema but it need not match the extra-schematic constraints contained in this specification. (For example, the document may contain transitions that reference state ids that are not defined within it.) The exact treatment of the file depends on allowed the format body of the URL. If it ends with '#' followed by a string, the string is taken state to be the id of an element in the file and the children of that element are inserted into the state's definition before any other material contained copied in the <state>. Thus the state is incorporating the definition of a state defined within the from another file. If, on the other hand, the URL does not contain '#', the contents of the <scxml> element are inserted into the definition of the state before any other material in the state, along with an <initial> element whose <transition> takes as its target the value of the <scxml> element's 'initial' attribute. Thus in We have removed this case the contents of the entire state machine are inserted into the definiiton of the state. Suppose attribute because we believe that the file at "someURL" looks as follows: <scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0" initial="someState"> <state id="someState"> <transition event="foo" target="someOtherState"/> </state> <state id="someOtherState"> <transition event="bar" target="finalState"/> </state> </scxml> A 'src' expression referencing 'someOtherState' will result in 'someOtherState's contents being inserted into the state's definition, as shown below. The following markup: <state id="state1" src="someURL#someOtherState"> <transition event="state1.Done" target="yetAnotherState"/> <final id="finalState"/> </state> will expand to: <state id="state1"> <transition event="bar" target="finalState"/> <transition event="state1.Done" target="yetOtherState"/> <final id="finalState"/> </state> On the other hand, a 'src' expression referencing the whole file will result in both 'someState' and 'someOther' state being inserted into the state's definition, along with the appropriate <initial> element. Thus <state id="state1" src="someURL"> <transition event="state1.Done" target="yetOtherState"/> <final id="finalState"/> </state> becomes <state id="state1"> <initial> <transition target="someState"/> </initial> <state id="someState"> <transition event="foo" target="someOtherState"/> </state> <state id="someOtherState"> <transition event="bar" target="finalState"/> </state> <transition event="state1.Done" target="yetOtherState"/> <final id="finalState"/> </state> File inclusion takes place at load time. Implementations are free to perform document validation by any method they choose as long as the result is logically equivalent to xinclude specification [XInclude] provides a single pass superior, standards-based version of validation occurring after the material from the external file has been incorporated. (Note that implementations are not required to validate the external file. All that is required is that the document resulting from the incorporation be valid.) The same functionality. Since SCXML schema D.7 Minimal Profile Schema requires that the ids of <state>, <parallel>, and <final>, as well as <history>, be unique within the document. Therefore an included file MUST not contain ids which conflict with those in the including file or in another included file. If such a conflict occurs, the document will fail schema validation. It is the script author's responsiblity to avoid these problems. One obvious way to do this an XML-based language, xinclude functionality is to generate/rewrite the included file dynamically adding a prefix to each ID and IDRef in it. automatically available.

3.14 SCXML Events

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:

  • Events are immutable read-only data structures. Neither the browser's processing nor the user's markup may modify an event once it is placed in queue. Note that this implies that modifications to the event structure are not permitted.
  • In profiles which contain the Data module, events will contain data that can be accessed via the 'event' variable, as specified in 5.6 System Variables .
  • Events have names which are matched against the "event" attribute of transitions. These names are strings consisting of alphanumeric characters plus the character '.' which is used to segment names into tokens. A transition matches an event if the value of its "event" attribute is identical to the event's name or if it is a sequence of tokens that form a prefix of the event's name. Thus a transition with an "event" attribute of 'error' will match events name 'error', 'error.send', 'error.send.failed', etc. Furthermore, '*' can be used as but would not match events named ‘errors.my.custom’ or ‘errorhandler.mistake’. For compatibility with CCXML, and to make the prefix matching possibly more clear to a reader of the SCXML document, the "event" attribute of a transition may also end with the wildcard matching any string '.*', which matches zero or more tokens at the end of characters. Thus the processed event's name. Note that a transition with “event” of ‘error’ and one with ‘error.*’ are functionally equivalent since the transition selection algorithm always runs prefix matching on the “event” attribute. As further syntactic sugar, an "event" event attribute consisting solely of '*' can be used as a wildcard matching any sequence of tokens which thus will match 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 B 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.
  • In profiles which contain the Data module, events will contain data that can be accessed via the 'event' variable, as specified in 5.6 System Variables . Events are immutable read-only data structures. Neither the browser's processing nor the user's markup may modify an event once it is placed in queue. Note that this implies that modifications to the event structure are not permitted.

There is a class of error events whose names begin with 'error.'. They may be raised by the platform, as specified in this document, or under application control. They are placed in the internal event queue and processed like any other event. In particular, they are not processed immediately if there are other events in the queue and they are ignored if no transition is found that matches them. Note however that authors can arrange for otherwise unhandled errors to cause the interpreter to exit by creating a transition with "event" attribute of 'error' and a target of any top-level final state (i.e. one that is a child of <scxml>). If such a transition T is placed in a state S, it will cause the state machine to terminate on any error that is raised in S or one of its substates and is not handled by another transition that is placed in a substate of S or in S and preceding T in document order.

In many applications, it is important for SCXML to receive events from external entities (for example those which it contacted with <invoke> and <send>.) Such applications should use profiles that include 4 External Communications Module .

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 <raise> and <send> elements. However, certain events are mandatory and generated automatically by the interpreter. In this version of the specification, in addition to error events, there is only the done.state. stateid event and the done.invoke. stateid.platformid event. We may well change or expand this set of mandatory events in future drafts of this specification. Furthermore, it is likely that there will be distinct profiles of SCXML for specific applications, such as the Multi-modal Interaction Framework [W3C MMI] and VoiceXML 3.0. These profiles will define extensions to the core language and will likely extend the set of mandatory events with additional events appropriate to the specific application.

Platforms may extend the names of these automatically generated events if they desire. For example, a platform could extend done.state. stateid with a timestamp and generate done.state. stateid.timestamp instead. Because any prefix of done.state. stateid is also a prefix of done.state. stateid.timestamp , any transition that matches the former event will also match the latter.

4 External Communications Module

The External Communications Module adds the capability of sending and receiving events from external entities, as well as invoking external services. Its schema can be found at D.3 Schema for External Module .

Profiles that include the External Communications module MUST :

4.1 <send>

4.1.1 Overview

<send> is used to send events and data to external systems, including external SCXML Interpreters, or to raise events in the current SCXML session.

The target of <send> is specified using the "target" and "type" attributes. These attributes control how the platform should dispatch the event to its final destination. The "target" attribute specifies the unique identifier of the event target that the system should send the event to. This can be the identifier of another SCXML session. In other cases the value of this attribute will depend on the type of the target. (For example a SIP URL for SIP-INFO messages or a HTTP URL for Web Services). If the target is the special term '_internal', the event will be added to the internal event queue of the sending session. If no target attribute is specified, the event will be added to the external event queue of the sending session. If the value of the "target" attribute is not supported, invalid or unreachable by the platform, the system will raise an error.send.targetunavailable event. The "type" attribute describes the type of the event target and is used in conjunction with the "target" attribute to determine how to connect to the target. The default value of this attribute is 'scxml'. If the event "type" specified is not supported, the platform will raise the error event error.send.typeinvalid. A platform must support the following value for the "type" attribute: Value Details "scxml" Target is an SCXML session. The transport mechanism is platform-specific. The SCXML Event Processor is described in G SCXML Event I/O Processor . Support for HTTP POST is optional, however platforms that support it must use the following value for the "type" attribute: Value Details "basichttp" Target is a URL. Data is sent via HTTP POST The basic HTTP Event Processor is described in See H Basic HTTP Event I/O Processor . Platforms may support other types of Event I/O Processors, for example: Web-services, SIP or basic HTTP GET. However, platforms SHOULD name the type beginning with "x-" to signify that they are platform dependent. <send> also specifies the content of the message to be sent. <send> may specify message the message name via the optional "event" attribute. Additional content may be specified in one of the three following mutually exclusive ways: 4.1.4 The "namelist" attribute specifying a space separated list Target of data model locations to be included with the message. The "namelist" attribute is supported only in profiles that contain the Data Module. <datamodel> <data id="target" expr="'tel:+18005551212'"/> <data id="content" expr="'http://www.example.com/mycontent.txt'"/> </datamodel> ... <send target="target" type="'x-messaging'" event="'fax.SEND'" namelist="content"/> A single <content> child containing explicit inline XML content specifying the message body. See 3.8 <content> Send for details. <send target="'csta://csta-server.example.com/'" type="'x-csta'"> <content> <csta:MakeCall> <csta:callingDevice>22343</callingDevice> <csta:calledDirectoryNumber>18005551212</csta:calledDirectoryNumber> </csta:MakeCall> </content> </send> One or more <param> children, specifying content from the Data Model. See and 5.5 <param> 4.1.5 The Type of Send for details. Note that the <param> element is supported only in profiles that contain the Data Module. The sending SCXML Interpreter MUST not alter the content of the <send> and must send all the data contained within the message to the destination specified in the target attribute of <send>. If the "type" specified in the <send> is not supported, the platform will raise an error event send.failed.typenotsupported. stateid.sendid , where stateid is the id of the <state> containing the <send>, and sendid is the automatically generated id for this instance of <send>. If no send id is specified in the <send> element, this part of the event name will be omitted. If the "type" is valid, but the platform is still unable to send the message for other reasons, the platform will raise an error event send.failed.targetnotfound. stateid.sendid , where stateid and sendid have the same significance as in the typenotsupported event. In the case of <send> elements with a "delay" attribute, these errors will be raised when the delay interval has passed and the platform actually attempts to send the event. Note that the absence of any error events does not mean that the event was successfully delivered to its target, but only that the platform was able to dispatch the event.

4.1.2 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description
event false This attribute is mandatory if "type" May not occur with 'eventexpr'. If the type is 'scxml'. 'scxml', either this attribute or 'eventexpr' must be present. Value expression string none A value expression which returns a character string that indicates indicating the type of message being generated. See 8.3 Legal Data Values and Value Expressions for details. The message type string may include alphanumeric characters and the "." (dot) character. The first character may not be a dot or a digit. Message type names are case-insensitive. If neither the event attribute 'event', 'eventexpr' or in-line content is specified, an error.fetch event will be thrown. If used in conjunction with the inline content, an error.fetch will be thrown.
target eventexpr false May not occur with 'event'. If the type is 'scxml' either this attribute or 'event' must be present. Value expression none A dynamic alternative to 'event'. 'event' is a static string, while 'eventexpr' is evaluated at runtime and is treated as if it were the current session value of 'event'.
target false May not occur with 'targetexpr' URI none A valid target URL URI A value expression returning a The unique identifier of the message target that the platform should send the event to. See 8.3 Legal Data Values and Value Expressions 4.1.4 The Target of Send for details. If the special value '_internal' is specified, the event is added to the internal event queue of the current session. If no value is specified, the event is added to the external event queue of the current session.
type targetexpr false May not occur with 'target' Value expression 'scxml' none Any value An expression that evaluates evaluating to a string. valid target URI A value expression which returns dynamic alternative to 'target'. 'target' is a static string, while 'targetexpr' is evaluated at runtime and is treated as if it were the value of 'target'.
type false May not occur with 'typeexpr' string none A character string that specifies the type of the message target. See 8.3 Legal Data Values and Value Expressions for details. Values defined by the specification are: scxml. See G SCXML Event I/O Processor 4.1.5 The Type of Send for details. basichttp. See H Basic HTTP Event I/O Processor
typeexpr false May not occur with 'type' value expression none for details. A dynamic alternative to 'type'. 'type' is a static string, while 'typeexpr' is evaluated at runtime and is treated as if it were the value of 'type'.
id false This attribute may not occur with 'idlocation'. NMTOKEN ID none Any valid token A string literal to be used as the identifier for this instance of <send>. It is the author's responsibility to insure that it is unique. See 9 IDs for details.
idlocation false This attribute may not occur with 'id'. Location expression none Any valid location expression Any location expression evaluating to a data model location. See 8.2 Location Expressions for details. The location's value If the 'id' attribute is not specified, the platform will be set to an internally generated unique identifier of type NMTOKEN to be associated with store the message being sent. id that it generates automatically in this location. See 9 IDs for details.
delay false This attribute may May not be used occur with "target" '_internal'. 'delayexpr' or when the attribute 'target' has the value "_internal". Value expression string '0s' None A value expression which returns a time designation as defined in CSS2 [CSS2] format The character string returned is interpreted as a time interval. The send tag will return immediately, but the message is not dispatched until the delay interval elapses. In this case, all arguments to send are evaluated when the send element is first processed, and not when the message is actually dispatched. Timers are useful for a wide variety of programming tasks, and can be implemented using this attribute. Note: The queue for messages events is maintained locally. Any messages waiting to be sent will be purged when the session that issued this request terminates.
delayexpr false May not occur with 'delay' or when the attribute 'target' has the value "_internal". Value expression None A value expression which returns a time designation as defined in CSS2 [CSS2] format A dynamic alternative to 'delay'. 'delay' is a static string, while 'delayexpr' is evaluated at runtime and is treated as if it were the value of 'delay'.
namelist false This attribute may not be specified in conjunction with the <content> or <param> elements. This attribute is supported only in profiles that contain the Data Module or the Script Module. List of location expressions none List of data model locations A space-separated list of zero or more data model locations to be included with the message. See 8.2 Location Expressions for details.
hints false May not occur with 'hintsexpr'. Value expression string none A value expression. The data returned string contains information which may be used by the implementing platform to optimize message transmission. The meaning of these hints is platform-specific.
hintsexpr false May not occur with 'hints' Value expression none A value expression. A dynamic alternative to 'hints'. 'hints' is a static string, while 'hintsexpr' is evaluated at runtime and is treated as if it were the value of 'hints'.

4.1.3 Children

  • <param>. Element containing data to be passed to the external service. Occurs 0 or more times. See 5.5 <param> for details. If <param> and 'namelist' both occur, the values generated by <param> go after those in the 'namelist'. If any <param> item has the same name as a 'namelist' item, both are included.
  • <content>. Element containing arbitrary material to be passed to the invoked component. The material may consist of non-XML markup or XML markup in any namespace. Occurs 0 or 1 times. See 3.8 <content> for details.

"namelist" and <content> may not co-occur. That is, the developer may specify the content of the event either with the "namelist" element and/or 1 or more occurrences of the <param> element, or with a single occurrence of the <content> element, but not both.

4.1.4 The Target of Send

The target of the <send> operation is the destination to which the event should be sent. It may be defined by either the 'target' or the 'targetexpr' attribute. Either one can be used to specify the unique identifier of the target. This may be the identifier of another SCXML session. In other cases the value of this attribute will depend on the type of the target. (For example a SIP URL for SIP-INFO messages or a HTTP URL for Web Services). The following special values are defined:

  • #_internal. If the target is the special term '#_internal', the event will be added to the internal event queue of the sending session.
  • #_scxml_ sessionid .If the target is the special term '#_scxml_ sessionid ', where sessionid is the id of an SCXML session, the event will be sent to the external queue of that session.
  • #_parent. If the target is the special term '#_parent', the event will be sent to the SCXML session that invoked the sending session, if there is one. See 4.3 <invoke> for details.
  • #_invoke_ invokeid .If the target is the special term '#_invoke_ invokeid ', where invokeid is the invokeid of an SCXML session that the sending session has created by <invoke>, the event will be sent to the external queue of that session. See 4.3 <invoke> for details.

If neither the 'target' nor the 'targetexpr' attribute is specified, the event will be added to the external event queue of the sending session. If the value of the 'target' or 'targetexpr' attribute is not supported, invalid or unreachable by the platform, the system will raise an error.send.targetunavailable event.

4.1.5 The Type of Send

The type of the <send> operation specifies the method that should be used to deliver the message to its target. The type may be defined by either the 'type' or the 'typeexpr' attribute. The type is used in conjunction with the target to determine how to connect to the destination. The neither the 'type' nor the 'typeexpr' is defined, a default value of 'scxml' is assumed. If the type specified is not supported, the platform will raise the error event error.send.typeinvalid.

A platform must support the following type:

Value Details
"scxml" Target is an SCXML session. The transport mechanism is platform-specific.

For details on the 'scxml' type, see G SCXML Event I/O Processor .

Support for HTTP POST is optional, however platforms that support it must use the following value for the "type" attribute:

Value Details
"basichttp" Target is a URL. Data is sent via HTTP POST

For details on the 'basichttp' type, see H Basic HTTP Event I/O Processor .Platforms may support other types such as web-services, SIP or basic HTTP GET. However, platforms SHOULD assign such types names beginning with "x-" to signify that they are platform dependent.

4.1.6 Message Content

<send> may specify the message name via the optional 'event' attribute. Additional content may be specified in one of the three following mutually exclusive ways:

  • The 'namelist' attribute specifying a space separated list of data model locations to be included with the message. The 'namelist' attribute is supported only in profiles that contain the Data Module.
    
    <datamodel>
    <data id="target" expr="'tel:+18005551212'"/>
    <data id="content" expr="'http://www.example.com/mycontent.txt'"/>
    </datamodel>
       ...
    <send target="target" type="'x-messaging'" event="'fax.SEND'" namelist="content"/>
    
    
  • A single <content> child containing explicit inline XML content specifying the message body. See 3.8 <content> for details.
    
    <send target="'csta://csta-server.example.com/'" type="'x-csta'">
          <content>
          <csta:MakeCall>
            <csta:callingDevice>22343</callingDevice>
            <csta:calledDirectoryNumber>18005551212</csta:calledDirectoryNumber>
          </csta:MakeCall>
          </content>
    </send>
    
    
  • One or more <param> children, specifying content from the Data Model. See 5.5 <param> for details. Note that the <param> element is supported only in profiles that contain the Data Module.

The sending SCXML Interpreter MUST not alter the content of the <send> and must send all the data contained within the message to the destination specified in the target attribute of <send>.

4.1.7 Send Errors

If the type specified for the <send> is not supported, the platform will raise an error event send.failed.typenotsupported. stateid.sendid ,where stateid is the id of the <state> containing the <send>, and sendid is the automatically generated id for this instance of <send>. If no send id is specified in the <send> element, this part of the event name will be omitted. If the type is valid, but the platform is still unable to send the message for other reasons, the platform will raise an error event send.failed.targetnotfound. stateid.sendid ,where stateid and sendid have the same significance as in the typenotsupported event. In the case of <send> elements with a 'delay' attribute, these errors will be raised when the delay interval has passed and the platform actually attempts to send the event. Note that the absence of any error events does not mean that the event was successfully delivered to its target, but only that the platform was able to dispatch the event.

4.2 <cancel>

The <cancel> element may be used to cancel a delayed <send> event. The system will attempt to cancel the pending event and will raise an internal event cancel.successful if it succeeds. Otherwise it will raise an error.notallowed event. <cancel> may be used to cancel only events that were raised by a <send> occurring in the same document.

4.2.1 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description
id sendid true false Cannot occur with sendidexpr, but one or the other of them must be specified Expression IDREF none A valid The ID of a delayed event identifier An expression The ID of the event which returns is to be canceled.
sendidexpr false Cannot occur with sendid, but one or the value other of them must be specified Value Expression none Any expression that evaluates to the ID of a delayed event identifier that was specified or generated when A dynamic alternative to 'sendid'. 'sendid' is a static string, while 'sendidexpr' is evaluated at runtime and is treated as if it were the send command was issued. value of 'sendid'.

4.2.2 Children

None

4.3 <invoke>

<invoke> and its child <finalize> are useful in states that model the behavior of an external service. The <invoke> element is executed after the state's <onentry> element and causes an instance of the external service to be created. The <param> element may be used to pass data to the service. Any events that are received by the state machine from the invoked component during the invocation are preprocessed by the <finalize> handler before transitions are selected. The <finalize> code is used to normalize the form of the returned data and to update the data model before the transitions' "event" and "cond" clauses are evaluated.

When the <invoke> element is executed, the platform MUST start a new logical instance of the external service specified in "type" and pass it the data specified by "src", <content>, or <param>. The service instance MAY be local or remote. In addition to the explicit arguments, the platform MUST keep track of the unique invoke id and insure that it is included in all events that the invoked service returns to the invoking machine.

The external service MAY generate multiple events while it is processing, but it MUST generate a special event 'done.invoke. invokeid ' once it has finished processing, where invokeid is the identifier for the corresponding <invoke> element. The external service MUST not generate any other events after this done event. If the invoking state machine takes a transition out of the state containing the <invoke> before it receives the 'done.invoke. stateid.platformid ' event, it MUST automatically cancel the invoked component and stop its processing. The cancel operation MUST act as if it were the final <onexit> handler in the invoking state.

When parallel states invoke the same external service concurrently, separate instances of the external service will be started. They can be distinguished by their invokeids which are generated as part of the invocation. Similarly, the invoke id contained in the events returned from the external services can be used to determine which events are responses to which invocation. Each event that is returned will be processed only by the <finalize> in the state that invoked it, but that event is then processed like any other event that the state machine receives. The finalize code can thus be thought of as a preprocessing stage that applies before the event is added to the event queue. Note that the event will be passed to all parallel states to check for transitions.

<invoke> occurs only in atomic states, namely those that do not have <state> or <parallel> children. Thus, a state may have either <state> and <parallel> children or an <invoke> child,but not both. (See A.1 Removing Restrictions on <invoke> )

Since an invocation will be canceled when the state machine leaves the invoking state, it does not make sense to start an invocation in a state that will be exited immediately. Therefore the <invoke> element is executed upon entry into the state, but only after checking for eventless transitions and transitions driven by pending internal events. If any such enabled transition is found , it is taken and the state is exited immediately, without triggering the invocation. Thus invocations are triggered only when the state machine has reached a stable configuration, i.e., one that it will be staying in while it waits for internal or external events. (See B Algorithm for SCXML Interpretation for details.)

4.3.1 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description
type false May not occur with 'typeexpr'. NMTOKEN 'scxml' none 'scxml', 'vxml2', 'vxml3', 'ccxml', plus other platform-specific values. A string specifying the type of the external service. Platforms MUST support 'scxml' as a value. Platforms MAY support 'vxml2', which indicates a VoiceXML 2.x interpreter, 'vxml3' which indicates a VoiceXML 3.x interpreter, and 'ccxml', which indicates a CCXML 1.0 interpreter. Platforms MAY support additional values, but they SHOULD name the values beginning with "x-" to signify that they are platform dependent.
src typeexpr false May not occur with 'type'. Value value expression None none Any value expression evaluating that evaluates to a character string that would be a valid URI. value for 'type'. A value expression that will be dynamic alternative to 'type'. 'type' is a static string, while 'typeexpr' is evaluated at the time that invoke runtime and is executed to produce treated as if it were the value of 'type'.
src false May not occur with the 'srcexpr' attribute or the <content> element. URI to pass None Any URI. A URI that will be passed to the external service. See 8.3 Legal 4.3.3 Data Values and Value Expressions Sharing for details. If "type" is one of the predefined types, the document at the URI will contain
srcexpr false May not occur with the corresponding markup to execute (i.e., an SCXML, VoiceXML, 'src' attribute or CCXML document). In other cases, the external service will decide how <content> element. Value expression None Any expression evaluating to handle a valid URI. A dynamic alternative to 'src'. 'src' is a static string, while 'srcexpr' is evaluated at runtime and is treated as if it were the contents value of the document. 'src'.
id false This attribute may May not occur with the 'idlocation' attribute. NMTOKEN ID none Any valid token A string literal to be used as the identifier for this instance of <invoke>. It is the author's responsibility to insure that it is unique. See 9 IDs for details.
idlocation false This attribute may May not occur with the 'id' attribute. Location expression none Any valid location expression Any data model expression evaluating to a data model location. See 8.2 Location Expressions for details. The location's value will be set to an internally generated unique identifier of type NMTOKEN which If the 'id' attribute is associated with not specified, the platform will store the id that it generates automatically in this invocation. This location. See 9 IDs for details. The automatically generated identifier will have the form stateid.platformid , where stateid is the id of the state containing this element and platformid is an identifier generated by the platform which MUST be unique within the current session.
namelist false This attribute is supported only in profiles that contain the Data Module or the Script Module. May not occur with the <param> element. List of location expressions none List of data model locations A space-separated list of zero or more data model locations to be passed to the invoked service. See See 4.3.3 Data Sharing and 8.2 Location Expressions for details.
autoforward false boolean false true or false If 'true', any external events received by the state machine will be forwarded automatically to the invoked external service.

Note that either the "id" or "idlocation" attribute may be specified, but not both. If the author does not provide an explicit identifier via the "id" attribute, the system will generate one automatically. It will store this identifier in the location specified by "idlocation" if that attribute is present. In the rest of this document, we will refer to this identifier as the "invokeid", regardless of whether it is specified by the author or generated by the platform.

4.3.2 Children

  • <param>. Element containing data to be passed to the external service. Occurs 0 or more times. See 5.5 <param> .
  • <finalize>. Element containing executable content to massage the data returned from the invoked component. Occurs 0 or 1 times. See 4.4 <finalize> for details.
  • <content>. Element containing arbitrary material to be passed to the invoked component. The material may consist of non-XML markup or XML markup in any namespace. Occurs 0 or 1 times. See 3.8 <content> for details.

At most one of "src", <param>, and <content>may be specified. However <param> may occur multiple times if it occurs.

<invoke> MUST not be a sibling of the <state> or <parallel> elements. It thus occurs only in atomic states, namely those which do not have substates.

4.3.3 Data Sharing

The invoked external resource is logically separate from the state machine that invokes it and does not share data with it unless the author explicitly requests this with the <param> tag, the or <content> tag, elements and/or the <send> tag 'src' and 'namelist' attributes.

  • For targets of type 'scxml', 'ccxml', 'vxml2' or 'vxml3', the 'autoforward' attribute. The <param> tag 5.5 <param> can be <content> element or 'src' attribute is used to pass provide markup that the invoked resource should execute. (The <content> element provides this markup in-line, while the 'src' attribute specifies it via a copy of all or part of uri.) Similarly, the <param> element and namelist attribute are used to specify values that are to be injected into the state machine's data model to of the invoked service. resource.
  • For targets of other types, the interpretation of <param> and <content> elements and the 'src' and 'namelist' attributes is platform-specific. However, values specified by <param> and namelist MUST be treated identically, as must those provided via 'src' and <content>

The invoked and invoking process may also communicate via events. If the 'autoforward' attribute is set to 'true', the invoking state machine will automatically forward a copy of all external events it receives to the external service. The invoking machine will send such events at the same time as it pulls them off the external event queue to process them. Once it has forwarded the copy, the invoking state machine will process the event normally, regardless of how it is handled in the external service.

SCXML scripts can also use the <send> tag To send messages to the child process on an ad-hoc basis, SCXML scripts can use the <send> tag. basis. The type should be set to the same value as was used in the original <invoke>, while the target should have the special form #_ invokeid , where invokeid is the identifier corresponding to the original <invoke> tag. For example, in a profile using ECMAScript as the data model, the following code would invoke a VXML session:

  <invoke type="vxml" idlocation="_data.myInvoke"/>
       

In this case, the unique invoke identifier has been stored in the data model location _data.MyInvoke. Since the target attribute is an expression which is evaluated, the following code will extract that identifier and send a message to the invoked VXML session:

             
  <send type="vxml" target="'#' + _data.myInvoke"/>
                

Finally, in the case where the invoked external service is an SCXML session, it may use <send> with the special target '_parent' and type 'scxml' to send events, possibly containing data, to the invoking state machine.

4.3.4 Implementation

The implementation of <invoke>, including communication between parent and child processes, is platform-specific, but the following requirements hold in the case where the invoked process is itself an SCXML session:

  • If the 'name' of a <param> element in the invoking machine matches the 'id' of a <data> element in the top-level data model of the invoked machine, then the value of the <param> element will replace the value of the corresponding <data> element. The behavior of 'namelist' is similar. If the value of a key in the namelist matches the 'id' of a <data> element in the top-level data model of the invoked machine, then the value of the key will replace the value of the corresponding <data> element. If the names do not match, the value of the <param> element or namelist key/value pair will not be added to the invoked machine's data model, though it may be made available by some other platform-specific means.
  • If the invoked state machine reaches a top-level final state, it must place an event done.invoke. id on the external event queue of the invoking machine, where id is the id generated at the start of the invocation. Note that reaching a top level final state corresponds to normal termination of the machine and that it cannot generate or process any further events once it is in this state.
  • If the invoking state machine exits the state containing the invocation before it receives the done.invoke. id event, it must cancel the invoked session. To do this, it MUST send the event cancel.invoke. invokeid to the invoked session, where invokeid is the identifier corresponding to the <invoke> element. When the invoked session receives this event, it MUST act as if the 'continue' variable specified in B Algorithm for SCXML Interpretation has been to 'false'. This will cause the invoked session to exit at the end of the next microstep. When the invoked session exits, it will execute the <onexit> handlers for all active states, but will not generate the done.invoke. id event. Once it cancels the invoked session, the invoking session MUST ignore any events it receives from that session. In particular it MUST not insert them into its external event queue.
  • Implementations MUST use the SCXML Event/IO processor ( G SCXML Event I/O Processor ) to communicate between the child and parent processes.

4.4 <finalize>

4.4.1 Attribute Details

None.

4.4.2 Children

<finalize>'s children consist of executable content. The content will be invoked on any event that the external service returns after <invoke> has been executed. This executable content will be applied before the system looks for transitions that match the event. In the case of parallel states, only the finalize code in the original invoking state will be executed. Within the executable content, the special variable '_event' may be used to refer to the data contained in the event which is being finalized.

If no executable content is specified, a default canonicalization handler will be invoked which will update the data model with any return values corresponding to <param> elements with missing "expr" attributes. Thus the effect of a <param> element with an empty "expr" attribute coupled with an empty <finalize> element is first to send all or part of the data model to the invoked component and then to update that part of the state machine's data model with the returned values. Note that the automatic update does not take place if the <finalize> element is absent as opposed to empty.

The purpose of the executable content <finalize> code is to normalize enable transformations between the format of data contained in events returned by the external service and update the state machine's data model before transitions are selected. <finalize> code where the event data may only massage data. be then stored. It MUST not raise events or invoke external actions. In particular, the <send> and <raise> elements may not occur.

In the example below, a state machine using an ECMAScript data model invokes a clock object that returns the current time in a ping event with an XML payload that includes the currentSecond, currentMinute, currentHour (1-12), and an isAm flag. <finalize> maps this data into an ECMAScript date object that is used in the condition of a transition. Thus <finalize> normalizes the data before the conditions on transitions are evaluated.


<scxml version="1.0" profile="ecmascript">
....
 <state id=”getTime”>
   <transition event=”ping” cond=”time.getHours() > 17 ||  time.getHours() < 9” target=”storeClosed”/>
   <transition event=”ping” target=”takeOrder”/>
   <datamodel>
     <data id=”time” expr=”new Date()”/>
   </datamodel>
   <invoke id=”timer” type=”x-clock” src=”clock.pl”>
     <finalize>
       <script>
         time.setSeconds(_event.data.currentSecond);
         time.setMinutes(_event.data.currentMinute);
         time.setHours(_event.data.currentHour + (_event.isAm ? 0 : 12) - 1);
       </script>
     </finalize>
   </invoke>
 </state>
....

5 Data Module

The Data Module offers the capability of storing, reading, and modifying a set of data that is internal to the state machine. Its schema may be found at D.4 Schema for Data Module . As an authoring convenience, the Data Module can read in data from an external source at load time, but at run time it is restricted to operating on its internal model. Note, however, that 4 External Communications Module allows SCXML to interact with external entities at run time, to exchange data as part of the interaction.

Profiles that include the Data Module MUST :

For examples of how to do this, see 9.2 10.2 The ECMAScript Profile and 9.3 10.3 The XPath Profile .

5.1 <datamodel>

To provide a uniform method of access to both local and remote data, we introduce a <datamodel> element which encapsulates any number of <data> elements. Each such element defines a single data object. The exact nature of the data object depends on the data model language used. The data object may be fetched from an external source or specified in-line. In cases where the data object specified is not a legal instance of the data model language, implementations MAY translate it into a legal expression, and MUST signal an error if the cannot do so.

Data created via the <data> element is local to the SCXML interpreter and not shared with any external resource. However, the local data model, or parts of it, may be sent to an external resource via the <send> element. (See 4.1 <send> .) Existing data values may be modified with the <assign> element. (See 5.3 <assign> ).

Logically, there is a single globally visible data model for the entire state machine. As an authoring convenience, however, we allow <datamodel> as a child of any <state>, thus allowing parts of the data model to be distributed throughout the document closer to the locations where the data will be accessed. However, all instances of the <data> element are created and initialized when the state machine is instantiated and may be accessed from any state at any time.

5.1.1 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description
schema false URI none Location of the schema for this datamodel URL of the schema for this datamodel. See 5.4 <validate> for its use. This attribute may occur only on the highest-level <datamodel> element, namely the one that is a child of <scxml>. The exact nature of the schema depends on the data model language being used.

5.1.2 Children

  • <data> Occurs 0 or more times. Each instance defines a named data element.Data elements are created when the document is loaded.

5.2 <data>

The <data> element is used to declare and populate portions of the datamodel. All <data> tags are evaluated exactly once, at load time. Implementations thus MUST evaluate <data> elements at load time but MAY do so in any order they choose. Ordering dependencies among <data> elements are thus not permitted. Suppose, for example, that the declaration of element "a" preceeds the declaration of element "b" in a document. It is not safe to assume that "a" will be instantiated and have a value when the declaration of "b" is executed. Therefore the "expr" in "b" cannot reference the value of "a" (and vice-versa).

5.2.1 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description
id true True ID none The name of the data item. It MUST be unique within the document. See 9 IDs for details.
src false URI none Any URI referencing a legal data value. See 8.3 Legal Data Values and Value Expressions for details. Gives the location from which the data object should be downloaded.
expr false Expression none Any valid value expression Evaluates to provide the value of the data item. See 8.3 Legal Data Values and Value Expressions for details.

5.2.2 Children

The children of the <data> element represent an in-line specification of the value of the data object.

At most one of "src" and "expr" may occur. If either is present, then the element MUST not have any children. Thus "src", "expr" and children are mutually exclusive inside the <data> element.

In addition to the "src" attribute and in-line child elements, values for the top-level <data> elements can be provided by the environment at instantiation time. The exact mechanism for this is implementation dependent, but values provided at instantiation time override those contained in the <scxml> element, whether they are specified in-line or via the "src" attribute.

If the value specified (by 'src', children, or the environment) is not a legal data value, the error error.invaliddata is raised at load time, and an empty data element is created in the data model with the specified id. Note that what constitutes a legal data value depends on the data model language used. See 9 10 Profiles for details.

The <assign> element may be used to modify the data model.

5.3 <assign>

5.3.1 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description
location true path expression none Any valid location expression. The location in the data model into which to insert the new value. See 8.2 Location Expressions for details. Note that in the case of an XML data model (see 9.3 10.3 The XPath Profile ), 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.
dataid false IDREF none The ID of any <data> element in the document The 'id' of a <data> element. If it is provided, the 'location' expression is interpreted as applying to the children of this <data> element. If the 'dataid' is not specified, the 'location' expression is interpreted as applying to the children of the <datamodel> element. This attribute allows a more succinct notation when XPath is used as the expression language, as indicated in 9.3 10.3 The XPath Profile and in the examples below.
expr false value expression none Any valid value expression An expression returning the value to be assigned. See 8.3 Legal Data Values and Value Expressions for details. If 'expr' is specified, no children are permitted.

5.3.2 Children

The children of the <assign>element provide an in-line specification of legal data value (see 8.3 Legal Data Values and Value Expressions ) to be inserted into the datamodel at the specified location.

If "expr" is present, then the element MUST not have any children. Thus "expr" and children are mutually exclusive inside the <assign> element.

Assignment to a data model is done by using a location expression to denote the part of the data model where the change is to be made. If the location expression does not denote a valid location in the datamodel an error error.illegalloc is raised. If the value specified (by 'expr' or children) is not a legal value for the location specified, the error error.invaliddata is raised. Note that what constitutes a legal value depends on the data model language used. See 9 10 Profiles for details.

5.4 <validate>

The <validate> element causes the datamodel to be validated. Note that validation of the datamodel occurs only when explicitly invoked by this element.

5.4.1 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description
location false location expression none Any valid location expression. The location of the subtree to validate. If it is not present, the entire datamodel is validated. See 8.2 Location Expressions for details.
schema false URI none Any valid URI The location of the schema to use for validation. If this attribute is not present, the schema specified in the top-level <datamodel> is used. An error error.validate.validationfailure will be raised at document load time if no schema is specified in either element.

5.4.2 Children

None.

5.5 <param>

The <param> tag provides a general way of accessing the data model. It can be used to identify data to be passed to an external service or to be included in an event.

5.5.1 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description
name true NMTOKEN none A string literal or a valid data model location expression The name of the parameter. It will be passed unmodified to the external service. It need not specify a node in the surrounding data model.
expr false value expression none Valid value expression An optional value expression (see 8.3 Legal Data Values and Value Expressions ). If provided, this expression specifies the value to pass to the invoked component.

If the 'expr' attribute is missing, the 'name' attribute will be taken as a data model location expression (see 8.2 Location Expressions ) and the value at that location will be accessed. If the 'expr' attribute is missing and the 'name' attribute does not refer to a location in the data model, an error error.illegalloc will be generated.

5.5.2 Children

None.

5.6 System Variables

The Data Module maintains a protected portion of the data model containing information that may be useful to applications. We refer to the items in this special part of the data model as 'system variables'. Implementations that include the Data Module MUST provide the following system variables, and MAY support others.

  • _event . The variable '_event' is bound to a structure containing the current event's name and any data contained in the event (see 5.6.1 The Internal Structure of Events . The exact nature of the structure depends on the datamodel being used. See 9 10 Profiles for details. The _event variable is bound when an event is pulled off the internal or external event queue to be processed, and remains bound to that event until another event is processed. When testing the 'cond' attribute of a <transition> element that contains an 'event' attribute, _event will always be bound to the event that the transition is being matched against. If the transition is selected to be executed, _event will remain bound to that event in the <onexit> handlers of the states being exited, the executable content of the transition itself, and the <onentry> handlers of the states being entered. In the case of <transition> elements that do not contain an 'event' attribute and the <onexit> and <onentry> handlers of any states that are exited or entered by such transitions, the _event variable will not have a predictable value since the transition is not being driven by an event. In these cases, _event will be bound to the last event that triggered a transition. _event is unbound when the state machine starts up, and is not bound until an event is processed. See B Algorithm for SCXML Interpretation for details. If the data in the event is not a legal instance of the data model language, and the system cannot translate it into one, then at the point at which the system attempts to bind _event, the error error.invaliddata will be raised and the event data part of the _event structure will not be bound. The event's name will still be available, however. Processing of both the original event and the error event will proceed as usual.
  • _sessionid . The variable _sessionid is bound at load time to the system-generated id for the current SCXML session, which will be of type NMTOKEN. It remains bound until the session terminates.
  • _name . The variable _name is bound at load time to the name of the state machine, which is specified in the "name" attribute of the <scxml> element. It remains bound until the session terminates.
  • _x .The variable _x is the root element for platform-specific system variables. Any platform-specific system variables MUST be created underneath it. The exact structure of the platform-specific variables depends on the data model. For example, in the ECMAScript profile 10.2 The ECMAScript Profile ,'_x' will be a top-level ECMAScript object and the platform-specific system variables will be its properties.

The set of system variables may be expanded in a future version versions of this specification. Therefore developers SHOULD Variable names beginning with '_' are reserved for system use. Developers MUST NOT use ids beginning with '_' in the <data> element since this may cause forwards-compatibility problems. element. Platforms MUST place all platform-specific system variables under the '_x' root.

The concrete realization of these variables in a specific data model depends on the language used. For the exact location of these variables in an XML data model, see 9.3 10.3 The XPath Profile . All system variables are protected and any attempt to change their values MUST fail and result in the error error.illegalassign being raised.

5.6.1 The Internal Structure of Events

Events have an internal structure which will be reflected in the _event variable. Profiles containing a datamodel can access this structure and use it to condition transitions (via boolean expressions in the 'cond' attribute) or to update the datamodel (via <assign>), etc. It is the responsibility of the SCXML platform that receives the events to fill in these fields appropriately. Platforms SHOULD convert data received from external entities into their local datamodel language if possible. If the conversion is not possible, platforms MAY ignore the event or signal an error.

The following fields are present in all events, whether internal or external.

  • name . This is a character string giving the name of the event. It is what is matched against the 'event' attribute of <transition>. Note that transitions can do additional tests by using the value of this field inside boolean expressions in the 'cond' attribute.
  • type . This field describes the event type. It MUST contain one of an enumerated set of string values consisting of: "platform" (for events raised by the platform itself, such as error events), "internal" (for events raised by <raise> and <send> with target '_internal') and "external" (for all other events).
  • sendid . In the case of error events triggered by a failed attempt to send an event, this field will contain the send id of the triggering <send> element. Otherwise it will be blank.

The following fields are logically present in all events, but will be filled in only in external events:

  • origin . This a URI, equivalent to the 'target' attribute on the <send> element. The combination of this field with the 'origintype' field SHOULD allow the receiver of the event to <send> a response back to the entity that originated this event.
  • origintype . This is a character string, similar to the 'type' attribute in <send> he combination of this field with the 'origin' field SHOULD allow the receiver of the event to <send> a response back to the entity that originated this event.
  • invokeid . If this event is generated from an invoked child process, this field will contain the id of the invocation that triggered the child process. Otherwise it will be blank.
  • data . This field contains whatever data the sending entity chose to include in this event. The receiving platform SHOULD reformat this data to match its data model, but MUST not otherwise modify it.

6 Script Module

6.1 <script>

The Script Module adds scripting capability to the state machine. Its schema may be found at D.5 Schema for Script Module . Profiles including the Script Module MUST :

  • Redefine the executable content group to include the <script> tag.
  • Redefine the <scxml> element to allow <script> as a child.

For an example A <script> element that is a child of how to do this, see 9.2 The ECMAScript Profile . <scxml> is evaluated at document load time. All other <script> elements are evaluated as part of normal executable content evaluation.

In profiles that contain both the Script Module and the Data Module, the name of any script variable may be used as a location expression (see 8.2 Location Expressions ).

For an example of a profile incorporating scripting, see 10.2 The ECMAScript Profile .

6.1.1 Attribute Details

None.

6.1.2 Children

The children of the <script> element represent the script code to be executed.

7 Anchor Module

The <anchor> module is intended to provide 'go back' or 'redo' functionality that is useful in some applications. An anchor MAY be specified instead of a "target" for the transition. In this case, the system transitions to the last state visited containing an <anchor> whose "type" matches the "anchor" specified in the transition.

When a state containing an <anchor> element is entered, a snapshot of the data model is taken before the state's <onentry> handler is executed. The default is to snapshot the entire datamodel, but the application author can restrict the snapshot to part of the datamodel using the 'snapshot' attribute. When a transition is taken with an 'anchor' as its target, the state machine returns to the most recently-visited state with an <anchor> whose 'type' attribute matches the 'anchor' in the transition. In the course of the transition, before the state containing the anchor element is entered, the datamodel is restored from the snapshot. The effect is thus to jump back and restart processing at that state. As part of this restart, all intermediate anchors are erased. Intermediate anchors are those that were set between the time the anchor state was last visited and the point at which the transition with the anchor state as target is taken. Note that all these anchors must have a different type from the one that is the target of the transition. If no state with a matching <anchor> type has been visited, the current state is exited and re- entered. For a complete definition of the semantics of <anchor>, see B Algorithm for SCXML Interpretation . For the schema of the Anchor Module, see D.6 Anchor Module Schema .

The ability to reset the datamodel may lead to accidental, unterminated loops in the state machine. The interpreter context MAY detect these and exit. Platforms MAY place limits on the number of snapshots they will store at any one time. Any such limits are platform-specific and outside the scope of this specification.

Profiles that includ the Anchor Module MUST :

7.1 <anchor>

7.1.1 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description
type true xsd:NMTOKEN none Defines the type of this anchor instance.
snapshot false path expression none Any expression denoting a node in the data model. A location in the datamodel to snapshot. If no snapshot value is provided, the entire data model is copied. Implementations MUST support XPath [XPath] as a path expression language and MAY support other languages if they choose. If the special value '_none' is specified, no snapshot is made.

7.1.2 Children

None.

8 Expressions

SCXML contains three types of expressions, as described below. Different profiles of SCXML will support different languages for these expression types, but certain properties of the expressions are constant across profiles and are defined here.

Expressions MUST not contain side effects that would effect the datamodel or the execution of the state machine. Implementations MAY assume that expressions do not have side effects when optimizing expression evaluation. Thus expressions may not be evaluated as often as indicated in B Algorithm for SCXML Interpretation or at the same points in the algorithm.

8.1 Conditional Expressions

Conditional expressions are used inside the 'cond' attribute of <transition>, <if> and <elseif>. If a conditional expression does not evaluate to a boolean value ('true' or 'false'), the error 'error.illegalcond' is raised. The set of operators in conditional expressions varies depending on the profile, but all profiles must support the 'In()' predicate, which is used to test whether the state machine is in a given state. This predicate allows coordination among parallel regions.

8.2 Location Expressions

Location expressions are used to specify a location in the datamodel as part of the <assign>element. The exact nature of a location depends on the profile. For example, in the XPath Profile ( 9.3 10.3 The XPath Profile ), the underlying datamodel is an XML tree and a location expression must evaluate to an existing node or nodeset in the datamodel. If a location expression does not evaluate to a legal location, an error error.illegalloc is raised.

8.3 Legal Data Values and Value Expressions

Any profile that includes the Data Module must specify the structure of the underlying data model. For example, the XPath Profile ( 9.3 10.3 The XPath Profile ) defines the data model to be an XML tree. Such a specification of the data model implicitly defines a set of "legal data values", namely the objects that can be part of such a data model. For an XML data model, the set of legal data values consists of XML trees and subtrees, plus strings (as values of attributes or text children). In conjunction with this, the Profile must define a set of value expressions which can be evaluated at runtime to return legal data values. If a value expression does not return a legal data value, the error error.illegalvalue is raised.

8.4 Errors in Expressions

Implementations MAY raise errors caused by syntactically ill-formed expressions at document load time, or they MAY wait and raise these errors at runtime when the expressions are evaluated. Implementations MUST raise errors caused by expressions returning illegal values at the points at which B Algorithm for SCXML Interpretation indicates that the expressions are to be evaluated. Note that this requirement holds even if the implementation is optimizing expression evaluation.

9 IDs

The values of all attributes of type "id" MUST be unique within the session. When such an attribute is defined to be optional and the author omits it, the system MUST generate a unique one automatically at document load time. Such system generated IDs cannot normally be referenced elsewhere in the document because they are not known to the author. In particular, a state with a system generated ID cannot be the target of a transition. The ids for <send> and <invoke> are subtly different. They must be unique within the session, but in the case where the author does not provide them, the system will generate a new unique ID not at load time but each time the element is executed .Furthermore the attribute 'idlocation' can be used to capture this automatically generated id. Finally note that the automatically generated id for <invoke> has a special format. See 4.3.1 Attribute Details for details. All other automatically generated ids may be in any format, as long as they are unique.

10 Profiles

A profile defines a concrete realization of the language. Each SCXML document MUST specify the profile it uses. At this point, implementations are required to support only the Minimal profile, which defines the core Harel functionality. Implementations MAY support other profiles, including the ECMAScript and XPath profiles defined below. The ECMAScript and XPath profiles, though optional, are normative in the sense that they define how implementations that support one of these languages MUST behave. The intent is to insure 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.

To define a profile, you must first specify the list of modules that the profile includes. This list MUST include the Core module and MAY include other ones. In addition to this list you must:

9.1 10.1 The Minimal Profile

9.1.1 10.1.1 Conformance

The Minimal profile defines a stripped down state machine with no external communications or data model, but with full Harel semantics. Conformant SCXML processors must implement the following modules:

Conformant documents must specify a value of profile="minimal" on the root <scxml> element.

For the schema of theMinimal profile, see D.7 Minimal Profile Schema .

9.1.2 10.1.2 Core Module Requirements

No elements or attributes are extended or redefined. For the schema of the Minimal Profile, see D.7 Minimal Profile Schema .

9.1.2.1 10.1.2.1 Conditional Expressions

The boolean expression language consists of the In predicate only . It has the form 'In( id )', where id is the id of a state in the enclosing state machine.

9.2 10.2 The ECMAScript Profile

9.2.1 10.2.1 Conformance

This section contains information which is specific to the SCXML ECMAScript profile. In particular, it defines the semantics of using ECMAScript in binding expressions for data model access, conditional evaluation, and value expressions in SCXML. It also defines use of the <script> element in this profile.

Conformant SCXML processors MUST implement the following modules from SCXML:

Conformant documents MUST specify a value of profile="ecmascript" on the root <scxml> element.

In addition, conformant implementations of the ECMAScript Profile for SCXML 1.0 MUST support ECMAScript Compact Profile [ECMASCRIPT-327] , a strict subset of the third edition of ECMAScript [ECMASCRIPT-262] . A conformant implementation MAY support ECMAScript for XML (E4X) [E4X] .

Editorial note  

A later version of this specification will clarify how XML data can accessed, manipulated and generated using this profile. Apart from E4X, we are also considering DOM access functions and ECMAScript 4.0 (4th edition of ECMAScript 262).

ECMAScript 4.0 is still under development. The specifications are not yet public. An overview has been published. Many elements of the new language will be familiar to Action Script developers. There are early implementation from Mozilla and on ecmascript.org .

9.2.2 10.2.2 Core Module Requirements

9.2.2.1 10.2.2.1 Conditional Expressions

ECMAScript expressions used in conditional expressions are converted into their effective boolean value using the ToBoolean operator as described in Section 9.2 of [ECMASCRIPT-262] . The expression is evaluated in its own local scope, and allows (read only) access to variables and functions in the global scope, including the data model (see 9.2.3 10.2.3 Data Module Requirements for scoping model).

The following example illustrates this usage.

Example: Use of a boolean expression to determine whether or not a transition is taken.
<state id="errorSwitch">
  <datamodel>
   <data id="time"/>
  </datamodel>
        
  <onentry>
    <assign location="_data.time" expr="currentDateTime()"/>
  </onentry>
          
  <transition cond="yearFromDatetime(_data.time) > 2009" target="newBehavior"/>
 
  <transition target="currentBehavior"/>
</state>

Any errors which arise during the processing of a conditional expression SHOULD be mapped into an SCXML error.illegalcond. errortype event where the optional errortype indicates the ECMAScript error type as specified in Section 15.11.6 of [ECMASCRIPT-262] . For instance, an ECMAScript expression which attempts to assign a value to a variable defined in the global scope would generate an error.illegalcond event.

Conditional expressions may take advantage of the In() predicate. Additional detail appears in 9.2.5.1 10.2.5.1 The In() predicate .

9.2.3 10.2.3 Data Module Requirements

The underlying data model is the subset of the ECMAScript object model as defined by JSON [RFC4627] . SCXML data model expressions are evaluated as ECMAScript expressions in global or local scope as described later in this section.

The SCXML datamodel is implemented as an ECMAScript object with the name _data .

In a <datamodel> element, each <data> child is bound to a property of the _data object. The property name is the value of the id attribute of <data> . The value of the property is assigned by the evaluation one of the following expressions:

  • value of the expr attribute
  • resource referenced by the value of the src attribute. JSON resources have the mime type application/json .
  • inline content

If no value is assigned, the property has the default value ECMAScript undefined.

Evaluation of JSON expressions MUST be supported and evaluation of XML expressions MAY be supported.

The _data object MUST be created by the processor upon initialization of the SCXML document. Any errors which arise during initialization SHOULD be mapped into an SCXML error.illegaldata .errortype event where the optional errortype indicates an ECMAScript error type as specified in Section 15.11.6 of [ECMASCRIPT-262] . For example, an error will be raised if the <data> element's id attribute is not a valid ECMAScript variable name or if the evaluation of the expr attribute value fails.

Example: Datamodel <data> initialization
<scxml version="1.0" profile="ecmascript">
  <datamodel>
   <data id="employees" src="http://example.com/employees.json"/>
   <data id="year" expr="2008"/>
   <data id="CEO" expr="\"Mr Big\""/>
   <data id="profitable" expr="true"/>
  </datamodel>
</scxml>

This profile uses ECMAScript scoping. Elements in the SCXML document are associated with ECMAScript scopes which themselves are chained together. Scopes are created when the SCXML processor enters specific elements, and the scope is destroyed when processor exits the element. This profiles defines two ECMAScript scopes: global and local.

A global scope MUST be defined for each SCXML session. The global scope is created when the SCXML session is created. The SCXML datamodel is contained within the global scope. The global scope has no parent scope.

The SCXML elements <state> , <parallel> , <final> and <transition> , as well as cond attributes, are each associated with an ECMAScript local scope. The local scope always has the global scope as its parent. Consequently, variables and function prototypes in the global scope are accessible through this scope chain.

Variable bindings take place in the local scope except for bindings to the variables defined in the global scope. Consequently, bindings to the datamodel ( _data object) are applied at global scope.

References to variables in the global and local scopes can be disambiguated by explicit scope designation: prepending the scope name plus "." to the variable name. For example, global.time identifies a variable with the name time in global scope, while local.time identifies a variable the same name in local scope. A variable reference without an explicit scope designation, references a variable in the local scope if defined, otherwise references a variable in the global scope.

Variables bindings are defined for the lifecycle of the respective scope.

Editorial note  

We solicit feedback on whether only two scopes, local and global, are sufficient for applications.

9.2.3.1 10.2.3.1 Location Expressions

ECMAScript left-hand-side expressions are used to select an object (or sub-property of an object) from the data model by providing a binding expression. The following example illustrates this usage:

Example: Use of the location attribute of the assign to update the salary of an employee.
<state id="errorSwitch">
    <datamodel>
      <data id="employees" src="http://example.com/employees.json"/>
    </datamodel>
    
    <onentry>
        <assign location="_data.employees.employee[12].salary" expr="42000"/>
    </onentry>
</state>

Any errors which arise during the processing of a location expression SHOULD be mapped into an SCXML error.illegalalloc. errortype event where the optional errortype indicates the ECMAScript error type as specified in Section 15.11.6 of [ECMASCRIPT-262] . For example, an error will arise if there is an attempt to assign a value to a system variable ( 9.2.3.3 10.2.3.3 System Variables ).

9.2.3.2 10.2.3.2 Value Expressions

The result of any ECMAScript expression may be used in a value expression.

Example: Copying event data into the local data model for the state.
<state id="processEvent">
    <datamodel>
        <data id="myEvent"/>
    </datamodel>
    
    <onentry>
        <assign location="_data.myEvent" expr="_event.data"/>
    </onentry>
</state>

Any errors which arise during the processing of a value expression SHOULD be mapped into an SCXML error.illegalvalue. errortype event where the optional errortype indicates the ECMAScript error type as specified in Section 15.11.6 of [ECMASCRIPT-262] .

9.2.3.3 10.2.3.3 System Variables

System variables are defined as ECMAScript read-only variables in global scope. The _event system variable is defined as an object with two properties: name (String value) for the name of the event; and data (Object value) exposing the event data payload. The _sessionid and _name system variables are defined as variables with ECMAScript String values.

The _sessionid and _name values MUST be set by the processor at session start.

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 object payload:


    { "answer" : 42 }

Then the underlying ECMA datamodel would have the following form:

Example: Illustration of system injected properties

{
  // The three properties below are automatically populated by the system
  "_name"      : "myName" ,
  "_sessionid" : "12345"  ,
  "_event"     : {
                    "name" : "foo.bar" ,
                    "data" : {
                               "answer"  :  42
                             }
                 } ,
  // Rest of the application / developer-authored data model goes here
}

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

Example: Accessing system _event name in a condition
<state id="checkSessionid">
    <transition cond="_event.name=='connector.sip.invite'" target="nextState">

<state id="checkEventName">
    <transition cond="_event.name=='foo.bar'" target="nextState">

     ...
    </transition>
</state>

9.2.4 10.2.4 Script Module Requirements

Editorial note  

This section is tentative and subject to revision in a later version of this specification.

In this profile, the inline content of the <script> is an ECMAScript program as defined in Section 14 of [ECMASCRIPT-262] .

This profile allows <script> elements to occur as children of <scxml> elements and within executable content.

When a <script> element is a child of <scxml> its contents are evaluated in global scope at document load time. Defined variables and functions are available through the scope chain to expressions in local scope.

When a <script> element occurs within executable content it is evaluated in the local scope associated with the containing element (or its ancestor).

Any errors which arise during processing of <script> content SHOULD be mapped into an SCXML error.script. errortype event where the optional errortype indicates the ECMAScript error type as specified in Section 15.11.6 of [ECMASCRIPT-262] .

Example: <script> in <scxml> to define global variable and function
<scxml version="1.0" profile="ecmascript">
  <script>
       var globalCounter = 0;
       function updateCounter() {
        globalCounter++;
       }
  </script>
</scxml>
Example: <script> in executable content to manipulate the data model
<state id="updateDM">
    <onentry>
      <script>
        _data.myDate = new Date(); 
        updateCounter();
      </script>
    </onentry>
</state>
Editorial note  

A later version will clarify how inline ECMAScript interacts with fetched ECMAScript programs (where external fetching takes place at document initialization, evaluation when the element is executed).

9.2.5 10.2.5 Additional Requirements

9.2.5.1 10.2.5.1 The In() predicate

A conformant SCXML processor MUST add an ECMAScript function to the SCXML namespace that implements the In() semantics described in section 8.1 of the [SCXML1] specification.

Function signature: function In(arg) { } Returns an ecmascript value indicating whether or not one of the current active states has an id that matches the value of $arg. This value will be converted to boolean using the ToBoolean operator.

9.2.6 10.2.6 Examples

Editorial note  

Detailed examples will be provided in a later version of this specification.

9.3 10.3 The XPath Profile

9.3.1 10.3.1 Conformance

This specification contains information which is specific to the SCXML XPath profile. In particular, it defines the semantics of using XPath in binding expressions for data model access, conditional evaluation, and value expressions in SCXML.

Conformant SCXML processors must implement the following modules from SCXML

Conformant documents must specify a value of profile="xpath" on the root <scxml> element.

In addition, conformant implementations of the XPath Profile for SCXML 1.0 MUST support [XPath 2.0] .

For the schema of the XPath profile, see D.9 XPath Profile Schema .

9.3.2 10.3.2 Core Module Requirements

9.3.2.1 10.3.2.1 Conditional Expressions

XPath 2.0 expressions used in conditional expressions are converted into their effective boolean value as described in section 2.4.3 of the [XPath 2.0] specification. The following example illustrates this usage.

Example: Use of a boolean expression to determine whether or not a transition is taken.
<state id="errorSwitch" xmlns:fn="http://www.w3.org/2005/xpath-functions">
  <datamodel>
    <data id="time"/>
  </datamodel>
          
  <onentry>
    <assign location="$time" expr="fn:current-dateTime()"/>
  </onentry>
          
  <transition cond="fn:year-from-dateTime($time) > 2009" target="newBehavior"/>
  <transition target="currentBehavior"/>
</state>
        

Any errors which arise during the processing of a conditional expression SHOULD be mapped into an SCXML error.illegalcond. errorcode event where the errorcode is the value specified in [XPath 2.0] and related specifications such as the [XPath 2.0 Functions and Operators] . For instance, an XPath expression which attempts to use a component having an undefined value would generate an error.illegalcond.XPST0001 event.

Conditional expressions may take advantage of the scxml:In() predicate. Additional detail appears in 9.3.4.1 10.3.4.1 The scxml:In() predicate .

9.3.3 10.3.3 Data Module Requirements

9.3.3.1 10.3.3.1 Location Expressions

XPath 2.0 expressions are used to select a node-set from the data model by providing a binding expression. The following example illustrates this usage:

Example: Use of the location attribute of the assign to update the count for both Boston and New York.
<state id="errorSwitch">
  <datamodel>
    <data id="cities">
      <list xmlns="">
        <city id="nyc" count="0">New York</city>
        <city id="bos" count="0">Boston</city>
      </list>
    </data>
  </datamodel>
  <onentry>
    <assign location="$cities/list/city[id='nyc']/@count" expr="1"/>
  </onentry>
</state>

Any errors which arise during the processing of a location expression SHOULD be mapped into an SCXML error.illegalalloc. errorcode event where the errorcode is the value specified in [XPath 2.0] and related specifications such as the [XPath 2.0 Functions and Operators] .

9.3.3.2 10.3.3.2 Value Expressions

The result of any XPath expression may be used in a value expression. If the result of the value expression is a node-set, a deep copy of the subtree rooted at each node is made.

Example: Copying event data into the local data model for the state.
<state id="processEvent">
  <datamodel>
    <data id="myEventData"/>
  </datamodel>
    
  <onentry>
    <assign location="$myEventData" expr="$_event/data"/>
  </onentry>
</state>

Any errors which arise during the processing of a value expression SHOULD be mapped into an SCXML error.illegalvalue. errorcode event where the errorcode is the value specified in [XPath 2.0] and related specifications such as the [XPath 2.0 Functions and Operators] .

9.3.3.3 10.3.3.3 System Variables

Within the Data Model, three implicit <data> elements are defined to hold the system variables as described in section 5.6 of the [XPath 2.0] specification. These are named $_event , $_sessionid , and $_name .

The $_event value MUST be assigned by processor before triggering executable content in the <onentry>, <onexit>, and <transition> elements which may reference the variable. The processor MUST clear the value by setting its child elements <name> and <data> to empty XML elements when event processing has completed.

The $_sessionid and $_name values MUST be set by the processor at session start.

The following SCXML illustrates the structure Suppose as part of executing a state machine named "myName" with a platform-assigned sessionid "12345", we are processing an event with the system variables in name "foo.bar" and the XPath profile. following XML payload:

<scxml name="myName" profile="xpath" ...>

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

Then the underlying XML datamodel would have the following form:

Example: Illustration of system injected data
  <datamodel>
    <data id="_name">mySCXMLMachine</data>
    <data id="_sessionid">12343</data>

    <!-- The three data elements below are automatically populated by the system -->
    <data id="_name">myName</data>
    <data id="_sessionid">12345</data>

    <data id="_event">
      <name/>
      <data/>

      <name xmlns="">foo.bar</name>
      <data xmlns="">
        <payload>
          <answer>42</answer>
        </payload>
      </data>

    </data>
    <!-- Rest of the application / developer-authored
         data model goes here -->

  </datamodel>
  ...
</scxml>

 

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

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

  <transition cond="$_sessionid = '12345'" target="nextState"/>

  ...
</state>

9.3.4 10.3.4 Additional Requirements

9.3.4.1 10.3.4.1 The scxml:In() predicate

A conformant SCXML processor MUST add an XPath function to the SCXML namespace that implements the In() semantics described in section 8.1 of the [SCXML1] specification.

Function signature: In($arg as xs:string?) as xs:boolean

Returns an xs:boolean indicating whether or not one of the current active states matches the value of $arg .

9.3.5 10.3.5 Examples

The following examples show various aspects of assignment in the XPath profile. 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[0]/title"  expr="'My favorite book'"/>

<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[0]" "$cart/myCart/books/book[1]" by the XML tree rooted in <bookinfo>.

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

results in

<data id="cart">
  <myCart xmlns="">
    <books>
      <book>
        <bookinfo>
          <isdn>12334455</isdn>
          <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 datamodel we are using does not have an <ISBN> node as a child of <book>:

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

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

10 11 Related Work

A number of other XML-based state machine notations have been developed, but none serves the same purpose as SCXML. XMI [UML XMI] is a notation developed for representing UML diagrams, including Harel State charts. However it is intended as a machine interchange format and is not readily authorable by humans. ebXML [OASIS ebXML] is a language for business process specification intended to support B2B e-commerce applications. It contains a state machine language that is in some ways similar to the one presented here, but its syntax and semantics are closely tied to its intended use in e-commerce. It is therefore not suitable as a general-purpose state machine language. XTND [XTND] , also called XML Transition Network Definition, is a notation for simple finite state machines but lacks Harel's notions of hierarchical and parallel states and are thus not suitable for a general-purpose state machine that is semantically equivalent to Harel statecharts.

A Open Issues

A.1 Removing Restrictions on <invoke>

We are considering allowing: 1) <invoke> to occur in non-atomic states 2) multiple instances of <invoke> to occur within a single state. It is currently possible to get similar functionality by putting instances of <invoke> in parallel states, but this may result in complicated state machines. We solicit comments on whether reducing the restrictions on <invoke> would be useful in practice.

A.2 Iterative Construct

Issue ():

We are considering adding an iterative construct, such as 'foreach' or 'while', to the executable content in the Core module. Such a construct is not strictly necessary, since iterators can be modeled by conditionalized targetless transitions. For example, to model a 'while' loop with condition C and body B, create an eventless transition with condition C and executable content B. It will keep firing and executing B without leaving its containing state as long as C is true. However, an explicit iterator might permit more succinct state machines. We sollicit solicit comments on the usefulness of such a construct.

Resolution: None recorded.

A.2 A.3 Alternative Notation

Issue (alternative_notation):

It could be argued that the current choice of names of SCXML elements and attributes is not optimal. Often rather long words are used (e.g. "transition", "target" and "location"), making lines longer than necessary, and contributing to the size of SCXML documents. Also, abbreviations are used in some cases (e.g. "expr" and "cond") but not in others, which may give the impression of a language not well thought out. Moreover, conventions for how to order the attributes within elements are lacking, which may make SCXML documents harder than necessary to read and understand.

We are considering redesigning this aspect of SCXML. For example, what is now written as follows:

 <transition event="e" cond="x>1" target="s">
    <assign location="/a/b" expr="2"/>
    <send event="e" target="t" expr="5" delay="2s"/>  </transition>

could instead be written like so:

 <go to="s" on="e" if="x>1">
    <assign data="2" to="/a/b"/>
    <send event="e2" data="5" to="t" after="2s"/>  </go>

Note that the latter notation (but not so much the former) suggests a very natural translation into English, e.g. as follows:

"go to s on e if x is bigger than one, assign two to /a/b and send e2 with a payload of five to t after 2 seconds" It seems there might be a way to name elements and attributes that 1) avoids abbreviations, 2) yet uses less space, 3) is easier to write, 4) is easier to read (since it is closer to English) and 5) suggests an natural order of attributes within elements, based on how the element reads when it is translated into English.

Would such a change of naming conventions be an improvement? Could it serve to attract more new users to SCXML? Or would it break to much with "tradition" and thus repell some current users? We solicit feedback on this matter.

Resolution: None recorded.

A.3 A.4 parallel transition order

Issue (transitionOrder):

In the case of transitions selected from parallel regions, the current algorithm completely specifies a) which transition is to be selected in case of conflicts (see isPreempted in B Algorithm for SCXML Interpretation ) and b) the order in which those transitions should be taken (see microstep in B Algorithm for SCXML Interpretation ). However, we could avoid completely specifying one or both of these choices. This would give implementations greater flexibility, but would impair the portability of applications, which would not necessarily behave the same way on different platforms. We solicit feedback on these alternatives.

Resolution: None recorded.

A.4 A.5 error handling

Issue ():

We need to specify the full set of errors that the platform may raise.

Resolution: None recorded.

A.5 Initial transition leading to a history state A.6 Simplification of <send> and <raise>

Issue ():

In Originally, when send and raise were proposed, send was for external communication between the current version SCXML state machine and an external instance (which might be an SCXML state machine or might be something else). Raise was an internal mechanism that allowed a state machine to raise an internal event - even in the absence of an external communication module or in the algorithm, having absence of a data model. The semantics of sending oneself an <initial> element event and raising an event were further different because when an event is sent using the send tag it always went on the external event queue, and when one raised an event that was always delivered to the internal event queue.

Over time, there were change requests to allow data passing with a transition the raise tag. This is never really strictly necessary since the data model is global and the raised event is internal to the state machine, but it can be convenient if the same transition may not care if it is handling a <history> pseudo-state leads raised event or an external event or if the data model may be modified in between when an event is raised and when it ends up being handled (due to unexpected results. the presence of other events on the internal event queue).

Over time, there were also change requests to allow the send tag, from the external communications module, to be able to send an event to the internal queue. The default history state special _internal valuer was used in send to achieve this goal. This is entered, even never strictly necessary due to the presence of the raise tag, but might be convenient if the state has already been visited send tag used targetexpr where the target is sometimes _internal and sometimes an external resource.

With these change requests the raise and send tags have become more similar and there are some discussions about what should be done. There are some arguments for leaving things as is: namely the raise is a non-default history value. Resolution: lighter weight than the send and could be present even in the absence of the external communications module. However there are arguments for changing the current state of the world as well: namely there are two ways to do the same thing and some people would rather either combine the two tags to make it less confusing or else make the separation more distinct by reverting the functionality in either send or raise or both to keep the two purposes distinct.

None recorded. The working group is considering these issues and solicits comments from the wider community on which approach they prefer.

B Algorithm for SCXML Interpretation

This section presents a normative algorithm for the interpretation of an SCXML document. Implementations are free to implement SCXML interpreters in any way they choose, but they must behave as if they were using the algorithm defined here.

The fact that SCXML implements a variant of the Statechart formalism does not as such determine a semantics for SCXML. Many different Statechart variants have been proposed, each with its own semantics. This section presents an informal semantics of SCXML documents, as well as a normative algorithm for the interpretation of SCXML documents.

Informal Semantics

The following definitions and highlevel principles and constraint are intended to provide a background to the normative algorithm, and to serve as a guide for the proper understanding of it.

Preliminary definitions

state
An element of type <state>, <parallel>, <final> or <scxml>.
pseudo state
An element of type <initial> or <history>.
transition target
A state, or an element of type <history>.
atomic state
A state of type <state> with no child states, or a state of type <final>.
compound state
A state of type <state> with at least one child state, or a state of type <scxml>.
start state
A dummy state equipped with a transition which when triggered by the Run event leads to the initial state(s). Added by the interpreter with an id guaranteed to be unique within the statemachine. The only role of the start state is to simplify the algorithm.
configuration
The maximal consistent set of states (including parallel and final states) that the machine is currently in. We note that if a state s is in the configuration c, it is always the case that the parent of s (if any) is also in c. Note, however, that <scxml> is not a(n explicit) member of the configuration.
source state
The source state of a transition is the atomic state from which the transition is leaving.
target state
A target state of a transition is a state that the transition is entering. Note that a transition can have zero or more target states.
targetless transition
A transition having zero target states.
eventless transition
A transition lacking the 'event' attribute.
external event
An SCXML event appearing in the external event queue. See section ? for details.
internal event
An event appearing in the internal event queue. It's exact representation is implementation dependent, but a simple string would work.
macrostep
An external event causes an SCXML state machine to take exactly one macrostep. A macrostep consists of a sequence (a chain) of microsteps. However, if the external event does not enable any transitions, no microstep will be taken, and the corresponding macrostep will be empty.
microstep
If an external event enables one or (in the case of parallel states) more transitions, a microstep is taken, involving the processing of each of the enabled transitions. This microstep may change the the current configuration, update the datamodel and/or generate new (internal and/or external) events. This, by causality, may in turn enable additional transitions which will be handled in the next microstep in the sequence, and so on.

Principles and Constraints

We state here some principles and constraints, on the level of semantics, that SCXML adheres to:

Encapsulation
An SCXML processor is a pure event processor . The only way to get data into an SCXML statemachine is to send external events to it. The only way to get data out is to receive events from it.
Causality
There shall be a causal justification of why events are (or are not) returned back to the environment, which can be traced back to the events provided by the system environment.
Determinism
An SCXML statemachine which does not invoke any external event processor must always react with the same behavior (i.e. the same sequence of output events) to a given sequence of input events (unless, of course, the statemachine is explicitly programmed to exhibit an non-deterministic behavior). In particular, the availability of the <parallel> element must not introduce any non-determinism of the kind often associated with concurrency. Note that observable determinism does not necessarily hold for state machines that invoke other event processors.
Completeness
An SCXML interpreter must always treat an SCXML document as completely specifying the behavior of a statemachine. In particular, SCXML is designed to use priorities (based on document order) to resolve situations which other statemachine frameworks would allow to remain under-specified (and thus non-deterministic, although in a different sense from the above).
Run to completion
SCXML adheres to a run to completion semantics in the sense that an external event can only be processed when the processing of the previous external event has completed, i.e. when all microsteps (involving all triggered transitions) have been completely taken.
Termination
A microstep always terminates. A macrostep may not. A macrostep that does not terminate may be said to consist of an infinitely long sequence of microsteps. This is currently allowed.

Algorithm

This section presents a normative algorithm for the interpretation of SCXML documents. Implementations are free to implement SCXML interpreters in any way they choose, but they must behave as if they were using the algorithm defined here. Note that the algorithm assumes a Lisp-like semantics in which the empty Set null is equivalent to boolean 'false' and all other entities are equivalent to 'true'.

Datatypes

These are the abstract datatypes that are used in the algorithm.

datatype List
   function head()      // Returns the head of the list
   function tail()      // Returns the tail of the list
   function append(l)   // Returns the list appended with l
    filter(f)   // Returns the list of elements that satify the predicate f
    some(f)     // Returns true if some element in the list satifies the predicate f
    every(f)    // Returns true if every element in the list satifies the predicate f

   function filter(f)   // Returns the list of elements that satisfy the predicate f
   function some(f)     // Returns true if some element in the list satisfies the predicate f
   function every(f)    // Returns true if every element in the list satisfies the predicate f
datatype Set
   procedure add(e)     // Adds e to the set
   procedure delete(e)  // Deletes e from the set
   function member(e)   // Is e a member of set?
   function isEmpty()   // Is the set empty?
   function toList()    // Converts the set to a list
   function diff(set2)  //Returns all members of Set that are not in set2
datatype Queue
   procedure enqueue(e) // Puts e last in the queue
   function dequeue()   // Removes and returns first element in queue
   function isEmpty()   // Is the queue empty?
datatype BlockingQueue
   procedure enqueue(e) // Puts e last in the queue
   function dequeue()   // Removes and returns first element in queue, blocks if queue is empty

Global variables

The following variables are global from the point of view of the algorithm. Their values will be set in the procedure interpret() .

global datamodel;
global configuration;
global internalQueue;
global externalQueue;
global historyValue;
global continue
 

Procedures and Functions

This section defines the procedures and functions that make up the core of the SCXML interpreter.

procedure interpret(scxml,id)

The purpose of this procedure is to initialize the interpreter. It is called with a parsed representation of an SCXML document.

In order to interpret an SCXML document, first perform inplace expansions of states by including SCXML source referenced by urls (see 3.13 Referencing External Files ) and change initial attributes to initial container children with empty transitions to the state from the attribute. Then (optionally) validate the resulting SCXML, and throw an exception if validation fails. Create an empty configuration complete with a new populated instance of the data model and a execute the global scripts. Create the two queues to handle events and set the global continue variable to true. Call executeTransitionContent on the initial transition that is a child of scxml. Then call enterState on the initial transition. Finally, start the interpreter's event loop.

procedure interpret(doc):
   expandScxmlSource(doc)
   if (!valid(doc)) {fail with error}
   configuration = new Set()
   previousConfiguration = newSet()
   datamodel = new Datamodel(doc)
   executeGlobalScriptElements(doc)
   internalQueue = new Queue()
   externalQueue = new BlockingQueue()
   continue = true
   executeTransitionContent([doc.initial.transition])
   enterState([doc.initial.transition])
   startEventLoop()

procedure startEventLoop()

Upon entering the state machine, we take all internally enabled transitions, namely those that don't require an event and those that are triggered by internal events. (Internal events can only be generated by the state machine itself.) When all such transitions have been taken, we move to the main event loop, which is driven by external events.

procedure procedure startEventLoop():
   previousConfiguration = null;
   
   initialStepComplete = false;
   until(initialStepComplete):
        enabledTransitions = selectTransitions(null)
        if (enabledTransitions.isEmpty()): 
           internalEvent = internalQueue.dequeue()// this call returns immediately if no event is available
             if (internalEvent):
                datamodel.assignValue("event", internalEvent)
                enabledTransitions = selectTransitions(internalEvent)
               
        if (enabledTransitions):
           microstep(enabledTransitions.toList()
        else:
           initialStepComplete = true

         initialStepComplete = false;
         until(initialStepComplete):
            enabledTransitions = selectEventlessTransitions()
            if (enabledTransitions.isEmpty()): 
               internalEvent = internalQueue.dequeue()// this call returns immediately if no event is available
               if (internalEvent):
                  datamodel.assignValue("event", internalEvent)
                  enabledTransitions = selectTransitions(internalEvent)
               else:
                  initialStepComplete = true
 
            if (enabledTransitions):
                microstep(enabledTransitions.toList()

   
   mainEventLoop()

procedure mainEventLoop()

This loop runs until we enter a top-level final state or an external entity cancels processing. In either case 'continue' will be set to false (see EnterStates, below, for termination by entering a top-level final state.)

Each iteration through the loop consists of three main steps: 1) execute any <invoke> tags for atomic states that we entered on the last iteration through the loop 2) Wait for an external event and then execute any transitions that it triggers 3) Take any subsequent internally enabled transitions, namely those that don't require an event or that are triggered by an internal event.

This event loop thus enforces run-to-completion semantics, in which the system process an external event and then takes all the 'follow-up' transitions that the processing has enabled before looking for another external event. For example, suppose that the external event queue contains events e1 and e2 and the machine is in state s1. If processing e1 takes the machine to s2 and generates internal event e3, and s2 contains a transition t triggered by e3, the system is guaranteed to take t, no matter what transitions s2 or other states have that would be triggered by e2. Note that this is true even though e2 was already in the external event queue when e3 was generated. In effect, the algorithm treats the processing of e3 as finishing up the processing of e1.

procedure procedure mainEventLoop():
   while(continue):
   
      for state in configuration.diff(previousConfiguration):
         if(isAtomic(state)):
            if state.invoke:
               state.invokeid = executeInvoke(state.invoke)
               datamodel.assignValue(state.invoke.attribute('idlocation'),state.invokeid)
      
      previousConfiguration = configuration
      externalEvent = externalQueue.dequeue() // this call blocks until an event is available
      datamodel.assignValue("event",externalEvent)
      enabledTransitions = selectTransitions(externalEvent)
      
      if (enabledTransitions):
         microstep(enabledTransitions.toList())
         
         // now take any newly enabled null transitions and any transitions triggered by internal events
         macroStepComplete = false;
         until(macroStepComplete):
            enabledTransitions = selectEventlessTransitions()
            if (enabledTransitions.isEmpty()): 
               internalEvent = internalQueue.dequeue()// this call returns immediately if no event is available
               if (internalEvent):
                  datamodel.assignValue("event", internalEvent)
                  enabledTransitions = selectTransitions(internalEvent)
               

               else:
                  macroStepComplete = true
 

            if (enabledTransitions):
               microstep(enabledTransitions.toList()
            else:
               macroStepComplete = true
       

                microstep(enabledTransitions.toList()
        

   // if we get here, we have reached a top-level final state or some external entity has set continue to false      
   exitInterpreter()  
    

procedure exitInterpreter()

The purpose of this procedure is to exit the current SCXML process by exiting all active states. If the machine is in a top-level final state, a Done event is generated.

procedure exitInterpreter():
   inFinalState = false
   statesToExit = new Set(configuration)
   for s in statesToExit.toList().sort(exitOrder)
      for content in s.onexit:
         executeContent(content)
      for inv in s.invoke:
         cancelInvoke(inv)
      if (isFinalState(s) && isScxmlState(s.parent())):
         inFinalState = true
      configuration.delete(s)
   if (inFinalState):
      sendDoneEvent(???)

function selectEventlessTransitions()

This function selects all transitions that are enabled in the current configuration that do not require an event trigger. First test if the state has been preempted by a transition that has already been selected and that will cause the state to be exited when the transition is taken. If the state has not been preempted, find a transition with no 'event' attribute whose condition evaluates to true . If multiple matching transitions are present, take the first in document order. If none are present, search in the state's ancestors in ancestory order until one is found. As soon as such a transition is found, add it to enabledTransitions , and proceed to the next atomic state in the configuration. If no such transition is found in the state or its ancestors, proceed to the next state in the configuration. When all atomic states have been visited and transitions selected, return the set of enabled transitions.

function selectEventlessTransitions(event):
   enabledTransitions = new Set()
   atomicStates = configuration.toList().filter(isAtomicState)
   for state in atomicStates:
         if !(isPreempted(s, enabledTransitions)):
         loop: for s in [state].append(getProperAncestors(state,null)):
            for t in s.transition:
               if ( t.attribute('event') == null && conditionMatch(t)) 
               enabledTransitions.add(t)
               break loop
   return enabledTransitions

function selectTransitions(event)

The purpose of the selectTransitions() procedure is to collect the transitions that are enabled by this event in the current configuration.

Create an empty set of enabledTransitions . For each atomic state in the configuration, first check if the event is the result of an <invoke> in this state. If so, apply any <finalize> code in the state. Next test if the state has been preempted by a transition that has already been selected and that will cause the state to be exited when the transition is taken. If the state has not been preempted, find a transition whose 'event' attribute matches event and whose condition evaluates to true . If multiple matching transitions are present, take the first in document order. If none are present, search in the state's ancestors in ancestory ancestry order until one is found. As soon as such a transition is found, add it to enabledTransitions , and proceed to the next atomic state in the configuration. If no such transition is found in the state or its ancestors, proceed to the next state in the configuration. When all atomic states have been visited and transitions selected, return the set of enabled transitions.

function selectTransitions(event):
   enabledTransitions = new Set()
   atomicStates = configuration.toList().filter(isAtomicState)
   for state in atomicStates:
      if (event.attribute('invokeid') != null && state.invokeid = event.invokeid):  //event is the result of an <invoke> in this state
         applyFinalize(state, event)
      if !(isPreempted(s, enabledTransitions)):
         loop: for s in [state].append(getProperAncestors(state,null)):
            for t in s.transition:
               if (t.attribute('event')!= null && isPrefix(t.attribute('event'), event.name) && conditionMatch(t)):
               enabledTransitions.add(t)
               break loop
   return enabledTransitions

function isPreempted(s transitionList)

Return true if a transition T in transitionList exits an ancestor of state s. In this case, taking T will pull the state machine out of s and we say that it preempts the selection of a transition from s. Such preemption will occur only if s is a descendant of a parallel region and T exits that region. If we did not do this preemption check, we could end up in an illegal configuration, namely one in which there were multiple active states that were not all descendants of a common parallel ancestor.

function isPreempted(s transitionList):
   preempted = false
   for t in transitionList:
      if (t.attribute('target') != null):
         LCA = findLCA([t.parent()].append(getTargetStates(t)))
         if (isDescendant(s,LCA)):
            preempted = true
            break
   return preempted

procedure microstep(enabledTransitions)

The purpose of the microstep procedure is to process the set of transitions enabled by an external event, an internal event, or by the presence or absence of certain values in the datamodel at the current point in time. The processing of the enabled transitions must be done in parallel ('lock step') in the sense that their source states must first be exited, then their actions must be executed, and finally their target states entered.

procedure microstep(enabledTransitions):
   exitStates(enabledTransitions)
   executeTransitionContent(enabledTransitions)
   enterStates(enabledTransitions)

procedure exitStates(enabledTransitions)

Create an empty statesToExit set. For each transition t in enabledTransitions , if t is targetless then do nothing, else let LCA be the least common ancestor state of the source state and target states of t . Add to the statesToExit set all states in the configuration that are descendants of LCA . Convert the statesToExit set to a list and sort it in exitOrder .

For each state s in the list, if s has a deep history state h , set the history value of h to be the list of all atomic descendants of s that are members in the current configuration, else set its value to be the list of all immediate children of s that are members of the current configuration. Again for each state s in the list, first execute any onexit handlers, then cancel any ongoing invocations, and finally remove s from the current configuration.

procedure exitStates(enabledTransitions):
   statesToExit = new Set()
   for t in enabledTransitions:
      if (t.attribute('target') != null):
         LCA = findLCA([t.parent()].append(getTargetStates(t)))
         for s in configuration.toList():
            if (isDescendant(s,LCA)):
               statesToExit.add(s)
   statesToExit = statesToExit.toList().sort(exitOrder)
   for s in statesToExit:
      for h in s.history:
         f = (h.attribute('type') == "deep") ?
             lambda(s0): isAtomicState(s0) && isDescendant(s0,s) :
             lambda(s0): s0.parent() == s
         historyValue[h.attribute('id')] = configuration.toList().filter(f)
   for s in statesToExit:
      for content in s.onexit:
         executeContent(content)
      for inv in s.invoke:
         cancelInvoke(inv)
      configuration.delete(s)

procedure executeTransitionContent(enabledTransitions)

For each transition in the list of enabledTransitions , execute its executable content.

 executeTransitions(enabledTransitions):

procedure executeTransitionContent(enabledTransitions):
   for t in enabledTransitions:
      executeContent(t)

procedure enterStates(enabledTransitions)

Create an empty statesToEnter set, and an empty statesForDefaultEntry set. For each transition t in enabledTransitions , if t is targetless then do nothing, else let LCA be the least common ancestor state of the source state and target states of t . For each target state s , if s is a history state then add either the history values associated with s or s 's default target to statesToEnter . Else (if s is not a history state), add s to statesToEnter . Convert statesToEnter to a list and sort it in enterorder .

For each state s in the list, first add s to the current configuration, then invoke any external processes specified in <invoke> elements and assign their sessionid s to the datamodel, keyed on the <invoke> element's id, then execute any onentry handlers, and finally, if s is a final state, generate relevant Done events. If we have reached a top-level final state, exit the interpreter.

procedure enterStates(enabledTransitions):
   statesToEnter = new Set()
   statesForDefaultEntry = new Set()
   for t in enabledTransitions:
      if (t.attribute('target') != null):
         LCA = findLCA([t.parent()].append(getTargetStates(t)))
         for s in getTargetStates(t):
             (isHistoryState(s)):
               ):
                   historyValue[s.attribute('id')]:
                     addStatesToEnter(s0,LCA,statesToEnter,statesForDefaultEntry)
               :
                   getTargetStates(s.transition):
                     addStatesToEnter(s0,LCA,statesToEnter,statesForDefaultEntry)
            :
               addStatesToEnter(s,LCA,statesToEnter,statesForDefaultEntry)

            addStatesToEnter(s,LCA,statesToEnter,statesForDefaultEntry)

   statesToEnter = statesToEnter.toList().sort(enterOrder)
   for s in statesToEnter:
      configuration.add(s)
      for content in s.onentry:
         executeContent(content)
      if (statesForDefaultEntry.member(s)):
         executeContent(s.initial.transition.children())
      if (isFinalState(s)):
         parent = s.parent()
         grandparent = parent.parent()
         internalQueue.enqueue(parent.attribute('id') + ".Done")
         if (isParallelState(grandparent)):
            if (getChildStates(grandparent).every(isInFinalState)):
               internalQueue.enqueue(grandparent.attribute('id') + ".Done")
   for s in configuration.toList():
      if (isFinalState(s) && isScxmlState(s.parent())):
         continue = false;

procedure addStatesToEnter(s,root,statesToEnter,statesForDefaultEntry)

The purpose of this procedure is to add to statesToEnter all states that must be entered as a result of entering state s . These include ancestors of s , parallel siblings of s or its ancestors, and s 's default children, if s is a parallel or compound state. Note that this procedure permanently modifies both statesToEnter and statesForDefaultEntry .

First, If s is a history state then add either the history values associated with s or s 's default target to statesToEnter .Else (if s is not a history state), add s to statesToEnter . Then, if s is a parallel state, add each of s 's children to statesToEnter . Else, if s is a compound state, add s to statesForDefaultEntry and add its default initial state to statesToEnter . Finally, for each ancestor anc of s , add anc to statesToEnter and if anc is a parallel state, add the children any child of anc that does not have a descendant on statesToEnter to statesToEnter .

procedure addStatesToEnter(s,root,statesToEnter,statesForDefaultEntry):
   statesToEnter.add(s)
    (isParallelState(s)):
       getChildStates(s):
         addStatesToEnter(child,s,statesToEnter,statesForDefaultEntry)
    (isCompoundState(s)):
      statesForDefaultEntry.add(s)
      addStatesToEnter(getDefaultInitialState(s),s,statesToEnter,statesForDefaultEntry)
    getProperAncestors(s,root):
      statesToEnter.add(anc)
       (isParallelState(anc)):
          getChildStates(anc):
             (!statesToEnter.toList().some(lambda(s): isDescendant(s,anc))):
               addStatesToEnter(pChild,anc,statesToEnter,statesForDefaultEntry)

   if (isHistoryState(s)):
       if (historyValue[s.attribute('id')] != null):
          for s0 in historyValue[s.attribute('id')]:
              addStatesToEnter(s0,LCA,statesToEnter,statesForDefaultEntry)
          else:             for s0 in getTargetStates(s.transition):
                addStatesToEnter(s0,LCA,statesToEnter,statesForDefaultEntry)
   else:
       statesToEnter.add(s)
       if (isParallelState(s)):          for child in getChildStates(s):
             addStatesToEnter(child,s,statesToEnter,statesForDefaultEntry)
       elif (isCompoundState(s)):
          statesForDefaultEntry.add(s)
          addStatesToEnter(getDefaultInitialState(s),s,statesToEnter,statesForDefaultEntry)
       for anc in getProperAncestors(s,root):
           statesToEnter.add(anc)
           if (isParallelState(anc)):              for pChild in getChildStates(anc):                 if (!statesToEnter.toList().some(lambda(s2): isDescendant(s2,pChild))):
                     addStatesToEnter(pChild,anc,statesToEnter,statesForDefaultEntry)

procedure isInFinalState(s)

Return true if state s is a compound <state> and one of its children is a <final> state and is a member of the configuration, or if s is a <parallel> state and isInFinalState is true of all its children.

function isInFinalState(s):
   if (isCompoundState(s)):
      return getChildStates(s).some(lambda(s): isFinalState(s) && configuration.member(s))
   elif (isParallelState(s)):
      return getChildStates(s).every(isInFinalState)
   else:
      return false

function findLCA(stateList)

Return the state element s such that s is a proper ancestor of all states on stateList and no descendant of s has this property. Note that there is guaranteed to be such a state an element since the <scxml> wrapper element (which we treat as a state here) is a common ancestor of all states. Note also that since we are speaking of proper ancestor (parent or parent of a parent, etc.) the LCA is never a member of stateList .

function findLCA(stateList):
    for anc in getProperAncestors(stateList.head(),null):
      if (stateList.tail().every(lambda(s): isDescendant(s,anc))):
         return anc

B.1 Semantics of <anchor>

There are a number of ways of defining the semantics of <anchor>. We choose the following because it shows that, <anchor> appears to represent an extension to Harel State Charts. However, except for the rollback of the data model, <anchor> can be viewed as a syntactic shortcut that does not extend the basic Harel semantics. We emphasize that implementations are required only to behave as if they assigned This section explains the following interpretation syntactic construction that can be used to represent <anchor> and that simpler and more efficient implementations are possible. in a pure Harel model.

First, we add a special branch 'anchors' to the data model, with a child for each anchor type defined in the document. Thus if the document defines anchor types "foo" and "bar", the data model will have paths 'anchors.foo' and 'anchors.bar'. Whenever the state machine enters a state with an <anchor> element, it sets the value of the corresponding anchor entry in the datamodel to the id of that state. Thus if a <state> with id 'state27' defines an <anchor> with 'type' "foo", whenever the state machine visits this state, it sets 'anchors.foo; to 'state27'. Furthermore, the state machine automatically adds the 'anchors' branch to the snapshot specified in the <anchor> element.

Now any <transition> which specifies an 'anchor' is replaced with a set of <transition>s, one for each <state> that defines that <anchor>. Each of the <transition>s takes as its 'target' one of the <state>s that defines the <anchor>. Furthermore, an extra clause is added to the 'cond' of the original <transition>, specifying that the corresponding location in the data model match the target <state>'s id. Finally, a default transition is added reentering the current <state>. For example, if the anchor type "foo" is defined in <state>s 'state27' and 'state33', then in <state> 'thisState', a transition with "event" "someEvent", "cond" "someCond" and "anchor" 'foo' will be replaced by three transitions, as shown below:

<transition event="someEvent" cond="someCond" anchor="foo"/>

is equivalent to

<transition event="someEvent" cond="datamodel.anchors.foo==state27 && someCond" target="state27"/>    
<transition event="someEvent" cond="datamodel.anchors.foo==state33 && someCond" target="state33"/> 
<transition event="someEvent" cond="someCond" target="state33"/> target="thisState"/>

At runtime when "someEvent" is raised and "someCond" is true, if either state27 or state33 has been visited, 'datamodel.anchors.foo' will have the corresponding stateid as its value and the corresponding transition will be selected. The only complication is that the transitions must retain the original 'anchor' attribute, so that the datamodel must be rolled back to the snapshot specified in the corresponding <anchor> element. Note that the 'anchors' branch must be automatically added to this snapshot, so that it will be automatically rolled back as well. (This has the effect of erasing any intermediate anchors that have been visited since the target state was exited.) If neither state27 nor state33 has been visited, the third transition will be taken, causing the state machine to exit and reenter 'thisState' without any rollback of the datamodel.

C Probabilistic State Machines

In some applications, it is useful for a state machine to behave non-deterministically according to a probability distribution. For example, we may want to have a state S1 which transitions to S2 30% of the time and to S3 70% of the time. Such behavior can be modeled in SCXML as long as the executable content includes a random number generator. In the example below, we use ECMAScript to generate a random number between 0.0 and 1.0 in the <onentry> handler of state S1. S1 has two transitions, both triggered by E1, going to states S2 and S3. S1 takes the first transition if the variable <rand> is ≤ 0.3 but the second transition if <rand> is > 0.3. Since <rand> is evenly distributed between 0.0 and 1.0, S1 will transition to S2 30% of the time and S3 70% of the time on event E1. Note that it is important that the random number generation take place outside the <cond> clause of the transition since there are no guarantees of when or how often that will be evaluated.

<scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0" initialstate="S1">
  
  <state id="S1">
    <datamodel>
      <data name="rand">
    </datamodel>
    <onentry>
      <assign name="rand" expr="Math.random()"/>
    </onentry>
    <transition event="E1" cond="rand <= 0.3" target="S2"/>
    <transition event="E1" cond="rand > 0.3" target="S3">
  </state>
  
  <state id="S2"/>
  <state id="S3"/>
  
</scxml>

D Schemas

D.1 Utility Schemas

The following schemas contain common definitions that are used by the schemas for specific modules and profiles.

scxml-datatypes.xsd

<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2008 sp1 (http://www.altova.com) by Alicia Fraumeni (Genesys Telecommunications Laboratories) -->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <xsd:annotation>
                <xsd:documentation>
                         XML Schema datatypes for SCXML
                        Defines containers for the SCXML datatypes, many of these
                        imported from other specifications and standards.
                </xsd:documentation>
                <xsd:documentation source="scxml-copyright.xsd"/>
        </xsd:annotation>
        <xsd:simpleType name="Exmode.datatype">
                <xsd:annotation>
                        <xsd:documentation>
                               execution mode     
                        </xsd:documentation>
                </xsd:annotation>
                <xsd:restriction base="xsd:NMTOKEN">
                        <xsd:enumeration value="lax"/>
                        <xsd:enumeration value="strict"/>
                </xsd:restriction>
        </xsd:simpleType>
        <xsd:simpleType name="Profile.datatype">
                <xsd:annotation>
                        <xsd:documentation>
                               profile 
                        </xsd:documentation>
                </xsd:annotation>
                <xsd:restriction base="xsd:NMTOKEN">
                        <xsd:enumeration value="minimum"/>

                        <xsd:enumeration value="minimal"/>

                        <xsd:enumeration value="xpath"/>
                        <xsd:enumeration value="ecmascript"/>
                </xsd:restriction>
        </xsd:simpleType>
        <xsd:simpleType name="HistoryType.datatype">
                <xsd:restriction base="xsd:string">
                        <xsd:enumeration value="shallow"/>
                        <xsd:enumeration value="deep"/>
                </xsd:restriction>
        </xsd:simpleType>
        <xsd:simpleType name="Boolean.datatype">
                <xsd:annotation>
                        <xsd:documentation>
                                Boolean: true or false only
                        </xsd:documentation>
                </xsd:annotation>
                <xsd:restriction base="xsd:NMTOKENS">
                        <xsd:enumeration value="true"/>
                        <xsd:enumeration value="false"/>
                </xsd:restriction>
        </xsd:simpleType>
        <xsd:simpleType name="URI.datatype">
                <xsd:annotation>
                        <xsd:documentation>
                                The xsd:anyURI type and thus URI references in SCXML
                                documents may contain a wide array of international
                                characters. Implementers should reference RFC 3987 and
                                the "Character Model for the World Wide Web 1.0:
                                Resource Identifiers" in order to provide appropriate
                                support for these characters in VoiceXML documents and
                                when processing values of this type or mapping them to
                                URIs.
                        </xsd:documentation>
                </xsd:annotation>
                <xsd:restriction base="xsd:anyURI"/>
        </xsd:simpleType>
        <xsd:simpleType name="Integer.datatype">
                <xsd:annotation>
                        <xsd:documentation>Non-negative integer</xsd:documentation>
                </xsd:annotation>
                <xsd:restriction base="xsd:nonNegativeInteger"/>
        </xsd:simpleType>
        <xsd:simpleType name="Duration.datatype">
                <xsd:annotation>
                        <xsd:documentation>
                                Time designation following Time [CSS2]; negative numbers
                                not allowed 
                        </xsd:documentation>
                </xsd:annotation>
                <xsd:restriction base="xsd:string">
                        <xsd:pattern value="(\+)?([0-9]*\.)?[0-9]+(ms|s)"/>
                </xsd:restriction>
        </xsd:simpleType>
        <xsd:simpleType name="ContentType.datatype">
                <xsd:annotation>
                        <xsd:documentation>Content type [RFC2045]</xsd:documentation>
                </xsd:annotation>
                <xsd:list itemType="xsd:token"/>
        </xsd:simpleType>
        <xsd:simpleType name="EventType.datatype">
                <xsd:annotation>
                        <xsd:documentation>
             EventType     
            </xsd:documentation>
                </xsd:annotation>
                <xsd:restriction base="xsd:token">
                        <xsd:pattern value="[\c\*]+"/>
                </xsd:restriction>
        </xsd:simpleType>
        <!-- Defines the  default CondLang datatype.        -->
        <xsd:simpleType name="CondLang.datatype">
                <xsd:annotation>
                        <xsd:documentation>
                                  Conditional language is expression 
                                  which must evaluate to Boolean True or False. 
                                  The expression language must define In(stateID) 
                                  as a valid expression.
            </xsd:documentation>
                </xsd:annotation>
                <xsd:restriction base="xsd:string"/>
        </xsd:simpleType>
        <!-- Defines the  default LocLang datatype.         -->
        <xsd:simpleType name="LocLang.datatype">
                <xsd:annotation>
                        <xsd:documentation>
                                  Location language is expression
                                  identifying a location in the datamodel.  
                </xsd:documentation>
                </xsd:annotation>
                <xsd:restriction base="xsd:string"/>
        </xsd:simpleType>
        <!-- Defines the default ValueLang datatype.       -->
        <xsd:simpleType name="ValueLang.datatype">
                <xsd:annotation>
                        <xsd:documentation>
                                  Value language is expression
                                  return a value.
            </xsd:documentation>
                </xsd:annotation>
                <xsd:restriction base="xsd:string"/>
        </xsd:simpleType>
</xsd:schema>

scxml-attribs.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <xsd:annotation>
                <xsd:documentation>
      This is the XML Schema common attributes for SCXML
    </xsd:documentation>
                <xsd:documentation source="scxml-copyright.xsd"/>
        </xsd:annotation>
        <xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This import brings in the XML namespace attributes
                                The module itself does not provide the schemaLocation
                                and expects the driver schema to provide the
                                actual SchemaLocation.
                  </xsd:documentation>
                </xsd:annotation>
        </xsd:import>
        <xsd:include schemaLocation="scxml-datatypes.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This include  brings in the SCXML datatypes.
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        
        <xsd:attributeGroup name="Fetchtimeout.attrib">
                <xsd:annotation>
                        <xsd:documentation>Used in Cache.attribs</xsd:documentation>
                </xsd:annotation>
                <xsd:attribute name="fetchtimeout" type="Duration.datatype"/>
        </xsd:attributeGroup>
        <xsd:attributeGroup name="Maxage.attrib">
                <xsd:annotation>
                        <xsd:documentation>Used in Cache.attribs</xsd:documentation>
                </xsd:annotation>
                <xsd:attribute name="maxage" type="Integer.datatype"/>
        </xsd:attributeGroup>
        <xsd:attributeGroup name="Maxstale.attrib">
                <xsd:annotation>
                        <xsd:documentation>Used in Cache attribs</xsd:documentation>
                </xsd:annotation>
                <xsd:attribute name="maxstale" type="Integer.datatype"/>
        </xsd:attributeGroup>
        <xsd:attributeGroup name="Cache.attribs">
                <xsd:annotation>
                        <xsd:documentation>Cache attributes to control caching behavior</xsd:documentation>
                </xsd:annotation>
                <xsd:attributeGroup ref="Fetchtimeout.attrib"/>
                <xsd:attributeGroup ref="Maxage.attrib"/>
                <xsd:attributeGroup ref="Maxstale.attrib"/>
        </xsd:attributeGroup>
</xsd:schema>

scxml-contentmodels.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <xsd:annotation>
                <xsd:documentation>
             XML Schema content models for SCXML
             * scxml.extra.content 
             * content
             * scxml.extra.attribs
             Defines SCXML shared content models.
        </xsd:documentation>
                <xsd:documentation source="scxml-copyright.xsd"/>
        </xsd:annotation>
        <xsd:attributeGroup name="scxml.extra.attribs">
                <xsd:annotation>
                        <xsd:documentation>group allowing attributes from other namespaces</xsd:documentation>
                </xsd:annotation>
                <xsd:anyAttribute namespace="##other" processContents="lax"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.extra.content">
                <xsd:annotation>
                        <xsd:documentation>
                                group allowing elements from other namespaces
                        </xsd:documentation>
                </xsd:annotation>
                <xsd:sequence>
                        <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <!-- content -->
        <xsd:attributeGroup name="scxml.content.attlist">
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.content.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.content.type" mixed="true">
                <xsd:group ref="scxml.content.content"/>
                <xsd:attributeGroup ref="scxml.content.attlist"/>
        </xsd:complexType>
        <xsd:element name="content" type="scxml.content.type"/>
</xsd:schema>

D.2 Schema for Core Module

scxml-module-core.xsd

<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2008 sp1 (http://www.altova.com) by Alicia Fraumeni (Genesys Telecommunications Laboratories) -->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <xsd:annotation>
                <xsd:documentation>
            This is the XML Schema core module for SCXML
            * scxml
            * state 
            * initial 
            * onexit
            * onentry 
            * transition
            * parallel
            * final 
            * history 
            * if
            * elseif
            * else
            * raise 
            * log
            * donedata
            The core module defines these elements and the
            attributes.
        </xsd:documentation>
                <xsd:documentation source="scxml-copyright.xsd"/>
        </xsd:annotation>
        <xsd:include schemaLocation="scxml-datatypes.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                Includes common SCXML datatypes
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-attribs.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                Includes common SCXML attributes
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-contentmodels.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                This module defines Common content model extensions  for SCXML
            </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <!-- core executable content model -->
        <xsd:group name="scxml.core.executablecontent">
                <xsd:choice>
                        <xsd:group ref="scxml.extra.content"/>
                        <xsd:element ref="raise"/>
                        <xsd:element ref="if"/>
                        <xsd:element ref="log"/>
                </xsd:choice>
        </xsd:group>
        <!-- scxml -->
        <xsd:attributeGroup name="scxml.scxml.attlist">
                <xsd:attribute name="initial" type="xsd:IDREFS"/>
                <xsd:attribute name="name" type="xsd:NMTOKEN"/>
                <xsd:attribute name="version" type="xsd:decimal" use="required" fixed="1.0"/>
                <xsd:attribute name="profile" type="Profile.datatype"/>
                <xsd:attribute name="exmode" type="Exmode.datatype" default="lax"/>
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.scxml.mix">
                <xsd:choice>
                        <xsd:element ref="initial"/>
                        <xsd:element ref="state" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:element ref="parallel" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:element ref="final" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:choice>
        </xsd:group>
        <xsd:group name="scxml.scxml.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.scxml.mix" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.scxml.type">
                <xsd:group ref="scxml.scxml.content"/>
                <xsd:attributeGroup ref="scxml.scxml.attlist"/>
        </xsd:complexType>
        <xsd:element name="scxml" type="scxml.scxml.type"/>
        <!-- state -->
        <xsd:attributeGroup name="scxml.state.attlist">
                <xsd:attribute name="id" type="xsd:ID" use="required"/>
                <xsd:attribute name="src" type="URI.datatype"/>

                <xsd:attribute name="id" type="xsd:ID"/>

                <xsd:attribute name="initial" type="xsd:IDREFS"/>
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.state.mix">
                <xsd:choice>
                        <xsd:element ref="onentry" minOccurs="0" maxOccurs="1"/>
                        <xsd:element ref="onexit" minOccurs="0" maxOccurs="1"/>
                        <xsd:element ref="transition" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:element ref="initial" minOccurs="0" maxOccurs="1"/>
                        <xsd:element ref="state" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:element ref="parallel" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:element ref="final" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:element ref="history" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:choice>
        </xsd:group>
        <xsd:group name="scxml.state.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.state.mix" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.state.type">
                <xsd:sequence>
                        <xsd:group ref="scxml.state.content"/>
                </xsd:sequence>
                <xsd:attributeGroup ref="scxml.state.attlist"/>
        </xsd:complexType>
        <xsd:element name="state" type="scxml.state.type"/>
        <!-- initial -->
        <xsd:attributeGroup name="scxml.initial.attlist">
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.initial.mix">
                <xsd:choice>
                        <xsd:element ref="transition" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:choice>
        </xsd:group>
        <xsd:group name="scxml.initial.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.initial.mix" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.initial.type">
                <xsd:group ref="scxml.initial.content"/>
                <xsd:attributeGroup ref="scxml.initial.attlist"/>
        </xsd:complexType>
        <xsd:element name="initial" type="scxml.initial.type"/>
        <!-- onentry -->
        <xsd:attributeGroup name="scxml.onentry.attlist">
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.onentry.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.core.executablecontent" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.onentry.type">
                <xsd:group ref="scxml.onentry.content"/>
                <xsd:attributeGroup ref="scxml.onentry.attlist"/>
        </xsd:complexType>
        <xsd:element name="onentry" type="scxml.onentry.type"/>
        <!-- onexit -->
        <xsd:attributeGroup name="scxml.onexit.attlist">
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.onexit.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.core.executablecontent" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.onexit.type">
                <xsd:group ref="scxml.onexit.content"/>
                <xsd:attributeGroup ref="scxml.onexit.attlist"/>
        </xsd:complexType>
        <xsd:element name="onexit" type="scxml.onexit.type"/>
        <!-- transition -->
        <xsd:attributeGroup name="scxml.transition.attlist">
                <xsd:attribute name="event" type="EventType.datatype"/>
                <xsd:attribute name="cond" type="CondLang.datatype"/>
                <xsd:attribute name="target" type="xsd:IDREFS"/>
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.transition.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.core.executablecontent" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.transition.type">
                <xsd:group ref="scxml.transition.content"/>
                <xsd:attributeGroup ref="scxml.transition.attlist"/>
        </xsd:complexType>
        <xsd:element name="transition" type="scxml.transition.type"/>
        <!-- parallel -->
        <xsd:attributeGroup name="scxml.parallel.attlist">
                <xsd:attribute name="id" type="xsd:ID" use="required"/>
                <xsd:attribute name="src" type="URI.datatype"/>

                <xsd:attribute name="id" type="xsd:ID"/>

                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.parallel.mix">
                <xsd:choice>
                        <xsd:element ref="onentry" minOccurs="0" maxOccurs="1"/>
                        <xsd:element ref="onexit" minOccurs="0" maxOccurs="1"/>
                        <xsd:element ref="transition" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:element ref="state" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:element ref="parallel" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:element ref="history" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:choice>
        </xsd:group>
        <xsd:group name="scxml.parallel.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.parallel.mix" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.parallel.type">
                <xsd:group ref="scxml.parallel.content"/>
                <xsd:attributeGroup ref="scxml.parallel.attlist"/>
        </xsd:complexType>
        <xsd:element name="parallel" type="scxml.parallel.type"/>
        <!-- final -->
        <xsd:attributeGroup name="scxml.final.attlist">
                <xsd:attribute name="id" type="xsd:ID" use="required"/>

                <xsd:attribute name="id" type="xsd:ID"/>

                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.final.mix">
                <xsd:choice>
                        <xsd:element ref="onentry" minOccurs="0" maxOccurs="1"/>
                        <xsd:element ref="onexit" minOccurs="0" maxOccurs="1"/>
                        <xsd:element ref="donedata" minOccurs="0" maxOccurs="1"/>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:choice>
        </xsd:group>
        <xsd:group name="scxml.final.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.final.mix" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.final.type">
                <xsd:group ref="scxml.final.content"/>
                <xsd:attributeGroup ref="scxml.final.attlist"/>
        </xsd:complexType>
        <xsd:element name="final" type="scxml.final.type"/>
        <!-- history -->
        <xsd:attributeGroup name="scxml.history.attlist">
                <xsd:attribute name="id" type="xsd:ID" use="required"/>

                <xsd:attribute name="id" type="xsd:ID"/>

                <xsd:attribute name="type" type="HistoryType.datatype"/>
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.history.mix">
                <xsd:choice>
                        <xsd:element ref="transition" minOccurs="0" maxOccurs="1"/>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:choice>
        </xsd:group>
        <xsd:group name="scxml.history.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.history.mix" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.history.type">
                <xsd:group ref="scxml.history.content"/>
                <xsd:attributeGroup ref="scxml.history.attlist"/>
        </xsd:complexType>
        <xsd:element name="history" type="scxml.history.type"/>
        <!-- if -->
        <xsd:attributeGroup name="scxml.if.attlist">
                <xsd:attribute name="cond" type="CondLang.datatype" use="required"/>
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.if.mix">
                <xsd:choice>
                        <xsd:element ref="elseif" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:element ref="else" minOccurs="0" maxOccurs="1"/>
                        <xsd:group ref="scxml.core.executablecontent" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:choice>
        </xsd:group>
        <xsd:group name="scxml.if.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.if.mix" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.if.type">
                <xsd:group ref="scxml.if.content"/>
                <xsd:attributeGroup ref="scxml.if.attlist"/>
        </xsd:complexType>
        <xsd:element name="if" type="scxml.if.type"/>
        <!-- elseif -->
        <xsd:attributeGroup name="scxml.elseif.attlist">
                <xsd:attribute name="cond" type="CondLang.datatype" use="required"/>
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.elseif.mix">
                <xsd:choice>
                        <!-- No content for this element -->
                </xsd:choice>
        </xsd:group>
        <xsd:group name="scxml.elseif.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.elseif.mix" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.elseif.type">
                <xsd:group ref="scxml.elseif.content"/>
                <xsd:attributeGroup ref="scxml.elseif.attlist"/>
        </xsd:complexType>
        <xsd:element name="elseif" type="scxml.elseif.type"/>
        <!-- else -->
        <xsd:attributeGroup name="scxml.else.attlist">
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.else.mix">
                <xsd:choice>
                        <!-- No content for this element -->
                </xsd:choice>
        </xsd:group>
        <xsd:group name="scxml.else.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.else.mix" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.else.type">
                <xsd:group ref="scxml.else.content"/>
                <xsd:attributeGroup ref="scxml.else.attlist"/>
        </xsd:complexType>
        <xsd:element name="else" type="scxml.else.type"/>
        <!-- raise -->
        <xsd:attributeGroup name="scxml.raise.attlist">
                <xsd:attribute name="event" type="xsd:NMTOKEN" use="required"/>
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.raise.mix">
                <xsd:choice>
                        <xsd:element ref="content" minOccurs="0" maxOccurs="1"/>
                </xsd:choice>
        </xsd:group>
        <xsd:group name="scxml.raise.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.raise.mix" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.raise.type">
                <xsd:group ref="scxml.raise.content"/>
                <xsd:attributeGroup ref="scxml.raise.attlist"/>
        </xsd:complexType>
        <xsd:element name="raise" type="scxml.raise.type"/>
        <!-- log -->
        <xsd:attributeGroup name="scxml.log.attlist">
                <xsd:attribute name="label" type="xsd:string"/>
                <xsd:attribute name="expr" type="ValueLang.datatype" use="required"/>
                <xsd:attribute name="level" type="xsd:positiveInteger" default="1"/>
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.log.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.log.type">
                <xsd:group ref="scxml.log.content"/>
                <xsd:attributeGroup ref="scxml.log.attlist"/>
        </xsd:complexType>
        <xsd:element name="log" type="scxml.log.type"/>
        <!-- donedata -->
        <xsd:attributeGroup name="scxml.donedata.attlist">
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.donedata.mix">
                <xsd:choice>
                        <xsd:element ref="content" minOccurs="0" maxOccurs="1"/>
                </xsd:choice>
        </xsd:group>
        <xsd:group name="scxml.donedata.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.donedata.mix" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.donedata.type">
                <xsd:group ref="scxml.donedata.content"/>
                <xsd:attributeGroup ref="scxml.donedata.attlist"/>
        </xsd:complexType>
        <xsd:element name="donedata" type="scxml.donedata.type"/>
</xsd:schema>
      

D.3 Schema for External Module

scxml-module-external.xsd

<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2008 sp1 (http://www.altova.com) by Alicia Fraumeni (Genesys Telecommunications Laboratories) -->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <xsd:annotation>
                <xsd:documentation>
            This is the XML Schema external module for SCXML
            * send 
            * cancel
            * invoke
            * finalize 
            The external module defines these elements and their
            attributes.
        </xsd:documentation>
                <xsd:documentation source="scxml-copyright.xsd"/>
        </xsd:annotation>
        <xsd:include schemaLocation="scxml-datatypes.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This module defines SCXML Attribute DataTypes
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-attribs.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This module defines Common attributes for SCXML
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-contentmodels.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This module defines Common content model extensions  for SCXML
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <!-- send -->
        <xsd:attributeGroup name="scxml.send.attlist">
                <xsd:attribute name="event" type="ValueLang.datatype"/>
                <xsd:attribute name="target" type="ValueLang.datatype"/>
                <xsd:attribute name="type" type="ValueLang.datatype" default="'scxml'"/>

                <xsd:attribute name="event" type="xsd:string"/>
                <xsd:attribute name="eventexpr" type="ValueLang.datatype"/>
                <xsd:attribute name="target" type="xsd:string"/>
                <xsd:attribute name="targetexpr" type="ValueLang.datatype"/>
                <xsd:attribute name="type" type="xsd:string" default="scxml"/>
                <xsd:attribute name="typeexpr" type="ValueLang.datatype"/>

                <xsd:attribute name="id" type="xsd:NMTOKEN"/>
                <xsd:attribute name="idlocation" type="LocLang.datatype"/>
                <xsd:attribute name="delay" type="ValueLang.datatype" default="'0s'"/>
                <xsd:attribute name="timeout" type="ValueLang.datatype" default="'0s'"/>

                <xsd:attribute name="delay" type="xsd:string" default="0s"/>
                <xsd:attribute name="delayexpr" type="ValueLang.datatype"/>

                <xsd:attribute name="namelist" type="xsd:string"/>
                <xsd:attribute name="hints" type="ValueLang.datatype"/>

                <xsd:attribute name="hints" type="xsd:string"/>
                <xsd:attribute name="hintsexpr" type="ValueLang.datatype"/>

                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.send.mix">
                <xsd:choice>
                        <xsd:element ref="content" minOccurs="0" maxOccurs="1"/>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:choice>
        </xsd:group>
        <xsd:group name="scxml.send.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.send.mix" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.send.type">
                <xsd:group ref="scxml.send.content"/>
                <xsd:attributeGroup ref="scxml.send.attlist"/>
        </xsd:complexType>
        <xsd:element name="send" type="scxml.send.type"/>
        <!-- invoke -->
        <xsd:attributeGroup name="scxml.invoke.attlist">
                <xsd:attribute name="src" type="ValueLang.datatype"/>
                <xsd:attribute name="type" type="xsd:NMTOKEN" use="required"/>

                <xsd:attribute name="type" type="xsd:NMTOKEN" default="scxml"/>
                <xsd:attribute name="typeexpr" type="ValueLang.datatype"/>
                <xsd:attribute name="src" type="URI.datatype"/>
                <xsd:attribute name="srcexpr" type="ValueLang.datatype"/>

                <xsd:attribute name="id" type="xsd:NMTOKEN"/>
                <xsd:attribute name="idlocation" type="LocLang.datatype"/>
                <xsd:attribute name="namelist" type="xsd:string"/>

                <xsd:attribute name="autoforward" type="Boolean.datatype" use="optional" default="false"/>
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.invoke.mix">
                <xsd:choice>
                        <xsd:element ref="finalize" minOccurs="0" maxOccurs="1"/>
                        <xsd:element ref="content" minOccurs="0" maxOccurs="1"/>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:choice>
        </xsd:group>
        <xsd:group name="scxml.invoke.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.invoke.mix" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.invoke.type">
                <xsd:group ref="scxml.invoke.content"/>
                <xsd:attributeGroup ref="scxml.invoke.attlist"/>
        </xsd:complexType>
        <xsd:element name="invoke" type="scxml.invoke.type"/>
        <!-- finalize -->
        <xsd:attributeGroup name="scxml.finalize.attlist">
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.finalize.mix">
                <xsd:choice>
                        <!-- MUST be redefined in the profile in order to define the appropriate executable content and datamodel. -->
                </xsd:choice>
        </xsd:group>
        <xsd:group name="scxml.finalize.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.finalize.mix" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.finalize.type">
                <xsd:group ref="scxml.finalize.content"/>
                <xsd:attributeGroup ref="scxml.finalize.attlist"/>
        </xsd:complexType>
        <xsd:element name="finalize" type="scxml.finalize.type"/>
        <!-- cancel -->
        <xsd:attributeGroup name="scxml.cancel.attlist">
                <xsd:attribute name="id" type="ValueLang.datatype" use="required"/>

                <xsd:attribute name="sendid" type="xsd:NMTOKEN"/>
                <xsd:attribute name="sendidexpr" type="ValueLang.datatype"/>

                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.cancel.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.cancel.type">
                <xsd:group ref="scxml.cancel.content"/>
                <xsd:attributeGroup ref="scxml.cancel.attlist"/>
        </xsd:complexType>
        <xsd:element name="cancel" type="scxml.cancel.type"/>
</xsd:schema>
      

D.4 Schema for Data Module

scxml-module-data.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <xsd:annotation>
                <xsd:documentation>
            This is the XML Schema data module for SCXML
            * datamodel 
            * data
            * assign
            * validate
            * param
            The anchor module defines these elements and their
            attributes.
        </xsd:documentation>
                <xsd:documentation source="scxml-copyright.xsd"/>
        </xsd:annotation>
        <xsd:include schemaLocation="scxml-datatypes.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                This module defines SCXML Attribute DataTypes
            </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-attribs.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                This module defines Common attributes for SCXML
            </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-contentmodels.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                This module defines Common content model extensions  for SCXML
            </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <!-- datamodel -->
        <xsd:attributeGroup name="scxml.datamodel.attlist">
                <xsd:attribute name="schema" type="URI.datatype"/>
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.datamodel.content">
                <xsd:sequence>
                        <xsd:element ref="data" minOccurs="0" maxOccurs="unbounded"/>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.datamodel.type">
                <xsd:group ref="scxml.datamodel.content"/>
                <xsd:attributeGroup ref="scxml.datamodel.attlist"/>
        </xsd:complexType>
        <xsd:element name="datamodel" type="scxml.datamodel.type"/>
        <!-- data -->
        <xsd:attributeGroup name="scxml.data.attlist">
                <xsd:attribute name="id" type="xsd:ID" use="required"/>
                <xsd:attribute name="src" type="URI.datatype"/>
                <xsd:attribute name="expr" type="ValueLang.datatype"/>
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.data.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.data.type" mixed="true">
                <xsd:group ref="scxml.data.content"/>
                <xsd:attributeGroup ref="scxml.data.attlist"/>
        </xsd:complexType>
        <xsd:element name="data" type="scxml.data.type"/>
        <!--  assign  -->
        <xsd:attributeGroup name="scxml.assign.attlist">
                <xsd:attribute name="location" type="LocLang.datatype" use="required"/>
                <xsd:attribute name="dataid" type="xsd:IDREF"/>
                <xsd:attribute name="expr" type="ValueLang.datatype"/>
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.assign.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.assign.type" mixed="true">
                <xsd:group ref="scxml.assign.content"/>
                <xsd:attributeGroup ref="scxml.assign.attlist"/>
        </xsd:complexType>
        <xsd:element name="assign" type="scxml.assign.type"/>
        <!--  validate  -->
        <xsd:attributeGroup name="scxml.validate.attlist">
                <xsd:attribute name="location" type="LocLang.datatype"/>
                <xsd:attribute name="schema" type="URI.datatype"/>
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.validate.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.validate.type">
                <xsd:group ref="scxml.validate.content"/>
                <xsd:attributeGroup ref="scxml.validate.attlist"/>
        </xsd:complexType>
        <xsd:element name="validate" type="scxml.validate.type"/>
        <!-- param -->
        <xsd:attributeGroup name="scxml.param.attlist">
                <xsd:attribute name="name" type="xsd:NMTOKEN" use="required"/>
                <xsd:attribute name="expr" type="ValueLang.datatype"/>
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.param.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.param.type">
                <xsd:group ref="scxml.param.content"/>
                <xsd:attributeGroup ref="scxml.param.attlist"/>
        </xsd:complexType>
        <xsd:element name="param" type="scxml.param.type"/>
</xsd:schema>
      

D.5 Schema for Script Module

scxml-module-script.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <xsd:annotation>
                <xsd:documentation>
            This is the XML Schema script module for SCXML
            * script
            The script module defines these elements and their
            attributes.
                </xsd:documentation>
                <xsd:documentation source="scxml-copyright.xsd"/>
        </xsd:annotation>
        <xsd:include schemaLocation="scxml-datatypes.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                Includes common SCXML datatypes
            </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-attribs.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                Includes common SCXML attributes
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-contentmodels.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This module defines Common content model extensions  for SCXML
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:attributeGroup name="scxml.script.attlist">
                <!-- Commented out until added to the actual draft.
                <xsd:attribute name="src" type="URI.datatype"/>
                <xsd:attribute name="srcexpr" type="ValueLang.datatype"/>
                <xsd:attribute name="charset" type="xsd:string"/>
                <xsd:attributeGroup ref="Cache.attribs"/>
                 -->
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.script.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.script.type" mixed="true">
                <xsd:group ref="scxml.script.content"/>
                <xsd:attributeGroup ref="scxml.script.attlist"/>
        </xsd:complexType>
        <xsd:element name="script" type="scxml.script.type"/>
</xsd:schema>
      

D.6 Anchor Module Schema

scxml-module-anchor.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <xsd:annotation>
                <xsd:documentation>
                        This is the XML Schema anchor module for SCXML
                        * anchor
                        The anchor module defines these elements and their
                        attributes.
                </xsd:documentation>
                <xsd:documentation source="scxml-copyright.xsd"/>
        </xsd:annotation>
        
        <xsd:include schemaLocation="scxml-datatypes.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This module defines SCXML Attribute DataTypes
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-attribs.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This module defines Common attributes for SCXML
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-contentmodels.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                This module defines Common content model extensions  for SCXML
            </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <!-- -->
        <!-- anchor -->
        <xsd:attributeGroup name="scxml.anchor.attlist">
                <xsd:attribute name="type" type="xsd:NMTOKEN" use="required"/>
                <xsd:attribute name="snapshot" type="LocLang.datatype"/>
                <xsd:attributeGroup ref="scxml.extra.attribs"/>
        </xsd:attributeGroup>
        <xsd:group name="scxml.anchor.content">
                <xsd:sequence>
                        <xsd:group ref="scxml.extra.content" minOccurs="0" maxOccurs="unbounded"/>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxml.anchor.type">
                <xsd:group ref="scxml.anchor.content"/>
                <xsd:attributeGroup ref="scxml.anchor.attlist"/>
        </xsd:complexType>
        <xsd:element name="anchor" type="scxml.anchor.type"/>
        <!-- Added this in because it should be defined here and used in the profiles. -->
        <xsd:simpleType name="Anchor.datatype">
                <xsd:annotation>
                        <xsd:documentation>
                                This defines the Anchor data type to be used for the transition element. 
            </xsd:documentation>
                </xsd:annotation>
                <xsd:restriction base="xsd:NMTOKEN"/>
        </xsd:simpleType>
</xsd:schema>
      

D.7 Minimal Profile Schema

scxml-profile-minimum.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2005/07/scxml" targetNamespace="http://www.w3.org/2005/07/scxml" blockDefault="#all">
        <xsd:annotation>
                <xsd:documentation>
      This is the XML Schema driver for SCXML 1.0, minimum profile.
      Please use this namespace for SCXML 1.0 elements:
        "http://www.w3.org/2005/07/scxml"
                </xsd:documentation>
                <xsd:documentation source="scxml-copyright.xsd"/>
        </xsd:annotation>
        <xsd:annotation>
                <xsd:documentation>
      This is the Schema Driver file for SCXML 1.0, minimum profile
     This schema
        + sets the namespace for SCXML 1.0 minimum profile 
        + imports external schemas (xml.xsd)
        + imports SCXML common datatypes, attributes and common models
        + imports schema modules 
          SCXML 1.0 includes the following Modules
           
           * SCXML core module 
                  </xsd:documentation>
        </xsd:annotation>
        <xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This import brings in the XML namespace attributes
                                The XML attributes are used by various modules.
                   </xsd:documentation>
                </xsd:annotation>
        </xsd:import>
        <xsd:include schemaLocation="scxml-datatypes.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This imports brings in the common datatypes for SCXML
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-attribs.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This imports brings in the common attributes for SCXML.
                    </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-contentmodels.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This imports the common content models. 
            </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-module-core.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                This imports the core module for SCXML
            </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
</xsd:schema>
      

D.8 ECMAScript Profile Schema

scxml-profile-ecma.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:scxml="http://www.w3.org/2005/07/scxml" xmlns="http://www.w3.org/2005/07/scxml" targetNamespace="http://www.w3.org/2005/07/scxml" blockDefault="#all">
        <xsd:annotation>
                <xsd:documentation>
                          This is the XML Schema driver for SCXML 1.0, ecma profile.

                          This is the XML Schema driver for SCXML 1.0, ecmascript profile.

                          Please use this namespace for SCXML 1.0 elements:
                        "http://www.w3.org/2005/07/scxml"
                </xsd:documentation>
                <xsd:documentation source="scxml-copyright.xsd"/>
        </xsd:annotation>
        <xsd:annotation>
                <xsd:documentation>
                        This schema
                                + sets the namespace for SCXML 1.0 basic ecma profile 

                                + sets the namespace for SCXML 1.0 basic ecmascript profile 

                                + imports external schemas (xml.xsd)
                                + includes SCXML common datatypes, attributes and content models
                                + includes schema modules 
                        SCXML 1.0 includes the following Modules
                           SCXML core module 
                           SCXML data module
                           SCXML script module
                           SCXML external module 
                </xsd:documentation>
        </xsd:annotation>
        <xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This import brings in the XML namespace attributes
                                The XML attributes are used by various modules.
            </xsd:documentation>
                </xsd:annotation>
        </xsd:import>
        <xsd:include schemaLocation="scxml-datatypes.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This includes brings in the common data types for SCXML
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-attribs.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This includes brings in the common attributes for SCXML
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-module-data.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This includes the data module for SCXML
                    </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-module-script.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This includes the script module for SCXML
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:redefine schemaLocation="scxml-module-external.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This imports the external module for SCXML and redefines the following.
                                        [1] Redefines send and invoke mix group to allow 
                                                param
                                        [2] Redefines finalize mix group to allow: 
                                                executable content 
                            </xsd:documentation>
                </xsd:annotation>
                <xsd:group name="scxml.send.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.send.mix"/>
                                <xsd:element ref="param" minOccurs="0" maxOccurs="unbounded"/>
                        </xsd:choice>
                </xsd:group>
                <xsd:group name="scxml.invoke.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.invoke.mix"/>
                                <xsd:element ref="param" minOccurs="0" maxOccurs="unbounded"/>
                        </xsd:choice>
                </xsd:group>
                <xsd:group name="scxml.finalize.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.finalize.mix"/>
                                <xsd:group ref="scxml.core.executablecontent"/>
                        </xsd:choice>
                </xsd:group>
        </xsd:redefine>
        <xsd:include schemaLocation="scxml-contentmodels.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This includes the common content models. 
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:redefine schemaLocation="scxml-module-core.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This imports the core module for SCXML and redefines the following.
                                        [1] Redefines executable content to allow 
                                                send, assign, validate, cancel and script elements
                                        [2] Redefines state and parallel mix group to allow 
                                                invoke
                                                datamodel
                                        [3] Redefines scxml group to allow 
                                                datamodel
                                                script
                            </xsd:documentation>
                </xsd:annotation>
                <xsd:group name="scxml.core.executablecontent">
                        <xsd:choice>
                                <xsd:group ref="scxml.core.executablecontent"/>
                                <xsd:element ref="send"/>
                                <xsd:element ref="assign"/>
                                <xsd:element ref="script"/>
                                <xsd:element ref="validate"/>
                                <xsd:element ref="cancel"/>
                        </xsd:choice>
                </xsd:group>
                <xsd:group name="scxml.state.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.state.mix"/>
                                <xsd:element ref="invoke" minOccurs="0"/>
                                <xsd:element ref="datamodel" minOccurs="0"/>
                        </xsd:choice>
                </xsd:group>
                <xsd:group name="scxml.scxml.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.scxml.mix"/>
                                <xsd:element ref="datamodel" minOccurs="0"/>
                                <xsd:element ref="script" minOccurs="0" maxOccurs="unbounded"/>
                        </xsd:choice>
                </xsd:group>
                <xsd:group name="scxml.parallel.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.parallel.mix"/>
                                <xsd:element ref="datamodel" minOccurs="0"/>
                        </xsd:choice>
                </xsd:group>
                <xsd:group name="scxml.donedata.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.donedata.mix"/>
                                <xsd:element ref="param" minOccurs="0" maxOccurs="unbounded"/>
                        </xsd:choice>
                </xsd:group>
                <xsd:group name="scxml.raise.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.raise.mix"/>
                                <xsd:element ref="param" minOccurs="0" maxOccurs="unbounded"/>
                        </xsd:choice>
                </xsd:group>
        </xsd:redefine>
</xsd:schema>
      

D.9 XPath Profile Schema

scxml-profile-xpath.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2005/07/scxml" xmlns:scxml="http://www.w3.org/2005/07/scxml" targetNamespace="http://www.w3.org/2005/07/scxml" blockDefault="#all">
        <xsd:annotation>
                <xsd:documentation>
            This is the XML Schema driver for SCXML 1.0, xpath profile.
                        Please use this namespace for SCXML 1.0 elements:
                        "http://www.w3.org/2005/07/scxml"
                </xsd:documentation>
                <xsd:documentation source="scxml-copyright.xsd"/>
        </xsd:annotation>
        <xsd:annotation>
                <xsd:documentation>
                        This is the Schema Driver file for SCXML 1.0, xpath profile
                        This schema
                                + sets the namespace for SCXML 1.0 basic profile 
                                + imports external schemas (xml.xsd)
                                + imports SCXML common datatypes, attributes and content models
                                + imports schema modules 
            SCXML 1.0 includes the following Modules
                SCXML core module 
                SCXML data module
                SCXML external module 
                </xsd:documentation>
        </xsd:annotation>
        <xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This import brings in the XML namespace attributes
                                The XML attributes are used by various modules.
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:import>
        <xsd:include schemaLocation="scxml-datatypes.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This includes brings in the common data types for SCXML
                    </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-attribs.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This includes brings in the common attributes for SCXML.
                        </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:include schemaLocation="scxml-module-data.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This includes the data module for SCXML
                    </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:redefine schemaLocation="scxml-module-external.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This imports the external module for SCXML and redefines the following.
                                        [1] Redefines send and invoke mix group to allow 
                                                param
                                        [2] Redefines finalize mix group to allow: 
                                                executable content 
                            </xsd:documentation>
                </xsd:annotation>
                <xsd:group name="scxml.send.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.send.mix"/>
                                <xsd:element ref="param" minOccurs="0" maxOccurs="unbounded"/>
                        </xsd:choice>
                </xsd:group>
                <xsd:group name="scxml.invoke.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.invoke.mix"/>
                                <xsd:element ref="param" minOccurs="0" maxOccurs="unbounded"/>
                        </xsd:choice>
                </xsd:group>
                <xsd:group name="scxml.finalize.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.finalize.mix"/>
                                <xsd:group ref="scxml.core.executablecontent"/>
                        </xsd:choice>
                </xsd:group>
        </xsd:redefine>
        <xsd:include schemaLocation="scxml-contentmodels.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This includes the common content models. 
                    </xsd:documentation>
                </xsd:annotation>
        </xsd:include>
        <xsd:redefine schemaLocation="scxml-module-core.xsd">
                <xsd:annotation>
                        <xsd:documentation>
                                This imports the core module for SCXML and redefines the following.
                                        [1] Redefines executable content to allow 
                                                send, assign, validate, and cancel elements
                                        [2] Redefines state and parallel mix group to allow 
                                                invoke
                                                datamodel
                                        [3] Redefines scxml group to allow 
                                                datamodel
                            </xsd:documentation>
                </xsd:annotation>
                <xsd:group name="scxml.core.executablecontent">
                        <xsd:choice>
                                <xsd:group ref="scxml.core.executablecontent"/>
                                <xsd:element ref="send"/>
                                <xsd:element ref="assign"/>
                                <xsd:element ref="validate"/>
                                <xsd:element ref="cancel"/>
                        </xsd:choice>
                </xsd:group>
                <xsd:group name="scxml.state.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.state.mix"/>
                                <xsd:element ref="invoke" minOccurs="0"/>
                                <xsd:element ref="datamodel" minOccurs="0"/>
                        </xsd:choice>
                </xsd:group>
                <xsd:group name="scxml.scxml.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.scxml.mix"/>
                                <xsd:element ref="datamodel" minOccurs="0"/>
                        </xsd:choice>
                </xsd:group>
                <xsd:group name="scxml.parallel.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.parallel.mix"/>
                                <xsd:element ref="datamodel" minOccurs="0"/>
                        </xsd:choice>
                </xsd:group>
                <xsd:group name="scxml.donedata.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.donedata.mix"/>
                                <xsd:element ref="param" minOccurs="0" maxOccurs="unbounded"/>
                        </xsd:choice>
                </xsd:group>
                <xsd:group name="scxml.raise.mix">
                        <xsd:choice>
                                <xsd:group ref="scxml.raise.mix"/>
                                <xsd:element ref="param" minOccurs="0" maxOccurs="unbounded"/>
                        </xsd:choice>
                </xsd:group>
        </xsd:redefine>
</xsd:schema>
      

D.10 SCXML Message Schema

scxml-message.xsd

<?xml version="1.0" encoding="UTF-8"?>
<!--
    XML Schema for sending messages to SCXML processors.
-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:scxml="http://www.w3.org/2005/07/scxml"
    targetNamespace="http://www.w3.org/2005/07/scxml"
        elementFormDefault="qualified">
        <xsd:annotation>
                <xsd:documentation xml:lang="en">
                        XML Schema for sending messages to SCXML processors.
                        Version 1.0
                </xsd:documentation>
                <xsd:documentation source="scxml-copyright.xsd" />
        </xsd:annotation>
        <xsd:attributeGroup name="scxmlmessage.extra.attribs">
                <xsd:annotation>
                        <xsd:documentation>
                                Group allowing attributes from other namespaces
                        </xsd:documentation>
                </xsd:annotation>
                <xsd:anyAttribute namespace="##other" processContents="lax" />
        </xsd:attributeGroup>
        <xsd:attributeGroup name="scxmlmessage.message.attlist">
                <xsd:attribute name="version" type="xsd:string" fixed="1.0" use="required" />
                <xsd:attribute name="source" type="xsd:anyURI" use="required" />
                <xsd:attribute name="target" type="xsd:anyURI" use="required" />
                <xsd:attribute name="sendid" type="xsd:string" use="optional">
                        <xsd:annotation>
                                <xsd:documentation>
                                        Non SCXML senders are not required to specify a sendid
                                </xsd:documentation>
                        </xsd:annotation>
                </xsd:attribute>
                <xsd:attribute name="name" type="xsd:string" use="optional">
                        <xsd:annotation>
                                <xsd:documentation>
                                        Defaults to "external.event"
                                </xsd:documentation>
                        </xsd:annotation>
                </xsd:attribute>
                <xsd:attribute name="sourcetype" type="xsd:string" use="optional">
                        <xsd:annotation>
                                <xsd:documentation>
                                        Defaults to "scxml"
                                </xsd:documentation>
                        </xsd:annotation>
                </xsd:attribute>
                <xsd:attribute name="type" type="xsd:string" use="optional">
                        <xsd:annotation>
                                <xsd:documentation>
                                        Defaults to "scxml"
                                </xsd:documentation>
                        </xsd:annotation>
                </xsd:attribute>
                <xsd:attribute name="language" type="xsd:string" use="optional">
                        <xsd:annotation>
                                <xsd:documentation>
                                        Defaults to "xml"
                                </xsd:documentation>
                        </xsd:annotation>
                </xsd:attribute>
                <xsd:attributeGroup ref="scxml:scxmlmessage.extra.attribs" />
        </xsd:attributeGroup>
        <xsd:group name="scxmlmessage.message.content">
                <xsd:sequence>
                        <xsd:element ref="scxml:payload" minOccurs="1" maxOccurs="1" />
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxmlmessage.message.type">
                <xsd:group ref="scxml:scxmlmessage.message.content" />
                <xsd:attributeGroup ref="scxml:scxmlmessage.message.attlist" />
        </xsd:complexType>
        <xsd:element name="message" type="scxml:scxmlmessage.message.type" />
        <xsd:attributeGroup name="scxmlmessage.payload.attlist">
                <xsd:attributeGroup ref="scxml:scxmlmessage.extra.attribs" />
        </xsd:attributeGroup>
        <xsd:group name="scxmlmessage.payload.content">
                <xsd:sequence>
                        <xsd:element ref="scxml:hint" minOccurs="0"
                                maxOccurs="1" />
                        <xsd:choice>
                                <xsd:sequence>
                                        <xsd:element ref="scxml:property" minOccurs="0"
                                                maxOccurs="unbounded" />
                                </xsd:sequence>
                                <xsd:sequence>
                                        <xsd:any namespace="##other" minOccurs="1"
                                                maxOccurs="unbounded" processContents="lax" />
                                </xsd:sequence>
                        </xsd:choice>
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxmlmessage.payload.type">
                <xsd:group ref="scxml:scxmlmessage.payload.content" />
                <xsd:attributeGroup ref="scxml:scxmlmessage.payload.attlist" />
        </xsd:complexType>
        <xsd:element name="payload" type="scxml:scxmlmessage.payload.type" />
        <xsd:attributeGroup name="scxmlmessage.property.attlist">
                <xsd:attribute name="name" type="xsd:string" use="required" />
                <xsd:attributeGroup ref="scxml:scxmlmessage.extra.attribs" />
        </xsd:attributeGroup>
        <xsd:group name="scxmlmessage.property.content">
                <xsd:sequence>
                        <xsd:element ref="scxml:hint" minOccurs="0"
                                maxOccurs="1" />
                        <xsd:any namespace="##other" minOccurs="0"
                                maxOccurs="unbounded" processContents="skip" />
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxmlmessage.property.type" mixed="true">
                <xsd:group ref="scxml:scxmlmessage.property.content" />
                <xsd:attributeGroup ref="scxml:scxmlmessage.property.attlist" />
        </xsd:complexType>
        <xsd:element name="property" type="scxml:scxmlmessage.property.type" />
        <xsd:element name="hint" type="xsd:string" />
</xsd:schema>

E Examples

E.1 Language Overview

This SCXML document gives an overview of the SCXML language and shows the use of its state machine transition flows:

Example: Main.scxml
<?xml version="1.0" encoding="us-ascii"?>
<!-- A wrapper state that contains all other states in this file
- it represents the complete state machine --> <scxml xmlns="http://www.w3.org/2005/07/scxml"
       version="1.0"
       initial="Main"
       profile="ecmascript">
  <state id="Main">
    <!-- its initial state is Test1 -->
    <initial>
      <transition target="Test1"/>
    </initial>
    <!-- Really simple state showing the basic syntax. -->
    <state id="Test1">
      <initial>
        <transition target="Test1Sub1"/>
      </initial>
      <!-- Runs before we go into the substate -->
      <onentry> 
        <log expr="'Inside Test1'"/>
      </onentry>
      <!-- Here is our first substate -->
      <state id="Test1Sub1">
        <onentry>
          <log expr="'Inside Test1Sub1.'"/>
        </onentry>
        <onexit>
          <log expr="'Leaving Test1Sub1'"/>
        </onexit>
        <!-- Go to Sub2 on Event1 -->
        <transition event="Event1" target="Test1Sub2"/>
      </state>
      <!-- Here is the second substate 
           It is final, so Test1 is done when we get here -->
      <final id="Test1Sub2"/>
      <!-- We get this event when we reach Test1Sub2. -->
      <transition event="Test1.done" target="Test2"/>
      <!-- We run this on the way out of Test1 -->
      <onexit>
        <log expr="'Leaving Test1...'"/>
      </onexit>
    </state>
    <state id="Test2">
      <initial>
        <transition target="Test2Sub1"/>
      </initial>
      <!-- This time we reference a state 
           defined in an external file.  Note that we could have
           loaded the entire file by leaving off the #Test2Sub1,
           but in that case we would need to rename one of the
           Test2Sub1 states (here or in the external file) to
           avoid the name collision -->
      <state id="Test2Sub1" src="External.scxml#Test2Sub1"/>
  
      <final id="Test2Sub2"/>
      <!-- Test2Sub2 is defined as final, so this
           event is generated when we reach it -->
      <transition event="Test2.done" next="Test3"/>
    </state>
    <state id="Test3">
      <initial>
        <transition target="Test3Sub1"/>
      </initial>
      <state id="Test3Sub1">
        <onentry>
          <log expr="'Inside Test3Sub1...'"/>
          <!-- Send our self an event in 5s -->
          <send event="'Timer'"  delay="'5s'"/>
        </onentry>
        <!-- Transition on to Test4.
             This will exit both us and our parent. -->
        <transition event="Timer" target="Test4"/>
        <onexit>
          <log expr="'Leaving Test3Sub1...'"/>
        </onexit>
      </state>
      <onexit>
        <log expr="'Leaving Test3...'"/>
      </onexit>
    </state>
    
    <state id="Test4">
      <onentry>
        <log expr="'Inside Test4...'"/>
      </onentry>
      <initial>
        <transition target="Test4Sub1"/>
      </initial>
      <state id="Test4Sub1">
        <onexit>
          <log expr="'Leaving Test4Sub1...'"/>
        </onexit>
        <!-- This transition causes the state to exit immediately
             after entering Test4Sub1.  The transition has no event
             or guard so it is always active -->
        <transition target="Test5"/>
      </state>
    </state>
       
    <state id="Test5">
      <onentry>
        <log expr="'Inside Test5...'"/>
      </onentry>
      <initial>
        <transition target="Test5P"/>
      </initial>
      <!-- Fire off our parallel states -->
      <parallel id="Test5P">
        <final id="Test5PSub1"/>
        <final id="Test5PSub2"/>
        <onexit>
          <log expr="'all parallel states done'"/>
        </onexit>
      </parallel>
      <!-- The parallel states are all final, so this
           event is generated immediately.  Although not shown,
           compound states (i.e., <state>s with content)
           are permitted within <parallel> as well. -->
      <transition event="Test5P.done" target="Test6"/>
    </state>
    <!-- 
         - This state shows invocation of an external component.
         - We will use CCXML + VoiceXML actions as an example 
         - as it is a good smoke test to show how it all 
         - fits together. 
         - Note: In a real app you would likely 
         - split this over several states but we 
         - are trying to keep it simple here. 
    -->
    <state id="Test6"
           xmlns:ccxml="http://www.w3.org/2002/09/ccxml"
           xmlns:v3="http://www.w3.org/2005/07/vxml3">
      <datamodel>
        <data name="ccxmlid" expr="32459"/>
        <date name="v3id" expr="17620"/>
        <data name="dest" expr="'tel:+18315552020'"/>
        <data name="src" expr="'helloworld2.vxml'"/>
        <data name="id" expr="'HelloWorld'"/>
      </datamodel>
      <onentry>
        <!-- Use <send> to run a createcall using the 
             CCXML component / Event I/O Processor -->
        <send target="ccxmlid" type="'ccxml'" event="'ccxml:createcall'" namelist="dest"/>
      </onentry>
      <transition event="ccxml:connection.connected">      
        <!-- Here as a platform-specific extension we use example V3 
             Custom Action Elements instead of send. -->
        <v3:form id="HelloWorld">
          <v3:block><v3:prompt>Hello World!</v3:prompt></v3:block>          
        </v3:form>
      </transition>
      <transition event="v3:HelloWorld.done">
        <!-- Here we are using the low level <send> 
             element to run a v3 form. Note that the event "v3:HelloWorld.done" 
             is assumed either to be set/sent explicitly by the v3:form code or 
             implicitly by some process outside of the v3:form -->
        <send target="v3id" type="'v3'" event="'v3:formstart'" namelist="src id"/>
      </transition>
      <transition event="v3:HelloWorld2.done">
        <!-- we use _eventdata to access data in the event we're processing.

        <!-- we use _event.data to access data in the event we're processing.

             Again we assume the v3:HelloWorld2.done is set/sent from outside
             this document -->
        <ccxml:disconnect connectionid="_eventdata.connectionid"/>      

        <ccxml:disconnect connectionid="_event.data.connectionid"/>      

      </transition>
      <transition event="ccxml:connection.disconnected" target="Done"/>
  
      <!-- Now some transitions to handle events generated by the component -->
      <transition event="send.successful">
        <!-- Component invoked successfully. This transition has no target 
             so Test6 is not exited.
             We are just going to log that we were able to send an event. -->
        <log expr="'Event was able to be sent'"/>
      </transition>
      <transition event="error.send" target="Done">
        <!-- If we get an error event we move to the Done state that 
             is a final state. -->
        <log expr="'Sending to and External component failed'"/>
      </transition>
      <onexit>
        <log expr="'Finished with external component'"/>
      </onexit>
    </state>
    <!-- This final state is an immediate child of Main
         -  when we get here, Main.done is generated. -->
    <final id="Done"/>
    <!-- End of Main > -->
  </state>
</scxml>
Example: Test2Sub1.scxml
<?xml version="1.0" encoding="us-ascii"?>
<scxml version="1.0" xmlns="http://www.w3.org/2005/07/scxml" initial="Test2Sub1"> 
  <!-- 
  - This is an example substate defined in
  - an external file referenced by Main.scxml.
  -->
  <state id="Test2Sub1">
    <onentry>
      <log expr="'Inside Test2Sub1'"/>
    </onentry>
    <transition event="Event2" target="Test2Sub2"/>
  </state>
</scxml>

E.2 Microwave Example

The example below shows the implementation of a simple microwave oven using SCXML.

Example: microwave-01.scxml

<?xml version="1.0"?>
<scxml xmlns="http://www.w3.org/2005/07/scxml"
       version="1.0"
       profile="ecmascript"
       initial="off">
  <!--  trivial 5 second microwave oven example -->
  <datamodel>
    <data id="cook_time" expr="5"/>
    <data id="door_closed" expr="true"/>
    <data id="timer" expr="0"/>
  </datamodel>
  <state id="off">
    <!-- off state -->
    <transition event="turn.on" target="on"/>
  </state>
  <state id="on">
    <initial>
        <transition target="idle"/>
    </initial>
    <!-- on/pause state -->
    <transition event="turn.off" target="off"/>
    <transition cond="timer &gt;= cook_time" target="off"/>
    <state id="idle">
      <!-- default immediate transition if door is shut -->
      <transition cond="door_closed" target="cooking"/>
      <transition event="door.close" target="cooking">
        <assign location="door_closed" expr="true"/>
        <!-- start cooking -->
      </transition>
    </state>
    <state id="cooking">
      <transition event="door.open" target="idle">
        <assign location="door_closed" expr="false"/>
      </transition>
      <!-- a 'time' event is seen once a second -->
      <transition event="time">
        <assign location="timer" expr="timer + 1"/>
      </transition>
    </state>
  </state>
</scxml>

E.3 Microwave Example (Using parallel)

The example below shows the implementation of a simple microwave oven using <parallel> and the SCXML In() predicate.

Example: microwave-02.scxml

<?xml version="1.0"?>
<scxml xmlns="http://www.w3.org/2005/07/scxml"
       version="1.0"
       profile="ecmascript"
       initial="oven"> 
  <!-- trivial 5 second microwave oven example -->
  <!-- using parallel and In() predicate -->
  <datamodel>
    <data id="cook_time" expr="5"/>
    <data id="door_closed" expr="true"/>
    <data id="timer" expr="0"/>
  </datamodel>
  <parallel id="oven">
    <!-- this region tracks the microwave state and timer -->
    <state id="engine">
      <transition target="off"/>
      <state id="off">
        <!-- off state -->
        <transition event="turn.on" target="on"/>
      </state>
      
      <state id="on">
        <transition target="idle"/>
         <!-- on/pause state -->
        
        <transition event="turn.off" target="off"/>
        <transition cond="timer &gt;= cook_time" target="off"/>
        
        <state id="idle">
          <transition cond="In('closed')" target="cooking"/>
        </state>
        
        <state id="cooking">
          <transition cond="In('open')" target="idle"/>
          <!-- a 'time' event is seen once a second -->
          <transition event="time">
            <assign location="timer" expr="timer + 1"/>
          </transition>
        </state>
      </state>
    </state>
    <!-- this region tracks the microwave door state -->
    <state id="door">
      <initial>
        <transition target="closed"/>
      </initial>
      <state id="closed">
        <transition event="door.open" target="open"/>
      </state>
      <state id="open">
        <transition event="door.close" target="closed"/>
       </state>
    </state>
  </parallel>
</scxml>

E.4 Calculator Example

The example below shows the implementation of a simple calculator in SCXML.

Example: calc.scxml

<?xml version="1.0" ?>
<scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0"
           initial="on" profile="ecmascript" name="calc">
        <datamodel>
                 <data id="long_expr" />
                 <data id="short_expr" expr="0" />
                 <data id="res" />
        </datamodel>
        <state id="on" initial="ready">
                <onentry>
                        <send event="DISPLAY.UPDATE" />
                </onentry>
                <state id="ready" initial="begin">
                <state id="begin">
                        <transition event="OPER.MINUS" target="negated1" />
                        <onentry>
                                <send event="DISPLAY.UPDATE" />
                        </onentry>
                </state>
                <state id="result">
                </state>
                        <transition event="OPER" target="opEntered" />
                        <transition event="DIGIT.0" target="zero1">
                                <assign dataid="short_expr" expr="''" />
                        </transition>
                        <transition event="DIGIT" target="int1">
                                <assign dataid="short_expr" expr="''" />
                        </transition>
                        <transition event="POINT" target="frac1">
                                <assign dataid="short_expr" expr="''" />
                        </transition>
                </state>
                <state id="negated1">
                        <onentry>
                                <assign dataid="short_expr" expr="'-'" />
                                <send event="DISPLAY.UPDATE" />
                        </onentry>
                        <transition event="DIGIT.0" target="zero1" />
                        <transition event="DIGIT" target="int1" />
                        <transition event="POINT" target="frac1" />
                </state>
                <state id="operand1">
                        <state id="zero1">
                                <transition event="DIGIT" cond="_event.name != 'DIGIT.0'" target="int1" />
                                <transition event="POINT" target="frac1" />
                        </state>
                        <state id="int1">
                                <transition event="POINT" target="frac1" />
                                <transition event="DIGIT">
                                        <assign dataid="short_expr" expr="_data.short_expr+_event.name.substr(_event.name.lastIndexOf('.')+1)" />
                                        <send event="DISPLAY.UPDATE" />
                                </transition>
                                <onentry>
                                        <assign dataid="short_expr" expr="_data.short_expr+_event.name.substr(_event.name.lastIndexOf('.')+1)" />
                                        <send event="DISPLAY.UPDATE" />
                                </onentry>
                        </state>
                        <state id="frac1">
                                <onentry>
                                        <assign dataid="short_expr" expr="_data.short_expr+'.'" />
                                        <send event="DISPLAY.UPDATE" />
                                </onentry>
                                <transition event="DIGIT">
                                        <assign dataid="short_expr" expr="_data.short_expr+_event.name.substr(_event.name.lastIndexOf('.')+1)" />
                                        <send event="DISPLAY.UPDATE" />
                                </transition>
                        </state>
                        <transition event="OPER" target="opEntered" />
                </state>
                <state id="opEntered">
                        <transition event="OPER.MINUS" target="negated2" />
                        <transition event="POINT" target="frac2" />
                        <transition event="DIGIT.0" target="zero2" />
                        <transition event="DIGIT" target="int2" />
                        <onentry>
                                <raise event="CALC.SUB" />
                                <send target="_internal" event="OP.INSERT">
                                        <param name="operator" expr="_event.name" />
                                </send>
                        </onentry>
                </state>
                <state id="negated2">
                        <onentry>
                                <assign dataid="short_expr" expr="'-'" />
                                <send event="DISPLAY.UPDATE" />
                        </onentry>
                        <transition event="DIGIT.0" target="zero2" />
                        <transition event="DIGIT" target="int2" />
                        <transition event="POINT" target="frac2" />
                </state>
                <state id="operand2">
                        <state id="zero2">
                                <transition event="DIGIT" cond="_event.name != 'DIGIT.0'" target="int2" />
                                <transition event="POINT" target="frac2" />
                        </state>
                        <state id="int2">
                           <transition event="DIGIT">
                                        <assign dataid="short_expr" expr="_data.short_expr+_event.name.substr(_event.name.lastIndexOf('.')+1)" />
                                        <send event="DISPLAY.UPDATE" />
                                </transition>
                                <onentry>
                                        <assign dataid="short_expr" expr="_data.short_expr+_event.name.substr(_event.name.lastIndexOf('.')+1)" />
                                        <send event="DISPLAY.UPDATE" />
                                </onentry>
                                <transition event="POINT" target="frac2" />
                        </state>
                        <state id="frac2">
                                <onentry>
                                        <assign dataid="short_expr" expr="_data.short_expr+'.'" />
                                        <send event="DISPLAY.UPDATE" />
                                </onentry>
                                <transition event="DIGIT">
                                        <assign dataid="short_expr" expr="_data.short_expr+_event.name.substr(_event.name.lastIndexOf('.')+1)" />
                                        <send event="DISPLAY.UPDATE" />
                                </transition>
                        </state>
                        <transition event="OPER" target="opEntered">
                                <raise event="CALC.SUB" />
                                <raise event="OP.INSERT" />
                        </transition>
                        <transition event="EQUALS" target="result">
                                <raise event="CALC.SUB" />
                                <raise event="CALC.DO" />
                        </transition>
                </state>
                <transition event="C" target="on" />
        </state>
        <transition event="CALC.DO">
                <assign dataid="short_expr" expr="''+_data.res" />
                <assign dataid="long_expr" expr="''" />
                <assign dataid="res" expr="0" />
        </transition>
        <transition event="CALC.SUB">
                <if cond="_data.short_expr!=''">
                        <assign dataid="long_expr" expr="_data.long_expr+'('+_data.short_expr+')'" />
                </if>
                <assign dataid="res" expr="eval(_data.long_expr)" />
                <assign dataid="short_expr" expr="''" />
                <send event="DISPLAY.UPDATE" />
        </transition>
        <transition event="DISPLAY.UPDATE">
                <log level="0" label="'result'" expr="_data.short_expr==''?_data.res:_data.short_expr" />
        </transition>
        <transition event="OP.INSERT">
                <log level="0" expr="_event.data[0]" />
                <if cond="_event.data[0] == 'OPER.PLUS'">
                        <assign dataid="long_expr" expr="_data.long_expr+'+'" />
                <elseif cond="_event.data[0]=='OPER.MINUS'" />
                        <assign dataid="long_expr" expr="_data.long_expr+'-'" />
                <elseif cond="_event.data[0]=='OPER.STAR'" />
                        <assign dataid="long_expr" expr="_data.long_expr+'*'" />
                <elseif cond="_event.data[0]=='OPER.DIV'" />
                        <assign dataid="long_expr" expr="_data.long_expr+'/'" />
                </if>
        </transition>
</scxml>

E.5 Shale Example

The example below, which is from the Apache Shale Project. Shale is a web application framework based on JavaServer Faces (JSF). It's composed of loosely coupled services that provide functionality such as application event callbacks, dialogs with conversation-scoped state, a view technology called Clay, annotation-based functionality to reduce configuration requirements and support for remoting. For more information on Shale please see http://shale.apache.org/ . SCXML is used as a "dialog manager" service in Shale (for details on the integration of SCXML in Shale please see http://shale.apache.org/shale-dialog-scxml/index.html ). It allows Shale application authors to express navigation across multiple JSF views and/or other conversations with users of a JSF application using the SCXML markup notation. The example below describes how the navigation across multiple JSF views can be expressed using SCXML. It also shows how a submachine (edit-profile-config.scxml) can be used within an SCXML file. The binding language used in these examples is EL [EL] , which is the expression language supported in the JSF environment.

Example: log-on-config.scxml
UML diagram for this example
<?xml version="1.0" encoding="UTF-8"?>
<!--
  Dialog definitions for Shale Use Cases Example Web Application
  written out as SCXML to demonstrate use of Commons SCXML as one
  of Shale's Dialog Manager implementations.
  For details, see: http://shale.apache.org/shale-dialog-scxml/
-->
<scxml xmlns="http://www.w3.org/2005/07/scxml" xmlns:my="http://scxml.examples.org/"
       version="1.0" initial="checkCookie" profile="el" >
  <state id="checkCookie">
    <onentry>
      <my:var name="cookieOutcome" expr="#{profile$logon.check}" />
    </onentry>
    <transition cond="${cookieOutcome eq 'authenticated'}" target="exit"/>
    <transition cond="${cookieOutcome eq 'unauthenticated'}" target="logon"/>
  </state>
  <state id="logon">
    <transition event="faces.outcome" cond="${outcome eq 'authenticated'}" target="exit"/>
    <transition event="faces.outcome" cond="${outcome eq 'create'}" target="createProfile"/>
  </state>
  <state id="createProfile" src="edit-profile-config.xml" >
      <transition event="createProfile.done" cond="${outcome eq 'success' or outcome eq 'cancel'}" target="exit"/>
  </state>
  <final id="exit"/>
</scxml>
Example: edit-profile-config.scxml
UML diagram for this example
<?xml version="1.0" encoding="UTF-8"?>
<!--
  Dialog definitions for Shale Use Cases Example Web Application
  written out as SCXML to demonstrate use of Commons SCXML as one
  of Shale's Dialog Manager implementations.
  For details, see: http://shale.apache.org/shale-dialog-scxml/
-->
<scxml xmlns="http://www.w3.org/2005/07/scxml" xmlns:my="http://scxml.examples.org/"
       version="1.0" initial="edit" profile="el">
  <state id="edit">
    <initial>
      <transition target="setup"/>
    </initial>
    <!-- global transitions (within state "edit") -->
    <transition event="faces.outcome" cond="${outcome eq 'cancel'}" target="cancel"/>
    <transition event="faces.outcome" cond="${outcome eq 'finish'}" target="finish"/>
    <state id="setup">
      <onentry>
        <my:var name="setupOutcome" expr="#{profile$edit.setup}" />
      </onentry>
      <transition cond="${setupOutcome eq 'success'}" target="page1"/>
    </state>
    <state id="page1">
      <transition event="faces.outcome" cond="${outcome eq 'next'}" target="page2"/>
    </state>
    <state id="page2">
      <transition event="faces.outcome" cond="${outcome eq 'previous'}" target="page1"/>
      <transition event="faces.outcome" cond="${outcome eq 'next'}" target="page3"/>
    </state>
    <state id="page3">
      <transition event="faces.outcome" cond="${outcome eq 'previous'}" target="page2"/>
      <transition event="faces.outcome" cond="${outcome eq 'next'}" target="editExit"/>
    </state>
  </state>
  <state id="cancel">
  <onentry>
      <my:var name="cancelOutcome" expr="#{profile$edit.cancel}" />
    </onentry>
    <transition cond="${cancelOutcome eq 'success'}" target="editExit">
      <my:var name="outcome" expr="cancel"/>
    </transition>
  </state> 
  <state id="finish">
    <onentry>
      <my:var name="finishOutcome" expr="#{profile$edit.finish}" />
    </onentry>
    <transition cond="${finishOutcome eq 'username'}" target="page1"/>
    <transition cond="${finishOutcome eq 'password'}" target="page1"/>
    <transition cond="${finishOutcome eq 'success'}" target="editExit">
      <my:var name="outcome" expr="success"/>
    </transition>
  </state>
  <final id="editExit"/>
</scxml>

E.3 E.6 Examples of Invoke and finalize

The following two SCXML documents demonstrate the use of Invoke and finalize. The first example shows the control flow for a voice portal offering traffic reports.

Example: Traffic Report
<?xml version="1.0"?>
<?access-control allow="*"?>
<scxml version="1.0" initial="Intro" profile="ecmascript">
  <state id="Intro">
    <invoke src="dialog.vxml#Intro" type="vxml2"/>
    <transition event="success" cond="_data.sessionChrome.playAds" target="PlayAds"/>
    <transition event="success" cond="!_data.sessionChrome.playAds &amp;&amp; _data.ANIQuality" 
                                        target="ShouldGoBack"/>
    <transition event="success" cond="!_data.sessionChrome.playAds &amp;&amp; !_data.ANIQuality" 
                                        target="StartOver"/>
  </state>
  <state id="PlayAds">
    <invoke src="dialog.vxml#PlayAds" type="vxml2"/>
    <transition event="success" cond="_data.ANIQuality" target="ShouldGoBack"/>
    <transition event="success" cond="!_data.ANIQuality" target="StartOver"/>
  </state>
  <state id="StartOver">
    <onenter>
      <script>enterStartOver();</script>
    </onenter>
    <invoke src="dialog.vxml#StartOver" type="vxml2">
      <param name="gotItFromANI" expr="_data.gotItFromANI"/>
      <finalize>
        <script>finalizeStartOver();</script>
      </finalize>
    </invoke>
    <transition event="success" target="ShouldGoBack"/>
    <transition event="doOver" target="StartOver"/>
    <transition event="restart" target="Intro"/> <!-- bail out to caller -->
  </state>
  <state id="ShouldGoBack">
    <invoke src="dialog.vxml#ShouldGoBack" type="vxml2">
      <param name="cityState" expr="_data.cityState"/>
      <param name="gotItFromANI" expr="_data.gotItFromANI"/>
      <finalize>
        <script>finalizeShouldGoBack();</script>
      </finalize>
    </invoke>
    <transition event="highWay" target="HighwayReport"/>
    <transition event="go_back" target="StartOver"/>
    <transition event="doOver" target="ShouldGoBack"/>
    <transition event="restart" target="Intro"/>
  </state>
  <state id="HighwayReport">
    <invoke src="dialog.vxml#HighwayReport" type="vxml2">
      <param name="cityState" expr="_data.cityState"/>
      <param name="gotItFromANI" expr="_data.gotItFromANI"/>
      <param name="playHRPrompt" expr="_data.playHRPrompt"/>
      <param name="metroArea" expr="_data.metroArea"/>
      <finalize>
        <script>finalizeHighwayReport();</script>
      </finalize>
    </invoke>
    <transition event="highway" target="PlayHighway"/>
    <transition event="go_back" target="StartOver"/>
    <transition event="doOver" target="HighwayReport"/>
    <transition event="fullreport" target="FullReport"/>
    <transition event="restart" target="Intro"/>
  </state>
  <state id="FullReport">
    <invoke src="dialog.vxml#FullReport" type="vxml2">
      <param name="cityState" expr="_data.cityState"/>
      <param name="metroArea" expr="_data.metroArea"/>
      <finalize>
        <script>finalizeFullReport();</script>
      </finalize>
    </invoke>
    <transition event="go_back" target="HighwayReport"/>
    <transition event="new_city" target="StartOver"/>
  </state>
  <state id="PlayHighway">
    <invoke src="dialog.vxml#PlayHighway" type="vxml2">
      <param name="cityState" expr="_data.cityState"/>
      <param name="curHighway" expr="_data.curHighway"/>
      <finalize>
        <script>finalizePlayHighway();</script>
      </finalize>
    </invoke>
    <transition event="go_back" target="HighwayReport"/>
  </state>
</scxml>

The following example shows a the control flow for a blackjack game.

Example: Blackjack
<?xml version="1.0"?>
<?access-control allow="*"?>
<scxml version="1.0" profile="ecmascript" initial="master"> <state id="master">
    <initial id="init1">
      <transition target="_home"/>
    </initial>
    <transition event="new_dealer" target="NewDealer"/>
    <transition event="mumble" target="_home"/> <!-- bail out to caller -->
    <transition event="silence" target="_home"/> <!-- bail out to caller -->
    <state id="_home">
      <onenter>
        <script>
        _data = {};
        </script>
      </onenter>
      <invoke src="datamodel.v3#InitDataModel" type="vxml3">
        <finalize>
          <script>
          var n;
          for (n in event) {
              _data[n] = event[n];
          }
          </script>
        </finalize>
      </invoke>
      <transition event="success" target="Welcome"/>
    </state>
    <state id="Welcome">
      <invoke src="dialog.vxml#Welcome" type="vxml3">
        <param name="skinpath" expr="_data.skinpath"/>
      </invoke>
      <transition event="success" target="Intro2"/>
    </state>
    <state id="Intro2">
      <invoke src="dialog.vxml#Intro2" type="vxml3">
        <param name="skinpath" expr="_data.skinpath"/>
      </invoke>
      <transition event="success" target="EvalDeal"/>
    </state>
    <state id="EvalDeal">
      <onenter>
        <script>enterEvalDeal();</script>
      </onenter>
      <invoke src="dialog.vxml#EvalDeal" type="vxml3">
        <param name="skinpath" expr="_data.skinpath"/>
        <param name="playercard1" expr="_data.playercard1"/>
        <param name="playercard2" expr="_data.playercard2"/>
        <param name="playertotal" expr="_data.blackjack.GetTotalOf('caller').toString()"/>
        <param name="dealercardshowing" expr="_data.dealercardshowing"/>
      </invoke>
      <transition event="success" target="AskHit"/>
    </state>
    <state id="AskHit">
      <invoke src="dialog.vxml#AskHit" type="vxml3">
        <param name="skinpath" expr="_data.skinpath"/>
        <finalize>
          <script>finalizeAskHit();</script>
        </finalize>
      </invoke>
      <transition event="hit" target="PlayNewCard"/>
      <transition event="stand" target="PlayDone"/>
    </state>
    <state id="PlayNewCard">
      <invoke src="dialog.vxml#PlayNewCard" type="vxml3">
        <param name="skinpath" expr="_data.skinpath"/>
        <param name="playernewcard" expr="_data.playernewcard"/>
        <param name="playertotal" expr="_data.blackjack.GetTotalOf('caller').toString()"/>
      </invoke>
      <transition event="success" cond="_data.blackjack.GetTotalOf('caller') &gt;= 21" target="PlayDone"/>
      <transition event="success" target="AskHit"/> <!-- less than 21 -->
    </state>
    <state id="PlayDone">
      <onenter>
        <script>enterPlayDone();</script>
      </onenter>
      <invoke src="dialog.vxml#PlayDone" type="vxml3">
        <param name="skinpath" expr="_data.skinpath"/>
        <param name="gameresult" expr="_data.blackjack.GetGameResult()"/>
        <param name="dealertotal" expr="_data.blackjack.GetTotalOf('dealer').toString()"/>
      </invoke>
      <transition event="playagain" target="Intro2"/>
      <transition event="quit" target="_home"/>
    </state>
    <state id="NewDealer">
      <onenter>
       <script>enterNewDealer();</script>
      </onenter>
      <invoke src="dialog.vxml#Dummy" type="vxml3"/>
      <transition event="success" target="Welcome"/>
    </state>
  </state>
</scxml>

E.4 E.7 Custom Action Elements

Custom Action Elements can be defined in other specifications/namespaces and are responsible for performing actions on behalf of custom components. Logically Custom Action Elements can be thought of as a collection of actions and handlers to perform specific tasks. An example of this is a CCXML <accept> element that is a Custom Action Element:

<transition event="ccxml:connection.alerting">
  <ccxml:accept connectionid="eventdata.connectionid"/>

  <ccxml:accept connectionid="_event.data.connectionid"/>

</transition>

This could be written using a <send> element using the following syntax:

<datamodel>
<data name="connectionid"/>
</datamodel>
<transition event="ccxml:connection.alerting">
  <assign name="connectionid" expr="eventdata.connectionid"/>

  <assign name="connectionid" expr="_event.data.connectionid"/>

 <send type="'ccxml'" event="'ccxml:accept'" namelist="connectionid"/> 
</transition>

A more complicated example might be a CCXML <createcall> where you are both providing variables and getting values back that using only the <send> syntax would be more complex as it would need to be broken over several steps. For example:

<onentry>
  <ccxml:createcall dest="'tel:+18315552020'" connectionid="myConnectionID"/> 
</onentry>

Would need to be modeled in two steps using <send> as you would need to do something like the following:

<datamodel>
  <data name="dest" expr="'tel:+18315552020'"/>
  <data name="connectionid"/>
</datamodel>
<onentry>
  <send type="'ccxml'" event="'ccxml:createcall'" namelist="dest"/>
</onentry>
<transition event="ccxml:createcall.success">
   <assign name="connectionid" expr="eventdata.connectionid"/>

   <assign name="connectionid" expr="_event.data.connectionid"/>

</transition>

The exact mappings between Custom Action Elements and <send> actions are to be defined in the individual Custom Action Element specifications.

F Conformance

A SCXML 1.0 processor is a user agent that can parse and process Conforming SCXML 1.0 documents.

In a Conforming SCXML 1.0 Processor, the XML parser must be able to parse and process all well-formed XML constructs defined within [XML] and [XMLNames] . It is not required that a Conforming SCXML 1.0 processor use a validating parser.

Conformance in SCXML is defined with respect to profiles. A Conforming SCXML 1.0 Processor that supports a given profile must support the syntax and semantics of all SCXML elements in that profile as described in this document. Consequently, a SCXML 1.0 Processor must not throw an error.unsupported.<element> for any SCXML element in that profile when processing a Conforming SCXML 1.0 Document.

When a Conforming SCXML 1.0 Processor encounters a Conforming SCXML 1.0 Document with non-SCXML elements or attributes which are proprietary, or defined in a non-SCXML namespace, and which cannot be processed, the processor's behavior is defined by the value of the 'exmode' attribute in the root <scxml> element of the document. If 'exmode' is strict, the processor must throw an error.badfetch event. If 'exmode' is 'lax', the processor must ignore the element.

When a Conforming SCXML 1.0 Processor encounters a document with a root element designating a namespace other than SCXML, its behavior is undefined.

When a conforming SCXML 1.0 Processor encounters a document with a root element of <scxml> with a version attribute with a value other than 1.0, its behavior is undefined.

There is, however, no conformance requirement with respect to performance characteristics of the SCXML 1.0 Processor.

G SCXML Event I/O Processor

The SCXML Event I/O Processor is intended to transport messages in a specific format to and from SCXML sessions. This processor specifies the schema of the messages and how they map onto SCXML events, but it does not define the transport mechanism, which is platform-specific. The schema for the message is available at D.10 SCXML Message Schema :. The sender or the receiver of the message may be either an SCXML session or an external entity, but this specification defines the behavior for SCXML sessions only .

The contents of the individual messages are defined as follows:

  1. The value of the 'name' attribute is taken from the 'event' attribute of the <send> element. It is then used as value the 'name' field in the event that is generated by the receiving processor (see 5.6.1 The Internal Structure of Events ). This field is what is matched against the 'event' attribute of <transition>.
  2. The value of the 'source' attribute is a URI that the receiving processor can use to reply to the sending processor. It is used as the value of the 'origin' field in the event that is generated by the receiving side (see 5.6.1 The Internal Structure of Events ). In profiles supporting the Data Module, the access URI is available in the sending session via the system variable _ioprocessors using the key "basichttp".
  3. The 'target' attribute contains an identifier of SCXML session to which the message should be delivered. It is taken from the 'target' attribute of the <send> element. In general, the format of the identifier is platform-specific. However there are two distinguished values. If the value of the 'target' attribute in the <send> element is '_internal', the receiving session will be identical to the sending session, and it will populate the 'type' field of the resulting event with "internal" and will add the event to its internal event queue. If the 'target' attribute is not specified, the receiving session will be identical to the sending session, and it will populate the 'type' field of the resulting event with "external" and will add the event to its external event queue. If the value of the 'target' attribute is anything else, the receiving processor will set the type field of the resulting event to "external" and will add the event to its external event queue.
  4. The 'sendid' attribute is populated with the identifier specified in the 'id' attribute or automatically generated by the platform when the <send> tag executed in the sending SCXML session. (See 4.1 <send> .) It will be used as the value of the 'sendid' field in the event that is generated by the receiving processor. If the author of the sending session did not specify either the 'id' or 'idlocation' attribute, this attribute will be empty.
  5. The 'sourcetype' attribute contains an indication of the type of process that generated the message. It will be used to populate the 'origintype' field of the event that is generated by the receiving processor. If the sender is an SCXML processor, the value will be "scxml".
  6. The 'language' attribute is used to indicate the type of data contained in the body of the message inside the <payload> element. The receiving process can use this information to parse and validate the message.
  7. The <payload> element contains any data that is associated with the message. It will be encoded in the language indicated by the 'language' attribute, for example XML or JSON. This data may be in any namespace, or in no namespace at all, but it may also contain <scxml:hint> and <scxml:property> elements that provide additional information about the data.

The mapping between <send>, the SCXML message structure, and the event that is raised in the receiving session is given below.

<send> element SCXML Message Structure Target Session Event
'event' attribute 'name' attribute 'name' field
not present in <send> but known to platform 'source' attribute 'origin' field
'target' attribute 'target' attribute not present
literal provided by author or value generated by platform 'sendid' attribute 'sendid' field
not present 'sourcetype' attribute. Always "scxml". 'origintype' field. Always "scxml".
not present 'language' attribute. not present
'namelist' attribute, <content> child, or <param> children <payload> element data field

The sending SCXML Event I/O processor MUST populate these fields of the SCXML message structure in the manner defined above, and the receiving processor MUST use them to create the appropriate internal or external event structure as defined above.

When an SCXML processor receives a message via the SCXML Event I/O Processor it validates the syntax of the incoming message and checks that it matches an active session. If the message fails syntactic validation or does not match an active session, the receiving processor notifies the sending processor of the error and ignores the message. If the message passes validation, but the receiving processor cannot handle the data format contained in the message, the receiving processor SHOULD raise the error: error.receive.datamismatch in the session for which the message was intended and SHOULD also notify the sending processor of the error. It then ignores the message. If no errors occur, the receiving session converts the message into an SCXML event, using the mapping defined above, and inserts the event its external event queue.

If the sending entity is an SCXML session, it SHOULD also report errors. If the sending session specifies a sessionid that does not exist on the receiving system, it SHOULD raise the error: error.send.nosuchsession. If the sending session specifies a data format that the receiving session does not support, it SHOULD raise the error: error.send.datamismatch. For any other errors, such as inability to connect to the receiving system, the sending system SHOULD raise error.send.failed.scxmlio. An implementation may extend any of the errors described in this section to provide more information if it desires. For example, an implmentation may choose to raise error.send.failed.scxmlio.cannotconnect or error.receive.datamismatch.ecmascript, etc.

The SCXML Event I/O Processor MUST handle the 'cancel.invoke. invokeid ' event. In particular, if SCXML session session1 sends this event to session session2, where session1 invoked session2 via an <invoke> element with invokeid invokeid , the SCXML Event I/O Processor MUST set the 'continue' variable in session2 to 'false' and discard the event. (See B Algorithm for SCXML Interpretation for details.) In all other cases (that is, in cases where the invokeid does not match), the SCXML Event I/O processor MUST discard the event and SHOULD signal an error.

G.1 Examples

Here are some examples of SCXML messages sent between SCXML sessions. Each example shows the original <send> element, the corresponding <message> structures and a transition handling the resulting event in the receiving SCXML session.

EXAMPLE 1: First, here is a message with an XML payload generated by <send> with a 'namelist':

SESSION1 : SENDING SESSION
Pattern: "event" attribute with an optional "namelist"
<datamodel>
  <data id="email" expr="'mailto:recipient@example.com'"/>
  <data id="content" expr="'http://www.example.com/mycontent.txt'"/>
  <data id="xmlcontent">
    <headers xmlns="http://www.example.com/headers">
      <cc>archive@example.com</cc>
      <subject>Example email</subject>
    </headers>
  </data>
</datamodel>
  ...
<send id="send-123"
      target="'http://scxml-processors.example.com/session2'"
      type="'scxml'" event="'email.send'"
      namelist="email content xmlcontent"
      hints="'Email headers'"/>

Here is the actual XML message that will be sent over platform-specific transport and converted into an event in the target SCXML session:

<scxml:message xmlns:scxml="http://www.w3.org/2005/07/scxml" version="1.0"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.w3.org/2005/07/scxml scxml-message.xsd"
       source="http://scxml-processors.example.com/session1" sourcetype="scxml"
       target="http://scxml-processors.example.com/session2" type="scxml"
       sendid="send-123" name="email.send">
  <scxml:payload>
    <scxml:property name="email">mailto:recipient@example.com</scxml:property>
    <scxml:property name="content">http://www.example.com/mycontent.txt</scxml:property>
    <scxml:property name="xmlcontent">
      <scxml:hint>Email headers</scxml:hint>
      <headers xmlns="http://www.example.com/headers">
        <cc>archive@example.com</cc>
        <subject>Example email</subject>
      </headers>
    </scxml:property>
  </scxml:payload>
</scxml:message>

Here is sample SCXML code to process that event in the receiving SCXML session. In this example <my:email> is platform-specific executable content that sends an email:

SESSION2 : RECEIVING SESSION
Pattern: "event" attribute with an optional "namelist"
<scxml:transition event="email.send">
  <my:email to="data('_event')/scxml:property[@name='email']"
            cc="data('_event')/scxml:property[@name='xmlcontent']/h:headers/h:cc"
            subject="data('_event')/scxml:property[@name='xmlcontent']/h:headers/h:subject"
            content="data('_event')/scxml:property[@name='content']"/>
</scxml:transition>

EXAMPLE 2: The next example shows <send> using inline XML content:

SESSION1 : SENDING SESSION
Pattern: "xmlns" attribute with explicit inline content
<send id="send-123"
      target="'http://scxml-processors.example.com/session2'"
      type="'scxml'"
      xmlns:csta="http://www.ecma.ch/standards/ecma-323/csta">
  <csta:MakeCall>
    <csta:callingDevice>22343</callingDevice>
    <csta:calledDirectoryNumber>18005551212</csta:calledDirectoryNumber>
  </csta:MakeCall>

  <content>
     <csta:MakeCall>
       <csta:callingDevice>22343</callingDevice>
       <csta:calledDirectoryNumber>18005551212</csta:calledDirectoryNumber>
     </csta:MakeCall>
  </content>

</send>

Here is the actual XML message that will be sent:

<scxml:message xmlns:scxml="http://www.w3.org/2005/07/scxml" version="1.0"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.w3.org/2005/07/scxml scxml-message.xsd"
       source="http://scxml-processors.example.com/session1"
       target="http://scxml-processors.example.com/session2"
       sendid="send-123">
  <scxml:payload xmlns:csta="http://www.ecma.ch/standards/ecma-323/csta">
    <csta:MakeCall>
      <csta:callingDevice>22343</csta:callingDevice>
      <csta:calledDirectoryNumber>18005551212</csta:calledDirectoryNumber>
    </csta:MakeCall>
  </scxml:payload>
</scxml:message>

Here is sample SCXML code to process the resulting event in the receiving SCXML session. It uses the special executable content <csta:makecall> to generate a telephone call:

SESSION2 : RECEIVING SESSION
Pattern: "xmlns" attribute with explicit inline content
<scxml:transition event="external.event">
  <csta:makecall callingDevice="data('_event')/csta:MakeCall/csta:callingDevice"
                 callingDirectoryNumber="data('_event')/csta:MakeCall/csta:callingDirectoryNumber"/>
</scxml:transition>

EXAMPLE 3: Finally, here is an example generated by <send> using both 'event' and'namelist' attributes and using JSON content:

SESSION1 : SENDING SESSION
Pattern: "event" attribute with an optional "namelist"
<datamodel>
  <data id="email" expr="'mailto:recipient@example.com'"/>
  <data id="content" expr="'http://www.example.com/mycontent.txt'"/>
  <data id="jsoncontent" src="http://www.example.com/headers.json"/>
</datamodel>
  ...
<send sendid="send-123"
      target="'http://scxml-processors.example.com/session2'"
      type="'scxml'" event="'email.send'"
      namelist="email content jsoncontent"
      hints="'Email headers'"/>

Here is the actual XML message that will be sent over platform-specific transport and converted into an event in the target SCXML session:

<scxml:message xmlns:scxml="http://www.w3.org/2005/07/scxml" version="1.0"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.w3.org/2005/07/scxml scxml-message.xsd"
       source="http://scxml-processors.example.com/session1"
       target="http://scxml-processors.example.com/session2"
       sendid="send-123" name="email.send" language="json">
  <scxml:payload>
    <scxml:property name="email">mailto:recipient@example.com</scxml:property>
    <scxml:property name="content">http://www.example.com/mycontent.txt</scxml:property>
    <scxml:property name="jsoncontent">
      <scxml:hint>Email headers</scxml:hint>
      <![CDATA[
        headers : {
          cc  : "audit@example.com" ,
          subject : "Example email"
        }
      ]]>
    </scxml:property>
  </scxml:payload>
</scxml:message>

Here is sample SCXML code to process the resulting event in the receiving SCXML session. In this example, <my:email> is special executable content as in the first example.

SESSION2 : RECEIVING SESSION
Pattern: "event" attribute with an optional "namelist"
<scxml:transition event="email.send">
  <my:email to="_event.email"
            cc="_event.jsoncontent.headers.cc"
            subject="_event.jsoncontent.headers.subject"
            content="_event.content"/>
</scxml:transition>

In some cases it may be convenient to included multiple <message> structures in a single payload. The following schema defines a <messages> element which contains multiple <message> elements. Support for this schema is optional.

scxml-messages.xsd

<?xml version="1.0" encoding="UTF-8"?>
<!--
    XML Schema for sending messages to SCXML processors.
-->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:scxml="http://www.w3.org/2005/07/scxml"
    targetNamespace="http://www.w3.org/2005/07/scxml"
        elementFormDefault="qualified">
        
<xsd:include schemalocation="scxml-message.xsd"/>
        <xsd:annotation>
                <xsd:documentation xml:lang="en">
                        XML Schema for sending messages to SCXML processors.
                        Version 1.0
                </xsd:documentation>
                <xsd:documentation source="scxml-copyright.xsd" />
        </xsd:annotation>
        <xsd:attributeGroup name="scxmlmessages.extra.attribs">
                <xsd:annotation>
                        <xsd:documentation>
                                Group allowing attributes from other namespaces
                        </xsd:documentation>
                </xsd:annotation>
                <xsd:anyAttribute namespace="##other" processContents="lax" />
        </xsd:attributeGroup>
        <xsd:attributeGroup name="scxmlmessages.messages.attlist">
                <xsd:attribute name="version" type="xsd:string" fixed="1.0"
                        use="required" />
                <xsd:attributeGroup ref="scxml:scxmlmessages.extra.attribs" />
        </xsd:attributeGroup>
        <xsd:group name="scxmlmessages.messages.content">
                <xsd:sequence>
                        <xsd:element ref="scxml:message" minOccurs="1"
                                maxOccurs="unbounded" />
                </xsd:sequence>
        </xsd:group>
        <xsd:complexType name="scxmlmessages.messages.type">
                <xsd:group ref="scxml:scxmlmessages.messages.content" />
                <xsd:attributeGroup ref="scxml:scxmlmessages.messages.attlist" />
        </xsd:complexType>
        <xsd:element name="messages" type="scxml:scxmlmessages.messages.type" />
</xsd:schema>

H Basic HTTP Event I/O Processor

The Basic HTTP Event I/O Processor is intended as a minimal interoperable mechanism for sending and receiving events between external components and SCXML 1.0 implementations. Support for the Basic HTTP Event I/O Processor is optional, but implementations that implement this processor MUST support sending and receiving messages in the SCXML message format using it( D.10 SCXML Message Schema ).

H.1 Access URI

The access URI for the Basic HTTP Event I/O Processor is the URI to which an external component can send an event for injection into an active session.

In profiles supporting both the Data Module and the External Module, the access URI is available via the system variable _ioprocessors using the key "basichttp". For example, in 9.2 10.2 The ECMAScript Profile , _ioprocessors["basichttp"] returns the access URI (e.g. http://www.example.com/scxml/basichttp) for the basichttp processor.

The access URI for the Basic HTTP Event I/O Processor may be sent to external components by, for example, its inclusion in the namelist attribute of the <send> element.

The access URI may also be specified in an implementation-specific manner (for example, product documentation).

H.2 Receiving Events

Input from external components can be received by the SCXML implementation at the basichttp access URI as HTTP POST requests (see [HTTP] ). If the HTTP parameter '_content' is present, its value will be interpreted as a message in the SCXML message format ( D.10 SCXML Message Schema ). Such messages are mapped to SCXML events as described in G SCXML Event I/O Processor . Implementations MAY accept other parameters as well. In such cases, the mapping of their values to SCXML events is implementation-specific.

The Basic HTTP Event I/O Processor validates the message it has received, builds the appropriate SCXML event and adds it to the appropriate event queue. It then indicates the result to the external component via a success response code 2XX. Note that this response is sent before the event is removed from the queue and processed.

In the cases where the message cannot be formed into an SCXML event, the processor MUST return an HTTP error code as defined in [HTTP] . The following codes are assigned a more specific meaning in the SCXML context:

  • 400 (Bad Request). Message structure is invalid.
  • 403 (Forbidden). Session id does not match an existing SCXML session id.

H.3 Sending Events

Events can be sent from the SCXML implementation to an external component with the Basic HTTP Event I/O Processor using the <send> element (see 4.1 <send> ) with the type attribute set to "basichttp". The target attribute is set to the access URI of the external component.

The HTTP method is "POST" and parameter values are encoded by default in an application/x-www-form-urlencoded body (POST method). This default encoding MAY be overriden in a platform-specific way, e.g. by using the 'hints' attribute.

If the namelist attribute is defined, its variable names and values are mapped to HTTP parameters. If one or more <param> children are present, their names (i.e. name attributes) and values are mapped to HTTP parameters. If a <content> child is present, its value is mapped to the distinguished HTTP parameter '_content'.

If the external component returns any HTTP response code other than 2XX, the implementation will raise the error error.send.failed.http. error_code in the session that attempted to send the event, where error_code is the HTTP error code that was received.

I References

CSS2
Cascading Style Sheets, level 2: CSS2 Specification . B. Bos, et al., Editors. World Wide Web Consortium, 12 May 1998. This version of the CSS2 Recommendation is http://www.w3.org/TR/1998/REC-CSS2-19980512/. The latest version of CSS2 is available at http://www.w3.org/TR/REC-CSS2/. (See http://www.w3.org/TR/1998/REC-CSS2-19980512/.)
OASIS ebXML
ebXML Business Process Specification Schema v2.0 . (See http://www.oasis-open.org/committees/documents.php?wg_abbrev=ebxml-bp.)
ECMASCRIPT-262
ECMAScript Language Specification Standard ECMA-262, 3rd Edition, December 1999. (See http://www.ecma-international.org/publications/standards/Ecma-262.htm.)
ECMASCRIPT-327
ECMAScript 3rd Edition Compact Profile Standard ECMA-327, July 2001. (See http://www.ecma-international.org/publications/standards/Ecma-327.htm.)
E4X
ECMAScript for XML (E4X) Specification Standard ECMA-357, 2nd Edition, December 2005. (See http://www.ecma-international.org/publications/standards/Ecma-357.htm.)
EL
EL: The JSP 2.0 Expression Language Interpreter (See http://jakarta.apache.org/commons/el/.)
Harel and Politi
Modeling Reactive Systems with Statecharts: The STATEMATE Approach By D. Harel and M. Politi. McGraw-Hill, 1998. (See http://www.wisdom.weizmann.ac.il/~dharel/reactive_systems.html.)
IETF RFC 2119
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels . Internet Engineering Task Force, 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)
IETF RFC 2396
RFC 2396: Uniform Resource Identifiers . Internet Engineering Task Force, 1995. (See http://www.ietf.org/rfc/rfc2396.txt.)
W3C CCXML 1.0
Voice Browser Call Control: CCXML Version 1.0 . W3C, 2005. (See http://www.w3.org/TR/2005/WD-ccxml-20050111/.)
HTTP
CMultimodal Architecture and Interfaces Working Draft . W3C, 2005. (See http://www.ietf.org/rfc/rfc2616.txt.)
JSON
The application/json Media Type for JavaScript Object Notation (JSON) RFC 4627, July 2006. (See http://www.ietf.org/rfc/rfc4627.txt.)
W3C MMI
"Hypertext Transfer Protocol -- HTTP/1.1 " . IETF RFC 2616, 199. (See http://www.w3.org/TR/mmi-arch/.)
RFC2616
Hypertext Transfer Protocol -- HTTP/1.1 IETF RFC 2616, 1999. (See http://www.ietf.org/rfc/rfc2616.txt.)
RFC2617
HTTP Authentication: Basic and Digest Access Authentication IETF RFC 2617, June 1999. (See http://www.ietf.org/rfc/rfc2617.txt.)
W3C VoiceXML 2.0
VoiceXML 2.0: . W3C, 2004. (See http://www.w3.org/TR/VoiceXML20.)
UML 2.0
UML Specification Version 2.0 .OMG, 2009. (See http://www.omg.org/uml/.)
UML XMI
XML Metadata Exchange version 2.1 .(See http://www.omg.org/technology/documents/modeling_spec_catalog.htm#XMI.)
XInclude
XML Inclusions (XInclude) Version 1.0 .W3C, 2006. (See http://www.w3.org/TR/xinclude/.)
XML
Extensible Markup Language (XML) 1.0 (Fourth Edition) T. Bray et. al. eds. World Wide Web Consortium 16 August 2006 (See http://www.w3.org/TR/xml/.)
XML ID
xml:id version 1.0 J. Marsh, D. Veillard, N. Walsh. World Wide Web Consortium, 9 September 2005. (See http://www.w3.org/TR/2005/REC-xml-id-20050909/.)
XMLNames
Namespaces in XML 1.0 (Second Edition) T. Bray, D. Hollander, A. Layman, R. Tobin, Editors, W3C Recommendation, 16 August 2006 (See http://www.w3.org/TR/2006/REC-xml-names-20060816/.)
XML Schema
XML Schema Part 2: Datatypes Second Edition P. Biron and A. Malhotra. World Wide Web Consortium, 28 October 2004. (See http://www.w3.org/TR/xmlschema-2/.)
XPath 2.0
XML Path Language (XPath) 2.0 A. Berglund, S. Boag, D. Chamberlin, M. Fernández, M. Kay, J. Robie, J. Siméon, January 2007 (See http://www.w3.org/TR/xpath20/.)
XPath 2.0 Functions and Operators
XQuery 1.0 and XPath 2.0 Functions and Operators A. Malhotra, J. Melton, N. Walsh, January 2007 (See http://www.w3.org/TR/xpath-functions/.)
XTND
XML Transition Network Definition .(See http://www.w3.org/TR/2000/NOTE-xtnd-20001121/.)