Skip to content
Source on GitHubVisitors

4. Reading a definition

Contents of DED 0.1

A host reads a DED definition in these steps.

  1. Recognise. A file is a DED definition of a designer type when its envelope names that type's origin. Each binding a designer type names for a shared extension (.yaml, .json, .xml) MUST use the envelope as its marker (FBL section 12.2): {rootKey: "designer", value: "<origin>"} for YAML and JSON, and a pattern matching the root element's start tag with that designer for XML. A registration (FBL section 8) MAY still name the designer type for a file that lacks the envelope; the binding's header then decides (FBL section 5.6): a header that is not required reads the file and reports the difference, a required one, as the Knowledge designer's are, makes the file unreadable.
  2. Check the version. A ded of 0.1 is read as this document says. A host MUST open a definition with a later version of DED read-only, with the reason, unless it implements that version.
  3. Find the designer type. A host MUST open a definition whose designer names no designer type it has installed read-only, if at all, with the reason naming the origin. It MUST NOT read such a definition through another designer type's bindings.
  4. Read the content through the bindings of the designer type's DESL specification (DESL section 10.1), which check the envelope as their header and report what they find.

When a registration and the envelope name different designer types, the envelope decides and the host reports the difference as a finding.

Referenced from