STXT frente a YAML

YAML es el estándar de facto de toda una generación de herramientas de infraestructura, y donde un ecosistema espera YAML, YAML es la respuesta correcta. La comparación va del diseño: qué le pide cada lenguaje a la persona que lo escribe, y qué le devuelve.

Hay además una diferencia de modelo previa a cualquier sintaxis: YAML no tiene el concepto de namespace. Nada en un documento YAML declara a qué vocabulario pertenece ni contra qué estructura debería validarse; esa información vive fuera, en la herramienta que lo lee. En STXT el namespace forma parte del lenguaje (STXT-SPEC §7) y es lo que conecta cada documento con su definición.

El mismo contenido, dos veces

Un pequeño descriptor de servicio en YAML:

service: billing
replicas: 2
ports:
  - 8080
  - 8443
maintainer: [email protected]
notes: |
  Restarted after the 2026-08-31 incident.
  The TLS certificate expires on 2027-03-01.

Y en STXT:

Service:
	Name: billing
	Replicas: 2
	Port: 8080
	Port: 8443
	Maintainer: [email protected]
	Notes >>
		Restarted after the 2026-08-31 incident.
		The TLS certificate expires on 2027-03-01.

Los dos documentos se parecen, y ese parecido es el sentido de la comparación: las diferencias están en las reglas que hay detrás de la indentación, no en la superficie.

Las reglas detrás de la indentación

La especificación de YAML es de las más extensas de cualquier formato de texto, y la superficie esconde decisiones que cambian el significado de un valor:

• Tipado implícito. no es un booleano en YAML 1.1 y una cadena en 1.2; 1.20 es un número y pierde el cero final; una versión como 3.10 significa algo distinto de "3.10". Que hagan falta comillas depende del contenido del valor.
• Dos sintaxis para las colecciones. El estilo de bloque y el de flujo ([a, b], {k: v}) conviven, y los documentos reales los mezclan.
• Anclas, alias y etiquetas. Las referencias (&a, *a) y las etiquetas de tipo (!!) forman parte del lenguaje, aunque la mayoría de los documentos no las usen nunca.
• La indentación es flexible. Cualquier número de espacios por nivel, decidido documento a documento; los tabuladores están prohibidos.

STXT mantiene las reglas en una página, y ninguna depende del contenido:

• Un valor siempre es texto. no, 1.20 y 3.10 son los caracteres escritos, sin comillas y sin excepciones. Los tipos existen, pero se declaran en el esquema; no los adivina el parser.
• Una forma de nodo, dos separadores. Nombre: valor para la estructura, Nombre >> para el texto literal. No hay una segunda sintaxis para lo mismo: una lista es un hijo repetido, como desarrolla la FAQ.
• Indentación fija. Un tabulador o cuatro espacios por nivel, igual en todos los documentos; mezclarlos en una línea es un error de parseo, no una convención.

El texto libre

Los dos lenguajes pueden incrustar texto de varias líneas, y la diferencia de mecanismo es representativa. Los escalares de bloque de YAML combinan tres decisiones — literal | o plegado >, el recorte -/+, y un indicador opcional de indentación — y la cadena resultante depende de todas. STXT tiene una sola construcción: todo lo indentado bajo un nodo >> es texto tal como se escribió, sin variantes, sin escapes y sin interpretación. Los blancos finales y las líneas vacías finales se recortan, y la regla es la misma para una nota de dos líneas y para un contrato de veinte páginas (STXT-SPEC §10).

El parseo y la superficie de ataque

Un parser YAML conforme es un proyecto grande, y en la práctica los parsers discrepan en los casos límite; cargar un documento con la API equivocada ha significado históricamente instanciación de objetos (las etiquetas) y agotamiento de memoria (la expansión de anclas, el ataque "billion laughs"). Nada de esto hace inutilizable a YAML — las bibliotecas maduras tienen modos seguros —, pero es una superficie que un formato de documentos no necesita.

STXT elimina la superficie en lugar de mitigarla: sin entidades, sin referencias, sin anclas, sin inclusión, sin ejecución de código, y el parseo es lineal, línea a línea, en una sola pasada. Un parser conforme se escribe en días y se comporta igual en todas las implementaciones, que es lo que certifica el corpus de conformidad. El modelo de amenazas es normativo: STXT-SPEC §15.

La validación

YAML no tiene capa de esquemas propia: la validación se delega en herramientas externas y convenciones de otros ecosistemas. En STXT la capa de esquemas forma parte del lenguaje, opcional y cerrada. El descriptor de arriba, validado:

Template (@stxt.template): com.example.deploy
	Structure >>
		Service (com.example.deploy):
			Name: (1)
			Replicas: (1) NATURAL
			Port: (+) NATURAL
			Maintainer: (1) EMAIL
			Notes: (?) TEXT

Service (com.example.deploy):
	Name: billing
	Replicas: 2
	Port: 8080
	Port: 8443
	Maintainer: [email protected]
	Notes >>
		The TLS certificate expires on 2027-03-01.

Un campo mal escrito, un puerto ausente o Replicas: two fallan con un código de error explícito en lugar de llegar a producción como una cadena:

# ERROR: Replicas exige un valor NATURAL
Service (com.example.deploy):
	Name: billing
	Replicas: two
	Port: 8080
	Maintainer: [email protected]

¿Y NestedText?

NestedText parte del mismo diagnóstico sobre YAML y toma varias de las mismas decisiones que STXT: todo valor es texto, sin tipado implícito, sin escapes, y la estructura en la indentación. La diferencia está en el modelo: NestedText conserva el modelo de datos de YAML — diccionarios, listas y cadenas, sin nombre ni vocabulario — y deja los tipos y la comprobación por entero a la aplicación. STXT modela documentos con nombre: nodos, namespaces que conectan cada documento con su definición, y la capa de esquemas y plantillas dentro del lenguaje. Como sustituto de YAML para transportar datos, NestedText llega a una sintaxis igual de predecible; STXT añade el vocabulario y la validación.

Cuándo usar cada uno

Usa YAML donde el ecosistema ya lo habla: manifiestos de Kubernetes, pipelines de CI, configuración de herramientas que leen sobre todo máquinas y plantillan otras máquinas.

STXT encaja mejor cuando los ficheros los escriben y leen personas: configuración con notas largas en prosa, documentos corporativos, contenido de un CMS, y cualquier documento que merezca validarse contra una estructura acordada. El caso de uso de ficheros de configuración desarrolla en detalle el escenario más cercano.

Para ver el lenguaje en sí, empieza por el tutorial o pega los ejemplos de arriba en el playground; la versión corta de esta comparación, junto a XML y TOML, está en la FAQ.