yalke

浏览: 240720 次
性别:
来自: Germany

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

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

博客分类：

Diplomarbeit

XML UML UP performance IBM

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

W3C Working Draft 5 July 2005

This version:

http://www.w3.org/TR/2005/WD-scxml-20050705/

Latest version:

http://www.w3.org/TR/scxml/

Previous version:

This is the first version.

Editors:

RJ Auburn, Voxeo

Jim Barnett, Aspect Communications

Michael Bodell, Tellme Networks

T.V. Raman, IBM

Abstract

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

Status of this Document

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

This document is the first Public Working Draft of SCXML for review by W3C Members and other interested parties, and has been developed by the Voice Browser Working Group (W3C Members only) as part of the W3C Voice Browser Activity.

SCXML is a candidate for the control language within VoiceXML 3.0 (currently under development by the Voice Browser working group), CCXML 2.0 (anticipated development in 2006 by the Voice Browser working group), and the multimodal authoring language (under development by the Multimodal Interaction working group).

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

This document was produced under the 5 February 2004 W3C Patent Policy. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing [and excluding] a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.

Per section 4 of the W3C Patent Policy, Working Group participants have 150 days from the title page date of this document to exclude essential claims from the W3C RF licensing requirements with respect to this document series. Exclusions are with respect to the exclusion reference document, defined by the W3C Patent Policy to be the latest version of a document in this series that is published no later than 90 days after the title page date of this document.

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.

1 Terminology
2 Overview
3 Basic State Notation
    3.1 SCXML
        3.1.1 Properties
    3.2 STATE
        3.2.1 Properties
    3.3 TRANSITION
        3.3.1 Properties
    3.4 PARALLEL
        3.4.1 Properties
4 Pseudo-States
    4.1 INITIAL
        4.1.1 Properties
    4.2 HISTORY
        4.2.1 Properties
    4.3 JOIN
        4.3.1 Properties
    4.4 SYNCH
        4.4.1 Properties
5 Executable Content
    5.1 Variables and Expressions
        5.1.1 <assign></assign>and
            5.1.1.1 Overview
            5.1.1.2 Attribute Details
            5.1.1.3 <assign></assign>Attribute Details
    5.2 Event Control
        5.2.1 <send></send>
            5.2.1.1 Overview
            5.2.1.2 Attribute Details
        5.2.2 <cancel></cancel>
            5.2.2.1 Overview
            5.2.2.2 Attribute Details
    5.3 Flow Control Elements
        5.3.1 <if></if>
            5.3.1.1 Overview
            5.3.1.2 Attribute Details
        5.3.2 <elseif></elseif>
            5.3.2.1 Overview
            5.3.2.2 Attribute Details
        5.3.3 <else></else>
            5.3.3.1 Overview
            5.3.3.2 Attribute Details
    5.4 Debugging Elements
        5.4.1 <log></log>
            5.4.1.1 Overview
            5.4.1.2 Attribute Details
6 Conditional Expressions
    6.1 Special Predicates
        6.1.1 In
            6.1.1.1 Overview
            6.1.1.2 Attribute Details
7 Related Work

Appendices

A Open Issues
    A.1 Empty Event Property of Transition
    A.2 Scoping Rules for ID
    A.3 State Templates
    A.4 XML Content in Send
    A.5 junction, choice, fork, and join
    A.6 Automatic Logging
B Schema
C CCXML to SCXML Conversion
D Examples
    D.1 Language Overview
E An Overview of Harel State Table Notation and Semantics
    E.1 A Simple State Machine
    E.2 Executing Actions On Entering And Exiting
    E.3 Complex States
    E.4 Parallel States
    E.5 Concurrency And Event Queues
    E.6 Synchronizing And Concurrency
    E.7 Sync Explained
    E.8 Microwave Oven
F References

1 Terminology

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

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

2 Overview

This document outlines a state machine notation that combines concepts from CCXML and Harel State Tables. It is intended to be a general-purpose state machine language that can be used in multiple contexts, including VoiceXML 3.0, CCXML 2.0, and the MultiModal Interaction framework. CCXML [W3C CCXML 1.0] is an event-based state machine language designed to support call control features in Voice Applications (specifically including VoiceXML but not limited to it). The CCXML 1.0 specification defines both a state machine and event handing syntax and a standardized set of call control elements. Harel State Tables are a state machine notation that are part of UML [UML 1.5]. 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. For an overview of the UML notation and a brief outline of its semantics, see E An Overview of Harel State Table Notation and Semantics, below.

