15. Conformance
Contents of FBL 0.6
| Class | Requirements |
|---|---|
| FBL document | Validates against $defs/Document and passes the checks of section 14.1 without errors. |
| Validator | Implements section 14.1 and reports problems with JSON Pointers; checks registrations against $defs/Registration and fixtures against $defs/Fixture and section 15.3. |
| Host — declared | Implements the lossless readings of the families it supports (section 4), rules (section 5), the splice catalogue and new-text rules (section 6), history and drift (section 7), the registration (section 8), several readings (section 9), routing and templates (sections 12, 13), and passes every fixture of the families it supports. It states which families it supports. |
| Host — full | Host — declared for all five families, plus folder subjects (section 10) and the plugin contract (section 11). |
| Persistence plugin | Meets section 11.4 for its format. |
A host that does not support a binding's family or plugin MUST open its documents read-only, if it can read them at all, and say why; this is DISL's rule for a missing required plugin (DISL §13.1).
A host that cannot watch files reads bodies on open and on request only, and says so. A host that cannot keep the registration (a read-only workspace) keeps positions for the session only, and says so. Nothing else in this document degrades: byte preservation, exact undo and drift refusal are required of every host.
fixtures/<name>/fixture.json, validated by $defs/Fixture, is a conformance test for hosts:
| Property | Description |
|---|---|
binding |
The binding under test, relative to the fixture. |
input |
The input body, a file beside the fixture, compared byte for byte (the repository keeps these files from line-ending conversion). |
read |
What reading the input yields: elements (id, type, and (FBL 0.5) optionally attributes, the values read for the attributes it names, a JSON string for a text and a JSON number, bool or null otherwise), findings (rule, line), unreadable. |
steps |
In order: an edit (add, set, remove, (FBL 0.3) move, place, or save without change; an add or a move carries a position as section 11.2 gives it, and (FBL 0.5) an add the slot it fills, as section 11.2's add does, which a host needs when one type fills several slots of one parent), an undo or a redo; the splices it must produce, as {operation, start, end, text} with UTF-8 byte offsets into the document before the step; the document after it (expect, or expectFile); refused with the reason when the edit must be refused and write nothing. |
A host passes a fixture when reading the input gives what read lists (for an element with attributes, each attribute named there has that value and that JSON type; attributes not named are not compared) and every step produces exactly its splices and its document. For a refused step it passes when it refuses the edit and writes nothing: the text of refused is informative, because FBL leaves a refusal's wording to the host except where a binding gives the reason itself (readOnly, section 3.4), and then it is that reason. The repository's validator checks every fixture's consistency: each step's splices turn the document before it into its expect, and back by their inverses; an undo returns the document the undone edit started from; a save and a refused edit change nothing. Undo steps list the inverse splices under the operation of the splice each inverts.
Together the fixtures exercise every operation of section 6.1.