skip to content

In a BPMN 2.0 interchange file, what does the process XML hold versus the BPMN DI section, and why must both travel together?

level: middleimportance: should knowfreq 30%

answer

  1. semantics versus layout
  2. shapes and edges point at elements
  3. what the layout part deliberately omits
  4. an engine may not draw at all

basics

~20 s

In BPMN 2.0 the process XML holds the model's semantics: elements, flows, data and attributes. The BPMN DI section holds only layout, shapes and edges on a plane, each pointing at a model element. Rendering needs both; execution needs only the model.

solid answer

~50 s

A BPMN 2.0.2 file has two layers. The **semantic model** (`definitions` with `process`, `collaboration`, `sequenceFlow`, data and attributes) is what an engine executes. **BPMN DI** (`BPMNDiagram` containing a `BPMNPlane` of `BPMNShape` and `BPMNEdge` elements) records positions, bounds and waypoints, and every shape or edge names its model element with `bpmnElement`. DI deliberately holds only what cannot be derived from the model, so a tool needs **both** to redraw the diagram; the standard says DI does not preserve tool "smarts", does not interchange colour, and does not check that the model is correct. The same model can carry several diagrams, each a partial view. An engine claiming Process Execution Conformance need not support the graphical syntax at all, which is why an executable model can run with no DI and why a model that only round-trips its drawing can still lose semantics.

code

xml · 11 lines
xml
<bpmndi:BPMNDiagram id="ExpenseDiagram">
  <bpmndi:BPMNPlane bpmnElement="ExpenseReimbursement">
    <bpmndi:BPMNShape bpmnElement="ApproveClaim">
      <dc:Bounds x="240" y="80" width="100" height="80"/>
    </bpmndi:BPMNShape>
    <bpmndi:BPMNEdge bpmnElement="OverLimit">
      <di:waypoint x="180" y="120"/>
      <di:waypoint x="240" y="120"/>
    </bpmndi:BPMNEdge>
  </bpmndi:BPMNPlane>
</bpmndi:BPMNDiagram>

go deeper

for a junior

Recall that the model holds meaning and BPMN DI holds positions, with each shape pointing at a model element.

for a middle

Explain what DI deliberately omits, why rendering needs both layers, and why execution needs only the model.

for a senior

Verify round-trips by comparing semantic models and extensions, not screenshots, and trace lost behaviour to dropped extensions.

for a principal

Set interchange policy for a toolchain: which layer is authoritative, which extensions are allowed, and how models are validated on import.

## Two layers in one file When the analyst exports the expense-reimbursement model and the developers import it, the file carries two separate things. | Layer | Root elements | Holds | Needed for | |---|---|---|---| | **Semantic model** | `definitions`, `process`, `collaboration`, `message`, `itemDefinition` | elements, sequence and message flows, data, expressions, implementation attributes | execution and analysis | | **BPMN DI** | `BPMNDiagram`, `BPMNPlane`, `BPMNShape`, `BPMNEdge` | bounds of shapes, waypoints of edges, labels, a few visual flags | redrawing the diagram | ## What BPMN DI is for Clause 12 of BPMN 2.0.2 defines **BPMN Diagram Interchange**: - It is meant to facilitate **interchange of diagrams between tools**, not to be a tool's internal representation. - The simplest approach was chosen to ensure unambiguous rendering, so DI does **not** preserve "tool smarts" such as layout intelligence or efficient styling. - It does **not** interchange colour; colour use in BPMN is non-normative. - It does **not** ascertain that the diagram is syntactically or semantically correct. - A diagram is a serialisation of **shapes and edges on a plane**; `BPMNPlane`, `BPMNShape` and `BPMNEdge` must each reference exactly one model element through `bpmnElement`. The one exception is a data object associated with a sequence flow, which is a shortcut for two data associations. - DI contains only information that is neither present in nor derivable from the model, so **to render a diagram, both the DI and the referenced model are required**. - One model can have **several diagrams**, each an incomplete or partial depiction. An element may not be depicted twice in one diagram (participant bands in a choreography excepted), but may appear in two diagrams. - DI has **no containment**: a plane is an ordered list of shapes and edges, and the order sets the Z-order. ## Why the separation matters for round-tripping 1. **Layout survives, semantics must too.** A tool that preserves DI but drops unknown attributes produces a diagram that looks identical and behaves differently. Check the semantic layer, not the picture. 2. **Execution does not need DI.** A tool claiming **Process Execution Conformance** is not required to support the standard's graphical syntax; it must support import of process diagram types and interpret the metamodel. An engine can run a model with no DI. 3. **Extensions ride in the semantic layer.** Engine-specific attributes are extensions to the model; if the importing tool does not understand them and `mustUnderstand` is false, it may drop them silently. 4. **`exporter` and `exporterVersion`** attributes on `definitions` record which tool wrote the file, which helps diagnose round-trip differences. ## And WS-BPEL? BPMN's stated scope includes ensuring that execution languages such as **WS-BPEL** can be visualised with a business-oriented notation. BPMN 2.0.2 has its own XML serialisation and execution semantics, and keeps the **mapping to WS-BPEL** as a separate conformance type, **BPEL Process Execution Conformance**. The mapping chapter states: - There is no mapping of the diagram itself; **each orchestration process in a pool maps to an individual WS-BPEL process**. - Not every BPMN process maps straightforwardly, because BPMN allows almost arbitrary graphs while WS-BPEL control flow is block-structured or acyclic; an **unstructured loop** cannot be represented directly. - To be mapped, a process **must be sound**: no deadlock (a token that can never be removed) and no lack of synchronisation (more than one token on a sequence flow). In practice the mapping is history for most teams: the BPMN XML itself is what tools interchange and engines execute. ## A round-trip check When a model moves between tools, compare the semantic layer: 1. Count elements by type in both files; a task that became a plain task has lost its type. 2. Compare every `formalExpression` and its declared language. 3. Compare implementation attributes, resource assignments and message references. 4. List extension elements the importing tool dropped or kept. A diagram that looks the same passes none of these checks by itself. ## Interview summary Say which layer holds what, that both are needed to redraw and only the model to execute, what DI deliberately leaves out, and that a round-trip check must compare semantics rather than the picture.

  • In BPMN 2.0, can one element appear twice in the same diagram?
    No. Multiple depictions of an element in a single diagram are not allowed, except participants in a choreography's participant bands. The same element may appear in two different diagrams of the same model.
  • In BPMN 2.0, does valid BPMN DI prove the model is correct?
    No. The standard says BPMN DI does not ascertain that the diagram is syntactically or semantically correct. Validation has to be done on the semantic model against the specification's rules.
  • In BPMN 2.0, why can't every process be mapped to WS-BPEL?
    BPMN allows almost arbitrary control-flow graphs, while WS-BPEL control flow is block-structured or free of cycles. A process must be sound to map, and an unstructured loop cannot be represented directly.

saying these in an interview costs you the question

  • Believing BPMN DI carries the process semantics
  • Assuming a matching picture after import means nothing was lost
  • Thinking an engine cannot run a model without diagram information
  • Expecting BPMN DI to preserve colours and tool layout rules
  • Believing every BPMN process maps directly to WS-BPEL