Design principles

1. The document is written for people

This is the principle the others follow from. An STXT document must be readable and writable without tools: the natural form of the text is the correct form, and the machine adapts to that form, not the other way round. Hence there are no braces, brackets, mandatory quotes or closing tags, and a document looks like an outline of notes. Where the convenience of the person and that of the machine conflict, the person wins.

2. Simplicity above all

Simplicity is a requirement of the language on three planes at once, and none of them is sacrificed for the other two:

• Simple to write and read. The rules a person needs to know fit in one page of the tutorial: a node, a text block, indentation, a comment.
• Simple to implement. A conforming parser is a line-by-line pass with a stack; the complete grammar fits in an appendix, and the language is described in neutral pseudocode from which the existing ports were derived. Writing a new parser is a matter of days, not months, and requires no library.
• Simple to process. The cost of parsing is linear in the size of the document: a single pass, no backtracking, no reference resolution and no second traversal.

3. Less is more

STXT is deliberately small, at every level. Hierarchy is expressed by indentation alone: one level is one tab or four spaces. A node is Name: value or Name >>. There is no list syntax, no quoted string syntax, no escaping, and no shorthand for the frequent case. A list is a repeated node:

Authors:
	Author: María Pérez
	Author: Juan García

4. There are no escape characters

An escape character is the least Human-First thing there is: it forces the writer to think about the parser instead of the text, and the reader to decipher what lies behind a backslash. That is why STXT has no escape sequences: a value is whatever follows the colon, a block is whatever is indented below the >>, and any character is allowed inside both, including :, # and >>.

Free text is thus literal: everything indented under a >> node is text as written, and relative indentation is preserved. A paragraph, a code fragment or a block of Markdown is pasted into the document without transformation, and is read and edited directly, with no convention of the language standing between the person and what they write.

5. Parsing safety, by design

STXT has no entities, references, anchors, file inclusion, tags that instantiate objects, or any form of evaluation. Namespaces are restricted to ASCII to rule out homograph attacks. The result of parsing is always a tree of nodes and text, and a conforming parser can process a document from an untrusted source with bounded memory.

6. Validation is a separate, optional layer

The parser needs no schemas. A document without a namespace, or with a namespace for which there is no definition, is a valid document that cannot be validated. When there is a schema, the content model is closed: an undeclared node is an error, not extra data to be ignored. The order of children is preserved in the tree but not validated.

The same criterion governs the other specifications: the base specification alone defines a complete, usable language, and each of the others describes an optional feature that must itself be simple. That is why schemas and templates do not cover every possible case: a simple validation system is preferable to one so complete that hardly anyone uses it.