For simplicity's sake, the language definitions below refer to the 'properties' of elements, without specifying whether said properties are attributes or children. The markup samples at the end of the document make specific decisions about what is an attribute and what is a child element, but we may revise these decisions as refine the definitions.

For concreteness sake, we use ECMAScript as the language for data elements, but the complete language definition will permit other languages such as XPath to be used as well.

3 Basic State Notation

3.1 `SCXML`

Top-level root element. Carries version information etc. We may decide that we don't need a special root element, particularly since the purpose of this notation is to be embedded in other languages, such as VoiceXML 3.0.

3.1.1 Properties

initialstate Identifies the top-level state for the document .
xmlns
version

3.2 `STATE`

Holds the representation of a state machine.

3.2.1 Properties

id Identifier for this state.
src Optional URL of a file containing the definition of this state. Any definitions within the body of the state element override those in the external file.
final Boolean property indicating whether this is a final state or not. Default value is false . Final states may not have substates or outgoing transitions. When a final state is entered, a completion event "parentID.done" is generated, where "parentID" is the id of this state's parent state.
onentry Optional property holding executable content to be run upon entering this state.
onexit Optional property holding executable content to be run when exiting this state.
transition Defines an outgoing transition from this state. May occur 0 or more times.
state Defines a sequential substate of the parent state. May occur 0 or more times. Incompatible with the parallel property.
initial A child which identifies initial state for state machines that have substates. This child is required if and only if the machine has one or more state children.
history A child which represents the descendant state that the parent state was in the last time the system transitioned from the parent. A transition with this state as its target is in fact a transition to one of the other descendant states of the parent. May occur 0 or more times.
parallel Defines a set of parallel substates. May occur 0 or 1 times. Incompatible with the state property.

3.3 `TRANSITION`

Transition rules are triggered by events and conditionalized via guard-conditions. The optional property target specifies the destination of the transition, which may be a state or a parallel region. If the target property on a transition is omitted, then taking the transition has the effect of leaving the machine in the same state after invoking any executable content that is supplied via the actions property. Such a transition is equivalent to an 'event' handler in HST notation. Note that this is different from a transition whose target is its source state. In the latter case, the state is exited and reentered, triggering execution of its onentry and onexit executable content.

The target property may specify the destination by id or in-line. In the latter case, the in-lined state is private to the transition in the sense that no other transition may take it as a target. This convention allows an in-lined state to be used as a form of scratch state which is visible only locally.

3.3.1 Properties

event Property that specifies the trigger for this transition. We have not determined if it is optional. Wildcarded event names are supported.
cond Optional guard condition. If it is present, the transition is taken only if the guard condition evaluates to true.
target Optional property that specifies the new state or parallel element to transition to. May be specified by reference or in-line. May occur multiple times, but if more than one instance is present, all must specify descendants of the same parallel element. target may not co-occur with exit)
exit Used as a shorthand for defining a transition to an empty final state. (Exclusive with target) As an example the following two transitions are the same:

<transition></transition>
  <exit></exit>
 
            
<transition></transition>
 <target></target>
  <state final="true"></state>

actions Immediate children of transition other than those listed above are executable content that is run after the onexit handler for this state and before the onentry handler in the target state.

3.4 `PARALLEL`

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

For the parallel element to be useful, each of its state substates must itself be a complex state, i.e., one with either state or parallel children. When the state machine enters the parent parallel element, it simultaneously enters each child state. Transitions wihthin the individual child elements operate normally, but there may not be transitions between the child elements since that would violate the semantics of parallelism. However any of the child elements may take a transition outside the parallel element. When this happens, the parallel element and all of its child elements are exited and the corresponding onexit handlers are executed. The handlers for the child elements execute first, in no determinate order, followed by that for the parent parallel element, followed by an action expression in the transition element, and then the onentry handlers in the target state.

3.4.1 Properties

id
onentry
onexit
state Defines a parallel substate region. May occur 1 or more times.

4 Pseudo-States

The following elements are called 'pseudo-states' because they do not have the full properties of states (for example they lack onentry and onexit handlers) and do not map to states in the underlying semantics of the language. However, they can be used like states in many places. In particular, they can often be the target of transition. They are a notational shorthand allowing the simple statement of some sophisticated control constructs.

4.1 `INITIAL`

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

4.1.1 Properties

