FBL — Format Binding Language
Contents of FBL 0.8
Specification, version 0.8 (Draft)
| Date | 2026-10-22 |
| Document schema | fbl.schema.json (JSON Schema, draft 2020-12), $defs/Document |
| Also in the schema | $defs/Registration (the parsed .adp registration), $defs/Fixture (round-trip fixtures) |
| Serves | every kind of tool: DISL through persistence.binding, DESL through persistence.bindings |
| Expression language | CEL — Common Expression Language (https://cel.dev) |
| Media type (provisional) | application/vnd.fbl.document+json |
| File extension | .fbl |
| Licence | Apache License 2.0 (Apache-2.0) |
This is a draft, version 0.8. It is complete enough to implement a conforming validator of FBL documents and a host that reads and writes bodies through declared bindings, but individual constructs may still change before version 1.0. FBL 0.2 (2026-10-05, approved by the product owner as part of the DISL 0.3 additions) gives the model changes a persistence plugin plans their fields: an add with a position, a move and a retype (section 11.2), which declared bindings follow too (section 6.4); and it lets a DISL specification map a binding's own type and attribute names onto its metamodel (DISL §11.2, persistence.typeMap; section 5.1). Every valid 0.1 document is a valid 0.2 document with the same meaning, except that a plugin that does not declare move is sent a reorder or re-parent as a remove and an add. FBL 0.3 (2026-10-09, for the Knowledge designer, spec 013) changes no behaviour: it names the tool type's specification wherever 0.2 said DISL, since a DESL specification uses bindings too (DESL section 5), and pairs each construct it relies on with its DISL and its DESL section (section 1.3); it lets a specification name one binding per format family, the body choosing among them by the files each claims (sections 1.2, 8.1); it spells a reference to a stored id as by: "id" (sections 5.2, 5.7); it lets a fixture's edit be a move or an add with a position, as section 11.2 already defines them (section 15.3); and it says how a container written on one line is created and removed around its entry (section 6.2). Every valid 0.2 document is a valid 0.3 document with the same meaning. FBL 0.4 (2026-10-09, for the Agent activity diagram, spec 014, by the ruling of 2026-10-09) lets a binding keep its entries and values in a nested mapping that the body may not have yet: an insert whose container is placed at: "end" creates every missing level of its selector (section 6.2), an attribute reached through child is written into a mapping it creates the same way in yaml and json (section 5.2), and remove-empty-levels removes the levels an entry's removal leaves empty (section 6.2). Every valid 0.3 document is a valid 0.4 document with the same meaning. FBL 0.5 (2026-10-10, spec 015, for the tools whose YAML files people write by hand) says what a slot reads from a scalar: it defines a scalar's written text (section 4.1.5), lets an attribute binding read it with read and makes it what a text attribute, an id and a reference read (sections 5.2, 5.3), presents it to CEL as text and style beside entry (section 2.4), lets a binding keep an entry readable when one value does not convert, with fallback, and read a quoted number, with quoted (sections 5.2, 7.4), and lets a fixture state the attribute values a reading yields and an add name the slot it fills (section 15.3). Every valid 0.4 document is a valid 0.5 document; section 5.2 lists the two places where 0.5 gives a meaning that 0.4 left open. FBL 0.6 (2026-10-12, spec 026, by the maintainer's ruling of 2026-10-12 on row B-09 of spec 025's behaviour-change register) makes an attribute binding's empty rule decide a new entry's key as it decides a set (sections 5.2, 6.2): 0.5 said that a key a new entry has no value for is left out, and left open whether an empty value counts as no value on an insert; 0.6 says it does not, so an attribute an add gives its empty value is written with keep, left out with remove and refuses the add with refuse (section 6.4), with a set's defaults, while an attribute the add does not give is still left out. Every valid 0.5 document is a valid 0.6 document. FBL 0.7 (2026-10-14, spec 028, for the Hierarchical Requirement Designer) adds a sixth family, bullets, which reads the list items under named headings of a Markdown file as a tree (section 4.8): a binding's sections name the headings, a rule's within the sections its items stand in, the slot {continuation: true} reads the lines indented under an item (section 5.2), and a move to another depth re-indents the entry it moves (sections 5.5, 6.3), and an insert's emit can write a literal bracket, as a Markdown task list needs (section 6.2), a fixture's read may state the parent of an element (section 15.3), an insert may place a line right after the header, and a case-insensitive rule's map ignores case (sections 5.2, 6.2). It lets a binding declare further blocks of the registration, registration.blocks, in the grammar layout: and identities: already have, each with the order its entries keep, whether they are keyed by ids and whether its writes are steps of the history (sections 8.1, 8.4), so a tool type can keep beside the body what the body's readers do not need. A word slot of a many attribute holds every word of its group that matches, which lets a line carry a list of tags (sections 4.6, 6.3). It also makes a host compare the body with the bytes an edit was planned against before applying it, as 0.6 required before an undo or a redo (section 7.2). Every valid 0.6 document is a valid 0.7 document with the same meaning. FBL 0.8 (2026-10-22, spec 033, for the functional decomposition graph, by the maintainer's ruling of 2026-10-22) lets an insert of the yaml and json families write a constant: a key and a scalar value every new entry of the rule is written with, that no attribute supplies, such as the value of the key whose value chose the rule (section 6.2). A constant only writes: when alone decides which rule an entry is read by, no edit but the add writes it, and a binding whose rule also writes the constant's key is refused when it is loaded (section 14.1). Every valid 0.7 document is a valid 0.8 document with the same meaning. Sections and paragraphs marked (informative) explain intent and give guidance; everything else is normative.
FBL relies on constructs that the specification language of the tool type's kind defines: id strategies and ephemeral ids, findings and their source locations, derived elements, the editing transaction and the tool type's origin. Where this document names one of them, the specification language is the definition; FBL defines none of its own. Where this document says the tool type's specification, it means the DISL specification of a diagram or the DESL specification of a designer whose persistence names the binding. Section 1.3 lists, for each construct, the section of DISL and of DESL that defines it; a citation of DISL in this document is read, for a designer, as a citation of the DESL section that table pairs it with.
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.