Techniques
Comparing views — identity before appearance
A before-and-after comparison is useful when definitions keep stable identity and the compared scopes are explicit.
Why use it?
Reviewing a change means seeing it, not reconstructing it from two files: one picture shows what appeared, what vanished and what moved — generated from the model, never hand-drawn.
When it helps
Migration plans, review packets, change proposals, before/after teaching material — anywhere two revisions of a model need one shared reading.
How to read it
- Separate added, removed and changed definitions from presentation-only changes.
- A title change need not change identity.
- Connections have their own content and must be checked independently of endpoint appearance.
What you need
- The two identified revisions or model scopes
- Stable definition identity
- The intended comparison scope
Things to check
- Similar labels do not prove that two definitions are the same item.
- A visible before-and-after layout is not by itself evidence of a computed semantic diff.
The converted example preserves the supplied comparison material. Inspect the current view’s declared data and available analysis rather than assuming prototype diff syntax.
Work with the converted example
- Open the viewer and select
main. Inspect the rendered view and its source. - Open the designer. Keep the selected profile and inspect its legal palette and property controls.
- Change one displayed title or an appropriate data value. Apply the edit and check the resulting diagram.
- Run the verifier and review its diagnostics before moving complete content into review.
- Download your edited DDN source to retain the change.
The example uses the indentation-based ddn-next-1 dialect. The language guide explains reusable definitions, dotted data rows and explicit property blocks.