WfMC Working Group 1 (XPDL) Meeting September 17, 2007

Agenda

• Discussion of XPDL 2.1 proposals on Wiki and any new proposals.See XPDL2.1Proposals in WIKI.
• URL to indicate a Remote Subprocess Node
• Coordinate Units for graphical information
• Direct in and Direct out
• Data Field Expose, set the level of trackable data, activities and processes
• icon for nodes
• read only data fields - fields set at the time the process is created, but can not be changed after that
• Simulation Results - a place to store sets of results of previous simulation runs or actual results from a BAM tool.
• Monitor Indicators - conditions on data that indicate to a BAM tool that an activity has started, or that it has ended.
• User Task Scripts & Activity Auditing
• constant data fields - set only at design time
• process and activiy viewers, other roles and relationships
• PackageRef External Ref
• Assigning IDs to Objects - specify whether ids are globally unique, unique to a file, or unique to that object category.
• 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.
• 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.
• Discussion of revisions required by BPMN 1.1.
• Discussion of conformance approach.
• Discussion of BPMN 2.0 rfp from OMG.

Notes from the meeting

• Meeting called to order 7:25 AM, Orlando Florida

• Discussion: how can we identify people for work.
• Mike Amend from BEA had multiple discussions with members about how important it is to extend XPDL to support all of the BPMN 1.1 capabilities. Proposal: as Mike to find someone to (1) make a pass through BPMN 1.1, and make a list of the changes that are relevant to XPDL, and (2) make some proposals to address those changes.
• We should engage non-members who have an intereste in XPDL. Who are they? How do we do it? (Wiki.) What do they need to do?
• Continue to use the Wiki for collection of these ideas.
• Release 2.1 contain, all existing extension proposals, extensions from conformance problems, and extensions necessary for BPMN 1.1.
• We need an XPDL implementer's list. These people should be involved at least in reviewing the proposed spec.
• Justin has desire to help on 12 extension proposals, and can probably have proposals in terms
• Are there people from BPMI who might want to work on this?

• The process for XPDL 2.1
• 2.0 was done by a small group of people going through a list of changes to schema, and submitted changes to the organization.
• Assume that the adoption meeting in early spring.
• September - now
• October - a list of things that need to be changed will be decided up at the Paris meeting. We may not have proposals for all these, but there should be a "cut" to determine what will be in the spec or not.
• November 15 - proposals for all the identified subjects.
• December 15 - draft spec for internal review
• January 15 - updated spec for public review
• February 20 - vote on adoption.

• Discussion points
• coordinate space and scaling
• multple graphical elements, tool id - Keith will make a "conformance profile" for this which outlines how Fujitsu, and others, use this.
• icons for activities
• are there other graphical elements that are needed? - Robert will look into this.
• BPMN has confusion about pools and lanes and processes. You can have an implied background pool, but can you have lanes on this. If there is an implied background pool, is there an implied background process.
• labels on arrows: nice if the spec had a definition on how to put the labels on the diagram.

• OMG RFP: there are some concern withing IBM about BPDM, and they indicated that IBM might NOT support BPDM development. IT is possible that they might support XPDL. They are now admitting that BPEL is not a solution to all problems. Might have something to do with acquisition of FileNet. If the OMG was to receive another RFP response, saying that XPDL was the serialization, what would happen? Normally, OMG asks the people representing the multiple responses to work together to make a common proposal. What about OASIS to give more legitimacy to XPDL? There is mire liklihood for success here. There are grave concerns that OMG will be a sink-hole for a tremendouns amount of man power, with no guarantee of success.

• Wf-XML and OGC opportunity: This is a tremendous opportunity. XPDL is doing well, but we do not want to be a one-trick pony. We need a follow-on act, and Wf-XML is a good way to do this.

• Origin: instead of having multiple origin points, the strong suggestion from TIBCO was that we simply pick top left as the origin, and everyone translates to/from this.
• Scale: similarly, we pick "pixels" as the default units, and a scaling factor is used to translate to/from pixels for those who do not support that.
• Parameters: this proposal is mature
• Data Fields: Justin will be looking into this.
• icons: proposal has been worked out, except for the actual format for the icon. Robert believes that the icon should be encoded idrectly in the XPDL som way, and that encoding needs to be specified.
• Simulation results seems like a large change, and maybe too much to do for the 2.1 release. We do not yet have a proposal. TIBCO might be interested in filling this in.
• Monitoring Indicators is in the same boat
• User Task Scripts & Activity Auditing has the script part fleshed out (still needs schema). The auditing part is realy activity state, and apparently TIBCO has a proposal for such activity states, or at least a set of events that an activity must generate. This is related to interface 5 work, and probably should be included in that work. Should break this into two proposals.

|Conference code: 01946e

Workflow Management Coalition, South San Jose Wiki