9. Several readings of one body
Contents of FBL 0.14
A reading is one tool type's view of a body. A host keeps one open body per pair of canonical body path (absolute, with the platform's case rules) and binding: its bytes, its lossless reading, its findings, its history, and (FBL 0.10) one model for each origin it is read for, which the binding's rules give for that origin (section 5.1). Every reading of the body is a view of that open body: an edit made in any of them is planned once against the body's bytes, applied once, recorded in the one history, and shown in every other open reading, of its own origin and of every other, without a reload. Undo in any reading undoes the most recent edit of the body, whichever reading made it, and redo likewise. (FBL 0.10) A registration's resource selection (section 8.2) is a view of its origin's model, so two registrations of one origin that select different resources show and edit their own while sharing the body's history.
Every reading of a body MUST use the same binding: the six C4 types name structurizr.fbl#workspace, the four W3C types w3c-turtle.fbl#turtle. A tool type whose specification names a different binding for a body that is already open MUST be opened read-only, with a reason, until the other readings close. (FBL 0.10) Readings of different origins through one binding are all editable: the bundle, job and pipeline readings of a Databricks bundle file, through databricks.fbl#configuration, each change the one open body. A validator SHOULD warn when two specifications claim the same extension with different bindings and no marker tells them apart.
Each reading keeps its own view data in its own registration (one .adp per reading), so positions of a container view and of a context view of the same workspace never mix, and none is written into the body. The registration's view header selects which view of the body the reading shows, for bindings whose blocks define views (sections 4.7 and, (FBL 0.11), 4.9), matched ignoring the case of ASCII letters; without it, the first view in document order of the block rules whose origins include the reading's origin, or of every view block when none has origins. Which elements a view draws is the reading's DISL viewpoint's, not FBL's. What FBL reads of the selected view is what the rules with selectedView read inside it (section 4.9). (FBL 0.11) A registration whose view names no view of the body opens a reading that shows no view's content; no finding is reported for it; a change of view data (a placement) is refused with the reason "This view is not in the document, so its positions cannot be stored." and nothing is written. A view header over a binding that defines no views is kept, and the reading shows the body, as before.
When a host is asked which readings it offers for a body, it lists every installed tool type whose binding claims the body (section 12), and, for a binding with claims.readings, each reading in the order of claims.origins, those whose suggest matches first.