Cmacc-compliant rendering for blockchain and other databases:

1. Example of a JSON-formatted query
   Example of a query done as a JSON snippet.
2. Queries
   
   1. A CommonAccord "document" is a report from a database (conventional, blockchain, file system, graph), where the "query" is special. The query asks for a rendering engine to be applied. The rendering engine is parameterized with a number of different possibilities. These are some useful parameterizations of the rendering engine:
      1. "xray" view with each value wrapped with metadata relating to its source file and key name. Enough info to permit interface to allow pop-up editing.
      2. "doc" view with each Value wrapped in its key, but not the file name. Like the current Doc view. Does not reveal the file structure of the generating party.
      3. "print" view without wrapping.
      4. "used" list of key/values actually used in rendering the document, so can provide to another party in "source" form without disclosing the internal organization.
      5. "missing" list of keys not found.
   2. All the other "views" currently in the CommonAccord app are common database queries, where an interface has been applied to the return. For example:
      1. "edit" view of the raw text in editable mode
      2. "raw" mode the text, no editing
      3. "map"(?) (currently called Source) view of the text of the Record with nice presentation, and file names linked for navigation.
      4. "find" a (partial) listing of keys and values available. Could be part of graph navigation via "map."
3. Render (parameter)
   
   1. Rendering is Expansion of a Value
      
      1. A "Document" is the result of rendering a "Record".
      2. Rendering is done by expanding the Value of a specified Key - by default it is currently "r00t" - with recursive expansion of {plugs} in the Value.
      3. Plugs are expanded by literal matching with the Plug name with the first matching Key name in the namespace of the Record.
   2. The Key namespace of a Record
      The Key namespace of a Record1 is:
      1. the Keys in Record1,
      2. for each RecordN referenced as a Value in Record1 - the Keys in RecordN:
         1. If a RecordN is referenced by an empty Key, the Keys and Values are included as is.
         2. If a RecordN is referenced by a Key which has a name, that name is "prefixed" to each of the Keys and the Plugs in RecordN.
            1. E.g., a reference Foo.=[Record2] means that a Key/Value in Record2 of "sec=My {Name}." would be evaluated as Foo.sec=My {Foo.Name}.
            2. If a Key called "Foo.Name" is not found, the prefix is removed and "Name" is tried. This deprefixing is both (i) essential in many uses, and (ii) a consequence of the object model.
      3. recursively, depth-first.
   3. Ordered versus Unordered List
      Currently, the order of Keys in a Record is significant.
      1. A Record may contain more than one Key with the same name - the top one has priority.
      2. It is common to reference a number of RecordNs via the same Key, notably with an empty Key.
      3. Multiple Key/Values is otherwise of minor use.
      It would be possible to develop a naming convention for Keys that indicated order. For instance (1)=[High_Priority.md], (2)=[Next_Priority.md]