The most basic user expectation for any language “standard” is interoperability between tools.  BPMN 1.x, however, never provided a standard interchange format.  For years, WfMC filled that gap with XPDL, an XML format originally developed for interchanging process models between proprietary workflow tools.  With each new version of the BPMN spec, Robert Shapiro and, more recently, Denis Gagne, added XPDL support for BPMN elements added or changed.  But without a side agreement between tool A and tool B, model interchange between them was essentially impossible.  This was one of the problems BPMN 2.0 promised to fix, but OMG mostly dropped the ball.  Fortunately, in the Finalization phase, they defined three process modeling conformance subclasses – Descriptive, Analytic, and Common Executable – specific subsets of BPMN elements and attributes that could provide a practical basis for model interchange.  In principle, a tool could claim to be able to import and understand any model containing only elements and attributes in a certain subclass and valid per the BPMN 2.0 xsd.

That’s in principle.  In practice, it takes more than that.  As with XPDL interchange, schema validation is not enough.  You need two things in addition:

  • The model must follow the rules of BPMN, as spelled out in the specification.  A model can be schema-valid but violate the rules.  For example, a sequence flow connecting elements in separate pools is schema-valid but illegal.
  • The serialization must follow certain conventions not spelled out in the spec.  Some XML that is valid per the BPMN 2.0 schema and by the rules of the spec is nevertheless excluded from the class of interoperable models.

Such a combination of rules and conventions comprises a BPMN Interoperability (BPMN-I) profile, in analogy to WS-I profiles for web service interoperability.  Unlike WS-I, which deals with runtime interoperation of web service requesters and providers, BPMN-I deals with design-time interchange, but the basic idea is the same: in order for tools to interoperate, you need to restrict the allowed XML.  OMG does not want to provide BPMN-I profiles, so I have taken it on myself, but I welcome participation by others.  I have posted a draft version here, with emphasis on the non-executable profile.  Interchange of executable or semi-executable BPMN 2.0, conforming to the Common Executable subclass, is more involved, and tools even able to attempt it don’t exist yet.  I have also created an online validation tool that tests conformance to BPMN-I and reports violations of the rules and conventions, available here.

The BPMN-I validation tool is similar to the tools I created for “method and style” validation last summer.  However, “method and style” validation was about conventions that make the process logic easily understood from the diagram alone.  BPMN-I is about conventions that make the XML interoperable between tools.  Method and style is directed at users building process models.  BPMN-I is directed at tool vendors.

Both the BPMN-I “spec” and tool are draft versions, not quite complete and certainly buggy in spots.  I welcome all comments and criticism.