comments on SCXML

as per my action http://www.w3.org/XML/XProc/2013/12/11-minutes

here is a brief review of SCXML with focus on identifying similarities
and differences with XProc,

to help aid XProc WG respond to SCXML WG request to provide comment.

--------------------------
SCXML tldr;
--------------------------

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

SCXML is an XML language that provides generic state-machine based
execution environment based on Harel statecharts.

Where Harel statecharts has had some recent exposure via extensions to  UML.

   http://en.wikipedia.org/wiki/State_diagram#Harel_statechart

SCXML goal is to provide a standardized state machine representation
for use in other XML languages. In concrete terms, SCXML initial use
case was to specifically target a replacement for state machine
representations in future versions of CCXML.

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

As a conceptual aid, consider the following contrived 'hello world'
SCXML example

 <scxml xmlns="http://www.w3.org/2005/07/scxml"
              version="1.0"
              initialstate="hello">

     <state id="hello" final="true">
      <onentry>
       <log expr="'hello world'" />
      </onentry>
      <transition cond="1 - 1" target="other">
               <script>enterStartOver();</script>
      </transition>
      <transition event="someEvent" target="hello"/>
      <onexit>
         <if cond="cond1">
              <script> ... do something ... </script>
         <elseif cond="cond2">
              <script>... do something ... </script>
         </elseif>
         <else>
              <script> ... do something ... </script>
         </else>
         </if>
      </onexit>
     </state>
      <state id="other">....</state>
</scxml>

which defines a 'hello' state, which when transitioned too, executes
on entry into the state the log command. As the initial state has been
defined as 'hello' this state is entered upon start of SCXML
execution.

The example illustrates the concept of 'executable content' in the
form of on entry and on exit, where the former uses the built in <log>
 to log system message and the later illustrates the more
comprehensive (and interesting in terms of xproc overlap) with the
<if> logic structure. As we have no further state transitions, we
never exit and thusly the <onexit> bit never gets executed.

A common usage of 'executable content' is as the direct child of
<transition/> element. State change is  as well as transition upon the
receipt of a specific event (someEvent).

In XProc, documents flow through a pipeline, which in turn define
context for steps to perform commands against. In a similar sense for
SCXML, we could imagine executable content (via perhaps script)
working on documents in SCXML but this approach runs counter to the
'natural grain' of SCXML processing.

The difference with SCXML is that state flow is being modeled and even
more interesting is the provision of <datamodel/> which travels with a
state. Lastly, transitions are event driven, where events are
processed from a queue ... I won't go into much detail here, the spec
does a relatively good job at illuminating the heuristics of
interaction with events and state transition.

What this example does not convey is 'what' the context is and thats
because the example provided is too simple ... for deeper insights take
a look at some of the examples;

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

Which shows how data in <datamodel> can be mutated and tested against,
nested states, more sophisticated transitions etc...

--------------------------
similarities
--------------------------

* executable content itself could be easily replaced by an xproc pipeline
* SCXML <datamodel/> weakly equiv to documents flowing through in
XProc ... it provides a context of sorts
* SCXML nested states provide similar levels of complex processing, as
is available with compound/multicontainer steps, though by completely
different mechanisms
* SCXML <if><elseif><else> roughly emulates <p:choose>
* SCXML <foreach> roughly emulates <p:for-each>

--------------------------
differences
--------------------------
* In SCXML, process flow is defined by event driven state transition,
in XProc, documents and connected pipes drive process flow
* In SCXML, <parallel/> gives explicit control of processing, where
this is a natural side effect of process flow (based on connected
pipes at runtime) ... which gives a sense of the default posture in
terms of parallel execution
* SCXML event handling is unique

--------------------------
summary
--------------------------

The language surrounding states in SCXML

	* micro and macro steps
	* compound state
	* source and target states

strike chords with how we describe steps in XProc, but its important
to understand that different things are being discussed.

in section 4.10 Extensibility of Executable Content, it normatively states

 'MAY provide additional executable content corresponding to special
features of their implementations'

which means we could envisage a pipeline being inserted, but as there
is no <foreach> example in section C.3 The XPath Data Model with which
to provide context, its unclear of how context would be set or what it
would mean in terms of what happens to result doc(s) on result output
port. I think we should pursue this question with the SCXML WG.

Additionally, the <script/> element may be another logical integration
point between SCXML and XProc.

I also think that we should press the SCXML WG to consider adopting
latest XPATH.

----

There are similarities between SCXML and XProc and I believe its
possible to write near similar processing with each ... though both take
radically different approaches to solving problems.

SCXML models state as nodes, where the events are edges which actuate
state transition, that invokes processing to occur. Transition can
also occur as a test condition on <datamodel/>; but as any mutation to
this data is achieved by events, it remains true that all state
transition is event driven.

XProc models the flow of documents through steps, each step performing
some kind of process. In SCXML model terms, these XProc nodes could be
viewed as implicit 'edges' eg. not events per se but related to events
(via their invocation of 'executable content').

It is my view that SCXML is a dsl geared for management of state,
which could be painfully emulated with XProc. Conversely, SCXML could
be made to perform many of the use cases of XProc, though painfully so
in some cases. I do not view XProc as a complete superset to SCXML,
nor vice versa ... they should be viewed as potentially complementary
technologies, geared for solving different problems, though with
overlap. This overlap could be minimised with my previous suggestion
of engaging the SCXML WG to outline issues revolving around context.

This review was time boxed, to uncover top level concerns ... its
probable I missed off things, but thought I should send through my
early findings so we can discuss at next WG meeting.

Jim Fuller

Received on Wednesday, 29 January 2014 18:33:27 UTC