Can you read that XML?

XML doesn't always provoke a good reaction on the readability front. Human readability, that is, rather than machine readability. Though often times, the examples of XML vocabularies that seem most tenuous are not designed with humans as the primary consumer in mind. Case in point: the UML2 XMI vocabulary subset for state machines as compared to SCXML. The former is undoubtedly convenient for machines, especially when you come at it from the tooling stack with editors in mind as it holds more graphical information that SCXML. With SCXML, on the other hand, human readability has always been an important design point.

I. To id or not to id

In SCXML, there is no need to id anything that is never again referred to. This includes <state>s, <invoke>s, <send>s etc. When a reference is needed, an id of the author's choice is supplied, with the caveat that the author has to ensure uniqueness. With XMI, for example, every state gets an generated id which is guaranteed to be unique and also guaranteed to be unreadable for humans. For example, its hard to say what the semantics of these states are with respect to the particular state machine at hand:

II. Lost and found

Graphically, each component of a state machine, be it a state or a transition or an entry point is a separate entity. XMI models the markup in a flat fashion, as a list of things on the screen all correlated using ids. SCXML nests certain elements in a manner that helps identify certain types of ownerships. For example, outbound transitions belong to the source state. Which means a state with three transitions looks like:

as against this (note that the snippet is really simplified, human readability ofcourse worsens exponentially with growing number of these elements):

III. Getting elemental

SCXML uses different element names for different types of pseudostates and state types (such as initial, history, state, final) which helps human readability whereas XMI uses the same element name.

Compare:

with:

VoiceXML 3.0 Third Working Draft published

The data layer, flow layer, profiles and event model building on DOM Level 3 events is shaping up. Kaz's announcement on www-voice:

Hi www-voice,

The third Working Draft of "Voice Extensible Markup Language
(VoiceXML) 3.0" has been published as follows.

This version:
  http://www.w3.org/TR/2009/WD-voicexml30-20090825/

Latest version:
  http://www.w3.org/TR/voicexml30/

Previous version:
  http://www.w3.org/TR/2009/WD-voicexml30-20090602/

A diff-marked version is also available for comparison purposes at:
http://www.w3.org/TR/2009/WD-voicexml30-20090825/diff.html

Best regards,

Kazuyuki Ashimura
for the W3C Voice Browser WG

Using UML2 Tools for SCXML

UML2 Tools from the Eclipse Model Development Tools (MDT) project provides a set of GMF-based (Graphical Modeling Framework) editors for viewing and editing UML models. After a quick install on Galileo, it was time for some experimentation. The diagramming feature-set is certainly more constrained than some of the other proprietary products in the space, particularly in the context of executable content in state machines. The model format used is XMI (XML Metadata Interchange) and there have been a couple of requests on Apache Commons user mailing list to get a stylesheet going to convert to State Chart XML (SCXML). r808257 adds the beginnings of such a stylesheet to the Commons SCXML extras.

A UML2 state machine diagram can actually contain multiple disconnected state machines. Since each needs to be styled to its own SCXML document, that clearly ruled in favor of using the less pervasive XSLT 2.0, for <xsl:result-document>. Which meant support for if-then-else in the XPaths came along, which turned out quite handy.

The transformation itself isn't too bad, once its bootstrapped. At the onset, to get the SCXML ball rolling, the first order of business is to determine whether the state machine has top level orthogonal states (<region>s in XMI). The second is to determine the initial state for each of the orthogonal states, which in XMI turns out to be a subvertex of type pseudostate with no value in the kind attribute i.e. subvertex[@xmi:type='uml:Pseudostate'][empty(@kind)]

And that gives us:

Once we get down from the region to the subvertex itself, the transformation is a straightforward switch on the type of the state to generate (abridged via ellipsis):

With increased UML2 Tools capabilities for the state machine diagram editor, many of us may soon have easy access to the model to middleware transformation below: