STXT frente a XML

De todos los formatos de esta serie, XML es el que más terreno comparte con STXT. Ambos modelan un documento como un árbol de nodos con nombre; ambos agrupan vocabularios con namespaces; ambos validan contra una estructura declarada. XML demostró que esas ideas funcionan a escala industrial. STXT persigue las mismas ambiciones con una restricción distinta: que el documento se pueda escribir y leer a mano sin etiquetas de cierre ni escapes.

El mismo contenido, dos veces

La cabecera de un artículo en XML:

<article xmlns="http://example.com/articles">
	<title>Modern Software &amp; Architecture</title>
	<published>2026-09-01</published>
	<author email="[email protected]">Ana López</author>
	<summary>
		A survey of monoliths, microservices
		&lt;and everything in between&gt;.
	</summary>
</article>

Y en STXT:

Article (com.example.articles): Modern Software & Architecture
	Published: 2026-09-01
	Author: Ana López
		Email: [email protected]
	Summary >>
		A survey of monoliths, microservices
		<and everything in between>.

El mismo árbol, la misma idea de namespace, y dos costes que desaparecen: nada se cierra — la indentación ya dice dónde termina Article — y nada se escapa, porque &, < y > no significan nada en un valor o un bloque de texto STXT.

Escapes y entidades

XML reserva < y & en todas partes, así que el texto debe escaparse o envolverse en CDATA, y la corrección depende de hacerlo cada vez. Las entidades abren además la superficie de ataque clásica: entidades externas (XXE) que leen ficheros o alcanzan la red, y expansión de entidades que agota la memoria. Los parsers endurecidos desactivan esas características; STXT nunca las tuvo. No hay entidades, ni referencias, ni inclusión, y cualquier carácter es legal en un valor o un bloque — el modelo de seguridad es normativo en STXT-SPEC §15.

Atributos y elementos

Cada vocabulario XML vuelve a decidir qué va en atributos y qué en elementos hijos, y los consumidores deben manejar ambos. STXT tiene una sola construcción: un nodo con valor e hijos, o un nodo con texto literal. Author, arriba, lleva su valor y un hijo Email; no hay un segundo eje que diseñar ni que parsear. Lo que XML gana con los atributos — metadatos compactos en línea — STXT lo cambia deliberadamente por uniformidad, como argumenta Principios de diseño.

La validación

XML tiene tres lenguajes de esquema — DTD, XSD y RELAX NG —, cada uno un ecosistema propio; XSD en particular es una especificación en dos partes con un sistema de tipos propio. La capa de esquemas de STXT es una página de conceptos — nodos, tipos, cardinalidades, un modelo de contenido cerrado — escrita en el propio STXT, en una forma de plantilla que refleja el documento:

Template (@stxt.template): com.example.articles
	Structure >>
		Article (com.example.articles):
			Published: (1) DATE
			Author: (+)
				Email: (1) EMAIL
			Summary: (?) TEXT

Valida menos que XSD — sin expresiones regulares sobre el contenido, sin reglas condicionales, sin restricciones de orden —, y cada una de esas ausencias es un no-objetivo declarado de la spec, que documenta qué queda fuera y por qué: mantener el modelo pequeño y predecible, con errores sobre los que una persona puede actuar (STXT-SCHEMA-SPEC §11).

Cuándo usar cada uno

Usa XML donde su ecosistema es el valor: estándares establecidos (DocBook, SVG, ODF, RSS), cadenas de herramientas construidas sobre XSLT y XPath, y vocabularios que necesitan contenido mixto — marcado en línea entretejido con la prosa —, que STXT deliberadamente no modela.

STXT encaja en los documentos que las personas redactan y las organizaciones validan: documentos corporativos, contratos, RFCs y propuestas técnicas, contenido de un CMS. El tutorial enseña el lenguaje entero de una sentada, el playground ejecuta los ejemplos de arriba, y la versión corta de esta comparación está en la FAQ.