STXT frente a XML
XML es el formato más cercano a STXT: un árbol de nodos con nombre, namespaces y esquemas. STXT busca lo mismo, en un documento que se pueda escribir y leer a mano.
El mismo contenido, dos veces
La cabecera de un artículo en XML:
<article xmlns="http://example.com/articles">
<title>Modern Software & Architecture</title>
<published>2026-09-01</published>
<author email="ana@example.com">Ana López</author>
<summary>
A survey of monoliths, microservices
<and everything in between>.
</summary>
</article>Y en STXT:
Article (com.example.articles): Modern Software & Architecture
Published: 2026-09-01
Author: Ana López
Email: ana@example.com
Summary >>
A survey of monoliths, microservices
<and everything in between>.Es el mismo árbol, con la misma idea de namespace. Las diferencias son estas:
| XML | STXT | |
|---|---|---|
| Fin de un nodo | Etiqueta de cierre | La indentación |
Caracteres < y & |
Se escapan (<, &) o van en CDATA |
No significan nada, cualquier carácter es legal |
| Dónde va un dato | En un atributo o en un elemento hijo | Siempre en un nodo hijo |
| Entidades | Internas y externas | No tiene |
| Esquemas | DTD, XSD, RELAX NG, Schematron | @stxt.schema y @stxt.template, escritos en STXT |
Escapes y entidades
XML reserva < y & en el contenido. El texto se escapa, o se envuelve en una sección CDATA,
que a su vez no puede contener ]]>.
Las entidades abren además dos ataques conocidos:
- Entidades externas (XXE): leen ficheros o alcanzan la red.
- Expansión de entidades: agota la memoria.
Los parsers endurecidos desactivan esas características. STXT no las tiene: no hay entidades, referencias ni inclusión (STXT-SPEC §15).
Atributos y elementos
XML ofrece dos sitios para un dato, atributo o elemento hijo. Cada vocabulario decide, y quien lo lee tiene que mirar los dos:
<server name="db1" host="10.0.0.5" port="5432">
<timeout unit="s">30</timeout>
<replica host="10.0.0.6"/>
<replica host="10.0.0.7"/>
</server>En STXT solo hay nodos. Lo que en XML era atributo o elemento es aquí, en los dos casos, un hijo:
Los atributos de XML son más compactos en una línea. STXT renuncia a eso a cambio de una forma única.
La validación
Un XSD para el artículo del principio:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://example.com/articles"
xmlns="http://example.com/articles"
elementFormDefault="qualified">
<xs:element name="article">
<xs:complexType>
<xs:sequence>
<xs:element name="title" type="xs:string"/>
<xs:element name="published" type="xs:date"/>
<xs:element name="author" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="email" type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="summary" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>Y la plantilla STXT, escrita en el propio lenguaje y con la forma del documento que describe:
Template (@stxt.template): com.example.articles
Structure >>
Article (com.example.articles):
Published: (1) DATE
Author: (+)
Email: (1) EMAIL
Summary: (?) TEXTNo son equivalentes del todo, y la diferencia va en las dos direcciones:
- El XSD valida más: el orden de los hijos (
xs:sequence), patrones, rangos y tipos derivados. Los esquemas de STXT no validan el orden, y no tienen expresiones regulares ni reglas condicionales (STXT-SCHEMA-SPEC §11). - La plantilla comprueba que
Emailes una dirección de correo, yxs:stringno lo hace. - El modelo de la plantilla es cerrado: cualquier hijo no declarado es un error.