DOM Event I/O Processor for SCXML

W3C Working Group Note 11 August 2015

This version:
Latest version:
Previous version:
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


This document describes the DOM Event I/O Processor for SCXML [SCXML]. This event processor allows SCXML state machines to communicate with external entities via DOM Events. For more details on Event I/O Processors, see the SCXML specification.

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 is W3C Note contains the description of the DOM I/O Processor for SCXML, which was part of the [SCXML] specification, but was removed because we did not receive enough implementation reports for it to be included in the final W3C Recommendation. However there was enough interest in it, including an implementation, that the Working Group decided to publish it as a separate note for archival purposes.

This Note was once published on 6 August 2015 as a First Public Working Group Note. However, after the publication we got comments that the Note's having a shortname of "dom-iop" was misleading since the Note does not belog to the core set of the DOM specifications but describes the DOM I/O processor for SCXML. Therefore this Note is now republished with a clearer shortname of "scxml-dom-iop" to avoid confusion.

The W3C Membership and other interested parties are invited to review the document and send comments to the Working Group's public mailing list www-voice@w3.org(archive). See W3C Mailing List and Archive Usage Guidelines.

This document has been produced as part of the Voice Browser Activity (activity statement), following the procedures set out for the W3C Process. The authors of this document are members of the Voice Browser Working Group.

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

Publication as a Working Group Note 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.

This document is governed by the 14 October 2005 W3C Process Document.

Table of Contents

1 Terminology
2 Overview
3 DOM Event I/O Processor
    3.1 Sending Events
    3.2 Receiving Events
    3.3 _ioprocessors Value


A References
    A.1 References

1 Terminology

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 [RFC 2119].

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

2 Overview

The DOM Event I/O processor handles communication between SCXML Interpreters and nodes in documents that implement the DOM. 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. (Note that the syntax and semantics of SCXML make no reference to the DOM, so that 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 User Agent can notify SCXML when the user clicks on a button, and the SCXML markup can notify the appropriate element 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 [DOMEvents], which are a general means for information propagation in XML documents. Note that we do not require that the SCXML document be represented in the other markup's DOM (though it may be).

3 DOM Event I/O Processor

3.1 Sending Events

The SCXML Processor MUST support sending DOM events to any node in the document by selecting the DOM Event I/O processor (type="http://www.w3.org/TR/scxml/#DOMEventProcessor") and specifying the node as the target. Processors MUST support CSS notation [CSS2] for specifying the node, and MAY support XPath [XPath 1.0] [XPath 2.0] or other notations. The SCXML Processor MUST support sending events that implement the CustomEvent interface. The Processor MAY support sending events that implement other interfaces. In this case, the Processor MUST support an additional attribute on <send>, called 'interface', that allows the author to specify the interface to use. The default value of this attribute MUST be 'CustomEvent'.

The Processor MUST use the value of the 'event' attribute as the type of the DOM event. The Processor MUST support two additional attributes on <send>, called 'cancelable' and 'bubbles', which can be used to set the corresponding properties of the event. The default value for 'cancelable' MUST be 'false'. The default value of 'bubbles' MUST be 'true'. The Processor MUST populate any other initializable attributes of the event with the values of any matching keys specified via "namelist" or <param>. If the specified DOM event type has a 'detail' attribute, the Processor MUST populate it with any remaining data (i.e., values specified by 'namelist', <param> or <content> that are not used to populate the event's initializable attributes.) If the specified event is not a legal DOM event or if the specified node cannot be reached, the SCXML Processor MUST place the error error.communication in the internal event queue.

A References

A.1 References

Cascading Style Sheets, level 2: CSS2 Specification World Wide Web Consortium. W3C Recommendation, May 1998. (See http://www.w3.org/TR/1998/REC-CSS2-19980512/.)
Document Object Model (DOM) Level 3 Events Specification World Wide Web Consortium. W3C Working Draft, 05 November 2013. (See http://www.w3.org/TR/DOM-Level-3-Events/.)
RFC 2119
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels Internet Engineering Task Force. March 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)
RFC 2396
RFC 2396: Uniform Resource Identifiers Internet Engineering Task Force. August 1998. (See http://www.ietf.org/rfc/rfc2396.txt.)
State Chart XML (SCXML): State Machine Notation for Control Abstraction. W3C Candidate Recommendation 2015. (See http://www.w3.org/TR/scxml/.)
XPath 1.0
XML Path Language (XPath) 1.0 World Wide Web Consortium. W3C Recommendation, November, 1999. (See http://www.w3.org/TR/xpath/.)
XPath 2.0
XML Path Language (XPath) 2.0 World Wide Web Consortium. W3C Recommendation, December, 2010. (See http://www.w3.org/TR/xpath20/.)