Assuring BPMN Interoperability

I've been working recently on tools to help BPMN 2.0 tool vendors more effectively interchange process models. (We're starting at absolute zero, so almost anything is an improvement.) In a way the work is similar to that previously reported re the rules of BPMN, but the earlier work was aimed at helping process modelers create diagrams that both conform to the rules of the BPMN spec and are easily understood from the diagram itself, what I call "style rules." I created an online tool that validates uploaded XML export from a tool that can serialize BPMN 2.0 properly (or nearly so), like Process Modeler for Visio from itp-commerce. The validation uses xslt 2.0 hosted on a separate website and accessed through an iframe. (The Altova engine only runs on Windows and is Linux. Bummer...) But the implementation displays the validation report in a popup window, so if the user is blocking popups it looks like nothing happened. Professional software puts up a little warning when that happens and lets you unblock, but mine... well, not so much. And I learned the hard way that most users don't really know about all the various popup blockers they have installed. So now itp-commerce just puts my rules directly inside their Visio add-in. Much easier for everyone. But I digress...

The new work is also xslt 2.0, using the same web infrastructure. Perhaps unlike the previous effort, here xslt is absolutely the right way to validate, because the artifact of interest is the XML itself. But here it's not about helping modelers create valid diagrams. It's really about helping tool vendors serialize BPMN properly. One of the tricky parts is linking the semantic model and the graphics information, which is in a separate block of XML. Each shape in the diagram (with location and size information) points to the id of a semantic element. Consider a simple diagram like this:

A diagram like this is admittedly bad practice, but whether it is "valid" or not depends on your tool. In the semantic model, if the start event is serialized under a separate default process element, then the model is invalid, since sequence flow cannot cross process boundaries. But if the tool put the start event under My Process, then it would not violate that rule. You might argue that a tool shouldn't ever do that, but the point is when a tool imports the XML output of another BPMN tool, there is no guarantee of what the exporting tool did. You need to be able to validate the XML directly for interoperability. And here I would say that even if the export fully conforms to the semantic rules of BPMN, this model should not be considered interoperable. That means an interoperability validation tool needs to test, in addition to the normal semantic rules of BPMN, rules that relate the semantic and graphics elements.

For example, the rule in question here might be something like this: In a diagram (i.e. page of the model), if a process is represented by a pool then all elements of that process on the page must be enclosed within the pool shape. In xslt this gets nasty because a pool shape doesn't point to a process directly. It points to a participant in a collaboration, and the participant points to a process. And once you get through that, you need to create a node-set of semantic elements belonging to that process, and from that create another node-set of corresponding shapes on the page, and then check if any of those shapes are drawn outside the pool. Relating a set of semantic elements to its corresponding shapes in xslt is nasty, trust me. You can't do it in xslt 1.0 but in xslt 2.0 you can, by caching node tree fragments in sequence variables. Anyway, it's slow going but it works.

A few tool vendors have expressed interest in this work, and once I am able to post the tool and interoperability profiles I think interest will pick up more.