BPMS Watch readers know I am a big fan of OMG’s Business Process Modeling Notation (BPMN) 2.0, which has passed its first approval hurdle and is now in the Finalization Task Force stage. A major reason is that for the first time, BPMN has standardized the schema for XML interchange of process models. That means you will be able to create a BPMN model in one tool with confidence you can open it in a different tool. I think that’s what every user expects from a “standard,” but BPMN never had it until v2.0. But there is one part of the standard that the team messed up big time: Diagram Interchange (DI), meaning the graphical layout of the shapes and symbols. Prior to BPMN 2.0, the de facto interchange format for BPMN models has been XPDL, an existing standard from the Workflow Management Coalition (WfMC) modified to handle BPMN. Each node in XPDL represents both an element in the BPMN semantic model and its corresponding visual element – including position, size, and other graphical details – in the diagram. But BPMN 2.0 separates the semantic model from its diagrammatic representation. That’s in a separate model – the DI model – that sits alongside the semantic model in the XML interchange document. That’s actually a good thing. It allows multiple diagrams (views, pages, etc.) to represent the same semantic element in different ways, such as different levels of detail. For example, if you have a hierarchical diagram of a complex process model, with a top-level view showing the entire process at very coarse-grained detail and many child-level views showing increasing levels of detail, BPMN 2.0 maintains a single consistent semantic model for the process, referenced by all the various views. That is good for maintaining the integrity of the model. In contrast, with XPDL each view of a particular model element represents a different XML element in the export, so if a subprocess or pool appears on multiple pages of the model, it is up to the tool – or the modeler – to maintain consistency between their definitions.
But OMG did not want to make DI, the graphical model, BPMN-specific. They wanted it to support other types of diagrams as well, particularly UML, something completely different but also owned by OMG. And they didn’t want to define the format in an XML schema document (XSD), the universal standard used by XML tools, SOA, and BPM. They wanted to define it in XMI (XML Model Interchange), OMG’s own standard for interchanging UML models. The problem with DI as specified in the BPMN 2.0 draft is that BPMN-specific diagram structure is not defined in a format usable by XML tools. Instead, it is defined in a separate “library,” which you could think of as a cheat sheet off to the side to remind you of the particular attributes allowed or required for BPMN-specific shapes.
If you think that is a strange way to define what is still nominally a notation (i.e. graphics) standard, you are not alone.
The problem is not that it is impossible to define a BPMN 2.0 model using the graphics as specified by DI, just that it will be too difficult to do so in practice. Unless you can represent DI as a true BPMN-specific schema, tool implementers cannot use the rich array of XML tools available to validate, transform, and test their XML exports. Graphical model interchange is difficult enough in XPDL, where the graphics come pre-attached to their semantic elements. A few BPMN 1.x tool vendors – ITP Commerce, Fujitsu, Global360, eClarus, TIBCO, BizAGI, and Lombardi – have achieved some level of BPMN interoperability using XPDL 2.1, but it requires tweaks to the XPDL using XSLT, the standard language for XML transformation. It would be extremely difficult to create those tweaks with DI – and they no doubt will still be needed with BPMN 2.0 – since tools that create, execute, and debug XSLT all need a proper schema. OMG needs to try again on the DI part.
It is no great feat to turn DI into a proper BPMN-specific schema. I did it myself (BpmnDi.xsd) in a few hours. I also created an XSLT that maps XPDL 2.1 to BPMN 2.0, using BpmnDi as the graphics model. If your BPMN tool outputs XPDL 2.1, you can try it out on your own models. [So far only the XPDL “standard”-level conformance is supported.] If you are interested in interoperability between BPMN tools, please make your sentiments known to OMG. These implementation “details” are what the FTF phase is all about.
