/Docs/OTF/ProseObject-Stack/Cmacc_0.md
Document views: Document Xray Visual Cicero Print   Source views: Source OpenParameters JSON(ish)   On GitHub: File ~PageRank   (rare: 'ShowMe' 1)
___
Model.Root{Ti}
{Intro.sec}
  1. {Repo.Sec}
  2. {File.Sec}
  3. {Doc.Sec}
  4. {EG.Sec}
  5. {Plus.Sec}
{Extro.sec}
TiCmacc
Intro.secCmacc is pronounced "Smack." It is the informal name for the CommonAccord data model. The following is a semi-formal description of Cmacc. The description is based on a file format for a Cmacc "Record". A Record may be in any format, but for a variety of reasons to be expanded, the File format seems canonical. (The functional part of a Record is only slightly more complex than a "Dictionary" as used in Python. The difference is that one can "prefix" another dictionary.) With that as prologue:
Repo.TiRepository
Repo.secA Cmacc repository is a folder of files ("Files"), which may have subfolders. The Files may have meaningful names, or may be named by hashing the content of the File.
Repo.[OTF/Z/ol/0]
File.TiFiles
File.1.0.secThe Files are plain text, and each consists of a list of key/values ("Key/Value"), where the Value can be either a string or the name of another File. For instance:
File.1.1.secModel.Root={HW}
File.1.2.secHW=Hello World
File.1.3.sec=[Dx/Acme/01-AngelRound/01-SAFE-Robinson_v0.md]
File.1.4.secBuyer.=[U/id/acme_incorporated]
File.1.[OTF/Z/ol-none/s4]
File.2.secThe Key/Values are delimited by a start-of-line, the first equals sign ("=")(the Value may contain an equals sign) and an end-of-line. (There is reason to want to change this to a double end-of-line.)
File.3.secThe file format is the canonical form, but the data model can also be done in a database, including a blockchain or a graph database. It may be convenient to use JSON.
File.[OTF/Z/ol/s3]
Doc.TiRendering Documents
Doc.0.secA File can be rendered into a text (the "Doc" view of the File).
Doc.1.secRendering starts with a specific Key (currently "Model.Root") and expands its Value. Expansion is done by replacing any strings wrapped in {braces} (Variable).
Doc.2.secThe replacement is based on matching the Variable name with the first matching Key name.
Doc.3.secThe notion of "first" is based on the File. The first Key in the File (reading down from the top) is the first. If there is no Key that matches, then referenced Files are searched, in the order they appear (reading from the top), recursively, depth-first. The match of a Key in a referenced File is, of course, based on the "prefixed" Key (see the next two items).
Doc.4.secA [Path/Name_of_Another_File] is matched with a file path and name. The effect is as if the list of Key/Values in that File was copied into the current File.
Doc.5.secThe only other feature is "prefixing." When referencing another File, the Key for the reference can be empty (see below in the source view of this File) or it can be a string (see 2.= in this File). If the Key has a string, then the string is added to the front of each Key and to the front of each Variable in the referenced File. This is chained, so that if a File3 uses a prefix "Buyer." when referencing File2, and File2 uses a prefix "CEO." when referencing File1, then each of the Keys in File1 is treated as being prefixed by "Buyer.CEO." This chaining can be as long as you want. When expanding a prefixed Variable, if no match is found, then the right-most prefixing link is removed and it is tried again. ("Buyer.") (This sounds complicated, but is extremely convenient and comports with our instincts the great majority of the time.)
Doc.[OTF/Z/ol/s5]
EG.TiFor Example
EG.1.secA File of deal points references parties and a form of document: Dx/Acme/01-AngelRound/01-SAFE-Robinson_v0.md
EG.2.secFile names may be "hashes", guaranteeing uniqueness and allowing certain kinds of proof even when maintaining the confidentiality of information in a "DRY" system: S/Sandbox/Blockchain/
EG.[OTF/Z/ol/s2]
Plus.[OTF/ProseObject-Stack/Cmacc_Extensions_0.md]
Extro.secFolders.