/Docs/S/About/Tech/Spec/0.md
  Source views: Source JSON(ish) on GitHub (VSCode)   Doc views: Document (&k=r00t): Visual Print Technical: OpenParameters Xray
(Sec = (Ti = Tech:)

(sec = (0.sec = )
(xlist = (Olist =
  1. (Package.Sec = (Package.Ti = Packages ("Cmacclets"))

    (Package.sec = (Package.0.sec = A set of files organized as Doc/; File/; query/; and vendor/. )
    (Package.xlist = (Package.Olist =
    1. (Package.Secs = (Package.secs = (Package.1.sec = Doc/ has Cmacc text. (Should the folder be called "Record/" or "Cmacc/" ?))
    2. (Package.2.sec = File/ can have "data" of any nature. The goal is to be able to communicate a data package - for instance an a/v work or a medical scan - with accompanying text and functions.)
    3. (Package.3.sec = query/ and vendor/ are technical (suggested by lower-case). ("query/" is a better label for what is currently called "view" in the existing implementations. "vendor/" is used for code - and some hosting systems currently require that name. )
      )
      )
    )
    )
    (Package.00.sec = )
    )
    )
  2. (Record.Sec = (Record.Ti = Records)

    (Record.sec = (Record.0.sec = )
    (Record.xlist = (Record.Olist =
    1. (Record.Secs = (Record.1.Sec = (Record.1.Ti = Implemented Features of Records)

      (Record.1.sec = (Record.1.0.sec = )
      (Record.1.xlist = (Record.1.Olist =
      1. (Record.1.Secs = (Record.1.secs = (Record.1.1.sec = A "Record" is an ordered list of key/values.)
      2. (Record.1.2.sec = (Record.1.2.0.sec = The "Values" are strings. They can be understood as: )
        (Record.1.2.xlist =
        1. (Record.1.2.secs = (Record.1.2.1.sec = html;)
        2. (Record.1.2.2.sec = the name of another Record;)
        3. (Record.1.2.3.sec = something else, for instance some computer code or a comment.)
          )
        )
        (Record.1.2.00.sec = )
        )
        )
        )
      )
      )
      (Record.1.00.sec = )
      )
      )
    2. (Record.2.Sec = (Record.2.Ti = "Punctuation")

      (Record.2.sec = (Record.2.0.sec = The rendering engine should work with a variety of formats:)
      (Record.2.xlist = (Record.2.Olist =
      1. (Record.2.Secs = (Record.2.secs = (Record.2.1.sec = The current flat file, source-code resembling. This enables use with tools of software collaboration. (Legal source prose is like software source code.))
      2. (Record.2.2.sec = JSON, for instance in blockchains, IPFS, etc.)
      3. (Record.2.3.sec = XML)
      4. (Record.2.4.sec = Databases - SQL and graph - for enterprise management.)
      5. (Record.2.5.sec = Google Docs - and why not have a mode that disrenders the text (makes into key=values) and then rerenders it with possible overrides.)
        )
        )
      )
      )
      (Record.2.00.sec = )
      )
      )
      )
    )
    )
    (Record.00.sec = )
    )
    )
  3. (query.Sec = (query.Ti = Cmacc-compliant rendering for blockchain and other databases: )

    (query.sec = (query.0.sec = )
    (query.xlist = (query.Olist =
    1. (query.Secs = (query.1.Sec = (query.1.Ti = Example of a JSON-formatted query)

      (query.1.sec = Example of a query done as a JSON snippet.)
      )
    2. (query.2.Sec = (query.2.Ti = Queries)

      (query.2.sec = (query.2.0.sec = )
      (query.2.xlist = (query.2.Olist =
      1. (query.2.Secs = (query.2.secs = (query.2.1.sec = (query.2.1.0.sec = 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:)
        (query.2.1.xlist = (query.2.1.Olist =
        1. (query.2.1.Secs = (query.2.1.secs = (query.2.1.1.sec = "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. (query.2.1.2.sec = "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. (query.2.1.3.sec = "print" view without wrapping.)
        4. (query.2.1.4.sec = "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. (query.2.1.5.sec = "missing" list of keys not found.)
          )
          )
        )
        )
        (query.2.1.00.sec = )
        )
      2. (query.2.2.sec = (query.2.2.0.sec = All the other "views" currently in the CommonAccord app are common database queries, where an interface has been applied to the return. For example: )
        (query.2.2.xlist = (query.2.2.Olist =
        1. (query.2.2.Secs = (query.2.2.secs = (query.2.2.1.sec = "edit" view of the raw text in editable mode)
        2. (query.2.2.2.sec = "raw" mode the text, no editing)
        3. (query.2.2.3.sec = "map"(?) (currently called Source) view of the text of the Record with nice presentation, and file names linked for navigation.)
        4. (query.2.2.4.sec = "find" a (partial) listing of keys and values available. Could be part of graph navigation via "map." )
          )
          )
        )
        )
        (query.2.2.00.sec = )
        )
        )
        )
      )
      )
      (query.2.00.sec = )
      )
      )
    3. (query.3.Sec = (query.3.Ti = Render (parameter))

      (query.3.sec = (query.3.0.sec = )
      (query.3.xlist = (query.3.Olist =
      1. (query.3.Secs = (query.3.1.Sec = (query.3.1.Ti = Rendering is Expansion of a Value)

        (query.3.1.sec = (query.3.1.0.sec = )
        (query.3.1.xlist = (query.3.1.Olist =
        1. (query.3.1.Secs = (query.3.1.secs = (query.3.1.1.sec = A "Document" is the result of rendering a "Record".)
        2. (query.3.1.2.sec = 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. (query.3.1.3.sec = Plugs are expanded by literal matching with the Plug name with the first matching Key name in the namespace of the Record. )
          )
          )
        )
        )
        (query.3.1.00.sec = )
        )
        )
      2. (query.3.2.Sec = (query.3.2.Ti = The Key namespace of a Record)

        (query.3.2.sec = (query.3.2.0.sec = The Key namespace of a Record1 is:)
        (query.3.2.xlist = (query.3.2.Olist =
        1. (query.3.2.Secs = (query.3.2.secs = (query.3.2.1.sec = the Keys in Record1,)
        2. (query.3.2.2.sec = (query.3.2.2.0.sec = for each RecordN referenced as a Value in Record1 - the Keys in RecordN:)
          (query.3.2.2.xlist = (query.3.2.2.Olist =
          1. (query.3.2.2.Secs = (query.3.2.2.secs = (query.3.2.2.1.sec = If a RecordN is referenced by an empty Key, the Keys and Values are included as is.)
          2. (query.3.2.2.2.sec = (query.3.2.2.2.0.sec = 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.)
            (query.3.2.2.2.xlist = (query.3.2.2.2.Olist =
            1. (query.3.2.2.2.Secs = (query.3.2.2.2.secs = (query.3.2.2.2.1.sec = 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. (query.3.2.2.2.2.sec = 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. )
              )
              )
            )
            )
            (query.3.2.2.2.00.sec = )
            )
            )
            )
          )
          )
          (query.3.2.2.00.sec = )
          )
        3. (query.3.2.3.sec = recursively, depth-first.)
          )
          )
        )
        )
        (query.3.2.00.sec = )
        )
        )
      3. (query.3.3.Sec = (query.3.3.Ti = Ordered versus Unordered List)

        (query.3.3.sec = (query.3.3.0.sec = Currently, the order of Keys in a Record is significant. )
        (query.3.3.xlist = (query.3.3.Olist =
        1. (query.3.3.Secs = (query.3.3.secs = (query.3.3.1.sec = A Record may contain more than one Key with the same name - the top one has priority. )
        2. (query.3.3.2.sec = It is common to reference a number of RecordNs via the same Key, notably with an empty Key.)
        3. (query.3.3.3.sec = Multiple Key/Values is otherwise of minor use.)
          )
          )
        )
        )
        (query.3.3.00.sec = It would be possible to develop a naming convention for Keys that indicated order. For instance (1)=[High_Priority.md], (2)=[Next_Priority.md])
        )
        )
        )
      )
      )
      (query.3.00.sec = )
      )
      )
      )
    )
    )
    (query.00.sec = )
    )
    )
  4. (Future.Sec = (Future.Ti = Future Possible Extensions)

    (Future.sec = (Future.0.sec = )
    (Future.xlist = (Future.Olist =
    1. (Future.Secs = (Future.1.Sec = (Future.1.Ti = Smart Folders)

      (Future.1.sec = (Future.1.0.sec = A very useful extension would be "smart" Folders.)
      (Future.1.xlist = (Future.1.Olist =
      1. (Future.1.Secs = (Future.1.secs = (Future.1.1.sec = For example, to replace the mass of Records currently at Z/ol/*, a smart folder could intercept the request for a file and return a (calculated) Record.)
      2. (Future.1.2.sec = Of course, smart Folders would respect the object model. An actual Record would have precedence over a calculated one. )
        )
        )
      )
      )
      (Future.1.00.sec = )
      )
      )
    2. (Future.2.Sec = (Future.2.Ti = Rendering)

      (Future.2.sec = (Future.2.0.sec = The following seem necessary extensions to rendering:)
      (Future.2.xlist = (Future.2.Olist =
      1. (Future.2.Secs = (Future.2.secs = (Future.2.1.sec = There needs to be a naming convention for the _second, and _third_, etc. highest priority Key in the Record's namespace. Foo=This value used to say: {Foo//-1}.)
      2. (Future.2.2.sec = The namespace (path) of Records can be augmented by specifying another, additional path. This additional Path2 adds to the namespace of the Path in the same way that referencing a Record2 adds to the namespace of a Record. The Path2 is treated as having higher priority than the basic Path.)
      3. (Future.2.3.sec = (Future.2.3.0.sec = It is desired to keep the functions and syntax very simple. The functions that remain somewhat cumbersome include: )
        (Future.2.3.xlist = (Future.2.3.Olist =
        1. (Future.2.3.Secs = (Future.2.3.secs = (Future.2.3.1.sec = Automatic numbering of cross-references. These can be parameterized, but there is still a bit of work. (Can be handled via interface.))
        2. (Future.2.3.2.sec = Calculation of values such as sums of a column of numbers. Can be handled by interface, or by smart contract. )
          )
          )
        )
        )
        (Future.2.3.00.sec = In each case, persisting the value as a standard Key/Value in a Record may increase certainty by keeping the data simple. )
        )
        )
        )
      )
      )
      (Future.2.00.sec = )
      )
      )
      )
    )
    )
    (Future.00.sec = )
    )
    )
)
)
(00.sec = )
)
)