id Identifier for this pseudo-state
src Optional URL of a file containing the definition of this pseudo-state. Any definitions within the body of the initial element override those in the external file.
transition A conditionless transition (i.e., one without a cond or event property). Such a transition is always enabled and will be taken as soon as the state is entered. The target of the transition must be a descendant of the parent state of initial. if stateS1 has an initialchild with a transition with target S12, there is no semantic difference between a transition that takes S1 as its target and one that takes S1's initial child as a target and one that takes S12 as its target. The result in all three cases is that the system enters both S1 and S12 as an atomic action, executing the onentry handlers of first S1 and then S12.

4.2 `HISTORY`

The history pseudo-state allows for 'pause and resume' control flow. Whenever a complex state is exited, its history pseudo-state, if present, records the state configuration at exit. Later a transition taking the history state as its target allows the state to pick up where it left off.

4.2.1 Properties

id Identifier for this pseudo-state
src Optional URL of a file containing the definition of this pseudo-state. Any definitions within the body of the initial element override those in the external file.
type. Legal values are 'shallow' and 'deep', with default value 'shallow'. if the value is 'shallow' then this state records only the immediate children of the parent state. In this case a transition with the historypseudo-state as its target will end up in the immediate child state that the parent was in the last time it was exited. On the other hand, if this property is set to 'deep', the history pseudo-state will remember nested states. In this case a transition with the history pseudo-state as its target will end up in the mostly deeply nested descendant state the parent was in the last time it was exited.
transition A conditionless transition (i.e., one without a cond or event property). Such a transition is always enabled and may be taken as soon as the state is entered. This transition represents the default history state and indicates the state to transition to if the parent state has never been entered before. if type is 'shallow', then the target of this transition must be an immediate child of the parent state. Otherwise it can be any descendant state.

4.3 `JOIN`

The join pseudo-state provides barrier logic allowing the synchronization of defined threads of control. For a discussion of its semantics see E An Overview of Harel State Table Notation and Semantics.

4.3.1 Properties

id An identifier for this pseudo-state.
transition. May occur one or more times. May not contain an event. At least one instance must not contain cond guard condition. Note: All incoming transitions must be unconditional.

4.4 `SYNCH`

The sync state is actually a normal state, not a pseudo-state, but it is included here because of its close association with the join pseudo-state. For a discussion of its semantics see E An Overview of Harel State Table Notation and Semantics.

4.4.1 Properties

id Identifier for this state.
transition. Must occur once or more and not have either cond or event properties. The target must be a join pseudo-state.
bound. An integer which can be used to turn the sync state into a semaphore. Default value: unlimited.

5 Executable Content

Executable Content consists of actions that are performed when the selected handler is executed. In general, such content must be able to set variables, raise events, and invoke functionality in the underlying platform. On the other hand, Executable Content may not cause transitions or any form of change of state, except indirectly, by raising events that are then caught by transitions. There are a variety of possible forms for Executable Content, particularly since the capabilities of the underlying platform vary across implementations. The content presented here is closely based on that in CCXML. This is partly for reasons of backward compatibility, but also because CCXML's executable content is quite flexible, consisting of Flow Control Elements, Event Control Elements or Custom Action Elements.

Flow Control Elements are used to control the flow of execution within Executable Content.

Event Control Elements are used to control how and when events are sent from SCXML.

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

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

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

<transition event="ccxml:connection.alerting" name="evt"></transition>
  
  <send event="ccxml:accept" namelist="connectionid" targettype="ccxml"></send>

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

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

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

<onentry></onentry>
  
  <send event="ccxml:createcall" namelist="dest" targettype="ccxml"></send>

<transition event="ccxml:createcall.success" name="evt"></transition>

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

5.1 Variables and Expressions

5.1.1 `<assign></assign>`and

5.1.1.1 Overview

Variables are declared using the element and are initialized with the results of evaluating the optional expr attribute as an expression. If the expr attribute is not present in the declaration, the variable is initialized to undefined. The values of variables may be subsequently changed with <assign></assign>.

Variables are declared explicitly by :

Variables can be assigned new values using <assign></assign>:

<assign name="currentstate" expr="'cleanup'"></assign>

The implementation MUST evaluate the expression contained in the expr attribute of <assign></assign>, and assign the results to the variable referenced in the name attribute.

5.1.1.2 `Attribute Details`

Name Required Attribute Constraints Type Default Value Valid Values Description

name	true		Variable name	none	Valid Variable name	Indicates the name of the variable.
expr	false		Expression	none	Valid Expression	Indicates the new value of the variable. This is the initial value.

5.1.1.3 <assign></assign>Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description

name	true		Left Hand Side Expression	none	Variable	An left hand side expression evaluating to a previously defined variable. The value of the attribute will receive the result of the `expr` attribute.
expr	true		Expression	none	Valid Expression	Indicates the new value of the variable.

