Notation bindings

A binding holds one modeling technology's diagram conventions as data: its diagram types, element sizing, spacing, title convention, connector routing, visual channels, standard views and presentation profiles. Adding a notation is a data change, not an engineering task. The dependency runs one way only: the composition engine contains no technology name and does not import the binding loader; a binding is data that feeds the engine.

What a binding contains. One data file per technology, in the composition skill's bindings folder, read with a safe parser so it cannot carry executable content. The declared technology id is authoritative (it must match what EA stores verbatim, the id before the :: in a diagram's <Technology>::<DiagramType> value). Every validation error names the offending key by its path into the document, and unknown keys are refused. A binding records:

• For the technology: its id; a display name and notes; optionally the binding it is built on (the base notation); a stereotype prefix (an empty prefix is a statement, not an omission); its diagram types; its standard views (viewpoints); its presentation profiles.
• For each diagram type: the EA base diagram type it is drawn on (also the resolver's weakest match); one of the eleven layout grammars; a title convention (drawn on the canvas, or supplied by EA's frame header); element sizing by notation concept, with a default; spacing, using the composer's own setting names; connector routing, with a default route and optionally the relationship types habitually drawn as a shared trunk; which visual channels the notation claims and which are free; optionally its own stereotype prefix.
• For each viewpoint: the diagram type it uses, the phrases a request might match, the concepts it admits, optionally its own grammar and notes.
• For each presentation profile: what it shows (connector labels, connector and element stereotypes, notes, compartments), whether it collapses parallel connectors and whether it keeps direction only, and a description.

