DED — Designer Definition Language
Contents of DED 0.2
Specification, version 0.2 (Draft)
| Date | 2026-10-14 |
| Kind | designer |
| Role | definition language |
| File extension | .ded (the JSON form; a designer type's bindings may claim other extensions, .md among them) |
| Paired language | DESL, the Designer Specification Language (.des) |
| Definition schema | ded.schema.json (JSON Schema, draft 2020-12), $defs/Definition, $id https://etalii.net/adp/ded/schema/0.1/ded.schema.json (the address 0.1 gave it) |
| Version key | "ded": "0.2" |
| Builds on | FBL 0.3 for storage |
| Licence | Apache License 2.0 (Apache-2.0) |
This is a draft, version 0.2. It holds what the designer types defined so far need of a stored document and nothing more (constitution principle V): the envelope every definition starts with, how a host recognises and reads one, and how a new one is written. DED 0.1 (2026-10-09, for the Knowledge designer, spec 013) states the envelope in YAML, JSON and XML. DED 0.2 (2026-10-14, for the Hierarchical Requirement Designer, spec 028) states it in Markdown (section 2), names .md among the shared extensions a binding claims with the envelope as its marker (section 4), and changes nothing else: every valid 0.1 definition is a valid 0.2 definition with the same meaning, and it MAY go on saying 0.1. Any construct may change before 1.0 (constitution principle IV). Sections and paragraphs marked (informative) explain intent; everything else is normative.
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in bold capitals.