5.2 Event Control

5.2.1 `<send></send>`

5.2.1.1 Overview

<send></send>is used to send messages containing events or other information directly to another SCXML Interpreter, other external systems using an Event I/O Processor or to raise events in the current SCXML session.

The event target of <send></send>is specified using the target and targettype attributes. These attributes control how the platform should dispatch the event to its final destination.

The target attribute specifies the unique identifier of the event target that the Event I/O Processor should send the event to. This can be the value of a SCXML Session ID to another SCXML session. In the case where you are using some other Event I/O Processor this attribute should be able to describe how to connect to the event destination (For example a SIP URL for SIP-INFO messages or a HTTP URL for Web Services). If no target attribute is specified the default target is the current SCXML session. If the value of the target attribute is not supported, invalid or unreachable by the Event I/O Processor the Platform MUST throw a error.send.targetunavailable event.

The targettype attribute controls what Event I/O Processor the event should be sent to. The default value of this attribute is 'ssxml'. If the event targettype specified is not supported the platform MUST throw a error.send.targettypeinvalid event.

A platform must support the following values for the targettype attribute:

Value Details

scxml SCXML Session Event Processor.

Platforms may support other types of Event I/O Processors, for example: Web-services, SIP or basic HTTP GET. However, platforms SHOULD name the Event I/O Processor beginning with "x-" to signify that they are platform dependent.

<send></send>also specifies the content of the message to be sent. <send></send>may specify message content in one of two ways (the following mechanisms are mutually exclusive):

event attribute with an OPTIONAL namelist
- The event attribute specifies an expression that returns the name of the event.
- The namelist attribute specifies a space separated list of variables to be included with the message.
```
<send event="'fax.SEND'" namelist="content" targettype="'x-messaging'" target="target"></send>
```

xmlns attribute with explicit content inline XML content specifying the message to sent the xmlns:<namespace></namespace> defines a namespace for the inline content

<send targettype="'x-csta'" target="'csta://csta-server.example.com/'" xmlns:csta="http://www.ecma.ch/standards/ecma-323/csta"></send>
      <csta:makecall>
        <csta:callingdevice>22343
        <csta:calleddirectorynumber>18005551212</csta:calleddirectorynumber>
      </csta:callingdevice></csta:makecall>

If an explicit namespace is provided as in the xmlns attribute of the <send></send>, this namespace can be used to validate the content of the <send></send>. A namespace specified on a <send></send>applies only to the attributes and content of the <send></send>. Multiple namespaces MAY be included in the <send></send>to associate message content with more than one namespace.

When an explicit namespace is specified for the <send></send>, the content of the <send></send>is parsed but can be ignored by the sending SCXML Interpreter until the <send></send>is executed. XML namespace identifiers contained in the <send></send>MUST be preserved and it is the responsibility of the Event I/O Processor responsible for forwarding events to the <send></send>target to parse the incoming message and remove the namespace prefix, if required by the <send></send>target.

The sending SCXML Interpreter MUST NOT alter the content of the <send></send>. The data contained within a <send></send>MUST be sent to the destination specified in the target attribute of <send></send>using the Event I/O Processor specified by the targettype attribute. When <send></send>is used with inline XML content, and the target is a SCXML session, the mapping of that XML content to event object properties is implementation-specific, and outside the scope of this specification. Although the full set of requirements for the Event I/O Processor is not within the scope of this specification, an event processor sending an event to a SCXML Interpreter is required to generate an event which can be processed in a SCXML Session. See Section 9.1 for details regarding the processing of incoming events by an SCXML Interpreter.

When a message is successfully sent to the target, a send.successful event will be thrown. Note that this does not mean that the target processed the message successfully. It is up to the target to generate events specific to the message. These events are application specific.

If the send request fails, an event signifying the error will be returned to the SCXML Session. The failure events are documented at the end of this section.

5.2.1.2 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description

