1. BPMN Diagram Interchange BPMN DI Schema and Meta-model Baseline Proposal
Subgroup Chair:
Robert Shapiro (Global360)
Baseline Proposal:
Denis Gagné (Trisotech)
Maged Elaasar (IBM)

2. Goal & Requirements Requirements Goal
The BPMN DI subgroup was mandated by the general FTF to create a BPMN DI schema that will only contain information that is neither present nor derivable from the semantic model
Goal
Create a simple BPMN Diagram Interchange (DI) Schema
Align BPMN DI schema with the DI Metamodel
Explore possible auto-generation of the schema from the MM

3. Background

4. OMG Diagram Definition Specification
Seperate OMG Diagram Definition specification effort ongoing
Diagram Definition specification to provide methods to formally define the graphical notation (diagrams) of MOF-based graphical languages, including but not limited to UML, SysML and BPMN.

6. DI

7. DI

8. DI

9. BPMN DI Meta-Model & Schema

10. The BPMN DI Meta-model

11. BPMNDiagram DI
BPMN DI

12. BPMNPlane DI
BPMN DI

13. BPMNShape DI
BPMN DI

14. BPMNEdge DI
BPMN DI

15. BPMN DI Concepts A BPMNDiagram has a BPMNPlane as root
A BPMNShape that is referring a semantic element
A BPMNEdge referring a semantic element
A BPMNShape that is a BPMNPlane
A BPMNPlane contains BPMNShapes and BPMNEdges

16. Schema Baseline One page long XSLT friendly
The Schema Baseline was posted as a proposal to

17. Showcase Example (from Maged)
Examples
Showcase Example (from Maged)

18. Process Diagram from Maged

19. Progress Diagram from Maged
BPMNShape bounded containing a BPMNPlane
BPMNDiagram
With a BPMNPlane as root
BPMNShape bounded containing a BPMNPlane that contains 4 BPMNShapes one of which is a BPMNPlane

20. Progress Diagram from Maged
BPMNShape bounded containing a BPMNPlane that contains 3 BPMNShapes and 1 BPMNEdge

21. Examples
Pools vs Lanesets

22. Page 182 Example with Pool
Using a Pool creates an incomplete Collaboration of one Participant depicted in one diagram

23. Page 182 Example with Lanes
Using a Lane creates a Process depicted in one diagram

24. Figure 7-6 Collaboration with Black Box Pools

25. Sub Processes and Call Activity
Examples
Sub Processes and Call Activity

26. Sub Process Expanded
One Process with one Diagram

27. Sub Process Collapsed One Process with two Diagrams
Details of Embedded Sub Process on a separate Diagram

28. Call Activity (Re-Use Sub Process)
Two Processes with two Diagrams
Details of Called Process on a separate Diagram

29. Conclusions
Choices made between orthogonal options will have to be confirmed/infirmed
Issues were raised in Jira against the Baseline for that purpose
Comments and Feedback are welcomed

30. Conclusions
The BPMN DI Baseline Proposal Schema is a simple and easy to read schema
One page long XSLT friendly
The BPMN DI Baseline Proposal Schema is completely aligned with OMG’s DI Meta-model
We even hope to potentially have the schema auto-generated from the Meta-model
The BPMN DI Baseline Proposal Schema only contains information that is neither present nor derivable from the semantic model
Except for Target and Source as per Issue A

31. Confirming/Infirming Choices

32. Confirming/Infirming Choices
Duplication of Source and Target information from the BPMN Semantics to the BPMN DI

33. Duplication of Source and Target information from the BPMN Semantics to the BPMN DI
The BPMN DI subgroup was mandated by the general FTF to create a BPMN DI schema that will only contain information that is neither present nor derivable from the semantic model.  In preparing the BPMN DI baseline proposal duplication of Source and Target were introduced in the BPMNEdge element to address the following cases:
Visual element without a semantical element to reference (e.g. conversation link).  Given that no semantical element can be referenced the target and source are required as these only exist in the BPMN DI.
This would also apply to visual extensions that are associated to element of the process diagrams but are not in the semantic (e.g. yellow sticky notes)
A semantical element that can be depicted many times (e.g. DataObject). It is possible to depict the same semantical DataObject many time on a diagram. We thus need target and source in DI to link the correct visual instance as they all depict the same semantical element.
Possible Remedy: In order to remove this duplication, a semantic element should exist for every depictable element.
Option If Source and Target duplication is maintained then maybe they should be made optional and only used in the above particular cases. The fact is that currently the BPMNEdge is of type DI:LabeledEdge, to have the Source and Target as optional would imply making them optional in the generic DI (Non BPMN Domain Specific) and that may not be desirable to the community of other domains.
This choice was reported as an issue for discussion purposes

34. Confirming/Infirming Choices
Sub typing BPMN DI elements vs grab bag attributes

35. Sub typing BPMN DI elements vs grab bag attributes
In an effort to not duplicate any information that is neither present nor derivable from the semantic model a grab bag approach was taken in the BPMNShape element for 4 visual attributes rather than duplicating the element type information contained in the semantic.
isHorizontal : Applies only to semantic context of type Laneset and Participant
isWhiteBox: Applies only to semantic context of type Participant
isExpended: Applies only to semantic context of type SubProcess and AdhocSubProcess,….
isMarkerVisible: Applies only to semantic context of type Exclusive Gateway
This choice was reported as an issue for discussion purposes

36. Confirming/Infirming Choices
Containment Structure x +

37. Containment structure
The BPMN DI baseline proposal does not capture element specific containment structure.  The BPMN DI has the notions that a BPMNShape can be an “atomic visual shape” or can be a BPMNPlane providing the layout of the “content” (e.g. Pool, Lane, Sub process, etc).  This has the effect that the actual containment relationship is only maintained in the semantic and is not duplicated and thus directly accessible only from the DI.  (For example in the case of matrix layout of lanes an element belonging to both and horizontal lane and a vertical lane in the semantic, the element could find itself at the root plane, the vertical lane plane or the horizontal lane plane.  A best practice of having elements at the root plane could be advised in such case).
An alternative approach could be to have notions of element specific containers such as laneplanes, subprocesplanes, etc.
This would make navigation and awareness of the containment structure possible from only the DI.
This choice was reported as an issue for discussion purposes

38. Stylesheet
The DI and more particularly the BPMN DI introduces the notion of “cascading style sheets”. 
The following precedence rule was favored in BPMN DI: Element, Local or current  Style, Master Style, Default.  The style at the element level on an attribute by attribute base overrides the styles inherited from above.  This means that if a Master Style specifies that all shapes should be blue with a texture gradient, one can only specify the color red for a specific shape at shape level and this particular shape will be red and will inherit the texture gradient from the master style while all other shapes will be blue with the texture gradient.
This choice was reported as an issue for discussion purposes