1. Introduction
Contents of ATD 0.1
(informative)
ATD is the one language in which a tool type of any kind is described completely: its identity, its model, its surface (a canvas for a diagram, a form-based surface for a designer, text for an editor), its behaviour, the bindings to the files it reads and writes, and the logic that hosts write per tool type today, in a small script that is part of the language. A tool type is described in one .atd file, or in a root file with the parts it imports: a tool description.
A smallest whole description of each kind is what atd new writes; section 19 prints three of the examples, and the guide for tool engineers writes a tool type of each kind step by step.
Today a tool engineer specifies a tool type in up to three JSON files, each in a language of its own: a specification in DISL or DESL, a binding in FBL, and a companion .md that lists in prose what neither language can say, which each host then writes as code. ATD states each concept once, in a core shared by every kind (section 7); puts the logic beside the declarations it serves (section 12); names what is too heavy or numeric for a script as a capability with a contract (section 13); and is defined by one grammar that is LALR(1), so that it can be checked as one unit, given one set of editing tools, and written by people and agents under a grammar that admits only valid text.
- End state. The
.atdtext alone is normative for every tool type; the JSON forms of DISL, DESL, EDSL and FBL are retired as authored forms, and every host runs tools from.atd. - Phase 1, this version. ATD is specified; the tool types in scope (29 diagram, 2 designer and 5 editor types) are described in
.atdunderdefinitions/, each with a trace (section 2.5) and conformance fixtures (section 2.3), but for the Knowledge designer, whose description spec 076 writes; the toolchain to write, check, edit, validate and debug descriptions exists, and validation has a runtime for diagrams only so far. The.dis,.desand.fblfiles stay the ones every host runs, unchanged. A host that finds a tool type both as.atdand as JSON files runs it from the JSON files and ignores the.atdwhen it loads tools. - Later phases. Conversion of the JSON files, hosts running tools from
.atd, and the retirement of the JSON languages as authored forms are features of their own.
DISL, DID, DESL, DED, EDSL, EDD and FBL remain specifications of this repository. ATD carries every construct of DISL 0.8, DESL 0.2 and FBL 0.16 (Appendix C maps each of their properties to the ATD construct that carries it), and the constructs an editor needs, which EDSL, a placeholder, does not yet have (section 10). ATD reuses their schemas: a setting of an ATD construct is checked against the $defs entry of DISL, DESL or FBL for the same thing (section 14.6), and a binding in ATD is an FBL binding written as text. Tools keep storing their documents in DID, DED or a body a binding reads; a tool description replaces none of them.
A tool engineer new to the language starts with the guide, and comes here for what a construct means. Section 5 gives the shape of a file, section 7 the constructs every kind shares, and sections 8, 9 and 10 the surface of a diagram, a designer and an editor; section 11 gives bindings, section 12 the script and section 13 capabilities. Section 14 says what a checker refuses, section 15 lists its findings, and Appendix B is the keywords. Whoever implements a checker, a language server or a runtime reads sections 2 to 4 and 14 to 16 as well: section 2 says what conformance is, and sections 3 and 4 how to read the grammar without Lark. Appendix C maps each property of DISL, DESL and FBL to its construct here.