Open psbrandt opened 4 years ago
Once the RFC is written, the elm-utils
library should be updated to return the decided upon intermediate representation as a POJO, and a new version should be published. Then, the phema-workbench-api should be updated to use this new version, and the ELM resource should be updated to return the new intermediate representation.
Many DSLs by libraries such as mermaid, flowchart.js, and Graphviz follow a general structure of:
Some of the DSLs allow you to intermix those two types of statements where you define nodes and relationships in a single statement.
:bulb: Our intermediate representation should allow representation in more than one DSL, assuming the DSL follows the general structure listed above.
These DSLs also allow you to specify the formatting as part of each expression.
:bulb: We should keep our intermediate representation free of display-specific details (e.g., square rectangle vs. rounded rectangle).
Many libraries that support flowchart-like displays will account for sub-graphs.
Need to also consider that not every visual representation is going to be purely graph-like. The example libraries listed so far are more graph based but we should account for other representations/visual paradigms that could be used.
We need to figure out the strategy for preparing an ELM tree for visualization. What do should our intermediate representation look like, and what is the pre-processing we need to do to generate it? Right now we have this visitor implementation:
https://github.com/PheMA/elm-utils/blob/bbcaed174a5c3f0aafbbede9a4e4a3bc4383c35e/src/main/java/edu/phema/transform/visiting/ElmGraphTransformationVisitor.java#L6
However, neither the
ElmBaseStatementPostOrderTransformationVisitor
nor theElmGraphTransformationVisitor
are complete, and we don't have a clear idea of what to do for complex expressions (e.g. temporal operators).