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: