STXT vs XML

Of all the formats in this series, XML shares the most ground with STXT. Both model a document as a tree of named nodes; both group vocabularies with namespaces; both validate against a declared structure. XML proved that those ideas work at industrial scale. STXT pursues the same ambitions with a different constraint: that the document can be written and read by hand with no closing tags and no escaping.

The same content, twice

An article header in 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>

And in 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>.

Same tree, same namespace idea, and two costs gone: nothing is closed — the indentation already says where Article ends — and nothing is escaped, because &, < and > have no meaning in an STXT value or text block.

Escaping and entities

XML reserves < and & everywhere, so text must be escaped or wrapped in CDATA, and correctness depends on doing it every time. Entities also open the classic attack surface: external entities (XXE) that read files or reach the network, and entity expansion that exhausts memory. Hardened parsers disable those features; STXT never had them. There are no entities, no references and no inclusion, and any character is legal in a value or a block — the security model is normative in STXT-SPEC §15.

Attributes and elements

Every XML vocabulary re-decides what goes in attributes and what in child elements, and consumers must handle both. STXT has one construct: a node with a value and children, or a node with literal text. Author above carries its value and an Email child; there is no second axis to design or to parse. What XML gains from attributes — compact inline metadata — STXT deliberately trades for uniformity, as Design principles argues.

Validation

XML has three schema languages — DTD, XSD and RELAX NG — each an ecosystem of its own; XSD in particular is a two-part specification with a type system of its own. The STXT schema layer is one page of concepts — nodes, types, cardinalities, a closed content model — written in STXT itself, in a template form that mirrors the document:

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

It validates less than XSD — no regular expressions over content, no conditional rules, no order constraints — and each of those absences is a stated non-goal of the spec, which documents what is left out and why: keeping the model small and predictable, with errors a person can act on (STXT-SCHEMA-SPEC §11).

When to use which

Use XML where its ecosystem is the value: established standards (DocBook, SVG, ODF, RSS), toolchains built on XSLT and XPath, and vocabularies that need mixed content — inline markup woven through prose — which STXT deliberately does not model.

STXT fits the documents people author and organizations validate: corporate documents, contracts, RFCs and technical proposals, CMS content. The tutorial shows the whole language in one sitting, the playground runs the examples above, and the short version of this comparison is in the FAQ.