Qué es SCXML: el estándar que casi nadie escribe

Llevas nueve niveles escribiendo máquinas sin preguntar de dónde salen sus reglas. Por qué el hijo gana al padre cuando ambos podrían transicionar. Por qué un evento levantado con raise se procesa antes que uno enviado desde fuera. Por qué al entrar en un estado compuesto se ejecuta primero el entry del padre y luego el del hijo, y no al revés. Ninguna de esas decisiones es arbitraria ni es una invención de XState: están escritas, palabra por palabra, en una Recomendación del W3C de 2015 llamada SCXML. La paradoja de este estándar es que su formato —XML— casi nadie lo usa, mientras que su contenido —un algoritmo de interpretación de treinta páginas— lo obedece medio ecosistema sin saberlo. Este nivel entero trata de esa parte invisible: no del XML, sino de la semántica que el XML solo sirve para transportar.

De Harel a la Recomendación: tres décadas de precisión creciente

David Harel publicó en 1987 el artículo que fundó el campo, Statecharts: A Visual Formalism for Complex Systems, escrito a partir de su trabajo sobre la aviónica de un caza donde las máquinas de estado planas habían colapsado bajo la explosión combinatoria. Aquel artículo aportó la jerarquía, la ortogonalidad y la historia —las tres ideas del nivel 2—, pero era ante todo un formalismo visual: definía qué se dibuja, no exactamente qué ocurre al ejecutarlo. La semántica operacional llegó después, con STATEMATE y el artículo de Harel y Naamad de 1996, y llegó ya bifurcada.

Esa bifurcación es el problema central de la historia. En 1994 Michael von der Beeck catalogó más de veinte variantes de statecharts que diferían en cuestiones nada cosméticas: si el efecto de una transición es visible en el mismo paso o en el siguiente, si gana la transición más externa o la más interna, si un evento generado internamente se consume ya o espera al próximo ciclo. Dos herramientas podían aceptar el mismo diagrama y ejecutarlo distinto. Cuando UML absorbió los statecharts a finales de los noventa les dio un vocabulario común y una notación estable, pero su especificación describía la semántica en prosa deliberadamente abierta, con puntos de variación explícitos que cada fabricante rellenaba a su gusto.

Conviene medir bien la gravedad de aquello. No se trataba de que las herramientas tuvieran atajos distintos o exportaran formatos incompatibles, problemas irritantes pero superficiales. Se trataba de que el mismo dibujo, con las mismas cajas y las mismas flechas, describía comportamientos diferentes según quién lo ejecutara, y de que no había forma de decidir cuál era el correcto porque no existía una definición de correcto. Un diagrama de estados era, en la práctica, documentación con apariencia de especificación: precisa a la vista, ambigua en el fondo, y por tanto inútil como contrato entre un equipo que diseña y otro que implementa.

flowchart LR
H[Harel 1987 formalismo visual] --> S[STATEMATE 1996 semantica operacional]
H --> V[Variantes academicas e industriales]
S --> U[UML State Machines]
V --> U
U --> W[W3C SCXML 2005 a 2015]
W --> X[XState SCION Qt SCXML Commons SCXML]
style H fill:#cba6f7,color:#11111b
style W fill:#a6e3a1,color:#11111b
style X fill:#89b4fa,color:#11111b

SCXML nació en 2005 en un lugar inesperado: el grupo de trabajo de navegadores de voz del W3C, que necesitaba una capa de control por encima de VoiceXML y CCXML para orquestar llamadas telefónicas. El nombre completo lo delata: State Chart XML: State Machine Notation for Control Abstraction. Diez años de borradores después, el 1 de septiembre de 2015, se convirtió en Recomendación. Y en ese trayecto ocurrió lo decisivo: el grupo entendió que una notación sin algoritmo no resuelve nada, y añadió un apéndice normativo con el intérprete completo escrito en pseudocódigo. Ese apéndice, no la sintaxis, es lo que convirtió a SCXML en el árbitro del dominio.

El origen telefónico dejó dos huellas visibles en el diseño. La primera es la obsesión por la comunicación entre sesiones: SCXML no asume que una máquina viva sola, sino que define procesadores de entrada y salida de eventos —uno interno, uno sobre HTTP, uno sobre el DOM— porque su caso de uso original era coordinar máquinas distribuidas en una centralita. La segunda es la neutralidad respecto al lenguaje de expresiones: la Recomendación admite tres modelos de datos —null, ecmascript y xpath— y deja la puerta abierta a otros, precisamente para no atar el control a ninguna plataforma. Ambas decisiones envejecieron de forma desigual, pero explican por qué el vocabulario incluye cosas que a un desarrollador de interfaces le parecen exóticas.

Anatomía de un documento: el vocabulario completo

