Project Michael Dings Impressum Login

All-Dings-LLD

I am a Design-Document.

About

Scope

I describe Low-Level-Details of the current All-Dings-Implementation.

The All-Dings-HLD describes the high-level System-Design. I describe the concrete Files, Data-Structures, Commands and Implementation-Details behind that Design.

Build and Deployment Details

The Top-Level-Makefile is:

Important Make-Targets are:

The current Work-Dir Makefile is:

The current Rendering-Makefile is:

The current default Html Rendering uses:

The legacy Html Rendering is still available:

Design-Direction:

The Web-Server can be started with: 

~/All-Dings/111 (Master)$ dings-host docker web start

Directory-Structure

The following Directories are used in the Dings-System:

The Environment-Variable Dings_Dir defines the Starting-Point: 

$ set | grep Dings_Dir
Dings_Dir=/Users/michaelholzheu/All-Dings/111

Top-Level Files

Runtime-Files

Config-Files

Log-Files

Repository-Layout

Day

dings-gpt show sm

The dings-gpt show sm Implementation uses the following Pipeline: 

md -> ir -> sm1 -> sm2 -> Text

The current Json Artifacts are:

The Pipeline-Layers have the following Implementation Roles:

Representation Json Structures

The generated Json-Files are Implementation-Artifacts.

Their exact Shape is defined by the current Code and can change.

This Document describes only the stable Top-Level-Structure and the intended Meaning of important Keys.

ir uses:

sm1 uses:

sm2 uses:

All-Dings.sm2.json adds global Lists and Maps for cross-document Queries.

For exact current Json, use the generated *.ir.json, *.sm1.json, *.sm2.json and All-Dings.sm2.json Files together with the Builder-Code.

Target-Resolution

show sm accepts different Target-Forms:

Concrete Targets resolve to a Dings-Number.

Virtual Class-Targets can also resolve to a virtual Class-Key, for Example when a Reference-Label is different from the canonical Dings-Name.

dings

show sm dings TARGET shows one Dings.

The command ensures the current sm1 and sm2 Json-Files for the Dings, builds a SM-Channel and renders it as Text.

The Output combines:

list

show sm list TARGET shows Members of a Class or virtual Class.

It uses:

show sm list [TARGET] where PREDICATE=OBJECT shows Dings matching a Relation.

It uses:

The where Form supports Wildcards:

names-of

show sm names-of TARGET [BASE] shows observed Names and Reference-Labels for a Dings.

It uses:

The optional BASE filters Names by Context-Class.

claims-from

show sm claims-from CLAIMER [PREDICATE] shows Claims that originate from one Dings.

It uses:

The optional PREDICATE can filter by:

All-Dings.sm2.json

The following Maps in All-Dings.sm2.json are especially relevant for show sm:

Global Views like list, names-of and claims-from require a current All-Dings.sm2.json.

The current Command to generate it is: 

~/All-Dings/111 (Master)$ dings-gpt render md-sm2

dings-gpt render Ir-Html

The Ir-Html Render-Path renders the ir Document-View into Html-Files without reparsing Markdown.

It is the current default Html Render-Path used by make render.

Supported Command Forms are: 

~/All-Dings/111 (Master)$ dings-gpt render Ir-Html
~/All-Dings/111 (Master)$ dings-gpt render 'Ir->Html'
~/All-Dings/111 (Master)$ dings-gpt render Ir Html

The default Output is:

The Render-Path uses:

The Render-Path expects the required Presentation and App Assets to exist in the target Html Environment.

The first Html Document-View renders:

The legacy dings html generate -a Command stays available.

Debug-Output

With -debug, show sm can show less compressed Source-Details where supported.

This includes: