CMS and publishing

A website, a blog, a product's documentation, a book in chapters: everything that is written to be published. STXT is the source format of that content: the text lives in files, the structure is visible, validation is a template and presentation is decided afterwards.

Published content always has three layers: the text someone writes, the structure that organizes it —pages, sections, chapters— and the data that accompanies it —title, author, date, editorial status, tags—. The tools that manage it tend to fuse those layers with the editing interface and with the final presentation, and the result is well known: the content ends up inside a database, in a shape only that tool understands, and changing tools is a migration.

With STXT as the source format, each page is a text file with its data as nodes and its body in blocks. The content manager —a static site generator, a headless CMS or a typesetting process— reads the tree and decides what to do with it. This very portal is built that way: each page of stxt.dev is an STXT document of the dev.stxt.website namespace, and the generator turns it into HTML. The FAQ shows two ways to verify it from the browser.

A page

Page (com.acme.cms.page):
	Title: About STXT
	Slug: about-stxt
	Language: en
	Status: Published
	Layout: default

	SEO:
		Title: STXT — A Human-First language
		Description: A readable, validatable text language
		Keywords:
			Keyword: stxt
			Keyword: documents
			Keyword: formats

	Header >>
		## STXT

		A structured text language, readable by people
		and reliable for machines.

	Content >>
		### What is STXT?

		STXT is a language designed for writing documents
		that can be read and processed without friction.

		### Principles

		- Human First
		- Minimal syntax
		- Optional validation

	Footer >>
		Last updated: January 2026

The editorial metadata —slug, language, status, layout, SEO— are nodes the manager reads directly. The body goes in blocks of type MARKDOWN (STXT-SCHEMA-SPEC §9.7): STXT does not interpret that Markdown, it only hands it over as is to the renderer; the type is a contract for whoever consumes it (and for the editor and the playground, which highlight it as Markdown). The footer is TEXT: it is shown literally. How the two languages divide the work is developed in STXT vs Markdown.

The template

Template (@stxt.template): com.acme.cms.page
	Description >>
		Page: A page of a website
		Status: Editorial status; only Published is published
	Structure >>
		Page:
			Title: (1)
			Slug: (1)
			Language: (?) ENUM [es, en, fr]
			Status: (1) ENUM [Draft, Published, Archived]
			Layout: (?)
			SEO: (?)
				Title: (?) @Title
				Description: (?)
				Keywords: (?)
					Keyword: (+)
			Header: (?) MARKDOWN
			Content: (?) MARKDOWN
			Footer: (?) TEXT

The template guarantees what the generator needs to work —title, slug and a status from the list— and leaves the rest optional. A page without Slug does not validate, and therefore is not generated; neither does a lowercase Status: published. That is the difference between an error that shows up in the editor and a page that disappears from the site without anyone knowing why.

SEO/Title reuses the definition of Title with @Title: it is the same node, with the same definition, in another place of the tree.

An article with authors and status

A blog or a magazine adds authorship, a date and an editorial workflow:

Article (com.acme.editorial.article):
	Title: Introduction to STXT
	Slug: introduction-to-stxt
	Authors:
		Author: Joan Costa
			Role: Editor
	Published date: 2026-01-10
	Status: Draft
	Tags:
		Tag: stxt
		Tag: formats

	Abstract >>
		STXT is a text language designed to balance
		human readability and machine reliability.

	Content >>
		## Why another format

		Most existing formats force a choice:
		either they are convenient for people or reliable for machines.

		STXT removes that dichotomy.
Template (@stxt.template): com.acme.editorial.article
	Description >>
		Article: Article of a blog or a periodical
	Structure >>
		Article:
			Title: (1)
			Slug: (1)
			Authors: (1)
				Author: (+)
					Role: (?)
			Published date: (?) DATE
			Status: (1) ENUM [Draft, Review, Published]
			Tags: (?)
				Tag: (+)
			Abstract: (?) TEXT
			Content: (1) MARKDOWN

The editorial workflow is the ENUM of Status: an article goes from Draft to Review and to Published, and that change is one line in the review's diff. The generator publishes only what is in Published and has a date; the rest exists in the repository, but not on the site.

A book in chapters

A long publication follows the same pattern, with the structure in plain sight and each chapter as a node that groups its data and its text:

Publication (com.acme.editorial.publication):
	Title: STXT — The book
	ISBN: 978-1-23456-789-0
	Language: en
	Status: In Progress

	Chapter: Introduction
		Number: 1
		Content >>
			This chapter introduces the basic concepts of STXT.
	Chapter: Syntax
		Number: 2
		Content >>
			The syntax of the language is described with examples.
	Chapter: Validation
		Number: 3
		Content >>
			Templates and schemas add semantic rules.
Template (@stxt.template): com.acme.editorial.publication
	Description >>
		Publication: Book or long document divided into chapters
	Structure >>
		Publication:
			Title: (1)
			ISBN: (?)
			Language: (1) ENUM [es, en, fr]
			Status: (1) ENUM [In Progress, Published]
			Chapter: (+)
				Number: (1) NATURAL
				Content: (1) MARKDOWN

Chapters are written in order and the tree preserves it, so the generator needs to sort nothing; Number exists so the number appears in the output and so a chapter can be referred to from outside. A forty-chapter book can be split into forty files with the same namespace, and the template still holds for each one.

The publishing flow

Each step is independent and replaceable:

  1. The document is written with any editor; with the VS Code extension, the template provides completion and immediate errors.
  2. It is versioned in a repository; editorial review is a diff.
  3. It is validated —in the editor, on the command line or in continuous integration— with stxt validate (The command line), which rejects a page without a slug or an article without an author before it reaches the generator.
  4. The generator reads the canonical tree and produces HTML, PDF, EPUB, a feed or an API; the same document goes out through several channels.

The document contains no HTML, CSS or layout: presentation is decided in step 4 and can be changed entirely without touching the content.

Limits

STXT is not a CMS: it has no editing interface, no users, no approval workflow, no preview. It is the format in which that CMS stores the content, and what it guarantees is that the content outlives the CMS. Nor does it define how a MARKDOWN block is rendered or which Markdown dialect is accepted: the renderer fixes that, and the template only declares that the block must be treated as such.

The generated variant of this flow —pages written by a model and rejected by the build until they validate— is developed in AI and LLMs; the tutorial covers the language behind the examples.