1. MIWG – Semantic Interchange Validation
Bruce Silver
Bruce Silver Associates/BPMessentials
Feb 20, 2013
© Bruce Silver Associates 2013
In cooperation with itp commerce ltd.

2. What is the Goal?
 Model interchange
 Starting from a reference diagram (plus possibly invisible semantic info, e.g. process/@name?)...
• Create the diagram in tool A
• Export BPMN xml from tool A
• Import xml into tool B
 How do we define success?
• Tool B model is semantically equivalent?
 E.g. hierarchical vs inline subprocess expansion
 Conditional sequence flow vs equivalent gateway
 AND split gateway vs multiple outgoing sequence flows
• Tool B model is semantically identical?
 Preserve IDs, element/attribute values exactly?
• Graphical equivalence – not my main concern here
 All tools have limitations
• Don’t support all BPMN elements, attributes, and patterns
• Don’t support all character sets, e.g. Unicode
• Specific graphics libraries, e.g. fixed size of graphic elements
• ID values
• Default element/attribute values where unspecified in the diagram
• How diagram labels generate semantic values (and vice versa)
 … so to facilitate interchange, MIWG export rules must impose additional constraints beyond what
is allowed by the spec
© Bruce Silver Associates 2013
In cooperation with itp commerce ltd.

3. The Serialization (Export) Problem
 Certain serializations are allowed or required by the spec
 … but need more than XSD and EMF to validate against the spec
• Metamodel and XSD don’t always agree
• Narrative text and tables may not agree with either one
• The spec is vague on some points
• There are also bugs
 We need to agree on the serialization rules for BPMN…
• Definitely allowed by the spec (consensus),
• Definitely not allowed by the spec (consensus), or
• In dispute (reasonable people may disagree, spec is vague or contradictory)
 … and agree on the additional MIWG constraints
• What elements and attributes are allowed in the export?
• Additional validation rules
 Once we agree on the rules, tools can validate against them
© Bruce Silver Associates 2013
In cooperation with itp commerce ltd.

4. Validating the Export
 Since the input is XML
and the output is a
report, XSLT works well
http://www.webratio.com/bpmnValidation
© Bruce Silver Associates 2013
In cooperation with itp commerce ltd.

5. A VERY simple model
 Serialization of the sequenceFlow no
 @name=‘no’ ?
• we probably all agree
 Child conditionExpression?
• I think so but others may not
• What is the proper value?
 no
 OK=‘no’
 Other?
© Bruce Silver Associates 2013
In cooperation with itp commerce ltd.

6. A slight variation
 Serialization of the sequenceFlow no
 Is this allowed?
• In my tool, gives “style error” if default flow has a label
 @name=‘no’ ?
• I think so, but others might disagree
 Child conditionExpression?
• I think not, but others might disagree
• What is the proper value?
 [no element]
 no
 OK=‘no’
 otherwise
 OK=‘otherwise’
© Bruce Silver Associates 2013
In cooperation with itp commerce ltd.

7. Other thorny issues
 How many participant elements in this model?
 What are their names?
 What is the name of the process?
 Can a child-level page (bpmndi:BPMNPlane/@bpmnRef points to a subprocess)
contain flowNode of another process?
 I think a structure error, but others may disagree
 Data flow: where should data associations be allowed/disallowed?
 Many many more…
© Bruce Silver Associates 2013
In cooperation with itp commerce ltd.

8. The Import Problem
 How much of the export must be preserved exactly on import?
 Versus converted to semantic equivalent?
 What elements/attributes can be ignored?
 Upon further editing in Tool B, how much consistency with Tool A export?
 Upon re-export from Tool B, to what extent can element/attribute values be
changed?
 This seems much harder problem
 Harder to define the rules
 Harder to validate automatically
© Bruce Silver Associates 2013
In cooperation with itp commerce ltd.