• XML Process Definition Language

XPDL Working group meeting, Feb 28 2005

Robert - opening remarks: BPMN was the driving reason for XPDL 2.0. Want to extend in such a way that 1.0 documents still work. But BPMN is high level and somewhat abstract, where XPDL is really more concrete.

Other driver is the number of things which have been discussed but never made it. For example BPMN has assignment statements, and this needs to be addressed in XPDL.

Final remark: BPMN does not discuss graphical attributes, such as X&Y coordinates. (Says XMI can offer this??) Lets not wait for XMI.

Time is important. There is an immediate need for a way to store BPMN. Other organizations are working on a solution of this problem, but assessment is that we should not wait for these; doing this now may positively influence the other solutions.

From Audience Issue of routing nodes. Spec says that routing nodes must not have side effect, but there are natural reasons that

Mike Marin: Purpose of BPMN is to visually represent processes, and communicate to humans. XPDL was loose in semantics because it was an interchange format.

Robert S: There are lot of details of BPMN that are not graphical.

Mike Marin: will be the editor of the new versions of the document.

Issue: Business process diagram can contain multiple separate top level processes

Sasa: not sure if there is a need for a "business process diagram" element or not. Other alternative is that the "package" maps to business process diagram.

Clearly there is a desire to have a single diagram that has multiple processes on it. The current proposal handles this by associating a package with a diagram, and multiple processes can be.

A "diagram" consists of multiple pages, each page is a physical representation separate from other pages. So, we need to talk about "pages".

Basically, if a given process needs to appear on two different pages, then you need to construct an "abstract" process which is composed only of "abstract" activities which are references to real activities. The real activity (or node) contains "view" attributes as well as "model" attributes, while the reference activity only has "view" attributes.

Discussion that we could separate the view from the model objects, and compose diagrams completely from view objects, which always refer to the model objects. But general agreement was that this unnecessarily complicates the easy cases, for some relatively uncommon complex cases. Decision to keep it simple for the simple cases.

Issue: complex gateways

Gateways are always activities. Need a new join type "complex" type