State Chart XML (SCXML): State
Machine Notation for Control Abstraction
W3C
Recommendation 1 September 2015
- This version:
- http://www.w3.org/TR/2015/REC-scxml-20150901/
- Latest version:
- http://www.w3.org/TR/scxml/
- Previous version:
- http://www.w3.org/TR/2015/PR-scxml-20150430/
- Editors:
- Jim Barnett, Genesys (Editor-in-Chief)
- Rahul Akolkar, IBM
- RJ Auburn, Voxeo
- Michael Bodell, (until 2012, when at Microsoft)
- Daniel C. Burnett, Voxeo
- Jerry Carter, (until 2008, when at Nuance)
- Scott McGlashan, (until 2011, when at HP)
- Torbjörn Lager, Invited Expert
- Mark Helbing, (until 2006, when at Nuance)
- Rafah Hosn, (until 2008, when at IBM)
- T.V. Raman, (until 2005, when at IBM)
- Klaus Reifenrath, (until 2006, when at Nuance)
- No'am Rosenthal, (until 2009, when at Nokia)
- Johan Roxendal, Invited Expert
Please refer to the errata for this document, which may include normative corrections.
See also translations.
Copyright
© 2015 W3C® (MIT,
ERCIM, Keio, Beihang). W3C
liability,
trademark and document
use rules apply.
Abstract
This document describes SCXML, or the "State Chart extensible
Markup Language". SCXML provides a generic state-machine based
execution environment based on CCXML and Harel State Tables.
A Conformance
[This section is normative.]
A.1
Conforming Documents
The following conformance requirements hold for all SCXML
documents.
- The root element of the document MUST be
.
- The element MUST include a "version" attribute with the
value "1.0".
- The element MUST designate the SCXML namespace. This can
be achieved by declaring an "xmlns" attribute or an attribute with
an "xmlns" prefix [XMLNames]. The namespace
for SCXML is defined to be http://www.w3.org/2005/07/scxml.
- The document MUST 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.
- The document MUST conform to any additional syntactic
constraints that are defined for the data model that it has chosen.
See B Data Models for the
definition of the individual data models.
A.2
Conforming Processors
A SCXML 1.0 processor is a user agent that can parse and process
Conforming SCXML 1.0 documents.
In a Conforming SCXML 1.0 Processor, the XML parser MUST be able
to parse and process all well-formed XML constructs defined within
[XML] and [XMLNames]. It
is not required that a Conforming SCXML 1.0 processor use a
validating parser.
A Conforming SCXML 1.0 Processor MUST support
the syntax and semantics of all mandatory SCXML elements described
in this document. A Conforming SCXML 1.0 Processor MAY support the
syntax and semantics of any optional SCXML elements described in
this document.
When a Conforming SCXML 1.0 Processor encounters a
non-conformant document, or one containing non-SCXML elements or
attributes which are proprietary, or defined in a non-SCXML
namespace, its behavior is undefined.
There is no conformance requirement with respect to performance
characteristics of the SCXML 1.0 Processor.
B Data Models
[This section is normative.]
The 'datamodel' attribute on defines the data
model that the document uses. The data model includes the
underlying data structure plus languages for boolean expressions,
location expressions, value expressions, and scripting. A
conformant SCXML document MAY specify the data model it uses. Conformant
SCXML processors MUST support the null data model, and MAY support
other data models, including the ECMAScript and XPath data models.
The ECMAScript and XPath model definitions given here are normative
in the sense that they define how implementations that support one
of these languages MUST behave. The intent is to ensure
interoperability among all processors that support ECMAScript, and
all those that support XPath, without requiring all implementations
to support either of those data model languages.
The definition of a data model MUST:
- Specify the boolean expression language used as the value of
the 'cond' attribute in , and
This language MUST not have side effects and MUST 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.
- Specify the location expression language that is used as the
value of the 'location' attribute of the tag.
- Specify the value expression language that is used as the value
of the 'expr' attribute of the and
elements.
- Specify the scripting language used inside the
The following example shows a the control flow for a blackjack
game.
G.6 Inline Content and
Namespaces
Since SCXML documents are XML documents, normal XML namespace
rules apply to inline content specified with and
. In particular, if no namespace is specified, the
inline content will be placed in the SCXML namespace. Consider the
following example:
The recipient of the message will see the following:
The following markup would cause the message to be delivered
without namespaces:
The recipient of the message will see the following:
The sender can also specify multiple namespaces:
In this case, the receiver would see:
G.7 Custom Action
Elements
Custom Action Elements can be defined in other
specifications/namespaces and are responsible for performing
actions on behalf of custom components. Logically Custom Action
Elements can be thought of as a collection of actions and handlers
to perform specific tasks. An example of this is a CCXML
element that is a Custom Action Element:
This could be written using a element using the
following syntax:
A more complicated example might be a CCXML
where you are both providing variables and getting values back that
using only the syntax would be more complex as it
would need to be broken over several steps. For example:
Would need to be modeled in two steps using as you
would need to do something like the following:
The exact mappings between Custom Action Elements and
actions are to be defined in the individual Custom
Action Element specifications.
H MIME Type
[This section is normative.]
This appendix registers a new MIME media type,
"application/scxml+xml".
The "application/scxml+xml" media type is being
submitted to the IESG for review, approval, and registration with
IANA.
H.1 Registration of MIME media
type application/scxml+xml
- MIME media type name:
application- MIME subtype name:
scxml+xml- Required parameters:
- None
- Optional parameters:
-
charset- This parameter has identical semantics to the
charset parameter of the application/xml
media type as specified in [RFC 3023] or its
successor.
- Encoding considerations:
- By virtue of SCXML content being XML, it has the same
considerations when sent as "application/scxml+xml"as does XML. See
[RFC 3023] (or its successor), section
3.2.
- Security considerations:
- SCXML elements may include arbitrary URIs. Therefore, the
security issues of [RFC 3986] section 7
should be considered. In addition, because of the extensibility
features for SCXML, it is possible that
"
application/scxml+xml" may describe content that has
security implications beyond those described here. However, if the
processor follows only the normative semantics of this
specification, this content will be ignored. Only in the case where
the processor recognizes and processes the additional content, or
where further processing of that content is dispatched to other
processors, would security issues potentially arise. And in that
case, they would fall outside the domain of this registration
document.
- Interoperability considerations:
- This specification describes processing semantics that dictate
behavior that must be followed when dealing with, among other
things, unrecognized elements.Because SCXML is extensible,
conformant "
application/scxml+xml" processors MAY
expect that content received is well-formed XML, but processors
SHOULD NOT assume that the content is valid SCXML or expect to
recognize all of the elements and attributes in the document.
- Published specification:
- This media type registration is extracted from Appendix H of
the State Chart XML (SCXML):
State Machine Notation for Control Abstraction
specification.
- Additional information:
-
- Magic number(s):
- There is no single initial octet sequence that is always
present in SCXML documents.
- File extension(s):
- SCXML documents are most often identified with the extensions
"
.scxml".
- Macintosh File Type Code(s):
- TEXT
- Person and email address to contact for further
information:
- Kazuyuki Ashimura, <[email protected]>.
- Intended usage:
- COMMON
- Restrictions on usage:
- None
- Author:
- The SCXML specification is a work product of the World Wide Web
Consortium's Voice Browser Working Group.
- Change controller:
- The W3C has change control over these specifications.
H.2
Fragment Identifiers
For documents labeled as "application/scxml+xml",
the fragment identifier notation is exactly that for
"application/xml", as specified in RFC 3023.