Specification
The TSON specification, split into two parts, plus room for companion specifications developed alongside it.
These documents describe the specification text. Implementations of TSON (parsers, encoders, libraries) may be licensed however you choose; the specification's license applies to the written text, not to code that implements it.
Spot an error, or have a comment on the specification? Open an issue on GitHub.
TSON Specification
- TSON Part 1: Text Data Format
The notation and reference encoding of the TSON schema system: the lexer, structural grammar, absent sentinel, augmentation syntax (annotations, type annotations, directives), and base type resolution — everything needed to losslessly read and write schemaless TSON data.
- TSON Part 2: Type System and Schema
The centre of the TSON series: the schema grammar, the type system and its operations, the schema chain and its resolution model, schema compilation and resolver output, the text encoding rules, and the operations of the schema, meta, and import directives.
Companion Specifications
- TSON Developer Guide
Design history, rationale, extended examples, and implementation guidance for the TSON specification series. Nothing in this guide is normative; where it appears to disagree with [TSON-DATA] or [TSON-SCHEMA], the specifications govern.
Schema Source Files
The normative TSON schema source files in .tn format.
Resolved Fixtures
Non-normative resolver output for the schema source files above. Parse the source, run the resolver, canonicalise, and compare against these fixtures.
Reports
Non-normative working documents prepared against this revision as input to the next development cycle: gap analyses mapping other schema systems onto TSON, and feedback gathered from building the first implementation. They record findings and design directions under consideration, not committed specification.
- Schema Language Mappings: Synthesis
Consolidates the five mapping reports into cross-cutting findings, a prioritised worklist for Part 2, and a shared converter architecture. Its headline result is that every construct in all five languages landed on existing machinery, a planned addition, or a principled decline — leaving the meta-kernel untouched.
- JSON Schema and OpenAPI → TSON
Maps JSON Schema 2020-12 and OpenAPI one-directionally and strictness-first, so that format annotations become validated core types while the constraint-algebra keywords (not, if/then/else, unevaluated*) stay excluded by design. Introduces the discriminator token and the rest field that let records stay closed.
- Protocol Buffers → TSON
Maps the protobuf IDL with protojson documents as the validation target. All three protobuf presence disciplines land on existing TSON field states with matching injection semantics, and field numbers and wire-encoding variants are preserved as annotations rather than type semantics.
- ASN.1 (X.680–X.683) → TSON
Maps ASN.1’s abstract syntax — the most architecturally TSON-like language examined, having separated abstract syntax from transfer syntax since 1984. Subtype constraints become refinements almost term-for-term; extensibility markers are the systematic tension against TSON’s closure.
- Apache Avro → TSON
Maps Avro, the one source language designed around schema evolution as its primary use case, which forces the writer/reader resolution question every other report deferred. Avro’s union JSON encoding turns out to be TSON’s labelled sum materialised on the wire.
- GraphQL SDL → TSON
Maps GraphQL SDL, which is a capability schema rather than a data schema: a response’s shape comes from the query, not from the type alone. Covers the input universe, the output type graph, and the per-query derivation that would make response contract validation possible.
- Implementation Feedback
Issues, ambiguities, and inconsistencies found in the specification while building the first implementation, each recorded with the reading that implementation chose and a suggested resolution. The most direct feedback loop the draft currently has.