• XML Process Definition Language

Proposals for XPDL 2.1 Extension

|Please note: these are preliminary proposals for XPDL 2.1 which has not yet been adopted by the coalition. These items are for discussion of that proposed extension. These items may change substantially before adoption, or may possibly never be officially adopted in their current form.

Below are a list of proposed changes for version 2.1 of the XML Process Definition Language spec.

• Changes required for BPMN 1.1
• URL to indicate a Remote Subprocess Node
• Coordinate Units for graphical information
• Direct in and Direct out - Test Run (debug) and Simulation values
• Data Field Expose, set the level of trackable data, activities and processes
• read only data fields - fields set at the time the process is created, but can not be changed after that
• constant data fields - set only at design time ('InitialValue' element on DataField element is already there, so we do not need this)
• PackageRef External Ref - see Package
• Assigning IDs to Objects - At the October 11, 2007 meeting (Paris) we determined that all IDs for objects should be unique within a package (XPDL file). For the package external ref feature (above) the id must be qualified by a 'namespace' attributed to the external package so id-clash is avoided.
• Lane Performer attribute - Provides a standard place to define the 'role' associated with a lane. In effect every activity in the lane by default acquires the performer expression defined in the Lane attribute.
• Activity Cost Structure - new parameters for specifying cost of activity and resources.

Items we might consider in the future:

• Scripting Language
• start and end scripts - scripts that run at the time that an activity starts, and another set that runs as the activity completes.
• Activity Auditing - specify additional activity trace-auditing
• icon for nodes
• Monitor Indicators - conditions on data that indicate to a BAM tool that an activity has started, or that it has ended.
• User Task Scripts - define scripts to be run in user task client application environment.
• process and activity viewers, other roles and relationships
• application drop - (need a definition for what this is.)

Other Discussion Items

Empty Pools: an empty Pool is used in BPMN to show the interaction with an external service (process) and it doesn?t make sense (in our opinion) to bring such a Pool into an XPDL package that is used in a process engine. We could provide an option in the export form (if you insist) that allows it to also export empty pools but this will cause problems in execution environments (e.g. in Carnot) since processes without any flow do not make sense in an execution environment. Is this a reasonable conclusion? Or are empty pools an important part of XPDL definition to show the source or destination of messages? Is there any extensions needed for this?

Unique ID: In BPMN there is a unique id for each element In XPDL there is the activity element that has an id, then there is for example the task element beneath the activity element that also has an id and there is in addition also an Object element beneath the activity that also has an id. This means that some tool could export a task and create up to three different ids and names for the same element and it would still be valid XPDL ? but of course a big problem for a tool like PM that tries to do a roundtrip. Do we need a definition of how tools should handle this?

Performers: The XPDL activity element has a performer child element and also a performers child element (with any number of performer child elements). Some tools might import/export only to the performer element and others only to the performers element - this was actually one of the problems with one product.