Un documento SCXML es un árbol de estados con contenido ejecutable colgando de él. Su vocabulario es corto y casi todo te resultará familiar, porque lo has estado usando bajo otros nombres durante nueve niveles.

Lo notable de esa lista es lo corta que es. Un lenguaje capaz de describir el control de una centralita telefónica, la interfaz de un vehículo o el flujo de una compra cabe en veinte elementos, y la razón es que casi toda su expresividad viene de la composición y no del vocabulario: anidar estados, poner regiones en paralelo y colgar contenido ejecutable de los puntos correctos basta para cubrir el dominio entero. Es la misma economía que hace que los lenguajes funcionales pequeños compitan con los grandes.

Un ejemplo mínimo con reintentos concentra casi todo el vocabulario en veinte líneas.

<scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0"
       datamodel="ecmascript" initial="inactivo">
  <datamodel>
    <data id="intentos" expr="0"/>
  </datamodel>

  <state id="inactivo">
    <transition event="FETCH" target="cargando"/>
  </state>

  <state id="cargando">
    <onentry>
      <assign location="intentos" expr="intentos + 1"/>
      <send event="TIMEOUT" delay="5s" id="reloj"/>
    </onentry>
    <onexit>
      <cancel sendid="reloj"/>
    </onexit>
    <transition event="done" target="exito"/>
    <transition event="error" cond="intentos &lt; 3" target="cargando"/>
    <transition event="error" target="fallo"/>
  </state>

  <final id="exito"/>
  <state id="fallo"/>
</scxml>

Dos detalles merecen atención. El primero es que las dos transiciones con event="error" están ordenadas: la condicional aparece antes, y por eso gana mientras se cumpla. Ese desempate por orden documental es una regla normativa que la lección 3 desarrollará. El segundo es el < dentro de la condición: la sintaxis XML obliga a escapar el operador menor que, lo cual ilustra por qué el formato nunca conquistó a nadie. La semántica es elegante; el transporte, no.

Hay una tercera lectura, más sutil, en el par formado por el send con retardo y el cancel en la salida. Ese idioma —programar un temporizador al entrar y cancelarlo al salir— es la forma canónica de expresar un plazo asociado a un estado, y SCXML la deja explícita en lugar de esconderla tras un atajo. XState la esconde con after, que es más cómodo y estrictamente equivalente. Ver la versión desplegada ayuda a entender por qué un after desaparece al abandonar el estado: no es magia del framework, es un cancel que alguien escribió por ti.

Por qué XState se apoya en SCXML sin hablar XML

XState no lee XML en su núcleo, y sin embargo su documentación se ha definido durante años por conformidad con SCXML. La razón es estratégica antes que técnica: implementar una semántica ya normalizada y verificada por una batería pública de tests le ahorró al proyecto discutir cada decisión de diseño desde cero, y le dio un argumento de autoridad frente a la pregunta inevitable de qué pasa en los casos raros. La respuesta es siempre la misma: lo que dice el apéndice D.

El beneficio para quien usa la librería es menos obvio y más duradero. Significa que el conocimiento que adquieres al aprender XState no es conocimiento de una API sino de un modelo computacional, y que por tanto se transfiere. Significa también que cuando la documentación calla —y toda documentación calla en algún momento— existe una fuente superior a la que acudir en lugar de recurrir a la experimentación a ciegas. Pocas librerías de gestión de estado ofrecen algo parecido: en la mayoría, el comportamiento en los casos límite es lo que haga la implementación actual, y eso puede cambiar en la siguiente versión menor sin que nadie lo considere un cambio de contrato.

La tabla revela también dónde XState se aparta. Los nombres de eventos automáticos se renombraron al espacio xstate. en la versión 5, el modelo de datos de SCXML se sustituyó por el context con assign, y las expresiones dejaron de ser cadenas evaluadas para ser funciones de JavaScript con tipos. Son divergencias de superficie: ninguna toca el algoritmo. Lo que XState hereda íntegro es el orden de ejecución, la resolución de conflictos, el cálculo de conjuntos de entrada y salida, y la disciplina de ejecución hasta completar.

El linaje tiene además un eslabón intermedio que conviene conocer. Antes de XState existió SCION, un intérprete de SCXML escrito en JavaScript que demostró que la semántica del W3C podía ejecutarse en el navegador con rendimiento razonable, y que sirvió de referencia técnica y conceptual para lo que vino después. La contribución de XState no fue inventar la semántica sino domesticar su ergonomía: sustituir el XML por objetos literales, añadir inferencia de tipos que hace imposible enviar un evento inexistente, y envolver todo en herramientas de visualización e inspección. Es una historia frecuente en el software: el estándar aporta las decisiones difíciles y la librería aporta que quepan en el día a día.