You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
8338 lines
306 KiB
8338 lines
306 KiB
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="EN">
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org" />
|
|
<title>State Chart XML (SCXML): State Machine Notation for Control
|
|
Abstraction</title>
|
|
<style type="text/css">
|
|
code { font-family: monospace; }
|
|
|
|
div.constraint,
|
|
div.issue,
|
|
div.note,
|
|
div.notice { margin-left: 2em; }
|
|
|
|
ol.enumar { list-style-type: decimal; }
|
|
ol.enumla { list-style-type: lower-alpha; }
|
|
ol.enumlr { list-style-type: lower-roman; }
|
|
ol.enumua { list-style-type: upper-alpha; }
|
|
ol.enumur { list-style-type: upper-roman; }
|
|
|
|
|
|
div.exampleInner pre { margin-left: 1em;
|
|
margin-top: 0em; margin-bottom: 0em}
|
|
div.exampleOuter {border: 4px double gray;
|
|
margin: 0em; padding: 0em}
|
|
div.exampleInner { background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px; margin: 0em }
|
|
div.exampleWrapper { margin: 4px }
|
|
div.exampleHeader { font-weight: bold;
|
|
margin: 4px}
|
|
|
|
table {
|
|
width:80%;
|
|
border:1px solid #000;
|
|
border-collapse:collapse;
|
|
font-size:90%;
|
|
}
|
|
|
|
td,th{
|
|
border:1px solid #000;
|
|
border-collapse:collapse;
|
|
padding:5px;
|
|
}
|
|
|
|
|
|
caption{
|
|
background:#ccc;
|
|
font-size:140%;
|
|
border:1px solid #000;
|
|
border-bottom:none;
|
|
padding:5px;
|
|
text-align:center;
|
|
}
|
|
|
|
img.center {
|
|
display: block;
|
|
margin-left: auto;
|
|
margin-right: auto;
|
|
}
|
|
p.caption {
|
|
text-align: center
|
|
}
|
|
|
|
.RFC2119 {
|
|
text-transform: lowercase;
|
|
font-style: italic;
|
|
}
|
|
</style>
|
|
|
|
<link type="text/css" rel="stylesheet"
|
|
href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" />
|
|
</head>
|
|
<body>
|
|
<div class="head">
|
|
<p><a href="http://www.w3.org/"><img width="72" height="48"
|
|
alt="W3C" src="http://www.w3.org/Icons/w3c_home" /></a></p>
|
|
|
|
<h1><a id="title" name="title" />State Chart XML (SCXML): State
|
|
Machine Notation for Control Abstraction</h1>
|
|
|
|
<h2><a id="w3c-doctype" name="w3c-doctype" />W3C Working Draft
|
|
<i>26</i> <i>April</i> <i>2011</i></h2>
|
|
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2011/WD-scxml-20110426/">http://www.w3.org/TR/2011/WD-scxml-20110426/</a></dd>
|
|
|
|
<dt>Latest version:</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/scxml/">http://www.w3.org/TR/scxml/</a></dd>
|
|
|
|
<dt>Previous version:</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2010/WD-scxml-20101216/">http://www.w3.org/TR/2010/WD-scxml-20101216/</a></dd>
|
|
|
|
<dt>Editors:</dt>
|
|
|
|
<dd>Jim Barnett, Genesys (Editor-in-Chief)</dd>
|
|
|
|
<dd>Rahul Akolkar, IBM</dd>
|
|
|
|
<dd>RJ Auburn, Voxeo</dd>
|
|
|
|
<dd>Michael Bodell, Microsoft</dd>
|
|
|
|
<dd>Daniel C. Burnett, Voxeo</dd>
|
|
|
|
<dd>Jerry Carter, (until 2008, when at Nuance)</dd>
|
|
|
|
<dd>Scott McGlashan, HP</dd>
|
|
|
|
<dd>Torbjörn Lager, Invited Expert</dd>
|
|
|
|
<dd>Mark Helbing, (until 2006, when at Nuance)</dd>
|
|
|
|
<dd>Rafah Hosn, (until 2008, when at IBM)</dd>
|
|
|
|
<dd>T.V. Raman, (until 2005, when at IBM)</dd>
|
|
|
|
<dd>Klaus Reifenrath, (until 2006, when at Nuance)</dd>
|
|
|
|
<dd>No'am Rosenthal, (until 2009, when at Nokia)</dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
|
|
© 2011 <a href="http://www.w3.org/"><acronym
|
|
title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a
|
|
href="http://www.csail.mit.edu/"><acronym
|
|
title="Massachusetts Institute of Technology">MIT</acronym></a>, <a
|
|
href="http://www.ercim.eu/"><acronym
|
|
title="European Research Consortium for Informatics and Mathematics">
|
|
ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>),
|
|
All Rights Reserved. W3C <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">
|
|
liability</a>, <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">
|
|
trademark</a> and <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-documents">document
|
|
use</a> rules apply.</p>
|
|
</div>
|
|
|
|
<hr />
|
|
<div>
|
|
<h2><a id="abstract" name="abstract" />Abstract</h2>
|
|
|
|
<p>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.</p>
|
|
</div>
|
|
|
|
<div>
|
|
<h2><a id="status" name="status" />Status of this Document</h2>
|
|
|
|
<p><em>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 <a
|
|
href="http://www.w3.org/TR/">W3C technical reports index</a> at
|
|
http://www.w3.org/TR/.</em></p>
|
|
|
|
<p>This document is the ninth Public Working Draft of SCXML
|
|
published on 26 April 2010 for review by W3C Members and other
|
|
interested parties, and has been developed by the <a
|
|
href="http://www.w3.org/Voice/">Voice Browser Working Group</a> as
|
|
part of the W3C <a
|
|
href="http://www.w3.org/Voice/Activity.html">Voice Browser
|
|
Activity</a>. The main difference from the previous draft is
|
|
corrections to the interpretation algorithm. A <a
|
|
href="diff.html">diff-marked version</a> of this document is also
|
|
available for comparison purposes.</p>
|
|
|
|
<p>Comments for this specification are welcomed to <a
|
|
href="mailto:www-voice@w3.org">www-voice@w3.org</a> (<a
|
|
href="http://lists.w3.org/Archives/Public/www-voice/">archives</a>).</p>
|
|
|
|
<p>This document was produced by a group operating under the <a
|
|
href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5
|
|
February 2004 W3C Patent Policy</a>. W3C maintains a <a
|
|
href="http://www.w3.org/2004/01/pp-impl/34665/status">public list
|
|
of any patent disclosures</a> 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 <a
|
|
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">
|
|
Essential Claim(s)</a> must disclose the information in accordance
|
|
with <a
|
|
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">
|
|
section 6 of the W3C Patent Policy.</a></p>
|
|
|
|
<p>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.</p>
|
|
</div>
|
|
|
|
<div class="toc">
|
|
<h2><a id="contents" name="contents" />Table of Contents</h2>
|
|
|
|
<p class="toc">1 <a href="#terminology">Terminology</a><br />
|
|
2 <a href="#overview">Overview</a><br />
|
|
3 <a href="#Basic">Core Constructs</a><br />
|
|
3.1 <a
|
|
href="#CoreIntroduction">Introduction</a><br />
|
|
3.2 <a
|
|
href="#scxml"><scxml></a><br />
|
|
3.3 <a
|
|
href="#state"><state></a><br />
|
|
3.4 <a
|
|
href="#parallel"><parallel></a><br />
|
|
3.5 <a
|
|
href="#transition"><transition></a><br />
|
|
3.6 <a
|
|
href="#initial"><initial></a><br />
|
|
3.7 <a
|
|
href="#final"><final></a><br />
|
|
3.8 <a
|
|
href="#onentry"><onentry></a><br />
|
|
3.9 <a
|
|
href="#onexit"><onexit></a><br />
|
|
3.10 <a
|
|
href="#history"><history></a><br />
|
|
3.11 <a
|
|
href="#LegalStateConfigurations">Legal State Configurations and
|
|
Specifications</a><br />
|
|
3.12 <a href="#events">SCXML
|
|
Events</a><br />
|
|
3.13 <a
|
|
href="#SelectingTransitions">Selecting and Executing
|
|
Transitions</a><br />
|
|
3.14 <a href="#IDs">IDs</a><br />
|
|
4 <a href="#executable">Executable Content</a><br />
|
|
4.1 <a
|
|
href="#ExecutableIntroduction">Introduction</a><br />
|
|
4.2 <a
|
|
href="#raise"><raise></a><br />
|
|
4.3 <a href="#if"><if></a><br />
|
|
4.4 <a
|
|
href="#elseif"><elseif></a><br />
|
|
4.5 <a href="#else"><else></a><br />
|
|
4.6 <a
|
|
href="#foreach"><foreach></a><br />
|
|
4.7 <a href="#log"><log></a><br />
|
|
4.8 <a
|
|
href="#profile-dependentexecutablecontent">Other Executable
|
|
Content</a><br />
|
|
4.9 <a
|
|
href="#EvaluationofExecutableContent">Evaluation of Executable
|
|
Content</a><br />
|
|
4.10 <a href="#extensibility">Extensibility
|
|
of Executable Content</a><br />
|
|
5 <a href="#data-module">Data Model and Data Manipulation</a><br />
|
|
5.1 <a
|
|
href="#DataModelIntroduction">Introduction</a><br />
|
|
5.2 <a
|
|
href="#datamodel"><datamodel></a><br />
|
|
5.3 <a href="#data"><data></a><br />
|
|
5.4 <a
|
|
href="#assign"><assign></a><br />
|
|
5.5 <a
|
|
href="#validate"><validate></a><br />
|
|
5.6 <a
|
|
href="#donedata"><donedata></a><br />
|
|
5.7 <a
|
|
href="#content"><content></a><br />
|
|
5.8 <a
|
|
href="#param"><param></a><br />
|
|
5.9 <a
|
|
href="#script"><script></a><br />
|
|
5.10 <a
|
|
href="#Expressions">Expressions</a><br />
|
|
5.11 <a href="#SystemVariables">System
|
|
Variables</a><br />
|
|
6 <a href="#external-module">External Communications</a><br />
|
|
6.1 <a
|
|
href="#ExternalIntroduction">Introduction</a><br />
|
|
6.2 <a href="#send"><send></a><br />
|
|
6.3 <a
|
|
href="#cancel"><cancel></a><br />
|
|
6.4 <a
|
|
href="#invoke"><invoke></a><br />
|
|
6.5 <a
|
|
href="#finalize"><finalize></a><br />
|
|
</p>
|
|
|
|
<h3><a id="appendices" name="appendices" />Appendices</h3>
|
|
|
|
<p class="toc">A <a
|
|
href="#AlgorithmforSCXMLInterpretation">Algorithm for SCXML
|
|
Interpretation</a><br />
|
|
B <a href="#schemas">Schema</a><br />
|
|
C <a href="#conformance">Conformance</a><br />
|
|
C.1 <a
|
|
href="#ConformingDocuments">Conforming Documents</a><br />
|
|
C.2 <a
|
|
href="#ConformingProcessors">Conforming Processors</a><br />
|
|
D <a href="#profiles">Data Models</a><br />
|
|
D.1 <a href="#minimal-profile">The Null
|
|
Data Model</a><br />
|
|
D.2 <a href="#ecma-profile">The ECMAScript
|
|
Data Model</a><br />
|
|
D.3 <a href="#xpath-profile">The XPath Data
|
|
Model</a><br />
|
|
E <a href="#eventioprocessors">Event I/O Processors</a><br />
|
|
E.1 <a href="#SCXMLEventProcessor">SCXML
|
|
Event I/O Processor</a><br />
|
|
E.2 <a
|
|
href="#BasicHTTPEventProcessor">Basic HTTP Event I/O
|
|
Processor</a><br />
|
|
E.3 <a href="#DOMEventProcessor">DOM Event
|
|
I/O Processor</a><br />
|
|
F <a href="#relatedWork">Related Work</a><br />
|
|
G <a href="#Examples">Examples</a><br />
|
|
G.1 <a href="#N1181C">Language
|
|
Overview</a><br />
|
|
G.2 <a href="#N1182D">Microwave
|
|
Example</a><br />
|
|
G.3 <a href="#MicrowaveParallel">Microwave
|
|
Example (Using parallel)</a><br />
|
|
G.4 <a href="#N11844">Calculator
|
|
Example</a><br />
|
|
G.5 <a href="#N1184F">Shale
|
|
Example</a><br />
|
|
G.6 <a href="#invokeex">Examples of Invoke
|
|
and finalize</a><br />
|
|
G.7 <a
|
|
href="#content_and_namespaces">Inline Content and
|
|
Namespaces</a><br />
|
|
G.8 <a href="#custom_action">Custom Action
|
|
Elements</a><br />
|
|
H <a href="#references">References</a><br />
|
|
</p>
|
|
</div>
|
|
|
|
<hr />
|
|
<div class="body">
|
|
<div class="div1">
|
|
<h2><a id="terminology" name="terminology" />1 Terminology</h2>
|
|
|
|
<p>The key words <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em>, <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em>, <em
|
|
title="REQUIRED in RFC2119 context" class="RFC2119">REQUIRED</em>,
|
|
<em title="SHALL in RFC2119 context" class="RFC2119">SHALL</em>,
|
|
<em title="SHALL NOT in RFC2119 context" class="RFC2119">SHALL
|
|
NOT</em>, <em title="SHOULD in RFC2119 context"
|
|
class="RFC2119">SHOULD</em>, <em
|
|
title="SHOULD NOT in RFC2119 context" class="RFC2119">SHOULD
|
|
NOT</em>, <em title="RECOMMENDED in RFC2119 context"
|
|
class="RFC2119">RECOMMENDED</em>, <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em>, and <em
|
|
title="OPTIONAL in RFC2119 context" class="RFC2119">OPTIONAL</em>
|
|
in this specification are to be interpreted as described in <a
|
|
href="#RFC2119">[IETF RFC 2119]</a>.</p>
|
|
|
|
<p>The terms base URI and relative URI are used in this
|
|
specification as they are defined in <a href="#RFC2396">[IETF RFC
|
|
2396]</a>.</p>
|
|
|
|
<p>All sections not marked as "informative" are normative.</p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="overview" name="overview" />2 Overview</h2>
|
|
|
|
<p>[This section is informative.]</p>
|
|
|
|
<p>This document outlines State Chart XML (SCXML), which is a
|
|
general-purpose event-based state machine language that combines
|
|
concepts from CCXML and Harel State Tables. CCXML <a
|
|
href="#CCXML">[W3C CCXML 1.0]</a> 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 <a
|
|
href="#Harel_Politi">[Harel and Politi]</a> and is included in UML
|
|
<a href="#UML">[UML 2.3]</a>. 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.</p>
|
|
|
|
<p><a href="#Basic"><b>3 Core Constructs</b></a> presents the core
|
|
state machine concepts, while <a href="#executable"><b>4 Executable
|
|
Content</b></a> contains an extensible set of actions that the
|
|
state machine can take in response to events. <a
|
|
href="#data-module"><b>5 Data Model and Data Manipulation</b></a>
|
|
defines constructs for storing and modifying data, while <a
|
|
href="#external-module"><b>6 External Communications</b></a>
|
|
provides the capability of communicating with external
|
|
entities.</p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="Basic" name="Basic" />3 Core Constructs</h2>
|
|
|
|
<div class="div2">
|
|
<h3><a id="CoreIntroduction" name="CoreIntroduction" />3.1
|
|
Introduction</h3>
|
|
|
|
<p>[This section is informative.]</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="BasicState" name="BasicState" />3.1.1 Basic State
|
|
Machine Notation</h4>
|
|
|
|
<p>The most basic state machine concepts are <a
|
|
href="#state"><b>3.3 <state></b></a>, <a
|
|
href="#transition"><b>3.5 <transition></b></a> and event (<a
|
|
href="#events"><b>3.12 SCXML Events</b></a>). Each state contains a
|
|
set of transitions that define how it reacts to events. Events can
|
|
be generated by the state machine itself or by external entities.
|
|
In a traditional state machine, the machine is always in a single
|
|
state. This state is called the active state. When an event occurs,
|
|
the state machine checks the transitions that are defined in the
|
|
active state. If it finds one that matches the event, it moves from
|
|
the active state to the state specified by the transition (called
|
|
the "target" of the transition.) Thus the target state becomes the
|
|
new active state.</p>
|
|
|
|
<p>The Harel state notation defines several extensions to these
|
|
basic notions. First of all, the state machine may take actions (as
|
|
defined in <a href="#executable"><b>4 Executable Content</b></a>)
|
|
while taking transitions. Specifically, each state may contain <a
|
|
href="#onentry"><b>3.8 <onentry></b></a> and <a
|
|
href="#onexit"><b>3.9 <onexit></b></a> actions. Transitions
|
|
may also contain actions. If a state machine takes transition T
|
|
from state S1 to state S2, it first performs the onexit actions in
|
|
S1, then the actions in T, then the onentry actions in S2.
|
|
Secondly, in addition to the 'event' attribute that specifies the
|
|
event(s) that can trigger it, transitions also have a 'cond'
|
|
attribute. If a transition has both 'event' and 'cond' attributes,
|
|
it will be selected only if an event is raised whose name matches
|
|
the 'event' attribute (see <a href="#EventDescriptors"><b>3.12.1
|
|
Event Descriptors</b></a> for details) and the 'cond' condition
|
|
evaluates to true. If the 'event' attribute is missing, the
|
|
transition is taken whenever the 'cond' evaluates to true. If more
|
|
than one transition matches, the first one in document order will
|
|
be taken. Thus, in the following example, the system will
|
|
transition to s1 when event e (or e.foo, etc.) occurs if x is equal
|
|
to 1, but will transition to s2 if event e (or e.foo, etc.) occurs
|
|
and x is not equal to 1, and will go to s3 if any other event
|
|
occurs.</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<state id=s">
|
|
<transition event="e" cond="x==1" target="s1"/>
|
|
<transition event="e" target="s2"/>
|
|
<transition event="*" target="s3"/>
|
|
</state>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>The data model can be changed only by the execution of
|
|
<invoke> or executable content. Therefore transitions with
|
|
missing 'event' attributes need be checked only after a transition
|
|
has been taken. See <a href="#AlgorithmforSCXMLInterpretation"><b>A
|
|
Algorithm for SCXML Interpretation</b></a> for details.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10153" name="N10153" />3.1.2 Compound States</h4>
|
|
|
|
<p>One of the most powerful concepts in Harel notation is the idea
|
|
that states may have internal structure. In particular, a
|
|
<state> element may contain nested <state> elements.
|
|
Such a state is called a compound state and we speak of it as the
|
|
parent state, while the nested elements are child states. The child
|
|
states may themselves have nested children and the nesting may
|
|
proceed to any depth. Ultimately we will reach a state that does
|
|
not contain any child states. Such a state is called an atomic
|
|
state. When a compound state is active, one and only one of its
|
|
child states is active. Conversely, when an child state is active,
|
|
its parent state must be active too. Thus at any point we have a
|
|
set of active states, containing an atomic state and all of its
|
|
ancestors. (We will see in the next section that multiple atomic
|
|
states can be active at the same time.)</p>
|
|
|
|
<div class="div4">
|
|
<h5><a id="N10158" name="N10158" />3.1.2.1 Initial, Final, and
|
|
History States</h5>
|
|
|
|
<p>In the presence of compound states, transitions no longer simply
|
|
move from the current active state to a new active state, but from
|
|
one set of active states to another. (See <a
|
|
href="#LegalStateConfigurations"><b>3.11 Legal State Configurations
|
|
and Specifications</b></a> for details.) If the target of a
|
|
transition is an atomic state, the state machine will enter not
|
|
only the atomic state, but also any of its ancestor states that are
|
|
not already active. Conversely, a transition may take a compound
|
|
state as its target. In this case, one of the compound state's
|
|
children must also become active, but the transition does not
|
|
specify which one. In this case we look at the target state's <a
|
|
href="#initial"><b>3.6 <initial></b></a> child which
|
|
specifies the state's default initial state, that is, the child
|
|
state to enter if the transition does not specify one. (If the
|
|
default initial state is itself compound, the state machine will
|
|
also enter its default initial state, and so on recursively until
|
|
it reaches an atomic state.) The presence of default initial states
|
|
provides a form of encapsulation, since a transition may select a
|
|
compound state as its target without understanding its internal
|
|
substate structure.</p>
|
|
|
|
<p>The default initial state of a compound state may also be
|
|
specified via the 'initial' attribute. 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. (If neither the
|
|
<initial> child or the 'initial' element is specified, the
|
|
default initial state is the first child state in document order.)
|
|
As an example, suppose that parent state S contains child states S1
|
|
and S2 in that order. If S specifies S1 as its default initial
|
|
state via the 'initial' attribute (or fails to specify any initial
|
|
state), then any transition that specifies S as its target will
|
|
result in the state machine entering S1 as well as S. In this case,
|
|
the result is exactly the same as if the transition had taken S1 as
|
|
its target. If, on the other hand, S specifies S1 as its default
|
|
initial state via an <initial> element 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.</p>
|
|
|
|
<p>A compound state may also have final and history states as
|
|
children. <a href="#final"><b>3.7 <final></b></a> is used to
|
|
signify that the parent state is in some sense "done" with its
|
|
processing. When a state machine enters a <final> substate of
|
|
a compound state, the parent state remains active, but the event
|
|
"done.state.<em>id</em>" is generated, where <em>id</em> is the
|
|
state id of the parent state. This event can trigger a transition
|
|
in any ancestor state (including the parent). If the transition
|
|
takes a target outside the parent state, the
|
|
"done.state.<em>id</em>" event in effect serves as a signal that it
|
|
is time to leave the parent state. <a href="#history"><b>3.10
|
|
<history></b></a> allows for pause and resume semantics in
|
|
compound states. Before the state machine exits a compound state,
|
|
it records the state's active descendents. If the 'type' attribute
|
|
of the <history> state is set to "deep", the state machine
|
|
saves the state's full active descendent configuration, down to the
|
|
atomic descendant(s). If 'type' is set to "shallow", the state
|
|
machine remembers only which immediate child was active. After
|
|
that, if a transition takes a <history> child of the state as
|
|
its target, the state machine re-enters not only the parent
|
|
compound state but also the state(s) in the saved configuration.
|
|
Thus a transition with a deep history state as its target returns
|
|
to exactly where the state was when it was last exited, while a
|
|
transition with a shallow history state as a target re-enters the
|
|
previously active child state, but will enter the child's default
|
|
initial state (if the child is itself compound.)</p>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a id="N10176" name="N10176" />3.1.2.2 Compound States and
|
|
Transitions</h5>
|
|
|
|
<p>Compound states also affect how transitions are selected. When
|
|
looking for transitions, the state machine first looks in the most
|
|
deeply nested active state(s), i.e., in the atomic state(s) that
|
|
have no substates. If no transitions match in the atomic state, the
|
|
state machine will look in its parent state, then in the parent's
|
|
parent, etc. Thus transitions in ancestor states serve as defaults
|
|
that will be taken if no transition matches in a descendant state.
|
|
If no transition matches in any state, the event is discarded.</p>
|
|
|
|
<p>In the case of a transition located in a compound state, the
|
|
'type' attribute is significant. The behavior of a transition with
|
|
'type' of "external" (the default) is defined in terms of the
|
|
transition's source state (which is the state that contains the
|
|
transition), the transition's target state(or states), and the <a
|
|
href="#LCA">Least Common Ancestor (LCA)</a> of the source and
|
|
target states (which is the closest state that is an ancestor of
|
|
all the source and target states). When a transition is taken, the
|
|
state machine will exit all active states that are proper
|
|
descendants of the LCA, 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. If the target state(s) of the transition is not
|
|
atomic, the state machine will enter their default initial states
|
|
recursively until it reaches an atomic state(s).</p>
|
|
|
|
<p>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 s2 is entered,
|
|
then state s21. Note that the LCA S is neither entered nor exited.
|
|
For more details see <a href="#SelectingTransitions"><b>3.13
|
|
Selecting and Executing Transitions</b></a> and <a
|
|
href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm for SCXML
|
|
Interpretation</b></a>.</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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
|
|
</pre>
|
|
</div>
|
|
|
|
<p>The behavior of transitions with 'type' of "internal" is
|
|
identical, except in the case of a transition whose source state is
|
|
a compound state and whose target(s) is a descendant of the source.
|
|
In such a case, an internal transition will not exit and re-enter
|
|
its source state, while an external one will, as shown in the
|
|
example below.</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<state id="S" initial="s1">
|
|
<state id="s1" initial="s11">
|
|
<onentry>
|
|
<log expr="entering S1"/>
|
|
</onentry>
|
|
<onexit>
|
|
<log expr="'leaving s1'"/>
|
|
</onexit>
|
|
|
|
<state id="s11">
|
|
<onentry>
|
|
<log expr="entering s11"/>
|
|
</onentry>
|
|
<onexit>
|
|
<log expr="'leaving s11'"/>
|
|
</onexit>
|
|
</state>
|
|
|
|
<transition event="e" target="s11" type="internal">
|
|
<log expr="'executing transition'"/>
|
|
</transition>
|
|
|
|
</state>
|
|
|
|
|
|
|
|
==== log output will be ======>
|
|
|
|
leaving s11
|
|
executing transition
|
|
entering s11
|
|
|
|
=== if transition were external, log output would be ====>
|
|
|
|
leaving s11
|
|
leaving s1
|
|
executing transition
|
|
entering s1
|
|
entering s11
|
|
|
|
</pre>
|
|
</div>
|
|
|
|
<p>If the 'target' on a <transition> is omitted, then the
|
|
value of 'type' does not have any effect and taking the transition
|
|
does not change the state configuration but does invoke the
|
|
executable content that is included in the transition. Note that
|
|
this is different from a <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.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10193" name="N10193" />3.1.3 Parallel States</h4>
|
|
|
|
<p>The <parallel> element represents a state whose children
|
|
execute in parallel. Like <state>, the <parallel>
|
|
element contains <onentry>, <onexit>,
|
|
<transition>, and <state> or <parallel> children.
|
|
However, the semantics of <parallel> are different. When a
|
|
<state> is active, exactly one of its children is active.
|
|
When a <parallel> element is active, <em>all</em> of its
|
|
children are active. Specifically, when the state machine enters
|
|
the parent <parallel> state, it also enters each child state.
|
|
The child states execute in parallel in the sense that any event
|
|
that is processed is processed in each child state independently,
|
|
and each child state may take a different transition in response to
|
|
the event. (Similarly, one child state may take a transition in
|
|
reponse to an event, while another child ignores it.) When all of
|
|
the children reach final states, the <parallel> element
|
|
itself is considered to be in a final state, and a completion event
|
|
done.state.<em>id</em> is generated, where <em>id</em> is the id of
|
|
the <parallel> element.</p>
|
|
|
|
<p>Transitions <em>within</em> the individual child elements
|
|
operate normally. However whenever a transition is taken with a
|
|
target <em>outside</em> the <parallel> element, 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.</p>
|
|
|
|
<p>In the following example, parallel state 'p' has two children S1
|
|
and S2. Suppose a transition takes S1's child S12 as a target.
|
|
(Note that this is permitted even though S12 is not the default
|
|
initial state for S1 and that S11 is not, in fact, visited in the
|
|
course of this example). Upon this transition, the state machine,
|
|
in addition to enterering S1 and S12, will also enter S1's parallel
|
|
sibling S2 and its initial state S21. Once the transition has been
|
|
taken, p, S1, S2, S12, and S21 will all be active. If event 'e1'
|
|
occurs, it will cause S12 to transition to S1Final, and S21 to
|
|
transition to S22. Entering S1Final will cause the event
|
|
done.state.S1 to be generated. At this point, S1 is in a final
|
|
state, but S2 is still active. Now suppose event 'e2' occurs. This
|
|
will cause S22 to transition to S2Final, and the event
|
|
done.state.S2 will be generated. Furthermore, since all of p's
|
|
children are now in final states, the event 'done.state.p' will be
|
|
generated, which will cause the transition contained in p to be
|
|
triggered, exiting the entire region.</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<parallel id="p">
|
|
|
|
<transition event="done.state.p" target="someOtherState"/>
|
|
|
|
<state id="S1" initial="S11">
|
|
<state id="S11">
|
|
<transition event="e4" target="S12"/>
|
|
</state>
|
|
<state id="S12">
|
|
<transition event="e1" target="S1Final"/>
|
|
</state>
|
|
<final id="S1Final"/>
|
|
</state>
|
|
|
|
<state id="S2" initial="S21">
|
|
<state id=S21">
|
|
<transition event="e1" target="S22"/>
|
|
</state>
|
|
<state id="S22">
|
|
<transition event="e2" target="S2Final/>
|
|
</state>
|
|
<final id="S2Final"/>
|
|
</state>
|
|
|
|
</parallel>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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. However, the parallel
|
|
children process the event in a defined, serial order, so no
|
|
conflicts or race conditions can occur. See <a
|
|
href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm for SCXML
|
|
Interpretation</b></a> for a detailed description of the semantics
|
|
<parallel> and the rest of SCXML.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="scxml" name="scxml" />3.2 <scxml></h3>
|
|
|
|
<p>The top-level wrapper element, which carries version
|
|
information. The actual state machine consists of its children.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="scxml-attr" name="scxml-attr" />3.2.1 Attribute
|
|
Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>initial</td>
|
|
<td>false</td>
|
|
<td>none</td>
|
|
<td>IDREFS</td>
|
|
<td>none</td>
|
|
<td>A legal state specification. See <a
|
|
href="#LegalStateConfigurations"><b>3.11 Legal State Configurations
|
|
and Specifications</b></a> for details.</td>
|
|
<td>The id of the initial state(s) for the document. If not
|
|
specified, the default initial state is the first child state in
|
|
document order.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>name</td>
|
|
<td>false</td>
|
|
<td>none</td>
|
|
<td>NMTOKEN</td>
|
|
<td>none</td>
|
|
<td>Any valid NMTOKEN</td>
|
|
<td>The name of this state machine. It is for purely informational
|
|
purposes.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>xmlns</td>
|
|
<td>true</td>
|
|
<td>none</td>
|
|
<td>URI</td>
|
|
<td>none</td>
|
|
<td>The value must be "http://www.w3.org/2005/07/scxml".</td>
|
|
<td></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>version</td>
|
|
<td>true</td>
|
|
<td>none</td>
|
|
<td>decimal</td>
|
|
<td>none</td>
|
|
<td>The only legal value is "1.0"</td>
|
|
<td></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>datamodel</td>
|
|
<td>false</td>
|
|
<td>none</td>
|
|
<td>NMTOKEN</td>
|
|
<td>"none"</td>
|
|
<td>"none", "ecmascript", "xpath" or other platform-defined
|
|
values.</td>
|
|
<td>The datamodel that this document requires. "none" denotes the
|
|
Empty datamodel, "ecmascript" the ECMAScript datamodel, and "xpath"
|
|
the XPath datamodel, as defined in <a href="#profiles"><b>D Data
|
|
Models</b></a>.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>binding</td>
|
|
<td>false</td>
|
|
<td />
|
|
<td>enum</td>
|
|
<td>"early"</td>
|
|
<td>"early", "late"</td>
|
|
<td>The data binding to use. See <a href="#DataBinding"><b>5.3.3
|
|
Data Binding and Scoping</b></a> for details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>exmode</td>
|
|
<td>false</td>
|
|
<td />
|
|
<td>enum</td>
|
|
<td>"lax"</td>
|
|
<td>"lax", "strict"</td>
|
|
<td>Determines whether the processor should silently ignore markup
|
|
that it does not support.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10242" name="N10242" />3.2.2 Children</h4>
|
|
|
|
<ul>
|
|
<li><state> A compound or atomic state. Occurs zero or more
|
|
times. See <a href="#state"><b>3.3 <state></b></a> for
|
|
details.</li>
|
|
|
|
<li><parallel> A parallel state. Occurs zero or more times.
|
|
See <a href="#parallel"><b>3.4 <parallel></b></a> for
|
|
details.</li>
|
|
|
|
<li><final> A top-level final state in the state machine.
|
|
Occurs zero or more times. The SCXML processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> terminate
|
|
processing when the state machine reaches this state. See <a
|
|
href="#final"><b>3.7 <final></b></a> for details.</li>
|
|
|
|
<li><datamodel> Defines part or all of the datamodel. Occurs
|
|
0 or 1 times. See <a href="#datamodel"><b>5.2
|
|
<datamodel></b></a></li>
|
|
|
|
<li><script> Provides scripting capability. Occurs 0 or 1
|
|
times. <a href="#script"><b>5.9 <script></b></a></li>
|
|
</ul>
|
|
</div>
|
|
|
|
<p>If 'exmode' is "lax", the SCXML processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> silently
|
|
ignore any markup that it does not support, including markup in
|
|
non-scxml namespaces. (Examples of unsupported elements include
|
|
elements that are not part of the specified data model or
|
|
executable content that some other platform has defined as an
|
|
extension.) If 'exmode' is "strict", the SCXML processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> treat
|
|
such markup as syntactically invalid and reject the document at
|
|
initialization time.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="state" name="state" />3.3 <state></h3>
|
|
|
|
<p>Holds the representation of a state.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10273" name="N10273" />3.3.1 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>id</td>
|
|
<td>false</td>
|
|
<td>none</td>
|
|
<td>ID</td>
|
|
<td>none</td>
|
|
<td>A valid id as defined in <a href="#Schema">[XML
|
|
Schema]</a></td>
|
|
<td>The identifier for this state. See <a href="#IDs"><b>3.14
|
|
IDs</b></a> for details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>initial</td>
|
|
<td>false</td>
|
|
<td>May not be specified in conjunction with the <initial>
|
|
element. May only occur in states that have child <state> or
|
|
<parallel> elements.</td>
|
|
<td>IDREFS</td>
|
|
<td>none</td>
|
|
<td>A legal state specification. See <a
|
|
href="#LegalStateConfigurations"><b>3.11 Legal State Configurations
|
|
and Specifications</b></a> for details.</td>
|
|
<td>The id of the default initial state (or states) for this
|
|
state.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N102B0" name="N102B0" />3.3.2 Children</h4>
|
|
|
|
<ul>
|
|
<li><onentry> Optional element holding executable content to
|
|
be run upon entering this <state>. Occurs 0 or more times.
|
|
See <a href="#onentry"><b>3.8 <onentry></b></a></li>
|
|
|
|
<li><onexit> Optional element holding executable content to
|
|
be run when exiting this <state>. Occurs 0 or more times. See
|
|
<a href="#onexit"><b>3.9 <onexit></b></a></li>
|
|
|
|
<li><transition> Defines an outgoing transition from this
|
|
state. Occurs 0 or more times. See <a href="#transition"><b>3.5
|
|
<transition></b></a></li>
|
|
|
|
<li><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 <a href="#initial"><b>3.6
|
|
<initial></b></a></li>
|
|
|
|
<li><state> Defines a sequential substate of the parent
|
|
state. Occurs 0 or more times.</li>
|
|
|
|
<li><parallel> Defines a parallel substate. Occurs 0 or more
|
|
times. See <a href="#parallel"><b>3.4 <parallel></b></a></li>
|
|
|
|
<li><final>. Defines a final substate. Occurs 0 or more
|
|
times. See <a href="#final"><b>3.7 <final></b></a>.</li>
|
|
|
|
<li><history> A child pseudo-state which records the
|
|
descendant state(s) that the parent state was in the last time the
|
|
system transitioned <em>from</em> the parent. May occur 0 or more
|
|
times. See <a href="#history"><b>3.10 <history></b></a>.</li>
|
|
|
|
<li><datamodel> Defines part or all of the datamodel. Occurs
|
|
0 or 1 times. See <a href="#datamodel"><b>5.2
|
|
<datamodel></b></a></li>
|
|
|
|
<li><invoke> Invokes an external service. Occurs 0 or more
|
|
times. See <a href="#invoke"><b>6.4 <invoke></b></a> for
|
|
details.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<p>[<a title="" id="atomic-state"
|
|
name="atomic-state">Definition</a>: An <b>atomic state</b> is one
|
|
that has no <state> or <parallel> children.]</p>
|
|
|
|
<p>[<a title="" id="compound-state"
|
|
name="compound-state">Definition</a>: A <b>compound state</b> is
|
|
one that has <state>, <parallel>, or <final>
|
|
children (or a combination of these).]</p>
|
|
|
|
<p>In a conformant SCXML document, a compound state <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> specify
|
|
either an "initial" attribute or an <initial> element, but
|
|
not both. See <a href="#initial"><b>3.6 <initial></b></a> 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.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="parallel" name="parallel" />3.4 <parallel></h3>
|
|
|
|
<p>The <parallel> element encapsulates a set of child states
|
|
which are simultaneously active when the parent element is
|
|
active.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N1030B" name="N1030B" />3.4.1 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>id</td>
|
|
<td>false</td>
|
|
<td />
|
|
<td>ID</td>
|
|
<td>none</td>
|
|
<td>A valid id as defined in <a href="#Schema">[XML Schema]</a>
|
|
</td>
|
|
<td>The identifier for this state. See <a href="#IDs"><b>3.14
|
|
IDs</b></a> for details.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10337" name="N10337" />3.4.2 Children</h4>
|
|
|
|
<ul>
|
|
<li><onentry> Holds executable content to be run upon
|
|
entering the <parallel> element. Occurs 0 or more times. See
|
|
<a href="#onentry"><b>3.8 <onentry></b></a></li>
|
|
|
|
<li><onexit> Holds executable content to be run when exiting
|
|
this element. Occurs 0 or more times. See <a href="#onexit"><b>3.9
|
|
<onexit></b></a></li>
|
|
|
|
<li><transition> Defines an outgoing transition from this
|
|
state. Occurs 0 or more times. See <a href="#transition"><b>3.5
|
|
<transition></b></a></li>
|
|
|
|
<li><state> Defines a parallel substate region. Occurs 0 or
|
|
more times. See <a href="#state"><b>3.3 <state></b></a>.</li>
|
|
|
|
<li><parallel> Defines a nested set of parallel regions.
|
|
Occurs 0 or more times.</li>
|
|
|
|
<li><history> A child which represents the state
|
|
configuration that this state was in the last time the system
|
|
transitioned <em>from</em> 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 <a href="#history"><b>3.10
|
|
<history></b></a>.</li>
|
|
|
|
<li><datamodel> Defines part or all of the datamodel. Occurs
|
|
0 or 1 times. See <a href="#datamodel"><b>5.2
|
|
<datamodel></b></a></li>
|
|
|
|
<li><invoke> Invokes an external service. Occurs 0 or more
|
|
times. See <a href="#invoke"><b>6.4 <invoke></b></a> for
|
|
details.</li>
|
|
</ul>
|
|
|
|
<p>A conformant SCXML document <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
contain any transitions between parallel siblings. Specifically, if
|
|
states Si and Sj are children of a <parallel> element, no
|
|
transition may have Si (or a descendant of Si) as its source and Sj
|
|
(or a descendent of Sj) as its target.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="transition" name="transition" />3.5
|
|
<transition></h3>
|
|
|
|
<p>Transitions between states are triggered by events and
|
|
conditionalized via guard conditions. They may contain executable
|
|
content, which is executed when the transition is taken.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10373" name="N10373" />3.5.1 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>event</td>
|
|
<td>false</td>
|
|
<td>At least one of 'event', 'cond' or 'target' must be
|
|
specified.</td>
|
|
<td>EventsTypes.datatype.</td>
|
|
<td>none</td>
|
|
<td>A space-separated list of event descriptors. See <a
|
|
href="#EventDescriptors"><b>3.12.1 Event Descriptors</b></a> for
|
|
details.</td>
|
|
<td>A list of designators of events that trigger this transition.
|
|
The transition will be taken only when an event is generated that
|
|
matches a descriptor on this list (see <a
|
|
href="#EventDescriptors"><b>3.12.1 Event Descriptors</b></a> for
|
|
details.) Also see <a href="#SelectingTransitions"><b>3.13
|
|
Selecting and Executing Transitions</b></a> and <a
|
|
href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm for SCXML
|
|
Interpretation</b></a> for details on how transitions are selected.
|
|
See <a href="#schemas"><b>B Schema</b></a> for the definition of
|
|
the datatype.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>cond</td>
|
|
<td>false</td>
|
|
<td>At least one of 'event', 'cond' or 'target' must be
|
|
specified.</td>
|
|
<td>Boolean expression</td>
|
|
<td>'true'</td>
|
|
<td>Any boolean expression.</td>
|
|
<td>The guard condition for this transition. The transition is
|
|
selected only if the condition evaluates to <code>true</code>. See
|
|
<a href="#ConditionalExpressions"><b>5.10.1 Conditional
|
|
Expressions</b></a> for details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>target</td>
|
|
<td>false</td>
|
|
<td>At least one of 'event', 'cond' or 'target' must be
|
|
specified.</td>
|
|
<td>IDREFS</td>
|
|
<td>none</td>
|
|
<td>A legal state specification. See <a
|
|
href="#LegalStateConfigurations"><b>3.11 Legal State Configurations
|
|
and Specifications</b></a> for details.</td>
|
|
<td>The identifier(s) of the state or parallel region to transition
|
|
to. See <a href="#SelectingTransitions"><b>3.13 Selecting and
|
|
Executing Transitions</b></a> and <a
|
|
href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm for SCXML
|
|
Interpretation</b></a> for details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>type</td>
|
|
<td>false</td>
|
|
<td>None</td>
|
|
<td>enum</td>
|
|
<td>"external"</td>
|
|
<td>"internal" "external"</td>
|
|
<td>Determines whether the source state is exited in transitions
|
|
whose target state is a descendant of the source state. See <a
|
|
href="#SelectingTransitions"><b>3.13 Selecting and Executing
|
|
Transitions</b></a> for details.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N103E7" name="N103E7" />3.5.2 Children</h4>
|
|
|
|
<ul>
|
|
<li>The children of <transition> are executable content that
|
|
is run after all the <onexit> handlers and before the all
|
|
<onentry> handlers that are triggered by this transition. See
|
|
<a href="#executable"><b>4 Executable Content</b></a></li>
|
|
</ul>
|
|
</div>
|
|
|
|
<p><a href="#SelectingTransitions"><b>3.13 Selecting and Executing
|
|
Transitions</b></a> contains more detail on the semantics of
|
|
transitions.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="initial" name="initial" />3.6 <initial></h3>
|
|
|
|
<p>This element represents the default initial state for a complex
|
|
<state> element (i.e. one one containing child <state>
|
|
or <parallel> elements.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N103FB" name="N103FB" />3.6.1 Attribute Details</h4>
|
|
|
|
<p>None</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10400" name="N10400" />3.6.2 Children</h4>
|
|
|
|
<ul>
|
|
<li><transition> A transition whose 'target' specifies the
|
|
default initial state(s). In a conformant SCXML document, this
|
|
transition <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em> contain 'cond' or 'event' attributes,
|
|
and <em title="MUST in RFC2119 context" class="RFC2119">MUST</em>
|
|
specify a non-null 'target' whose value is a valid state
|
|
specification (see <a href="#LegalStateConfigurations"><b>3.11
|
|
Legal State Configurations and Specifications</b></a> for details).
|
|
This transition <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> contain executable content.</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="final" name="final" />3.7 <final></h3>
|
|
|
|
<p><final> represents a final state of an <scxml> or
|
|
compound <state> element.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10419" name="N10419" />3.7.1 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>id</td>
|
|
<td>false</td>
|
|
<td />
|
|
<td>ID</td>
|
|
<td>none</td>
|
|
<td>A valid id as defined in <a href="#Schema">[XML
|
|
Schema]</a></td>
|
|
<td>The identifier for this state. See <a href="#IDs"><b>3.14
|
|
IDs</b></a> for details.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10444" name="N10444" />3.7.2 Children</h4>
|
|
|
|
<ul>
|
|
<li><onentry> Optional element holding executable content to
|
|
be run upon entering this state. Occurs 0 or 1 times. See <a
|
|
href="#onentry"><b>3.8 <onentry></b></a> for details.</li>
|
|
|
|
<li><onexit> Optional element holding executable content to
|
|
be run when exiting this state. Occurs 0 or 1 times. See <a
|
|
href="#onexit"><b>3.9 <onexit></b></a> for details.</li>
|
|
|
|
<li><donedata> Optional element specifying data to be
|
|
included in the done.state.<em>id</em> or done.invoke.<em>id</em>
|
|
event. See <a href="#donedata"><b>5.6 <donedata></b></a> for
|
|
details.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<p>When the state machine enters the <final> child of a
|
|
<state> element, the SCXML processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> after
|
|
generate the event done.state.<em>id</em> after completion of the
|
|
<onentry> elements, where <em>id</em> is the id of the parent
|
|
state. When the state machine reaches the <final> child of an
|
|
<scxml> element, it <em title=" MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> terminate. See <a
|
|
href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm for SCXML
|
|
Interpretation</b></a> for details. If the SCXML session was
|
|
triggered as the result by an <invoke> element in another
|
|
session, the SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> generate the event
|
|
done.invoke.<em>id</em> after termination and return it to the
|
|
other session, where <em>id</em> is the unique identifier generated
|
|
when the <invoke> element was executed. See <a
|
|
href="#invoke"><b>6.4 <invoke></b></a> for details.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="onentry" name="onentry" />3.8 <onentry></h3>
|
|
|
|
<p>A wrapper element containing executable content to be executed
|
|
when the state is entered.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10483" name="N10483" />3.8.1 Attribute Details</h4>
|
|
|
|
<p>None.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10488" name="N10488" />3.8.2 Children</h4>
|
|
|
|
<p>The children of the <onentry> handler consist of
|
|
executable content as defined in <a href="#executable"><b>4
|
|
Executable Content</b></a>.</p>
|
|
</div>
|
|
|
|
<p>The SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> execute the <onentry> handlers of a
|
|
state in document order when the state is entered. In doing so, it
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> treat
|
|
each handler as a separate block of executable content. See <a
|
|
href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm for SCXML
|
|
Interpretation</b></a> for details.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="onexit" name="onexit" />3.9 <onexit></h3>
|
|
|
|
<p>A wrapper element containing executable content to be executed
|
|
when the state is exited.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N104A1" name="N104A1" />3.9.1 Attribute Details</h4>
|
|
|
|
<p>None.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N104A6" name="N104A6" />3.9.2 Children</h4>
|
|
|
|
<p>The children of the <onexit> handler consist of executable
|
|
content as defined in <a href="#executable"><b>4 Executable
|
|
Content</b></a>.</p>
|
|
</div>
|
|
|
|
<p>The SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> execute the <onexit> handlers of a
|
|
state in document order when the state is exited. In doing so, it
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> treat
|
|
each handler as a separate block of executable content. See <a
|
|
href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm for SCXML
|
|
Interpretation</b></a> for details.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="history" name="history" />3.10 <history></h3>
|
|
|
|
<p>The <history> pseudo-state allows allows a state machine
|
|
to remember its state configuration. A <transition> taking
|
|
the <history> state as its target will return the state
|
|
machine to this recorded configuration.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N104BF" name="N104BF" />3.10.1 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>id</td>
|
|
<td>false</td>
|
|
<td />
|
|
<td>ID</td>
|
|
<td>none</td>
|
|
<td>A valid id as defined in <a href="#Schema">[XML
|
|
Schema]</a></td>
|
|
<td>Identifier for this pseudo-state. See <a href="#IDs"><b>3.14
|
|
IDs</b></a> for details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>type</td>
|
|
<td>false</td>
|
|
<td />
|
|
<td>enum</td>
|
|
<td>"shallow"</td>
|
|
<td>"deep" or "shallow"</td>
|
|
<td>Determines whether the active atomic substate(s) of the current
|
|
state or only its immediate active substate(s) are recorded.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N104F8" name="N104F8" />3.10.2 Children</h4>
|
|
|
|
<ul>
|
|
<li><transition> A transition whose 'target' specifies the
|
|
default history configuration. In a conformant SCXML document, this
|
|
transition <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em> contain 'cond' or 'event' attributes,
|
|
and <em title="MUST in RFC2119 context" class="RFC2119">MUST</em>
|
|
specify a non-null 'target' whose value is a valid state
|
|
specification (see <a href="#LegalStateConfigurations"><b>3.11
|
|
Legal State Configurations and Specifications</b></a>). This
|
|
transition <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> contain executable content. If 'type' is
|
|
"shallow", then the 'target' of this <transition> <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> contain
|
|
only immediate children of the parent state. Otherwise it <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> contain
|
|
only atomic descendants of the parent. Occurs once. (Note that
|
|
under the definition of a legal state specification, if the parent
|
|
of the history element is <state> and the default state
|
|
specification contains a multiple states, then, in a conformant
|
|
SCXML document, the 'type' of the history element <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> be "deep"
|
|
and the states <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> be atomic descendents of a
|
|
<parallel> element that is itself a descendent of the parent
|
|
<state> element.)</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<p>If the 'type' of a <history> element is "shallow", the
|
|
SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> record the immediately active children of
|
|
its parent before taking any transition that exits the parent. If
|
|
the 'type' of a <history> element is "deep", the SCXML
|
|
processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> record the active atomic descendents of
|
|
the parent before taking any transition that exits the parent.
|
|
Before the parent state has been visited for the first time, the
|
|
SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> treat the default history configuration,
|
|
which is specified by the 'target' of the <history> element's
|
|
<transition> child, as if it were the stored configuration.
|
|
If a transition is executed that takes the <history> state as
|
|
its target, the SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> behave as if the transition had taken the
|
|
stored state configuration as its target. (Note that in a
|
|
conformant SCXML document, a <state> or <parallel>
|
|
element <em title="MAY in RFC2119 context" class="RFC2119">MAY</em>
|
|
have both "deep" and "shallow" <history> children.)</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="LegalStateConfigurations"
|
|
name="LegalStateConfigurations" />3.11 Legal State Configurations
|
|
and Specifications</h3>
|
|
|
|
<p>[<a title="" id="state-active"
|
|
name="state-active">Definition</a>: A <state> or
|
|
<parallel> element is <b>active</b> if it has been entered by
|
|
a transition and has not subsequently been exited.]</p>
|
|
|
|
<p>[<a title="" id="state-configuration"
|
|
name="state-configuration">Definition</a>: The <b>state
|
|
configuration</b> of a state machine is the set of currently active
|
|
states. ]</p>
|
|
|
|
<p>An SCXML document places the state machine in an initial state
|
|
configuration at initialization time (via the 'initial' attribute
|
|
of the <scxml> element). Each transition that the state
|
|
machine takes thereafter places the state machine in another state
|
|
configuration (which need not be distinct from the former one.) A
|
|
conformant SCXML document <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> place the state machine only in legal
|
|
state configurations, where a legal state configuration is one that
|
|
meets the following conditions:</p>
|
|
|
|
<ul>
|
|
<li>The configuration contains exactly one child of the
|
|
<scxml> element.</li>
|
|
|
|
<li>The configuration contains one or more atomic states.</li>
|
|
|
|
<li>When the configuration contains an atomic state, it contains
|
|
all of its <state> and <parallel> ancestors.</li>
|
|
|
|
<li>When the configuration contains a non-atomic <state>, it
|
|
contains one and only one of the state's children.</li>
|
|
|
|
<li>If the configuration contains a <parallel> state, it
|
|
contains all of its children.</li>
|
|
</ul>
|
|
|
|
<p>It follows from this definition that if a state machine is in
|
|
more than one atomic state, the atomic states can be traced back
|
|
through a chain of <state> or >parallel> ancestors to a
|
|
single <parallel> ancestor.</p>
|
|
|
|
<p>The 'target' attribute of a <transition> (or the 'initial'
|
|
attribute of a <state> or <scxml> element) do not in
|
|
the general case specify a full legal state configuration since 1)
|
|
they can contain <parallel> or non-atomic <state>
|
|
elements 2) they do not contain the ancestors of the states in the
|
|
list. We therefore define a legal state specification to be a set
|
|
of states such that 1) no state is an ancestor of any other state
|
|
on the list, and 2) a full legal state configuration results when
|
|
all ancestors and default initial descendants have been added.
|
|
(Note that the process of adding default initial descendants is
|
|
recursive, since the 'initial' value may itself be non-atomic.) In
|
|
a conformant SCXML document, the value of an 'initial' attribute or
|
|
the 'target' of a <transition> <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> either be
|
|
empty or contain a legal state specification.</p>
|
|
|
|
<p>In a conformant SCXML document, there is an additional
|
|
requirement on the value of the 'initial' attribute of a
|
|
<state> and on the 'target' of a <transition> inside an
|
|
<initial> element: all the states <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> be
|
|
descendants of the containing <state> element.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="events" name="events" />3.12 SCXML Events</h3>
|
|
|
|
<p>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:</p>
|
|
|
|
<ul>
|
|
<li>The SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> make the data contained in an event
|
|
accessible via the 'event' variable, as specified in <a
|
|
href="#SystemVariables"><b>5.11 System Variables</b></a>.</li>
|
|
|
|
<li>The SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> make the event's name accessible via the
|
|
'event' variable, as specified in <a
|
|
href="#SystemVariables"><b>5.11 System Variables</b></a>. The SCXML
|
|
processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> use this same name value to match against
|
|
the 'event' attribute of transitions.</li>
|
|
</ul>
|
|
|
|
<p>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. These are described in <a
|
|
href="#events"><b>3.12 SCXML Events</b></a>. Platforms <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> extend the
|
|
names of these automatically generated events by adding a suffix.
|
|
For example, a platform could extend done.state.<em>id</em> with a
|
|
timestamp suffix and generate done.state.<em>id.timestamp</em>
|
|
instead. Because any prefix of done.state.<em>id</em> is also a
|
|
prefix of done.state.<em>id.timestamp</em>, any transition that
|
|
matches the former event will also match the latter.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="EventDescriptors" name="EventDescriptors" />3.12.1 Event
|
|
Descriptors</h4>
|
|
|
|
<p>Like an event name, an event descriptor is a series of
|
|
alphanumeric characters segemented into tokens by the "."
|
|
character. The 'event' attribute of a transition consists of one or
|
|
more such event descriptors separated by spaces.</p>
|
|
|
|
<p>[<a title="" id="transition-match"
|
|
name="transition-match">Definition</a>: A transition <b>matches</b>
|
|
an event if at least one of its event descriptors matches the
|
|
event's name. ]</p>
|
|
|
|
<p>[<a title="" id="event-match" name="event-match">Definition</a>:
|
|
An event descriptor <b>matches</b> an event name if its string of
|
|
tokens is an exact match or a prefix of the set of tokens in the
|
|
event's name. In all cases, the token matching is case sensitive.
|
|
]</p>
|
|
|
|
<p>For example, a transition with an 'event' attribute of "error
|
|
foo" will match event names "error", "error.send",
|
|
"error.send.failed", etc. (or "foo", "foo.bar" etc.) but would not
|
|
match events named "errors.my.custom",
|
|
"errorhandler.mistake","errOr.send" or "foobar".</p>
|
|
|
|
<p>For compatibility with CCXML, and to make the prefix matching
|
|
possibly more clear to a reader of the SCXML document, an event
|
|
descriptor <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> also end with the wildcard '.*', which
|
|
matches zero or more tokens at the end of the processed event's
|
|
name. Note that a transition with 'event' of "error", one with
|
|
"error.", and one with "error.*" are functionally equivalent since
|
|
they are token prefixes of exactly the same set of event names.</p>
|
|
|
|
<p>An event designator consisting solely of "*" can be used as a
|
|
wildcard matching any sequence of tokens, and thus any event. Note
|
|
that this is different from a transition lacking the 'event'
|
|
attribute altogether. Such an eventless transition does not match
|
|
any event, but will be taken whenever its 'cond' attribute
|
|
evaluates to 'true'. As shown in <a
|
|
href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm for SCXML
|
|
Interpretation</b></a>, 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.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="ErrorEvents" name="ErrorEvents" />3.12.2 Errors</h4>
|
|
|
|
<p>Once the SCXML processor has begun executing a well-formed SCXML
|
|
document, it <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> signal any errors that occur by raising
|
|
SCXML events whose names begin with 'error.'. the processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> place
|
|
these events in the internal event queue and <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> process
|
|
them like any other event. (Note 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.) Two
|
|
error events are defined in this specification:
|
|
'error.communication' and 'error.execution'. The former cover
|
|
errors occurring while trying to communicate with external
|
|
entities, such as those arising from <send> and
|
|
<invoke>, while the latter category consists of errors
|
|
internal to the execution of the document, such as those arising
|
|
from expression evaluation.</p>
|
|
|
|
<p>The set of error events may be extended in future versions of
|
|
this specification. However, the set of names beginning with
|
|
'error.platform' is reserved for platform- and application-specific
|
|
errors. Therefore applications and platforms <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> extend the
|
|
set of errors defined in this specification in two ways. First by
|
|
adding a suffix to an error name defined in this specification, and
|
|
second by using 'error.platform' with or without a suffix. In
|
|
addition, platforms <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> include additional information about the
|
|
nature of the error in the 'data' field of the event. See <a
|
|
href="#SystemVariables"><b>5.11 System Variables</b></a> for
|
|
details.</p>
|
|
|
|
<p>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.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="errorsAndEvents" name="errorsAndEvents" />3.12.3 List of
|
|
Errors and Events</h4>
|
|
|
|
<p>The following events are generated automatically by the SCXML
|
|
implementation under conditions defined elsewhere in this
|
|
document.</p>
|
|
|
|
<table border="1" cellpadding="2" cellspacing="2"
|
|
summary="errors and events" width="100%">
|
|
<tbody>
|
|
<tr>
|
|
<th align="center">Name</th>
|
|
<th align="center">Description</th>
|
|
<th align="center">Defined in</th>
|
|
<th align="center">See also</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="center">done.state.<em>id</em></td>
|
|
<td>Indicates that the state machine has entered a final substate
|
|
of state <em>id</em>.</td>
|
|
<td><a href="#final"><b>3.7 <final></b></a></td>
|
|
<td><a href="#CoreIntroduction"><b>3.1 Introduction</b></a></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="center">done.invoke.<em>id</em></td>
|
|
<td>Indicates that the invoked process with invokeid <em>id</em>
|
|
has completed processing.</td>
|
|
<td><a href="#invoke"><b>6.4 <invoke></b></a></td>
|
|
<td><a href="#final"><b>3.7 <final></b></a>, exitInterpreter
|
|
procedure in <a href="#AlgorithmforSCXMLInterpretation"><b>A
|
|
Algorithm for SCXML Interpretation</b></a> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="center">cancel.invoke.<em>id</em></td>
|
|
<td>Sent from an invoking session to an invoked session to
|
|
terminate its processing.</td>
|
|
<td><a href="#invokeimplementation"><b>6.4.3 Implementation of
|
|
<invoke></b></a> </td>
|
|
<td><a href="#SCXMLEventProcessor"><b>E.1 SCXML Event I/O
|
|
Processor</b></a></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="center">error.communication</td>
|
|
<td>Indicates that an error has occurred while trying to
|
|
communicate with an external entity.</td>
|
|
<td><a href="#ErrorEvents"><b>3.12.2 Errors</b></a></td>
|
|
<td><a href="#send"><b>6.2 <send></b></a>, <a
|
|
href="#SCXMLEventProcessor"><b>E.1 SCXML Event I/O
|
|
Processor</b></a>, <a href="#BasicHTTPEventProcessor"><b>E.2 Basic
|
|
HTTP Event I/O Processor</b></a>, <a
|
|
href="#DOMEventProcessor"><b>E.3 DOM Event I/O
|
|
Processor</b></a></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="center">error.execution</td>
|
|
<td>Indicates that an error internal to the execution of the
|
|
document has occurred, such as one arising from expression
|
|
evaluation.</td>
|
|
<td><a href="#ErrorEvents"><b>3.12.2 Errors</b></a></td>
|
|
<td><a href="#foreach"><b>4.6 <foreach></b></a>, <a
|
|
href="#assign"><b>5.4 <assign></b></a>, <a
|
|
href="#param"><b>5.8 <param></b></a>, <a
|
|
href="#ConditionalExpressions"><b>5.10.1 Conditional
|
|
Expressions</b></a>, <a href="#LocationExpressions"><b>5.10.2
|
|
Location Expressions</b></a>, <a href="#ValueExpressions"><b>5.10.3
|
|
Legal Data Values and Value Expressions</b></a>, <a
|
|
href="#ErrorsinExpressions"><b>5.10.4 Errors in
|
|
Expressions</b></a>, <a href="#SystemVariables"><b>5.11 System
|
|
Variables</b></a>, <a href="#send"><b>6.2 <send></b></a>, <a
|
|
href="#ecma_location_expressions"><b>D.2.3 Location
|
|
Expressions</b></a>, <a href="#ecma_assign"><b>D.2.5
|
|
<assign></b></a>, <a href="#xpath_assign"><b>D.3.5
|
|
<assign></b></a> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="center">error.platform</td>
|
|
<td>Indicates that a platform- or application-specific error has
|
|
occurred.</td>
|
|
<td><a href="#ErrorEvents"><b>3.12.2 Errors</b></a></td>
|
|
<td /></tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="SelectingTransitions" name="SelectingTransitions" />3.13
|
|
Selecting and Executing Transitions</h3>
|
|
|
|
<p>To simplify the following definitions, we introduce the event
|
|
NULL. NULL has no name and is used only in these definitions. It
|
|
nevers occurs in the event queues of an SCXML Processor. All other
|
|
events have names and are distinct from NULL. (In effect, NULL is a
|
|
pseudo-event that is used in these definitions as a trigger for
|
|
eventless transitions.)</p>
|
|
|
|
<p>[<a title="" id="transition-enabled"
|
|
name="transition-enabled">Definition</a>: A transition T is
|
|
<b>enabled</b> by named event E in atomic state S if a) T's source
|
|
state is S or an ancestor of S, b) T matches E's name (see <a
|
|
href="#EventDescriptors"><b>3.12.1 Event Descriptors</b></a>) c) T
|
|
lacks a 'cond' attribute or its 'cond' attribute evaluates to
|
|
"true". A transition is <b>enabled</b> by NULL in atomic state S if
|
|
a) T lacks an 'event' attribute b) T's source state is S or an
|
|
ancestor of S c) T lacks an 'cond' attribute or its 'cond'
|
|
attribute evaluates to "true". (Note that such a transition can
|
|
never be enabled by any named event.)]</p>
|
|
|
|
<p>[<a title="" id="optimally-enabled"
|
|
name="optimally-enabled">Definition</a>: A transition T is
|
|
<b>optimally enabled</b> by event E in atomic state S if a) T is
|
|
enabled by E in S and b) no transition that precedes T in document
|
|
order in T's source state is enabled by E in S and c) no transition
|
|
is enabled by E in S in any descendent of T's source state.]</p>
|
|
|
|
<p>[<a title="" id="optimal-transition-set"
|
|
name="optimal-transition-set">Definition</a>: The <b>optimal
|
|
transition set</b> enabled by event E in state configuration C is
|
|
the largest set of transitions such that each transition in the set
|
|
is optimally enabled by E in an atomic state in C and no transition
|
|
has a source state that is exited by another transition in the set
|
|
that proceeds it in document order. ]</p>
|
|
|
|
<p>[<a title="" id="source-state"
|
|
name="source-state">Definition</a>: The <b>source state</b> of a
|
|
transition is the <state> or <parallel> element that it
|
|
occurs in. The <b>target state(s)</b> of the transition is the
|
|
state or set of states specified by its 'target' attribute. The
|
|
<b>complete target set</b> of a transition consists of all the
|
|
states that will be active after the transition is taken. It
|
|
contains the target states of the transition plus all their
|
|
ancestors, expanded by the recursive application of the following
|
|
two operations: 1) if any <parallel> element is a member of
|
|
the set, any of its children that are not members of the set must
|
|
be added 2) if any compound <state> is in the set and none of
|
|
its children is in the set, its default initial state is added to
|
|
the set. Any state whose child(ren) are added to the complete
|
|
target set by clause 2 is called a <b>default entry state</b>.
|
|
]</p>
|
|
|
|
<p>[<a title="" id="exit-set" name="exit-set">Definition</a>: The
|
|
<b>exit set</b> of a transition is the set of states that are
|
|
exited when the transition is taken. If the transition does not
|
|
contain a 'target', its exit set is empty. Otherwise (i.e., if the
|
|
transition contains a 'target'), if it 'type' of "external", its
|
|
exit set consists of all active states that are proper descendents
|
|
of the <a href="#LCA">Least Common Ancestor (LCA)</a> of the source
|
|
and target states. Otherwise, if the transition has 'type'
|
|
"internal" and all its target states are proper descendents of its
|
|
source state, the target set consists of all active states that are
|
|
proper descendents of its source state. (If a transition has 'type'
|
|
of "internal", but its target states are not all proper descendents
|
|
of its source state, its exit set is defined as if it had 'type' of
|
|
"external". The exit set of a set of transitions is the union of
|
|
the exit sets of the individual transitions. ]</p>
|
|
|
|
<p>[<a title="" id="entry-set" name="entry-set">Definition</a>: The
|
|
<b>entry set</b> of a transition is the set of states that are
|
|
entered when the transition is taken. If a transition does not
|
|
contain a 'target', its entry set is empty. Otherwise, it consists
|
|
of all members of the transitions complete target set that are not
|
|
currently active. The entry set of a set of transitions is the
|
|
union of the transition sets of the individual transitions.]</p>
|
|
|
|
<p>[<a title="" id="microstep" name="microstep">Definition</a>: A
|
|
<b>microstep</b> consists of the execution of the transitions in an
|
|
optimal enabled transition set.]</p>
|
|
|
|
<p>[<a title="" id="macrostep" name="macrostep">Definition</a>: A
|
|
<b>macrostep</b> is a series of one or more microsteps ending in a
|
|
configuration where the internal event queue is empty and no
|
|
transitions are enabled by NULL. ]</p>
|
|
|
|
<p>To execute a microstep, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> execute
|
|
the transitions in the corresponding optimal enabled transition To
|
|
execute a set of transitions, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> first
|
|
exit all the states in the transitions' exit set in <a
|
|
href="#exitOrder">exit order</a>. It <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> then
|
|
execute the executable content contained in the transitions in
|
|
document order. It <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> then enter the states in the transitions'
|
|
entry set in <a href="#entryOrder">entry order</a>.</p>
|
|
|
|
<p>To exit a state, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> execute
|
|
the executable content in the state's <onexit> handler. Then
|
|
it <em title="MUST in RFC2119 context" class="RFC2119">MUST</em>
|
|
cancel any ongoing invocations that were triggered by that state.
|
|
Finally, the Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> remove the state from the active state's
|
|
list.</p>
|
|
|
|
<p>To enter a state, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> add the
|
|
state to the active state's list. Then it <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> execute
|
|
the executable content in the state's <onentry> handler. If
|
|
the state is a default entry state and has an <initial>
|
|
child, the SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> then execute the executable content in
|
|
the <initial> child's <transition>.</p>
|
|
|
|
<p>At startup, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> place the
|
|
state machine in the configuration specified by the 'initial'
|
|
attribute of the <scxml> element.</p>
|
|
|
|
<p>After entering the initial configuration, and after executing
|
|
each microstep, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> check the
|
|
state configuration for <final> states that it has entered
|
|
during the microstep. If it has entered a <final> state that
|
|
is a child of <scxml>, it <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> halt processing. If it has entered a
|
|
<final> state that is a child of a compound state, it <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> generate
|
|
the event done.state.<em>id</em>, where <em>id</em> is the id of
|
|
the compound state. If the compound state is itself the child of a
|
|
<parallel> element, and all the <parallel> element's
|
|
other children are in final states, the Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> generate
|
|
the event done.state.<em>id</em>, where <em>id</em> is the id of
|
|
the <parallel> elements.</p>
|
|
|
|
<p>After checking the state configuration, the Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> select
|
|
the optimal transition set enabled by NULL in the current
|
|
configuration. If the set is not empty, it <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> execute
|
|
it as a microstep. If the set is empty, the Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> remove
|
|
events from the internal event queue until the queue is empty or it
|
|
finds an event that enables a non-empty optimal transition set in
|
|
the current configuration. If it finds such a set, the processor
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> then
|
|
execute it as a microstep. (Otherwise the internal event queue is
|
|
empty and the Processor has completed a macrostep.)</p>
|
|
|
|
<p>After completing a macrostep, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> execute
|
|
in document order the <invoke> handlers in all states that
|
|
have been entered since the completion of the last macrostep. Then
|
|
the Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> remove events from the external event
|
|
queue, waiting till events appear if necessary, until it finds one
|
|
that enables a non-empty optimal transition set in the current
|
|
configuration. The Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> then execute that set as a microstep.</p>
|
|
|
|
<p>See <a href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm
|
|
for SCXML Interpretation</b></a> for more details.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="IDs" name="IDs" />3.14 IDs</h3>
|
|
|
|
<p>In a conformant SCXML document, the values of all attributes of
|
|
type "id" <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> be unique within the session. When such
|
|
an attribute is defined to be optional and the author omits it, the
|
|
SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> generate a unique one automatically at
|
|
document load time. (Note that 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. In a
|
|
conformant SCXML document, they <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> be unique within the session, but in the
|
|
case where the author does not provide them, the processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> generate
|
|
a new unique ID not at load time but <em>each time the element is
|
|
executed</em>. 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 <a href="#invokeattrs"><b>6.4.1 Attribute Details</b></a> for
|
|
details. The SCXML processor <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> generate all other ids in any format, as
|
|
long as they are unique.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="executable" name="executable" />4 Executable
|
|
Content</h2>
|
|
|
|
<div class="div2">
|
|
<h3><a id="ExecutableIntroduction"
|
|
name="ExecutableIntroduction" />4.1 Introduction</h3>
|
|
|
|
<p>[This section is informative.]</p>
|
|
|
|
<p>Executable content allows the state machine to <em>do</em>
|
|
things. It provides the hooks that allow an SCXML session to modify
|
|
its data model and interact with external entities. Executable
|
|
content consists of actions that are performed as part of taking
|
|
transitions. In particular, executable content occurs inside
|
|
<onentry> and <onexit> elements as well as inside
|
|
transitions. When the state machine takes a transition, it executes
|
|
the <onexit> executable content in the states it is leaving,
|
|
followed by the content in the transition, followed by the
|
|
<onentry> content in the states it is entering. See <a
|
|
href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm for SCXML
|
|
Interpretation</b></a> for details.</p>
|
|
|
|
<p>This standard defines elements of executable content which can
|
|
raise events<a href="#raise"><b>4.2 <raise></b></a>,
|
|
communicate with external entities <a href="#send"><b>6.2
|
|
<send></b></a>, log information <a href="#log"><b>4.7
|
|
<log></b></a> execute scripts <a href="#script"><b>5.9
|
|
<script></b></a> and modify the data model <a
|
|
href="#assign"><b>5.4 <assign></b></a>, as well as control
|
|
constructs to conditionalize execution <a href="#if"><b>4.3
|
|
<if></b></a> and to iterate over the items in a collection <a
|
|
href="#foreach"><b>4.6 <foreach></b></a>. In addition, SCXML
|
|
implementations are allowed to define their own, platform-specific
|
|
executable content (see <a href="#extensibility"><b>4.10
|
|
Extensibility of Executable Content</b></a>).</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="raise" name="raise" />4.2 <raise></h3>
|
|
|
|
<p>The <raise> element raises an event in the current SCXML
|
|
session. Note that the event will not be processed until the
|
|
current block of executable content has completed and all events
|
|
that are already in the internal event queue have been processed.
|
|
For example, suppose the <raise> element occurs first in the
|
|
<onentry> handler of state S followed by executable content
|
|
elements ec1 and ec2. If event e1 is already in the internal event
|
|
queue when S is entered, the event generated by <raise> will
|
|
not be processed until ec1 and ec2 have finished execution and e1
|
|
has been processed. For details of event processing, see <a
|
|
href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm for SCXML
|
|
Interpretation</b></a>. Note that the <a href="#send"><b>6.2
|
|
<send></b></a> 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.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N1077E" name="N1077E" />4.2.1 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>event</td>
|
|
<td>true</td>
|
|
<td />
|
|
<td>NMTOKEN</td>
|
|
<td>none</td>
|
|
<td></td>
|
|
<td>Specifies the name of the event. This will be matched against
|
|
the 'event' attribute of transitions.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N107A4" name="N107A4" />4.2.2 Children</h4>
|
|
|
|
None.</div>
|
|
|
|
<p>The SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> place the event that is generated at the
|
|
rear of the session's internal event queue.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="if" name="if" />4.3 <if></h3>
|
|
|
|
<p><if> is a container for conditionally executed
|
|
elements.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N107B3" name="N107B3" />4.3.1 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>cond</td>
|
|
<td>true</td>
|
|
<td />
|
|
<td>Conditional expression</td>
|
|
<td>none</td>
|
|
<td>A valid conditional expression</td>
|
|
<td>A boolean expression. See <a
|
|
href="#ConditionalExpressions"><b>5.10.1 Conditional
|
|
Expressions</b></a> for details.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N107DC" name="N107DC" />4.3.2 Children</h4>
|
|
|
|
<ul>
|
|
<li><elseif> Occurs 0 or more times. See <a
|
|
href="#elseif"><b>4.4 <elseif></b></a></li>
|
|
|
|
<li><else> Occurs 0 or 1 times. See <a href="#else"><b>4.5
|
|
<else></b></a></li>
|
|
|
|
<li>The other children of <if> consist of executable content.
|
|
Note that since <if> itself is executable content, nested
|
|
<if> statements are allowed.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<p>The behavior of <if> is defined in terms of partitions of
|
|
executable content. The first partition consists of the executable
|
|
content between the <if> and the first <elseif>,
|
|
<else> or </if> tag. Each <elseif> tag defines a
|
|
partition that extends from it to the next <elseif>,
|
|
<else> or </if> tag. The <else> tag defines a
|
|
partition that extends from it to the closing </if> tag. In a
|
|
conformant SCXML document, a partition <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> be empty.
|
|
In a conformant SCXML document, <else> <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> occur
|
|
after all <elseif> tags.</p>
|
|
|
|
<p>When the <if> element is executed, the SCXML processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> execute
|
|
the first partition in document order that is defined by a tag
|
|
whose 'cond' attribute evaluates to true, if there is one.
|
|
Otherwise, it <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> execute the partition defined by the
|
|
<else> tag, if there is one. Otherwise it <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
execute any of the executable content.</p>
|
|
|
|
<p>Here is an example:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="elseif" name="elseif" />4.4 <elseif></h3>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10809" name="N10809" />4.4.1 Overview</h4>
|
|
|
|
<p><elseif> is an empty element that partitions the content
|
|
of an <if>, and provides a condition that determines whether
|
|
the partition is executed.</p>
|
|
</div>
|
|
|
|
<div class="div3" /></div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="else" name="else" />4.5 <else></h3>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10813" name="N10813" />4.5.1 Overview</h4>
|
|
|
|
<p><else> is an empty element that partitions the content of
|
|
an <if>. It is equivalent to an <elseif> with a "cond"
|
|
that always evaluates to true.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10818" name="N10818" />4.5.2 Attribute Details</h4>
|
|
|
|
<p>None.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="foreach" name="foreach" />4.6 <foreach></h3>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10821" name="N10821" />4.6.1 Overview</h4>
|
|
|
|
<p>The <foreach> element allows an SCXML application to
|
|
iterate through a collection in the data model and to execute the
|
|
actions contained within it for each item in the collection.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10826" name="N10826" />4.6.2 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>array</td>
|
|
<td>true</td>
|
|
<td />
|
|
<td>Value expression</td>
|
|
<td>none</td>
|
|
<td>A value expression that evaluates to an iterable
|
|
collection.</td>
|
|
<td>The <foreach> element will iterate over a shallow copy of
|
|
this collection.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>item</td>
|
|
<td>true</td>
|
|
<td />
|
|
<td>xsd:string</td>
|
|
<td>none</td>
|
|
<td>Any variable name that is valid in the specified data
|
|
model.</td>
|
|
<td>A variable that stores a different item of the collection in
|
|
each iteration of the loop.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>index</td>
|
|
<td>false</td>
|
|
<td />
|
|
<td>xsd:string</td>
|
|
<td>none</td>
|
|
<td>Any variable name that is valid in the specified data
|
|
model.</td>
|
|
<td>A variable that stores the current iteration index upon each
|
|
iteration of the foreach loop.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10868" name="N10868" />4.6.3 Children</h4>
|
|
|
|
<p>The children of <foreach> consist of one or more items of
|
|
executable content. (Note that they are considered to be part of
|
|
the same block of executable content as the parent <foreach>
|
|
element.)</p>
|
|
</div>
|
|
|
|
<p>The SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> declare a new variable if the one
|
|
specified by 'item' is not already defined. If 'index' is present,
|
|
the SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> declare a new variable if the one
|
|
specified by 'index' is not already defined. If 'array' does not
|
|
evaluate to a legal iterable collection, or if 'item' does not
|
|
specify a legal variable name, the SCXML processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> terminate
|
|
execution of the <foreach> element and the block that
|
|
contains it, and place the error error.execution on the internal
|
|
event queue.</p>
|
|
|
|
<p>The SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> start with the first item in the
|
|
collection and proceed to the last item in the iteration order that
|
|
is defined for the collection. (This order depends on the data
|
|
model in use. ) For each item, the processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> act as if
|
|
it has made a shallow copy or reference and assign it to the item
|
|
variable. (Note that the assigned value <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> be null or
|
|
undefined if the collection contains a null or undefined item.)
|
|
After making the assignment, the SCXML processor <em
|
|
title=" MUST in RFC2119 context" class="RFC2119">MUST</em> evaluate
|
|
its child executable content. It <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> then
|
|
proceed to the next item in iteration order. If the evaluation of
|
|
any child element causes an error, the processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> cease
|
|
execution of the <foreach> element and the block that
|
|
contains it. (Note that SCXML does not provide break functionality
|
|
to interrupt <foreach>, however targetless and/or eventless
|
|
transitions can provide sophisticated iterative behavior within the
|
|
SCXML application itself.)</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="log" name="log" />4.7 <log></h3>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10890" name="N10890" />4.7.1 Overview</h4>
|
|
|
|
<p><log> allows an application to generate a logging or debug
|
|
message.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10895" name="N10895" />4.7.2 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>label</td>
|
|
<td>false</td>
|
|
<td />
|
|
<td>string</td>
|
|
<td>empty string</td>
|
|
<td />
|
|
<td>A character string with an implementation-dependent
|
|
interpretation.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>expr</td>
|
|
<td>true</td>
|
|
<td />
|
|
<td>Value expression</td>
|
|
<td>none</td>
|
|
<td />
|
|
<td>An expression returning the value to be logged. See <a
|
|
href="#ValueExpressions"><b>5.10.3 Legal Data Values and Value
|
|
Expressions</b></a> for details. The nature of the logging
|
|
mechanism is implementation-dependent. For example, the SCXML
|
|
processor may convert this value to a convenient format before
|
|
logging it.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N108CA" name="N108CA" />4.7.3 Children</h4>
|
|
|
|
<p>None.</p>
|
|
</div>
|
|
|
|
<p>The manner in which the message is displayed or logged is
|
|
platform-dependent. The SCXML processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> insure
|
|
that <log> has no side-effects on document
|
|
interpretation.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="profile-dependentexecutablecontent"
|
|
name="profile-dependentexecutablecontent" />4.8 Other Executable
|
|
Content</h3>
|
|
|
|
<p>The following elements of executable content are defined
|
|
elsewhere in this specification. They <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> occur
|
|
wherever executable content is allowed and <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
occur anyplace else.</p>
|
|
|
|
<ul>
|
|
<li><assign>. Changes the value of a location in the data
|
|
model. See <a href="#assign"><b>5.4 <assign></b></a> for
|
|
details.</li>
|
|
|
|
<li><validate>. Validates the data model. See <a
|
|
href="#validate"><b>5.5 <validate></b></a> for details.</li>
|
|
|
|
<li><script>. Provides scripting capabilties. See <a
|
|
href="#script"><b>5.9 <script></b></a> for details.</li>
|
|
|
|
<li><send>. Sends an event to a specified destination. See <a
|
|
href="#send"><b>6.2 <send></b></a> for details.</li>
|
|
|
|
<li><cancel>. Cancels an event that was to be sent See <a
|
|
href="#cancel"><b>6.3 <cancel></b></a> for details.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="EvaluationofExecutableContent"
|
|
name="EvaluationofExecutableContent" />4.9 Evaluation of Executable
|
|
Content</h3>
|
|
|
|
<p>Wherever executable content is permitted, an arbitrary number of
|
|
elements <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> occur. Such a sequence of elements of
|
|
executable content is called a block. For example, if transition t
|
|
takes the state machine from atomic state S1 to atomic state S2,
|
|
there are three blocks of executable content executed: the one in
|
|
the <onexit> handler of S1, the one inside t, and the one
|
|
inside the <onentry> handler of S2. The SCXML processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> execute
|
|
the elements of a block in document order. If the processing of an
|
|
element causes an error to be raised, the processor <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
process the remaining elements of the block. (The execution of
|
|
other blocks of executable content is not affected.)</p>
|
|
|
|
<p>Events raised during the processing of executable content are
|
|
treated like any other events. Note in particular, that error
|
|
events will not be removed from the queue and processed until all
|
|
events preceding them in the queue have been processed. See <a
|
|
href="#ErrorEvents"><b>3.12.2 Errors</b></a> and <a
|
|
href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm for SCXML
|
|
Interpretation</b></a> for details.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="extensibility" name="extensibility" />4.10 Extensibility
|
|
of Executable Content</h3>
|
|
|
|
<p>Implementations <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> may provide additional executable content
|
|
corresponding to special features of their implementations. The
|
|
functionality of such platform-specific content is not restricted,
|
|
except that it <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em> cause transitions or any form of
|
|
change of state (except indirectly, by raising events that trigger
|
|
transitions). Note that SCXML treats the executable content
|
|
triggered by a transition as a single blocking operation and that
|
|
no events are processed until all the executable content has
|
|
completed. For example, when taking a transition into state S, the
|
|
SCXML processor will not process any events or take any transitions
|
|
until all <onentry> handlers in S have finished. It is thus
|
|
important that all executable content, including platform-specific
|
|
extensions, execute swiftly.</p>
|
|
|
|
<p>In a conformant SCXML document any extensions to executable
|
|
content <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em> be defined the 'scxml' namespace.
|
|
(Note that the schema <a href="#schemas"><b>B Schema</b></a> allows
|
|
elements from arbitrary namespaces inside blocks of executable
|
|
content.) The following example shows the incorporation of CCXML
|
|
functionality (see <a href="#CCXML">[W3C CCXML 1.0]</a>) into
|
|
SCXML. In particular an <accept> element in the 'ccxml'
|
|
namespace is invoked as executable content inside a transition.</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<transition event="ccxml:connection.alerting">
|
|
<ccxml:accept connectionid="_event.data.connectionid"/>
|
|
</transition>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>This markup is legal on any SCXML interpreter, but the behavior
|
|
of <accept> element is platform-dependent. See <a
|
|
href="#ConformingProcessors"><b>C.2 Conforming Processors</b></a>
|
|
for details.</p>
|
|
|
|
<p>A general method for implementing extensions using the
|
|
<send> element is presented in <a
|
|
href="#custom_action"><b>G.8 Custom Action Elements</b></a>.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="data-module" name="data-module" />5 Data Model and Data
|
|
Manipulation</h2>
|
|
|
|
<div class="div2">
|
|
<h3><a id="DataModelIntroduction"
|
|
name="DataModelIntroduction" />5.1 Introduction</h3>
|
|
|
|
<p>[This section is informative.]</p>
|
|
|
|
<p>The Data Model offers the capability of storing, reading, and
|
|
modifying a set of data that is internal to the state machine. This
|
|
specification does not mandate any specific data model, but instead
|
|
defines a set of abstract capabilities that can be realized by
|
|
various languages, such as ECMAScript or XML/XPath. Implementations
|
|
may choose the set of data models that they support. In addition to
|
|
the underlying data structure, the data model defines a set of
|
|
expression as described in <a href="#Expressions"><b>5.10
|
|
Expressions</b></a>. These expressions are used to refer to
|
|
specific locations in the data model, to compute values to assign
|
|
to those locations, and to evaluate boolean conditions. Finally,
|
|
the data model includes a set of system variables, as defined in <a
|
|
href="#SystemVariables"><b>5.11 System Variables</b></a>, which are
|
|
automatically maintained by the SCXML processor.</p>
|
|
|
|
<p>The data model is defined via the <a href="#datamodel"><b>5.2
|
|
<datamodel></b></a> element, which contains zero or more <a
|
|
href="#data"><b>5.3 <data></b></a> elements, each of which
|
|
defines a single data element and assigns an initial value to it.
|
|
These values may be specified in-line or loaded from an external
|
|
source. They can then be updated via the <a href="#assign"><b>5.4
|
|
<assign></b></a> element. The <a href="#validate"><b>5.5
|
|
<validate></b></a> element can be used to validate the data
|
|
(in data models where that makes sense), while the <a
|
|
href="#donedata"><b>5.6 <donedata></b></a>, <a
|
|
href="#content"><b>5.7 <content></b></a> , and <a
|
|
href="#param"><b>5.8 <param></b></a> elements can be used to
|
|
incorporate data into communications with external entities.
|
|
Finally, the <a href="#script"><b>5.9 <script></b></a>
|
|
element permits the incorporation of a scripting language.</p>
|
|
|
|
<p>The interpretation of these elements depends on the datamodel in
|
|
question, and not all elements are supported in all datamodels. For
|
|
the details of specific data models, see <a href="#profiles"><b>D
|
|
Data Models</b></a>.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="datamodel" name="datamodel" />5.2 <datamodel></h3>
|
|
|
|
<p><datamodel> is a wrapper element which encapsulates any
|
|
number of <data> elements, each of which defines a single
|
|
data object. The exact nature of the data object depends on the
|
|
data model language used.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10972" name="N10972" />5.2.1 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>schema</td>
|
|
<td>false</td>
|
|
<td />
|
|
<td>URI</td>
|
|
<td>none</td>
|
|
<td>Location of the schema for this datamodel</td>
|
|
<td>URL of the schema for this datamodel. See <a
|
|
href="#validate"><b>5.5 <validate></b></a> for its use. The
|
|
exact nature of the schema depends on the data model language being
|
|
used.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N1099B" name="N1099B" />5.2.2 Children</h4>
|
|
|
|
<ul>
|
|
<li><data> Occurs 0 or more times. Each instance defines a
|
|
named data element.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<p>In a conformant SCXML document, the 'schema' attribute <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> occur on
|
|
the top-level <datamodel> elemen, namely the one that is a
|
|
child of <scxml>. It <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em> occur on any other element.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="data" name="data" />5.3 <data></h3>
|
|
|
|
<p>The <data> element is used to declare and populate
|
|
portions of the datamodel.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N109B0" name="N109B0" />5.3.1 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>id</td>
|
|
<td>true</td>
|
|
<td />
|
|
<td>ID</td>
|
|
<td>none</td>
|
|
<td></td>
|
|
<td>The name of the data item. See <a href="#IDs"><b>3.14
|
|
IDs</b></a> for details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>src</td>
|
|
<td>false</td>
|
|
<td />
|
|
<td>URI</td>
|
|
<td>none</td>
|
|
<td />
|
|
<td>Gives the location from which the data object should be
|
|
fetched. See <a href="#ValueExpressions"><b>5.10.3 Legal Data
|
|
Values and Value Expressions</b></a> for details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>expr</td>
|
|
<td>false</td>
|
|
<td />
|
|
<td>Expression</td>
|
|
<td>none</td>
|
|
<td>Any valid value expression</td>
|
|
<td>Evaluates to provide the value of the data item. See <a
|
|
href="#ValueExpressions"><b>5.10.3 Legal Data Values and Value
|
|
Expressions</b></a> for details.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N109FA" name="N109FA" />5.3.2 Children</h4>
|
|
|
|
<p>The children of the <data> element represent an in-line
|
|
specification of the value of the data object.</p>
|
|
|
|
<p>In a conformant SCXML document, a <data> element <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> have either
|
|
a 'src' or an 'expr' attribute, but <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
have both. Furthermore, if either attribute is present, the element
|
|
<em title="MUST NOT in RFC2119 context" class="RFC2119">MUST
|
|
NOT</em> have any children. Thus 'src', 'expr' and children are
|
|
mutually exclusive in the <data> element.</p>
|
|
|
|
<p>The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> must allow the environment to provide
|
|
values for top-level <data> elements (namely those that are
|
|
children of the <datamodel > element that is a child of
|
|
<scxml>). Specifically, the Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> use the
|
|
values provided at instantiation time instead of those contained in
|
|
thee <data> elements. The manner in which the environment
|
|
specifies these values is platform-dependent.</p>
|
|
|
|
<p>If the value specified (by 'src', children, or the environment)
|
|
is not a legal data value, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> create an
|
|
empty data element in the data model with the specified id. Note
|
|
that what constitutes a legal data value depends on the data model
|
|
language used. See <a href="#profiles"><b>D Data Models</b></a> for
|
|
details.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="DataBinding" name="DataBinding" />5.3.3 Data Binding and
|
|
Scoping</h4>
|
|
|
|
<p>There is a single globally visible data model for the entire
|
|
state machine. Specifically, the SCXML processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> allow any
|
|
data element to be accessed from any state. Thus the data model has
|
|
no concept of scoping. However, authors control when the initial
|
|
values are assigned to the data elements by means of the 'binding'
|
|
attribute on the <scxml> element. When 'binding' is assigned
|
|
the value "early" (the default), the scxml processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> create
|
|
all data elements and assign their initial values at document
|
|
initialization time. When 'binding' is assigned the value "late",
|
|
the scxml processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> create the data elements at document
|
|
initialization time, but <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> assign the value specified by 'expr' to a
|
|
given data element only when the state that contains it is entered
|
|
for the first time, before any <onentry> markup. (The value
|
|
of the data element between the time it is created and the time its
|
|
parent state is first entered will depend on the data language
|
|
chosen. The value specified by 'expr' will be assigned to the data
|
|
element even if the element already has a non-null value when the
|
|
parent state is first entered.)</p>
|
|
|
|
<p>Ordering dependencies between <data> elements are not
|
|
permitted. In the case of early binding, the scxml processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> evaluate
|
|
all <data> elements at initialization time but <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> do so in
|
|
any order it chooses. Suppose, for example, that the declaration of
|
|
element "a" precedes 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 safely reference the value of "a" (and vice-versa).
|
|
When late binding is selected, the scxml processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> create
|
|
data model elements at initialization time but <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> do so in
|
|
any order it chooses. Similarly, the processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> assign
|
|
the value specified by 'expr' to data elements only when the state
|
|
containing them is first entered, but <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> do so in
|
|
any order it chooses.</p>
|
|
|
|
<p>Values created by <data> elements are local to their
|
|
session. In particular, the scxml processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> insure
|
|
that such values are changed only by the execution of executable
|
|
content or the <finalize> element. Note that in addition to
|
|
the author-controlled <data> elements there are system
|
|
variables whose values are maintained by the scxml processor. See
|
|
<a href="#SystemVariables"><b>5.11 System Variables</b></a> for
|
|
details.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="assign" name="assign" />5.4 <assign></h3>
|
|
|
|
<p>The <assign> element is used to modify the data model.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10A4E" name="N10A4E" />5.4.1 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>location</td>
|
|
<td>true</td>
|
|
<td />
|
|
<td>path expression</td>
|
|
<td>none</td>
|
|
<td>Any valid location expression.</td>
|
|
<td>The location in the data model into which to insert the new
|
|
value. See <a href="#LocationExpressions"><b>5.10.2 Location
|
|
Expressions</b></a> for details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>expr</td>
|
|
<td>false</td>
|
|
<td>This attribute must not occur in an <assign> element that
|
|
has children.</td>
|
|
<td>value expression</td>
|
|
<td>none</td>
|
|
<td>Any valid value expression</td>
|
|
<td>An expression returning the value to be assigned. See <a
|
|
href="#ValueExpressions"><b>5.10.3 Legal Data Values and Value
|
|
Expressions</b></a> for details.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10A89" name="N10A89" />5.4.2 Children</h4>
|
|
|
|
<p>The children of the <assign>element provide an in-line
|
|
specification of legal data value (see <a
|
|
href="#ValueExpressions"><b>5.10.3 Legal Data Values and Value
|
|
Expressions</b></a>) to be inserted into the datamodel at the
|
|
specified location.</p>
|
|
</div>
|
|
|
|
<p>A conformant SCXML document <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> specify either "expr" or children of
|
|
<assign>, but not both.</p>
|
|
|
|
<p>Assignment to a data model is done by using a location
|
|
expression to denote the part of the data model where the insertion
|
|
is to be made. If the location expression does not denote a valid
|
|
location in the datamodel or if the value specified ( by 'expr' or
|
|
children) is not a legal value for the location specified, the
|
|
processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> place the error error.execution in the
|
|
internal event queue. Otherwise, the processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> place the
|
|
specified value at the specified location. Note that the nature of
|
|
the insertion and the definition of a legal value depends on the
|
|
data model language used. Note also that datamodels <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> additional
|
|
attributes for <assign> beyond those specified here. See <a
|
|
href="#profiles"><b>D Data Models</b></a> for details.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="validate" name="validate" />5.5 <validate></h3>
|
|
|
|
<p>The <validate> element causes the datamodel to be
|
|
validated.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10AAA" name="N10AAA" />5.5.1 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>location</td>
|
|
<td>false</td>
|
|
<td />
|
|
<td>location expression</td>
|
|
<td>none</td>
|
|
<td>Any valid location expression.</td>
|
|
<td>The location of the subtree to validate. If it is not present,
|
|
the entire datamodel is validated. See <a
|
|
href="#LocationExpressions"><b>5.10.2 Location Expressions</b></a>
|
|
for details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>schema</td>
|
|
<td>false</td>
|
|
<td />
|
|
<td>URI</td>
|
|
<td>none</td>
|
|
<td>Any valid URI</td>
|
|
<td>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.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10AE1" name="N10AE1" />5.5.2 Children</h4>
|
|
|
|
<p>None.</p>
|
|
</div>
|
|
|
|
<p>The SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> validate the datamodel only when
|
|
instructed to do so by the <validate> element. A valid SCXML
|
|
document containing the <validate> element <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> specify a
|
|
schema with the 'schema'attribute of the <validate> element
|
|
or with the 'schema' attribute of the <datamodel> element (or
|
|
with both). If the <validate> element specifies a schema, the
|
|
processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> use this schema to validate the
|
|
datamodel. Otherwise, it <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> use the value specified in the
|
|
<datamodel> element.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="donedata" name="donedata" />5.6 <donedata></h3>
|
|
|
|
<p>A wrapper element holding data to be returned when a
|
|
<final> state is entered.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10AFA" name="N10AFA" />5.6.1 Attribute Details</h4>
|
|
|
|
<p>None.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10AFF" name="N10AFF" />5.6.2 Children</h4>
|
|
|
|
<ul>
|
|
<li><content>. Specifies in-line data to include in the
|
|
event. May occur 0 or 1 times. See <a href="#content"><b>5.7
|
|
<content></b></a> .</li>
|
|
|
|
<li><param> Extracts data from the data model to include in
|
|
the event. See <a href="#param"><b>5.8 <param></b></a> for
|
|
details. May occur 0 or more times.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<p>A conformant SCXML document <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> specify either a single <content>
|
|
element or one or more <param> elements as children of
|
|
<donedata>, but not both. .</p>
|
|
|
|
<p>In cases where the SCXML processor generates a 'done' event upon
|
|
entry into the final state, it <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> place the data specified by this element
|
|
in the _event.data field, but exact format of that data will be
|
|
determined by the datamodel (see <a href="#profiles"><b>D Data
|
|
Models</b></a> for details). In other cases (namely when the
|
|
<final> element is a child of <scxml> and the state
|
|
machine has not been triggered by <invoke>), the SCXML
|
|
processor <em title="SHOULD in RFC2119 context"
|
|
class="RFC2119">SHOULD</em> return the data to the environment in
|
|
an implementation-dependent manner.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="content" name="content" />5.7 <content></h3>
|
|
|
|
<p>A container element holding in-line data to be passed to an
|
|
external service.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10B25" name="N10B25" />5.7.1 Attribute Details</h4>
|
|
|
|
<p>None.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10B2A" name="N10B2A" />5.7.2 Children</h4>
|
|
|
|
<p>In a conformant SCXML document, the child elements of
|
|
<content> contain arbitrary markup which <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> consist of
|
|
text, XML from any namespace, or a mixture of both. The use of this
|
|
markup depends on the context in which the <content> element
|
|
occurs. See <a href="#donedata"><b>5.6 <donedata></b></a>, <a
|
|
href="#send"><b>6.2 <send></b></a> and <a
|
|
href="#invoke"><b>6.4 <invoke></b></a> for details. For the
|
|
use of namespaces inside <content>, see <a
|
|
href="#content_and_namespaces"><b>G.7 Inline Content and
|
|
Namespaces</b></a>.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="param" name="param" />5.8 <param></h3>
|
|
|
|
<p>The <param> tag provides a general way of identifying a
|
|
name/key and a dynamically calcuated value, which can be passed to
|
|
an external service or included in an event.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10B44" name="N10B44" />5.8.1 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>name</td>
|
|
<td>true</td>
|
|
<td />
|
|
<td>NMTOKEN</td>
|
|
<td>none</td>
|
|
<td>A string literal</td>
|
|
<td>The name of the key.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>expr</td>
|
|
<td>false</td>
|
|
<td>May not occur with 'location'</td>
|
|
<td>value expression</td>
|
|
<td>none</td>
|
|
<td>Valid value expression</td>
|
|
<td>A value expression (see <a href="#ValueExpressions"><b>5.10.3
|
|
Legal Data Values and Value Expressions</b></a>) that is evaluated
|
|
to provide the value.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>location</td>
|
|
<td>false</td>
|
|
<td>May not occur with 'expr'</td>
|
|
<td>location expression</td>
|
|
<td>none</td>
|
|
<td>Valid location expression</td>
|
|
<td>A location expression (see <a
|
|
href="#LocationExpressions"><b>5.10.2 Location Expressions</b></a>)
|
|
that specifies the location in the datamodel to use as the
|
|
value.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>A conformant SCXML document <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> specify either the 'expr' attribute of
|
|
<param> or the 'location' attribute, but <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
specify both. If the 'location' attribute does not refer to a valid
|
|
location in the data model, or if the evaluation of the 'expr'
|
|
produces an error, the processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> place the
|
|
error error.execution on the internal event queue and <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> ignore
|
|
the name and value. Otherwise the use of the name and value depends
|
|
on the context in which the <param> element occurs. See <a
|
|
href="#donedata"><b>5.6 <donedata></b></a>, <a
|
|
href="#send"><b>6.2 <send></b></a> and <a
|
|
href="#invoke"><b>6.4 <invoke></b></a> for details.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10BA5" name="N10BA5" />5.8.2 Children</h4>
|
|
|
|
<p>None.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="script" name="script" />5.9 <script></h3>
|
|
|
|
<p>The <script> element adds scripting capability to the
|
|
state machine.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10BB0" name="N10BB0" />5.9.1 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>src</td>
|
|
<td>false</td>
|
|
<td>May not occur if the element has children.</td>
|
|
<td />
|
|
<td>none</td>
|
|
<td>A valid URI</td>
|
|
<td>Gives the location from which the script should be
|
|
downloaded.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10BD6" name="N10BD6" />5.9.2 Children</h4>
|
|
|
|
<p>The children of the <script> element represent the script
|
|
code to be executed.</p>
|
|
</div>
|
|
|
|
<p>A conformant SCXML document <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> specify either the 'src' attribute or
|
|
child content, but not both. If 'src' is specified, the SCXML
|
|
Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> download the script from the specified
|
|
location at load time. If the script can not be downloaded within a
|
|
platform-specific timeout interval, the document is considered
|
|
non-conformant, and the platform <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> reject
|
|
it.</p>
|
|
|
|
<p>The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> evaluate any <script> element that
|
|
is a child of <scxml> at document load time. It <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> evaluate
|
|
all other <script> elements as part of normal executable
|
|
content evaluation.</p>
|
|
|
|
<p>In a conformant SCXML document, the name of any script variable
|
|
<em title="MAY in RFC2119 context" class="RFC2119">MAY</em> be used
|
|
as a location expression (see <a
|
|
href="#LocationExpressions"><b>5.10.2 Location
|
|
Expressions</b></a>).</p>
|
|
|
|
<p>For an example of a data model incorporating scripting, see <a
|
|
href="#ecma-profile"><b>D.2 The ECMAScript Data Model</b></a>.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="Expressions" name="Expressions" />5.10 Expressions</h3>
|
|
|
|
<p>SCXML contains three types of expressions, as described below.
|
|
Different datamodels will support different languages for these
|
|
expression types, but certain properties of the expressions are
|
|
constant across languages and are defined here.</p>
|
|
|
|
<p>The SCXML processor <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> optimize expression evaluation. Thus the
|
|
SCXML processor <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> not evaluate expressions as often as
|
|
indicated in <a href="#AlgorithmforSCXMLInterpretation"><b>A
|
|
Algorithm for SCXML Interpretation</b></a> or at the same points in
|
|
the algorithm.</p>
|
|
|
|
<p>When "late" data binding is used, accessing data substructure in
|
|
expressions before the corresponding <data> element is loaded
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> yield
|
|
the same execution-time behavior as accessing non-existent data
|
|
substructure in a loaded <data> instance. Such behavior is
|
|
defined by the data expression language in use.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="ConditionalExpressions"
|
|
name="ConditionalExpressions" />5.10.1 Conditional Expressions</h4>
|
|
|
|
<p>Conditional expressions are used inside the 'cond' attribute of
|
|
<transition>, <if> and <elseif>. The SCXML
|
|
processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> insure that boolean expressions do not
|
|
contain side effects that would effect the datamodel or the
|
|
execution of the state machine. If a conditional expression cannot
|
|
be evaluated as a boolean value ('true' or 'false') or if its
|
|
evaluation causes an error, the SCXML processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> treat the
|
|
expression as if it evaluated to 'false' and <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> place the
|
|
error 'error.execution' in the internal event queue. The set of
|
|
operators in conditional expressions varies depending on the
|
|
datamodel, but all datamodels <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> support the 'In()' predicate, which takes
|
|
a stateID as its argument and returns true if the state machine is
|
|
in that state. This predicate allows coordination among parallel
|
|
regions.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="LocationExpressions" name="LocationExpressions" />5.10.2
|
|
Location Expressions</h4>
|
|
|
|
<p>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 datamodel. For example, in the XPath
|
|
datamodel (<a href="#xpath-profile"><b>D.3 The XPath Data
|
|
Model</b></a>), the underlying data structure is an XML tree and
|
|
the set of valid locations consists of the existing nodes and
|
|
nodesets in the tree. If a location expression cannot be evaluated
|
|
to yield a valid location, the SCXML processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> place the
|
|
error error.execution in the internal event queue.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="ValueExpressions" name="ValueExpressions" />5.10.3 Legal
|
|
Data Values and Value Expressions</h4>
|
|
|
|
<p>A data model definition contains a specification of the
|
|
underlying data structure. For example, the XPath datamodel (<a
|
|
href="#xpath-profile"><b>D.3 The XPath Data Model</b></a>) defines
|
|
the data structure to be an XML tree. Such a specification of the
|
|
data structure implicitly defines a set of "legal data values",
|
|
namely the objects that can be part of such a data structure. 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 datamodel definition
|
|
specifies 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 SCXML processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> place the
|
|
error error.execution in the internal event queue.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="ErrorsinExpressions" name="ErrorsinExpressions" />5.10.4
|
|
Errors in Expressions</h4>
|
|
|
|
<p>The SCXML processor <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> reject documents containing syntactically
|
|
ill-formed expressions at document load time, or it <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> wait and
|
|
place error.execution in the internal event queue at runtime when
|
|
the expressions are evaluated. If the processor waits until it
|
|
evaluates the expressions at runtime to raise errors, it <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> raise
|
|
errors caused by expressions returning illegal values at the points
|
|
at which <a href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm
|
|
for SCXML Interpretation</b></a> indicates that the expressions are
|
|
to be evaluated. Note that this requirement holds even if the
|
|
implementation is optimizing expression evaluation.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="SystemVariables" name="SystemVariables" />5.11 System
|
|
Variables</h3>
|
|
|
|
<p>The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> maintain a protected portion of the data
|
|
model containing information that can be useful to applications. We
|
|
refer to the items in this special part of the data model as
|
|
'system variables'. Implementations <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> provide
|
|
the following system variables, and <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> support
|
|
others.</p>
|
|
|
|
<ul>
|
|
<li><em>_event</em>. The SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> use the
|
|
variable '_event' to hold a structure containing the current
|
|
event's name and any data contained in the event (see <a
|
|
href="#InternalStructureofEvents"><b>5.11.1 The Internal Structure
|
|
of Events</b></a>. The exact nature of the structure depends on the
|
|
datamodel being used. See <a href="#profiles"><b>D Data
|
|
Models</b></a> for details. The Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> bind the
|
|
_event variable when an event is pulled off the internal or
|
|
external event queue to be processed, and <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> keep the
|
|
variable bound to that event until another event is processed. (It
|
|
follows that when an application is testing the 'cond' attribute of
|
|
a <transition> element that contains an 'event' attribute,
|
|
_event will 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
|
|
was matched against a transition.) The SCXML Processor <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
bind _event at initialization time until the first event is
|
|
processed. Hence _event is unbound when the state machine starts
|
|
up. See <a href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm
|
|
for SCXML Interpretation</b></a> for details. If the data in the
|
|
event is not a legal instance of the data model language, and the
|
|
Processor cannot translate it into one, then the Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> place the
|
|
error error.execution in the internal event queue at the point at
|
|
which it attempts to bind _event. In this case, the Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> leave the
|
|
event data part of the _event structure unbound. (Note that the
|
|
event's name will still be available, however and that processing
|
|
of both the original event and the error event will proceed as
|
|
usual.)</li>
|
|
|
|
<li><em>_sessionid</em>. The Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> bind the
|
|
variable _sessionid at load time to the system-generated id for the
|
|
current SCXML session. (This is of of type NMTOKEN.) The Processor
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> keep
|
|
the variable bound to this value until the session terminates.</li>
|
|
|
|
<li><em>_name</em>. The Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> bind the
|
|
variable _name at load time to the value of the 'name' attribute of
|
|
the <scxml> element. The Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> keep the
|
|
variable bound to this value until the session terminates.</li>
|
|
|
|
<li><em>_ioprocessors</em>. The Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> bind the
|
|
variable _ioprocessors to a set of values, one for each Event I/O
|
|
Processor that it supports. The value associated with each I/O
|
|
Processor gives an address that external entities can use to
|
|
communicate with this SCXML session using that Event I/O Processor.
|
|
The underlying data structure and the syntax to access it depend on
|
|
the data model. See <a href="#profiles"><b>D Data Models</b></a>
|
|
for details. The nature of the values associated with the
|
|
individual Event I/O Processors depends on the Event I/O Processor
|
|
in question. See <a href="#eventioprocessors"><b>E Event I/O
|
|
Processors</b></a> for details. The Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> keep the
|
|
variable bound to this set of values until the session
|
|
terminates.</li>
|
|
|
|
<li><em>_x</em>. The variable _x is the root element for
|
|
platform-specific system variables. The Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> place all
|
|
platform-specific system variables underneath it. The exact
|
|
structure of the platform-specific variables depends on the data
|
|
model. For example, in the ECMAScript datamodel <a
|
|
href="#ecma-profile"><b>D.2 The ECMAScript Data Model</b></a>, '_x'
|
|
will be a top-level ECMAScript object and the platform-specific
|
|
system variables will be its properties.</li>
|
|
</ul>
|
|
|
|
<p>The set of system variables may be expanded in future versions
|
|
of this specification. Variable names beginning with '_' are
|
|
reserved for system use. A conformant SCXML document <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
contain ids beginning with '_' in the <data> element.
|
|
Platforms <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> place all platform-specific system
|
|
variables under the '_x' root.</p>
|
|
|
|
<p>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 <a href="#xpath-profile"><b>D.3
|
|
The XPath Data Model</b></a>. The Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> cause any
|
|
attempt to change the value of a system variable to fail and <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> place the
|
|
error error.execution on the internal event queue when such an
|
|
attempt is made.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="InternalStructureofEvents"
|
|
name="InternalStructureofEvents" />5.11.1 The Internal Structure of
|
|
Events</h4>
|
|
|
|
<p>Events have an internal structure which is reflected in the
|
|
_event variable. This variable can be accessed to condition
|
|
transitions (via boolean expressions in the 'cond' attribute) or to
|
|
update the datamodel (via <assign>), etc.</p>
|
|
|
|
<p>The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> insure that the following fields are
|
|
present in all events, whether internal or external.</p>
|
|
|
|
<ul>
|
|
<li><em>name</em>. 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.</li>
|
|
|
|
<li><em>type</em>. This field describes the event type. The SCXML
|
|
Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> set it to: "platform" (for events raised
|
|
by the platform itself, such as error events), "internal" (for
|
|
events raised by <raise> and <send> with target
|
|
'_internal') or "external" (for all other events).</li>
|
|
|
|
<li><em>sendid</em>. In the case of error events triggered by a
|
|
failed attempt to send an event, the Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> set this
|
|
field to the send id of the triggering <send> element.
|
|
Otherwise it <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> leave it blank.</li>
|
|
|
|
<li><em>origin</em>. This a URI, equivalent to the 'target'
|
|
attribute on the <send> element. If this event was received
|
|
from an external entity, the SCXML Processor <em
|
|
title="SHOULD in RFC2119 context" class="RFC2119">SHOULD</em> set
|
|
this field to a value which, in combination with the "origintype"
|
|
field, will allow the receiver of the event to <send> a
|
|
response back to the originating entity. Otherwise, the Processor
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> leave
|
|
this field blank.</li>
|
|
|
|
<li><em>origintype</em>. If this event was received from an
|
|
external entity, the SCXML Processor <em
|
|
title="SHOULD in RFC2119 context" class="RFC2119">SHOULD</em> set
|
|
this field to a value which, in combination with the 'origin'
|
|
field, will allow the receiver of the event to <send> a
|
|
response back to the originating entity. Otherwise, the Processor
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> leave
|
|
this field blank.</li>
|
|
|
|
<li><em>invokeid</em>. If this event is generated from an invoked
|
|
child process, the Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> set this field to the invoke id of the
|
|
invocation that triggered the child process. Otherwise it <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> leave it
|
|
blank.</li>
|
|
|
|
<li><em>data</em>. This field contains whatever data the sending
|
|
entity chose to include in this event. The receiving SCXML
|
|
Processor <em title="SHOULD in RFC2119 context"
|
|
class="RFC2119">SHOULD</em> reformat this data to match its data
|
|
model, but <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em> otherwise modify it. If the
|
|
conversion is not possible, the Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> leave the
|
|
field blank and <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> place an error in the internal event
|
|
queue.</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="external-module" name="external-module" />6 External
|
|
Communications</h2>
|
|
|
|
<div class="div2">
|
|
<h3><a id="ExternalIntroduction" name="ExternalIntroduction" />6.1
|
|
Introduction</h3>
|
|
|
|
<p>[This section is informative.]</p>
|
|
|
|
<p>The External Communications capability allows an SCXML session
|
|
to send and receive events from external entities, and to invoke
|
|
external services. <a href="#send"><b>6.2 <send></b></a>
|
|
provides "fire and forget" capability to deliver events and data to
|
|
any destination, including other SCXML sessions. The 'delay'
|
|
attribute allows for deferred event delivery and can be used to
|
|
implement a timer. The details of event transport as well as the
|
|
format of the event and data are determined by the Event I/O
|
|
Processor selected. Each implementation will support one or more
|
|
such processor, and the author of the SCXML markup can choose the
|
|
one that is appropriate for the type of endpoint he is trying to
|
|
reach.</p>
|
|
|
|
<p><a href="#invoke"><b>6.4 <invoke></b></a> offers a more
|
|
tightly coupled form of communication, specifically the ability to
|
|
trigger a platform-defined service and pass data to it. It 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> and
|
|
<content> elements and the 'namelist' attribute can 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 <em>before</em>
|
|
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.</p>
|
|
|
|
<p>When parallel states invoke the same external service
|
|
concurrently, separate instances of the external service will be
|
|
started. They can be distinguished by ids which are associated with
|
|
them. Similarly, the ids 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.</p>
|
|
|
|
<p>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 <em>after</em> 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 external events. (See <a
|
|
href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm for SCXML
|
|
Interpretation</b></a> for details.)</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="send" name="send" />6.2 <send></h3>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10D38" name="N10D38" />6.2.1 Overview</h4>
|
|
|
|
<p><send> is used to send events and data to external
|
|
systems, including external SCXML Interpreters, or to raise events
|
|
in the current SCXML session.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10D3D" name="N10D3D" />6.2.2 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>event</td>
|
|
<td>false</td>
|
|
<td>Must not occur with 'eventexpr'. If the type is 'scxml', either
|
|
this attribute or 'eventexpr' must be present.</td>
|
|
<td>EventType.datatype</td>
|
|
<td>none</td>
|
|
<td></td>
|
|
<td>A string indicating the name of message being generated. See <a
|
|
href="#schemas"><b>B Schema</b></a> for details on the data
|
|
type.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>eventexpr</td>
|
|
<td>false</td>
|
|
<td>Must not occur with 'event'. If the type is 'scxml', either
|
|
this attribute or 'event' must be present.</td>
|
|
<td>Value expression</td>
|
|
<td>none</td>
|
|
<td></td>
|
|
<td>A dynamic alternative to 'event'. If this attribute is present,
|
|
the SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> evaluate it when the parent <send>
|
|
element is evaluated and treat the result as if it had been entered
|
|
as the value of 'event'.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>target</td>
|
|
<td>false</td>
|
|
<td>Must not occur with 'targetexpr'</td>
|
|
<td>URI</td>
|
|
<td>none</td>
|
|
<td>A valid target URI</td>
|
|
<td>The unique identifier of the message target that the platform
|
|
should send the event to. See <a href="#SendTargets"><b>6.2.4 The
|
|
Target of Send</b></a> for details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>targetexpr</td>
|
|
<td>false</td>
|
|
<td>Must not occur with 'target'</td>
|
|
<td>Value expression</td>
|
|
<td>none</td>
|
|
<td>An expression evaluating to a valid target URI</td>
|
|
<td>A dynamic alternative to 'target'. If this attribute is
|
|
present, the SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> evaluate it when the parent <send>
|
|
element is evaluated and treat the result as if it had been entered
|
|
as the value of 'target'.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>type</td>
|
|
<td>false</td>
|
|
<td>Must not occur with 'typeexpr'</td>
|
|
<td>string</td>
|
|
<td>none</td>
|
|
<td></td>
|
|
<td>A token that specifies the transport mechanism for the message.
|
|
See <a href="#SendTypes"><b>6.2.5 The Type of Send</b></a> for
|
|
details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>typeexpr</td>
|
|
<td>false</td>
|
|
<td>Must not occur with 'type'</td>
|
|
<td>value expression</td>
|
|
<td>none</td>
|
|
<td></td>
|
|
<td>A dynamic alternative to 'type'. If this attribute is present,
|
|
the SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> evaluate it when the parent <send>
|
|
element is evaluated and treat the result as if it had been entered
|
|
as the value of 'type'.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>id</td>
|
|
<td>false</td>
|
|
<td>Must not occur with 'idlocation'.</td>
|
|
<td>xml:ID</td>
|
|
<td>none</td>
|
|
<td>Any valid token</td>
|
|
<td>A string literal to be used as the identifier for this instance
|
|
of <send>. See <a href="#IDs"><b>3.14 IDs</b></a> for
|
|
details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>idlocation</td>
|
|
<td>false</td>
|
|
<td>Must not occur with 'id'.</td>
|
|
<td>Location expression</td>
|
|
<td>none</td>
|
|
<td>Any valid location expression</td>
|
|
<td>Any location expression evaluating to a data model location in
|
|
which a system-generated id can be stored. See below for details.
|
|
for details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>delay</td>
|
|
<td>false</td>
|
|
<td>Must not occur with 'delayexpr' or when the attribute 'target'
|
|
has the value "_internal".</td>
|
|
<td>Duration.datatype</td>
|
|
<td>None</td>
|
|
<td>A time designation as defined in CSS2 <a
|
|
href="#CSS2">[CSS2]</a> format</td>
|
|
<td>Indicates how long the processor should wait before dispatching
|
|
the message. See <a href="#schemas"><b>B Schema</b></a> for details
|
|
on the data type.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>delayexpr</td>
|
|
<td>false</td>
|
|
<td>Must not occur with 'delay' or when the attribute 'target' has
|
|
the value "_internal".</td>
|
|
<td>Value expression</td>
|
|
<td>None</td>
|
|
<td>A value expression which returns a time designation as defined
|
|
in CSS2 <a href="#CSS2">[CSS2]</a> format</td>
|
|
<td>A dynamic alternative to 'delay'. If this attribute is present,
|
|
the SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> evaluate it when the parent <send>
|
|
element is evaluated and treat the result as if it had been entered
|
|
as the value of 'delay'.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>namelist</td>
|
|
<td>false</td>
|
|
<td>Must not be specified in conjunction with the <content>
|
|
element.</td>
|
|
<td>List of location expressions</td>
|
|
<td>none</td>
|
|
<td>List of data model locations</td>
|
|
<td>A space-separated list of one or more data model locations to
|
|
be included with the message. See <a
|
|
href="#LocationExpressions"><b>5.10.2 Location Expressions</b></a>
|
|
for details.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10E1E" name="N10E1E" />6.2.3 Children</h4>
|
|
|
|
<ul>
|
|
<li><param>. The SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> evaluate
|
|
this element when the parent <send> element is evaluated and
|
|
pass the resulting data unmodified to the external service when the
|
|
message is delivered. Occurs 0 or more times. See <a
|
|
href="#param"><b>5.8 <param></b></a> for details. If
|
|
<param> and 'namelist' both occur, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> place the
|
|
values generated by <param> after those in the 'namelist'. If
|
|
any <param> item has the same name as a 'namelist' item, the
|
|
SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> include both.</li>
|
|
|
|
<li><content>. The SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> extract
|
|
the children of this element when the parent <send> element
|
|
is evaluated and pass the resulting data unmodified to the external
|
|
service when the message is delivered. The material <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> consist of
|
|
non-XML markup or XML markup in any namespace. Occurs 0 or 1 times.
|
|
See <a href="#content"><b>5.7 <content></b></a> for
|
|
details.</li>
|
|
</ul>
|
|
|
|
<p>A conformant SCXML document <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> specify either 'event', 'eventexpr' or
|
|
in-line content. A conformant document <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
specify 'event' in conjunction with the inline content. A
|
|
conformant document <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em> specify both "namelist" and
|
|
<content>.</p>
|
|
|
|
<p>If 'idlocation' is present, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> generate
|
|
an id when the parent <send> element is evaluated and store
|
|
it in this location. See <a href="#IDs"><b>3.14 IDs</b></a> for
|
|
details.</p>
|
|
|
|
<p>If a delay is specified via 'delay' or 'delayexpr', the SCXML
|
|
Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> interpret the character string as a time
|
|
interval. It <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> dispatch the message only when the delay
|
|
interval elapses. (Note that the evaluation of the
|
|
<code>send</code> tag will return immediately.) The Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> evaluate
|
|
all arguments to <send> when the <send> element is
|
|
evaluated, and not when the message is actually dispatched. If the
|
|
SCXML session terminates before the delay interval has elapsed, the
|
|
SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> discard the message without attempting to
|
|
deliver it.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="SendTargets" name="SendTargets" />6.2.4 The Target of
|
|
Send</h4>
|
|
|
|
<p>The target of the <send> operation specifies the
|
|
destination of the event. The target is defined by either the
|
|
'target' or the 'targetexpr' attribute. In most cases, the format
|
|
of the target depends on the type of the target (for example a SIP
|
|
URL for SIP-INFO messages or a HTTP URL for Web Services). In
|
|
addition, this specification defines the following special values,
|
|
which SCXML Processors <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> support:</p>
|
|
|
|
<ul>
|
|
<li>#_internal. If the target is the special term '#_internal', the
|
|
Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> add the event to the internal event queue
|
|
of the sending session.</li>
|
|
|
|
<li>#_scxml_<em>sessionid</em>. If the target is the special term
|
|
'#_scxml_<em>sessionid</em>', where <em>sessionid</em> is the id of
|
|
an SCXML session that is accessible to the Processor, the Processor
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> add
|
|
the event to the external queue of that session. The set of SCXML
|
|
sessions that are accessible to a given SCXML Processor is
|
|
platform-dependent.</li>
|
|
|
|
<li>#_parent. If the target is the special term '#_parent', the
|
|
Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> add the event to the external event queue
|
|
of the SCXML session that invoked the sending session, if there is
|
|
one. See <a href="#invoke"><b>6.4 <invoke></b></a> for
|
|
details.</li>
|
|
|
|
<li>#_<em>invokeid</em>. If the target is the special term
|
|
'#_<em>invokeid</em>', where <em>invokeid</em> is the invokeid of
|
|
an SCXML session that the sending session has created by
|
|
<invoke>, the Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> must add the event to the external queue
|
|
of that session. See <a href="#invoke"><b>6.4
|
|
<invoke></b></a> for details.</li>
|
|
</ul>
|
|
|
|
<p>If neither the 'target' nor the 'targetexpr' attribute is
|
|
specified, the SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> add 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 or invalid, the
|
|
Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> place the error error.execution on the
|
|
internal event queue. If it is unable to reach the target, the
|
|
Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> place the error error.communication on
|
|
the internal event queue.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="SendTypes" name="SendTypes" />6.2.5 The Type of
|
|
Send</h4>
|
|
|
|
<p>The type of the <send> operation specifies the method that
|
|
the SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> use to deliver the message to its target.
|
|
A conformant SCXML document <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> use either the 'type' or the 'typeexpr'
|
|
attribute to define the type. If neither the 'type' nor the
|
|
'typeexpr' is defined, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> assume
|
|
the default value of 'scxml. If the SCXML Processor does not
|
|
support the type that is specified, it <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> place the
|
|
event error.execution on the internal event queue.</p>
|
|
|
|
<p>SCXML Processors <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> support the following type:</p>
|
|
|
|
<table border="1" cellpadding="2" cellspacing="2"
|
|
summary="send type values" width="100%">
|
|
<tbody>
|
|
<tr>
|
|
<th align="center">Value</th>
|
|
<th align="center">Details</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="center">"scxml"</td>
|
|
<td align="left">Target is an SCXML session. The transport
|
|
mechanism is platform-specific.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>For details on the 'scxml' type, see <a
|
|
href="#SCXMLEventProcessor"><b>E.1 SCXML Event I/O
|
|
Processor</b></a>.</p>
|
|
|
|
<p>Support for HTTP POST is optional, however Processors that
|
|
support it <em>must</em> use the following value for the "type"
|
|
attribute:</p>
|
|
|
|
<table border="1" cellpadding="2" cellspacing="2"
|
|
summary="send type values" width="100%">
|
|
<tbody>
|
|
<tr>
|
|
<th align="center">Value</th>
|
|
<th align="center">Details</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="center">"basichttp"</td>
|
|
<td align="left">Target is a URL. Data is sent via HTTP POST</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>For details on the 'basichttp' type, see <a
|
|
href="#BasicHTTPEventProcessor"><b>E.2 Basic HTTP Event I/O
|
|
Processor</b></a>.</p>
|
|
|
|
<p>Support for DOM event delivery is optional, however Processors
|
|
that support it <em>must</em> use the following value for the
|
|
"type" attribute:</p>
|
|
|
|
<table border="1" cellpadding="2" cellspacing="2"
|
|
summary="send type values" width="100%">
|
|
<tbody>
|
|
<tr>
|
|
<th align="center">Value</th>
|
|
<th align="center">Details</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="center">"DOM"</td>
|
|
<td align="left">Target is a node in the current document, which
|
|
may contain markup from multiple namespaces. A DOM event will be
|
|
targeted at that node.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>For details on the 'DOM' type, see <a
|
|
href="#DOMEventProcessor"><b>E.3 DOM Event I/O
|
|
Processor</b></a>.</p>
|
|
|
|
<p>Processors <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> support other types such as web-services,
|
|
SIP or basic HTTP GET. However, they <em
|
|
title="SHOULD in RFC2119 context" class="RFC2119">SHOULD</em>
|
|
assign such types names beginning with "x-" to signify that they
|
|
are platform dependent.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="SendContent" name="SendContent" />6.2.6 Message
|
|
Content</h4>
|
|
|
|
<p>The sending SCXML Interpreter <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> not alter
|
|
the content of the <send> and <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> include
|
|
it in the message that it sends to the destination specified in the
|
|
target attribute of <send>.</p>
|
|
|
|
<p>Note that the document author can specify the message content in
|
|
one of two mutually exclusive ways:</p>
|
|
|
|
<ul>
|
|
<li>An optional 'event' attribute, combined with an optional
|
|
'namelist' attribute, combined with 0 or more <param>
|
|
children. Here is an example using the 'event' and 'namelist'
|
|
attributes:
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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"/>
|
|
</pre>
|
|
</div>
|
|
</li>
|
|
|
|
<li>A single <content> child containing explicit inline XML
|
|
content specifying the message body. See <a href="#content"><b>5.7
|
|
<content></b></a> for details.
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>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.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="cancel" name="cancel" />6.3 <cancel></h3>
|
|
|
|
<p>The <cancel> element is used to cancel a delayed
|
|
<send> event. The SCXML Processor <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
allow <cancel> to affect events that were not raised in the
|
|
same document. The Processor <em title="SHOULD in RFC2119 context"
|
|
class="RFC2119">SHOULD</em> make its best attempt to cancel the
|
|
delayed event. Note, however, that it can not be guaranteed to
|
|
succeed, for example if the event has already been delivered by the
|
|
time the <cancel> tag executes.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10F61" name="N10F61" />6.3.1 Attribute Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>sendid</td>
|
|
<td>false</td>
|
|
<td>Must not occur with sendidexpr.</td>
|
|
<td>IDREF</td>
|
|
<td>none</td>
|
|
<td>The ID of a delayed event</td>
|
|
<td>The ID of the event which is to be canceled.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>sendidexpr</td>
|
|
<td>false</td>
|
|
<td>Must occur with sendid.</td>
|
|
<td>Value Expression</td>
|
|
<td>none</td>
|
|
<td>Any expression that evaluates to the ID of a delayed event</td>
|
|
<td>A dynamic alternative to 'sendid'. If this attribute is
|
|
present, the SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> evaluate it when the parent
|
|
<cancel> element is evaluated and treat the result as if it
|
|
had been entered as the value of 'sendid'.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<p>A conformant SCXML document <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> specify exactly one of sendid or
|
|
sendidexpr.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N10F9F" name="N10F9F" />6.3.2 Children</h4>
|
|
|
|
<p>None</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="invoke" name="invoke" />6.4 <invoke></h3>
|
|
|
|
<p>The <invoke element is used to create an instance of an
|
|
external service.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="invokeattrs" name="invokeattrs" />6.4.1 Attribute
|
|
Details</h4>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>type</td>
|
|
<td>false</td>
|
|
<td>Must not occur with the 'typeexpr' attribute.</td>
|
|
<td>NMTOKEN</td>
|
|
<td>none</td>
|
|
<td>'scxml', 'vxml2', 'vxml3', 'ccxml', plus other
|
|
platform-specific values.</td>
|
|
<td>A string specifying the type of the external service. See below
|
|
for details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>typeexpr</td>
|
|
<td>false</td>
|
|
<td>Must not occur with the 'type' attribute.</td>
|
|
<td>value expression</td>
|
|
<td>none</td>
|
|
<td>Any value expression that evaluates to a character string that
|
|
would be a valid value for 'type'.</td>
|
|
<td>A dynamic alternative to 'type'. If this attribute is present,
|
|
the SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> evaluate it when the parent
|
|
<invoke> element is evaluated and treat the result as if it
|
|
had been entered as the value of 'type'.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>src</td>
|
|
<td>false</td>
|
|
<td>Must not occur with the 'srcexpr' attribute or the
|
|
<content> element.</td>
|
|
<td>URI</td>
|
|
<td>None</td>
|
|
<td>Any URI.</td>
|
|
<td>A URI to be passed to the external service. See below for
|
|
details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>srcexpr</td>
|
|
<td>false</td>
|
|
<td>Must not occur with the 'src' attribute or the <content>
|
|
element.</td>
|
|
<td>Value expression</td>
|
|
<td>None</td>
|
|
<td>Any expression evaluating to a valid URI.</td>
|
|
<td>A dynamic alternative to 'src'. If this attribute is present,
|
|
the SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> evaluate it when the parent
|
|
<invoke> element is evaluated and treat the result as if it
|
|
had been entered as the value of 'src'.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>id</td>
|
|
<td>false</td>
|
|
<td>Must not occur with the 'idlocation' attribute.</td>
|
|
<td>ID</td>
|
|
<td>none</td>
|
|
<td>Any valid token</td>
|
|
<td>A string literal to be used as the identifier for this instance
|
|
of <invoke>. See <a href="#IDs"><b>3.14 IDs</b></a> for
|
|
details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>idlocation</td>
|
|
<td>false</td>
|
|
<td>Must not occur with the 'id' attribute.</td>
|
|
<td>Location expression</td>
|
|
<td>none</td>
|
|
<td>Any valid location expression</td>
|
|
<td>Any data model expression evaluating to a data model location.
|
|
See <a href="#LocationExpressions"><b>5.10.2 Location
|
|
Expressions</b></a> for details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>namelist</td>
|
|
<td>false</td>
|
|
<td>Must not occur with the <content> element.</td>
|
|
<td>List of location expressions</td>
|
|
<td>none</td>
|
|
<td>List of data model locations</td>
|
|
<td>A space-separated list of zero or more data model locations to
|
|
be passed to the invoked service. See See <a
|
|
href="#DataSharing"><b>6.4.4 Data Sharing</b></a> and <a
|
|
href="#LocationExpressions"><b>5.10.2 Location Expressions</b></a>
|
|
for details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>autoforward</td>
|
|
<td>false</td>
|
|
<td />
|
|
<td>boolean</td>
|
|
<td>false</td>
|
|
<td>true or false</td>
|
|
<td>A flag indicating whether to forward events to the invoked
|
|
process. See below for details.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N1104C" name="N1104C" />6.4.2 Children</h4>
|
|
|
|
<ul>
|
|
<li><param>. Element containing data to be passed to the
|
|
external service. Occurs 0 or more times. See <a
|
|
href="#param"><b>5.8 <param></b></a>.</li>
|
|
|
|
<li><finalize>. Element containing executable content to
|
|
massage the data returned from the invoked component. Occurs 0 or 1
|
|
times. See <a href="#finalize"><b>6.5 <finalize></b></a> for
|
|
details.</li>
|
|
|
|
<li><content>. Element containing arbitrary material to be
|
|
passed to the invoked component. The material <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> consist of
|
|
non-XML markup or XML markup in any namespace. Occurs 0 or 1 times.
|
|
See <a href="#content"><b>5.7 <content></b></a> for
|
|
details.</li>
|
|
</ul>
|
|
|
|
<p>A conformant SCXML Document <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
specify more than one of 'src', <param>, or <content>.
|
|
However it <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> specify <param> multiple times.</p>
|
|
</div>
|
|
|
|
<p>Platforms <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> support 'scxml' as a value for the 'type'
|
|
attribute. Platforms <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> 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 <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> support additional values, but they <em
|
|
title="SHOULD in RFC2119 context" class="RFC2119">SHOULD</em> name
|
|
the values beginning with "x-" to signify that they are platform
|
|
dependent.</p>
|
|
|
|
<p>A conformant SCXML document <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> specify either the 'id' or 'idlocation'
|
|
attribute, but <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em> specify both. If the 'idlocation'
|
|
attribute is present, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> generate
|
|
an id automatically when the <invoke> element is evaluated
|
|
and store it in the location specified by 'idlocation'. (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). The automatically generated identifier
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> have
|
|
the form <em>stateid.platformid</em>, where <em>stateid</em> is the
|
|
id of the state containing this element and <em>platformid</em> is
|
|
automatically generated. <em>platformid</em> <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> be unique
|
|
within the current session.</p>
|
|
|
|
<p>When the <invoke> element is executed, the SCXML Processor
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> start
|
|
a new logical instance of the external service specified in 'type'
|
|
or 'typexpr', passing it the URL specified by 'src' or the data
|
|
specified by <content>, or <param>. The service
|
|
instance <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> be local or remote. In addition to the
|
|
explicit arguments, the Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> keep
|
|
track of the unique invokeid and insure that it is included in all
|
|
events that the invoked service returns to the invoking
|
|
session.</p>
|
|
|
|
<p>When the 'autoforward' attribute is set to true, the SCXML
|
|
Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> send an exact copy of every external
|
|
event it receives to the invoked process. All the fields specified
|
|
in <a href="#InternalStructureofEvents"><b>5.11.1 The Internal
|
|
Structure of Events</b></a> <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> have the same values in the forwarded
|
|
copy of the event. The SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> forward
|
|
the event at the point at which it removes it from the external
|
|
event queue of the invoking session for processing. See <a
|
|
href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm for SCXML
|
|
Interpretation</b></a> for details.</p>
|
|
|
|
<p>The external service <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> return multiple events while it is
|
|
processing. If there is a <finalize> handler in the instance
|
|
of <invoke> that created the service that generated the
|
|
event, the SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> execute the code in that <finalize>
|
|
handler right before it removes the event from the event queue for
|
|
processing. It <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em> execute the <finalize> handler
|
|
in any other instance of <invoke>. Once the external service
|
|
has finished processing it <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> return a special event
|
|
'done.invoke.<em>id</em>' to the external event queue of the
|
|
invoking process, where <em>id</em> is the invokeid for the
|
|
corresponding <invoke> element. The external service <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
generate any other events after this done event. If the invoking
|
|
session takes a transition out of the state containing the
|
|
<invoke> before it receives the 'done.invoke.<em>id</em>'
|
|
event, the SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> automatically cancel the invoked
|
|
component and stop its processing. The cancel operation <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> act as if
|
|
it were the final <onexit> handler in the invoking state.</p>
|
|
|
|
<p>Invoked services of type 'scxml', 'ccxml', 'vxml2' or 'vxml3'
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em>
|
|
interpret values specified by the <content> element or 'src'
|
|
attribute as markup to be executed. Similarly, they <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> interpret
|
|
values specified by <param> element or 'namelist' attribute
|
|
as values that are to be injected into their data models. For
|
|
targets of other invoked service types, the interpretation of
|
|
<param> and <content> elements and the 'src' and
|
|
'namelist' attributes is platform-specific. However, these services
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> treat
|
|
values specified by <param> and namelist identically. They
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> also
|
|
treat values specified by 'src' and <content>
|
|
identically.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="invokeimplementation"
|
|
name="invokeimplementation" />6.4.3 Implementation of
|
|
<invoke></h4>
|
|
|
|
<p>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:</p>
|
|
|
|
<ul>
|
|
<li>If the 'name' of a <param> element in the <invoke>
|
|
matches the 'id' of a <data> element in the top-level data
|
|
declarations of the invoked session, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> use the
|
|
value of the <param> element as the initial value of the
|
|
corresponding <data> element. (The top-level data
|
|
declarations are those that are contained in the <datamodel>
|
|
element that is a child of <scxml>.) (Note that this means
|
|
that any value specified in the <data> element is ignored.)
|
|
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 session, the SCXML Processor
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> use
|
|
the value of the key as the initial value of the corresponding
|
|
<data> element. If the names do not match, the Processor <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
add the value of the <param> element or namelist key/value
|
|
pair the invoked session's data model. However the Processor <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> make the
|
|
values available by some other platform-specific means.</li>
|
|
|
|
<li>When the invoked state machine reaches a top-level final state,
|
|
the Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> place the event done.invoke.<em>id</em>
|
|
on the external event queue of the invoking machine, where
|
|
<em>id</em> is the invokeid for this 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.</li>
|
|
|
|
<li>As described above, if the invoking state machine exits the
|
|
state containing the invocation before it receives the
|
|
done.invoke.<em>id</em> event, it cancels the invoked session. To
|
|
do this, the Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> send the event cancel.invoke.<em>id</em>
|
|
to the invoked session, where <em>id</em> is the identifier
|
|
corresponding to the <invoke> element. When the invoked
|
|
session receives this event, the Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> act as if
|
|
the 'continue' variable specified in <a
|
|
href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm for SCXML
|
|
Interpretation</b></a> has been set to 'false'. (This will cause
|
|
the invoked session to exit at the end of the next microstep. Note
|
|
that the cancel.invoke.<em>id</em> is not inserted into the event
|
|
queue of the invoked session and is not visible to markup in the
|
|
invoked document.) The Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> execute
|
|
the <onexit> handlers for all active states in the invoked
|
|
session, but it <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em> generate the done.invoke.<em>id</em>
|
|
event. Once it cancels the invoked session, the Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> ignore
|
|
any events it receives from that session. In particular it <em
|
|
title="MUST NOT in RFC2119 context" class="RFC2119">MUST NOT</em>
|
|
not insert them into the external event queue of the invoking
|
|
session.</li>
|
|
|
|
<li>The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> use the SCXML Event/IO processor (<a
|
|
href="#SCXMLEventProcessor"><b>E.1 SCXML Event I/O
|
|
Processor</b></a>) to communicate between the invoking and the
|
|
invoked sessions.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="DataSharing" name="DataSharing" />6.4.4 Data
|
|
Sharing</h4>
|
|
|
|
<p>[This section is informative.]</p>
|
|
|
|
<p>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>
|
|
or <content> elements and/or the 'src' and 'namelist'
|
|
attributes.</p>
|
|
|
|
<p>The invoked and invoking process can also communicate via
|
|
events. In addition to automatic forwarding specified by the
|
|
'autoforward' attribute. SCXML scripts can also use the
|
|
<send> tag to send messages to the child process on an ad-hoc
|
|
basis. The 'type' attribute of <send> is set to the same
|
|
value as was used in the original <invoke>, while the target
|
|
has the special form #_<em>invokeid</em>, where <em>invokeid</em>
|
|
is the identifier corresponding to the original <invoke> tag.
|
|
For example, in a document using ECMAScript as the data model, the
|
|
following code would invoke a VXML session:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<invoke type="vxml" idlocation="myInvoke"/>
|
|
|
|
</pre>
|
|
</div>
|
|
|
|
<p>In this case, the unique invoke identifier has been stored in
|
|
the data model location 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:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
|
|
<send type="vxml" targetexpr="'#' + myInvoke"/>
|
|
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Finally, in the case where the invoked external service is an
|
|
SCXML session, it can use <send> with the special target
|
|
'_parent' and type 'scxml' to send events, possibly containing
|
|
data, to the invoking session.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="finalize" name="finalize" />6.5 <finalize></h3>
|
|
|
|
<p>The <finalize> element enables an invoking session to
|
|
update its data model with data contained in events returned by the
|
|
invoked session. <finalize> contains executable content that
|
|
is executed whenever the external service returns an event after
|
|
the <invoke> has been executed. This content is applied
|
|
before the system looks for transitions that match the event.
|
|
Within the executable content, the system variable '_event' can be
|
|
used to refer to the data contained in the event which is being
|
|
processed.In the case of parallel states, only the finalize code in
|
|
the original invoking state is executed.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N11150" name="N11150" />6.5.1 Attribute Details</h4>
|
|
|
|
<p>None.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N11155" name="N11155" />6.5.2 Children</h4>
|
|
|
|
<p><finalize>'s children consist of 0 or more elements of
|
|
executable content.</p>
|
|
</div>
|
|
|
|
<p>In a conformant SCXML document, the executable content inside
|
|
<finalize> <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em> raise events or invoke external
|
|
actions. In particular, the <send> and <raise> elements
|
|
<em title="MUST NOT in RFC2119 context" class="RFC2119">MUST
|
|
NOT</em> occur.</p>
|
|
|
|
<p>If no executable content is specified, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> update
|
|
the data model with any return values that have a name that matches
|
|
the 'location' attribute of a <param> element inside the
|
|
<invoke>. Thus the effect of an <invoke> with
|
|
<param> element with a 'location' attribute coupled with an
|
|
empty <finalize> element is first to send the part of the
|
|
data model specified by 'location' to the invoked component and
|
|
then to update that part of the 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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<scxml version="1.0" datamodel="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>
|
|
....
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="back">
|
|
<div class="div1">
|
|
<h2><a id="AlgorithmforSCXMLInterpretation"
|
|
name="AlgorithmforSCXMLInterpretation" />A Algorithm for SCXML
|
|
Interpretation</h2>
|
|
|
|
<p>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 <em>as if</em> they were using the algorithm defined
|
|
here.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<h2 id="InformalSemantics">Informal Semantics</h2>
|
|
|
|
<p>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.</p>
|
|
|
|
<h3 id="PrelimaryDefinitions">Preliminary definitions</h3>
|
|
|
|
<dl>
|
|
<dt class="label">state</dt>
|
|
|
|
<dd>An element of type <state>, <parallel>,
|
|
<final> or <scxml>.</dd>
|
|
|
|
<dt class="label">pseudo state</dt>
|
|
|
|
<dd>An element of type <initial> or <history>.</dd>
|
|
|
|
<dt class="label">transition target</dt>
|
|
|
|
<dd>A state, or an element of type <history>.</dd>
|
|
|
|
<dt class="label">atomic state</dt>
|
|
|
|
<dd>A state of type <state> with no child states, or a state
|
|
of type <final>.</dd>
|
|
|
|
<dt class="label">compound state</dt>
|
|
|
|
<dd>A state of type <state> with at least one child
|
|
state.</dd>
|
|
|
|
<dt class="label">configuration</dt>
|
|
|
|
<dd>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.</dd>
|
|
|
|
<dt class="label">source state</dt>
|
|
|
|
<dd>The source state of a transition is the atomic state from which
|
|
the transition departs.</dd>
|
|
|
|
<dt class="label">target state</dt>
|
|
|
|
<dd>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.</dd>
|
|
|
|
<dt class="label">targetless transition</dt>
|
|
|
|
<dd>A transition having zero target states.</dd>
|
|
|
|
<dt class="label">eventless transition</dt>
|
|
|
|
<dd>A transition lacking the 'event' attribute.</dd>
|
|
|
|
<dt class="label">external event</dt>
|
|
|
|
<dd>An SCXML event appearing in the external event queue. Such
|
|
events are either sent by external sources or generated with the
|
|
<send> element.</dd>
|
|
|
|
<dt class="label">internal event</dt>
|
|
|
|
<dd>An event appearing in the internal event queue. Such events are
|
|
either raised automatically by the platform or generated with the
|
|
<event> element.</dd>
|
|
|
|
<dt class="label">microstep</dt>
|
|
|
|
<dd>A microstep involves the processing of a single transition (or,
|
|
in the case of parallel states, a single set of transitions.) A
|
|
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.</dd>
|
|
|
|
<dt class="label">macrostep</dt>
|
|
|
|
<dd>A macrostep consists of a sequence (a chain) of microsteps, at
|
|
the end of which the state machine is in a stable state and ready
|
|
to process an external event. Each external event causes an SCXML
|
|
state machine to take exactly one macrostep. However, if the
|
|
external event does not enable any transitions, no microstep will
|
|
be taken, and the corresponding macrostep will be empty.</dd>
|
|
</dl>
|
|
|
|
<h3 id="PrinciplesandConstraints">Principles and Constraints</h3>
|
|
|
|
<p>We state here some principles and constraints, on the level of
|
|
semantics, that SCXML adheres to:</p>
|
|
|
|
<dl>
|
|
<dt class="label">Encapsulation</dt>
|
|
|
|
<dd>An SCXML processor is a <em>pure event processor</em>. 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.</dd>
|
|
|
|
<dt class="label">Causality</dt>
|
|
|
|
<dd>There shall be a <em>causal justification</em> 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.</dd>
|
|
|
|
<dt class="label">Determinism</dt>
|
|
|
|
<dd>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.</dd>
|
|
|
|
<dt class="label">Completeness</dt>
|
|
|
|
<dd>An SCXML interpreter must always treat an SCXML document as
|
|
<em>completely</em> 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).</dd>
|
|
|
|
<dt class="label">Run to completion</dt>
|
|
|
|
<dd>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.</dd>
|
|
|
|
<dt class="label">Termination</dt>
|
|
|
|
<dd>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.</dd>
|
|
</dl>
|
|
|
|
<h2 id="Algorithm">Algorithm</h2>
|
|
|
|
<p>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 <em>if</em> 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'.</p>
|
|
|
|
<h3 id="Datatypes">Datatypes</h3>
|
|
|
|
<p>These are the abstract datatypes that are used in the
|
|
algorithm.</p>
|
|
|
|
<pre>
|
|
datatype List
|
|
<code>function</code> head() // Returns the head of the list
|
|
<code>function</code> tail() // Returns the tail of the list
|
|
<code>function</code> append(l) // Returns the list appended with l
|
|
<code>function</code> filter(f) // Returns the list of elements that satisfy the predicate f
|
|
<code>function</code> some(f) // Returns true if some element in the list satisfies the predicate f
|
|
<code>function</code> every(f) // Returns true if every element in the list satisfies the predicate f
|
|
|
|
datatype OrderedSet
|
|
<code>procedure</code> add(e) // Adds e to the set if it is not already a member
|
|
<code>procedure</code> delete(e) // Deletes e from the set
|
|
<code>function</code> member(e) // Is e a member of set?
|
|
<code>function</code> isEmpty() // Is the set empty?
|
|
<code>function</code> toList() // Converts the set to a list that reflects the order in which elements were originally added.
|
|
<code>procedure</code> clear() // Remove all elements from the set (make it empty)
|
|
<code>function</code> diff(set2) // Returns an OrderedSet containing all members of OrderedSet that are not in set2, preserving the original set order.
|
|
|
|
|
|
datatype Queue
|
|
<code>procedure</code> enqueue(e) // Puts e last in the queue
|
|
<code>function</code> dequeue() // Removes and returns first element in queue
|
|
<code>function</code> isEmpty() // Is the queue empty?
|
|
|
|
datatype BlockingQueue
|
|
<code>procedure</code> enqueue(e) // Puts e last in the queue
|
|
<code>function</code> dequeue() // Removes and returns first element in queue, blocks if queue is empty
|
|
</pre>
|
|
|
|
<h3 id="GlobalVariables">Global variables</h3>
|
|
|
|
<p>The following variables are global from the point of view of the
|
|
algorithm. Their values will be set in the
|
|
procedureinterpret().</p>
|
|
|
|
<pre>
|
|
global configuration
|
|
global previousConfiguration
|
|
global statesToInvoke
|
|
global datamodel
|
|
global internalQueue
|
|
global externalQueue
|
|
global historyValue
|
|
global continue
|
|
global binding
|
|
</pre>
|
|
|
|
<h3 id="Predicates">Predicates</h3>
|
|
|
|
<p>The following binary predicates are used for determining the
|
|
order in which states are entered and exited.</p>
|
|
|
|
<pre>
|
|
<code><a id="entryOrder"
|
|
name="entryOrder">entryOrder</a></code> // Ancestors precede descendants, with document order being used to break ties
|
|
<code><a id="exitOrder"
|
|
name="exitOrder">exitOrder</a></code> // Descendants precede ancestors, with reverse document order being used to break ties
|
|
</pre>
|
|
|
|
<h3 id="ProceduresandFunctions">Procedures and Functions</h3>
|
|
|
|
<p>This section defines the procedures and functions that make up
|
|
the core of the SCXML interpreter.</p>
|
|
|
|
<h4 id="interpret"><code>procedure</code> interpret(scxml,id)</h4>
|
|
|
|
<p>The purpose of this procedure is to initialize the interpreter
|
|
and to start processing. It is called with a parsed representation
|
|
of an SCXML document.</p>
|
|
|
|
<p>In order to interpret an SCXML document, first convert initial
|
|
attributes to <initial> container children with transitions
|
|
to the state specified by the attribute (such transitions will not
|
|
contain any executable content). 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. Finally call enterState on the initial transition that is a
|
|
child of scxml and start the interpreter's event loop.</p>
|
|
|
|
<pre>
|
|
procedure interpret(doc):
|
|
expandScxmlSource(doc)
|
|
if not valid(doc): failWithError()
|
|
configuration = new OrderedSet()
|
|
previousConfiguration = new OrderedSet()
|
|
statesToInvoke = new OrderedSet()
|
|
datamodel = new Datamodel(doc)
|
|
executeGlobalScriptElements(doc)
|
|
internalQueue = new Queue()
|
|
externalQueue = new BlockingQueue()
|
|
continue = true
|
|
binding = doc.binding
|
|
if binding == "early":
|
|
initializeDatamodel(datamodel, doc)
|
|
enterState([doc.initial.transition])
|
|
startEventLoop()
|
|
</pre>
|
|
|
|
<h4 id="startEventLoop"><code>procedure</code>
|
|
startEventLoop()</h4>
|
|
|
|
<p>Upon entering the state machine, we take all internally enabled
|
|
transitions, namely those that either don't require an event or
|
|
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.</p>
|
|
|
|
<pre>
|
|
procedure startEventLoop():
|
|
initialStepComplete = false
|
|
until initialStepComplete:
|
|
enabledTransitions = selectEventlessTransitions()
|
|
if enabledTransitions.isEmpty():
|
|
if internalQueue.isEmpty():
|
|
initialStepComplete = true
|
|
else:
|
|
internalEvent = internalQueue.dequeue()
|
|
datamodel["event"] = internalEvent
|
|
enabledTransitions = selectTransitions(internalEvent)
|
|
if not enabledTransitions.isEmpty():
|
|
microstep(enabledTransitions.toList())
|
|
mainEventLoop()
|
|
</pre>
|
|
|
|
<h4 id="mainEventLoop"><code>procedure</code> mainEventLoop()</h4>
|
|
|
|
<p>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.)</p>
|
|
|
|
<p>Each iteration through the loop consists of three main steps: 1)
|
|
execute any <invoke> tags for 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. However special
|
|
preliminary processing is applied to the event if the state has
|
|
executed any <invoke> elements. First, if this event was
|
|
generated by an invoked process, apply <finalize> processing
|
|
to it. Secondly, if any <invoke> elements have autoforwarding
|
|
set, forward the event to them. These steps apply before the
|
|
transitions are taken. 3) Take any subsequent internally enabled
|
|
transitions, namely those that don't require an event or that are
|
|
triggered by an internal event.</p>
|
|
|
|
<p>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
|
|
<em>external</em> event queue contains events ext1 and ext2 and the
|
|
machine is in state s1. If processing ext1 takes the machine to s2
|
|
and generates <em>internal</em> event int1, and s2 contains a
|
|
transition t triggered by int1, the system is guaranteed to take t,
|
|
no matter what transitions s2 or other states have that would be
|
|
triggered by ext2. Note that this is true even though ext2 was
|
|
already in the external event queue when int1 was generated. In
|
|
effect, the algorithm treats the processing of int1 as finishing up
|
|
the processing of ext1.</p>
|
|
|
|
<pre>
|
|
procedure mainEventLoop():
|
|
while continue:
|
|
for state in statesToInvoke:
|
|
for inv in state.invoke:
|
|
invoke(inv)
|
|
statesToInvoke.clear()
|
|
previousConfiguration = configuration
|
|
externalEvent = externalQueue.dequeue() # this call blocks until an event is available
|
|
datamodel["event"] = externalEvent
|
|
for state in configuration:
|
|
for inv in state.invoke:
|
|
if inv.invokeid == externalEvent.invokeid: # event is the result of an <invoke> in this state
|
|
applyFinalize(inv, externalEvent)
|
|
if inv.autoforward:
|
|
send(inv.id, externalEvent)
|
|
enabledTransitions = selectTransitions(externalEvent)
|
|
if not enabledTransitions.isEmpty():
|
|
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():
|
|
if internalQueue.isEmpty():
|
|
macroStepComplete = true
|
|
else:
|
|
internalEvent = internalQueue.dequeue()
|
|
datamodel["event"] = internalEvent
|
|
enabledTransitions = selectTransitions(internalEvent)
|
|
if not enabledTransitions.isEmpty():
|
|
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()
|
|
</pre>
|
|
|
|
<h4 id="exitInterpreter"><code>procedure</code>
|
|
exitInterpreter()</h4>
|
|
|
|
<p>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. (Note that in
|
|
this case, the final state will be the only active state.) The
|
|
implementation of returnDoneEvent is platform-dependent, but if
|
|
this session is the result of an <invoke> in another SCXML
|
|
session, returnDoneEvent will cause the event
|
|
done.invoke.<id> to be placed in the external event queue of
|
|
that session, where <id> is the id generated in that session
|
|
when the <invoke> was executed.</p>
|
|
|
|
<pre>
|
|
procedure exitInterpreter():
|
|
statesToExit = configuration.toList().sort(exitOrder)
|
|
for s in statesToExit:
|
|
for content in s.onexit:
|
|
executeContent(content)
|
|
for inv in s.invoke:
|
|
cancelInvoke(inv)
|
|
configuration.delete(s)
|
|
if isFinalState(s) and isScxmlState(s.parent):
|
|
returnDoneEvent(s.donedata)
|
|
</pre>
|
|
|
|
<h4 id="selectEventlessTransitions"><code>function</code>
|
|
selectEventlessTransitions()</h4>
|
|
|
|
<p>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 it is taken. If the state has not been preempted, find a
|
|
transition with no 'event' attribute whose condition evaluates to
|
|
<code>true</code>. If multiple matching transitions are present,
|
|
take the first in document order. If none are present, search in
|
|
the state's ancestors in 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.</p>
|
|
|
|
<pre>
|
|
function selectEventlessTransitions():
|
|
enabledTransitions = new OrderedSet()
|
|
atomicStates = configuration.toList().filter(isAtomicState).sort(documentOrder)
|
|
for state in atomicStates:
|
|
if not isPreempted(state, enabledTransitions):
|
|
loop: for s in [state].append(getProperAncestors(state, null)):
|
|
for t in s.transition:
|
|
if not t.event and conditionMatch(t):
|
|
enabledTransitions.add(t)
|
|
break loop
|
|
return enabledTransitions
|
|
</pre>
|
|
|
|
<h4 id="selectTransitions"><code>function</code>
|
|
selectTransitions(event)</h4>
|
|
|
|
<p>The purpose of the selectTransitions()procedure is to collect
|
|
the transitions that are enabled by this event in the current
|
|
configuration.</p>
|
|
|
|
<p>Create an empty set of <code>enabledTransitions</code>. For each
|
|
atomic state 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 it is taken. If the state has not been preempted, find
|
|
a transition whose 'event' attribute matches <code>event</code> and
|
|
whose condition evaluates to <code>true</code>. If multiple
|
|
matching transitions are present, take the first in document order.
|
|
If none are present, search in the state's ancestors in 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.</p>
|
|
|
|
<pre>
|
|
function selectTransitions(event):
|
|
enabledTransitions = new OrderedSet()
|
|
atomicStates = configuration.toList().filter(isAtomicState).sort(documentOrder)
|
|
for state in atomicStates:
|
|
if not isPreempted(state, enabledTransitions):
|
|
loop: for s in [state].append(getProperAncestors(state, null)):
|
|
for t in s.transition:
|
|
if t.event and nameMatch(t.event, event.name) and conditionMatch(t):
|
|
enabledTransitions.add(t)
|
|
break loop
|
|
return enabledTransitions
|
|
</pre>
|
|
|
|
<h4 id="isPreempted"><code>function</code> isPreempted(s
|
|
transitionList)</h4>
|
|
|
|
<p>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 thus 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.</p>
|
|
|
|
<pre>
|
|
function isPreempted(s, transitionList):
|
|
preempted = false
|
|
for t in transitionList:
|
|
if t.target:
|
|
LCA = findLCA([t.source].append(getTargetStates(t.target)))
|
|
if isDescendant(s,LCA):
|
|
preempted = true
|
|
break
|
|
return preempted
|
|
</pre>
|
|
|
|
<h4 id="microstepProcedure"><code>procedure</code>
|
|
microstep(enabledTransitions)</h4>
|
|
|
|
<p>The purpose of the microstep <code>procedure</code> is to
|
|
process a single set of transitions. These may have been 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.</p>
|
|
|
|
<p>If a single atomic state is active, then enabledTransitions will
|
|
contain only a single transition. If multiple states are active
|
|
(i.e., we are in a parallel region), then there may be multiple
|
|
transitions, one per active atomic state (though some states may
|
|
not select a transition.) In this case, the transitions are taken
|
|
in the document order of the atomic states that selected them.</p>
|
|
|
|
<pre>
|
|
procedure microstep(enabledTransitions):
|
|
exitStates(enabledTransitions)
|
|
executeTransitionContent(enabledTransitions)
|
|
enterStates(enabledTransitions)
|
|
</pre>
|
|
|
|
<h4 id="exitStates"><code>procedure</code>
|
|
exitStates(enabledTransitions)</h4>
|
|
|
|
<p>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. Next remove all the
|
|
states on statesToExit from the set of states that will have invoke
|
|
processing done at the start of the next macrostep. (Suppose
|
|
macrostep M1 consists of microsteps m11 and m12. We may enter state
|
|
s in m11 and exit it in m12. We will add s to statesToInvoke in
|
|
m11, and must remove it in m12. In the subsequent macrostep M2, we
|
|
will apply invoke processing to all states that were enter, and not
|
|
exited, in M1.) Then convert statesToExit to a list and sort it in
|
|
exitOrder.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<pre>
|
|
procedure exitStates(enabledTransitions):
|
|
statesToExit = new OrderedSet()
|
|
for t in enabledTransitions:
|
|
if t.target:
|
|
if t.type == "internal" and getTargetStates(t.target).every(lambda s: isDescendant(s,t.source)):
|
|
ancestor = t.source
|
|
else:
|
|
ancestor = findLCA([t.source].append(getTargetStates(t.target)))
|
|
for s in configuration:
|
|
if isDescendant(s,ancestor):
|
|
statesToExit.add(s)
|
|
for s in statesToExit:
|
|
statesToInvoke.delete(s)
|
|
statesToExit = statesToExit.toList().sort(exitOrder)
|
|
for s in statesToExit:
|
|
for h in s.history:
|
|
if h.type == "deep":
|
|
f = lambda s0: isAtomicState(s0) and isDescendant(s0,s)
|
|
else:
|
|
f = lambda s0: s0.parent == s
|
|
historyValue[h.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)
|
|
</pre>
|
|
|
|
<h4 id="executeTransitionContent"><code>procedure</code>
|
|
executeTransitionContent(enabledTransitions)</h4>
|
|
|
|
<p>For each transition in the list of
|
|
<code>enabledTransitions</code>, execute its executable
|
|
content.</p>
|
|
|
|
<pre>
|
|
procedure executeTransitionContent(enabledTransitions):
|
|
for t in enabledTransitions:
|
|
executeContent(t)
|
|
</pre>
|
|
|
|
<h4 id="enterStates"><code>procedure</code>
|
|
enterStates(enabledTransitions)</h4>
|
|
|
|
<p>Create an empty statesToEnter set, and an empty
|
|
statesForDefaultEntry set. For each transition t in
|
|
enabledTransitions, if t is targetless then do nothing, else for
|
|
each target state s, call addStatesToEnter. This will add to
|
|
statesToEnter s plus any descendent states that will have to be
|
|
entered by default once s is entered. (If s is atomic, there will
|
|
not be any such states.) Now for each target state s, add any of
|
|
s's ancestors that must be entered when s is entered. (These will
|
|
be any ancestors of s that are not currently active. Note that
|
|
statesToEnter is a set, so it is harmless if the same ancestor is
|
|
entered multiple times.) In the case where the ancestor state is
|
|
parallel, call addStatesToEnter on any of its child states that do
|
|
not already have a descendent on statesToEnter. (If a child state
|
|
already has a descendant on statesToEnter, it will get added to the
|
|
list when we examine the ancestors of that descendant.)</p>
|
|
|
|
<p>We now have a complete list of all the states that will be
|
|
entered as a result of taking the transitions in
|
|
enabledTransitions. Add them to statesToInvoke so that invoke
|
|
processing can be done at the start of the next macrostep. Convert
|
|
statesToEnter to a list and sort it in entryorder. For each state s
|
|
in the list, first add s to the current configuration. Then if we
|
|
are using late binding, and this is the first time we have entered
|
|
s, initialize its data model. Then execute any onentry handlers. If
|
|
s's initial state is being entered by default, execute any
|
|
executable content in the initial transition. Finally, if s is a
|
|
final state, generate relevant Done events. If we have reached a
|
|
top-level final state, set continue to false as a signal to stop
|
|
processing.</p>
|
|
|
|
<pre>
|
|
procedure enterStates(enabledTransitions):
|
|
statesToEnter = new OrderedSet()
|
|
statesForDefaultEntry = new OrderedSet()
|
|
for t in enabledTransitions:
|
|
if t.target:
|
|
tstates = getTargetStates(t.target)
|
|
if t.type == "internal" and tstates.every(lambda s: isDescendant(s,t.source)):
|
|
ancestor = t.source
|
|
else:
|
|
ancestor = findLCA([t.source].append(tstates))
|
|
for s in tstates:
|
|
addStatesToEnter(s,statesToEnter,statesForDefaultEntry)
|
|
for s in tstates:
|
|
for anc in getProperAncestors(s,ancestor):
|
|
statesToEnter.add(anc)
|
|
if isParallelState(anc):
|
|
for child in getChildStates(anc):
|
|
if not statesToEnter.some(lambda s: isDescendant(s,child)):
|
|
addStatesToEnter(child,statesToEnter,statesForDefaultEntry)
|
|
for s in statesToEnter:
|
|
statesToInvoke.add(s)
|
|
statesToEnter = statesToEnter.toList().sort(enterOrder)
|
|
for s in statesToEnter:
|
|
configuration.add(s)
|
|
if binding == "late" and s.isFirstEntry:
|
|
initializeDataModel(datamodel.s,doc.s)
|
|
s.isFirstEntry = false
|
|
for content in s.onentry:
|
|
executeContent(content)
|
|
if statesForDefaultEntry.member(s):
|
|
executeContent(s.initial.transition)
|
|
if isFinalState(s):
|
|
parent = s.parent
|
|
grandparent = parent.parent
|
|
internalQueue.enqueue(new Event("done.state." + parent.id, parent.donedata))
|
|
if isParallelState(grandparent):
|
|
if getChildStates(grandparent).every(isInFinalState):
|
|
internalQueue.enqueue(new Event("done.state." + grandparent.id, grandparent.donedata))
|
|
for s in configuration:
|
|
if isFinalState(s) and isScxmlState(s.parent):
|
|
continue = false
|
|
</pre>
|
|
|
|
<h4 id="addStatesToEnter"><code>procedure</code>
|
|
addStatesToEnter(state,root,statesToEnter,statesForDefaultEntry)</h4>
|
|
|
|
<p>The purpose of this procedure is to add to statesToEnter state
|
|
and/or any of its descendants that must be entered as a result of
|
|
state being the target of a transition. Note that this procedure
|
|
permanently modifies both statesToEnter and
|
|
statesForDefaultEntry.</p>
|
|
|
|
<p>First, If state is a history state then add either the history
|
|
values associated with state or state's default target to
|
|
statesToEnter. Else (if state is not a history state), add state to
|
|
statesToEnter. Then, if state is a a compound state, add state to
|
|
statesForDefaultEntry and recursively call addStatesToenter on its
|
|
default initial state(s). Otherwise, if state is a parallel state,
|
|
recursively call addStatesToEnter on each of its child states.</p>
|
|
|
|
<pre>
|
|
procedure addStatesToEnter(state,statesToEnter,statesForDefaultEntry):
|
|
if isHistoryState(state):
|
|
if historyValue[state.id]:
|
|
for s in historyValue[state.id]:
|
|
addStatesToEnter(s,statesToEnter,statesForDefaultEntry)
|
|
else:
|
|
for t in state.transition:
|
|
for s in getTargetStates(t.target):
|
|
addStatesToEnter(s,statesToEnter,statesForDefaultEntry)
|
|
else:
|
|
statesToEnter.add(state)
|
|
if isCompoundState(state):
|
|
statesForDefaultEntry.add(state)
|
|
for s in getTargetStates(state.initial):
|
|
addStatesToEnter(s,statesToEnter,statesForDefaultEntry)
|
|
elif isParallelState(state):
|
|
for s in getChildStates(state):
|
|
addStatesToEnter(s,statesToEnter,statesForDefaultEntry)
|
|
</pre>
|
|
|
|
<h4 id="isInFinalState"><code>procedure</code>
|
|
isInFinalState(s)</h4>
|
|
|
|
<p>Return true if s is a compound <state> and one of its
|
|
children is an active <final> state (i.e. is a member of the
|
|
current configuration), or if s is a <parallel> state and
|
|
isInFinalState is true of all its children.</p>
|
|
|
|
<pre>
|
|
function isInFinalState(s):
|
|
if isCompoundState(s):
|
|
return getChildStates(s).some(lambda s: isFinalState(s) and configuration.member(s))
|
|
elif isParallelState(s):
|
|
return getChildStates(s).every(isInFinalState)
|
|
else:
|
|
return false
|
|
</pre>
|
|
|
|
<h4 id="findLCA"><code>function</code> findLCA(stateList)</h4>
|
|
|
|
<p>The <a id="LCA" name="LCA">Least Common Ancestor</a> is the
|
|
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 an element since the <scxml> wrapper
|
|
element 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.</p>
|
|
|
|
<pre>
|
|
function findLCA(stateList):
|
|
for anc in getProperAncestors(stateList.head(), null):
|
|
if stateList.tail().every(lambda s: isDescendant(s,anc)):
|
|
return anc
|
|
</pre>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="schemas" name="schemas" />B Schema</h2>
|
|
|
|
<p>The schemas for SCXML can be found in <a
|
|
href="http://www.w3.org/2011/04/SCXML/">www.w3.org/2011/04/SCXML</a>.
|
|
The master schema is <a
|
|
href="http://www.w3.org/2011/04/SCXML/scxml.xsd">http://www.w3.org/2011/04/SCXML/scxml.xsd</a>.
|
|
The schema for SCXML messages is <a
|
|
href="http://www.w3.org/2011/04/SCXML/scxml.xsd">http://www.w3.org/2011/04/SCXML/scxml-message.xsd</a></p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="conformance" name="conformance" />C Conformance</h2>
|
|
|
|
<p>This section is normative.</p>
|
|
|
|
<div class="div2">
|
|
<h3><a id="ConformingDocuments" name="ConformingDocuments" />C.1
|
|
Conforming Documents</h3>
|
|
|
|
<p>The following conformance requirements hold for all SCXML
|
|
documents.</p>
|
|
|
|
<ol class="enumar">
|
|
<li>The root element of the document <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> be
|
|
<scxml>.</li>
|
|
|
|
<li>The <scxml> element <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> include a "version" attribute with the
|
|
value "1.0".</li>
|
|
|
|
<li>The <scxml> element <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> designate the SCXML namespace. This can
|
|
be achieved by declaring an "xmlns" attribute or an attribute with
|
|
an "xmlns" prefix <a href="#XMLNames">[XMLNames]</a>. The namespace
|
|
for SCXML is defined to be http://www.w3.org/2005/07/scxml.</li>
|
|
|
|
<li>The document <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> conform to all the syntactic constraints
|
|
defined in this specification, including those contained in the
|
|
schema, those contained in the "Attribute Constraints" and "Valid
|
|
Values" fields in the attribute tables, and those contained in the
|
|
definition of its children.</li>
|
|
|
|
<li>The document <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> conform to any additional syntactic
|
|
constraints that are defined for the data model that it has chosen.
|
|
See <a href="#profiles"><b>D Data Models</b></a> for the definition
|
|
of the individual data models.</li>
|
|
</ol>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="ConformingProcessors" name="ConformingProcessors" />C.2
|
|
Conforming Processors</h3>
|
|
|
|
<p>A SCXML 1.0 processor is a user agent that can parse and process
|
|
Conforming SCXML 1.0 documents.</p>
|
|
|
|
<p>In a Conforming SCXML 1.0 Processor, the XML parser <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> be able
|
|
to parse and process all well-formed XML constructs defined within
|
|
<a href="#XML">[XML]</a> and <a href="#XMLNames">[XMLNames]</a>. It
|
|
is not required that a Conforming SCXML 1.0 processor use a
|
|
validating parser.</p>
|
|
|
|
<p>A Conforming SCXML 1.0 Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> support
|
|
the syntax and semantics of all mandatory SCXML elements described
|
|
in this document. A Conforming SCXML 1.0 Processor <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> support the
|
|
syntax and semantics of any optional SCXML elements described in
|
|
this document. A Conforming SCXML 1.0 Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> behave as
|
|
if it were executing the algorithm specified in <a
|
|
href="#AlgorithmforSCXMLInterpretation"><b>A Algorithm for SCXML
|
|
Interpretation</b></a>.</p>
|
|
|
|
<p>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, it <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> behave as
|
|
instructed by the 'exmode' attribute.</p>
|
|
|
|
<p>When a Conforming SCXML 1.0 Processor encounters a nonconformant
|
|
document, then if 'exmode' is "strict", it <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> reject
|
|
the document and <em title="SHOULD in RFC2119 context"
|
|
class="RFC2119">SHOULD</em> signal an error to the entity that
|
|
requested the execution of the document. The means of signaling
|
|
this error are platform-specific and outside the scope of this
|
|
specification. Note specifically that in this case, a Conforming
|
|
SCXML Processor <em title="MUST NOT in RFC2119 context"
|
|
class="RFC2119">MUST NOT</em> enter the initial state of a
|
|
nonconformant SCXML document. When a Conforming SCXML 1.0 Processor
|
|
encounters a nonconformant document, and 'exmode' is not "strict",
|
|
its behavior is undefined.</p>
|
|
|
|
<p>There is no conformance requirement with respect to performance
|
|
characteristics of the SCXML 1.0 Processor.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="profiles" name="profiles" />D Data Models</h2>
|
|
|
|
<p>The 'datamodel' attribute on <scxml> defines the data
|
|
model that the document uses. The data model includes the
|
|
underlying data structure plus languages for boolean expressions,
|
|
location expressions, value expressions, and scripting. Each
|
|
conformant SCXML document <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> specify the data model it uses. (Note
|
|
that the "null" data model is the default.) Conformant SCXML
|
|
processors <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> support the null data model, and <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> support
|
|
other data models, including the ECMAScript and XPath data models.
|
|
The ECMAScript and XPath model definitions given here are normative
|
|
in the sense that they define how implementations that support one
|
|
of these languages <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> 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.</p>
|
|
|
|
<p>The definition of a data model <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em>:</p>
|
|
|
|
<ul>
|
|
<li>Specify the boolean expression language used as the value of
|
|
the'cond' attribute in <transition>, <if> and
|
|
<elseif> This language <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> not have side effects and <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> include
|
|
the predicate 'In', which takes a single argument, the id of a
|
|
state in the enclosing state machine, and returns 'true' if the
|
|
state machine is in that state.</li>
|
|
|
|
<li>Specify the location expression language that is used as the
|
|
value of the 'location' attribute of the <assign> tag.</li>
|
|
|
|
<li>Specify the value expression language that is used as the value
|
|
of the 'expr' attribute of the <data> and <assign>
|
|
elements.</li>
|
|
|
|
<li>Specify the scripting language used inside the <script>
|
|
element</li>
|
|
</ul>
|
|
|
|
<div class="div2">
|
|
<h3><a id="minimal-profile" name="minimal-profile" />D.1 The Null
|
|
Data Model</h3>
|
|
|
|
<p>The value "null" for the 'datamodel' attribute results in an
|
|
absent or empty data model. In particular:</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N11387" name="N11387" />D.1.1 Data Model</h4>
|
|
|
|
<p>There is no underlying data model.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N1138C" name="N1138C" />D.1.2 Conditional
|
|
Expressions</h4>
|
|
|
|
<p>The boolean expression language consists of the In predicate
|
|
<em>only</em>. It has the form 'In(<em>id</em>)', where <em>id</em>
|
|
is the id of a state in the enclosing state machine. The predicate
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em>
|
|
return 'true' if and only if that state is in the current state
|
|
configuration.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N1139D" name="N1139D" />D.1.3 Location Expressions</h4>
|
|
|
|
<p>There is no location expression language.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N113A2" name="N113A2" />D.1.4 Value Expressions</h4>
|
|
|
|
<p>There is no value expression language.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N113A7" name="N113A7" />D.1.5 Scripting</h4>
|
|
|
|
<p>There is no scripting language.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N113AC" name="N113AC" />D.1.6 System Variables</h4>
|
|
|
|
<p>System variables are not accessible.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N113B1" name="N113B1" />D.1.7 Unsupported Elements</h4>
|
|
|
|
<p>The <foreach> element and the elements defined in <a
|
|
href="#data-module"><b>5 Data Model and Data Manipulation</b></a>
|
|
are not supported in the Null Data Model. If the SCXML processor
|
|
encounters a document specifying the Null Data Model and containing
|
|
one of these elements, it <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> behave as instructed by the 'exmode'
|
|
attribute on <scxml>. See <a href="#scxml"><b>3.2
|
|
<scxml></b></a> for details.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="ecma-profile" name="ecma-profile" />D.2 The ECMAScript
|
|
Data Model</h3>
|
|
|
|
<p>The value 'ecmascript' for the 'datamodel' attribute results in
|
|
an ECMASccript data model. Implementations that support this value
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em>
|
|
support the third edition of ECMAScript <a
|
|
href="#ECMAScript262">[ECMASCRIPT-262]</a>. Implementations <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> support
|
|
ECMAScript for XML (E4X) <a href="#E4X">[E4X]</a>.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="ecma_core_module" name="ecma_core_module" />D.2.1 Data
|
|
Model</h4>
|
|
|
|
<p>For each <data> element in the document, the SCXML
|
|
Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> create an ECMAScript variable object
|
|
whose name is the value of the "id" attribute of
|
|
<code><data></code>. Note that the value of the variable can
|
|
be assigned in one of the following three ways:</p>
|
|
|
|
<ul>
|
|
<li>value of the "expr" attribute</li>
|
|
|
|
<li>resource referenced by the value of the "src" attribute</li>
|
|
|
|
<li>inline content</li>
|
|
</ul>
|
|
|
|
<p>If no value is assigned, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> assign
|
|
the variable the default value ECMAScript undefined. Note that the
|
|
assignment takes place at the time indicated by the 'binding'
|
|
attribute on the <scxml> element.</p>
|
|
|
|
<p>The Processor <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> support evaluation of JSON expressions and
|
|
of XML expressions.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N113ED" name="N113ED" />Example:
|
|
Datamodel <data> initialization</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<scxml version="1.0" datamodel="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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>The Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> place all variables in a single global
|
|
ECMAScript scope.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="ecma_cond_expressions"
|
|
name="ecma_cond_expressions" />D.2.2 Conditional Expressions</h4>
|
|
|
|
<p>The Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> convert ECMAScript expressions used in
|
|
conditional expressions into their effective boolean value using
|
|
the ToBoolean operator as described in Section 9.2 of <a
|
|
href="#ECMAScript262">[ECMASCRIPT-262]</a>.</p>
|
|
|
|
<p>The following example illustrates this usage.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N11406" name="N11406" />Example:
|
|
Use of a boolean expression to determine whether or not a
|
|
transition is taken.</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<state id="errorSwitch">
|
|
<datamodel>
|
|
<data id="time"/>
|
|
</datamodel>
|
|
|
|
<onentry>
|
|
<assign location="time" expr="currentDateTime()"/>
|
|
</onentry>
|
|
|
|
<transition cond="yearFromDatetime(time) > 2009" target="newBehavior"/>
|
|
|
|
<transition target="currentBehavior"/>
|
|
</state>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>The SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> add an ECMAScript function to the SCXML
|
|
namespace that takes a stateID as its argument and returns 'true'
|
|
if that state is in the current state configuration, as described
|
|
in <a href="#ConditionalExpressions"><b>5.10.1 Conditional
|
|
Expressions</b></a>. Here is an example of its use, taken from <a
|
|
href="#MicrowaveParallel"><b>G.3 Microwave Example (Using
|
|
parallel)</b></a> below:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
|
|
<transition cond="In('closed')" target="cooking"/>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="ecma_location_expressions"
|
|
name="ecma_location_expressions" />D.2.3 Location Expressions</h4>
|
|
|
|
<p>The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> accept any ECMAScript left-hand-side
|
|
expression as a location expression. The following example
|
|
illustrates this usage. (Note that the example assumes that the
|
|
data loaded from http://http://example.com/employees.json creates
|
|
the necessary data structure, so that employees.employee[12].salary
|
|
exists when <assign> is evaluated. If it didn't, the
|
|
Processor would raise error.execution and the <assign> would
|
|
have no effect.)</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N11424" name="N11424" />Example:
|
|
Use of the location attribute of the assign to update the salary of
|
|
an employee.</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<state id="errorSwitch">
|
|
<datamodel>
|
|
<data id="employees" src="http://example.com/employees.json"/>
|
|
</datamodel>
|
|
|
|
<onentry>
|
|
<assign location="employees.employee[12].salary" expr="42000"/>
|
|
</onentry>
|
|
</state>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="ecma_value_expressions"
|
|
name="ecma_value_expressions" />D.2.4 Value Expressions</h4>
|
|
|
|
<p>The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> accept any ECMAScript expression as a
|
|
value expression.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N11433" name="N11433" />Example:
|
|
Copying event data into the local data model for the state.</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<state id="processEvent">
|
|
<datamodel>
|
|
<data id="myEvent"/>
|
|
</datamodel>
|
|
|
|
<onentry>
|
|
<assign location="myEvent" expr="_event.data"/>
|
|
</onentry>
|
|
</state>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="ecma_assign" name="ecma_assign" />D.2.5
|
|
<assign></h4>
|
|
|
|
<p>When evaluating an <assign> element in the ECMA data
|
|
model, the SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> replace the existing value at 'location'
|
|
with the value produced by evaluating 'expr'. If it is unable to do
|
|
so (for example, if 'location' evaluates to ECMAScript 'null' or
|
|
'undefined'), it <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> place the error error.execution on the
|
|
internal event queue.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="ecma_system_variables"
|
|
name="ecma_system_variables" />D.2.6 System Variables</h4>
|
|
|
|
<p>The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> define an ECMAScript read-only variable
|
|
for each system variable defined in <a
|
|
href="#SystemVariables"><b>5.11 System Variables</b></a>. The
|
|
<code>_sessionid</code> and <code>_name</code> system variables are
|
|
defined as variables with ECMAScript String values. The
|
|
<code>_event</code> system variable is defined as an object with
|
|
properties for each of the fields defined in <a
|
|
href="#InternalStructureofEvents"><b>5.11.1 The Internal Structure
|
|
of Events</b></a>: <code>name</code>,<code>type</code>,
|
|
<code>sendid</code>, <code>origin</code>, <code>origintype</code>,
|
|
and <code>invokeid</code> are String values, while
|
|
<code>data</code> is an Object value.</p>
|
|
|
|
<p>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:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
{ "answer" : 42 }
|
|
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Then the underlying ECMA datamodel would have the following
|
|
form:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N1147A" name="N1147A" />Example:
|
|
Illustration of system injected properties</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
{
|
|
// 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
|
|
}
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>As an example, here is a sample transition that accesses the
|
|
<code>_event</code> variable in that data model.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N11485" name="N11485" />Example:
|
|
Accessing system _event name in a condition</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<state id="checkEventName">
|
|
<transition cond="_event.name=='foo.bar'" target="nextState">
|
|
...
|
|
</transition>
|
|
</state>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="ecma_script_module" name="ecma_script_module" />D.2.7
|
|
Scripting</h4>
|
|
|
|
<p>The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> accept any ECMAScript program as defined
|
|
in Section 14 of <a href="#ECMAScript262">[ECMASCRIPT-262]</a> as
|
|
the content of a <script> element.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="ecma_foreach" name="ecma_foreach" />D.2.8
|
|
<foreach></h4>
|
|
|
|
<p>In the ECMA data model, the 'array' value expression <em
|
|
title="SHOULD in RFC2119 context" class="RFC2119">SHOULD</em>
|
|
evaluate to an ECMAScript array (i.e. the result of the expression
|
|
<em title="SHOULD in RFC2119 context" class="RFC2119">SHOULD</em>
|
|
satisfy instanceof(Array) in ECMAScript). The 'item' attribute <em
|
|
title="SHOULD in RFC2119 context" class="RFC2119">SHOULD</em>
|
|
specify a legal ECMAScript variable name. The iteration order is
|
|
the order of the underlying ECMAScript array, and goes from an
|
|
index of 0 by increments of one to an index of array_name.length -
|
|
1. Note that since shallow copy is required <foreach>
|
|
assignment is equivalent to item = array_name[index] in ECMAScript.
|
|
Note also that the assigned value could be undefined for a sparse
|
|
array.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N114A6" name="N114A6" />Example:
|
|
Logging ISBN of all books in bookstore shopping cart</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<foreach collection="cart.books" item="book">
|
|
<log expr="'Cart contains book with ISBN ' + book.isbn"/>
|
|
</foreach>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N114AC" name="N114AC" />D.2.9 Unsupported Elements</h4>
|
|
|
|
<p><a href="#validate"><b>5.5 <validate></b></a> is not
|
|
supported in the ECMA Data Model. If the SCXML processor encounters
|
|
a document specifying the ECMA Data Model and containing this
|
|
element, it <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> behave as instructed by the 'exmode'
|
|
attribute on <scxml>. See <a href="#scxml"><b>3.2
|
|
<scxml></b></a> for details.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="xpath-profile" name="xpath-profile" />D.3 The XPath Data
|
|
Model</h3>
|
|
|
|
<p>The value "xpath" for the 'datamodel' attribute results in an
|
|
XML data model with XPath used as the expression language.
|
|
Implementations that support this data model <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> support
|
|
<a href="#XPATH2">[XPath 2.0]</a>.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="xpath-datamodel" name="xpath-datamodel" />D.3.1 Data
|
|
Model</h4>
|
|
|
|
<p>For each <data> element in the document, the SCXML
|
|
Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> create an XPath variable whose name is
|
|
the value of the 'id' attribute of the element. Note that the value
|
|
of the variable can be assigned in one of the following three
|
|
ways:</p>
|
|
|
|
<ul>
|
|
<li>by means of the 'expr' attribute</li>
|
|
|
|
<li>by means of a resource referenced by the 'src' attribute</li>
|
|
|
|
<li>by means of inline content</li>
|
|
</ul>
|
|
|
|
<p>If no value is assigned, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> assign
|
|
the variable the default value as the following DOM node:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
<data xmlns=""></data>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Note that the assignment takes place at the time indicated by
|
|
the 'binding' attribute on the <scxml> element.</p>
|
|
|
|
<p>The Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> place all variables in a single global
|
|
XPath scope, such that they are subsequently available to all
|
|
expressions within the document.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N114E5" name="N114E5" />Example:
|
|
Syntax for XPath datamodel initialization</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<scxml version="1.0" datamodel="xpath">
|
|
<datamodel>
|
|
<data id="company">
|
|
<about xmlns="">
|
|
<name>Example company</name>
|
|
<website>example.com</website>
|
|
<CEO>John Doe</CEO>
|
|
</about>
|
|
</data>
|
|
<data id="employees" src="http://example.com/employees.xml"/>
|
|
<data id="defaultdata"/>
|
|
</datamodel>
|
|
</scxml>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N114EB" name="N114EB" />D.3.2 Conditional
|
|
Expressions</h4>
|
|
|
|
<p>The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> accept any XPath 2.0 expression as a
|
|
conditional expression and <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> convert it into its effective boolean
|
|
value as described in section 2.4.3 of the <a href="#XPATH2">[XPath
|
|
2.0]</a> specification. The following example illustrates this
|
|
usage.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N114F9" name="N114F9" />Example:
|
|
Use of a boolean expression to determine whether or not a
|
|
transition is taken.</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>The SCXML processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> add an XPath function to the SCXML
|
|
namespace that takes a stateID as its argument and returns 'true'
|
|
if that state is in the current state configuration, as described
|
|
in <a href="#ConditionalExpressions"><b>5.10.1 Conditional
|
|
Expressions</b></a>. For examples of the use of this predicate (but
|
|
in an ECMAScript context), see <a href="#MicrowaveParallel"><b>G.3
|
|
Microwave Example (Using parallel)</b></a>.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<p>Function signature: <code>In($stateID as xs:string?) as
|
|
xs:boolean</code></p>
|
|
|
|
<p>Returns an <code>xs:boolean</code> indicating whether or not the
|
|
state with ID $stateID is one of the currently active states.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N11514" name="N11514" />D.3.3 Location Expressions</h4>
|
|
|
|
<p>The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> accept any XPath 2.0 expression as a
|
|
location expression. The following example illustrates this
|
|
usage:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N1151C" name="N1151C" />Example:
|
|
Use of the location attribute of the assign to update the count for
|
|
both Boston and New York.</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N11522" name="N11522" />D.3.4 Value Expressions</h4>
|
|
|
|
<p>The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> allow any XPath expression to be used as
|
|
a value expression. If the result of the value expression is a
|
|
node-set, the Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> make a deep copy of the subtree rooted at
|
|
each node.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N1152D" name="N1152D" />Example:
|
|
Copying event data into the local data model for the state.</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<state id="processEvent">
|
|
<datamodel>
|
|
<data id="myEventData"/>
|
|
</datamodel>
|
|
|
|
<onentry>
|
|
<assign location="$myEventData" expr="$_event/data"/>
|
|
</onentry>
|
|
</state>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="xpath_assign" name="xpath_assign" />D.3.5
|
|
<assign></h4>
|
|
|
|
<p>Implementations supporting the XPath datamdel <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> support
|
|
the following additional attributes for the <assign>
|
|
element.</p>
|
|
|
|
<table border="1" summary="attibute table">
|
|
<tbody>
|
|
<tr>
|
|
<th>Name</th>
|
|
<th>Required</th>
|
|
<th>Attribute Constraints</th>
|
|
<th>Type</th>
|
|
<th>Default Value</th>
|
|
<th>Valid Values</th>
|
|
<th>Description</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>type</td>
|
|
<td>false</td>
|
|
<td />
|
|
<td>enum</td>
|
|
<td>replacechildren</td>
|
|
<td>replacechildren, firstchild, lastchild, previoussibling,
|
|
nextsibling, replace, delete, addattribute</td>
|
|
<td>Defines the nature of the insertion to be performed. See below
|
|
for details.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>attr</td>
|
|
<td>false</td>
|
|
<td>This attribute must be present if and only if 'type' is
|
|
'addattribute'.</td>
|
|
<td>NMTOKEN</td>
|
|
<td>none</td>
|
|
<td></td>
|
|
<td>The attribute name to add at the specified location.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> modify the datamodel as directed by the
|
|
'type' attribute as described below. If it is unable to do so, it
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em> place
|
|
the error error.execution on the internal event queue:</p>
|
|
|
|
<ul>
|
|
<li>replacechildren. All the children at 'location' are replaced
|
|
with the value specified by 'expr'.</li>
|
|
|
|
<li>firstchild. The value specified by 'expr' is inserted before
|
|
all of the children at 'location'.</li>
|
|
|
|
<li>lastchild. The value specified by 'expr' is inserted after all
|
|
of the children at 'location'.</li>
|
|
|
|
<li>previoussibling. The value specified by 'expr' is inserted
|
|
before the node specified by 'location', keeping the same
|
|
parent.</li>
|
|
|
|
<li>nextsibling. The value specified by 'expr' is inserted after
|
|
the node specified by 'location', keeping the same parent.</li>
|
|
|
|
<li>replace. The node specified by 'location' is replaced by the
|
|
value specified by 'expr'.</li>
|
|
|
|
<li>delete. The node specified by 'location' is deleted. 'expr' is
|
|
ignored.</li>
|
|
|
|
<li>addattribute. An attribute with the name specified by 'attr'
|
|
and value specified by 'expr' is added to the node specified by
|
|
'location'.</li>
|
|
</ul>
|
|
|
|
<p>Note that in the case of an XML data model, it is not required
|
|
to assign to the root of a tree (i.e., the "name" value in a
|
|
<data> tag), since the path expression can reach down into
|
|
the tree to assign a new value to an internal node. The following
|
|
examples show various aspects of assignment in the XPath data
|
|
model. Suppose we have a data model of the following form:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Here is an example of assignment of a string to an element
|
|
node.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
|
|
<assign location="$cart/myCart/books/book[1]/title" expr="'My favorite book'"/>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>results in</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
<data id="cart">
|
|
<myCart xmlns="">
|
|
<books>
|
|
<book>
|
|
<title>My favorite book</title>
|
|
</book>
|
|
<book>
|
|
<title>Freakonomics</title>
|
|
</book>
|
|
...
|
|
</data>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Now suppose we assign an xml structure to an element node. The
|
|
following assignment statement would have the effect of replacing
|
|
the children of the element "$cart/myCart/books/book[1]" by the XML
|
|
tree rooted in <bookinfo>.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
<assign location="$cart/myCart/books/book[0]">
|
|
<bookinfo xmlns="">
|
|
<isdn>12334455</isdn>
|
|
<author>some author</author>
|
|
</bookinfo>
|
|
</assign>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>results in</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
<data id="cart">
|
|
<myCart xmlns="">
|
|
<books>
|
|
<book>
|
|
<bookinfo>
|
|
<isdn>12334455</isdn>
|
|
<author>some author</author>
|
|
</bookinfo>
|
|
</book>
|
|
<book>
|
|
<title>Freakonomics</title>
|
|
</book>
|
|
...
|
|
</data>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Here are examples of legal and illegal assignment to an
|
|
attribute:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
<!-- 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>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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":</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
<assign location="$cart/myCart/books/book" expr="'The Zen Mind'"/>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>results in</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
<data id="cart">
|
|
<myCart xmlns="">
|
|
<books>
|
|
<book>The Zen Mind</book>
|
|
<book>The Zen Mind</book>
|
|
</books>
|
|
...
|
|
</data>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
<assign location="$cart/myCart/books/book">
|
|
<price>20.0</price>
|
|
</assign>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>results in</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
<data id="cart">
|
|
<myCart xmlns="">
|
|
<books>
|
|
<book>
|
|
<price>20.0</price>
|
|
</book>
|
|
<book>
|
|
<price>20.0</price>
|
|
</book>
|
|
</books>
|
|
...
|
|
</data>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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>:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
|
|
<assign location="$cart/myCart/books/book[1]/ISBN" expr="'....'"/>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N115C9" name="N115C9" />D.3.6 System Variables</h4>
|
|
|
|
<p>The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> create an implicit <data> element
|
|
for each system variable defined in <a
|
|
href="#SystemVariables"><b>5.11 System Variables</b></a>.</p>
|
|
|
|
<p>Suppose as part of executing a state machine named "myName" with
|
|
a platform-assigned sessionid "12345", we are processing an event
|
|
with the name "foo.bar" and the following XML payload:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
<payload xmlns="">
|
|
<answer>42</answer>
|
|
</payload>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Then the underlying XML datamodel would have the following
|
|
form:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N115DC" name="N115DC" />Example:
|
|
Illustration of system injected data</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<datamodel>
|
|
|
|
<!-- 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 xmlns="">foo.bar</name>
|
|
<data xmlns="">
|
|
<payload>
|
|
<answer>42</answer>
|
|
</payload>
|
|
</data>
|
|
</data>
|
|
|
|
<!-- Rest of the application / developer-authored
|
|
data model goes here -->
|
|
|
|
</datamodel>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>As an example, here is a sample transition that accesses the
|
|
<code>$_sessionid</code> variable in that data model.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
<state id="checkSessionid">
|
|
<transition cond="$_sessionid = '12345'" target="nextState"/>
|
|
...
|
|
</state>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N115EB" name="N115EB" />D.3.7 Scripting</h4>
|
|
|
|
<p>There is no scripting language.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="XML_foreach" name="XML_foreach" />D.3.8
|
|
<foreach></h4>
|
|
|
|
<p>In the XPath data model, the 'array' value expression <em
|
|
title="SHOULD in RFC2119 context" class="RFC2119">SHOULD</em>
|
|
evaluate to an Node-set The 'item' attribute <em
|
|
title="SHOULD in RFC2119 context" class="RFC2119">SHOULD</em>
|
|
specify a legal XPath variable name. The iteration order is the
|
|
order of the underlying Node-set, and goes from an index of 1 by
|
|
increments of one to an index of count(node-set).</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N115FC" name="N115FC" />Example:
|
|
Logging ISBN of all books in bookstore shopping cart</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<foreach collection="$cart/books" item="book">
|
|
<log expr="'Cart contains book with ISBN ' + $book/isbn"/>
|
|
</foreach>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N11602" name="N11602" />D.3.9 Unsupported Elements</h4>
|
|
|
|
<p><a href="#script"><b>5.9 <script></b></a> is not supported
|
|
in the XPath Data Model. If the SCXML processor encounters a
|
|
document specifying the XPath Data Model and containing this
|
|
element, it <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> behave as instructed by the 'exmode'
|
|
attribute on <scxml>. See <a href="#scxml"><b>3.2
|
|
<scxml></b></a> for details.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="eventioprocessors" name="eventioprocessors" />E Event
|
|
I/O Processors</h2>
|
|
|
|
<div class="div2">
|
|
<h3><a id="SCXMLEventProcessor" name="SCXMLEventProcessor" />E.1
|
|
SCXML Event I/O Processor</h3>
|
|
|
|
<p>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 message and how it maps onto SCXML
|
|
events, but it does not define the transport mechanism, which is
|
|
platform-specific. The schema for the message is available at <a
|
|
href="http://www.w3.org/2011/04/SCXML/scxml.xsd">http://www.w3.org/2011/04/SCXML/scxml-message.xsd</a>.
|
|
SCXML Processors <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> support sending messages to and receiving
|
|
messages from other SCXML sessions using the SCXML Event I/O
|
|
Processor. An SCXML Processor <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> support exchanging messages with non-SCXML
|
|
endpoints using the SCXML Event I/O Processor. However this
|
|
specification defines the behavior for SCXML endpoints only.</p>
|
|
|
|
<p>The contents of the message are defined as follows:</p>
|
|
|
|
<ol>
|
|
<li>'name'. The sending SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> take the
|
|
value of this attribute from the 'event' attribute of the
|
|
<send> element. The receiving SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> use it as
|
|
the value the 'name' field in the event that it generates (see <a
|
|
href="#InternalStructureofEvents"><b>5.11.1 The Internal Structure
|
|
of Events</b></a>).</li>
|
|
|
|
<li>'source'. The sending SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> populate
|
|
this attribute with a URI that the receiving processor can use to
|
|
reply to the sending processor. The receiving SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> use this
|
|
URI as the value of the 'origin' field in the event that it
|
|
generates (see <a href="#InternalStructureofEvents"><b>5.11.1 The
|
|
Internal Structure of Events</b></a>).</li>
|
|
|
|
<li>'target'. The sending SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> take the
|
|
value of this attribute from the 'target' attribute of the
|
|
<send> element. The receiving SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> use this
|
|
value to determine which session to deliver the message to. See <a
|
|
href="#SendTargets"><b>6.2.4 The Target of Send</b></a> for details
|
|
on the interpretation of this identifier.</li>
|
|
|
|
<li>'sendid'. the sending SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> populate
|
|
this attribute with the identifier specified in the 'id' attribute
|
|
or automatically generated by the platform when the <send>
|
|
tag is executed in the sending session. (See <a href="#send"><b>6.2
|
|
<send></b></a>.) The receiving SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> use this
|
|
value as the value of the 'sendid' field in the event that it
|
|
generates. If the author of the sending session did not specify
|
|
either the 'id' or 'idlocation' attribute, the sending SCXML
|
|
Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> leave this attribute empty.</li>
|
|
|
|
<li>'sourcetype'. The sending SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> assign
|
|
this attribute the value "scxml". (Note that other types of senders
|
|
will assign different values.) The receiving Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> use this
|
|
value as the value of the 'origintype' field of the event that it
|
|
generates.</li>
|
|
|
|
<li>The 'language' attribute is used to indicate the type of data
|
|
contained in the body of the message inside the <payload>
|
|
element. The sending SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> populate
|
|
this attribute with the value of the 'datamodel' attribute in the
|
|
<scxml> element.</li>
|
|
|
|
<li><payload>. The sending SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> populate
|
|
this element with any data specified in the 'namelist' attribute of
|
|
in <param> and <content> elements. It <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> encode
|
|
the data in the language indicated by the 'language' attribute, for
|
|
example XML or JSON. This data <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> be in any namespace, or in no namespace at
|
|
all. The receiving SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> use this
|
|
value to populate the '_data' field of the event that it
|
|
generates.</li>
|
|
</ol>
|
|
|
|
<p>Here is a summary of the mapping between <send>, the SCXML
|
|
message structure, and the event that is raised in the receiving
|
|
session.</p>
|
|
|
|
<table border="1" cellpadding="2" cellspacing="2"
|
|
summary="send type values" width="100%">
|
|
<tbody>
|
|
<tr>
|
|
<th align="center"><send> element</th>
|
|
<th align="center">SCXML Message Structure</th>
|
|
<th align="center">Target Session Event</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left">'event' attribute</td>
|
|
<td align="left">'name' attribute</td>
|
|
<td align="left">'name' field</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left">not present in <send> but known to
|
|
platform</td>
|
|
<td align="left">'source' attribute</td>
|
|
<td align="left">'origin' field</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left">'target' attribute</td>
|
|
<td align="left">'target' attribute</td>
|
|
<td align="left">not present</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left">literal provided by author or value generated by
|
|
platform</td>
|
|
<td align="left">'sendid' attribute</td>
|
|
<td align="left">'sendid' field</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left">not present</td>
|
|
<td align="left">'sourcetype' attribute. Always "scxml".</td>
|
|
<td align="left">'origintype' field. Always "scxml".</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left">not present</td>
|
|
<td align="left">'language' attribute.</td>
|
|
<td align="left">not present</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td align="left">'namelist' attribute, <content> child, or
|
|
<param> children</td>
|
|
<td align="left"><payload> element</td>
|
|
<td align="left">data field</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>When an SCXML Processor receives a message via the SCXML Event
|
|
I/O Processor it <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> validate the syntax of the incoming
|
|
message and check that it matches an active session. If the message
|
|
fails syntactic validation or does not match an active session, the
|
|
Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> notify the sending processor of the error
|
|
and <em title="MUST in RFC2119 context" class="RFC2119">MUST</em>
|
|
ignore the message. If the message passes validation, but the
|
|
receiving Processor cannot handle the data format contained in the
|
|
message, the receiving Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> place the
|
|
error error.communication in internal queue of the session for
|
|
which the message was intended and <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> ignore
|
|
the message. The Processor <em title="SHOULD in RFC2119 context"
|
|
class="RFC2119">SHOULD</em> also notify the sending endpoint of the
|
|
error. If no errors occur, the receiving Processor <em
|
|
title="CONVERT in RFC2119 context" class="RFC2119">CONVERT</em> the
|
|
message into an SCXML event, using the mapping defined above, and
|
|
<em title="CONVERT in RFC2119 context" class="RFC2119">CONVERT</em>
|
|
insert the event its external event queue.</p>
|
|
|
|
<p>If the sending entity is an SCXML session, it <em
|
|
title="SHOULD in RFC2119 context" class="RFC2119">SHOULD</em> also
|
|
report errors. For example, if the sending session specifies a
|
|
sessionid that does not exist on the receiving system, specifies a
|
|
data format that the receiving session does not support, or is
|
|
unable to connect to the receiving system, it <em
|
|
title="SHOULD in RFC2119 context" class="RFC2119">SHOULD</em> place
|
|
the error error.communication on the internal event queue.</p>
|
|
|
|
<p>If the current session was triggered by an instance of
|
|
<invoke>, the SCXML Event I/O Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> handle
|
|
the 'cancel.invoke.<em>id</em>' event as defined in <a
|
|
href="#invokeimplementation"><b>6.4.3 Implementation of
|
|
<invoke></b></a>. In other cases (namely if the current
|
|
session was not triggered by an instance of <invoke> or if
|
|
the <em>id</em> does not match the invokeid of the triggering
|
|
<invoke> element), the SCXML Event I/O processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> discard
|
|
the event and <em title=" SHOULD in RFC2119 context"
|
|
class="RFC2119">SHOULD</em> signal an error.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N1172F" name="N1172F" />E.1.1 Examples</h4>
|
|
|
|
<p>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.</p>
|
|
|
|
<p><em>EXAMPLE 1:</em> First, here is a message with an XML payload
|
|
generated by <send> with a 'namelist':</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
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"/>
|
|
|
|
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Here is the actual XML message that will be sent over
|
|
platform-specific transport and converted into an event in the
|
|
target SCXML session:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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">
|
|
<headers xmlns="http://www.example.com/headers">
|
|
<cc>archive@example.com</cc>
|
|
<subject>Example email</subject>
|
|
</headers>
|
|
</scxml:property>
|
|
<scxml:hint>Email headers</scxml:hint>
|
|
</scxml:payload>
|
|
</scxml:message>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
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>
|
|
</pre>
|
|
</div>
|
|
|
|
<p><em>EXAMPLE 2:</em> The next example shows <send> using
|
|
inline XML content:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
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">
|
|
|
|
<content>
|
|
<csta:MakeCall>
|
|
<csta:callingDevice>22343</callingDevice>
|
|
<csta:calledDirectoryNumber>18005551212</csta:calledDirectoryNumber>
|
|
</csta:MakeCall>
|
|
</content>
|
|
|
|
</send>
|
|
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Here is the actual XML message that will be sent:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
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>
|
|
</pre>
|
|
</div>
|
|
|
|
<p><em>EXAMPLE 3:</em> Finally, here is an example generated by
|
|
<send> using both 'event' and 'namelist' attributes and using
|
|
JSON content:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
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"/>
|
|
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Here is the actual XML message that will be sent over
|
|
platform-specific transport and converted into an event in the
|
|
target SCXML session:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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">
|
|
<![CDATA[
|
|
headers : {
|
|
cc : "audit@example.com" ,
|
|
subject : "Example email"
|
|
}
|
|
]]>
|
|
</scxml:property>
|
|
<scxml:hint>Email headers</scxml:hint>
|
|
</scxml:payload>
|
|
</scxml:message>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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.</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>scxml-messages.xsd</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?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"
|
|
targetNamespace="http://www.w3.org/2005/07/scxml"
|
|
xmlns="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="scxmlmessages.extra.attribs" />
|
|
</xsd:attributeGroup>
|
|
|
|
<xsd:group name="scxmlmessages.messages.content">
|
|
<xsd:sequence>
|
|
<xsd:element ref="message" minOccurs="1"
|
|
maxOccurs="unbounded" />
|
|
</xsd:sequence>
|
|
</xsd:group>
|
|
|
|
<xsd:complexType name="scxmlmessages.messages.type">
|
|
<xsd:group ref="scxmlmessages.messages.content" />
|
|
<xsd:attributeGroup ref="scxmlmessages.messages.attlist" />
|
|
</xsd:complexType>
|
|
|
|
<xsd:element name="messages" type="scxmlmessages.messages.type" />
|
|
|
|
</xsd:schema>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="BasicHTTPEventProcessor"
|
|
name="BasicHTTPEventProcessor" />E.2 Basic HTTP Event I/O
|
|
Processor</h3>
|
|
|
|
<p>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 <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> support sending and receiving messages in
|
|
the SCXML message format using it(<a
|
|
href="http://www.w3.org/2011/04/SCXML/scxml.xsd">http://www.w3.org/2011/04/SCXML/scxml-message.xsd</a>).</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="accessURI" name="accessURI" />E.2.1 Access URI</h4>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>The access URI is available via the system variable
|
|
_ioprocessors using the key "basichttp". For example, in <a
|
|
href="#ecma-profile"><b>D.2 The ECMAScript Data Model</b></a>,
|
|
_ioprocessors["basichttp"] returns the access URI (e.g.
|
|
http://www.example.com/scxml/basichttp) for the basichttp
|
|
processor.</p>
|
|
|
|
<p>The access URI may also be specified in an
|
|
implementation-specific manner (for example, product
|
|
documentation).</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N11789" name="N11789" />E.2.2 Receiving Events</h4>
|
|
|
|
<p>An SCXML Processor that supports the Basic HTTP Event I/O
|
|
Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> accept messages from external components
|
|
the access URI as HTTP POST requests (see <a
|
|
href="#HTTP">[HTTP]</a>). The SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> validate
|
|
the message it receiveds and then <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> build the
|
|
appropriate SCXML event and <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> add it to the appropriate event
|
|
queue.</p>
|
|
|
|
<p>If the HTTP parameter '_content' is present, the SCXML Processor
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em>
|
|
interpret its value as a message in the SCXML message format (<a
|
|
href="http://www.w3.org/2011/04/SCXML/scxml.xsd">http://www.w3.org/2011/04/SCXML/scxml-message.xsd</a>).
|
|
The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> map such a message to an SCXML event as
|
|
described in <a href="#SCXMLEventProcessor"><b>E.1 SCXML Event I/O
|
|
Processor</b></a>. An SCXML Processor <em
|
|
title="MAY in RFC2119 context" class="RFC2119">MAY</em> accept
|
|
other parameters as well. In such cases, the mapping of their
|
|
values to SCXML events is implementation-specific.</p>
|
|
|
|
<p>After it adds the received message to the appropriate event
|
|
queue, the SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> then indicate 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 <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> return an HTTP error code as defined in
|
|
<a href="#HTTP">[HTTP]</a>. The following codes are assigned a more
|
|
specific meaning in the SCXML context:</p>
|
|
|
|
<ul>
|
|
<li>400 (Bad Request). Message structure is invalid.</li>
|
|
|
|
<li>403 (Forbidden). Session id does not match an existing SCXML
|
|
session id.</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N117BF" name="N117BF" />E.2.3 Sending Events</h4>
|
|
|
|
<p>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 <a href="#send"><b>6.2
|
|
<send></b></a>) with the type attribute set to "basichttp"
|
|
and the target attribute set to the access URI of the external
|
|
component.</p>
|
|
|
|
<p>The SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> attempt deliver the message using HTTP
|
|
method "POST" and with parameter values encoded by default in an
|
|
application/x-www-form-urlencoded body (POST method). An SCXML
|
|
Processor <em title="MAY in RFC2119 context"
|
|
class="RFC2119">MAY</em> support other encodings, and allow then to
|
|
be specified in a platform-specific way.</p>
|
|
|
|
<p>If the namelist attribute is defined, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> map its
|
|
variable names and values to HTTP parameters. If one or more
|
|
<param> children are present, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> map their
|
|
names (i.e. name attributes) and values to HTTP parameters. If a
|
|
<content> child is present, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> map its
|
|
value to the distinguished HTTP parameter '_content'.</p>
|
|
|
|
<p>If the external component returns any HTTP response code other
|
|
than 2XX, the SCXML Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> place the error error.communication on
|
|
the internal event queue of the session that attempted to send the
|
|
event.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="DOMEventProcessor" name="DOMEventProcessor" />E.3 DOM
|
|
Event I/O Processor</h3>
|
|
|
|
<p>The DOM Event I/O processor handles communication between SCXML
|
|
markup and markup in other namespaces in mixed-markup XML
|
|
documents. An example of this would be a document containing both
|
|
SCXML and HTML markup. In such a case, each language retains its
|
|
own context and its own independent semantics. (For example,
|
|
SCXML's event processing algorithm is not affected by the fact that
|
|
there is HTML markup elsewhere in the document.) It is however
|
|
useful for the two languages to be able to communicate by sending
|
|
events back and forth, so that the HTML markup can notify SCXML
|
|
when the user clicks on a button, and the SCXML markup can notify
|
|
HTML when it is time to place a certain field in focus, etc. The
|
|
DOM Event I/O processor handles this communication by means of DOM
|
|
Events <a href="#DOMEvents">[DOMEvents]</a>, which are a general
|
|
means for information propagation in XML documents.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N117E8" name="N117E8" />E.3.1 Sending Events</h4>
|
|
|
|
<p>The SCXML author can send a DOM event to any node in the
|
|
document by selecting the DOM Event I/O processor (type="DOM") and
|
|
specifying the URI of that node as the target. The SCXML Processor
|
|
<em title="MUST in RFC2119 context" class="RFC2119">MUST</em>
|
|
populate the attributes of the event with the values specified via
|
|
"namelist" or <param>. "namelist" or <param>. The
|
|
Processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> ignore items that do not correspond to
|
|
attributes of the event. If the URI specified is not part of the
|
|
same document, the SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> place the
|
|
error error.communication in the internal event queue.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a id="N117F6" name="N117F6" />E.3.2 Receiving Events</h4>
|
|
|
|
<p>When a DOM event is targeted at the <scxml> root node, the
|
|
DOM Event I/O processor <em title="MUST in RFC2119 context"
|
|
class="RFC2119">MUST</em> convert it into an SCXML event and insert
|
|
it in the external event queue. It <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> convert
|
|
the attributes of the DOM event into like-named elements in the
|
|
data field of the event (see <a
|
|
href="#InternalStructureofEvents"><b>5.11.1 The Internal Structure
|
|
of Events</b></a> for details.) The SCXML Processor <em
|
|
title="MUST in RFC2119 context" class="RFC2119">MUST</em> ignore
|
|
DOM events targeted at other nodes in the SCXML markup.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="relatedWork" name="relatedWork" />F Related Work</h2>
|
|
|
|
<p>A number of other XML-based state machine notations have been
|
|
developed, but none serves the same purpose as SCXML. XMI <a
|
|
href="#XMI">[UML XMI]</a> 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 <a href="#ebXML">[OASIS ebXML]</a> 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 <a href="#XTND">[XTND]</a>, 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.</p>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<p>This section is informative.</p>
|
|
|
|
<h2><a id="Examples" name="Examples" />G Examples</h2>
|
|
|
|
<div class="div2">
|
|
<h3><a id="N1181C" name="N1181C" />G.1 Language Overview</h3>
|
|
|
|
<p>This SCXML document gives an overview of the SCXML language and
|
|
shows the use of its state machine transition flows:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N11821" name="N11821" />Example:
|
|
Main.scxml</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?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"
|
|
datamodel="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. -->
|
|
<xi:include href="SCXMLExamples/Test2Sub1.xml" parse="text"/>
|
|
|
|
<final id="Test2Sub2"/>
|
|
|
|
<!-- Test2Sub2 is defined as final, so this
|
|
event is generated when we reach it -->
|
|
<transition event="done.state.Test2" 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 parallel states. In a more realistic example
|
|
the parallel substates Test5PSub1 and Test5PSub2 would themselves
|
|
have substates and would do some real work before transitioning to final substates -->
|
|
<parallel id="Test5P">
|
|
<state id="Test5PSub1" initial="Test5PSub1Final">
|
|
<final id="Test5PSub1Final"/>
|
|
</state>
|
|
<state id="Test5PSub2" initial="Test5PSub2Final">
|
|
<final id="Test5PSub2Final"/>
|
|
</state>
|
|
<onexit>
|
|
<log expr="'all parallel states done'"/>
|
|
</onexit>
|
|
</parallel>
|
|
|
|
<!-- The parallel states immediately transition to final substates,
|
|
so this event is generated immediately. -->
|
|
<transition event="done.state.Test5P" 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> a message to a CCXML Processor asking it to run createcall -->
|
|
<send target="ccxmlid" type="basichttp" 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. The implementation of this logic
|
|
would be platform-dependent. -->
|
|
<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="basichttp" event="v3:formstart" namelist="src id"/>
|
|
</transition>
|
|
|
|
<transition event="v3:HelloWorld2.done">
|
|
<!-- 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="_event.data.connectionid"/>
|
|
</transition>
|
|
|
|
<transition event="ccxml:connection.disconnected" target="Done"/>
|
|
|
|
<transition event="send.failed" 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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N11827" name="N11827" />Example:
|
|
Test2Sub1.xml</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<!-- This is an example substate defined in
|
|
- an external file and included by Main.scxml.
|
|
-->
|
|
<state id="Test2Sub1">
|
|
<onentry>
|
|
<log expr="'Inside Test2Sub1'"/>
|
|
</onentry>
|
|
<transition event="Event2" target="Test2Sub2"/>
|
|
</state>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="N1182D" name="N1182D" />G.2 Microwave Example</h3>
|
|
|
|
<p>The example below shows the implementation of a simple microwave
|
|
oven using SCXML.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N11832" name="N11832" />Example:
|
|
microwave-01.scxml</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0"?>
|
|
<scxml xmlns="http://www.w3.org/2005/07/scxml"
|
|
version="1.0"
|
|
datamodel="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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="MicrowaveParallel" name="MicrowaveParallel" />G.3
|
|
Microwave Example (Using parallel)</h3>
|
|
|
|
<p>The example below shows the implementation of a simple microwave
|
|
oven using <parallel> and the SCXML In() predicate.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N1183E" name="N1183E" />Example:
|
|
microwave-02.scxml</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0"?>
|
|
<scxml xmlns="http://www.w3.org/2005/07/scxml"
|
|
version="1.0"
|
|
datamodel="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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="N11844" name="N11844" />G.4 Calculator Example</h3>
|
|
|
|
<p>The example below shows the implementation of a simple
|
|
calculator in SCXML.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N11849" name="N11849" />Example:
|
|
calc.scxml</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0" ?>
|
|
<scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0"
|
|
initial="on" datamodel="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 location="short_expr" expr="''" />
|
|
</transition>
|
|
<transition event="DIGIT" target="int1">
|
|
<assign location="short_expr" expr="''" />
|
|
</transition>
|
|
<transition event="POINT" target="frac1">
|
|
<assign location="short_expr" expr="''" />
|
|
</transition>
|
|
</state>
|
|
<state id="negated1">
|
|
<onentry>
|
|
<assign location="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 location="short_expr" expr="short_expr+_event.name.substr(_event.name.lastIndexOf('.')+1)" />
|
|
<send event="DISPLAY.UPDATE" />
|
|
</transition>
|
|
<onentry>
|
|
<assign location="short_expr" expr="short_expr+_event.name.substr(_event.name.lastIndexOf('.')+1)" />
|
|
<send event="DISPLAY.UPDATE" />
|
|
</onentry>
|
|
</state>
|
|
<state id="frac1">
|
|
<onentry>
|
|
<assign location="short_expr" expr="short_expr+'.'" />
|
|
<send event="DISPLAY.UPDATE" />
|
|
</onentry>
|
|
<transition event="DIGIT">
|
|
<assign location="short_expr" expr="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 location="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 location="short_expr" expr="short_expr+_event.name.substr(_event.name.lastIndexOf('.')+1)" />
|
|
<send event="DISPLAY.UPDATE" />
|
|
</transition>
|
|
<onentry>
|
|
<assign location="short_expr" expr="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 location="short_expr" expr="short_expr +'.'" />
|
|
<send event="DISPLAY.UPDATE" />
|
|
</onentry>
|
|
<transition event="DIGIT">
|
|
<assign location="short_expr" expr="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 location="short_expr" expr="''+ res" />
|
|
<assign location="long_expr" expr="''" />
|
|
<assign location="res" expr="0" />
|
|
</transition>
|
|
<transition event="CALC.SUB">
|
|
<if cond="short_expr!=''">
|
|
<assign location="long_expr" expr="long_expr+'('+short_expr+')'" />
|
|
</if>
|
|
<assign location="res" expr="eval(long_expr)" />
|
|
<assign location="short_expr" expr="''" />
|
|
<send event="DISPLAY.UPDATE" />
|
|
</transition>
|
|
<transition event="DISPLAY.UPDATE">
|
|
<log level="0" label="'result'" expr=".short_expr==''?res:short_expr" />
|
|
</transition>
|
|
<transition event="OP.INSERT">
|
|
<log level="0" expr="_event.data[0]" />
|
|
<if cond="_event.data[0] == 'OPER.PLUS'">
|
|
<assign location="long_expr" expr="long_expr+'+'" />
|
|
<elseif cond="_event.data[0]=='OPER.MINUS'" />
|
|
<assign location="long_expr" expr="long_expr+'-'" />
|
|
<elseif cond="_event.data[0]=='OPER.STAR'" />
|
|
<assign location="long_expr" expr="long_expr+'*'" />
|
|
<elseif cond="_event.data[0]=='OPER.DIV'" />
|
|
<assign location="long_expr" expr="long_expr+'/'" />
|
|
</if>
|
|
</transition>
|
|
</scxml>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="N1184F" name="N1184F" />G.5 Shale Example</h3>
|
|
|
|
<p>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
|
|
<a href="http://shale.apache.org/">http://shale.apache.org/</a>.
|
|
SCXML is used as a "dialog manager" service in Shale (for details
|
|
on the integration of SCXML in Shale please see <a
|
|
href="http://shale.apache.org/shale-dialog-scxml/index.html">http://shale.apache.org/shale-dialog-scxml/index.html</a>).
|
|
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 <a
|
|
href="#EL">[EL]</a>, which is the expression language supported in
|
|
the JSF environment.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N11865" name="N11865" />Example:
|
|
log-on-config.scxml</div>
|
|
|
|
<img src="SCXMLExamples/logon.png" class="center"
|
|
alt="UML diagram for this example" />
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?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.example.com/"
|
|
version="1.0" initial="checkCookie" datamodel="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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N11872" name="N11872" />Example:
|
|
edit-profile-config.scxml</div>
|
|
|
|
<img src="SCXMLExamples/editprofile.png" class="center"
|
|
alt="UML diagram for this example" />
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?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.example.com/"
|
|
version="1.0" initial="edit" datamodel="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>
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="invokeex" name="invokeex" />G.6 Examples of Invoke and
|
|
finalize</h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N11885" name="N11885" />Example:
|
|
Traffic Report</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0"?>
|
|
<?access-control allow="*"?>
|
|
<scxml version="1.0" initial="Intro" datamodel="ecmascript">
|
|
<state id="Intro">
|
|
<invoke src="dialog.vxml#Intro" type="vxml2"/>
|
|
<transition event="success" cond="sessionChrome.playAds" target="PlayAds"/>
|
|
<transition event="success" cond="!sessionChrome.playAds &amp;&amp; ANIQuality"
|
|
target="ShouldGoBack"/>
|
|
<transition event="success" cond="!sessionChrome.playAds &amp;&amp; !ANIQuality"
|
|
target="StartOver"/>
|
|
</state>
|
|
|
|
<state id="PlayAds">
|
|
<invoke src="dialog.vxml#PlayAds" type="vxml2"/>
|
|
<transition event="success" cond="ANIQuality" target="ShouldGoBack"/>
|
|
<transition event="success" cond="!ANIQuality" target="StartOver"/>
|
|
</state>
|
|
|
|
<state id="StartOver">
|
|
<onenter>
|
|
<script>enterStartOver();</script>
|
|
</onenter>
|
|
<invoke src="dialog.vxml#StartOver" type="vxml2">
|
|
<param name="gotItFromANI" expr="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="cityState"/>
|
|
<param name="gotItFromANI" expr="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="cityState"/>
|
|
<param name="gotItFromANI" expr="gotItFromANI"/>
|
|
<param name="playHRPrompt" expr="playHRPrompt"/>
|
|
<param name="metroArea" expr="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="cityState"/>
|
|
<param name="metroArea" expr="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="cityState"/>
|
|
<param name="curHighway" expr="curHighway"/>
|
|
<finalize>
|
|
<script>finalizePlayHighway();</script>
|
|
</finalize>
|
|
</invoke>
|
|
<transition event="go_back" target="HighwayReport"/>
|
|
</state>
|
|
</scxml>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<p>The following example shows a the control flow for a blackjack
|
|
game.</p>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleHeader"><a id="N1188D" name="N1188D" />Example:
|
|
Blackjack</div>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<?xml version="1.0"?>
|
|
<?access-control allow="*"?>
|
|
<scxml version="1.0" datamodel="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="skinpath"/>
|
|
</invoke>
|
|
<transition event="success" target="Intro2"/>
|
|
</state>
|
|
|
|
<state id="Intro2">
|
|
<invoke src="dialog.vxml#Intro2" type="vxml3">
|
|
<param name="skinpath" expr="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="skinpath"/>
|
|
<param name="playercard1" expr="playercard1"/>
|
|
<param name="playercard2" expr="playercard2"/>
|
|
<param name="playertotal" expr="blackjack.GetTotalOf('caller').toString()"/>
|
|
<param name="dealercardshowing" expr="dealercardshowing"/>
|
|
</invoke>
|
|
<transition event="success" target="AskHit"/>
|
|
</state>
|
|
|
|
<state id="AskHit">
|
|
<invoke src="dialog.vxml#AskHit" type="vxml3">
|
|
<param name="skinpath" expr="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="skinpath"/>
|
|
<param name="playernewcard" expr="playernewcard"/>
|
|
<param name="playertotal" expr="blackjack.GetTotalOf('caller').toString()"/>
|
|
</invoke>
|
|
<transition event="success" cond="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="skinpath"/>
|
|
<param name="gameresult" expr="blackjack.GetGameResult()"/>
|
|
<param name="dealertotal" expr="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>
|
|
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="content_and_namespaces"
|
|
name="content_and_namespaces" />G.7 Inline Content and
|
|
Namespaces</h3>
|
|
|
|
<p>Since SCXML documents are XML documents, normal XML namespace
|
|
rules apply to inline content specified with <content> and
|
|
<data>. In particular, if no namespace is specified, the
|
|
inline content will be placed in the SCXML namespace. Consider the
|
|
following example:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
|
|
<send target="http://example.com/send/target" type="'basichttp'">
|
|
<content>
|
|
<a>fffff</a>
|
|
</content>
|
|
</send>
|
|
|
|
</pre>
|
|
</div>
|
|
|
|
<p>The recipient of the message will see the following:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
|
|
<a xmlns="http://www.w3.org/2005/07/scxml">fffff</a>
|
|
|
|
</pre>
|
|
</div>
|
|
|
|
<p>The following markup would cause the message to be delivered
|
|
without namespaces:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
|
|
<send target="http://example.com/send/target" type="'basichttp'">
|
|
<content>
|
|
<a xmlns="">fffff</a>
|
|
</content>
|
|
</send>
|
|
|
|
</pre>
|
|
</div>
|
|
|
|
<p>The recipient of the message will see the following:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
|
|
<a>fffff</a>
|
|
|
|
</pre>
|
|
</div>
|
|
|
|
<p>The sender can also specify multiple namespaces:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
|
|
<send target="http://example.com/send/target" type="'basichttp'">
|
|
<content>
|
|
<root xmlns="http://example.com/r" xmlns:a="http://example.com/a" xmlns:b="http://example.com/b" xmlns:c="http://example.com/c">
|
|
<a:alpha>1</a:alpha>
|
|
<b:beta>2</b:beta>
|
|
<c:gamma>3</c:gamma>
|
|
</root>
|
|
</content>
|
|
</send>
|
|
|
|
</pre>
|
|
</div>
|
|
|
|
<p>In this case, the receiver would see:</p>
|
|
|
|
<div class="exampleOuter">
|
|
<pre>
|
|
|
|
<root xmlns="http://example.com/r">
|
|
<alpha xmlns="http://example.com/a">1</alpha>
|
|
<beta xmlns="http://example.com/b>2</beta>
|
|
<gamma xmlns="http://example.com/c>3</gamma>
|
|
</root>
|
|
|
|
</pre>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a id="custom_action" name="custom_action" />G.8 Custom Action
|
|
Elements</h3>
|
|
|
|
<p>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:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<transition event="ccxml:connection.alerting">
|
|
<ccxml:accept connectionid="_event.data.connectionid"/>
|
|
</transition>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>This could be written using a <send> element using the
|
|
following syntax:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<datamodel>
|
|
<data name="connectionid"/>
|
|
</datamodel>
|
|
<transition event="ccxml:connection.alerting">
|
|
<assign name="connectionid" expr="_event.data.connectionid"/>
|
|
<send type="ccxml" event="ccxml:accept" namelist="connectionid"/>
|
|
</transition>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<onentry>
|
|
<ccxml:createcall dest="'tel:+18315552020'" connectionid="myConnectionID"/>
|
|
</onentry>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Would need to be modeled in two steps using <send> as you
|
|
would need to do something like the following:</p>
|
|
|
|
<div class="exampleInner">
|
|
<pre>
|
|
<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="_event.data.connectionid"/>
|
|
</transition>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>The exact mappings between Custom Action Elements and
|
|
<send> actions are to be defined in the individual Custom
|
|
Action Element specifications.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a id="references" name="references" />H References</h2>
|
|
|
|
<dl>
|
|
<dt class="label"><a id="CSS2" name="CSS2" />CSS2</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/1998/REC-CSS2-19980512/"><cite>Cascading
|
|
Style Sheets, level 2: CSS2 Specification</cite></a>. 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/.)</dd>
|
|
|
|
<dt class="label"><a id="ebXML" name="ebXML" />OASIS ebXML</dt>
|
|
|
|
<dd><a
|
|
href="http://www.oasis-open.org/committees/documents.php?wg_abbrev=ebxml-bp">
|
|
<cite>ebXML Business Process Specification Schema v2.0</cite></a>.
|
|
(See
|
|
http://www.oasis-open.org/committees/documents.php?wg_abbrev=ebxml-bp.)</dd>
|
|
|
|
<dt class="label"><a id="DOMEvents"
|
|
name="DOMEvents" />DOMEvents</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/DOM-Level-3-Events/"><cite>EDocument
|
|
Object Model (DOM) Level 3 Events Specification</cite></a> W3C
|
|
Working Draft, September 2009. (See
|
|
http://www.w3.org/TR/DOM-Level-3-Events/.)</dd>
|
|
|
|
<dt class="label"><a id="ECMAScript262"
|
|
name="ECMAScript262" />ECMASCRIPT-262</dt>
|
|
|
|
<dd><a
|
|
href="http://www.ecma-international.org/publications/standards/Ecma-262.htm">
|
|
<cite>ECMAScript Language Specification</cite></a> Standard
|
|
ECMA-262, 3rd Edition, December 1999. (See
|
|
http://www.ecma-international.org/publications/standards/Ecma-262.htm.)</dd>
|
|
|
|
<dt class="label"><a id="ECMAScript327"
|
|
name="ECMAScript327" />ECMASCRIPT-327</dt>
|
|
|
|
<dd><a
|
|
href="http://www.ecma-international.org/publications/standards/Ecma-327.htm">
|
|
<cite>ECMAScript 3rd Edition Compact Profile</cite></a> Standard
|
|
ECMA-327, July 2001. (See
|
|
http://www.ecma-international.org/publications/standards/Ecma-327.htm.)</dd>
|
|
|
|
<dt class="label"><a id="E4X" name="E4X" />E4X</dt>
|
|
|
|
<dd><a
|
|
href="http://www.ecma-international.org/publications/standards/Ecma-357.htm">
|
|
<cite>ECMAScript for XML (E4X) Specification</cite></a> Standard
|
|
ECMA-357, 2nd Edition, December 2005. (See
|
|
http://www.ecma-international.org/publications/standards/Ecma-357.htm.)</dd>
|
|
|
|
<dt class="label"><a id="EL" name="EL" />EL</dt>
|
|
|
|
<dd><a href="http://commons.apache.org/el/"><cite>EL: The JSP 2.0
|
|
Expression Language Interpreter</cite></a> (See
|
|
http://commons.apache.org/el/.)</dd>
|
|
|
|
<dt class="label"><a id="Harel_Politi" name="Harel_Politi" />Harel
|
|
and Politi</dt>
|
|
|
|
<dd><a
|
|
href="http://www.wisdom.weizmann.ac.il/~dharel/reactive_systems.html">
|
|
<cite>Modeling Reactive Systems with Statecharts: The STATEMATE
|
|
Approach</cite></a> By D. Harel and M. Politi. McGraw-Hill, 1998.
|
|
(See
|
|
http://www.wisdom.weizmann.ac.il/~dharel/reactive_systems.html.)</dd>
|
|
|
|
<dt class="label"><a id="RFC2119" name="RFC2119" />IETF RFC
|
|
2119</dt>
|
|
|
|
<dd><a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>RFC 2119:
|
|
Key words for use in RFCs to Indicate Requirement
|
|
Levels</cite></a>. Internet Engineering Task Force, 1997. (See
|
|
http://www.ietf.org/rfc/rfc2119.txt.)</dd>
|
|
|
|
<dt class="label"><a id="RFC2396" name="RFC2396" />IETF RFC
|
|
2396</dt>
|
|
|
|
<dd><a href="http://www.ietf.org/rfc/rfc2396.txt"><cite>RFC 2396:
|
|
Uniform Resource Identifiers</cite></a>. Internet Engineering Task
|
|
Force, 1995. (See http://www.ietf.org/rfc/rfc2396.txt.)</dd>
|
|
|
|
<dt class="label"><a id="CCXML" name="CCXML" />W3C CCXML 1.0</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2005/WD-ccxml-20050111/"><cite>Voice
|
|
Browser Call Control: CCXML Version 1.0</cite></a>. W3C, 2005. (See
|
|
http://www.w3.org/TR/2005/WD-ccxml-20050111/.)</dd>
|
|
|
|
<dt class="label"><a id="HTTP" name="HTTP" />HTTP</dt>
|
|
|
|
<dd><a href="http://www.ietf.org/rfc/rfc2616.txt"><cite>CMultimodal
|
|
Architecture and Interfaces Working Draft</cite></a>. W3C, 2005.
|
|
(See http://www.ietf.org/rfc/rfc2616.txt.)</dd>
|
|
|
|
<dt class="label"><a id="JSON" name="JSON" />JSON</dt>
|
|
|
|
<dd><a href="http://www.ietf.org/rfc/rfc4627.txt"><cite>The
|
|
application/json Media Type for JavaScript Object Notation
|
|
(JSON)</cite></a> RFC 4627, July 2006. (See
|
|
http://www.ietf.org/rfc/rfc4627.txt.)</dd>
|
|
|
|
<dt class="label"><a id="MMI" name="MMI" />W3C MMI</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/mmi-arch/"><cite>"Hypertext
|
|
Transfer Protocol -- HTTP/1.1 "</cite></a>. IETF RFC 2616, 199.
|
|
(See http://www.w3.org/TR/mmi-arch/.)</dd>
|
|
|
|
<dt class="label"><a id="RFC2616" name="RFC2616" />RFC2616</dt>
|
|
|
|
<dd><a href="http://www.ietf.org/rfc/rfc2616.txt"><cite>Hypertext
|
|
Transfer Protocol -- HTTP/1.1</cite></a> IETF RFC 2616, 1999. (See
|
|
http://www.ietf.org/rfc/rfc2616.txt.)</dd>
|
|
|
|
<dt class="label"><a id="RFC2617" name="RFC2617" />RFC2617</dt>
|
|
|
|
<dd><a href="http://www.ietf.org/rfc/rfc2617.txt"><cite>HTTP
|
|
Authentication: Basic and Digest Access Authentication</cite></a>
|
|
IETF RFC 2617, June 1999. (See
|
|
http://www.ietf.org/rfc/rfc2617.txt.)</dd>
|
|
|
|
<dt class="label"><a id="VoiceXML" name="VoiceXML" />W3C VoiceXML
|
|
2.0</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/voicexml20/"><cite>VoiceXML
|
|
2.0:</cite></a> . W3C, 2004. (See
|
|
http://www.w3.org/TR/voicexml20/.)</dd>
|
|
|
|
<dt class="label"><a id="UML" name="UML" />UML 2.3</dt>
|
|
|
|
<dd><a href="http://www.omg.org/spec/UML/2.3/"><cite>UML
|
|
Specification Version 2.3</cite></a>. OMG, 2009. (See
|
|
http://www.omg.org/spec/UML/2.3/.)</dd>
|
|
|
|
<dt class="label"><a id="XMI" name="XMI" />UML XMI</dt>
|
|
|
|
<dd><a
|
|
href="http://www.omg.org/technology/documents/modeling_spec_catalog.htm#XMI">
|
|
<cite>XML Metadata Exchange version 2.1</cite></a>. (See
|
|
http://www.omg.org/technology/documents/modeling_spec_catalog.htm#XMI.)</dd>
|
|
|
|
<dt class="label"><a id="xinclude" name="xinclude" />XInclude</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/xinclude/"><cite>XML Inclusions
|
|
(XInclude) Version 1.0</cite></a>. W3C, 2006. (See
|
|
http://www.w3.org/TR/xinclude/.)</dd>
|
|
|
|
<dt class="label"><a id="XML" name="XML" />XML</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/xml/"><cite>Extensible Markup
|
|
Language (XML) 1.0 (Fourth Edition)</cite></a> T. Bray et. al. eds.
|
|
World Wide Web Consortium 16 August 2006 (See
|
|
http://www.w3.org/TR/xml/.)</dd>
|
|
|
|
<dt class="label"><a id="ID" name="ID" />XML ID</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2005/REC-xml-id-20050909/"><cite>xml:id
|
|
version 1.0</cite></a> J. Marsh, D. Veillard, N. Walsh. World Wide
|
|
Web Consortium, 9 September 2005. (See
|
|
http://www.w3.org/TR/2005/REC-xml-id-20050909/.)</dd>
|
|
|
|
<dt class="label"><a id="XMLNames" name="XMLNames" />XMLNames</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2006/REC-xml-names-20060816/"><cite>Namespaces
|
|
in XML 1.0 (Second Edition)</cite></a> 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/.)</dd>
|
|
|
|
<dt class="label"><a id="Schema" name="Schema" />XML Schema</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/xmlschema-2/"><cite>XML Schema
|
|
Part 2: Datatypes Second Edition</cite></a> P. Biron and A.
|
|
Malhotra. World Wide Web Consortium, 28 October 2004. (See
|
|
http://www.w3.org/TR/xmlschema-2/.)</dd>
|
|
|
|
<dt class="label"><a id="XPATH2" name="XPATH2" />XPath 2.0</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/xpath20/"><cite>XML Path Language
|
|
(XPath) 2.0</cite></a> 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/.)</dd>
|
|
|
|
<dt class="label"><a id="XPATH2FO" name="XPATH2FO" />XPath 2.0
|
|
Functions and Operators</dt>
|
|
|
|
<dd><a href="http://www.w3.org/TR/xpath-functions/"><cite>XQuery
|
|
1.0 and XPath 2.0 Functions and Operators</cite></a> A. Malhotra,
|
|
J. Melton, N. Walsh, January 2007 (See
|
|
http://www.w3.org/TR/xpath-functions/.)</dd>
|
|
|
|
<dt class="label"><a id="XTND" name="XTND" />XTND</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2000/NOTE-xtnd-20001121/"><cite>XML
|
|
Transition Network Definition</cite></a>. (See
|
|
http://www.w3.org/TR/2000/NOTE-xtnd-20001121/.)</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html>
|
|
|