event	false	This attribute may not be specified in conjunction with inline content	Expression	none		An expression which returns a character string that indicates the type of event being generated. The event type may include alphanumeric characters and the "." (dot) character. The first character may not be a dot or a digit. Event type names are case-insensitive. If neither the `data` attribute or inline content is specified, an `error.fetch` event will be thrown. If used in conjunction with the inline content, an `error.fetch` will be thrown.
target	false		Expression	none	A valid target URL	An expression returning the target location of the event. The `target` attribute specifies the unique identifier of the event target that the Event I/O Processor should send the event to.
targettype	false		Expression	scxml	scxml	An expression which returns a character string that specifies the type of the Event I/O Processor that the event should be dispatched to. Values defined by the specification are: scxml - This species that the event will be dispatched to the SCXML Session Event Processor.
sendid	false		Left Hand Side Expression	none	Variable	An left hand side expression evaluating to a previously defined variable. The value of the attribute will receive an internally generated unique string identifier to be associated with the event being sent. If this attribute is not specified, the event identifier is dropped.
delay	false		Expression	'0s'	An expression which returns a character string in CSS2 [CSS2] format	The character string returned is interpreted as a time interval. The `send` tag will return immediately, but the event is not dispatched until the delay interval elapses. Timers are useful for a wide variety of programming tasks, and can be implemented using this attribute. `Note:` The queue for sending events is maintained locally. Any events waiting to be sent will be purged when the session that issued this request terminates.
xmlns:[YourNameSpacePrefix]	false		string	none		This returns a namespace identifying the contained message format. More than one `xmlns` attribute may be included.
namelist	false	This attribute may not be specified in conjunction with inline content	Var List	none	List of Variable names	A list of zero or more whitespace separated CCXML variable names to be included with the event. When an variable is included with the event, its value is first converted into a string. If the variable is an Object, the mechanism by which it is included is not currently defined. Instead of including Objects directly, the application developer may explicitly include the properties of an Object. e.g. "date.month date.year". If used in conjunction with the inline content, an `error.fetch` will be thrown.
hints	false		Expression	none	An expression.	The data returned contains information which may be used by the implementing platform to configure the event processor. The meaning of these hints is specific to the implementing platform and the event processor.

5.2.2 <cancel></cancel>

5.2.2.1 Overview

When a SCXML program uses <send></send>to send an event and includes a delay attribute, the <cancel></cancel>command will cancel the pending event, if possible.

The cancel operation will cancel a pending event by removing it from the event queue of the SCXML session from which it has been sent. If the delay has expired and the event has already been removed from the event queue, the <cancel></cancel>request will fail and an error.notallowed event will be delivered to the event queue of the SCXML session that executed the <cancel></cancel>.

The <cancel></cancel>element may be used to cancel events delivered to local or remote SCXML sessions. Compliant SCXML implementations are REQUIRED to support the cancellation of local events but may choose not to support the cancellation of remote events in which case an error.notallowed event should be thrown for such requests. The format of the event identifier returned by a <send></send>request, and specified in the sendid attribute of <cancel></cancel>, is implementation specific but is expected to uniquely define events across SCXML sessions.

5.2.2.2 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description

sendid true Expression none A valid event identifier An expression which returns the value of the event identifier that was received when the send command was issued.

5.3 Flow Control Elements

5.3.1 <if></if>

5.3.1.1 Overview

<if></if>is a container for conditionally executed elements. <else></else>and <elseif></elseif>can optionally appear within an <if></if>as immediate children, and serve to partition the elements within an <if></if>. <else></else>and <elseif></elseif>have no content. <else></else>is a synonym for <elseif cond="true"></elseif>.

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

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

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

<if cond="..."></if>
  <!----> is true ->
  <else></else>
  <!----> is false ->

However, <else></else>is a synonym for <elseif cond="true"></elseif>, so an example such as:

<if cond="..."></if>
  <!----> is true ->
  <else></else>
  <!----> is false ->
  <else></else>
  <!---->

is also possible and must be interpreted as:

<if cond="..."></if>
  <!----> is true ->
  <elseif cond="true"></elseif>
  <!----> is false ->
  <elseif cond="true"></elseif>
  <!---->

With this definition for <else></else>, a valid XML [XML] document is also a valid SCXML document.

5.3.1.2 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description

An expression which can be evaluated to true or false.

5.3.2 <elseif></elseif>

5.3.2.1 Overview

An <elseif></elseif>partitions the content of an <if></if>, and provides a condition that determines the selection of the partition it begins. <elseif></elseif>can appear optionally as an immediate child of an <if></if>.

5.3.2.2 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description

An expression which can be evaluated to true or false.

5.3.3 <else></else>

5.3.3.1 Overview

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

5.3.3.2 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description

none

else is a synonym for elseif cond="true".

5.4 Debugging Elements

5.4.1 <log></log>

5.4.1.1 Overview

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

5.4.1.2 Attribute Details

Name Required Attribute Constraints Type Default Value Valid Values Description

label	false		Expression	none		An expression which returns a character string which may be used, for example, to indicate the purpose of the log.
expr	true		Expression	none		An expression evaluating to a string to be logged.

7 Related Work

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