Closed vocabularies. Grammars: the eleven in Layout grammars. Visual channels (ten): fill, border, border width, line color, line style, font color, opacity, icon, size and position. Title conventions: drawn or frame header. Routes (ten, EA's Line Style names): Direct, AutoRouting, CustomLine, TreeVertical, TreeHorizontal, LateralVertical, LateralHorizontal, OrthogonalSquare, OrthogonalRounded and Bezier. Comparison ignores case and punctuation.

What the schema is strict about, and why.

• Spacing uses the engine's own setting names, so translating a binding to a spec is the identity. A misnamed setting such as a bare "pitch" is refused with the names the author probably meant. Values are not range-checked in the binding; the composer owns that.
• Channels are mandatory, and so is the statement of what fill is used for, because each notation already claims some visual channels. A channel cannot be both claimed and free. A notation that does not use fill can say so, and then fill may appear among the free channels.
• The title convention is explicit per diagram type because a diagram with two titles and a diagram with none are equally likely mistakes. Measured across the reference corpus, 13 of 13 ArchiMate diagrams draw a title and 10 of 11 BPMN diagrams use EA's frame.
• A binding may name a grammar that cannot be composed, such as EA-semantic, so that the diagram type is recorded honestly.
• Measured sizes do not know the content's names (see the fit conflict in Composition modules).

Inheritance. EA is a UML tool and every MDG technology is a stereotype layer applied to UML. One binding (UML, the base notation) is the root and every other declares that it extends UML, recording for each of its own diagram types which of the parent's diagram types it is drawn on. What a child states wins. What it leaves unstated is inherited for exactly two things: sizing per concept and spacing per setting, taken from the diagram type it is drawn on (the substrate). Grammar, title, routing, channels and notes are never inherited (letting a parent's graph win over a child's layered bands would flatten the structure an MDG adds). The stereotype prefix is inherited only when absent, and from the technology, never the substrate. Viewpoints and presentation profiles inherit one level with the child's entries winning. A child does not acquire its parent's diagram type catalog.

The binding loader and resolver (bindings.py)

What it does, and why it matters to you. Loads and validates bindings, resolves inheritance, translates a diagram type's conventions into the spec a composer takes, and resolves which binding applies to a given diagram. It is why a diagram gets the sizes and spacing its notation uses without anyone typing numbers.

Logic: Rule-based for resolution (a judgment with a stated confidence); deterministic for loading and building a spec.

What it takes in and produces

A binding answers, for any concept, which stereotype EA stores and the reverse; which diagram type a diagram's style names; and which viewpoints admit a given set of concepts, narrowest first. A diagram type answers its spec, size for a concept, claimed and free channels, default and per-relationship routes, whether it draws its own title, and the grammar's three answers and placement. A viewpoint carries what it admits, its intent, its diagram type and the same grammar answers (with "no opinion" meaning ask the diagram type). A presentation profile yields its display settings and whether it collapses parallel connectors.

Used by. ea-diagram-composition, and ea-diagram-advisor (it ranks the bindings' viewpoints).

How resolution behaves. The resolver runs a chain, each step reporting its own confidence: the diagram's own <Technology>::<DiagramType> (exact, and final whether or not it resolves); the diagram type matching exactly one bound diagram type name (inferred); the diagram type matching exactly one bound base type (weak). The installed-technology inventory filters every step: a binding for a technology the repository does not have is never used, however well it matches. Unresolved answers say which kind of nothing they are: ambiguous, unbound, not installed or unidentified. When the AI asks for a spec with the item names, the width is widened to the narrowest at which the longest space-free run of the widest name reads as fitting, plus the checker's label margin each side, and the spec carries the conflicts, what was widened, the requested width, the driver, a note, whether the figure is extrapolated, and the conflicts still unanswered. A full-width character is charged two cells; other characters outside printable ASCII are reported as unvalidated.

Limitations. The direct lookup cannot say why it found nothing. A spacing setting the diagram type's composer never reads is inert and nothing reports it. The text-fit constant was calibrated as a maximum over printable ASCII in one font. A multi-word name can still read as cramped at a width where it fits on one line (the label-cramped check is the backstop).

Shipped bindings. Eleven bindings ship. The table lists what each binds.

Totals. 32 diagram types are bound: graph 15, layered bands 9, lanes 3, and one each of radial, radial tree, chevron stack, matrix and EA-semantic. One technology (UML) is the base; ten extend it. Only ArchiMate 3 declares viewpoints. Presentation profiles ship in three bindings: ArchiMate 3, BPMN 2.0 and UML.

Presentation profiles. Each profile says what a view shows. Detail: everything (labels, stereotypes, notes, all compartments, no collapsing). Review: connector labels and notes shown, stereotypes hidden, compartments reduced to names. Executive: labels, stereotypes and notes hidden, compartments reduced to names, parallel connectors collapsed to direction only; collapsing requires an annotation. Notation-specific descriptions: BPMN's review profile keeps flow labels because they carry gateway conditions, and its executive profile summarizes the happy path. UML's review profile keeps labels because they carry multiplicities and role names.

Coverage and deliberately unbound types. A diagram type with no binding is not a wall: it is composed from engine defaults and the gap is fidelity (measured sizes, spacing, prefix), not capability. A resolution reports it as "unbound". Types are left unbound for a stated reason, all recorded in the bindings' own notes:

• No supportable default size. A default size is mandatory and a figure is only stated when it comes from at least 10 observations with a unique mode, or is inherited from the substrate. Below that, the type is recorded as an omission, not guessed. Examples: UML Collaboration and InteractionOverview; StrategyMap BalancedScorecard (4 elements, one size) and FlowChart (a tie between two sizes); TOGAF_EnterpriseContinuum (8 of 8 the same size, one observation short), TOGAF_ADM, TOGAF_ACM, TOGAF_OrganizationStructure and IEEE1471_ConceptualFramework.
• Classified as graph, with no binding. BPMN Conversation (a graph of participants and hexagons) and BPEL (an execution export, not a drawn notation); SysML InternalBlock, UseCase, Parametric, Package and Activity; some thirty UAF diagram types across the seven other ids of that family.
• Classified EA-semantic, not producible. UML Sequence; SysML Sequence and StateMachine; UAF state-machine and sequence types; the UAF programme-timeline type (horizontal position is a date).
• Different sampled shapes. UAF SV-4 mixes an activity graph and an action flow with pins nested in actions, so it is composed from engine defaults.

The server's benchmark suite audits the bindings against a reference corpus of professionally drawn diagrams. Its percentages are recomputed on every run from the bindings and a research catalog.