Principios de diseño
STXT es un lenguaje pensado para las personas (Human-First). Todo lo demás —la sencillez, la indentación como estructura, la ausencia de escapes, la seguridad del parseo, la validación como capa aparte— se deriva de ese principio.
1. El documento se escribe para personas
Este es el principio del que salen los demás. Un documento STXT debe poder leerse y escribirse sin herramientas: la forma natural del texto es la forma correcta, y la máquina se adapta a esa forma, no al revés. De ahí que no haya llaves, corchetes, comillas obligatorias ni etiquetas de cierre, y que un documento parezca un esquema de notas. Donde la comodidad de la persona y la de la máquina entran en conflicto, gana la persona.
2. La sencillez por encima de todo
La sencillez es un requisito del lenguaje en tres planos a la vez, y ninguno se sacrifica por los otros dos:
- Sencillo de escribir y leer. Las reglas que una persona necesita conocer caben en una página del tutorial: un nodo, un bloque de texto, la indentación, un comentario.
- Sencillo de implementar. Un parser conforme es un recorrido línea a línea con una pila; la gramática completa cabe en un apéndice y el lenguaje se describe en pseudocódigo neutro del que se han derivado los puertos existentes. Escribir un parser nuevo es un trabajo de días, no de meses, y no requiere ninguna biblioteca.
- Sencillo de procesar. El coste de parsear es lineal en el tamaño del documento: una sola pasada, sin retroceso, sin resolver referencias y sin segundo recorrido.
3. Menos es más
STXT es deliberadamente pequeño, en todos sus niveles. La jerarquía se expresa
únicamente con la indentación: un nivel es un tabulador o cuatro espacios. Un nodo es
Nombre: valor o Nombre >>. No hay sintaxis de lista, ni de cadena entre comillas,
ni de escape, ni notación abreviada para el caso frecuente. Una lista es un nodo
repetido:
4. No hay caracteres de escape
Un carácter de escape es lo menos Human-First que existe: obliga a quien escribe a
pensar en el parser en lugar de en el texto, y a quien lee a descifrar lo que hay
detrás de una barra. Por eso STXT no tiene secuencias de escape: un valor es lo que
hay tras los dos puntos, un bloque es lo que hay indentado debajo del >>, y
cualquier carácter vale dentro de ambos, incluidos :, # y >>.
El texto libre es, así, literal: todo lo indentado bajo un nodo >> es texto tal
cual, y la indentación relativa se conserva. Un párrafo, un fragmento de código o un
bloque de Markdown se pegan en el documento sin transformarlos, y se leen y se editan
de forma directa, sin que ninguna convención del lenguaje se interponga entre la
persona y lo que escribe.
5. La seguridad del parseo, por diseño
STXT no tiene entidades, referencias, anclas, inclusión de ficheros, etiquetas que instancien objetos ni ninguna forma de evaluación. Los namespaces se restringen a ASCII para excluir los ataques homográficos. El resultado de parsear es siempre un árbol de nodos y texto, y un parser conforme puede procesar un documento de una fuente no confiable con memoria acotada.
6. La validación es una capa aparte y opcional
El parser no necesita esquemas. Un documento sin namespace, o con un namespace para el que no hay definición, es un documento válido que no se puede validar. Cuando hay esquema, el modelo de contenido es cerrado: un nodo no declarado es un error, no un dato extra que se ignora. El orden de los hijos se conserva en el árbol pero no se valida.
El mismo criterio ordena el resto de especificaciones: la especificación base define por sí sola un lenguaje completo y usable, y cada una de las demás describe una característica opcional que debe ser, a su vez, sencilla. Por eso los esquemas y las plantillas no cubren todos los casos posibles: es preferible un sistema de validación sencillo a uno tan completo que apenas nadie use.