9. Several readings of one body
Contents of FBL 0.8
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 model, its findings and its history. Every reading of the body is a view of that open body: an edit made in any of them is planned and applied once, recorded in the one history, and shown in every other open reading without a reload. Undo in any reading undoes the most recent edit of the body, whichever reading made it.
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. 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 (section 4.7), matched ignoring case; without it, the first view in document order of the kinds the reading's tool type shows. The view's content (which elements a view includes) is the reading's DISL viewpoint's, not FBL's.
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.