Issues for Business Process Model and Notation 2.1 Revision Task Force

To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

Issue 14223: Allow a Process to be Ad Hoc (in addition to a Sub-Process) (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Enhancement
Severity: Significant
Summary:

Currently only Sub-Processes can be Ad Hoc. However, it would be useful for Processes to be Ad Hoc also. This would allow libraries of Ad Hoc Processes to be defined and re-used

Resolution:
Revised Text:
Actions taken:
August 26, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue.  Disposition: Deferred

Issue 14242: Concept definition for Business Process (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Since you still have the concept definition for "Business Process" listed as "TBD" in the Glossary, PNA would like to propose the following definition:      Business Process:    A Business Process is a cooperation between several people and/or systems each performing a particular role and possible other entities such as departments within a company or organization, in order to produce a product or to deliver a service to a customer. Within BPMN a Business Process is described using a BPD.

Resolution:
Revised Text:
Actions taken:
September 2, 2009: received issue

Discussion:

This issue is a clarification/refinement of some basic and general concepts that do not have a direct impact on any implementation.  The FTF decides to defer this issue to the RTF to properly discuss and agree on this general term  Disposition: Deferred

Issue 14293: Page 046, Section 7.2, Message not listed as a BPMN element (bpmn2-rtf)

Click here for this issue's archive.
Source: Trisotech (Mr. Denis Gagne, dgagne(at)trisotech.com)
Nature: Uncategorized Issue
Severity:
Summary:

 Reported by [email protected], Jul 06, 2009    The Message element is not listed in any of the categories        Comment 1 by [email protected], Jul 10, 2009    The Message element is not listed in any of the BPMN element categories

Resolution:
Revised Text:
Actions taken:
September 2, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach resolution, so we will defer this issue.  Disposition: Deferred

Issue 14303: Depiction of diagram fragments (bpmn2-rtf)

Click here for this issue's archive.
Source: Trisotech (Mr. Denis Gagne, dgagne(at)trisotech.com)
Nature: Uncategorized Issue
Severity:
Summary:

 Reported by [email protected], Jul 08, 2009    The spec should prescribe how diagram fragments are presented.  (e.g.   three dots at end of continuing flows, ...)    Given that BPMN has very specific structural requirements, most diagram   fragments in the spec (and elsewhere) are not valid BPMN models.

Resolution:
Revised Text:
Actions taken:
September 2, 2009: received issue

Discussion:

The FTF agrees that a proper definition of diagram fragment is important, but we cannot reach agreement and apply such change in this FTF.  Consequently, we defer this issue to the RTF so it can define how to draw fragments and appy the definition to all relevant pictures.  Disposition: Deferred

Issue 14327: Page 070, section 8 list of Core elements (bpmn2-rtf)

Click here for this issue's archive.
Source: Trisotech (Mr. Denis Gagne, dgagne(at)trisotech.com)
Nature: Uncategorized Issue
Severity:
Summary:

 Reported by [email protected], Jul 29, 2009    The figure 8-1 indicates "Infrastructure, Common Elements, and Services".   Three Core sub-packages are listed in page 71 "Foundation, Service, and   Common".  Figure 8-2 shows "Foundation, Common, and Service".  Section 8.1 describes "Infrastructure", Section 8.2   describes "Foundation", Section 8.3 describes "Common Elements" and   Section 8.4 describes "Services".  The list of BPMN core elements indicated in thre first bullet of section   2.1.1   is: "Infrastructure, Foundation, Common, and Service packages."      Is there 3 or 4 sub-packages and should we use the same naming convention   within this section of the document?

Resolution:
Revised Text:
Actions taken:
September 4, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach resolution, so we will defer this issue.  Disposition: Deferred

Issue 14333: Page 251, Start Event on the boundary of a sub-process (bpmn2-rtf)

Click here for this issue's archive.
Source: Trisotech (Mr. Denis Gagne, dgagne(at)trisotech.com)
Nature: Uncategorized Issue
Severity:
Summary:

 Reported by [email protected], Jul 29, 2009    Is it still allowed to have Start and End Event on the boundary of an   expended Sub-process?     This was clearly stated and shown in BPMN 1.2. It is mentionned   at page 251, but no example are provided.    Is figure 7-8 page 69 valid?

Resolution:
Revised Text:
Actions taken:
September 4, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach resolution, so we will defer this issue.  Disposition: Deferred

Issue 14354: This is a style suggestion to make diagrams clearer (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

This is a style suggestion to make diagrams clearer.  The XOR gateway allows two forms of diagram: empty diamond, and a diamond with an X in it.  While redundancy is OK in general, the fact that different vendors make different choices. But an X and a cross look very similar.  While the X should be allowed, the spec should indicate that it is preferred to use the blank option, with the eye to eventually eliminating the X.

Resolution:
Revised Text:
Actions taken:
September 4, 2009: received issue

Discussion:

The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF/FTF.  Disposition: Deferred

Issue 14422: Add a User Event (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Enhancement
Severity: Significant
Summary:

There are many situations where a human involved in a process triggers an Event. The current set of Event types do not adequate reflect this situation. Thus, a new type of Event, a User Event, should be added to BPMN.

Resolution:
Revised Text:
Actions taken:
September 14, 2009: received issue

Discussion:

Defer. The FTF agrees that this is an issue that should be resolved, but did not agree on a resolution and deferred its resolution to a future RTF.  Disposition: Deferred

Issue 14538: Page 203, Table 10-26, The text describing the none and all behavior have been inverted (bpmn2-rtf)

Click here for this issue's archive.
Source: Trisotech (Mr. Denis Gagne, dgagne(at)trisotech.com)
Nature: Clarification
Severity: Minor
Summary:

Page  203, Table 10-26, The text describing the none and all behavior of the behavior attribute have been inverted.

Resolution:
Revised Text:
Actions taken:
October 8, 2009: received issue

Issue 14614: Example of Lane, Laneset, and Partitions (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Clarification
Severity: Significant
Summary:

Chapter 10.7 needs a more detailed example of how lanes can use process information/elements to partition flow objects

Resolution:
Revised Text:
Actions taken:
November 6, 2009: received issue

Discussion:

Examples are required but are non-normative, so we can defer.  Disposition: Deferred

Issue 14653: Message flow to/from events in Collaboration diagrams (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Send/receive events and tasks have the same meaning, but the  Collaboration section only shows message flow to/from tasks and other  activities.  Clarify that message flow can be attached to send/receive  events in Collaboration.

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach resolution, so we will defer this issue.  Disposition: Deferred

Issue 14656: Gateways in Choreography missing split or merge (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

The section on gateways in choreography covers splits (diverging)  gateways but not merges (converging) for parallel, exclusive.  Only  merges are covered for complex gateways.

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach resolution, so we will defer this issue.  Disposition: Deferred

Issue 14657: CorrelationClassDiagram missing conversation association end name (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Figure 8-18 (The Correlation Class Diagram) is missing the association  end name listed in Table 8-32 (CorrelationKey model associations).    Comments:  From: wstephe created: Fri, 24 Jul 2009 12:40:19 -0500 (CDT)  I was going to add an issue that would request to remove the conversation model association row from Table 8-32. The model association is uni-directional, so correlationKeys should appear in the Conversation table (11-1), but conversation should not appear in the CorrelationKey table (8-32).

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

Resolution:  The FTF Team is not able to allocate time to reach resolution, so we will defer this issue.

Issue 14661: PartnerRole underspecified and misnamed (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

PartnerRole does not specify the context of the role (is it a role in an  organization?). The examples given (a buyer, seller, or manufacturer)  could just be Participants, rather than PartnerRoles.  The term "role"  also conflicts with Participants, which are effectively roles in  Interactions.

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

Resolution:  The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF.

Issue 14663: Interactions supporting interactions (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

When a business commits to an interaction with potential business  partners, it might be that a particular partner needs only some of the  interaction.  This would be specified in another interaction diagram.  The modeler needs to link these two interactions to say one supports the  other, with the same semantics of the currently supports association,  except applied to messaging rather than activities.  The supports  association should be generalized to cover interactions

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

The beta specification currently enables abstraction in processes, but  not interactions, which is inconsistent and disables common interaction  use cases, for example as described in the issue. Resolving this  requires a modeler declaration indicating "runtime" message exchanges  between businesses following one interaction also follow another. This  means message exchanges can occur in reality that are not modeled in the  more abstract interaction model. The resolution would be very similar  to the same capability for processes, but requires explanation and  examples, which can be provided in RTF, and coordination with resolution  of 14686.  Disposition: Deferred

Issue 14666: Rules for exclusive gateway in choreography too strict (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Exclusive gateways in choreography are required to use decision data  accessible to all participants involved in the gatway.  But if if the  senders after gateway are the same, then receivers can use event  gateways or event subprocess to wait for event that might never come.  It isn't necessary for the receivers to have access to the decision  data.

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

The FTF agreed that there is a problem that needs fixing, but could not agree on a resolution and deferred its resolution to a future RTF  Disposition: Deferred

Issue 14667: Multiple senders after event-based gateway in choreography (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

About event-based gateways in choreography, the spec says:      [Event-based] Gateways are used in Choreography when the data used to    make the decision is only visible to the internal Processes of one    Participant.      On the right side of the Gateway [CB: I assume this means immediately    after]: either the senders MUST be the same; or the receivers MUST be    the same.    If the decision criteria is private to one participant, how can there  multiple senders after the gateway?

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

The FTF agreed that there is a problem that needs fixing, but could not agree on a resolution and deferred its resolution to a future RTF  Disposition: Deferred

Issue 14668: Event-based gateways in choreography should be exclusive (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

An event-based gateway implies a message is being waited for, but  choreographies can't receive messages, they have no central controller.  One of the participants will have an event-based gateway internally, but  the other will have a exclusive gateway. The choreography can use an  exclusive gateway with no conditions, with the semantics is that exactly  one of the following messages will be sent.    Comments:  From: conrad.bock created: Mon, 13 Jul 2009 15:53:49 -0500 (CDT)  Email from Frank about conditions on exclusive gateways in choreographies:    Hello Conrad,     In my opinion there is no need to even have data as decision criteria.  There may be a button, that a user presses (request xy..). Of course you  can discuss, that the fact, that a button has been pressed is in itself  data in the system. But it is a different kind of.     So in the case of two senders there are two users and two buttons.  Whoever presses first sends first.   Whoever sends second is in a different branch of the choreography.  That's how I understand it.

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach resolution, so we will defer this issue.  Disposition: Deferred

Issue 14669: Parallel Gateway participants (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Section 12.6.4 (Parallel Gateway) says "They create parallel paths of  the Choreography that all Participants are aware of."  Not all  participants, only those involved after the gateway.

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

The FTF agreed that there is a problem that needs fixing, but could not agree on a resolution and deferred its resolution to a future RTF  Disposition: Deferred

Issue 14673: Figure 11-4 description (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

The first sentence of the paragraph under Figure 11-4 (Conversational  view choreographies) refers to Figure 11-3, but is about Figure 11-4, as  far as I can tell.  How is the parent-child relation referred to at the  beginning of the paragraph reflected in the notation or metamodel?  It  says the Planned Order Variations as being keyed on Order Id, but the  figure shows it keyed on Variation ID also (compare to description of  Retailer Order and Delivery Variations Ack).  The paragraph refers to  Conversations instead of Communication.    The second paragraph under Figure 11-4 refers to Detailed Shipment  Schedule and Delivery Monitor, which aren't in Figure 11-3 or 4. The  paragraph refers to Conversations instead of Communication.    The third paragraph under Figure 11-4 refers to Delivery Planning and  Special Cover, which aren't in Figure 11-3 or 4.  It mentions messages  spawning conversations, which isn't described anywhere else.  The  paragraph refers to Conversations instead of Communication.

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

This issue is postponed for more discussion in RTF.  Disposition: Deferred

Issue 14674: Section 10.5.5 Complex Gateway: The general description of Complex Gateways needs improving (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Enhancement
Severity: Significant
Summary:

The general description of Complex Gateways needs improving. An example or two would be good.    Comments:  From: wstephe created: Sun, 13 Sep 2009 23:49:07 -0500 (CDT)  The version number was removed from the summary so that it will apply to the Beta 1 spec

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF/FTF.  Disposition: Deferred

Issue 14683: Beta 1 Section 15.1.2 Sub-Process Mappings: Table referenced is missing (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Revision
Severity: Minor
Summary:

Page 453. The first sentance of the section states:  "The following table displays the mapping of an embedded Sub-Process with Adhoc="False" to a WS-BPEL scope. (This extends the mappings that are defined for all Activities--see page 450):"    However, the table is not there.

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

Defer. The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF  Disposition: Deferred

Issue 14686: Exclusive gateway Choreography rules too restrictive, only sender needed (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Decisions are prevented from being used Choreographies if not all participants have access to the information on which the decision is made. But if the activities following the gateway are all sent by the same participant, only that participant needs to know how the decision is made. Using an event-based gateway in this case is confusing, since there is no waiting for events to proceed to the activities following it. Some sided email below about this. Steve, > The Gateway would most likely be Event based. The Buyer is > probably not going to be aware of the data that would be > used to make the decision, particularly a change order. > Thus, the Buyer is just going to be waiting for one of the > three responses. Makes sense for the buyer, but this isn't a model of the buyer (and the Seller is making a regular decision, why isn't that shown?). It's also odd to see an event-based gateway in a choreography since choreography can't don't wait for events, the participants do. The figure looks right according to the spec, but I think the spec is too restrictive on regular decisions in choreogrpahies. Conrad Steve, > The Seller is making a regular decision internally, but the > rationale (i.e., data) used to make the decision is private > for the Seller. A Choreography can only use Exclusive > Gateways if the data used for them is public. I understand that's the rule, but I'm not sure it make sense. In this case, the activities following the gateway are all initiated by the Seller. The rule should be that the seller has access to the decision data. > The Buyer does not know ahead of time, what the > results of the decision will be since the Buyer has not seen the > Seller's internal data. And that's fine, because it isn't the Buyer who initiates any of the activities after the gateway. > All private Exclusive Gateways show up as Event Gateways in a > Choreography. This is too hard to explain, for example, who receives the event? The choreography itself can't received an event, and there's no indication that it's the Buyer (other than they Buyer is receiving in the activities after the gateway). For FTF discussion. :) Conrad

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

This requires decisions with no conditions in a choreography, which  means the conditions are known privately to the sender of the activities  after the exclusive gateway, but not modeled in the "public"  choreography. This avoids event-based gateways in choreographies, which  cannot respond to events. These "abstract" choreographies are possible,  but requires more discussion in RTF in conjunction with 14663 [OMG  14663].  Disposition: Deferred

Issue 14698: Roles for Entities (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

There is no association between PartnerEntities and PartnerRoles, even  though entities will play roles.  The only link currently is through  participant, requiring modification of a C models to link a role or  entity, see <a href="http://www.osoa.org/jira/browse/BPMN-520">http://www.osoa.org/jira/browse/BPMN-520</a>.  An association  between partner entities and roles would enable collections of C models  to be grouped by roles, with roles reused by entities.

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

This is deferred for more discussion in the RTF, in conjunction with better specification of partner roles, see 14661.  Disposition: Deferred

Issue 14702: Beta 1: Section 17 BPMN Example: Include full BPMN example for this section (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Enhancement
Severity: Critical
Summary:

Section 17 will be temporarily removed until the BPMN example is added.     The section should have a full example with diagrams, XML, and supporting text.

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue.  Disposition: Deferred

Issue 14704: optional source and target refs for data association (bpmn2-rtf)

Click here for this issue's archive.
Source: Bruce Silver Associates (Mr. Bruce Silver, bruce(at)brsilver.com)
Nature: Revision
Severity: Critical
Summary:

dataOutputAssociation/@sourceRef should be optional, not required.  dataInputAssociation/@targetRef should be optional, not required.  This is to support non-executable models (<a href="http://www.osoa.org/jira/browse/BPMN-381" title="Abstract BPMN Profile"><strike>BPMN-381</strike></a>), since these elements are part of the data interface of the parent node, which is unspecified in non-executable models.  The other end of the association, the dataObject, is still required.    Comments:  From: [email protected] created: Thu, 14 May 2009 11:04:19 -0500 (CDT)  Counterproposal - Rather than making the source or target optional, instead 'lighten' the spec text.  The spec currently states that the source or target must be an ItemAwareElement.  In the case of non-executable models, the source or target may be the FlowElement itself.  So my proposal is to tweak the spec text, so as to allow this.

Resolution:
Revised Text:
Actions taken:
November 19, 2009: received issue

Discussion:

It was decided to wait until we have more user experience (i.e., complaints) about the issue. Thus we will defer the issue.  Disposition: Deferred

Issue 14709: Multiple processes per participant (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

From side discussion with Frank: A single public interaction  (choreography, collaboration, or conversation) might be supported by  multiple internal processes, but the current metamodel only allows one  process per participant.  The multiplicity should be widened to *.

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

It should be possible for a collaboration to require support of more  than one process in a participant. This is deferred for more discussion  in RTF on a solution.  Disposition: Deferred

Issue 14711: Beta 1 Section 15.1.2 Mapping to BPEL Activities: Message Mapping snippet refers to StructureDefinition (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Revision
Severity: Minor
Summary:

The figure for the mapping of Message to BPEL shows a snippet that includes a StructureDefinition element. The actual attribute for Message is structureRef, which points to ItemDefinition.  This figure should be updated.

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue.  Disposition: Deferred

Issue 14729: Add an example of Mutlple Start Events on the Boundary of a Sub-Process (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Enhancement
Severity: Significant
Summary:

Add an example of Mutlple Start Events on the Boundary of a Sub-Process as shown in an example for Issue 145 and described in the execution semantics section.  Section 10.2.5, Beta 1 spec

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF.  Disposition: Deferred

Issue 14730: Initializing and updating properties is not straight-forward (bpmn2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Matthias Kloppmann, matthias.kloppmann(at)de.ibm.com)
Nature: Revision
Severity: Minor
Summary:

From examples meeting on 2009.03.26:     When creating the looping example for <a href="http://www.osoa.org/jira/browse/BPMN-281" title="V0.5.6: Section 10.3 Data [Data]: Assignments not defined"><strike>BPMN-281</strike></a>, it is not obvious how to initialize properties. Also, updating a property via a dataInputAssociation or dataOutputAssociation is unnecessarily complicated because sourceRef and targetRef are currently mandatory elements, but not really applicable for properties.    Proposal:  (1) Introduce a new entity "initializationAssignment" (or better name) as a contained element for property (and data object for symmetry reasons), which has the same structure as assignment, but with an optional "to" element.  (2) Make dataInputAssociation::sourceRef and ::targetRef optional, likewise dataOutputAssociation::sourceRef and ::targetRef.    Comments:  From: trickovic created: Tue, 7 Apr 2009 04:00:15 -0500 (CDT)  As per 4/6 BPMN 2.0 meeting: Defer <a href="http://www.osoa.org/jira/browse/BPMN-471" title="Initializing and updating properties is not straight-forward">BPMN-471</a>.

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

This issue can be handled by an RTF.  Disposition: Deferred

Issue 14737: Exclusive Gateway Choreography Rule too Restrictive, starting new process (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Filed for Dale Moberg.  The rule illustrated by Figure 12-36  is that the  choreography activities after an exclusive gateway must have the same  receivers if the initiators are different.  However, the receivers can  be different if the activity starts a new process in the receiving  participant, or if the receiving participant has access to the data in  the decision from earlier in the flow.  Steve says the discussions so  far did not account for activites that start processes in the  participants.

Resolution: The beta specification does not seem to have the restriction for exclusive gateways cited in the issue, but the filer is correct that the choreography enforcability rules do not account for the possibility of starting new processes in receivers. The issue is deferred for more discussion in RTF. Disposition: Deferred
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

Comments:  From: conrad.bock created: Wed, 25 Feb 2009 10:17:41 -0600 (CST)  From Steve's minutes:    Dale also brought up a problem with the rule defined in the Text  Annotation in Figure 11-36. The rule is too restrictive. We need to  clarify. The rule applies for some cases, but not others. If all the  Ptps have seen a message with the appropriate data, then the rule could  be relaxed. Basically all internal processes would be using data  Decisions. Also, we didn't consider that a message could be the start of  an internal Process for one of the Participants? However, if the  receivers of the message (after the decision) didn't have access to the  data, but had been previous part of the process, then there would be a  problem. The internal process of those participants would be using an  Event Gateway, but the Choreography Process would not contain the time  out information for the internal process (so that it would not get  stuck).  Basically, we need to review the examples update how the rules  are specified.    From: conrad.bock created: Thu, 23 Jul 2009 08:45:57 -0500 (CDT)  Presumably this issue applies to inclusive gateways, because a similar  decision is made about which paths to split/merge.

Issue 14738: Notation for alternaitve data input/output sets (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

Notation for data input/output sets is missing.  I/O sets have a similar  execution effect as decision and merge gateways, so it seems like they  should be visible.    Comments:  From: wstephe created: Fri, 13 Mar 2009 13:50:54 -0500 (CDT)  The decision on this for BPMN 1.X  was that there would be no notation for this since it would probably be too complicated. There was a non-normative suggestion that inputs that belong in the same inputSet could be connected to the same point on the activity, but we didn't want to have anything like pins. I haven't seen any other suggestions. If we had something to look at, then we could consider.  But, in general, in probably should be deferred for now.

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach resolution, so we will defer this issue.  Disposition: Deferred

Issue 14741: Beta 1: Section 9.1 Collaboration: Expand description of Collaboration in section (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Enhancement
Severity: Significant
Summary:

The background text for the description of Collaboration is rather thin. Add more description and a figure or two.

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF.  Disposition: Deferred

Issue 14744: Beta 1: Section 10.2.4 Performer: Relate Performer to Human Performer (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Revision
Severity: Significant
Summary:

Mainly Editorial:    A HumanPerformer is a type of Performer, but there is no reference to this in the Performer section. There should be more description of how Performer can be used (e.g., through HumanPerformer).

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Issue 14745: Section 14.2.2 Activity (semantics): (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Enhancement
Severity: Critical
Summary:

Beta 1: Section 14.2.2 Activity (semantics): The state of a Data Object should be considered as a Performance Constrainst for an Activity Changing from the Ready to Active state    ##Source: IBM (Stephen A. White, [email protected])  ##Original Issue: http://www.osoa.org/jira/browse/BPMN-411  ##Original Info: (Severity: Critical - Nature: Enhancement)    The state of a Data Object should be considered as a Performance Constrainst for an Activity Changing from the Ready to Active state.    If a Data Object is not in the state defined as an input (e.g., "Approved"), then the InputSet should not yet be considered "available."

Resolution: - This is potentially a minor feature that would be suitable for an RTF. There are alternative methods for resolving this issue and the FTF did not come up with an agreement. Some resolutions would be out of scope for an RTF, but others would not. Thus, it should be deferred for further discussion by an RTF to determine it can be resolved or closed. Disposition: Deferred
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

Comments:  From: ings_osoa created: Tue, 10 Mar 2009 10:35:26 -0500 (CDT)  SAP believes that modeling of Data Object states is out of scope of BPMN 2.0. This is required if we want to introduce the state of Data Objects as a performance constraint.    Steve still thinks this is an interesting issue but he agrees to defer it as it will not be resolvable in the available time.     From: conrad.bock created: Tue, 10 Mar 2009 10:40:43 -0500 (CDT)  The spec already supports Data Object state, see Figure 10-46 (DataObject class diagram) in 0.9.7.    From: conrad.bock created: Tue, 10 Mar 2009 10:43:31 -0500 (CDT)  P.S. Since the specfalready supports Data Object state, it would be good to include it in the execution semantics.  The execution semantics description is very incomplete anyway and is critical to complete, see  <a href="http://www.osoa.org/jira/browse/BPMN-415">http://www.osoa.org/jira/browse/BPMN-415</a>.  I added a link.    From: hvo created: Mon, 16 Mar 2009 09:54:09 -0500 (CDT)  My state of knowledge is also that data object state is out of scope. It can be specified but it does not affect semantics. Data object state was never considered a "performance constraint" in in sense of Sect 13 so far.    From: hvo created: Wed, 18 Mar 2009 11:49:42 -0500 (CDT)  Steve, Conrad and me suggest to defer this issue.

Issue 14751: Beta 1: Section 10.2.2 Human Interactions: The Parameter class should be described (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Revision
Severity: Significant
Summary:

The Parameter class is an association of ProcessRole. Parameter has its own attributes. Thus, there should be a short subsection that describes Parameter, including a table that describes the attributes.   A general question: Parameter is a very generic name. Should this class be named something more specific?

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue.  Disposition: Deferred

Issue 14755: Beta 1: Section 10.1.2: Use of BPMN Common Elements [Process] -- Return removed TBD sections and complete text (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Revision
Severity: Critical
Summary:

Some sections with TBDs were removed for the Nov OMG posting. These sections should be returned and filled with content.   This section should match a parallel section in Chapter 11 (Choreography).

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF.  Disposition: Deferred

Issue 14756: Beta 1: Section 11.2: Use of BPMN Common Elements [Choreography] -- Return removed TBD sections and complete text (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Revision
Severity: Critical
Summary:

Some sections with TBDs were removed for the Nov OMG posting. These sections should be returned and filled with content.  This section should match a parallel section in Chapter 10 (Process).

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF.  Disposition: Deferred

Issue 14757: [Chroeography] Complete section 11.4: Events (bpmn2-rtf)

Click here for this issue's archive.
Source: Oracle (Dr. Martin Chapman, martin.chapman(at)oracle.com)
Nature: Revision
Severity: Critical
Summary:

Complete 11.4.1, 11.4.2, and 11.4.3 on choreogrpahy events.  Each sub-section may require more text, review and some example and pictures.        Comments:  From: trickovic created: Fri, 12 Dec 2008 06:37:38 -0600 (CST)  Issue assigned to Steve/the choreography team.

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue.  Disposition: Deferred

Issue 14759: Beta 1 Section 8.3.17 Sequence Flow and 14.2.1 Sequence Flow Considerations (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Enhancement
Severity: Significant
Summary:

Beta 1 Section 8.3.17 Sequence Flow and 14.2.1 Sequence Flow Considerations (Execution Semantics): Add Exclusive conditional behavior from activities    ##Source: IBM (Stephen A. White, [email protected])  ##Original Issue: http://www.osoa.org/jira/browse/BPMN-349  ##Original Info: (Severity: Significant - Nature: Enhancement)    Suggested by Michael Rowley: Add Exclusive conditional behavior from activities.    "Perhaps there should be a new variant of the minidiamond symbol to show that they are exclusive (filled in black, perhaps?).  For human activities, it would then be clear that the different flows are different choices that can be made by the user.  In B4P they would also be the "outcome" of the task."    This was discussed on a BLOG (<a href="http://kswenson.wordpress.com/2008/01/01/human-process-trouble-ticket/#comment-8886">http://kswenson.wordpress.com/2008/01/01/human-process-trouble-ticket/#comment-8886</a>)    Proposal TBD

Resolution: The FTF agrees that this issue deserves further discussion, and could not agree on a resolution and deferred its resolution to a future RTF Disposition: Deferred
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

Comments: From: wstephe created: Fri, 21 Nov 2008 17:43:58 -0600 (CST) Assigned to Hagen for now since there are execution semantics consequences of this feature. From: hvo created: Thu, 22 Jan 2009 09:11:32 -0600 (CST) Seems to be related to 145, at least for subprocesses, more precisely related to the discussion there whether we want to encapsulate alternative behavior in a subprocess and how we want to show that at the interface. From: bruce created: Sat, 24 Jan 2009 18:00:25 -0600 (CST) I don't think this is same as 145. This one uses normal semantics of subprocess completion. It is purely notational, and works the same regardless of the visual representation of the activity (unlike 145). Conditional sequence flow with the open diamond "implies" independent conditions (like OR gateway) but it "could" be used with exclusive conditions (like XOR gateway). This makes a clear distinction between the two forms of conditional sequence flow out of an activity. The downside is yet another graphic element. From: david_marston created: Sun, 25 Jan 2009 11:53:25 -0600 (CST) Maybe you just need to say that at a certain level of formality, explicit gateways are necessary. I think we don't want a mix of exclusive and inclusive minidiamonds, which would be the next requested feature once two kinds are allowed. If you are drawing the process for human consumption, be informal and show all exit conditions as inclusive (and use an annotation to state that formal rules exist, if that would ease your guilt). If you want a model that will compile into checkboxes and/or radio buttons, draw the necessary gateways. From: mariano.benitez created: Tue, 27 Jan 2009 12:37:28 -0600 (CST) I would really like to be able to define exclusive implicit gateways in the activity, this has been the behaviour of our product for the past 8 years and we never had a complain abou it. (This is just to express how much I like the idea, it is not an argument.) :) Now, I agree NOT to mix exclusive and inclusive minidiamonds. What I think is that the inclusive/exclusive behaviour is an attribute of the activity. The default SF out of the activity is actually an attribute of the activity itself, so we might well add another attribute "gateway behaviour" that would be inclusive or inclusive. Actually diamonds has nothing to do with the type of gateway they are flowing out from. I prefer an activity attribute that would rule for all conditional SF out of the activity. From: hvo created: Wed, 28 Jan 2009 02:30:27 -0600 (CST) Is there any reason why we would like to have this feature only on the output side but not on the input side? From: wstephe created: Wed, 28 Jan 2009 17:17:34 -0600 (CST) I understand Mariano's point of view on this issue. A few tool vendors involved in V1.0 had similar features and so the mini diamond was added. I would have preferred that ALL Sequence Flow control be handled by Gateways. Having both Gateways and mini diamonds is too much notation, in my opinion. BPMN is already dinged by people who say that it is too complex. I would not suggest that we remove the mini-diamonds, since they are legacy, but I would prefer that we don't add any more notation to V2.0 than we have to. I would recommend that we defer this issue. From: mariano.benitez created: Fri, 30 Jan 2009 08:21:32 -0600 (CST) I think multiple sequence flows in/out of activities is a reasonable shortcut that most of our customers use, it makes the visual diagram cleaner. Actually, in the case of multiple incoming sequence flows, it behaves like an exclusive gateway, different from the outgoing side. (see section 13.2.1) There is no reason why people would not want inclusive gateway semantics on the incoming side too. I don't think it is too much of a change to add 2 attributes that describe the incoming and outgoing behaviour, and it would make the semantics more consistent and flexible for users. So, I would recommend we open this issue with the proposal I just made. From: wstephe created: Fri, 25 Sep 2009 15:10:08 -0500 (CDT) Summary updated to match Beta 1 spec sections

Issue 14761: Section 14.4 [BPEL mapping] Missing intermediate send event; mapping of participant ref (bpmn2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Matthias Kloppmann, matthias.kloppmann(at)de.ibm.com)
Nature: Revision
Severity: Significant
Summary:

Type: Technical    Description of issue:  1. The spec misses the mapping for intermediate message send events  2. The spec misses a mapping for send/receive events and tasks where the other party is specified not by a service-ref, but by a message flow to another participant.    Proposal:  1. Include that mapping into spec (see Visio)  2. Introduce text describing how BPEL partnerLink is derived from either serviceRef or participantRef; use [serviceRef | participantRef] or similar notation as abbreviation.

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF.  Disposition: Deferred

Issue 14762: Provide example: Choreography (bpmn2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Matthias Kloppmann, matthias.kloppmann(at)de.ibm.com)
Nature: Enhancement
Severity: Significant
Summary:

Description of issue: Missing choreography example    Proposal: Add an example showing a choreography with several choreography activities, based on the existing example.    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF.  Disposition: Deferred

Issue 14763: Provide example: Conversation View (bpmn2-rtf)

Type: Example    Description of issue: Missing example for Conversation View.    Proposal: Add an example showing a conversation view.    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should     also be provided using BPMN notation.    Comments:  From: wstephe created: Mon, 1 Dec 2008 21:45:34 -0600 (CST)  An example has been started. It needs to be finished (including XML).    Also, we should use this issue to track the full text requirements for Section 9.5 "Conversations" (V0.9.1)

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF.  Disposition: Deferred

Issue 14764: Provide example: Complex gateway (bpmn2-rtf)

Description of issue: Missing example for complex gateway.    Proposal: Add an example showing a complex gateway.    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

This issue shall be addressed by providing an example. The FTF agreed to defer this issue to a future RTF, as examples are non-normative part of the specification.  Disposition: Deferred

Issue 14765: Provide example: Multi-instance activity (bpmn2-rtf)

Description of issue: Missing example for multi-instance activity.    Proposal: Add an example showing a multi-instance activities, including data assignments from a set of values to the individual parallel instances, and from the results of the parallel instances to a result set. This will require collaboration with the Data team.    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF.  Disposition: Deferred

Issue 14766: Provide example: Basic gateway examples (bpmn2-rtf)

Description of issue: Missing examples for basic gateways.    Proposal: Add three examples showing XOR, IOR and AND gateways.    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.    Comments:  From: mkloppmann created: Thu, 19 Feb 2009 12:31:13 -0600 (CST)  Per the 2009.02.19 examples sub-team meeting:  -- Medium priority  -- Combine with <a href="http://www.osoa.org/jira/browse/BPMN-310" title="Provide example: Basic process structure">BPMN-310</a>

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF.  Disposition: Deferred

Issue 14767: Provide example: Inline Subprocess (bpmn2-rtf)

Description of issue: Missing example for Inline Subprocess    Proposal: Add an example showing Inline Subprocess    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.    Comments:  From: mkloppmann created: Thu, 19 Feb 2009 12:33:25 -0600 (CST)  Per the 2009.02.19 examples sub-team meeting:  -- This item is related to <a href="http://www.osoa.org/jira/browse/BPMN-365" title="Notation for data flow in/out of a process">BPMN-365</a>

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF.  Disposition: Deferred

Issue 14769: Provide example: Basic process structure (bpmn2-rtf)

Description of issue: Missing example for process structure    Proposal: Add an example showing process structure.    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.      Comments:  From: mkloppmann created: Thu, 19 Feb 2009 12:30:43 -0600 (CST)  Per the 2009.02.19 examples sub-team meeting:  -- Medium priority  -- The example should contain activities, events, gateways  -- Combine with <a href="http://www.osoa.org/jira/browse/BPMN-316" title="Provide example: Basic gateway examples">BPMN-316</a>

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

Examples are useful but non-normative part of the specification. The FTF agreed to defer this issue to a future RTF.  Disposition: Deferred

Issue 14770: Beta 1 Spec: Section 14 BPEL Mapping: Better clarify the subset of BPMN diagrams that are BPEL-mappable (roundtrippable! (bpmn2-rtf)

Click here for this issue's archive.
Source: Bruce Silver Associates (Mr. Bruce Silver, bruce(at)brsilver.com)
Nature: Enhancement
Severity: Significant
Summary:

Better clarify the subset of BPMN diagrams that are BPEL-mappable (roundtrippable!)

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

Defer. The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF.  Disposition: Deferred

Issue 14771: Beta 1 Spec: Section 10.3 Data [Data]: (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Enhancement
Severity: Significant
Summary:

Beta 1 Spec: Section 10.3 Data [Data]: If start of an activity is guarded by availability of input data, there should be some visible indication of this in the diagram    ##Source: IBM (Stephen A. White, [email protected])  ##Original Issue: http://www.osoa.org/jira/browse/BPMN-302  ##Original Info: (Severity: Significant - Nature: Enhancement)    This is number 5 of 12 issues submitted by Bruce Silver    If start of an activity is guarded by availability of input data, there should be some visible indication of this in the diagram.  ("Modeling" means you don't need to see the non-diagram attributes).  It seems like BPMN 2.0 is trying to make data more a first class citizen, so this is needed.    Comments:  From: bruce created: Fri, 5 Dec 2008 17:29:56 -0600 (CST)  In a user task, it is understood that time can elapse between task ready and active, whereas in service task there is no delay.  So the temporal semantics are clear from the diagram.  The issue is when service task is guarded by data "availability" - whatever that implies.  If service task could incur delay between ready and active because of input data, this should be visible somehow in the diagram.

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

This is a request for a new graphical element. The FTF agreed to defer this issue to a future RTF.  Disposition: Deferred

Issue 14773: Beta 1 Spec: New Annex?: Enumerate the validation rules of BPMN (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Enhancement
Severity: Significant
Summary:

This is number 3 of 12 issues submitted by Bruce Silver    Enumerate the validation rules of BPMN.  Back in the old days when the BPDM guys kept saying BPMN 1.0 had no explicit rules or metamodel, you said it did but it was buried in the narrative.  Now you have an explicit metamodel but the rules are still buried in the narrative, and inconsistent from one part to the next.  Judging from v1.x it will take years to clean up the narrative, so just enumerate the rules in one place and say this overrides contrary info elsewhere in the narrative.

Resolution:
Revised Text:
Actions taken:
November 20, 2009: received issue

Discussion:

The FTF acknowledges the issue and thinks is a good idea to create a normative appendix with the validation rules.  Nevertheless, we think it is not possible to properly resolve the issue during the available time of the FTF. So the proposal is to defer it until the RTF, which can begin  as soon as the FTF completes the final report.  Disposition: Deferred

Issue 14774: Section 9 Collaboration [Choreography; Specification, Metamodel]: (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Enhancement
Severity: Significant
Summary:

Section 9 Collaboration [Choreography; Specification, Metamodel]: Clarify that a pool represents a single BPMN process, not a "participant" meaning role or business entity     ##Source: IBM (Stephen A. White, [email protected])  ##Original Issue: http://www.osoa.org/jira/browse/BPMN-299  ##Original Info: (Severity: Significant - Nature: Enhancement)    This is number 2 of 12 issues submitted by Bruce Silver    Clarify that a pool represents a single BPMN process, not a "participant" meaning role or business entity.  At least do this for a white box pool (aka private process); a black box pool (abstract process) is empty of activities, so its process is unknown and often labeled as role or business entity.  Also remove the language that multiple pools in a BPD are about B2B.  This is rarely the case.  Multiple white box pools in a BPD are used when the processes involved have independent lifetimes and cardinality, and almost always when both pools represent the same business entity not B2B.

Resolution: The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF/FTF. Disposition: Deferred
Revised Text:
Actions taken:
November 23, 2009: received issue

Discussion:

Comments:  From: bruce created: Fri, 5 Dec 2008 17:51:52 -0600 (CST)  I suspect I will not carry the day on this one.  I see there was language to this effect in early November and then deleted later.  Can we at least say that a pool may contain at most one process?    From: wstephe created: Tue, 15 Sep 2009 14:28:08 -0500 (CDT)  The section number was removed from the Summary to allow this to apply to the Beta 1 spec

Issue 14775: Throughout Spec [Specification]: Define explicit separation of "modeling" vs "implementation" attributes (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Enhancement
Severity: Significant
Summary:

This is number 1 of 12 issues submitted by Bruce Silver:    Define explicit separation of "modeling" vs "implementation" attributes.  The current "core" vs "extended" is nowhere close to this, since modeling needs much of the extended set.  Modeling is about orchestration of "abstract" activities, abstract meaning they have a name (label), task type, perhaps markers like loop/MI/adhoc, and unique id of course, but not implementation properties.  Abstract sequence flow has name, source and target refs; if conditional, the label is sufficient - you don't require a conditionExpression.  Message flow or message event does not require a message attribute, timer event does not require TimeDate or TimeCycle (please rename it to Duration) attribute, error event does not require an error code attribute, etc.  Those are for implementation; in modeling it's the diagram that counts, i.e. the label.

Resolution:
Revised Text:
Actions taken:
November 23, 2009: received issue

Discussion:

The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF.  Disposition: Deferred

Issue 14777: Correlation across conversations (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Critical
Summary:

The metamodel seems to be missing relations between the correlation  information in multiple conversations of the same collaboration /  choreography.  For example, in Figure 11.3 (Conversation diagram  depicting several conversations between Participants in a related  domain) how does the process internal to Consignee handling the  Consignee-Retailer conversation map its correlation information to the  correlation info in the Consignee-Supplier conversation?  Without this  the Consignee conversations with the Retailer and Supplier will be  uncoordinated.

Resolution: The issue points out that properties of correlation keys in different conversations might be intended to have the same runtime values, but this cannot be currently captured in the metamodel. For example, in Figure 11.3 of the beta specification, the conversation between Consignee and Supplier might use some of the same key properties as the conversation between Supplier and Shipper, and these might or might not be intended to have the same value, but the metamodel cannot capture which is intended. This issue is deferred to RTF for more discussion on how to address it. Disposition: Deferred
Revised Text:
Actions taken:
November 23, 2009: received issue

Discussion:

Comments: From: conrad.bock created: Mon, 27 Oct 2008 14:07:22 -0500 (CDT) Ivana said she will check with Alistar before opening this. From: conrad.bock created: Tue, 16 Dec 2008 10:58:54 -0600 (CST) Ivana said: Please check v0.9.2 and in particular the cardinality condition on conversation and correlation set. From: conrad.bock created: Tue, 16 Dec 2008 14:36:33 -0600 (CST) I see that conversations can have multiple correlation sets, but where is the mapping specified between them? For example, in Figure 9.13 of v0.9.2 (A Conversation Diagram example), the correlation information specified between Retailer and Consignee might need to be transformed to the correlation information between Consignee and Supplier. Where is that mapping specified? From: ings_osoa created: Wed, 14 Jan 2009 16:47:16 -0600 (CST) 288 open assign to Alistair, probably work in progress and/or already done, Alistair can determine which is the case From: alistair.barros created: Mon, 2 Feb 2009 23:36:44 -0600 (CST) Spec updates sent to Steve provide preliminary text to address this issue. technical discussions are currently taking place and final proposal will be produced as a result. From: conrad.bock created: Wed, 11 Feb 2009 09:18:29 -0600 (CST) Alistar, I couldn't find this addressed in the update posted on <a href="http://www.osoa.org/jira/browse/BPMN-253,">http://www.osoa.org/jira/browse/BPMN-253,</a> maybe I missed it. Since a conversation provides a multi-participant view, the message flows between two of the participants might contain information used for correlation with other participants. For example, in the conversation in Section 1.7 of your update, a message flow from Retailer and Consignee might have data to be used as correlation information between the Consignee and Supplier and back to the Retailer from the Supplier. This enables the Retailer to tell the message flows from the Supplier are apart of the overall interaction involving the Consignee. How are these relationships between the conversations captured in the metamodel? From: ings_osoa created: Fri, 6 Mar 2009 14:33:13 -0600 (CST) Deferring as per 3/5 choreo status call minutes.

Issue 14784: Define "Pool" (bpmn2-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Cory B. Casanave, cory-c(at)modeldriven.com)
Nature: Enhancement
Severity: Significant
Summary:

The term "pool" is used extensively in the specification yet the definition seems inconsistent and not tied to the meta model.  Sometimes a pool seems to be the role of a participant in a process context.  In other cases it seems to be the essential container of a process.  It seems to be a graphical element but shows up on ends of associations and in definitions of the semantics.  The term "pool" does not seem to have any semantic relevance to process.  Examples:  •	While a normal Process exists within a Pool, a Choreography exists between Pools (or Participants).  •	A Pool is the graphical representation of a Participant in a Collaboration (see page 235). It is also acts as a "swimlane" and a graphical container for partitioning a set of Activities from other Pools, usually in the context of B2B situations.  •	Nor can Sequence Flow cross a Pool boundary.  •	For message exchanges between pools, Conversations are used to group several Message Flow  •	A Participant is a specific business entity (e.g., a company) or a more general business role (e.g., a buyer, seller, or manufacturer) responsible for the execution of the Process enclosed in a Pool.    The semantics behind of pool should be clarified and the spec should not use graphical elements to define semantics.

Resolution: > The term "pool" is used extensively in the specification yet the definition seems inconsistent and not tied to the meta model. > It seems to be a graphical element but shows up on ends of associations and in definitions of the semantics. The term "pool" > does not seem to have any semantic relevance to process. The second paragraph of the Collaborations section explains that Pools are a notation for Participants. As a notation, they don't have a semantics by themselves, this is specified for Participant. Sometimes the term Pool is used interchangably with Participant, but this is in the informal way of referring to elements by their notation. One option might be to replace all uses of Pool with Participant. The relationship between participants and processes are the subject of issue 14709. > Sometimes a pool seems to be the role of a participant in a process context. In other cases it seems to be the essential container of a > process. This is the subject of issue 14774. > While a normal Process exists within a Pool, a Choreography exists between Pools (or Participants). > Nor can Sequence Flow cross a Pool boundary. > A Pool is the graphical representation of a Participant in a Collaboration (see page 235). It is also acts as a "swimlane" and a > graphical container for partitioning a set of Activities from other Pools, usually in the context of B2B situations. This is is currently a design decision taken in BPMN, that processes and interactions are separate. Can discuss more in RTF. > For message exchanges between pools, Conversations are used to group several Message Flow This follows from pools being a notation for participants in interactions. > A Participant is a specific business entity (e.g., a company) or a more general business role (e.g., a buyer, seller, or manufacturer) > responsible for the execution of the Process enclosed in a Pool. This is done with PartnerEntities or PartnerRoles linked to Participants. Participants can share the same PartnerEntity or PartnerRole. The issue is deferred for more discussion in RTF, in conjunction with issues 14709 Disposition: Deferred
Revised Text:
Actions taken:
November 23, 2009: received issue

Discussion:

Comments: From: bruce created: Fri, 5 Dec 2008 18:49:53 -0600 (CST) I agree w/Cory. Pool has fundamental semantics, unlike Lane which is purely notational. Sequence flow from start to end constrained within a pool. Message flow must connect two pools. A pool can contain at most one process (not counting subprocess activities within that process). Etc. For some reason BPMN refuses to say a pool is a container for a process. Instead it says a pool is a visual expression of a "participant" - role or entity - even though behind-the-firewall collaborations between pools representing the exact same role or entity are not uncommon. They are separate pools not because they represent different participants but because of their independent lifetime and cardinality. From: mariano.benitez created: Mon, 29 Dec 2008 13:29:47 -0600 (CST) Also in the XSD schema the conversation element has a unbounded reference to a "pool" element. The MM do not mention Pool, but it is defined in the XSD. From: bruce created: Tue, 27 Jan 2009 18:28:26 -0600 (CST) The MM element for pool should be process. A BPD (sorry, "collaboration diagram") with two collaborating processes representing the exact same role or business entity contains two pools interacting via message flows. Pool is a visual element, process is the MM element. The pool always exists but sometimes is invisible. So it is a Zen visual element. From: wstephe created: Tue, 27 Jan 2009 18:47:25 -0600 (CST) I don' think that a Process is the same as a Pool. For one, a Process can appear in more than one Pool. For example, WalMart could play two Roles in a Collaboration, occupying two Pools. Those two Pools could have different Processes, but those two Pools could actually use the same Process (if the Modeler chooses). The Pool, which we have been equating to Participant lately, may or may not reference (contain) a Process. From: mariano.benitez created: Fri, 30 Jan 2009 07:53:06 -0600 (CST) Steve, In your example: Could you describe how the MM would look like in both cases (same process in both pools and different processes)? Probably I don't fully understand Collaboration, but how does a sequence flow whose target is a pool woud relate to the real process? From: bruce created: Fri, 30 Jan 2009 12:04:01 -0600 (CST) Steve's example is enlightening, because it shows the problem is lack of clarity on what is a "process." To me, his example describes two processes, not one. A BPMN process is an orchestration, a continuous flow of control from start to end events via sequence flow. A "business process" may indeed have more than one BPMN process, perhaps even performed by the same participant (WalMart), acting in same role (or different roles) in multiple pools. The reason they are separate processes/pools is that 1) they have independent lifetimes; 2) they may have independent cardinality. In BPEL no one has trouble with this distinction. A business process is very often composed of multiple BPEL processes. Why is this not a single BPEL process? For many of the same reasons as in BPMN. The BPMN spec explicitly says a process is not a "thing" but a collection of things. I don't think this is consistent with BPMN 2.0 MM. If we can agree that a BPMN process is a thing, then I think the pool question will be simpler to resolve.

Issue 14786: Beta 1 - Section 14.3 [Execution Semantics]: Examples for the use of gateways are missing (bpmn2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Hagen Voelzer, hvo(at)zurich.ibm.com)
Nature: Revision
Severity: Minor
Summary:

The use of some gateways should be described by example, e.g. complex gateway, inclusive gateway, multiple instances

Resolution:
Revised Text:
Actions taken:
November 23, 2009: received issue

Discussion:

This issue shall be addressed by providing an example. The FTF agreed to defer this issue to a future RTF, as examples are non-normative part of the specification.  Disposition: Deferred

Issue 14788: Annex A {Spec]: Add a section that documents the changes between V1.1 and V2.0 (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Enhancement
Severity: Significant
Summary:

We need to document the changes from V1.1. For example, we removed two attributes from User Task, because the same functionality is being handled elsewhere. We need to document such changes to make it easier for the implementers that need to migrate.    Comments:  From: mariano.benitez created: Wed, 8 Oct 2008 15:57:52 -0500 (CDT)  We also dropped the concept of "streaming" data, so this should also be included in this section.  Assignments elements are also removed, converted to DataAssociations.    From: wstephe created: Sat, 12 Sep 2009 13:47:45 -0500 (CDT)  Spec Draft version removed to prepare for BPMN 2.0 FTF

Resolution:
Revised Text:
Actions taken:
November 23, 2009: received issue

Discussion:

This section is not normative, so like the examples, they can be completed by an RTF. And the FTF Team is not able to allocate time to reach proper resolution, so we  will defer this issue.  Disposition: Deferred

Issue 14790: Section 8.3.3 [Data] Inconsistency between usage of expressions in Sequence Flows and in Data Associations (bpmn2-rtf)

Click here for this issue's archive.
Source: Tekgensis (Mr. Mariano Benitez, mariano(at)benitez.nu)
Nature: Revision
Severity: Significant
Summary:

We have created some guards around the use of unavailable data in expressions of Data Associations.    The issue I am raising is about the use case when a conditional sequence flow uses an expression, and the data objects used in that expression are unassigned.

Resolution:
Revised Text:
Actions taken:
November 23, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue.  A proper resolution would include guards on each usage of expressions, including sequence flows, but also on loop characteristics, conditional events, etc.  Disposition: Deferred

Issue 14794: More description for "Process as a callable element" (bpmn2-rtf)

Click here for this issue's archive.
Source: Oracle (Mr. Vishal Saxena, nobody)
Nature: Revision
Severity: Significant
Summary:

##Source: Oracle (Vishal Saxena, [email protected])  ##Original Issue: http://www.osoa.org/jira/browse/BPMN-118  ##Original Info: (Severity: Minor - Nature: Revision)    On page 122 (152 in PDF) under fig 10-2 we describe process as a callable element. I think its a good idea to give small introduction.    Comments:  From: wstephe created: Fri, 11 Sep 2009 17:12:58 -0500 (CDT)  The page and section numbers were updated to match the Beta 1 spec

Resolution:
Revised Text:
Actions taken:
November 24, 2009: received issue

Discussion:

The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution. This is not an implementation issue so it is deferred to a future RTF.  Disposition: Deferred

Issue 14796: Section 10.2.3: Task description needs revisiting (bpmn2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Ms. Suzette Samoojh, ssamoojh(at)ca.ibm.com)
Nature: Revision
Severity: Minor
Summary:

Description of issue:  The description for Task needs revisiting   - States that "A Task is used when the work in the Process cannot be broken down to a finer level of details".  This doesn't reflect typical usage.  It's not that it cannot be broken down, but rather many users simply choose to not break down further.  Users model at the level of detail most appropriate for their needs and the needs of their audience.   - States that "Generally, an end-user and/or applications are used to perform the Task when it is executed".  What does this mean?  A black-box Task is traditionally used for documentation processes, where what the task does is more important than how (whether by an end-user or by an application) it is done.  If users know how it should be done then they would use a specialized task (i.e. User Task or Service Task) rather than Task    Proposal:  Reword to make it clear that Task has a purpose and usage in itself, beyond being a superclass for specialized tasks.

Resolution:
Revised Text:
Actions taken:
November 24, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue.  Disposition: Deferred

Issue 14800: Section 10.5 Text duplicated from 8.3.10 (bpmn2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Matthias Kloppmann, matthias.kloppmann(at)de.ibm.com)
Nature: Revision
Severity: Minor
Summary:

Description of issue: The first three paragraphs in section 8.4 are duplicates of the same paragraphs in 8.3.10 where gateways are introduced.    Proposal: Replace paragraphs in 10.5 by a short paragraph and a reference to 8.3.10's gateway section.

Resolution:
Revised Text:
Actions taken:
November 24, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue.  Disposition: Deferred

Issue 14802: Section 10.2 Clearer separation between conceptual and visual model needed (bpmn2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Matthias Kloppmann, matthias.kloppmann(at)de.ibm.com)
Nature: Revision
Severity: Minor
Summary:

Description of issue: This section mixes conceptual meta-model statements with visual representation statements. A clearer separation of those concepts is needed.  -- p 127 (157 in PDF) "... inclusion of re-usable tasks and processes in the diagram" should be "... invocation of re-usable tasks and other processes from the process"  -- p 127 (157 in PDF) "... a process is not a graphical object. Instead, it is a set of graphical objects." A process is neither, it is a container for activities and other entities, all of which have a graphical representation.  -- p. 133 (163 in PDF) ff "A task is a rounded corner rectangle" should be "A task is represented by a rounded corner rectangle". This occurs frequently for all task types, so globally change "is a rounded corner rectangle" to "is represented by a rounded corner rectangle"

Resolution:
Revised Text:
Actions taken:
November 24, 2009: received issue

Discussion:

This issue can be handled by and RTF.  Disposition: Deferred

Issue 14815: Link Events - Constraints and Usage not clearly documented (bpmn2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Ms. Suzette Samoojh, ssamoojh(at)ca.ibm.com)
Nature: Clarification
Severity: Minor
Summary:

The Sequence Flow constraints around the usage of Link Events are not clearly expressed in the spec.      Very simply, it should express that:   - A Catch Link Event should have no incoming Sequence Flow.   - A Throw Link Event should have no outgoing Sequence Flow.      Instead the spec has several rather confusing statements (pgs 235-236) that make it hard to infer the simple behavior I described above.  Statements like:  - If the Intermediate Event is used within normal flow:     - Intermediate Events MUST be the target of a Sequence Flow.  - An Intermediate Event MUST be a source for Sequence Flow.     - An exception to this: a source Link Intermediate Event (as defined below), it is not required to have an outgoing Sequence Flow.  - A Link Intermediate Event MUST NOT be both a target and a source of a Sequence Flow.    - A Link Intermediate Event MAY be the target (target Link) or a source (source Link) of a Sequence Flow, but MUST NOT be both a target and a source.      Recommendation:   - Tighten up and simplify the constraint descriptions for Link Events.   - Refrain from introducing new terms "source" and "target", or if the new terms are needed, clearly relate them to the existing "catch" and "throw" terms.

Resolution:
Revised Text:
Actions taken:
November 23, 2009: received issue

Discussion:

The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF/FTF.  Disposition: Deferred

Issue 14824: Continue versus terminate in loop (bpmn2-rtf)

Click here for this issue's archive.
Source: VDMbee (Mr. Henk de Man, hdman(at)vdmbee.com)
Nature: Enhancement
Severity: Significant
Summary:

Introduction of end type break within a loop construct (continue construct is already there, implemented by the terminate end type which can be used inside a loop (multi instance activity) to end the loop).�         This relates to what is e.g. said on page 407: �For a �terminate� End Event, the Sub-Process is abnormally terminated. In case of a multi-instance Activity, only the affected instance is terminated.�    So, differentation is required between the two modes of getting out of the loop.

Resolution:
Revised Text:
Actions taken:
November 25, 2009: received issue

Discussion:

The FTF Team is not able to allocate time to reach resolution, so we will defer this issue.  Disposition: Deferred

Issue 14831: A New Hook for Organizational Models? (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Revision
Severity: Significant
Summary:

The hook in BPMN for Resource Models is through the Resource class. Generally, Organization Models are considered separate from Resource Models, but there is not a separate hook for Organization Models in BPMN, the Resource class would have to be used for Organization models, which could be confusing.   The Resource class could be renamed to make it more generic, or a new class for Organization could be added.

Resolution:
Revised Text:
Actions taken:
December 2, 2009: received issue

Discussion:

This is a request for a new element. The FTF agreed to defer this issue to a future RTF.  Disposition: Deferred

Issue 14854: Add Brief Description for Error and Escalation Event Definitions (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Clarification
Severity: Significant
Summary:

The other Event Definitions have a brief description of what they are. The Error and Escalation do not have this description.

Resolution:
Revised Text:
Actions taken:
December 10, 2009: received issue

Discussion:

This issue is related to section 10.4.5 (Event Definitions)  Conditional, Error, and Escalation Events are properly described in other sections, so there is no lack of information.  Consequently, this issue will be deferred to the RTF to properly unify/correlate the descriptions in the different sections.  Disposition: Deferred

Issue 14876: UML interface operations do not match BPMN interface operations (bpmn2-rtf)

Click here for this issue's archive.
Source: Tekgensis (Mr. Mariano Benitez, mariano(at)benitez.nu)
Nature: Revision
Severity: Critical
Summary:

Currently interface operations in BPMN follow a "Document" model where all the arguments are wrapped in a single "Message" in and out of the operation.  But in UML, interface operations follow the "RPC" model, where arguments are independent and each one has the "In, Out, InOut" classifier.  This difference creates several problems when trying to relate/map BPMN and UML operations. Another side effect of the BPMN message model is that you cannot use simple data associations to fill the arguments of a service call. Since the operation is a single type, we have to use transformations to target the arguments (in my case we hide this complexity from the end user, and probably every vendor will do the same.      So, if the FTF wants to have a reasonable integration with SoaML, we should fix this issue. The proposal is to adopt the UML model, with separate arguments instead of a single document in and out.   We understand this is a major change, and a migration path from the Beta spec to the final one is a mandatory requirement.

Resolution:
Revised Text:
Actions taken:
December 17, 2009: received issue

Discussion:

The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF/FTF.  Disposition: Deferred

Issue 14879: The spec should clearly state what visual features are available for extensions and which are restricted to core spec (bpmn2-rtf)

Click here for this issue's archive.
Source: Tekgensis (Mr. Mariano Benitez, mariano(at)benitez.nu)
Nature: Clarification
Severity: Minor
Summary:

Right now there is no clear separation on which graphical features (like line thickness, type of lines, color, etc) vendors are free to use as extensions, and which are restricted for the specification to use.      We should define which features we want to use in the spec and which ones vendors are free to use. The reason for this is that if a vendor chooses line thickness for some visual extension and in a revision we choose to use the same feature, the vendor is forced to change to adapt (most importantly end-users).    For example: it is clear that color is open for vendor extensions, and we should pick lines (thickness, dotted, etc) as restricted for our use.

Resolution:
Revised Text:
Actions taken:
December 17, 2009: received issue

Discussion:

It would be important for the spec to clearly specify the limits where graphical extensions can be added, and what is exclusive to the specification. It is not important  right now, but I think we need to fix this. specially looking forward. So I propose to defer the issue.  Disposition: Deferred

Issue 15007: How to represent Activities that might fit in more than one Lane? (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Clarification
Severity: Significant
Summary:

Some activities (or other elements) may have properties that would allow them to be placed in more than one lane. For example, a Task could be assigned multiple resources. Is there a way to display the activity in multiple lanes? If not, how is would the most appropriate lane be chosen?

Resolution:
Revised Text:
Actions taken:
January 28, 2010: received issue

Discussion:

The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF/FTF.  Disposition: Deferred

Issue 15030: Ambiguous statements about Sequence Flow (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Clarification
Severity: Minor
Summary:

In section 10.4.1, Event Concepts, (page 211 -241 PDF) there are some confusing statements about Sequence Flow. For example, one statement reads: "The Data Association for a Throw Event is performed when the Sequence Flow arrives at the Throw Event."  Sequence Flow do not "arrive" in this context. The statements should be revised to refer to Tokens arriving at the Events to make consistent with the rest of the specification

Resolution:
Revised Text:
Actions taken:
February 3, 2010: received issue

Discussion:

The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue.  Disposition: Deferred

Issue 15043: Multi-language labels for diagram elements (bpmn2-rtf)

Click here for this issue's archive.
Source: Signavio GmbH (Dr. Gero Decker, gero.decker(at)signavio.com)
Nature: Enhancement
Severity: Significant
Summary:

Most diagram elements carry a text label. The current version of the spec only allows to specify one string that is used as label.    Multi-national companies often document their business processes in multiple languages (English, German, Spanish..). BPMN should therefore allow to set multiple labels per element (+ default language for the diagram)

Resolution:
Revised Text:
Actions taken:
February 9, 2010: received issue

Discussion:

The FTF Team is not able to allocate time to reach proper resolution, so we will defer this issue.  Disposition: Deferred

Issue 15054: Redundancy in specifying data in processes (bpmn2-rtf)

Click here for this issue's archive.
Source: International Business Machines (Prof. Dr. Frank Leymann, nobody)
Nature: Clarification
Severity: Significant
Summary:

There is an obvious redundancy in defining data in BPMN 2.0 (data objects, item definitions, messages, import of schema,...). The current spec does not say what is mandatory to be specified in which situation. At least the most common scenarios should clarified in the spec, e.g. what must be specified in case a WSDL doc is already available and the message described in this document should be used by a service task; or what must be specified in case in incoming message (by a start event) should be copied to a data object.    I submitted a comprehensive document describing the situation to the [email protected] address, whithout any reaction since weeks.  I am happy to send this document to the one assigned to this issue and discuss it.

Resolution:
Revised Text:
Actions taken:
February 17, 2010: received issue

Discussion:

This issue shall be addressed by providing an example. The FTF agreed to defer this issue to a future RTF, as examples are non-normative part of the specification.  Disposition: Deferred

Issue 15065: definitionalCollaborationRef should be 0..* (bpmn2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Table 10.1, definitionalCollaborationRef includes the phrase �For Processes that interact with other Participants,� which implies that Processes *are* Participants. In fact they are distinct elements in the metamodel.     More significantly it states �The definitional Collaboration specifies the Participants the Process interacts with, and more specifically, which individual service, Send or Receive Task, or Message Event, is connected to which Participant through Message Flow.� However a Process could be linked to Participants in many Collaborations and so the multiplicity of [0..1] seems over-limiting.

Resolution:
Revised Text:
Actions taken:
February 18, 2010: received issue

Discussion:

The same process can appear in multiple collaborations, and must be  consistent with all them, so it is unclear why definitional  collaboration are any different the others a process appears in. One  possibility is to limit correlation to the definitional collaboration.  If processes can have multiple definitional collaborations, it needs to  be decided which applies when the process is called.  This is deferred for more discussion in RTF.  Disposition: Deferred

Issue 15066: Notation for expanded hexagons (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Filed for soaML: When multiple hexagons (conversation/communication) are  expanded, it isn't possible to tell which message flows go with which  hexagons, because the hexagons disappear.  Should have a grouping  notation to show which message flow came from expanding which hexagons.

Resolution:
Revised Text:
Actions taken:
February 18, 2010: received issue

Discussion:

This is deferred for more discussion on a notation for this.  Disposition: Deferred

Issue 15070: Notation for shared correlation properties (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Filed for Alistar: Conversations / communications sharing correlation  properties should be linked graphically.

Resolution:
Revised Text:
Actions taken:
February 18, 2010: received issue

Discussion:

This is a request for a new graphical element. The FTF agreed to defer this issue to a future RTF.  Disposition: Deferred

Issue 15071: Enforcability rules not complete (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary:

Filed for Alistar: Enforcability rules not complete.

Resolution:
Revised Text:
Actions taken:
February 18, 2010: received issue

Discussion:

The FTF agreed that there is a problem that needs fixing, but could not agree on a resolution and deferred its resolution to a future RTF  Disposition: Deferred

Issue 15101: Integrate temporal and token semantics (bpmn2-rtf)

Click here for this issue's archive.
Source: Agile Enterprise Design (Mr. Fred A. Cummins, fred.a.cummins(at)gmail.com)
Nature: Clarification
Severity: Significant
Summary:

BPMN uses temporal semantics currently in process abstraction, and token flow in process execution.  It isn't currently clear which semantics should be used for what purposes, or if they are compatible. Temporal semantics should be highlighted as one of the semantics for sequence flow, especially in conjunction with definitional collaborations, and it should be related to the token semantics.

Resolution:
Revised Text:
Actions taken:
March 1, 2010: received issue

Discussion:

This can be addressed in an RTF by clarifying the relationship between  temporal and token semantics.  Disposition: Deferred

Issue 15121: Rethink implementation attribute in Send/Receive/Service Tasks (bpmn2-rtf)

Click here for this issue's archive.
Source: Intalio, Inc. (Mr. Tammo van Lessen, tammo(at)intalio.com)
Nature: Clarification
Severity: Significant
Summary:

Currently, send/receive/service/user/business rule tasks have an "implementation" attribute. Based on the information in the spec and from the process orchestration subgroup call, this attribute shall identify the technology to be used for interaction. This can be Web Service, WS-HT or any other protocol/coordination protocol.      While this makes sense for human tasks and business rule tasks, there are a couple of inconsistencies with Send/Receive/Service tasks. Here is why:      - Receive Task has an implementation attribute, a message event has not.  - A Receive Task and a subsequent Send Task that deal with messages defined within the same operation may have different values for the implementation attribute. This is however probably not intended.      My proposed resolution is to remove the implementation attributes for send/receive/service tasks. We should discuss whether this information is really needed or whether it could be inferred by the implementationRef of the interface/operation tuple. The information might be needed to determine in which technology an interface/operation is implemented. See also http://www.osoa.org/jira/browse/BPMNFTF-519#action_15739    As an alternative, MessageEventDefinition would need such an attribute as well.

Resolution:
Revised Text:
Actions taken:
March 8, 2010: received issue

Discussion:

The FTF agrees that there is a problem that needs fixing, but did not agree on a resolution and deferred its resolution to a future RTF/FTF.  Disposition: Deferred

Issue 15158: Lists of values (bpmn2-rtf)

Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Clarification
Severity: Minor
Summary:

The word "list" is used a fair amount in describing attributes and model  associations.  I think these are intended to be sets in most cases,  rather than lists (no ordering, no duplicates).  In UML, the default is  sets, you need to add "{ordered}" "{non-unique}" to get lists.

Resolution:
Revised Text:
Actions taken:
April 5, 2010: received issue

Discussion:

This is a problem in the specification, but was noticed too late to  address in the FTF.  Disposition: Deferred

Issue 15159: Choreography activities sharing message flow (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Clarification
Severity: Minor
Summary:

The spec allows multiple choreography activities to share the same  message flow.  Is that intended?

Resolution:
Revised Text:
Actions taken:
April 5, 2010: received issue

Issue 15171: Messages and User Tasks (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Clarification
Severity: Significant
Summary:

It is possible that User Tasks may send and/or receive messages. Thus, the mechanisms built into Send, Receive, and Service Tasks should also apply to User Tasks.  Also, Message Flow can connect to any Task. Thus, there should be some restrictions on this or messaging should be applied at the Task level instead of the individual sub-types

Resolution:
Revised Text:
Actions taken:
April 9, 2010: received issue

Issue 15217: Add Link Events to a sub-conformance level (Descriptive) (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Clarification
Severity: Minor
Summary:

There is a proposal to add conformance levels to BPMN 2.0. The proposal for a Descriptive level should include Link Events.

Resolution:
Revised Text:
Actions taken:
April 21, 2010: received issue

Issue 15253: Data associations need to be revisited and their use clarified. (bpmn2-rtf)

Click here for this issue's archive.
Source: Trisotech (Mr. Denis Gagne, dgagne(at)trisotech.com)
Nature: Revision
Severity: Significant
Summary:

Data associations need to be revisited and their use clarified.      Data association should have there own visual depiction.  Using the look of association is misleading as data associations have a different meaning than associations.      A data association is an edge between flow elements (data objects(ref) and data stores(ref))as such they should not cross boundaries of pools or can they?  This is not clear.  It is also not clear if data objects(ref) and data stores (ref) can be drwan outside lanesets or pools.

Resolution:
Revised Text:
Actions taken:
May 13, 2010: received issue

Issue 15255: Define rules for placement of multiple activity markers (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Clarification
Severity: Minor
Summary:

A Task or Sub-Process may have multiple markers (e.g., looping, compensation, etc.). But the spec does not explicitly define how the markers should be ordered. The examples in the spec are not consistent in how they are presented.

Resolution:
Revised Text:
Actions taken:
May 17, 2010: received issue

Issue 15256: CorrelationSubscription Ownership - Sub Process (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

Currently only Processes can 'own' Correlation Subscriptions. However, also Sub Processes should be able to define and own Correlation Subscriptions.      Use case: restrict the lifecycle of the correlation subscription to the sub process only (as opposed to activating the subscription for the entire lifecycle of the process. This is particularly required in the case of long running processes.      Proposed resolution:  Figure 10.29- The Sub-Process class diagram   Table 10.20 - Sub-Process attributes   Table 10.48 - SubProcess XML schema   > ADD attribute correlationSubscriptions:CorrelationSubscription [0..*] to class Sub-Process

Resolution:
Revised Text:
Actions taken:
May 17, 2010: received issue

Issue 15284: Clarify Relationship between Collabration Message Flow and Choreography Tasks (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Clarification
Severity: Minor
Summary:

When a Choreography is included in a Collaboration, the spec says that Message Flow can be "wired up" to Choreography Tasks. This needs to be defined better. Are the objects connected or overlapping? What if the Choreography Task moves, etc.

Resolution:
Revised Text:
Actions taken:
June 8, 2010: received issue

Issue 15374: Inconsistency between Boundary Event attribute names in Table 10.91 and Table 10.102 (bpmn2-rtf)

Click here for this issue's archive.
Source: Camunda Services GmbH (Mr. Falko Menge, falko.menge(at)camunda.com)
Nature: Revision
Severity: Minor
Summary:

The Boundary Event XML schema in Table 10.102 on page 292 (322) defines an attribute called 'attachedToRef', whereas Table 10.91 on page 268 (298) lists an attribute with the name 'attachedTo'.      Proposal:  Replace 'attachedTo' with 'attachedToRef' in Table 10.91.

Resolution:
Revised Text:
Actions taken:
July 14, 2010: received issue

Issue 15375: Event Sub-Process only in Sub-Processes? (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Chapter 12.2.5 defines on page 178 (208 pdf)  'An Event Sub-Process is a specialized Sub-Process that is used within a Process (or Sub-Process)'       Chapter 13.4.4 defines on Page 452 (482 pdf)  'Event Sub-Processes allow to handle an Event within the context of a given Sub-Processes or Process.'      The second paragraph of Chapter 13.4.4 specify the cancel/parallel execution of the enclosing Sub-Process. If the Parent Process is not a Sub-Process but a Process, there is no definition.      Solution:  Replace in the second paragraph 'enclosing Sub-Process' with 'Parent Process' (2x).

Resolution:
Revised Text:
Actions taken:
July 15, 2010: received issue

Discussion:

Issue 15385: Incorrect reference in loopcharacteristics class diagram (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In the loopcharacteristics class diagram (figure 10.45) there are two references between StandardLoopCharacteristics and Expression. The one named 'loopMaximum' is not correct. LoopMaximum is an integer and is an attribute of StandardLoopCharacteristics (see table 10.28)

Resolution:
Revised Text:
Actions taken:
July 28, 2010: received issue

Issue 15386: Replace "process" attribute of a laneSet with "flowElementsContainer"? (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In BPMN2.0 beta1 LaneSet had a relationship with Process. This was changed in beta 2 and now LaneSet has a relationship with FlowElementsContainer, with the exception of Choreographies or Sub-Choreographies (see Figure 10.126 - The Lane class diagram ). In Table 10.134 � LaneSet attributes and model associations (of BETA2 document ) I see that there is a process attribute described as "the process owing the Lane set". Shouldn�t there be a "flowElementsContainer" attribute (as the LaneSet can be owned by a Sub-Process too) instead of the "process" attribute?

Resolution:
Revised Text:
Actions taken:
July 29, 2010: received issue

Issue 15388: Ambiguous statement about DataObjects and DataObjectReference (bpmn2-rtf)

Click here for this issue's archive.
Source: Rosch Consulting (Mrs. Cristina Conrad, nobody)
Nature: Clarification
Severity: Minor
Summary:

In section 10.3.1 there are some confusing statements about DataObjects and DataObjectReference. One statement reads "Data Object Reference cannot specify item definitions, and Data Objects cannot specify states." (page 215) and on the next page there is another statement that reads "Data Object elements can optionally reference a DataState element, which is the state of the data contained in the Data Object (see an example of DataStates used for Data Objects in Figure 7.8)." Can then DataObjects reference a state? Or is the "state" in the first sentence a different kind of state?      Furthermore the schema (https://www.omg.org/spec/BPMN/2.0/20100501/Semantic.xsd) specifies that the DataOjectReference may have a reference to the item definition:  <xsd:element name="dataObjectReference" type="tDataObjectReference" substitutionGroup="flowElement" />   <xsd:complexType name="tDataObjectReference">  <xsd:complexContent>  <xsd:extension base="tFlowElement">  <xsd:sequence>  <xsd:element ref="dataState" minOccurs="0" maxOccurs="1" />   </xsd:sequence>  <xsd:attribute name="itemSubjectRef" type="xsd:QName" />   <xsd:attribute name="dataObjectRef" type="xsd:IDREF" />   </xsd:extension>  </xsd:complexContent>  </xsd:complexType>      And that the DataObject may have a state:  <xsd:element name="dataObject" type="tDataObject" substitutionGroup="flowElement" />   <xsd:complexType name="tDataObject">  <xsd:complexContent>  <xsd:extension base="tFlowElement">  <xsd:sequence>  <xsd:element ref="dataState" minOccurs="0" maxOccurs="1" />   </xsd:sequence>  <xsd:attribute name="itemSubjectRef" type="xsd:QName" />   <xsd:attribute name="isCollection" type="xsd:boolean" default="false" />   </xsd:extension>  </xsd:complexContent>  </xsd:complexType>

Resolution:
Revised Text:
Actions taken:
July 30, 2010: received issue

Issue 15389: XML Schema for dataObjectReference and dataStoreReference are missing (bpmn2-rtf)

Click here for this issue's archive.
Source: Rosch Consulting (Mrs. Cristina Conrad, nobody)
Nature: Clarification
Severity: Minor
Summary:

Schema for dataObjectReference and dataStoreReference is missing from chapter 10.3.4 XML Schema for Data

Resolution:
Revised Text:
Actions taken:
July 30, 2010: received issue

Issue 15393: Activity as InteractionNode (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Depicted in the table 7.4 on page 44 and documented on page 124 message flow is allowed from and to activities, but in the meta-model on page 123 only Tasks are InteractionNodes and not activities.

Resolution:
Revised Text:
Actions taken:
August 3, 2010: received issue

Issue 15396: Incorrect N-to-N relationships in participants class diagram (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The "Participant attributes and model associations" on page 119 state that a Participant can play 0 or 1 PartnerRole and/or 0 or 1 PartnerEntity. The class diagram on page 118 however displayes an N-to-N relationship between Participant and PartnerRole/PartnerEntity. This is not correct.

Resolution:
Revised Text:
Actions taken:
August 4, 2010: received issue

Issue 15407: Figure 10.98 needs Updating (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Revision
Severity: Significant
Summary:

Figure 10.98 shows an Event Gateway that initiates a process, but the Gateway marker is incorrect. The marker needs to be updated to that of a multiple Start Event rather than a multiple Intermediate Event.

Resolution:
Revised Text:
Actions taken:
August 6, 2010: received issue

Issue 15408: Typo: "Interrupting" should be "Non-Interrupting" (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Revision
Severity: Minor
Summary:

The first sentence of the subsection "Non-interrupting Event Handlers (Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)" starts out: "Interrupting Event Handlers are those..."  The text should be: "Non-Interrupting Event Handlers are those..."

Resolution:
Revised Text:
Actions taken:
August 6, 2010: received issue

Issue 15414: How many source are allowed for data association? (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In the text on page 228 it says "Data association elements have one or more sources and a target", but in the meta-model in figure 10.64 the association is marked as "*" meaning it is also possible to have 0 sources. As well as in table 10.63: "sourceRef:ItemAwareElement [0..*]".     It is not clear how many sources of a data association are allowed now.

Resolution:
Revised Text:
Actions taken:
August 12, 2010: received issue

Issue 15415: Cardinality of sources for Data Association (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Throughout the text it is stated that a data association has one or more sources and one target (see page 228). First of all, if that is true the meta-model should be adjusted on page 229, figure 10.64. Taking "*" as cardinality for sources of a data association would allow a data association to exist without any source. I suggest to change the cardinality to "1..*".    Second, in the description I couldn't find any example explaining for which cases more than one source in a data association makes sense. Is it allowed because a data object can be collection?

Resolution:
Revised Text:
Actions taken:
August 13, 2010: received issue

Issue 15422: Unclear and incorrect specification of Expressions and Formal Expressions (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

The use of expression and formalexpression is unclear. The description of 'Expression' states: 'The Expression class is used to specify an Expression using natural-language text. These Expressions are not executable and are considered underspecified '. However, table 8.1 states about 'expressionLanguage': 'This attribute identifies the formal Expression language used in Expressions within the elements of this Definition'. I guess this should be ' This attribute identifies the formal Expression language used in Formal Expressions'.   Then there are several places where an 'expression' can be entered and not a 'formal expression'. For example table 10.64: assignment attributes. The 'from' and 'to' both are an 'Expression'. Just above the table it says: "The default Expression language for all Expressions is specified in the Definitions element, using the expressionLanguage attribute. It can also be overridden on each individual Assignment using the same attribute". Since the 'from' and 'to' fields are 'Expressions' and not 'Formal Expressions', it is not possible to specify the expressionLanguage. The expression class cleary states it used to specify using "natural-language".  There are more places where a FormalExpression might be a better choice. Like the conditionExpression of a sequence flow. Since it is an 'Expression' it can only containt the condition in natural language. Venders will need to add vendor specific extension elements to contain the formal expression.  FormalExpressions are a subclass of Expressions. Maybe it is the intention that FormalExpressions can be used whereever expressions can be used. However, the xsd clearly forbids this (as noticed already by Mr Denis Gagne in issue 14433)  Finally, the description of 'Expression' states: "The natural language text is captured using the documentation attribute, inherited from BaseElement". In example xml in the document, like in Table 10.19, expressions are just put in the body of the expression:              <sequenceFlow sourceRef="OrderApprovedDecision" targetRef="OrderAndShipment">                           <conditionExpression>Was the Order Approved?</conditionExpression>               /sequenceFlow>   Is this then correct? The description of the Expression class states it should be in the document attribute (which is by the way also not correct since the xsd states 'document' is not an attribute but an element).

Resolution:
Revised Text:
Actions taken:
August 19, 2010: received issue

Issue 15423: Contradictory mandatoryness of category for category values (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The group class diagram (figure 8.15) states that a category values must reference exactly one category.  The category values attributes table (table 8.23) however states that the category is not mandatory.

Resolution:
Revised Text:
Actions taken:
August 20, 2010: received issue

Issue 15428: Definition of Association is to strict (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Page 68 states:  An Association is used to connect user-defined text (an Annotation) with a Flow Object (see Figure 8.12).  This is to strict: an association can also be used to associate a compenstaion boundary event with a compenation activity.

Resolution:
Revised Text:
Actions taken:
August 26, 2010: received issue

Issue 15431: Wrong metaclass name in attribute description (bpmn2-rtf)

Click here for this issue's archive.
Source: INRIA (Mr. Juan Cadavid, jcadavid(at)irisa.fr)
Nature: Revision
Severity: Minor
Summary:

In table 10.58, description of the attribute outputSets mentions "...Every Data Interface must define..." when it should say "...Every InputOutputSpecification must define..."

Resolution:
Revised Text:
Actions taken:
August 26, 2010: received issue

Issue 15441: Definition of Signal Missing (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Clarification
Severity: Significant
Summary:

The Section on Common Elements (8.3) should have a subsection that defines Signal, the way that Message, Escalation, and Error are defined.

Resolution:
Revised Text:
Actions taken:
September 1, 2010: received issue

Issue 15443: Page 29 Wrong reference to page 240 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Table 7.1. Row �Event�       It says   �An Event is something that �happens� during the course of a Process (see page 245)�      It should say   �An Event is something that �happens� during the course of a Process (see page 240)�

Resolution:
Revised Text:
Actions taken:
September 4, 2010: received issue

Issue 15444: Page 96 Wrong reference to table 8.49 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

It says   �Table 8.51 presents the additional model associations for the Resource element:�      It should say   �Table 8.49 presents the additional attributes and model associations for the Resource element:�      �model associations� should be replaced by �attributes and model associations�  �Table 8.51� should be replaced by �Table 8.49�

Resolution:
Revised Text:
Actions taken:
September 6, 2010: received issue

Issue 15445: Page 96. Wrong reference to table 8.50 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

    It says   �Table 8.51 presents the additional model associations for the ResourceParameter element:�      It should say   �Table 8.50 presents the additional attributes and  model associations for the ResourceParameter element:�      �model associations� should be replaced by �attributes and model associations�  �Table 8.51� should be replaced by �Table 8.50�

Resolution:
Revised Text:
Actions taken:
September 6, 2010: received issue

Issue 15446: Page153 Wrong reference to section 8.3.2 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Table 10.1. Row �correlationSubscriptions�.      It says   �correlationSubscriptions are a feature of context-based correlation (cf. section 8.3.3).�      It should say   �correlationSubscriptions are a feature of context-based correlation (cf. section 8.3.2).�    �section 8.3.3� should be replaced by �section 8.3.2�

Resolution:
Revised Text:
Actions taken:
September 6, 2010: received issue

Issue 15447: Page154. Wrong reference to chapter 13 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   ��Chapter 14 (see page 440).�      It should say   ��Chapter 13 (see page 440).�    �Chapter 14� should be replaced by �Chapter 13"

Resolution:
Revised Text:
Actions taken:
September 6, 2010: received issue

Issue 15448: Adding child attributes and child elements in XSLT causes errors (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The examples of Business Process Model and Notation (BPMN) Version 2.0 - Beta 2, (May 2010) are valid with the provided XML Schema: spec/BPMN/2.0/20100501/BPMN20.xsd. However, the spec/BPMN/2.0/20100501/BPMN20-ToXMI.xslt does not transform these models into a complete XMI file. For example UserTasks with an implementation and ioSpecification is defined in BPMN as follows:  <semantic:userTask implementation="##unspecified" completionQuantity="1" isForCompensation="false" startQuantity="1" name="Review Issue List" id="_6-66">  <semantic:incoming>_6-167</semantic:incoming>  <semantic:outgoing>_6-169</semantic:outgoing>  <semantic:ioSpecification>  <semantic:dataInput id="Din1276277381462"/>  <semantic:inputSet>  <semantic:dataInputRefs>Din1276277381462</semantic:dataInputRefs>  </semantic:inputSet>  <semantic:outputSet/>  </semantic:ioSpecification>  <semantic:dataInputAssociation id="_6-151">  <semantic:sourceRef>_6-139</semantic:sourceRef>  <semantic:targetRef>Din1276277381462</semantic:targetRef>  </semantic:dataInputAssociation>  </semantic:userTask>      After the transformation with "BPMN20-ToXMI.xslt" I get the following result (without the specified implementation):  <flowElements xmi:type="bpmnxmi:UserTask" id="_6-66" name="Review Issue List" outgoing="_6-169 " incoming="_6-167 " isForCompensation="false" startQuantity="1" completionQuantity="1">  <ioSpecification xmi:type="bpmnxmi:InputOutputSpecification">  <inputSets xmi:type="bpmnxmi:InputSet" dataInputRefs="Din1276277381462 "/>  <outputSets xmi:type="bpmnxmi:OutputSet"/>  <dataInputs xmi:type="bpmnxmi:DataInput" id="Din1276277381462"/>  </ioSpecification>  <dataInputAssociations xmi:type="bpmnxmi:DataInputAssociation" id="_6-151" targetRef="Din1276277381462 " sourceRef="_6-139 "/>  </flowElements>      I took the "Email Voting 2.bpmn" example from the spec/BPMN/2.0/examples/ZIP. The transformation of "Email Voting 2.bpmn" produces the following error messages:  /XSLT-Transformation/BPMN20-ToXMI.xslt; Line #8; Column #116; Cannot add attribute dataObjectRef after child nodes or before an element is produced.  Attribute will be ignored.  OR  /XSLT-Transformation/BPMN20-ToXMI.xslt; Line #8; Column #116; Cannot add attribute implementation after child nodes or before an element is produced.  Attribute will be ignored.  (similar messages for cancelActivity, dataObjectRef, messageRef, attachedToRef, isCollection)

Resolution:
Revised Text:
Actions taken:
September 6, 2010: received issue

Issue 15455: Page167. Wrong reference to page 171 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �See �User Task� on page 167 within the larger section of �Human Interactions� for the details of User Tasks.�      It should say   �See �User Task� on page 171 within the larger section of �Human Interactions� for the details of User Tasks.�    �page 167� should be replaced by �page 171

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Issue 15456: Page168. Wrong reference to figure 10.18 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �A Manual Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a hand figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).�      It should say   �A Manual Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a hand figure marker that distinguishes the shape from other Task types (as shown in Figure 10.18).�    �Figure 10.17� should be replaced by �Figure 10.18�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Issue 15457: Page168 . Wrong reference to figure 10.19 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.11).�      It should say   �However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.19).�    �Figure 10.11� should be replaced by �Figure 10.19�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Issue 15458: Page 169. Wrong reference to figure 10.20 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Script Task (see Figure 10.11).�      It should say   �However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Script Task (see Figure 10.20).�    �Figure 10.11� should be replaced by �Figure 10.20�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Issue 15459: Page170. Wrong references to figures 10.17 10.18 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   ��the human involvement is REQUIRED to complete the Task (see Figure 10.15 and Figure 10.17, above).�      It should say   ��the human involvement is REQUIRED to complete the Task (see Figure 10.17 and Figure 10.18, above).�      �Figure 10.15� should be replaced by �Figure 10.17�    �Figure 10.17� should be replaced by �Figure 10.18�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Discussion:

Issue 15460: Page 172. Wrong reference to table 10.4 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �The User Task inherits the instance attributes of Activity (see Table 8.49).�      It should say   �The User Task inherits the instance attributes of Activity (see Table 10.4).�    �Table 8.49� should be replaced by �Table 10.4�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Issue 15461: Page 180. Wrong reference to figure 10.25 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �The (Collapsed) Sub-Process marker, seen in Figure 10.24, can be combined ��      It should say   �The (Collapsed) Sub-Process marker, seen in Figure 10.25, can be combined ��    �Figure 10.24� should be replaced by �Figure 10.25�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Issue 15462: Page 181. Wrong reference to figure 10.29 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �Figure 10.28 shows the class diagram related to Sub-Processes.�      It should say   �Figure 10.29 shows the class diagram related to Sub-Processes.�    �Figure 10.28� should be replaced by �Figure 10.29�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Issue 15464: Page 191. Wrong reference to figure 10.42 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �A Call Activity MUST fullfil the data requirements, as well as return the data produced by the CallableElement being invoked (see Figure 10.41).�      It should say   �A Call Activity MUST fullfil the data requirements, as well as return the data produced by the CallableElement being invoked (see Figure 10.42).�    �Figure 10.41� should be replaced by �Figure 10.42�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Issue 15465: Page 212. Wrong references to tables 10.51 10.52 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   ��and ItemAwareElement (Table 10.52). Table 10.54 presents the additional attributes of the DataObject element:�      It should say   ��and ItemAwareElement (Table 10.51). Table 10.52 presents the additional attributes of the DataObject element:�      �Table 10.52� should be replaced by �Table 10.51�  �Table 10.54� should be replaced by �Table 10.52�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Issue 15466: Page 217. Wrong reference to table 10.57 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �Table 10.54 presents the additional attributes of the Property element:�      It should say   �Table 10.57 presents the additional attributes of the Property element:�    �Table 10.54� should be replaced by �Table 10.57�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Issue 15467: Page 219. Wrong reference to table 10.58 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �Figure 10.54 presents the additional attributes and model associations of the InputOutputSpecification element:�      It should say   �Table 10.58 presents the additional attributes and model associations of the InputOutputSpecification element:�    �Figure 10.54� should be replaced by �Table 10.58�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Issue 15468: Page 231. Wrong reference to table 10.63 1 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �The DataInputAssociation element inherits the attributes and model associations of DataAssociation (see Table 10.64), but does not contain any additional attributes or model associations.�      It should say   �The DataInputAssociation element inherits the attributes and model associations of DataAssociation (see Table 10.63), but does not contain any additional attributes or model associations.�    �Table 10.64� should be replaced by �Table 10.63�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Issue 15469: Page 231. Wrong reference to table 10.63 2 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �The DataOutputAssociation element inherits the attributes and model associations of DataAssociation (see Table 10.64), but does not contain any additional attributes or model associations.�      It should say   �The DataOutputAssociation element inherits the attributes and model associations of DataAssociation (see Table 10.63), but does not contain any additional attributes or model associations.�    �Table 10.64� should be replaced by �Table 10.63

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Discussion:

Issue 15470: Page 245. Wrong reference to table 10.83 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �The ImplicitThrowEvent element inherits the attributes and model associations of ThrowEvent (see Table 10.84), ��      It should say   �The ImplicitThrowEvent element inherits the attributes and model associations of ThrowEvent (see Table 10.83), ��    �Table 10.84� should be replaced by �Table 10.83�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Issue 15471: Page 248. Wrong reference to table 10.85 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �There is only one (1) type of Start Event for Sub-Processes in BPMN (see Figure 10.82): None.�      It should say   �There is only one (1) type of Start Event for Sub-Processes in BPMN (see Table 10.85): None.�    �Figure 10.82� should be replaced by �Table 10.85�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Discussion:

Issue 15472: Page 266. Wrong reference to table 10.91 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �Table 8.46 presents the additional attributes and model associations of the Boundary Event element:�      It should say   �Table 10.91 presents the additional attributes and model associations of the Boundary Event element:�    �Table 8.46� should be replaced by �Table 10.91�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Issue 15473: Page. 300. Wrong reference to page 450 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �The precise synchronization behavior of the Inclusive Gateway can be found on page 300.�      It should say   �The precise synchronization behavior of the Inclusive Gateway can be found on page 450.�    �page 300� should be replaced by �page 450�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Issue 15474: Page 313. Wrong references to figures 10.123 10.124 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �A Lane is a sub-partition within a Process (often within a Pool) and will extend the entire length of the Process level,, either vertically (see Figure 10.122) or horizontally (see Figure 10.123).�      It should say   �A Lane is a sub-partition within a Process (often within a Pool) and will extend the entire length of the Process level,, either vertically (see Figure 10.123) or horizontally (see Figure 10.124).�      �Figure 10.122� should be replaced by �Figure 10.123�  �Figure 10.123� should be replaced by �Figure 10.124�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Discussion:

Issue 15475: Page 485. Wrong reference to figure 14.2 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �End Events can be combined with other BPMN objects to complete the merging or joining of the paths of a WSBPEL structured element (see Figure 7.3).�      It should say   �End Events can be combined with other BPMN objects to complete the merging or joining of the paths of a WSBPEL structured element (see Figure 14.2).�    �Figure 7.3� should be replaced by �Figure 14.2�

Resolution:
Revised Text:
Actions taken:
September 9, 2010: received issue

Discussion:

Issue 15502: Chapter 7. Typos (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

a) Section 7. Page 21. It says �BPMN provides a multiple diagrams, which are designed for use by the people who design and manage Business Processes.� It should say �BPMN provides multiple diagrams, which are designed for use by the people who design and manage Business Processes.� �a multiple� should be replaced by �multiple� ---------------------------------------------------------- b) Section 7.2.2. Page 34. In table 7.2. Row �Conditional flow� It says �A Sequence Flow can have a condition Expression that are evaluated at runtime �� It should say �A Sequence Flow can have a condition Expression that is evaluated at runtime �� �that are evaluated� should be replaced by �that is evaluated� ---------------------------------------------------------- c) Section 7.2.2. Page 34. In table 7.2. Row �Default flow� It says �These Sequence Flows will have a diagonal slash will be added to the beginning of the connector �� It should say �These Sequence Flows will have a diagonal slash added to the beginning of the connector �� �slash will be added� should be replaced by �slash added� ---------------------------------------------------------- d) Section 7.2.2. Page 36. In table 7.2. Row �Fork�. It says �This represents �uncontrolled� flow is the preferred method for most situations.� It should say �This represents �uncontrolled� flow which is the preferred method for most situations.� �flow is� should be replaced by �flow which is� ---------------------------------------------------------- e) Section 7.2.2. Page 39. Table 7.2. Row �Mutiple Instances�. It says �A set of three (3) horizontal liness will be displayed at the bottom-center of the activity for sequentail Multi-Instances (see upper figure to the right). A set of three (3) vertical liness will be displayed at the bottom-center of the activity for sequentail Multi-Instances (see lower figure to the right).� It should say �A set of three (3) horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see upper figure to the right). A set of three (3) vertical lines will be displayed at the bottom-center of the activity for parallel Multi-Instances (see lower figure to the right).� �horizontal liness� should be replaced by �horizontal lines� first �sequentail Multi-Instances� should be replaced by �sequential Multi-Instances� �vertical liness� should be replaced by �vertical lines� second �sequentail Multi-Instances� should be replaced by �parallel Multi-Instances�

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15503: Chapter 8. Typos (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

a)  Section 8.2.3. Page 59.      Table 8.10. Row �value�.       It says   �[Element [0..1]�      It should say   �Element [0..1]�      First �[� should be removed  ----------------------------------------------------------      b)  Section 8.2.3. Page 59.      Table 8.10. Row �valueRef�.       It says   �[Element [0..1]�      It should say   �Element [0..1]�      First �[� should be removed  ----------------------------------------------------------      c)  Section 8.2.4. Page 62.      It says   �The �identity/relationship� model it is reduced to the creation of families of typed relationships ��      It should say   �The �identity/relationship� model is reduced to the creation of families of typed relationships ��      �model it is reduced� should be replaced by �model is reduced�  ----------------------------------------------------------      d)  Section 8.2.4. Page 63.      Table 8.15. Row �sources�.       It says   �[Element [1..*]�       It should say   �Element [1..*]�      First �[� should be removed   ----------------------------------------------------------      e)  Section 8.2.4. Page 63.      Table 8.15. Row �targets�.       It says   �[Element [1..*]�      It should say   �Element [1..*]�      First �[� should be removed  ----------------------------------------------------------      f)  Section 8.3.1. Page 67.      It says   �An Association is line that MUST be drawn ��      It should say   �An Association is a line that MUST be drawn ��      �is line� should be replaced by �is a line�  ----------------------------------------------------------      g)  Section 8.3.9. Page 90.      It says   �The details for the types of Gateways (Exclusive, Inclusive, Parallel, Event-Based, and Complex) is defined on page 295 ��      It should say   �The details for the types of Gateways (Exclusive, Inclusive, Parallel, Event-Based, and Complex) are defined on page 295 ��      �is defined� should be replaced by �are defined�  ----------------------------------------------------------      h)  Section 8.3.10. Page 92.      Table 8.47. Row �structureRef�.       It says   �[Element [0..1]�      It should say   �Element [0..1]�      First �[� should be removed  ----------------------------------------------------------      i)  Section 8.3.11. Page 93.      It says   �In a Message is a rectangle with converging diagonal lines in the upper ��      It should say   �A Message is a rectangle with converging diagonal lines in the upper ��      �In a� should be replaced by �A�  ----------------------------------------------------------      j)  Section 8.3.12. Page 96.      It says   �These parameters can be used at runtime to define query e.g., into an ��      It should say   �These parameters can be used at runtime to define a query e.g., into an ��    �define query� should be replaced by �define a query�

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15504: Chapter 9. Typos (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

a) Section 9.4. Page 125. 9.4 Conversations It says �The Conversation diagram is particular usage of and an informal description �� It should say �The Conversation diagram is a particular usage of and an informal description �� �is particular usage� should be replaced by �is a particular usage� ---------------------------------------------------------- b) Section 9.4. Page 128. It says �Figure 9.20 shows a how the Sub-Conversation of ...� It should say �Figure 9.20 shows how the Sub-Conversation of ...� �a how� should be replaced by �how� ---------------------------------------------------------- c) Section 9.4. Page 129. It says �Figure 9.21 shows a how the Conversation of...� It should say �Figure 9.21 shows how the Conversation of...� �a how� should be replaced by �how� ---------------------------------------------------------- d) Section 9.4.4. Page 134. Table 9.12. Row �calledCollaborationRef� It says �Collaboratioin [0..1]� It should say �Collaboration [0..1]� �Collaboratioin� should be replaced by �Collaboration� ---------------------------------------------------------- e) Section 9.4.5. Page 134. It says �The GlobalConversation element inherits the attributes and model associations and Collaboration �� It should say �The GlobalConversation element inherits the attributes and model associations of Collaboration� �and Collaboration� should be replaced by �of Collaboration� ---------------------------------------------------------- f) Section 9.4.6. Page 137. It says ��on the left with a Call Conversations to a Collaboration on the right.� It should say ��on the left with a Call Conversation to a Collaboration on the right.� �Conversations� should be replaced by �Conversation� ---------------------------------------------------------- g) Section 9.4.6. Page 138. It says �For example, the Credit Agency Participants on the right corresponds �� It should say �For example, the Credit Agency Participant on the right corresponds �� �Participants� should be replaced by �Participant� ---------------------------------------------------------- h) Section 9.4.8. Page 139. It says � � and can be defined for the Message Flows that belong to the a Conversation.� It should say ��and can be defined for the Message Flows that belong to a Conversation.� �to the a� should be replaced by �to a� ---------------------------------------------------------- i) Section 9.4.8. Page 140. It says ��if the conceptual data comprises of an order than the correlation field might be denoted �� It should say ��if the conceptual data comprises of an order then the correlation field might be denoted �� �than� should be replaced by �then �

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15505: Chapter 10. Typos (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

a) Section 10. Page 151. Table 10.1. Row �processType�. It says �The processType attribute Provides additional information �� It should say �The processType attribute provides additional information �� �Provides� should be replaced by �provides�. ---------------------------------------------------------- b) Section 10.2. Page 157. Table 10.3. Row �completionQuantity�. It says �This number of tokens will be sent done ...� It should say �This number of tokens will be sent down ...� �sent done� should be replaced by �sent down � ---------------------------------------------------------- c) Section 10.2.3. Page 161. The words �marker� and �Marked� are nor used consistently throughout the text. For example: On p. 161: �The loop Marker MAY be used in combination with the compensation marker.� On p. 197: �The loop Marker MAY be used in combination with the Compensation Marker.� On p.198: �The Multi-Instance marker MAY be used in combination with the Compensation marker.� ---------------------------------------------------------- d) Section 10.2.4. Page 170. It says �Manual Tasks and User Tasks have a Icons to indicate ...� It should say �Manual Tasks and User Tasks have icons to indicate ...� �a Icons� should be replaced by �icons� ---------------------------------------------------------- e) Section 10.3.1. Page 224. It says ��the payloard within the Message will not flow out of the Receive Task and into the Process.� It should say ��the payload within the Message will not flow out of the Receive Task and into the Process.� �payloard� should be replaced by �payload� ---------------------------------------------------------- f) Section 10.3.1. Page 231. It says �� a DataOutput contained within an ACTIVITY with any ItemAwareElement accessible �� It should say �� a DataOutput contained within an Activity with any ItemAwareElement accessible �� �ACTIVITY� should be replaced by �Activity� ---------------------------------------------------------- g) Section 10.3.1. Page 231. It says ��one from a item-aware element � to a item-aware element �� It should say ��one from an item-aware element � to an item-aware element �� �a item-aware� should be replaced (twice) by �an item-aware� ---------------------------------------------------------- h) Section 10.4.2. Page 248. Table 10.84. Row �Multiple� It says �(a pentagon�see the upper figure to the right)� It should say �(a pentagon�see figure to the right)� �see the upper figure� should be replaced by �see figure� ---------------------------------------------------------- i) Section 10.4.4. Page 263. Table 10.90. Row �Compensation�. It says �Note that the interrupting a non-interrupting aspect of ...� It should say �Note that the interrupting and non-interrupting aspect of ...� �a non-interrupting� should be replaced by �and non-interrupting� ---------------------------------------------------------- j) Section 10.4.5. Page 273. Paragraph �The ConditionalEventDefinition element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to the EventDefinition element (see page 268). Table 10.95 presents the additional model associations of the ConditionalEventDefinition element:� It is repeated twice. The first one should be removed. ---------------------------------------------------------- k) Section 10.4.5. Page 275. It says �When used to �throw� to the target Link, the Event marker will be filled (see Figure 10.84: upper: lower Left).� It should say �When used to �throw� to the target Link, the Event marker will be filled (see Figure 10.84: lower left).� �upper: lower Left� should be replaced by �lower left�

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15506: Chapter 11. Typos (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

a) Section 11.3.1. Page 330. It says �Because the other outgoing Sequence Flows will have appropriately visible of data as described above, �� It should say �Because the other outgoing Sequence Flows will have appropriate visibility of data as described above, �� �have appropriately visible� should be replaced by �have appropriate visibility� ---------------------------------------------------------- b) Section 11.4.1. Page 337. It says �The width of the Participant Band will be expanded to contain both the name of the Participant and the multi-instance marker.� It should say �The high of the Participant Band will be expanded to contain both the name of the Participant and the multi-instance marker.� �width� should be replaced by �high� Note: On page 342 this (equivalent) sentence is a sub-bullet. ---------------------------------------------------------- c) Section 11.4.2. Page 341. It says �In addition, any Participant Band beyond the first two optional; ...� It should say �In addition, any Participant Band beyond the first two is optional; ...� �two optional� should be replaced by �two is optional� ---------------------------------------------------------- d) Section 11.4.2. Page 342. It says �The width of the Participant Band will be expanded to contain both the name of the Participant and the multi-instance marker.� It should say �The high of the Participant Band will be expanded to contain both the name of the Participant and the multi-instance marker.� �width� should be replaced by �high� Note: On page 337 this (equivalent) sentence is not a sub-bullet. ---------------------------------------------------------- e) Section 11.4.2. Page 342. Figure 11.23. It says �Figure 11.23 - Sub-Choreography Markers with a multi-instance Participant� It should say �Figure 11.23 � A Sub-Choreography with a multi-instance Participant� �Sub-Choreography Markers� should be replaced by �A Sub-Choreography� Note: Compare it with Figure 11.15, p.337. ---------------------------------------------------------- f) Section 11.4.6. Page 345. It says ��when the Participants send or receive Messages so that they Participants are NOT REQUIRED to guess about when it is their turn to send a Message.� It should say ��when the Participants send or receive Messages so that the Participants are NOT REQUIRED to guess about when it is their turn to send a Message.� �they Participants� should be replaced by �the Participants�

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15507: Chapter 13. Typos (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

)  Section 13.1. Page 440.      It says   �A token reaching an End Event triggers the behavior associated with the Event type is, ��      It should say   �A token reaching an End Event triggers the behavior associated with the Event type, ��      �type is� should be replaced by �type�  ----------------------------------------------------------      b)  Section 13.4.5. Page 457.      It says   �A compensation Event Sub-Process can in particular recursively trigger compensation for Activities contained in that its parent.�      It should say   �A compensation Event Sub-Process can in particular recursively trigger compensation for Activities contained in its parent.�      �in that its� should be replaced by �in its�  ----------------------------------------------------------      c)  Section 13.4.5. Page 458.      It says   �Second, if no error Event Sub-Process is specified for a particular Sub-Process and a particular error, ��      It should say   �Second, if no error Event Sub-Process is specified for a particular Sub-Process and a particular error occurs, ��    �particular error,� should be replaced by �particular error occurs,�

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15508: Chapter14. Typos (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

a)  Section 14.1.1. Page 463.      It says   �The following figure describes the mapping of a Process, represented by its defining Collaboration, to WS-BPEL. The process itself is described by a contained graph G of flow elements) to WS-BPEL.�      Maybe it should say   �The following figure describes the mapping of a Process, represented by its defining Collaboration, to WS-BPEL. The process itself is described by a contained graph G of flow elements.�      �elements) to WS-BPEL� should be replaced by �elements�  ----------------------------------------------------------      b)  Section 14.1.2. Page 466.      It says   �(i.e., Message Events, Service, send or Receive Tasks)�      It should say   �(i.e., Message Events, Service, Send or Receive Tasks)�    �send� should be replaced by �Send�.

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15509: Left over restrictions on use of Start and End Events (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Revision
Severity: Critical
Summary:

Issue 14783 relaxed the restrictions on the use of Start and End Events. But there are two statements in the spec that are left over.  On page 248:  "If there is an End Event, then there MUST be at least one Start Event."  This should be removed      On page 256:  "If there is a Start Event, then there MUST be at least one End Event."  This should be removed

Resolution:
Revised Text:
Actions taken:
September 10, 2010: received issue

Issue 15510: Page 84. Event is not direct subclass of FlowElement (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

says   �The Event element inherits the attributes and model associations of FlowElement (see Table 8.44), but adds no additional attributes or model associations:�      It should say   �The Event element inherits the attributes and model associations of FlowElement (see Table 8.44), through its relationship to FlowNode, but adds no additional attributes or model associations.�    Event is direct subclass of FlowNode, which is direct subclass of FlowElement. (See Figure 8.20, p. 84.)

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15511: Page 96. ResourceParameter is not subclass of RootElement (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �The ResourceParameter element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to RootElement.�      It should say   �The ResourceParameter element inherits the attributes and model associations of BaseElement (see Table 8.5).�    ResourceParameter it is not subclass of RootElement. It is direct subclass of BaseElement. (See Figure 8.31, p.96.)

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15512: Page 97. Wrong multiplicity of association in Table 8.50 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Table 8.50. Row �type�       It says   �type: ItemDefinition�      It should say   �type: ItemDefinition [0..1]�    In Figure 8.31 (p. 96) model association �type� (from ResourceParameter to ItemDefinition) is optional ([0..1])

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15513: Page 99. Wrong inheritance of FlowNode (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

It says   �Since Gateway, Activity, Choreography Activity, and Event have their own attributes, model associations, and inheritances; the FlowNode element does not inherit from any other BPMN element. Table 8.52 presents the additional model associations of the FlowNode element:�      It should say   �The FlowNode element inherits the attributes and model associations of FlowElement (see Table 8.44). Table 8.52 presents the additional model associations of the FlowNode element:�    FlowNode  is subclass of FlowElement. (See Figure 8.35, p. 98; and Figure 8.22, p.87.)

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15514: Page 104. Navigation (arrowhead) is needed if Figure 8.36 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Figure 8.36 and Table 8.65 (p.105)      A navigation (arrowhead) is needed from �Interface� to �CallableElement� in Figure 8.36 in order to be consistent with the model association �callableElement� in Table 8.65 (p.105).     The inclusion of  �callableElements� in Table 8.65 means that �Interface knows about CallableElement�, which (in UML) is graphically represented with an arrowhead from �Interface� to �CallableElement�.

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15515: Page 109. Wrong multiplicity in Figure 9.1 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Figure 9.1 and Table 9.1 (p.110).    In Figure 9.1 multiplicity of  �conversationAssociations� (from �Collaboration� to �ConversationAssociation�) is [1..1], but it should be [0..*], as it is shown in Table 9.1 (p.110).

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15516: Page 110. Wrong use of UML concept �aggregation�. (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In Table 9.1. Row �conversations�.       It says   �The conversations model aggregation relationship allows a Collaboration to contain ��      It should say   �The conversations model composition relationship allows a Collaboration to contain ��    In Figure 9.1 (p. 109), the line �begins� with a filled mini-diamond, which represents a composition, not an aggregation.

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15517: Page 111. Association �participants� not shown in Figure 9.1 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Table 9.1. Row �participants�. And Figure 9.1 (p.109).      Model association �participants� (from �Collaboration� to �Participant�) is not shown in Figure 9.1 (p.109).    Model association �participants� should be shown in Figure 9.1 because it is the location where all class �Collaboration� relationships must be displayed.

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15518: Page 115. Confusion over subtypes of Collaboration 1. (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

It says   �When Participants are defined  they are contained within a Collaboration, which includes the sub-types of Choreography, GlobalConversation, or GlobalChoreographyTask.�      This is not consistent with what is shown in Figure 9.1 (p.109): GlobalConversation and Choreography are sub-types of Collaboration; and GlobalChoreographyTask is sub-type of  Choreography.      Maybe it should say   �When Participants are defined  they are contained within a Collaboration, which includes the sub-types  GlobalConversation,  Choreography and  GlobalChoreographyTask.�

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Discussion:

Issue 15519: Page 117. Wrong name of model association �interfaceRefs�. (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Table 9.2. Row �interfaceRef�.    The model association name should be �interfaceRefs�, because of its multiplicity ([0..*]), and because this is its name in Figure 9.7 (p.116).

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Discussion:

Issue 15520: Page 117 & 118. Wrong name of association �participantRefs (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Table 9.3 (p.117). Row �participantRef�.       The model association name should be �participantRefs�, because of its multiplicity ([0..*]). Its name should be  modified  in Figure 9.7 (p.116) too.  --------------------------------------      Table 9.4 (p.118). Row �participantRef�.     The model association name should be �participantRefs�, because of its multiplicity ([0..*]). Its name should be  modified  in Figure 9.7 (p.116) too.

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15521: Page 117 & 118. Confusion over subtypes of Collaboration 2 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Table 9.3 (p.117).  Row �participantRef�.       It says   �Specifies how the PartnerEntity participates in Collaborations and Choreographies.�      It should say  �Specifies how the PartnerEntity participates in Collaborations.�   ----------------------------------------------------      Table 9.4 (p.118).  Row �participantRef�.       It says   �Specifies how the PartnerRole participates in Collaborations and Choreographies.�      It should say  �Specifies how the PartnerRole participates in Collaborations.�   --------------------------------------------------      In Beta 2 GlobalConversation and Choreography are sub-types of Collaboration; and GlobalChoreographyTask is sub-type of  Choreography.   Then �Collaborations and Choreographies� is incomplete and ambiguous.

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15522: Page 139. Ambiguous multiplicities of associations (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Table 9.14. Row �innerConversationNodeRef�.       In table 9.14 the multiplicity of model association �innerConversationNodeRef� is [0..1], but in Figure 9.31 (p. 139) its multiplicity is [1..1].   Its description in Table 9.14 (�This attribute defines the ConversationNodes of the referenced element...�) suggests that its multiplicity should be [0..*].      The multiplicity of  �innerConversationNodeRef� should be clearly defined ([0..1], or [1..1], or [0..*]). In case of [0..*] the model association name should be changed to �innerConversationNodeRefs�  ---------------------------------------------      Table 9.14. Row �outerConversationNodeRef�.       In table 9.14 the multiplicity of model association �outerConversationNodeRef� is [0..*], but in Figure 9.31 (p. 139) its multiplicity is [1..1].   Its description in Table 9.14 (�This attribute defines the ConversationNodes of the parent element...�) suggests that its multiplicity should be [0..*].       The multiplicity of  �outerConversationNodeRef� should be clearly defined ([1..1], or [0..*]). In case of [0..*] the model association name should be changed to �outerConversationNodeRefs�    Table 9.14 and Figure 9.31 should be updated accordingly.

Resolution:
Revised Text:
Actions taken:
September 13, 2010: received issue

Issue 15531: Page 151. Wrong role name and multiplicity of association �artifacts� (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Figure 10.3.      Name and multiplicity of role from �Process� to �Artifact� are:     �artifact�  and  �0..1�     but they should be:       �artifacts�  and  �*� .     See  Table 10.1 (p. 152), row �artifacts�.

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15532: Page 182. Missing Start event triggers for Event Sub-Process (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:  �The Start Event trigger (EventDefinition) MUST be from the following types: Message, Error, Escalation, Compensation, Conditional, Signal, and Multiple (see page 268 for more details).�      Problem: �Timer� and �Parallel Multiple� are not mentioned, but they are valid Start Event triggers for Event Sub-Process (see Table 10.93, pp. 269 & 270). Then, it should say:     �The Start Event trigger (EventDefinition) MUST be from the following types: Message, Timer, Error, Escalation, Compensation, Conditional, Signal,  Multiple and Parallel Multiple (see page 268 for more details).�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15533: Page 185. Nonexistent attribute shown in Figure 10.29 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Table 10.21 and Figure 10.29 (p. 181)      Attribute �protocol� was removed from class Transaction in Table 10.21 (p.185), but it remains in Figure 10.29 (p.181).     Attribute �protocol� of class Transaction should be removed from Figure 10.29.

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15534: Page 185. Nonexistent enumeration used in Table 10.21 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Table 10.21 and Figure 10.29 (p. 181)      Enumeration TransactionMethod was removed from Figure 10.29 (p.181), but it is still used in Table 10.21 (p.185) in attribute �method�.     Maybe �method: TransactionMethod� should be replaced by �method: string� as it is defined in Figure 10.29.

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15535: Page 192. Association �calledElementRef�: wrong name, location and description (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Figure 10.42. and Table 10.23.      a)  Figure 10.42      Model association from �CallActivity� to �CallableElement�.   Role name �calledElementRef� is located near class �CallActivity�, but it must be located near class CallableElement.   ---------------------------------------------------------------------      b) Table 10.23. Row �calledElement�  It says:  �calledElement: CallableElement [0..1]�      It should say:  �calledElementRef: CallableElement [0..1]�      �calledElement� should be replaced by �calledElementRef�  ----------------------------------------------------------------------      c) Table 10.23. Row �calledElement�      It says:   �� MUST NOT be called by the Call Conversation element.�      Table 10.23 describes �CallActivity� model associations, not �Call Conversation� model associations (Table 9.12, p. 134).      Then, it should say:   �� MUST NOT be called by the Call Activity element.�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Discussion:

Issue 15536: Page 202. Wrong multiplicity of model association �event� (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Table 10.31. Row �event�.       It says:   �event: ImplicitThrowEvent�      Model association �event� is optional, see Figure 10.45 (p.196).      Then, it should say:   �event: ImplicitThrowEvent [0..1]�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15537: Page 221. Nonexistent attribute �optional� mentioned (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

It says   �The �optional� attribute defines if a DataInput is valid even if the state is �unavailable�. The default value is false. If the value of this attribute is true, then the execution of the Activity will not begin until a value is assigned to the DataInput element, through the corresponding Data Associations.�      Problem: The �optional� attribute of �DatInput� is mentioned, but  it is not shown in any Table or Figure (in particular Figure 10.59, p. 221; and Table 10.59, p. 222).    This paragraph should be removed; or the attribute �optional� should be added in Table 10.59 and Figure 10.59.

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15538: Pages 221-223. Inheritance of DataInput, DataOutput. Wrong table reference (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

a) Page 221      It says:  �The DataInput element inherits the attributes and model associations of BaseElement (see Table 8.5) and ItemAwareElement (Table 10.52).�      DataInput is subclass of ItemAwareElement, which is subclass of BaseElement (see Figure 10.50, p.211). Furthermore, attributes and model associations of ItemAwareElement are shown in Table 10.51.      Then, it should say:  �The DataInput element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to ItemAwareElement (Table 10.51).�  ----------------------------------------------------------------------------------------------------      b) Page 223  It says:  �The DataOutput element inherits the attributes and model associations of BaseElement (see Table 8.5) and ItemAwareElement (Table 10.52).�      DataOutput is subclass of ItemAwareElement, which is subclass of BaseElement (see Figure 10.50, p.211). Furthermore, attributes and model associations of ItemAwareElement are shown in Table 10.51.      Then, it should say:   �The DataOutput element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to ItemAwareElement (Table 10.51).�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15539: Page 230. Wrong type of model association �transformation� (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Table 10.63. Row �transformation�.      It says:   �transformation: Expression [0..1]�      �transformation� is a role name of the association from �DataAssociation� to �FormalExpression� (see Figure 10.64, p.229). So the type is not �Expression�, but �FormalExpression�.      Then, it should say:   �transformation: FormalExpression [0..1]�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15540: Page 230. Super-class of �Assignment� not shown in any diagram (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:   �The Assignment element inherits the attributes and model associations of BaseElement (see Table 8.5).�    But, it is not shown in any diagram that �Assignment� is subclass of �Base Element�.

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15541: Pages 230-231. Wrong name of Table 10.64 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

�Assignment� has no attributes and two model associations (see Figure 10.64, p.229).      Page 230.      It says:  �Table 10.64 presents the additional attributes of the Assignment element:�      It should say:  �Table 10.64 presents the additional model associations  of the Assignment element:�  --------------------------------------------------------------------------  Page 231.      It says:  �Table 10.64 � Assignment attributes�      It should say:  �Table 10.64 � Assignment model associations�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Discussion:

Issue 15542: Page 231. Activity is not an Item Aware Element (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

It says:   ��one from a item-aware element (e.g., an Activity) contained by the source of the Sequence Flow, ��      �Activity�  is not an item-aware element, but it contains an item-aware element (see Figure 10.50, p. 211; Figure 10.57, p. 219).      Then, it should say:   ��one from an item-aware element contained by the source of the Sequence Flow (e.g., an Activity), ��

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15543: Page 241. Wrong role names in Figure 10.69 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Figure 10.69.       a)  Role name �dataOutputAssociation� (from �CatchEvent� to �DataOutputAssociation�) should be �dataOutputAssociations�.       See Table 10.82  (p. 243). Row �dataOutputAssociations�  ---------------------------------------------------------------------------------------      b) Role name �dataInputAssociation� (from �ThrowEvent� to �DataInputAssociation�) should be �dataInputAssociations�.     See table 10.83 (p. 245). Row �dataInputAssociations�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Discussion:

Issue 15544: Page 266. Wrong role name "attachedToRef" in Table 10.91 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Table 10.91. Row �attachedTo�      It says:  �attachedTo: Activity�      It should say:  �attachedToRef: Activity�    See Figure 10.69  (p.241).

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15545: Page 274. Wrong role name �errorRef� in Table 10.96 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Table 10.96. Row �error�      It says:   �error: Error [0..1]�      It should say:   �errorRef: Error [0..1]�    See Figure 10.80  (p.274).

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15546: Page 308. Incorrect name of Parallel Event-Based Gateway 1 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:  �The Parallel Event Gateway is also a type of race condition...�      It should say:  �The Parallel Event-Based Gateway is also a type of race condition ...�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15547: Pages 312-457. Nonexistent attribute �compensable� mentioned (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

On page 312, it says:   �It is possible to specify that a Sub-Process can be compensated without having to define the compensation handler. The Sub-Process attribute compensable, when set, specifies that default compensation is implicitly defined, which recursively compensates all successfully completed Activities within that Sub-Process.�      On page 457 (section 13.4.4), it says:   �It is possible to specify that a Sub-Process can be compensated without having to define the compensation handler. The Sub-Process attribute compensable, when set, specifies that default compensation is implicitly defined, which recursively compensates all successfully completed Activities within that Sub-Process, invoking them in reverse order of their forward execution.�      The mentioned attribute �compensable� doesn�t appear in any Class Diagram or Table. In particular, Figure 10.29 and Table 10.20 (p.181), where the Sub-Process element is described.    These paragraphs should be removed; or the attribute �compensable� should be added in Table 10.20 and Figure 10.29.

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15548: Page 317. Ambiguous associations �partitionElement� and �partitionElementRef� (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Table 10.135.      a)   Model associations �partitionElement� and �partitionElementRef� have the same description:   �A reference to a BaseElement which specifies the partition value and partition type. Using this partition element a BPMN compliant tool can determine the FlowElements which have to be partitioned in this Lane.�      So, which is the difference  between them?  --------------------------------------------------------------------------      b)  Model association �flowNodeRefs� is described as �the list of FlowNodes partitioned into this Lane according to the partitionElement defined as part of the Lane element.�      �partitionElement� is optional. What happen if �partitionElement� is not defined?       Does �flowNodeRefs� depend of �partitionElementRef� also?    Can both �partitionElement� and �partitionElementRef� be defined at the same time?

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Discussion:

Issue 15549: Page 338. Wrong name, multiplicity and description of �messageFlowRefs� (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

a)    Table 11.2. Row �messageFlowRef�.      It says:   �messageFlowRef: Message Flow [1..*]�      It should say:   �messageFlowRefs: Message Flow [1..2]�      See Figures 11.1 (p.326) and 11.6 (p.332), where the multiplicity [1..2] is clear.  ----------------------------------------------------------------------------      b)  In Figures 11.1 (p.326) and 11.6 (p.332) the role name is �messageFlowRef�, but it should be �messageFlowRefs�, because there can be more than one links.  --------------------------------------------------------------------------------------      c)   In Table 11.2. Row �messageFlowRef�, it says �Although not graphical represented, Choreography Task contain one (1) or more Message Flows that represent the interaction(s) between the Participants referenced by the Choreography Task.�      But, on page 333, it says:   �A Choreography Task is an atomic Activity in a Choreography Process. It represents an Interaction, which is one (1) or two (2) Message exchanges between two (2) Participants.�  Furthermore, the multiplicity is [1..2].      Then, in Table 11.2. Row �messageFlowRefs�, it should say:  �Although not graphical represented, Choreography Task contain one (1) or two (2)  Message Flows that represent the interaction(s) between the Participants referenced by the Choreography Task.�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Discussion:

Issue 15550: Page 341. Choreography instead of Sub-Choreography (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:   �The Choreography Activity shares the same shape as a Sub-Process or any other BPMN Activity, which is in this state.�      This sentence is within section 11.4.2, where Sub-Choreographies are described.      Then, it should say:   �The Sub-Choreography shares the same shape as a Sub-Process or any other BPMN Activity, which is in this state.�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15551: Page 341. Choreography Activity instead of Task (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:  �The three (3) or more partitions in the Sub-Choreography shape provide the distinction between this type of Task and an Orchestration Sub-Process (in a traditional BPMN diagram).�      A Sub-Choreography is not a �type of Task�, but it is a �type of Choreography Activity�.      Then, it should say:   �The three (3) or more partitions in the Sub-Choreography shape provide the distinction between this type of Choreography Activity and an Orchestration Sub-Process (in a traditional BPMN diagram).�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15552: Page 342. Wrong reference to Table 11.3 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:   �Table 11.3 presents the additional model associations of the GlobalChoreographyTask element:�      But in Table 11.3 Sub-Choreography element is described.      Then, it should say:   �Table 11.3 presents the additional model associations of the Sub-Choreography element:�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15553: Page 345. Wrong type of "calledChoreographyRef" (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Table 11.4.      It says:   �calledChoreographyRef: CallableElement [0..1]�      The model association is form �CallChoreography� to �Choreography�.  See Figure 11.27, p. 344.      Then, it should say:   �calledChoreographyRef: Choreography [0..1]�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Discussion:

Issue 15554: Page 359. Missing markers in Send and Receive Tasks (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Figure 11.37.      Participant A:        Two (of three) Send Tasks without message markers.      Participant B:        One (of two) Receive Task without message marker.        One (of two) Receive Task without incoming Message Flow.      Participant C:        Receive Task without message marker.

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15555: Pages 366-368. Wrong direction of Message Flow (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

a) Figure 11.43 (p.366)      Direction of M1 is wrong. It should be from Task in Participant B to Task in Participant A.  ----------------------------------------------------------------------      b) Figure 11.45 (p.368)  Direction of M1 is wrong. It should be from Task in Participant B to Task in Participant A.

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15556: Page 370. Wrong Parallel Gateway in Figure 11.47 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Figure 11.47.       Participant B: The Parallel Gateway has a �decision�, and its outgoing Sequence Flows have �conditions�.       It is a mistake. �A Parallel Gateway creates parallel paths without checking any conditions; each outgoing Sequence Flow receives a token upon execution of this Gateway.� (p. 302).    Then, words �Decision?�, �Yes� and �No� should be removed.

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15557: Page 440. Incorrect name of Parallel Event-Based Gateway 2 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:  �If the instance was created through an instantiating Parallel Gateway, then all subsequent Events (of that Gateway) MUST have occurred.�      Normal Parallel Gateways cannot be instantiating elements.      Then, it should say:  �If the instance was created through an instantiating Parallel Event-Based Gateway, then all subsequent Events (of that Gateway) MUST have occurred.�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Discussion:

Issue 15558: Page 441. �Task� instead of �Activity� (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:   �Uncontrolled flow means that, for each token arriving on any incoming Sequence Flows into the Activity, the Task will be enabled independently of the arrival of tokens on other incoming Sequence Flows. The presence of multiple incoming Sequence Flows behaves as an exclusive gateway. If the flow of tokens into the Task needs to be �controlled,� then Gateways (other than Exclusive) should be explicitly included in the Process flow prior to the Task to fully eliminate semantic ambiguities.�      The description is intended for �Activities� in general, not for �Tasks� in particular.      Then, it should say:   �Uncontrolled flow means that, for each token arriving on any incoming Sequence Flows into the Activity, the Activity will be enabled independently of the arrival of tokens on other incoming Sequence Flows. The presence of multiple incoming Sequence Flows behaves as an exclusive gateway. If the flow of tokens into the Activity needs to be �controlled,� then Gateways (other than Exclusive) should be explicitly included in the Process flow prior to the Activity to fully eliminate semantic ambiguities.�    Three times �Task� should be replaced by �Activity�.

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Discussion:

Issue 15559: Page 452. Incorrect name of Parallel Event-Based Gateway 3 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:  �When used at the Process start as a Parallel Event Gateway, only message-based triggers are allowed.�      It should say:   �When used at the Process start as a Parallel Event-Based Gateway, only message-based triggers are allowed.�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15577: Page 57. Associations are incorrectly drawn Figure 8.6 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Figure 8.6.       Generalization from �Documentation� to �BaseElement� is on top of aggregation from �BaseElement� to  �Documentation�.      Both relationships should be drawn separately. See Figure 8.5 (p.55),  where they are correctly drawn.

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15578: Page 72. Artifact incorrectly identified as a Flow Element (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Table 8.23. Row �categorizedFlowElements�      It says   �The FlowElements attribute identifies all of the elements (e.g., Events, Activities, Gateways, and Artifacts) that are within the boundaries of the Group.�      The name of the model association is �categorizedFlowElements�, not �FlowElements�.      Model Association �categorizedFlowElements� is of type �FlowElement�, but �Artifact� is not a �FlowElement� (see Figure 8.8, page 66; and Figure 8.22, page 87).  So �Artifacts� cannot be examples of elements identified by �categorizedFlowElements�.      Then, it should say   �The categorizedFlowElements model association  identifies all of the Flow Elements (e.g., Events, Activities, and Gateways)  that are within the boundaries of the Group.�

Resolution:
Revised Text:
Actions taken:
September 17, 2010: received issue

Issue 15579: Page 77. Incomplete sentence (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In Sub-Section Key-based Correlation.      It says   �The idea is to use a joint Conversation �token� which is used (passed to and received from) and outgoing and incoming Message.�      The sentence is incomplete.   Furthermore, the word �incoming� is underlined, but it is not clear the purpose of doing this.

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15580: Page 78. Wrong association type in Table 8.32 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Table 8.32. Row �type�      It says   �type: string [0..1]�      Model Association �type� is an �ItemDefinition� (see Figure 8.17, page 76).       Then, it should say   �type: ItemDefinition [0..1]�

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15581: Page 128. Wrong name of Conversation �Delivery/Dispatch Plan� (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:   �� a Message exchange in the Delivery Negotiation leads to Shipment Schedule, Delivery Planning and Delivery/Dispatch Conversations and these could be combined ��      The name of the Conversation is �Delivery/Dispatch Plan�, not �Delivery/Dispatch�. See Figure 9.18. p.127.      Then, it should say:   �� a Message exchange in the Delivery Negotiation leads to Shipment Schedule, Delivery Planning and Delivery/Dispatch Plan Conversations and these could be combined ��     �Delivery/Dispatch� should be replaced by �Delivery/Dispatch Plan�

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15582: Page 130. Nonexistent Conversation �Special Cover� is mentioned (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:  �An example is Delivery Planning which leads to Carrier Planning and Special Cover.�       Conversation �Special Cover� is not shown in Figure 9.18, p.127.     Maybe Conversation �Special Cover�  is the Conversation between Shipper and Insurance (Figure 9.18), which has not name.

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15583: Page 132. �Communication� instead of �Conversation� Figure 9.23 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �Figure 9.23 � A Communication element�      �Communication� element in Beta 1 is �Conversation� in Beta 2.      Then, is should be   �Figure 9.23 � A Conversation element�    �Communication� should be replaced by �Conversation�

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Discussion:

Issue 15584: Page 140-141. Wrong name of model associations (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

a)    Page 140      It says:   �A Collaboration uses ParticipantAssociations and MessageFlowAssociations for this purpose.�      The name of the model associations are:  participantAssociatios  and messageFlowAssociations (see Figure 9.33, p. 142;  Table 9.1, p.111).      Then, it should say:  �A Collaboration uses participantAssociatios and messageFlowAssociations for this purpose.�      �ParticipantAssociations and MessageFlowAssociations� should be replaced by �participantAssociatios and messageFlowAssociations�  --------------------------------------------------------------------------      b)   Page 140      It says:   �To handle the Participants, the innerParticipant of a ParticipantAssociation refers to a Participant in the Choreography, while the outerParticipant refers to ��      The name of the model associations are:  innerParticipantRef and outerParticipantRef  (see Figure 9.33, p. 142;  Table 9.7, p.121).      Then, it should say:  �To handle the Participants, the innerParticipantRef of a ParticipantAssociation refers to a Participant in the Choreography, while the outerParticipantRef  refers to ��       �innerParticipant� should be replaced by �innerParticipantRef�   �outerParticipant� should be replaced by �outerParticipantRef  �   --------------------------------------------------------------------------      c) Page 141      It says:   ��Participants could be assumed to be the inner and outerParticipants of a ParticipantAssociation.�      The name of the model associations are:  innerParticipantRef and outerParticipantRef  (see Figure 9.33, p. 142;  Table 9.7, p.121).      Then, it should say:   ��Participants could be assumed to be the innerParticipantRef and outerParticipantRef  of a ParticipantAssociation.�       �inner and outerParticipants� should be replaced by �innerParticipantRef and outerParticipantRef  �  --------------------------------------------------------------------------      d)  Page 141      It says:   �To handle Message Flows, the innerMessageFlow of a MessageFlowAssociation refers to a Message Flow in the Choreography, while the outerMessageFlow refers to ��      The name of the model associations are:  innerMessageFlowRef and outerMessageFlowRef (see Figure 9.33, p. 142;  Table 9.9, p.125).      Then, it should say:   �To handle Message Flows, the innerMessageFlowRef of a MessageFlowAssociation refers to a Message Flow in the Choreography, while the outerMessageFlowRef refers to ��       �innerMessageFlow� should be replaced by �innerMessageFlowRef�   �outerMessageFlow� should be replaced by �outerMessageFlowRef�

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15585: Page 154. �Choreography� instead of �Process (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:   �Some BPMN elements are common to both Process and Choreography, as well as Collaboration; they are used in these diagrams. The next few sections will describe the use of Messages, Message Flows, Participants, Sequence Flows, Artifacts, Correlations, Expressions, and Services in Choreography.�      Chapter 10 is devoted to Processes, not to Choreographies.  The same paragraph is in 9.1.1 (p.112), where �the next sections� describe the use of BPM elements in Choreography. But in 10.1.2, they describe the use of BPM elements in Processes.      It should say:   �Some BPMN elements are common to both Process and Choreography, as well as Collaboration; they are used in these diagrams. The next few sections will describe the use of Messages, Message Flows, Participants, Sequence Flows, Artifacts, Correlations, Expressions, and Services in Process.�    �and Services in Choreography� should be replaced by �and Services in Process�

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15586: Pages 165-167. �implementation� attribute of Send and Receive Tasks (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

a)  Page 165       Table 10.9. Row �implementation�.       It says:   �� that will be used to send and receive the Messages.�      Table 10.9 describes Send Task element, so the Messages are sent only.      Then, it should say:   �� that will be used to send the Messages.�      �send and receive� should be replaced by �send�  ---------------------------------------------------------------------      b) Page 167      Table 10.10. Row �implementation�.       It says:   �� that will be used to send and receive the Messages.�      Table 10.10 describes Receive Task element, so the Messages are received only.      Then, it should say:   �� that will be used to receive the Messages.�

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15587: Page 171. �Manual Task� instead of �User Task� (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

First paragraph says:   �The User Task inherits the attributes and model associations of Activity (see Table 10.3), but does not have any additional attributes or model associations.�      This sentence is in sub-section �Manual Task�, which starts on page 170.      Then, it should say:   �The Manual Task inherits the attributes and model associations of Activity (see Table 10.3), but does not have any additional attributes or model associations.�    �User Task� should be replaced by �Manual Task�

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15588: Page 190. Paragraph needs to be nested (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Paragraph:  �If the details of the called Process are available, then the shape of the Call Activity will be the same as a expanded Sub-Process, but the boundary of the shape MUST have a thick line (see Figure 10.41).�      This paragraph  should  be a sub-bullet of  �If the Call Activity calls a Process, then there are two (2) options:�, because it describes the second option.

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15589: Page 224. Typos (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

a) Sub-section Send Task Mapping       It says:   ��there MUST be at most inputSet set and at most one Data Input on the Send Task.�      It should say:   ��there MUST be at most one inputSet set and at most one Data Input on the Send Task.�      �at most inputSet� should be replaced by �at most one inputSet�      b) Sub-section Recieve Task Mapping  It says:  ��there MUST be at most outputSet set and at most one Data Output on the Receive Task.�      It should say:   ��there MUST be at most one outputSet set and at most one Data Output on the Receive Task.�    �at most outputSet� should be replaced by �at most one outputSet�

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15590: Page 246. Typo (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Sub-Section Start Event Triggers      It says:   �Start Events can be used for three types of Processes:�      But four are listed. The third (Global Process) is explained in Sub-Sections: �Start Event for Top-Level Processes� and �Start Events for Sub-Processes�.        Then, it should say:   �Start Events can be used for four types of Processes:�

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15591: Page 255. Message End Event sends Messages (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Table 10.88. Row ��Message�.      It says   �The actual Participant from which the Message is received can be identified ��      Table 10.88 describes End Event Types, so the Message can only be sent.      Then, it should say   �The actual Participant to which the Message is sent can be identified ��      �from which� should be replaced by �to which�  �is received� should be replaced by �is sent�

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15592: Page 281. Wrong name of Figure 10.92 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Figure 10.92.      It says   �Figure 10.92 � Multiple Events�      Figure 10.92 shows Parallel Multiple Events, not Multiple Events (see Figure 10.90, p.280).      It should say   �Figure 10.92 � Parallel Multiple Events�    �Multiple� should be replaced by �Parallel Multiple�

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15593: Page 283. The number of types of Event handlers (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:   �There are three (3) types of Event handlers: those that start a Process, those that are part of the normal Sequence Flow, and those that are attached to Activities, either via boundary Events or via separate inline handlers in case of an Event Sub-Process.�      Actually, there are four Sub-Sections:  1) Handling Start Events (p.283)  2) Handling Events within normal Sequence Flow (Intermediate Events) (p. 284)  3) Handling Events attached to an Activity (Intermediate boundary Events and Event Sub-Processes) (p.285). With two sub-sub-.sections.  4) Handling End Events (p.288)     Then, it should say:   �There are four (4) types of Event handlers: those that start a Process, those that are part of the normal Sequence Flow, those that are attached to Activities, either via boundary Events or via separate inline handlers in case of an Event Sub-Process, and those that end a Process.�      �three (3) types� should be replaced by �four (4) types�  �and those that are attached to Activities� should be replaced by �those that are attached to Activities�  �Event Sub-Process.� should be replaced by �Event Sub-Process, and those that end a Process.�

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue
September 18, 2010: received issue

Issue 15595: Page 312. Wrong name of Figure 10.122 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says   �Figure 10.122 - Monitoring Class Diagram�      Figure describes A Compensation Event Sub-Process (see last paragraph on page 311).      Then, it should say   �Figure 10.122 - Compensation Event Sub-Process�    �Monitoring Class Diagram� should be replaced by �Compensation Event Sub-Process

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15596: Page 352. �escalation� instead of �non- interrupting (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Table 11.7. Row �Timer: Attached to Activity boundary�      It says:   �This includes both interrupting and escalation Events.�      �Escalation� does not make sense here.      Then, it should say:   �This includes both interrupting and non- interrupting Events.�    �escalation� should be replaced by �non- interrupting�

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15597: Page 352. �Cancel� instead of �Compensation (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

a) Table 11.7. Row �Compensation: in Normal Flow�      It says:   ��there would be no indicator as to who is the source of the Cancel.�      Compensation Event is described  here.      Then, it should say:   ��there would be no indicator as to who is the source of the Compensation.�      �Cancel� should be replaced by �Compensation�       b) Table 11.7. Row �Compensation: Attached to Activity boundary�      It says:   ��on the Participant Band that is receiving the Cancel.�      Compensation Event is described  here.      Then, it should say:    ��on the Participant Band that is receiving the  Compensation.�    �Cancel� should be replaced by �Compensation

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15598: Page 363. Wrong names of Choreography Tasks (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Figure 11.40.      Choreography Task names are all the same: Choreography Task 1.    They should be: Choreography Task 1, Choreography Task 2, and Choreography Task 3.

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15599: Page 364. Number of Choreography Activities preceding an Inclusive Gateway (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:   �For the split behavior to be enforced, the initiators of Choreography Activities immediately following the Gateway and the receiver of Choreography Activities immediately preceding the Gateway are the same Participant (i.e., A).�      It is said �initiators of Choreography Activities�, meaning that there will be multiple Choreography Activities after the Gateway.      But it is said �the receiver of Choreography Activities�, so it is not clear what the author wanted to communicate: One or multiple Choreography Activities before the Gateway. Both cases are possible (see page. 297).      In the example (Figure 11.42, p.365) only one Choreography Task precedes the Gateways, but it is just one possible configuration.      Then, it should say:  1)  �For the split behavior to be enforced, the initiators of Choreography Activities immediately following the Gateway and the receiver of Choreography Activity immediately preceding the Gateway are the same Participant (i.e., A).�      or    2) �For the split behavior to be enforced, the initiators of Choreography Activities immediately following the Gateway and the receivers of Choreography Activities immediately preceding the Gateway are the same Participant (i.e., A).�

Resolution:
Revised Text:
Actions taken:
September 18, 2010: received issue

Issue 15601: Figure 10.30 is incorrect (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Clarification
Severity: Minor
Summary:

Figure 10.30 shows a collapsed Event Sub-Process. This figure is supposed to have an event marker in the upper left of the shape (as described in the bullet directly above it).

Resolution:
Revised Text:
Actions taken:
September 19, 2010: received issue

Issue 15602: Page 274. Wrong role name �errorRef� in Table 10.96 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Table 10.96. Row �error�      It says:   �error: Error [0..1]�      It should say:   �errorRef: Error [0..1]�    See Figure 10.80  (p.274).

Resolution:
Revised Text:
Actions taken:
September 19, 2010: received issue

Discussion:

Issue 15636: Is a Choreography a type of Process? (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

ANTECEDENTS:        i)  Chapter/Section 7.1.1. Page 23, it says:   �There are three basic types of sub-models within an end-to-end BPMN model:   Processes (Orchestration), including:     Private non-executable (internal) Business Processes     Private executable (internal) Business Processes     Public Processes   Choreographies  Collaborations, which can include Processes and/or Choreographies      A view of Conversations�  -------------------------------------------------------------------      ii) Chapter/Section 7.3. Page 41, it says:   �The BPMN 2.0 aims to cover three basic models of Processes: private Processes (both executable and non-executable), public Processes, and Choreographies.�  --------------------------------------------------------------------      iii) Chapter/Section 9. Page 109, it says:  �Collaborations  � MAY include Processes within the Pools and/or Choreographies between the Pools�  --------------------------------------------------------------------      iv) Chapter/Section 11. Page 325, it says:   �A Choreography is a type of process, but differs in purpose and behavior from a standard BPMN Process.�   ----------------------------------------------------------------------      v) Throughout   the entire document.  In several places it is used the expression �Choreography Process�   instead of   �Choreography�.      ----------------------------------------------------------------------          COMMENTS:      a) Classifications on pages 23 and 41 are different. It is not clear the difference between �types of sub-models within an end-to-end BPMN model� and �basic models of Processes�. In the first case �Choreographies are not Processes�, but in the second �Choreographies are Processes�.      b) According to UML models �Choreographies are not Processes�. See  Figure 9.1 (p 109), Figure 10.2 (p. 150) and Figure 11.1 (p. 326).      c) Maybe in a broad sense a �Choreography IS a Process�. But the formal definitions (UML models in BPMN 2.0 specification) make a clear distinction between both concepts. Which � of course �are tightly interrelated.          SUGGESTIONS:       Modify the classification on page 41 in order to be consistent with the classification on page 23.      Replace �Choreography Process� by �Choreography�.    On page 325 replace �A Choreography is a type of process, ��  by  �A Choreography is like a process, ..�

Resolution:
Revised Text:
Actions taken:
September 23, 2010: received issue

Discussion:

Issue 15637: Some Tokens consumed by Complex Gateways don�t reach end nodes (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

ANTECEDENTS:        i)  Chapter/Section 7.1.1. Page 27 (�Understanding the Behavior of Diagrams�), it says:   �A Start Event generates a token that MUST eventually be consumed at an End Event. (which MAY be implicit if not graphically displayed).�.   --------------------------------------------------------------------------      ii) Chapter/Section 10.4.3. Page 254, it says:   �All the tokens that were generated within the Process MUST be consumed by an End Event before the Process has been completed.�       �For Processes without an End Event, a token entering a path-ending Flow Object will be consumed when the processing performed by the object is completed (i.e., when the path has completed), as if the token had then gone on to reach an End Event. When all tokens for a given instance of the Process are consumed, then the Process will reach a state of being completed.�  --------------------------------------------------------------------------      iii) Chapter/Section 10.4.3. Page 257, it says:   �All tokens that are generated at the Start Event for that Process MUST eventually arrive at an End Event.�.  --------------------------------------------------------------------------      iv) Chapter/Section 13.1. Page 440, it says:   �For a Process instance to become completed, all tokens in that instance MUST reach an end node, i.e., a node without outgoing Sequence Flows.�  --------------------------------------------------------------------------          COMMENTS:       These statements are not entirely correct because  Complex Gateways can consume tokens and do not generate an outgoing token. These token �are lost� before they could reach and end node,  but the Process instance can become complete anyway.      In the waiting-for-reset phase the Complex Gateway �consumes a token from each incoming Sequence Flow that has a token and from which it had not yet consumed a token in the first phase �the Gateway might not produce any tokens in this phase and no exception is thrown.�  (Table 13.5, p.454).   Then, the tokens are consumed by the Gateway and will never reach any end node. For example, this is the normal behavior of a  3-of-5 discriminator, where the last two tokens will be consumed by the Gateway and lost.          SUGGESTION:    State that in order to be completed all tokes in a Process instance MUS be consumed, which is usually (normally) achieved when the tokens reach end nodes.

Resolution:
Revised Text:
Actions taken:
September 23, 2010: received issue

Issue 15638: Is �Association� a type of �Artifact� or not? (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

ANTECEDENTS:        i) Chapter/Section  7.2. Page 28, it says:      �There are four (4) Connecting Objects:      Sequence Flows      Message Flows      Associations      Data Associations�      and       �The current set of Artifacts includes:     Group     Text Annotation�      --------------------------------------------------------------------------      ii) Chapter/Section 8.3.1. Figure 8.8. Page 66.       In Figure 8.8 �Association�  is a type of  �Artifact�.  --------------------------------------------------------------------------      iii) Chapter/Section 11.3.2. Page 331.   When describing Artifacts in Choreographies, it says: �Both Text Annotations and Groups can be used within Choreographies and all BPMN diagrams. There are no restrictions on their use.�      --------------------------------------------------------------------------           COMMENTS:      In (i)  �Associations� are identified as connectors, and are not included among  the �Artifacts�.       In (ii) According to the Meta-model  �Association� is an �Artifact�, and it is described inside Section �8.3.12 Artifacts� (p.67).  but in other parts of the document this fact is ignored.      In (iii) �Associations� are not mentioned as a type of �Artifact�.          SUGGESTION:    On pages 28 and 331, state that �Association� is a type of �Artifact� in order to be consistent with the meta-model.

Resolution:
Revised Text:
Actions taken:
September 23, 2010: received issue

Issue 15639: Number of Participant bands and Messages in a Choreography Task (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

i) Chapter/Section 7.2.2. Page 32 . Table 7.2. Row �Choreography Task�. It says:   �A Choreography Task is an atomic Activity in a Choreography (see page 333). It represents a set of one (1) or more Message exchanges. Each Choreography Task involves two (2) Participants. The name of the Choreography Task and each of the Participants are all displayed in the different bands that make up the shape�s graphical notation. There are two (2) or more Participant Bands and one Task Name Band.�    --------------------------------------------------------------------------      ii) Chapter/Section 11.4. Page 332. Figure 11.6.   Model association from �ChoreographyTask� to �MessageFlow� (role name �messageFlowRefs�) has multiplicity [1..2]  --------------------------------------------------------------------------      iii) Chapter/Section 11.4. Page 332. Table 11.1. Row �participantRefs�. It says:  �participantRefs: Participant [2..*]�  --------------------------------------------------------------------------      iv) Chapter/Section 11.4.1. Page 333. It says:   �A Choreography Task is an atomic Activity in a Choreography Process. It represents an Interaction, which is one (1) or two (2) Message exchanges between two (2) Participants. Using a Collaboration diagram to view these elements (see page 109 for more information on Collaboration), we would see the two (2) Pools representing the two (2) Participants of the Interaction ��  --------------------------------------------------------------------------      v) Chapter/Section 11.4.1. Page 333. It says:   �There are two (2) or more Participant Bands and one Task Name Band (see Figure 11.8).�  --------------------------------------------------------------------------      vi) Chapter/Section 11.4.1. Page 335. It says:   �The three (3) bands in the Choreography Task shape provide the distinction between this type of Task and an Orchestration Task (in a traditional BPMN diagram).�  --------------------------------------------------------------------------      vii) Chapter/Section 11.4.1. Page 338. Table 11.2. Row �messageFlowRef�. It says:  �messageFlowRef: Message Flow [1..*]�  �Although not graphical represented, Choreography Task contain one (1) or more Message Flows that represent the interaction(s) between the Participants referenced by the Choreography Task.�  --------------------------------------------------------------------------          COMMENTS:      There are inconsistencies concerning the number of Messages, Participants and Participant Bands in a Choreography Task.      In (i)  Messages: 1 or more.  Participants: 2  Participant bands: 2 or more      In (ii)  Messages: 1 or 2.      In (iii)   Participants: 2 or more.   (Because �ChoreographyTask� inherits �participantRefs� from �ChoreographyActivity�.)      In (iv)  Messages: 1 or 2.  Participants: 2      In (v)   Participant bands: 2 or more      In (vi)   Participant bands: 2.  (There are 3 bands, one of them is de Task Name band.)      In (vii)   Messages: 1 or more.        It seems that the correct numbers should be:  Messages: 1 or 2  Participants: 2  Task name band: 1  Participants bands: 2  Total bands: 3 (= 1 + 2)            SUGGESTIONS:      In (i)   �one (1) or more Message exchanges�   should be replaced by   �one (1) or two (2) Message exchanges�  �two (2) or more Participant Bands�   should be replaced by   �two (2) Participant Bands�      In (ii) nothing       In (iii)   A new model association should be drawn in Figure 11.6 from �ChoreographyTask� to �Participant�, which actually would not be a new model association but a redefinition of �participantsRefs� form �ChoreographyActivity� to �Participant�.       It should be annotated: [2..2] +participantRefs {redefines participantRefs}  (See OMG Unified Modeling LanguageTM (OMG UML), Infrastructure. formal/2009-02-04. Pages 113, 150)      In (iv) nothing      In (v)   �two (2) or more Participant Bands�   should be replaced by   �two (2) Participant Bands�      In (vi) nothing      In (vii)   �messageFlowRef: Message Flow [1..*]� should be replaced by �messageFlowRefs: Message Flow [1..2]�      �one (1) or more Message Flows� should be replaced by �one (1) or two (2) Message Flows�      A new row should be added to Table 11.2  �participantRefs: Participant [2..2]�  �A Choreography Task has two (2)  Participants (see page 115 for more information on Participants). This is a redefinition of participantRefs of ChoreographyActivity (see Table 11.1).�

Resolution:
Revised Text:
Actions taken:
September 23, 2010: received issue

Issue 15640: Inconsistencies related to Default Sequence Flow (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

i) Chapter/Section  7.2.2. Page 34. Table 7.2. Row �Default flow�. It says:  �For Data-Based Exclusive Gateways or Inclusive Gateways, one type of flow is the Default condition flow ��  --------------------------------------------------------------------------      ii) Chapter/Section 8.3.9. Page 90  According to Figure 8.24 a Sequence Flow can be the �default flow� of many Gateways simultaneously (see multiplicity [0..*] of roles exclusiveGateway, inclusiveGateway and complexGateway).        The same occurs in Figure 10.104 (p.297); Figure 10.107 (p. 299); Figure 10.109 (p.301); and Figure 10.114 (p.304).  --------------------------------------------------------------------------      iii) Chapter/Section 8.3.13. Page 98. Figure 8.35.  Multiplicity of role �activity� (from �SequenceFlow� to �Activity�) is [1..1].       The same occurs in Figure 10.6 (p.155).  --------------------------------------------------------------------------      iv) Chapter/Section 11.3.1. Page 330. It says:   �Default Sequence Flows: For Exclusive Gateways, Inclusive Gateways, and Choreography Activities that have Conditional Sequence Flows, one of the outgoing Sequence Flows MAY be a Default Sequence Flow. Because the other outgoing Sequence Flows will have appropriately visible of data as described above, the Participants would know if all the other conditions would be false, thus the Default Sequence Flow would be selected and the Choreography would move down that Sequence Flow.�  --------------------------------------------------------------------------      v) Chapter/Section 11.4. Page 332. Figure 11.6.  �ChoreographyActivity� is not associated with �SequenceFlow� for optional default.       The same occurs in Figure 8.35, p. 98.  ---------------------------------------------------------------------------        COMMENTS:      In (i): �Default flows� are used by Complex Gateways and Activities too, but they are not mentioned. Furthermore, in BPMN 2 the name is �Exclusive Gateway� not �Data-Based Exclusive Gateway� (see  p. 33)       In (ii):  It is impossible for a Sequence Flow to be the �default flow� of more than one  Gateway or Activity simultaneously, because a Sequence Flow has only one FlowNode as its sourceRef (Figure 8.35, p.98; see also Section 8.3.13).      In (iii):  Multiplicity [1..1] of role �activity� (from �SequenceFlow� to �Activity�) means that every Sequence Flow  is the default of exactly one Activity, which is not possible.       In (iv):  Complex Gateways can have default in Orchestrations, but they are not mentioned for Choreographies (� For Exclusive Gateways, Inclusive Gateways, and Choreography Activities that have Conditional Sequence Flows �).       In (v):  Choreography Activities can have default, but the corresponding  associations between �ChoreographyActivity� and �SequenceFlow� in Figures 8.35  and 11.6  are  not  shown           SUGGESTIONS:      In (i): It says:   �For Data-Based Exclusive Gateways or Inclusive Gateways, one type of flow is the Default condition flow ��      It should say:  �For Exclusive, Inclusive or Complex Gateways, or Activities one type of flow is the Default condition flow ��        In (ii): Multiplicity  of roles exclusiveGateway, inclusiveGateway and complexGateway in Figures 8.24, 10.104, 10.107, 10.109 and 10.114 should be changed from [0..*]  to [0..1].   Furthermore, in Figures 8.24 and 10.104 a constrain {XOR } should be used in order to underline that a Sequence Flow cannot be a default flow of two or more Flow Nodes simultaneously (See OMG Unified Modeling LanguageTM (OMG UML), Infrastructure. formal/2009-02-04. Pages 41, 42, 43). This {XOR] must include the associations from �SequenceFlow� to �ExclusiveGateway�, � EnclusiveGateway�, � ComplexGateway�,  �Activity� and  � ChoreographyActivity�.      In (iii): Multiplicity  of role �activity� (from �SequenceFlow� to �Activity�) in Figures 8.35 and 10.6 should be changed from [1..1]  to [0..1].      In (iv): If default are allowed in Choreographies for Complex Gateways, then �For Exclusive Gateways, Inclusive Gateways, and Choreography Activities that have Conditional Sequence Flows�   should be replaced by  �For Exclusive Gateways, Inclusive Gateways,, Complex Gateways, and Choreography Activities that have Conditional Sequence Flows�.      In (v): The corresponding model associations (between �ChoreographyActivity� and �SequenceFlow� : +activity [0..1] --> +default [0..1]) should be added to Figures 8.35 and 11.6.   Also, the corresponding  row �default� should be added  to Table 11.1 (p.332). (Similar to row �default� in Table 10.3, p. 156).

Resolution:
Revised Text:
Actions taken:
September 23, 2010: received issue

Issue 15645: Page 83. Wrong reference to Table 8.42 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:  �The Escalation element inherits the attributes and model associations of BaseElement (see Table 8.5), through its relationship to RootElement. Table 8.41 presents the additional model associations of the Error element:�      Table 8.41  is referenced, but it is 8.42 which should be mentioned.      Then, it should say:  �The Escalation element inherits the attributes and model associations of BaseElement (see Table 8.5), through its relationship to RootElement. Table 8.42 presents the additional attributes and model associations of the Escalation element:�        �Table 8.41 presents the additional model associations of the Error element� should be replaced by �Table 8.42 presents the additional attributes and model associations of the Escalation element�

Resolution:
Revised Text:
Actions taken:
September 27, 2010: received issue

Issue 15662: Page 106. Wrong role name �errorRef� in Table 8.66 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Table 8.66. Row �errorRef�      It says:   �errorRef: Error [0..*]�      It should say:   �errorRefs: Error [0..*]�    See Figure 8.36  (p.104).

Resolution:
Revised Text:
Actions taken:
September 28, 2010: received issue

Issue 15663: Inconsistencies and contradictions concerning Error element (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

ANTECEDENTS: i) Chapter/Section 8.3.3. Page 82. Table 8.41. Row �name�. It says: �name : string� It means that �name� is mandatory. ii) Chapter/Section 8.3.3. Page 82. Table 8.41. Row �errorCode�. It says: �errorCode: string� It means that �errorCode� is mandatory. When describing this attribute three cases are identified: - End Event - Intermediate Event within normal flow - Intermediate Event attached to the boundary of an Activity iii) Chapter/Section 8.4.3. Page 105. It says: �An Operation defines Messages that are consumed and, optionally, produced when the Operation is called. It can also define zero or more errors that are returned when operation fails.� (see Figure 8.36, p.104, Table 8.66, p. 106). iv) Chapter/Section 10.4.1. Page 242. It says: �A trigger that is propagated is forwarded from the location where the Event has been thrown to the innermost enclosing scope instance (e.g., Process level) which has an attached Event being able to catch the trigger �. If no catching Event is found for an error or escalation trigger, this trigger is unresolved.� v) Chapter/Section 10.4.2. Page 250. Table 10.86. Row �Error�. It says: �The Error Start Event is only allowed for triggering an in-line Event Sub- Process. If there is only one (1) EventDefinition associated with the Start Event and that EventDefinition is of the subclass ErrorEventDefinition, then the Event is an Error Start Event and uses a lightning marker (see the figures to the right). Given the nature of Errors, an Event Sub-Process with an Error trigger will always interrupt its containing Process.� vi) Chapter/Section 10.4.3. Page 255. Table 10.88. Row �Error�. It says: �This type of End indicates that a named Error should be generated. All currently active threads in the particular Sub-Process are terminated as a result. The Error will be caught by a Catch Error Intermediate Event with the same errorCode or no errorCode which is on the boundary of the nearest enclosing parent Activity (hierarchically). The behavior of the Process is unspecified if no Activity in the hierarchy has such an Error Intermediate Event. The system executing the process can define additional Error handling in this case, a common one being termination of the Process instance.� vii) Chapter/Section 10.4.4. Page 263. Table 10.90. Row �Error�. It says: �A catch Intermediate Error Event can only be attached to the boundary of an Activity, i.e., it MAY NOT be used in normal flow. If used in this context, it reacts to (catches) a named Error, or to any Error if a name is not specified. Note that an Error Event always interrupts the Activity to which it is attached, i.e., there is not a non-interrupting version of this Event. The boundary of the Event thus always solid (see figure on the right).� viii) Chapter/Section 10.4.5. Page 269. Table 10.93. Row �Error�. Three Error Event Definitions are shown: Start Event Sub-Process (Interrupting) Intermediate Event attached to the boundary of an Activity (interrupting) End Event. ix) Chapter/Section 10.4.5. Page 274. Table 10.96. Row �error�. It says: �error: Error [0..1]� It means that �error� is optional. (By the way, its name should be errorRef, see Figure 10.80, p.274). COMMENTS: In (i) the name of an Error is mandatory, it means that the expression �named Error� carries no information, because every Error �is named�. Furthermore, the name of the Error is not used to identify it, the attribute errorCode is used instead. Then: - in (vi) the sentence �This type of End indicates that a named Error should be generated� is incorrect. - in (vii) the sentence �If used in this context, it reacts to (catches) a named Error, or to any Error if a name is not specified� is incorrect. In (ii) the attribute errorCode should be optional ([0..1]), because sometimes errorCode is not supplied (according to descriptions in Tables 8.41 and 10.88; it is mandatory only when the processType attribute of the Process is set to executable). In (ii) Intermediate Event within normal flow is identified, but it is incorrect, because it doesn�t exist as it is stated in (vii) and (viii). Furthermore, Start Event Sub-Process (Interrupting) is not identified in (ii), but it is in (viii). In (ii) when describing End Event, it is said �If the result is an Error, then the errorCode MUST be supplied (if the processType attribute of the Process is set to executable) This �throws� the Error.� It is confusing because the Error is actually thrown when an instance of Error (the �errorRef� of the ErrorEventDefinition) is thrown. In (iii) it is said that Operations use Errors too. Nevertheless, Errors are described as if they were associated only with Events. In (iv), according to meta-model a catching Error Event may not have an Error instance associated or can be associated to an Error instance without errorCode. In both cases �no catching Event is found�, but it is not clear whether both situations must be treated equally or not. In (v) nothing is said about the presence or absence of errorCode as in (vi). In (vi) the expression �named Error� is used, which (as stated above) is incorrect. It can be deduced that when an Error is thrown by the End Event it must contain an errorCode. But it not clear if an Error End Event must or must not throw an Error (which is optional, see ix). Besides, the Error can be catching by a Event Sub-Process, what it is not mentioned in (vi). In (vii) the expression �named Error� is used, which (as stated above) is incorrect. It seems that �name� is used instead of �errorCode�. It is not clear what happen when no Error is associated to de EventDefinition: Does it react as if an Error without errorCode where associated? In (ix) attribute errorRef is optional, but there are no rules concerning when and where an Error should be thrown. Nothing is said about processType attribute of the Process. So, it is possible that �processType attribute of the Process is set to executable� and no Error is provided, in consequence no errorCode could be supplied. Summary of problems: - The name of the Error cannot be used to match Errors, errorCode must be used instead. - According to some descriptions errorCode must be optional. - According to the meta-model errorRef is optional, but it is not clear when and where this attribute should be provided. - Error is described as if it were used by Events only, but it used by Operation too. SUGGESTIONS: - Remove all references to �named Errors� and the use of attribute �name� as a matching mechanism. - Define whether errorRef (in ErrorEventDefinition element) will be optional or not. - Define whether errorCode (in Error element) will be optional or not. - Describe all rules concerning errorRef and errorCode in Tables 10.86, 10.88 and 10.90 (where Error Start Event, Error End Event and Error Intermediate Event are described). - Describe rules concerning the use or Errors by Operations in section 8.4.3. - Remove from Tables 8.41 and 10.96 (where Error and ErrorEventDefinition are described) the rules concerning Events (remember that Errors are used by Operations too, and in the future more BPMN element could used Errors too). At least these issues should be clarified: a) If the processType attribute of the Process is set to executable, must errorRef or errorCode be supplied? or both? b) If errorRef (in ErrorEventDefinition element) is optional: - Is errorRef optional for a throwing Error End Event? - Is errorRef optional for a catching Error Start and Intermediate Events? If this is the case, what happens when an Error arrives? c) If errorCode (in Error element) is optional: - Is errorCode optional for a throwing Error End Event? - Is errorCode optional for a catching Error Start and Intermediate Events? d) Can two instances of Error share the same errorCode? - If the modeler want to match two Error Events (one throwing and one catching), must he/she provide the same Error to both ErrorEventDefinitions or two different Errors with the same errorCode? (According to the meta-model both alternatives are allowed, see Figure 10.80.)

Resolution:
Revised Text:
Actions taken:
September 28, 2010: received issue

Issue 15665: Inconsistencies and contradictions concerning Escalation element (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

ANTECEDENTS: i) Chapter/Section 8.3.4. Page 83. Table 8.42. Row �name�. It says: �name : string� It means that �name� is mandatory. ii) Chapter/Section 8.3.4. Page 83. Table 8.42. Row �escalationCode�. �escalationCode: string� It means that �escalationCode� is mandatory. When describing this attribute three cases are identified: - End Event - Intermediate Event within normal flow - Intermediate Event attached to the boundary of an Activity iii) Chapter/Section 10.4.1. Page 242. It says: �A trigger that is propagated is forwarded from the location where the Event has been thrown to the innermost enclosing scope instance (e.g., Process level) which has an attached Event being able to catch the trigger �. If no catching Event is found for an error or escalation trigger, this trigger is unresolved.� iv) Chapter/Section 10.4.2. Page 250. Table 10.86. Row �Escalation�. It says: �Escalation Event Sub-Processes implement measures to expedite the completion of a business Activity, should it not satisfy a constraint specified on its execution (such as a time-based deadline). The Escalation Start Event is only allowed for triggering an in-line Event Sub- Process. If there is only one (1) EventDefinition associated with the Start Event and that EventDefinition is of the subclass EscalationEventDefinition, then the Event is an Escalation Start Event and uses an arrowhead marker�� v) Chapter/Section 10.4.3. Page 255. Table 10.88. Row �Escalation�. It says: �This type of End indicates that an Escalation should be triggered. Other active threads are not affected by this and continue to be executed. The Escalation will be caught by a Catch Escalation Intermediate Event with the same escalationCode or no escalationCode which is on the boundary of the nearest enclosing parent Activity (hierarchically). The behavior of the Process is unspecified if no Activity in the hierarchy has such an Escalation Intermediate Event.� vi) Chapter/Section 10.4.4. Page 263. Table 10.90. Row �Escalation�. It says: �This type of Event is used for handling a named Escalation. If attached to the boundary of an Activity, the Intermediate Event catches an Escalation. In contrast to an Error, an Escalation by default is assumed to not abort the Activity to which the boundary Event is attached...� vii) Chapter/Section 10.4.5. Page 269. Table 10.93. Row �Escalation�. Six Escalation Event Definitions are shown: Start Event Sub-Process (Interrupting and non-interrupting) Intermediate Event attached to the boundary of an Activity (interrupting and non-interrupting) Intermediate Event within normal flow End Event viii) Chapter/Section 10.4.5. Page 275. Table 10.97. Row �escalationRef�. It says: �escalationRef: Escalation [0..1]� It means that �escalationRef� is optional. COMMENTS: In (i) the name of an Escalation is mandatory, it means that the expression �named Escalation� carries no information, because every Escalation �is named�. Furthermore, the name of the Escalation is not used to identify it, the attribute escalationCode is used instead. Then: - in (vi) the sentence �This type of Event is used for handling a named Escalation� is incorrect. In (ii) the attribute escalationCode should be optional ([0..1]), because sometimes escalationCode is not supplied (according to descriptions in Tables 8.42 and 10.88; it is mandatory only when the processType attribute of the Process is set to executable). In (ii) Start Event Sub-Process (Interrupting) is not identified in, but it is in (vii). In (ii) when describing End Event, it is said �If the Result is an Escalation, then the escalationCode MUST be supplied (if the processType attribute of the Process is set to executable). This �throws� the Escalation.� It is confusing because the Escalation is actually thrown when an instance of Escalation (the �escalationRef� of the EscalationEventDefinition) is thrown. In (iii), according to meta-model a catching Escalation Event may not have an Escalation instance associated or can be associated to an Escalation instance without escalationCode. In both cases �no catching Event is found�, but it is not clear whether both situations must be treated equally or not. In (iv) nothing is said about the presence or absence of escalationCode as in (v). In (v) it can be deduced that when an Escalation is thrown by the End Event it must contain an escalationCode. But it not clear if an Escalation End Event must or must not throw an Escalation (which is optional, see viii). Besides, the Escalation can be catching by a Event Sub-Process, what it is not mentioned in (v). In (vi) the expression �named Escalation� is used, which (as stated above) is incorrect. Furthermore, nothing is said about the presence or absence of escalationCode as in (v). In (viii) attribute escalationRef is optional, but there no rules concerning when and where an Escalation should be thrown. Nothing is said about processType attribute of the Process. So, it is possible that �processType attribute of the Process is set to executable� and no Escalation is provided, in consequence no escalationCode could be supplied. Summary of problems: - The name of the Escalation cannot be used to match Escalations, escalationCode must be used instead. - According to some descriptions escalationCode must be optional. - According to the meta-model escalationRef is optional, but it is not clear when and where this attribute should be provided. - Escalation is described as if it were used by Events only, but in the future it could used by others elements (as Error is used by Events and Operations). SUGGESTIONS: - Remove all references to �named Escalations� and the use of attribute �name� as a matching mechanism. - Define whether escalationRef (in EscalationEventDefinition element) will be optional or not. - Define whether escalationCode (in Escalation element) will be optional or not. - Describe all rules concerning escalationRef and escalationCode in Tables 10.86, 10.88 and 10.90 (where Escalation Start Event, Escalation End Event and Escalation Intermediate Event are described). - Remove from Tables 8.42 and 10.97 (where Escalation and EscalationEventDefinition are described) the rules concerning Events (remember that Escalations could be used by other elements too). At least these issues should be clarified: a) If the processType attribute of the Process is set to executable, must escalationRef or escalationCode be supplied? or both? b) If escalationRef (in EscalationrEventDefinition element) is optional: - Is escalationRef optional for a throwing Escalation End and Intermediate Events? - Is escalationRef optional for a catching Escalation Start and Intermediate Events? If this is the case, what happens when an Escalation arrives? c) If escalationCode (in Escalation element) is optional: - Is escalationCode optional for a throwing Escalation End and Intermediate Events? - Is escalationCode optional for a catching Escalation Start and Intermediate Events? d) Can two instances of Escalation share the same escalationCode? - If the modeler want to match two Escalations Events (one throwing and one catching), must he/she provide the same Escalation to both EscalationEventDefinitions or two different Escalations with the same escalationCode? (According to the meta-model both alternatives are allowed, see Figure 10.82)

Resolution:
Revised Text:
Actions taken:
September 28, 2010: received issue

Issue 15666: Text mentiones keyword "MUST NOT" 2 times (bpmn2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

In the following text, MUST NOT is listed 2 times:      The keywords �MUST,� �MUST NOT,� �REQUIRED,� �SHALL,� �MUST NOT,� �SHOULD,� �SHOULD NOT,�  �RECOMMENDED,� �MAY,� and �OPTIONAL� in this document are to be interpreted as described in RFC-2119.

Resolution:
Revised Text:
Actions taken:
September 30, 2010: received issue

Issue 15667: Multiple Instances Description: Sequential instead of parallel, Typos (bpmn2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

I found a minor mistake on page 39 concerning multiple instances. The text describes 3 vertical and 3 horizontal lines and declares that both define sequential Multi-Instances. I think that 3 vertical lines should be parallel Multi-Instance (also displayed in the figures).      In addition, there are three typos in this text: horizontal liness -> lines, vertical liness -> lines, sequentail -> sequential      In addition, I think that at the following two positions, the numbers are not correct:   Page 34: See next seven figures. Only five figures concerning Sequence Flow are listed.   Page 35: See next five rows. Only four following lines contain corresponding figures.

Resolution:
Revised Text:
Actions taken:
September 30, 2010: received issue

Issue 15679: Text references DataObject Element although DataState is meant (bpmn2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

The following line is taken from page 213:      The DataState element inherits the attributes and model associations of BaseElement (see Table 8.5). Table 10.54  presents the additional attributes and model associations of the DataObject element:      I think that "DataState" is meant instead of "DataObject".

Resolution:
Revised Text:
Actions taken:
October 4, 2010: received issue

Issue 15682: Figure 10.30 doesn't correspond with Text: Start Event as Marker (bpmn2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

According to page 182, a collapsed Event Sub-Process will show the start event as a marker: If the Event Sub-Process is collapsed, then its Start Event will be used as a marker in the upper left corner of  the shape (see Figure 10.30).      However, Figure 10.30 doesn't show the mentioned marker and, so, doesn't correspond with the text.

Resolution:
Revised Text:
Actions taken:
October 4, 2010: received issue

Issue 15718: Page 224. Typos (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

a) Sub-section Send Task Mapping       It says:   ��there MUST be at most inputSet set and at most one Data Input on the Send Task.�      It should say:   ��there MUST be at most one inputSet set and at most one Data Input on the Send Task.�      �at most inputSet� should be replaced by �at most one inputSet�      b) Sub-section Recieve Task Mapping  It says:  ��there MUST be at most outputSet set and at most one Data Output on the Receive Task.�      It should say:   ��there MUST be at most one outputSet set and at most one Data Output on the Receive Task.�    �at most outputSet� should be replaced by �at most one outputSet�

Resolution:
Revised Text:
Actions taken:
October 11, 2010: received issue

Issue 15719: Page 345. Sub-Choreographies instead of Choreography Activities (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:   �Both Sub-Choreographies can have standard loops and multi-instances. Examples of Choreography Activities with the appropriate markers can be seen in Figure 11.12 and Figure 11.22.�      The purpose of this paragraph is to explain that both Choreography Task and Sub-Choreography can have loop markers.  Figure 11.12  shows Choreography Task Markers, and Figure 11.22 shows Sub-Choreography Markers      Then, it should say:   �Both Choreography Activities can have standard loops and multi-instances. Examples of Choreography Activities with the appropriate markers can be seen in Figure 11.12 and Figure 11.22.�    �Sub-Choreographies� should be replaced by �Choreography Activities�

Resolution:
Revised Text:
Actions taken:
October 11, 2010: received issue

Issue 15720: Inconsistencies concerning Flow Elements (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

i) Chapter/Section  8.3.7. Page 86. It says:  �FlowElement is the abstract super class for all elements that can appear in a Process flow, which are FlowNodes (see page 99, which consist of Activities (see page 155), Choreography Activities (see page 331) Gateways (see page 295), and Events (see page 240)), Data Objects (see page 212), Data Associations (see page 228), and Sequence Flows (see page 97).�       In other words, Flow Elements are:     a) Flow Node          a.1)  Activity          a.2)  Choreography Activity          a.3)  Gateway          a.4)  Event    b) Data Object      c) Data Association    d) Sequence Flow          ii) Chapter/Section  8.3.7. Page 87. Figure 8.22  According to classes and their associations Flow Elements are:     a) Flow Node          a.1) Activity          a.2) Choreography Activity          a.3) Gateway          a.4) Event    b) Data Object      c) DataStoreReference    d) Sequence Flow          iii) Chapter/Section  8.3.8. Page 88. It says:  �Basically, a FlowElementsContainer contains FlowElements, which are Events (see page 240), Gateways (see page 295), Sequence Flows (see page 97), Activities (see page 155), and Choreography Activities (see page 331).�      In other words, Flow Elements are:    a) Event    b) Gateway    c) Sequence Flow    d) Activity    e) Choreography Activity          iv) Chapter/Section 8.3.8. Page 89. Table 8.45. It says: �Flow elements are Events, Gateways, Sequence Flows, Activities, Data Objects, Data Associations, and Choreography Activities.�      In other words, Flow Elements are:    a) Event    b) Gateway    c) Sequence Flow    d) Activity    e) Data Object    f) Data Association    g) Choreography Activity          v) Chapter/Section 10.3.1. Page 212. Figure 10.51.   According to classes and their associations:   DataObjectReference is subclass of FlowElement  DataObject is subclass of FlowElement         vi) Chapter/Section 10.3.1. Page 216. Figure 10.55.  According to classes and their associations:   DataStoreReference is subclass of FlowElement  DataStore is subclass of RootElement          COMMENTS:      In (i), (ii), (iii) and (iv) the lists of Flow Elements are different.      In (i) and (iv) DataAssociation is mentioned as a type of FlowElement, but it is not correct. See Figure 10.64 (p. 229), where it is shown that DataAssociation is direct subclass of BaseElement. Furthermore, DataAssociation in not shown as a subclass of FlowElement in (ii).      In (ii) Data Association is replaced by DataStoreReference      In (iii) Data Object, Data Association, and Data Store Reference are not mentioned.      In (iv) DataObjectReference, DataStore and DataStoreReference are not mentioned.      In (v) DataObjectReference is subclass of FlowElement, but it is not mentioned in (i), (ii), (iii) and (iv).      In (vi) DataStore is not a subclass of FlowElement, as DataObjectReference, DataObject and DataStoreReference. In the document it is not explained the reason for this exclusion.          SUGGESTIONS:      It seems that Flow Elements are:           a) Flow Node          a.1) Activity          a.2) Choreography Activity          a.3) Gateway          a.4) Event    b) Data Object      c) Data Object  Reference    d) Data Store     e) Data Store Reference     f) Sequence Flow      If this is the case, then (i), (ii), (iii), (iv), and (vi) should be updated accordingly.       In (i) remove Data Association           add Data Object Reference, Data Store and Data Store Reference.      In (ii) add Data Object Reference, and Data Store.      In (iii) add Data Object, Data Object  Reference,  Data Store, and Data Store Reference.      In (iv) remove Data Association             add Data Object Reference, Data Store and Data Store Reference.        In (vi) remove generalization from DataStore to RootElement, and add generalization from DataStore to FlowElement.    (v) doesn�t require modifications

Resolution:
Revised Text:
Actions taken:
October 11, 2010: received issue

Issue 15721: Inconsistencies concerning Item-Aware Elements (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

) Chapter/Section 10.3.1. Page 211. It says:   �The elements in the specification defined as item-aware elements are: Data Objects, Data Object References, Data Stores, Properties, DataInputs and DataOutputs.�        ii) Chapter/Section 10.3.1. Page 211. Figure 10.50.  According to classes and their associations item-aware elements are:      a) Properties      b) Data Objects      c) Data Object References       d) DataInputs       e) DataOutputs       f) Data Stores       g) Data Store References        iii) Chapter/Section 10.3.1. Page 212. Figure 10.51.   According to classes and their associations:   DataObjectReference is subclass of FlowElement  DataObject is subclass of FlowElement         iv) Chapter/Section 10.3.1. Page 216. Figure 10.55.  According to classes and their associations:   DataStoreReference is subclass of FlowElement  DataStore is subclass of RootElement      v) Chapter/Section 10.3.1. Page 216. It says:  �The DataStore element inherits the attributes and model associations of FlowElement (see Table 8.44) through its relationship to RootElement, and ItemAwareElement (see Table 10.51).�           COMMENTS:      In (i) Data Stores Reference is not mentioned, but it is shown as a subclass of ItemAwareElement in (ii).      In (iv) DataStore is not a subclass of FlowElement, as DataObjectReference, DataObject and DataStoreReference. In the document it is not explained the reason for this exclusion.      In (v) the sentence is clearly wrong, because it is inconsistent with the class diagrams: RootElement is not subclass of FlowElement.          SUGGESTIONS:      In (i) add Data Store References.      In (iv) remove generalization from DataStore to RootElement, and add generalization from DataStore to FlowElement.      Replace (v)  with �The DataStore element inherits the attributes and model associations of FlowElement (see Table 8.44) and ItemAwareElement (Table 10.51).�       (ii) and (iii) don�t require modifications.

Resolution:
Revised Text:
Actions taken:
October 11, 2010: received issue

Issue 15722: Incorrect multiplicity of dataStoreRef (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

i) Chapter/Section 10.3.1. Page 211. Figure 10.50.  Role dataObjectRef (from DataObjectReference to DataObject) has multiplicity [1..1].  Role dataStoreRef (from DataStoreReference to DataStore) has multiplicity [0..1].        ii) Chapter/Section 10.3.1. Page 212. Figure 10.51.  Role dataObjectRef (from DataObjectReference to DataObject) has multiplicity [1..1].      iii) Chapter/Section 10.3.1. Page 213. Table 10.53. Row �dataObjectRef�. It says:      �dataObjectRef: DataObject�       It means that dataObjectRef  is mandatory (multiplicity [1..1]).      iv) Chapter/Section 10.3.1. Page 216. Figure 10.55.  Role dataStoreRef (from DataStoreReference to DataStore) has multiplicity [0..1].        v) Chapter/Section 10.3.1. Page 217. Table 10.56. Row �dataStoreRef�. It says:      �dataStoreRef: DataStore�       It means that dataStoreRef  is mandatory (multiplicity [1..1]).        COMMENTS:      In (i) and (iv) dataStoreRef  is optional ([0..1])., but in (v) it is said that dataStoreRef  is mandatory ([1..1]). Clearly there is contradiction concerning the multiplicity of dataStoreRef. Furthermore, a question arises: How can a DataStoreReference exist without a referenced DataStore?         SUGGESTIONS:      It seems that dataStoreRef should be mandatory (multiplicity [1..1]), if this is the case:      In (i) and (iv) change multiplicity of dataStoreRef from [0..1] to  [1..1]    (ii), (iii) and (v) don�t require modifications.

Resolution:
Revised Text:
Actions taken:
October 11, 2010: received issue

Issue 15723: Messages Flows can be attached to Events (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Chapter/Section  9.2. Page 113. It says:  �Message Flows can cross the Pool boundary to attach to the appropriate Activity�       COMMENTS:      Messages Flows can be attached to Message Events (see Table 7.4, p. 44). If  a Multiple Event (or  Parallel Multiple Event) contains MessageEventDefinitions, it can be the source or the target of one or more Message Flows too.         SUGGESTION:      It should say:   �Message Flows can cross the Pool boundary to attach to the appropriate Activity or Event�

Resolution:
Revised Text:
Actions taken:
October 11, 2010: received issue

Issue 15724: Service Tasks can be the source or target of Messages Flows (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

i) Chapter/Section 9.4.6. Page 135. It says: �Conversation Links into Activities that are not Send or Receive Tasks indicate that the Activity will send or receive Messages of the Conversation at some level of nesting.� ii) Chapter/Section 10. Page 153. Table 10.1. Row �definitionalCollaborationRef�. It says: �The definitional Collaboration specifies the Participants the Process interacts with, and more specifically, which individual service, Send or Receive Task, or Message Event, is connected to which Participant through Message Flows.� iii) Chapter/Section 10.2.3. Page 162. It says: �The actual Participant whose service is used can be identified by connecting the Service Task to a Participant using a Message Flows within the definitional Collaboration of the Process � see Table 10.1.� iv) Chapter/Section 10.2.3. Page 163. Figure 10.12. According to classes and their associations, ServiceTask is not directly associated to Message, but they are indirectly associated through Operation. v) Chapter/Section 11.4.6. Page 348. It says: �Usually in these cases, the initiating Participant will use a single Activity to handle both the sending and receiving of the Messages. A BPMN Service Task can be used for this purpose and these types of Tasks are often referred to as �request-response� Tasks for Choreography modelers.� vi) Chapter/Section 14.1.2. Page 464. It says: �The partner link associated with the WS-BPEL invoke is derived from both the participant Q that the Service Task is connected to by Mesage Flows, and from the interface referenced by the operation of the Service Task.� vii) Chapter/Section 14.1.2. Page 466. It says: �For those BPMN nodes sending or receiving Messages (i.e., Message Events, Service, send or Receive Tasks) that have an associated key-based Correlation Key, �� COMMENTS: >From (ii) to (vii) it can be deduced that Service Task can be the source and target of Message Flows. SUGGESTIONS: In (i) it should say: �Conversation Links into Activities that are not Send, Receive or Service Tasks indicate that the Activity will send or receive Messages of the Conversation at some level of nesting.� Furthermore: In (ii) �which individual service, Send or� should be replaced by �which individual Service, Send or� In (iii) �Participant using a Message Flows within� should be replaced by �Participant using Message Flows within� In (vi) �Task is connected to by Mesage Flows� should be replaced by �Task is connected to by Message Flows� In (vii) �Service, send or Receive Tasks� should be replaced by �Service, Send or Receive Tasks�

Resolution:
Revised Text:
Actions taken:
October 11, 2010: received issue

Issue 15725: Examples - DI - Lanes and Nested Lanes.bpmn example is not according to the specifications (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Examples - DI - Lanes and Nested Lanes.bpmn example is not according to the specifications.  In xml:                      <bpmn:lane name="Lane 2 - 2" id="Lane_Lane2_2">                          <bpmn:flowNodeRef>Task_UserTask</bpmn:flowNodeRef>                          <bpmn:flowNodeRef>DataObject_Document</bpmn:flowNodeRef>                      </bpmn:lane>    DataObject_Document is a dataObjectReference (and that derives directly from flowElement) and not a flowNode. The documentation clearly states that flowNodeRef should be a reference to a flowNode and not to a flowElement (this has even changed from beta1 to beta2).

Resolution:
Revised Text:
Actions taken:
October 12, 2010: received issue

Issue 15732: Participant multi-instance instead of Sub-Choreography multi-instance (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

    i) Chapter/Section  11.4.1. Page 337.It says:   �The marker for a Choreography Task that is multi-instance MUST be a set of three vertical lines�      ii) Chapter/Section  11.4.2. Page 342.It says:   �The marker for a Sub-Choreography that is multi-instance MUST be a set of three vertical lines.�          COMMENTS:       (i) describes the use of a multi-instance marker in the Participant Band for a multi-instance Participant (see Figure 11.15, p. 337).  Multi-instance marker for the Choreography Task  is described on page 336.        (ii) describes the use of a multi-instance marker in the Participant Band for a multi-instance Participant (see Figure 11.23, p. 342).  Multi-instance marker for the Sub-Choreography is described on page 341.          SUGGESTION:      In (i) it should say:  �The marker for a Participant (of a Choreography Task) that is multi-instance MUST be a set of three vertical lines.�      In (ii) it should say:   �The marker for a Participant (of a Sub-Choreography) that is multi-instance MUST be a set of three vertical lines.�

Resolution:
Revised Text:
Actions taken:
October 14, 2010: received issue

Discussion:

Issue 15733: Intermediate Message Event can be source or target of Message Flow (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Chapter/Section  10.4.4. Page 259. Table 10.89. Row �Message�. It says:   �The actual Participant from which the Message is received can be identified by connecting the Event to a Participant using a Message Flow ��      COMMENTS:      The description is devoted to both throw and catch Intermediate Message Events, but it is only described the Participant associated with the catch Event.      SUGGESTION:      It should say:  �The actual Participant from which the Message is received or to which the Message is sent can be identified by connecting the Event to a Participant using a Message Flow ��

Resolution:
Revised Text:
Actions taken:
October 14, 2010: received issue

Discussion:

Issue 15734: �cancelActivity� is not an attribute of Activity (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

i) Chapter/Section  10.4. Page 241. Figure 10.69.   Class BoundaryEvent has attribute cancelActivity  (See Table 10.91, p. 266)      ii) Chapter/Section  10.4.4. Page 262. Table 10.90. Rows �Message�, �Timer�, �Escalation�, �Conditional�, �Signal�, �Multiple� and �Parallel Multiple�  It says:  �Note that if using this notation, the attribute cancelActivity of the Activity to which the Event is attached is implicitly set to true.�       or       �Note that if using this notation, the attribute cancelActivity of the Activity to which the Event is attached is implicitly set to false.�          iii) Chapter/Section  10.4.4. Page 266. Table 10.92.   This Table doesn�t contain o row for Parallel Multiple Event.      iv) Chapter/Section  13.4.3. Page 455. It says:  �For boundary Events, handling first consists of consuming the Event occurrence. If the cancelActivity attribute is  set, the Activity the Event is attached to is then cancelled (in case of a multi-instance, all its instances are cancelled); if  the attribute is not set, the Activity continues execution (only possible for Message, Signal, Timer, and Conditional  Events, not for Error Events). Execution then follows the Sequence Flow connected to the boundary Event.�      COMMENTS:      According to the meta-model (i) cancelActivity is an attribute of BoundaryEvent, but in (ii) it is said that it is an attribute of Activity.      In (iii) a row is needed for Parallel Multiple.      In (iv) it is suggested that cancelActivity is optional. This is not the case, cancelActivity is mandatory: it is always set (to true or to false).      SUGGESTIONS:      In (ii)   �the attribute cancelActivity of the Activity� should be replaced by �the attribute cancelActivity of the BoundaryEvent� (14 times)      In (iii) add an additional row for Parallel Multiple.       In (iv)   �If the cancelActivity attribute is set,� should be replaced by �If the cancelActivity attribute is set to true,�    �if the attribute is not set� should be replaced by �if the attribute is set to false�

Resolution:
Revised Text:
Actions taken:
October 14, 2010: received issue

Discussion:

Issue 15735: Page 288. Typos (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Description:      i) It says:  �Interrupting Event Handlers are those that have the cancelActivity attribute is set to true.�      It should say:  �Interrupting Event Handlers are those that have the cancelActivity attribute set to true.�      �is set to true�  should be replaced by   �set to true�        ii) It says:  �Interrupting Event Handlers are those that have the cancelActivity attribute is set to false.�      It should say:  �Non-interrupting Event Handlers are those that have the cancelActivity attribute set to false�      �Interrupting�  should be replaced by   �Non-interrupting�    �is set to false�  should be replaced by   �set to false�

Resolution:
Revised Text:
Actions taken:
October 14, 2010: received issue

Issue 15736: Message Flow Connections for Start, End and Intermediate Events (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

i) Chapter/Section 10.4.2. Page 253. Message Flow Connections for Start Events It says: - A Start Event MAY be the target for a Message Flow; it can have zero (0) or more incoming Message Flows. Each Message Flow targeting a Start Event represents an instantiation mechanism (a trigger) for the Process. Only one of the triggers is REQUIRED to start a new Process. - A Start Event MUST NOT be a source for a Message Flow; it MUST NOT have outgoing Message Flows. ii) Chapter/Section 10.4.3. Page 257. Message Flow Connections for End Events It says: - An End Event MUST NOT be the target of a Message Flow; it can have no incoming Message Flows.. - An End Event MAY be the source of a Message Flow; it can have zero (0) or more outgoing Message Flows. Each Message Flow leaving the End Event will have a Message sent when the Event is triggered. - The Result attribute of the End Event MUST be set to Message or Multiple if there are any outgoing Message Flows. - The Result attribute of the End Event MUST be set to Multiple if there is more than one (1) outgoing Message Flows iii) Chapter/Section 10.4.4. Page 268. Message Flow Connections for Intermediate Events It says: - A Message Intermediate Event MAY be the target for a Message Flow; it can have one (1) incoming Message Flow. - A Message Intermediate Event MAY be a source for a Message Flow; it can have one (1) outgoing Message Flow. - A Message Intermediate Event MAY have an incoming Message Flow or an outgoing Message Flow, but not both. COMMENTS: In (i) it is not explained when the Start Event can have incoming Message Flows. The rules are: The Start Event MUST be associated with one (1) or more MessageEventDefinitions if there are any incoming Message Flows. The Start Event will be Message, Multiple or Parallel Multiple if there are any incoming Message Flows. The Start Event will be Multiple or Parallel Multiple if there is more than one (1) incoming Message Flows. In (i) it is said �Only one of the triggers is REQUIRED to start a new Process�, this is true for a Multiple Start Event, but not for a Parallel Multiple Start Event. In (ii) the �Result� attribute is mentioned. It was an attribute of End Event in BPMN 1.2, but not in BPMN 2.0. (see Figure 10.69, p. 241). The rules are: The End Event MUST be associated with one (1) or more MessageEventDefinitions if there are any outgoing Message Flows. The End Event will be Message or Multiple if there are any outgoing Message Flows. The End Event will be Multiple if there is more than one (1) outgoing Message Flows. In (iii) it is described only the Message Intermediate Event, but Multiple and Parallel Multiple Intermediate Events can be the source or the target of Message Flows too. SUGGESTIONS: In (i) add the rules that define when the Start Event can have incoming Message Flows, and consider the case when a a Parallel Multiple Start Event is used. In (ii) remove references to �Result� attribute and update the rules that define when the End Event can have outgoing Message Flows. In (iii) describe the rules concerning Message Flows for Multiple and Parallel Multiple Intermediate Events.

Resolution:
Revised Text:
Actions taken:
October 14, 2010: received issue

Issue 15737: Page 247. �Parallel� instead of �Parallel Multiple� (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:  �There are seven (7) types of Start Events for top-level Processes in BPMN (see Table 10.84): None, Message, Timer, Conditional, Signal, Multiple, and Parallel.�      It should say:  �There are seven (7) types of Start Events for top-level Processes in BPMN (see Table 10.84): None, Message, Timer, Conditional, Signal, Multiple, and Parallel Multiple.�    �Parallel� should be replaced by �Parallel Multiple�.

Resolution:
Revised Text:
Actions taken:
October 14, 2010: received issue

Discussion:

Issue 15738: Page 270. Typo (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

It says:   �When one of the EventDefinition sub-types (e.g., TimerEventDefinition) is defined it is contained in Definitions, or a contained EventDefinition contained in a throw/catch Event.�      According Figures 8.4 (p.52),  10.69 (p.241) and 10.73 (p.270), it should say:   �When one of the EventDefinition sub-types (e.g., TimerEventDefinition) is defined it is contained in Definitions, or in a throw/catch Event.�

Resolution:
Revised Text:
Actions taken:
October 14, 2010: received issue

Discussion:

Issue 15739: Inconsistencies concerning Link Events (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

i) Chapter/Section  10.4.4. Page 260. Table  10.89.  Row �Link�. It says:  �There can be multiple source Link Events, but there can only be one target Link Event.�      ii) Chapter/Section  10.4.4. Page 268.  It says:     - If there is a source Link, there MUST be a matching target Link (they have the same name).          - There MAY be multiple source Links for a single target Link.          - There MUST NOT be multiple target Links for a single source Link.     iii) Chapter/Section  10.4.5. Page 270. Figure 10.73.   Role �target� (from LinkEventDefinition to LinkEventDefinition)  has multiplicity [0..1]  Role �source� (from LinkEventDefinition to LinkEventDefinition)  has multiplicity [0..*]      iv) Chapter/Section  10.4.5. Page 278. Table  10.98.  Row  �sources�. It says:  �sources: LinkEventDefinition [1..*]�  �Used to reference the corresponding �catch� or �target� LinkEventDefinition, when this LinkEventDefinition represents a �throw� or �source� LinkEventDefinition.�      v) Chapter/Section  10.4.5. Page 278. Table  10.98.  Row  �target�. It says:  �target: LinkEventDefinition [1]�  �Used to reference the corresponding �throw� or �source� LinkEventDefinition, when this LinkEventDefinition represents a �catch� or �target� LinkEventDefinition.�      COMMENTS:      In (iii) the role name �source� is incorrect, because its multiplicity is �many� and  it is not the name shown in (iv)      In (iv) the multiplicity of �sources� is incorrect, it must be [0..*], because � by definition � a source (throw) Link doesn�t have any �sources�. Furthermore, in (iii) the multiplicity is [0..*].      In (iv) the description in misplaced. Actually, it is the description of the role �target�.      In (v) the multiplicity of �target� is incorrect, it must be [0..1], because � by definition � a target (catch) Link doesn�t have any �target�. Furthermore, in (iii) the multiplicity is [0..1].      In (v) the description in misplaced. Actually, it is the description of the role �sources�.      In (iv) and (v) it is not stated that �target� and �sources� are mutually exclusive.       A source (throw) Link have one �target� and zero �sources�       A target (catch) Link have one or more �sources� and  no �target�.        SUGGESTIONS:  In (iii) change role name from �source� to �sources�.      In (iv) change multiplicity form �[1..*]�  to  �[0..*]�      In (iv) replace description by:  �Used to reference the corresponding �throw� or �source� LinkEventDefinitions (at least one), when this  LinkEventDefinition represents a �catch� or �target� LinkEventDefinition. When the LinkEventDefinition represents a �throw� or �source� LinkEventDefinition this model association  is not set.�      In (v) change multiplicity form �[1..1]�  to  �[0..1]�      In (iv) replace description by:  �Used to reference the corresponding �catch� or �target� LinkEventDefinition, when this LinkEventDefinition represents a �throw� or �source� LinkEventDefinition. When the LinkEventDefinition represents a �catch� or �target� LinkEventDefinition this model association  is not set.�

Resolution:
Revised Text:
Actions taken:
October 15, 2010: received issue

Discussion:

Issue 15740: None Intermediate Event: �catch� or �throw� (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Description:      ANTECEDENTS:  i) Chapter/Section  10.4.4. Page 259. Table  10.89.  Row �None�. It says:  �The None Intermediate Event is only valid in normal flow, i.e., it MAY NOT be used on the boundary of an Activity. Although there is no specific trigger for this Event, it is defined as throw Event.�      ii) Chapter/Section  10.4.5. Page 269. Table  10.93.  Row �None�.  None Intermediate Event is shown as a throw Event        iii) Chapter/Section  10.4.5. Page 280. It says:  �There are three (3) variations of None Events: a Start Event, a catch Intermediate Event, and ��      �The catch None Intermediate Event MUST only be used in normal flow and, thus, MAY NOT be attached to the boundary of an Activity.�        COMMENTS:      In (i) and (ii) None Intermediate Event is defined as a throw Event, but in (iii) it is considered to be a catch Event        SUGGESTIONS:      It seems that it is not important which type (throw or catch) would be chosen, but  it is necessary to define one and be consistent in its use.     Note: see Issue 15687

Resolution:
Revised Text:
Actions taken:
October 15, 2010: received issue

Discussion:

Issue 15741: Event Sub-Processes use Multiple and Parallel Multiple Start Events (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

i) Chapter/Section 10.4.2. Page 248. Table 10.84. Row �Multiple�. It says: �This means that there are multiple ways of triggering the Process� ii) Chapter/Section 10.4.2. Page 248. Table 10.84. Row �Parallel Multiple�. It says: �This means that there are multiple triggers REQUIRED before the Process can be instantiated� iii) Chapter/Section 10.4.2. Page 252. Table 10.86. Row �Multiple�. It says: �A Multiple Event indicates that that there are multiple ways of triggering the Event Sub-Process.� iv) Chapter/Section 10.4.2. Page 252. Table 10.86. Row �Parallel Multiple�. It says: �A Parallel Multiple Event indicates that that there are multiple ways of triggering the Event Sub-Process. All of them are REQUIRED to actually �� v) Chapter/Section 10.4.5. Page 279. It says: �If the trigger is Multiple, there are multiple ways of starting the Process. Only one of them is necessary to trigger the start of the Process. The EventDefinition subclasses will define which triggers apply� vi) Chapter/Section 10.4.5. Page 280. It says: �If the trigger is Multiple, there are multiple triggers REQUIRED to start the Process. All of them are necessary to trigger the start of the Process. The EventDefinition subclasses will define which triggers apply.� COMMENTS: (i) and (ii) describe the use of Multiple and Parallel Multiple Start Events in Top-Level Processes. (iii) and (iv) describe the use of Multiple and Parallel Multiple Start Events in Event Sub- Processes In (v) and (vi) it is not mentioned the fact that Multiple and Parallel Multiple Start Events are used by Event Sub-Processes too. SUGGESTIONS: In (v) and (vi) �Process� should be replaced by �Process or Event Sub- Process� (4 times)

Resolution:
Revised Text:
Actions taken:
October 15, 2010: received issue

Discussion:

Issue 15742: Page 281. Typo in Table 10.100 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Table 10.100. Row �signalRef�.  It says:   �If the trigger is a Signal, then a Signal is provided.�      �signalRef� is optional and it is similar to �errorRef� (see Table 10.96 p. 274) and �escalationRef� (see Table 10.97 p. 275).      Then,  it should say   �If the trigger is a Signal, then a Signal payload MAY be provided.�

Resolution:
Revised Text:
Actions taken:
October 15, 2010: received issue

Discussion:

Issue 15743: Pages 285-287. Missing Events types (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

i) Chapter/Section  10.4.2. Page 269. Table  10.93.   Boundary Interrupting Events are: error, cancel, compensation, message, timer, escalation, conditional, signal, multiple and parallel multiple.      Boundary Non-interrupting Events are: message, timer, escalation, conditional, signal, multiple and parallel multiple.      Event Sub-Process Interrupting Events are: error, compensation,  message, timer, escalation, conditional, signal, multiple and parallel multiple.      Event Sub-Process Non-interrupting Events are:  message, timer, escalation, conditional, signal, multiple and parallel multiple.        ii) Chapter/Section  10.4.6. Page 285. Subsection �Handling Events attached to an Activity (Intermediate boundary Events and Event Sub-Processes)�. It says:      �For boundary Events, handling consists of consuming the Event occurrence and either canceling the Activity the Event is   attached to, followed by normal Sequence Flows leaving that Activity, or by running an Event Handler without canceling the   Activity (only for Message, Signal, Timer and Conditional Events, not for Error Events).�      iii) Chapter/Section  10.4.6. Page 287. It says:  �For an interrupting Event (Error, Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple),   only one Event Sub-Process for the same Event Declaration MUST be modeled.�      COMMENTS:      In (ii) Escalation, Multiple and Parallel Multiple are not mentioned as Boundary Non-Interrupting. Furthermore,   Cancel and Compensations are not mentioned  as Boundary Events that always interrupt.      In (iii) Compensation is not mentioned as an interrupting Event for an Event Sub-Process.        SUGGESTIONS:      In (ii)   �(only for Message, Signal, Timer and Conditional Events, not for Error Events)�   should be replaced by  �(only for Message,   Signal, Timer, Conditional, Escalation, Multiple and Parallel Multiple Events, not for Error, Cancel and Compensation   Events)�      In (iii)   �(Error, Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)�   should be replaced by  �Error, Escalation, Message, Signal, Timer, Conditional, Compensation, Multiple, and Parallel Multiple)�

Resolution:
Revised Text:
Actions taken:
October 15, 2010: received issue

Discussion:

Issue 15744: Table 8.14: Example for BPMN's extension mechanism is not schema-valid (bpmn2-rtf)

Click here for this issue's archive.
Source: Camunda Services GmbH (Mr. Falko Menge, falko.menge(at)camunda.com)
Nature: Revision
Severity: Significant
Summary:

The example for BPMN's extension mechanism in Table 8.14 on page 61 (PDF 91) is not valid with respect to the XML Schema.      The example uses Extension Elements that are already defined in BPMN as part of ioSpecification, namely dataInput, dataOutput, inputSet, and outputSet. To be valid BPMN, those elements must be contained in an 'extensionElements' element and reside in an own XML namespace.    I'd suggest to use different Extension Elements to avoid confusion with existing BPMN elements.

Resolution:
Revised Text:
Actions taken:
October 15, 2010: received issue

Discussion:

Issue 15745: Inconsistencies concerning attribute �activationCount� (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

i) Chapter/Section 10.5.5. Page 305. Table 10.126. Row �activationCount�. It says: �Refers at runtime to the number of tokens that are present on an incoming Sequence Flow of the Complex Gateway.� ii) Chapter/Section 13.3.5. Page 452-453. It says: � Each incoming gate of the Complex Gateway has an attribute activationCount, which can be used in an Expression as an integer-valued variable. This variable represents the number of tokens that are currently on the respective incoming Sequence Flows. The Complex Gateway has an attribute activationExpression. An activationExpression is a boolean Expression that refers to data and to the activationCount of incoming gates. For example, an activationExpression could be x1+x2+�+xm >= 3 stating that it needs 3 out of the m incoming gates to have a token in order to proceed. To prevent undesirable oscillation of activation of the Complex Gateway, ActivationCount variables should only be used in subexpressions of the form �� COMMENTS: In (i) according to Table 10.126 (�Instance attributes related to the Complex Gateway�) for each instance of a certain Complex Gateway there is one �activationCount� attribute, which memorize the �number of tokens that are present on an incoming Sequence Flow�. But a Complex Gateway - by definition � has more than one incoming Sequence Flow. In (ii) it is described the presence and usage of more than one �activationCount� variable in a single instance of a Complex Gateway. In (ii) it is clearly stated that �Each incoming gate of the Complex Gateway has an attribute activationCount�. Then, the �activationCount� attribute should be located in each incoming �SequenceFlow instance�, but it is not what the meta-model says (see Figure 8.35, p. 98). �activationCount� cannot be an attribute of Sequence Flow Class , because a �normal� instance of Sequence Flow that reachs a Complex Gateway will be instantiate as many times as the Complex Gateway. In (ii) the attribute activationExpression is mentioned, but according to Figure 10.114 and Table 10.125 (p. 304) its real name is activationCondition. SUGGESTIONS: Somehow the meta-model must represent the fact that there will be many �activationCount� for each instance of a Complex Gateway. An option is to make �activationCount� attribute (of Complex Gateway instance) an array of integers (one for each incoming Sequence Flow). In (ii) replace �activationExpression� with �activationCondition� Typo: in (ii) �on the respective incoming Sequence Flows� should be replaced by �on the respective incoming Sequence Flow�

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Issue 15746: Events that can be located after an Event-Based Gateway (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Chapter/Section  10.5.6. Page 306. It says:       �Event-Based Gateways are configured by having outgoing Sequence Flows target an Intermediate Event or a Receive Task ��      �If Message Intermediate Events are used in the configuration, then Receive Tasks MUST NOT ��      �Only the following Intermediate Event triggers are valid: Message, Signal, Timer, Conditional, and Multiple (which can only include the previous triggers). Thus, the following Intermediate Event triggers are not valid: Error, Cancel, Compensation, and Link.�        COMMENTS:      According to Table 10.93 (p. 269)  Intermediate catch Events in normal flow are: message, timer, conditional, link, signal, multiple and parallel multiple.      The Events after an Event-Based Gateway can  be only catch Intermediate Events in normal flow, but two of them (Link and parallel Multiple) are not allowed.        SUGGESTIONS:      Then, it should say:       �Event-Based Gateways are configured by having outgoing Sequence Flows target an Intermediate catch Event or a Receive Task ��      �If Message Intermediate catch Events are used in the configuration, then Receive Tasks MUST NOT ��    �Only the following Intermediate catch Event triggers in normal flow are valid: Message, Signal, Timer, Conditional, and Multiple (which can only include the previous triggers). Thus, the following Intermediate catch Event triggers in normal flow are not valid:   Link,   and Parallel Multiple.�

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Discussion:

Issue 15747: Wrong Public Process in Figure 10.127 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

i) Chapter/Section  10.8. Page 318.  It says:  �For example Figure 10.127 shows a public Process at the top with a Send Task and Receive Task. A supporting private Process is shown at the bottom.�       ii) Chapter/Section  10.8. Page 319.  Figure 10.127.  Public Process (at the top) consists of a Receive Task followed by a Send Task.      iii) Issue 14652: Private process example correction (bpmn2-ftf). It says:  �The private process in Figure 10-122 (One Process supporting to another)  should have activity X and event B in parallel, because event B may  arrive while X is executing, which would be lost in the current example.  See webinar example on slide 51 in bmi/09-06-02.�        COMMENTS:      In (i) it is stated that the A must be a Send Task, and B must be a Receive Task.      In (ii) A is a Receive Task, and B is a Send Task. This contradicts (i).       In (iii) it is stated that the problem with the example was the location of Activity X and Event B in the Private Process, nothing is said about Tasks A and B.        SUGGESTIONS:      Change the types of Tasks in Public Process:    Task A should be a Send Task (filled envelope marker)    Task B  should be a Receive Task (unfilled envelope marker)

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Discussion:

Issue 15748: Number of internal markers for Choreography Activities (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

i) Chapter/Section  11.4.1. Page 335.  It says:  �There are two types of internal markers (see Figure 11.12):�       �A Choreography Task MAY have only one of the three (3) markers at one time.�      ii) Chapter/Section  11.4.2. Page 341.  It says:  �There are two types of internal markers (see Figure 11.22):�      �A Sub-Choreography MAY have only one of the three (3) markers at one time.�      COMMENTS:      In (i) and (ii) it is clear that there are three markers, not two.      SUGGESTIONS:      In (i) it should say:   �There are three (3)  types of internal markers (see Figure 11.12):�      In (ii) it should say:   �There are three  (3) types of internal markers (see Figure 11.22):�

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Discussion:

Issue 15749: Sub-Choreography is not a compound Activity (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

i) Chapter/Section  8.3.7. Page 87. Figure 8.22. According to classes and their relationships:   Both Activity and Choreography Activity are sub-classes of Flow Node.      ii) Chapter/Section  11.4.2. Page 338.  It says:  �A Sub-Choreography is a compound Activity in that it has detail that is defined as a flow of other Activities, in this case, a Choreography.�        COMMENTS:      According to (i)  Choreography Activity is not a type of Activity, because there is not generalization from  Choreography Activity to  Activity.      Then, A Sub-Choreography cannot be a �compound Activity�, because a Sub-Choreography is not a type of Activity.        SUGGESTIONS:       In (ii) it should say:   �A Sub-Choreography is a compound  ChoreographyActivity in that it has detail that is defined as a flow of other ChoreographyActivities.�      �Activity� should be replaced by �ChoreographyActivity�  �Activities� should be replaced by �ChoreographyActivities

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Discussion:

Issue 15750: Page 350. Typo (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Chapter/Section  11.5.1. Page 350. Table  11.6.  Row �None�. It says:  �Sub-Processes, however, we should look at. The Parent Process can be considered the trigger.�        COMMENTS:      This sentence (�we should look at�) seems to be a draft.      Table 11.6 is devoted to Start Events in Choreography, so �Sub-Processes� and �Process�  are not pertinent here.      SUGGESTIONS:    Remove it.

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Discussion:

Issue 15751: Restrictions for Relative and Absolute Timers are the same (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Chapter/Section  11.6.2. Page 360.  It says:      �For relative timers: All Participants on the right side of the Gateway MUST be involved in the Choreography Activity that immediately precedes the Gateway.�       �For absolute timers (full time/date): All Participants on the right side of the Gateway MUST be involved in the Choreography Activity that immediately precedes the Gateway.�        COMMENTS:      The restrictions for Relative and Absolute Timers are exactly the same.        SUGGESTIONS:  If both restrictions are the same,  collapse them  into one bullet.    If the restrictions are different, modify them accordingly.

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Discussion:

Issue 15752: Terminate End Event in a Choreography with many Participants (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

i) Chapter/Section  11.5.3. Page 354. Table  11.8.  Row �Terminate�. It says:  �The use of the Terminate End Event really only works when there are  only two (2) Participants. If there are more than two (2) Participants, then any  Participant that was not involved in the last Choreography Task would not necessarily  know that the Terminate End Event had been reached.�      ii) Chapter/Section  11.6.5.  Page 371. Figure 11.48.  Four (4) Participants (Purchaser and Service Providers A, B, C) are involved, and it ends with a Terminate End Event.        COMMENTS:      According to (i), the  Terminate End Event in Choreography depicted in (ii) doesn�t work.       In (i) it is said �any Participant that was not involved in the last Choreography Task would not necessarily know that the Terminate End Event had been  reached�, so it seems that in some cases Terminate End Event  could work when there are  More than  two (2) Participants.        SUGGESTIONS:    Clarify whether the  Terminate End Event in Figure 11.48 works or not.

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Discussion:

Issue 15753: �empty Start Event� is used instead of �None Start Event� (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In Chapter 13 the expression �empty Start Event� is used instead of  �None Start Event�, the latter is used in all other Chapters.        SUGGESTION:    Use �the expression �None Start Event� in order to be consistent with the rest of the document.

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Discussion:

Issue 15754: Apparent contradiction concerning compensation handler invocations (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

i) Chapter/Section  13.4.5. Page 457.  It says:  �Triggering compensation for the Multi-Instance Sub-Process individually triggers compensation for all instances within the current scope. If compensation  is specified via a boundary compensation handler, this boundary compensation handler also is invoked once for each instance of the Multi-Instance Sub-Process in the current scope.�      ii) Chapter/Section  13.4.5. Page 458.  It says:  �In case the Activity is a multi-instance or loop, the Compensation Activity is triggered only once, too, and thus has to compensate the effects of all instances.�      COMMENTS:      It seems there is a contradiction between (i) and (ii).       - In (i) there are as many invocations as instances are.      - In (ii) there is only one invocation for many instances.      SUGGESTIONS:    Clarify whether there is a contradiction or not.

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Discussion:

Issue 15755: Conditions for completion of Process and Sub-Process (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

i) Chapter/Section 10.4.2. Page 245. It says: �There MAY be multiple Start Events for a given Process level. - Each Start Event is an independent Event. That is, a Process instance SHALL be generated when the Start Event is triggered.� ii) Chapter/Section 13.1. Page 440. It says: �To specify that the instantiation of a Process waits for multiple Start Events to happen, a Multiple Parallel Start Event can be used.� �Note that two Start Events are alternative, A Process instance triggered by one (1) of the Start Events does not wait for an alternative Start Event to occur.� �Note that there MAY be multiple instantiating Parallel Event-Based Gateways. This allows the modeler to express that either all the Events after the first Gateway occur or all the Events after the second Gateway and so forth.� �Each Start Event that occurs creates a token on its outgoing Sequence Flows, which is followed as described by the semantics of the other Process elements.� iii) Chapter/Section 13.4.6. Page 458. It says: �The Process instance is then completed, if and only if the following two conditions hold:� - All start nodes of the Process have been visited. More precisely, all Start Events have been triggered, and for all starting Event-Based Gateways, one of the associated Events has been triggered.� iv) Chapter/Section 13.4.6. Page 459. It says: �The Sub-Process instance is then completed, if and only if the following two conditions hold: - All start nodes of the Sub-Process have been visited. More precisely, all Start Events have been triggered, And for all starting Event-Based Gateways, one of the associated Events has been triggered.� COMMENTS: >From (i) and (ii) can be deduced that each tart node (start event or start event-based gateway) is independent, i.e. the activation of one of them generates an new independent instance of the Process. But in (iii) and (iv) it is said that all start nodes must be visited as a pre-condition to complete the execution of the Process instance. This contradicts what it is stated in (i) and (ii). SUGGESTIONS: Modify (iii) and (iv) to make them consistent with what it is stated in (i) and (ii). Typo in (ii): �� are alternative, A Process instance�� should be replaced by �� are alternative. A Process instance��

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Discussion:

Issue 15756: Legal BPMN models and �lack of synchronization" (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

) Chapter/Section  10.2. Page 157.  Table 10.3. Row �completionQuantity�. It says:  �This attribute defines the number of tokens that MUST be generated from the Activity. This number of tokens will be sent down any outgoing Sequence Flow  ��      ii) Chapter/Section  13.3.5. Page 452.   It says:  �Each incoming gate of the Complex Gateway has an attribute activationCount, which can be used in an Expression as an integer-valued variable. This variable represents the number of tokens that are currently on the respective incoming Sequence Flow.�      iii) Chapter/Section  14. Page 461.  It says:  �To map a BPMN orchestration Process to WS-BPEL it MUST be sound, that is it MUST contain neither a deadlock nor a lack of synchronization. A deadlock is a reachable state of the Process that contains a token on some Sequence Flow that cannot be removed in any possible future. A lack of synchronization is a reachable state of the Process where there is more than one token on some Sequence Flow.�      COMMENTS:      >From (i) and (ii) can be deduced that a correct  BPMN model allows Process instances with  Sequence Flows containing  more than one token.      According to (iii) this is considered a �lack of synchronization�, which prevents the mapping to WS-BPEL.      SUGGESTIONS:    Clarify whether �lack of synchronization� means that the Model is illegal or not.

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Issue 15757: In Chapter 14 Figures are not numbered (bpmn2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

In Chapter 14 Figures and Tables are not numbered.      COMMENTS:      The absence of numbers in Figures and Tables complicates the reading.   Furthermore, in the rest of the document the Figures and Tables are numbered.      SUGGESTIONS:    Number Figures and Tables in Chapter 14.

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Discussion:

Issue 15758: Pages 467-468. Missing Figure (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

i) Chapter/Section  14.1.2. Page 467.   It says:   �The following figure shows the mapping of a BPMN Sub-Process without an Event Sub-Process:�      ii) Chapter/Section  14.1.2. Page 468.   It says:  �The following figure shows the mapping of a BPMN Sub-Process with an Event Sub-Process. (Event Sub- Processes could also be added to a top-level Process, in which case their mapping extends correspondingly.)�      COMMENTS:      After (i) there is no Figure. The Figure after (ii) seems to be the one that must be located after (i).      SUGGESTIONS:    Verify the correct position of the Figure located after (ii).

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Discussion:

Issue 15759: Page 473.Wrong reference to figure (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Chapter/Section  14.1.3. Page 473.   Sub-section �Message End Events� It says:  �A Message Start Event is mapped to WS-BPEL as shown in the following figure:�        SUGGESTIONS:      It should say:   �A Message End Event is mapped to WS-BPEL as shown in the following figure:�    �Start Event�  should be replaced by   �End Event�

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Discussion:

Issue 15760: Wrong configuration of Event-Based Gateway (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

i) Chapter/Section 10.5.6. Page 306. It says: �Event-Based Gateways are configured by having outgoing Sequence Flows target an Intermediate Event or a Receive Task in any combination (see Figure 10.116 and Figure 10.117) except that: - If Message Intermediate Events are used in the configuration, then Receive Tasks MUST NOT be used in that configuration and vice versa.� ii) Chapter/Section 10.5. Page 298: �A diverging Exclusive Gateway (Decision) ...� Page 300: �A diverging Inclusive Gateway (Inclusive Decision) �� Page 305: �The Event-Based Gateway represents a branching point in the Process where the alternative paths that follow the Gateway are based on Events that occur, rather than the evaluation of Expressions using Process data (as with an Exclusive or Inclusive Gateway).� iii) Chapter/Section 14.1.4. Page 478. Sub-section �Exclusive (Event-based) Decision Pattern�. Figure shows tree branches with one Message Intermediate Event, one Receive Task and one Timer Intermediate Event. COMMENTS: According to (i) Message Intermediate Events and Receive Tasks MUST NOT be used in the same configuration of an Event-Based Gateway. Nevertheless, in (iii) both are used in the same configuration. According to (ii) Exclusive and Inclusive Gateways are considered �decisions�, but not Event-Based Gateways. SUGGESTIONS: Modify Figure in Sub-section �Exclusive (Event-based) Decision Pattern�: use Message Intermediate Events or Receive Tasks, but not both. Name the Sub-section: �Exclusive (Event-based) Pattern�

Resolution:
Revised Text:
Actions taken:
October 18, 2010: received issue

Discussion:

Issue 15764: Table 7.2 Element Data Object column "Notation" typo Data ObjecT (Collection) (bpmn2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

Just a typo in Table 7.2 at Element "Data Object" on p. 35 in column "Notation". It is written "Data Objec (Collection)" but should say "Data Object (Collection)". The "t" is missing in the word "object".

Resolution:
Revised Text:
Actions taken:
October 19, 2010: received issue

Discussion:

Issue 15806: Figure 10.127, private process supports public process (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In Figure 10.127, one process supports another. According to the corresponding text a message is sent and afterwards received and the same order is required by the public and the private process.       However, in the figure the private process sents and receives a message, but the public process first receives message A and then sends message B. The order seems to be not identical.

Resolution:
Revised Text:
Actions taken:
November 8, 2010: received issue

Discussion:

Issue 15807: Reference calledChoreographyRef of CallChoreography refers to Choreography and to CallableElement (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

The calledChoreographyRef of CallChoreography refers to different Elements and is therefore conflicting.       According to the class diagram (Figure 11.27) CallChoreography has a relationship calledChoreographyRef that references Choreography.       According to the Model Associations on page 345, calledChoreographyRef references CallableElement.       I think that based on the other text the relationship to Choreography is correct. The Model Associations should be corrected.

Resolution:
Revised Text:
Actions taken:
November 9, 2010: received issue

Discussion:

Issue 15808: Outgoing Paths after Inclusive Gateway (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

I think that the number of outgoing paths after an Inclusive Gateway are conflicting. According to page 37 and page 300, all combinations of paths MAY be taken, from zero to all. However, on page 362 it is mentioned several times that one or more alternative branches are chosen (one of more branches MAY be activated upstream). The difference is taking zero paths. Is it possible to take zero paths after an Inclusive Gateway? If yes, is the process flow interrupted or can the flow just continue after a later merge? What happens if there is no corresponding merge for the split? It seems that taking zero paths is possible based on the conditions which are evaluated separately. However, I think, that the specification from page 362 should be taken and that one or more outgoing paths receive a token. Then A OR B can also be transformed to (A XOR B) XOR (A AND B). Also the definition of logical disjunction is that one or more of its operands are true (according to the truth table A OR B is only false if A is false and B is false). If the intention behind taking zero paths is that it should be possible to execute non of the tasks, then my second suggestion would be to define that an "empty" path is mandatory and if no task should be executed then a token can be sent on the "empty" path. Also if the separately evaluated conditions are the reason for allowing zero paths, again a mandataroy empty default path could be a solution to avoid that the inclusive split contradicts with the logical disjunction. As Inclusive Gateways are a very complex topic a discussion would be interesting.

Resolution:
Revised Text:
Actions taken:
November 9, 2010: received issue

Discussion:

Issue 15809: Table 10.56 is named Data Store attributes instead of Data Store Reference attributes (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

On page 217 Table 10.56 is named Data Store attributes instead of Data Store Reference attributes.       Table 10.55 shows the real Data Store attributes. In addition, the last sentence on page 216 rightly specifies: "Table 10.56 presents the additional model associations of the Data Store Reference element:".

Resolution:
Revised Text:
Actions taken:
November 10, 2010: received issue

Discussion:

Issue 15810: Attributes and Model Associations of EndEvent (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Every specified Element has a sentence of the type "The RootElement element inherits the attributes and model associations of BaseElement (see Table 8.5), but does  not have any further attributes or model associations." or the type "The Association element inherits the attributes and model associations of BaseElement (see Table 8.5). Table 8.20 presents the additional attributes and model associations for an Association" except EndEvent.      It seems that EndEvent has no attributes, so the sentence "The EndEvent element inherits the attributes and model associations of ThrowEvent (see Table ..), but does  not have any further attributes or model associations." could be inserted.

Resolution:
Revised Text:
Actions taken:
November 10, 2010: received issue

Discussion:

Issue 15811: CompensateEventDefinition vs. CompensationEventDefinition (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The same element is sometimes called CompensateEventDefinition and sometimes CompensationEventDefinition.      CompensateEventDefinition used:  * Within the Class Diagram Figure 10.76  * Table 10.106 � CompensateEventDefinition XML schema      CompensationEventDefinition used:  * in the labeling text of Figure 10.76  * In the following text and description of the attributes and model associations.      I would recommend to use CompensationEventDefinition.

Resolution:
Revised Text:
Actions taken:
November 10, 2010: received issue

Discussion:

Issue 15812: Model Association participantMultiplicity(Ref) of element Participant (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The model association participantMultiplicity(Ref) is twice named participantMultiplicity (in the class diagram and in Table 9.2 on the left side) and once participantMultiplicityRef (in Table 9.2 on the text of the right side). Maybe the text of Table 9.2 can be replaced as follows:      participantMultiplicity: participant-  Multiplicity [0..1]  -->  participantMultiplicityRef: Participant-  Multiplicity [0..1]

Resolution:
Revised Text:
Actions taken:
November 11, 2010: received issue

Discussion:

Issue 15814: Cardinality of Relationship from CategoryValue to Category (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

According to the Group class diagram (Figure 8.15 on page 70) CategoryValue has a relationship with cardinality 1 to Category. However, according to Table 8.23 on page 72, CategoryValue references category with a cardinality of [0..1].      I would suggest to set the cardinality to 1.

Resolution:
Revised Text:
Actions taken:
November 12, 2010: received issue

Discussion:

Issue 15815: Attributes of Transaction Element (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

According to the class diagram of Sub-Process (Figure 10.29, page 181), Transaction has two attributes (protocol and transaction). However, in Table 10.21 on page 185 only method is mentioned (transaction missing).       In addition, the class diagram specifies that the data type of method is string. Table 10.21, however, defines that the data type is of TransactionMethod.    Since an element TransactionMethod is not defined in any metamodel, I would suggest to use data type string. In addition, protocol could be inserted in Table 10.21 with a cardinality of [0..1] or [1].

Resolution:
Revised Text:
Actions taken:
November 12, 2010: received issue

Discussion:

Issue 15816: Attributes of StandardLoopCharacteristics (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

According to the LoopCharacteristics class diagram (Figure 10.45, page 196) StandardLoopCharacteristics only has one attribut (testBefore). However, Table 10.28 on page 198 shows two further attributes (loopMaximum and loopCondition).

Resolution:
Revised Text:
Actions taken:
November 12, 2010: received issue

Discussion:

Issue 15817: Connection Rules for Message Flow (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

According to Table 7.4 on page 44, Message Flows can only connect to events of type message. According to page 257: The Result attribute of the End Event MUST be set to Message or Multiple if there are any outgoing Message Flows.       Are events with Multiple Trigger allowed to have outgoing Message Flows? If yes, this should also be specified in Table 7.4.   Is it further also possible to have a Start Event with Multiple Trigger having multiple incoming Message Flows?    In addition, Table 7.4 is missing several arrows, e.g. first row (connecting from a Start Event) and last column (connecting to an End Event). Furthermore, the first column might also be possible (connections from a pool to another StartEvent).

Resolution:
Revised Text:
Actions taken:
November 12, 2010: received issue

Discussion:

Issue 15818: Attributes of GlobalScriptTask (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

There is no table with attributes and associations of GlobalScriptTask available.      Basically the attributes should be similar to ScriptTask which has according to Table 10.12 on page 170 two attributes (scriptFormat: string [0..1], script: string [0..1]).      According to the Global Task class diagram, however, GlobalScriptTask has script: string and striptLanguage: String. The XML schema on page 205 also mentions script [0..1] and scriptLanguage [1].     The differences are therefore the attributes scriptFormat vs. scriptLanguage as well as their cardinality.

Resolution:
Revised Text:
Actions taken:
November 12, 2010: received issue

Discussion:

Issue 15819: Element Repository (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

On page 329 it is stated that: As mentioned above, neither Data Objects nor Repositories are used in Choreographies. Both of these elements are used exclusively in Processes and require the concept of a central locus of control.    Repository is refered to as being an element that can be used in Processes and it is also highlighted like other elements. However, an element with the name Repository is nowhere else mentioned.

Resolution:
Revised Text:
Actions taken:
November 12, 2010: received issue

Discussion:

Issue 15839: Multiple uncontrolled incoming Sequence Flows (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

According to Section 13.2.1:   The presence of multiple incoming Sequence Flows behaves as an exclusive gateway.       However, I think this is only the case for alternative paths (only one token). Otherwise, several instances are created. See the specification from other sections:       An Activity MAY be a target for Sequence Flows; it can have multiple incoming Sequence Flows. Incoming Sequence Flows MAY be from an alternative path and/or parallel paths.      If the Activity has multiple incoming Sequence Flows, then this is considered uncontrolled flow. This means that when a token arrives from one of the Paths, the Activity will be instantiated. It will not wait for the arrival of tokens from the other paths. If another token arrives from the same path or another path, then a separate instance of the Activity will be created.      If all the incoming flow is alternative, then a Gateway is not needed.      I think that only multiple alternative incoming flows correspond to an exclusive gateway. I, therefore, suggest the following adaptation:      The presence of multiple "alternative" incoming Sequence Flows behaves as an exclusive gateway.      or     The presence of multiple incoming Sequence Flows may instantiate an Activity several times.

Resolution:
Revised Text:
Actions taken:
November 22, 2010: received issue

Discussion:

Issue 15883: Converging Gateway has multiple outgoing connections (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

According to the footnotes on page 7:  a.Multiple outgoing connections are only allowed for converging Gateways.  b.Multiple outgoing connections are only allowed for diverging Gateways.      Footnote a should be correted to "multiple incoming connections". The right definition is also specified on page 298:      A Gateway with a gatewayDirection of converging MUST have multiple incoming Sequence Flows, but MUST NOT have multiple outgoing Sequence Flows.

Resolution:
Revised Text:
Actions taken:
December 9, 2010: received issue

Discussion:

Issue 15891: Attributes of Element Resource Role (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

According to the class diagram of Resources on page 158, ResourceRole has an attribute "name" of type string.      However, in Table 10.5 - Resource Role model associations on page 159, only three relationships are mentioned but no attribute "name".

Resolution:
Revised Text:
Actions taken:
December 10, 2010: received issue

Discussion:

Issue 15892: Attribute Description of Class Signal missing (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

On page 281 Signal Events are described. The Class Diagram of SignalEventDefinition (Fig. 10.93) refers to a class called Signal with an attribute name and a relationship to ItemDefinition with the name structureRef. However, the attributes and model associations of this class are nowhere described in detail.     Remark: attributes and model associations are also missing for some Global Tasks (GlobalBusinessRuleTask, GlobalScriptTask and GlobalUserTask), however, in this case similar attribute descriptions are available for the classes BusinessRuleTask, ScriptTask and UserTask and might be taken (only problem is the difference described in Issue 15818).

Resolution:
Revised Text:
Actions taken:
December 13, 2010: received issue

Discussion:

Attribute Description of Class Signal missing

Issue 15893: Relationship type of CorrelationProperty (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

According to the Correlation Class Diagram (Figure 8.17) on page 76, CorrelationProperty has a relationship type with cardinality 0..1 to ItemDefinition.      However, in Table 8.32 (CorrelationProperty model associations) on page 78, the relationship type has the datatype string.    Suggestion: Correction of Table 8.32, change type from string to ItemDefinition

Resolution:
Revised Text:
Actions taken:
December 13, 2010: received issue

Discussion:

Issue 15894: Model Associations of class Event (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

According to page 84:  The Event element inherits the attributes and model associations of FlowElement (see Table 8.44), but adds no additional attributes or model associations.    However, according to the class diagram in Figure 8.20, Event has one model association to Property with the name 'properties' and the cardinality [0..n].

Resolution:
Revised Text:
Actions taken:
December 13, 2010: received issue

Discussion:

Issue 15900: Inheritance and Relationship of ResourceParameter (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

According to the class diagram (Figure 8.31) and the XML Schema, ResourceParameter inherits from BaseElement and has a relationship with cardinality [0..1] to ItemDefinition.      However, according to the last paragraph on page 96: The ResourceParameter element inherits the attributes and model associations of BaseElement (see Table 8.5)  through its relationship to RootElement. In addition, Table 8.50 defines no cardinality for the relationship type and, therefore, leads to the assumption that the cardinality is 1.      Suggestion: As the element Resource is also derived from RootElement, it would fit to also derive ResourceParameter from RootElement. Considering the cardinality, I would suggest to define a cardinality of [0..1].

Resolution:
Revised Text:
Actions taken:
December 15, 2010: received issue

Discussion:

Issue 15901: Subclasses of Interaction Node (Task vs. Activity) (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

According to the Message Flow Class Diagram (Figure 9.14), Interaction Node has four subclasses: Participant, ConversationNode, Task and Event.       However, according to page 124:  Of the types of InteractionNode, only Pools/Participants, Activities, and  Events can be the source of a Message Flow.       The question now is, whether Task or Activity should be the subclass of Interaction Node.    Suggestion: The Message Flow Connection Rules on page 44 specify that Message Flows can also connect to Sub-Processes. Therefore, I think it is necessary to define that Activity is a subclass of InteractionNode.

Resolution:
Revised Text:
Actions taken:
December 15, 2010: received issue

Issue 15911: Meaning of 'behavior' attribute on MultiInstanceLoopCharacteristics quite confusing (bpmn2-rtf)

Click here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de)
Nature: Clarification
Severity: Significant
Summary:

The meaning of the 'behavior' attribute on the MultiInstanceLoopCharacteristics is quite confusing. It is told that:      - 'None' should throw an event on each instance,  - 'All' should throw no event at all       It seems that None and All meaning have been swapped.      I also think that oneBehaviorEventRef and noneBehaviorEventRef can be merged as they are exclusive, they will never both be filled.      Another question: what Event will own (composition relationship) the EventDefinition that is referenced by oneBehaviorEventRef or noneBehaviorEventRef ?  As far as I understood, an EventDefinition can be owned only by an Event.        My proposed solution:  ---------------------  1) Rewrite behavior: MultiInstanceBehavior meaning as following:       behavior: MultiInstanceBehavior =    all { None | First | Each | Complex} :   -----------------------------------------   The attribute behavior acts as a shortcut for specifying when events SHALL be thrown    from an Activity instance that is about to complete. It can assume val-   ues of None, One, All, and Complex, resulting in the following behav-   ior:   � None: no Event is ever thrown; a token is produced after completion    of all instances   � First: the EventDefinition referenced through the oneEvent    association will be thrown upon the first instance completing;   � Each: the EventDefinition which is associated through the    noneEvent association will be thrown for each instance    completing;   � Complex: the complexBehaviorDefinitions are consulted to    determine if and which Events to throw.       For the behaviors of First and Each, a default    SignalEventDefinition will be thrown which automatically carries    the current runtime attributes of the MI Activity.   Any thrown Events can be caught by boundary Events on the Multi-   Instance Activity.        3) Change oneBehaviorEventRef and noneBehaviorEventRef composition relationships    Unless an answer is provided to the referred event definition ownership.       2) Change the type of oneBehaviorEventRef and noneBehaviorEventRef to ThrowEvent    Unless an answer is provided to the referred event definition ownership.      4) Merge oneBehaviorEventRef and noneBehaviorEventRef into 'behaviorEventRef'

Resolution:
Revised Text:
Actions taken:
January 4, 2011: received issue

Discussion:

Issue 15954: conversion of choreographies to collaboration diagrams (bpmn2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

The XOR-Gateways in choreographies are defined. Also the conversion of choreographies with XORs to collaboration diagrams is described, however there are two issues for the conversion.       1st) The description in the specification states that event-based gateways should be used in collaboration. Figure 11.37 which depicts the example collaboration does not have any event-based gateway. So, please adapt the figure and show event-based gateways as following the description     2nd) if event-based gateways are used, then a time-out can occur.. on page 361 this likely time-out is mentioned... Please update the section on p359 accordingly to inform and consult the reader.

Resolution:
Revised Text:
Actions taken:
January 14, 2011: received issue

Discussion:

Issue 15955: major error in figures for corresponding diagrams (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary:

    In the choreography diagram in figure 11.42 Participant B sends a message to Participant A.       Figure 11.43 is the corresponding collaboration view. However, here Participant A sends a message to Participant B... Following, both figures are not equal, 11.43 is not the corresponding figure to 11.42...     The same error occurs for figures 11.45 and 11.44

Resolution:
Revised Text:
Actions taken:
January 14, 2011: received issue

Issue 15956: Wrong diagram (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary:

In figure 11.47 the pool Participant B contains a parallel gateway. The parallel gateway is named with a decision and the answers as a XOR-gateway should be named.     Please remove this description to follow the semantics of the parallel gateway

Resolution:
Revised Text:
Actions taken:
January 14, 2011: received issue

Discussion:

Issue 15957: Content of Section missing (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Just before Section 11.8 XML Schema for choreography there are two headings named "Choreography Task in Combined View" and "Sub-Choreography in Combined View". However, there is no content or description shown.     Please update the sections with their content.

Resolution:
Revised Text:
Actions taken:
January 14, 2011: received issue

Discussion:

Issue 15958: enumeration missing (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

On page the call activity is explained. In the enumeration starting with "If the Call Activity calls a Process, then there are two (2) options:........" there is only option displayed.   The second option is not shown as enumeration but with pure text. The text for the second option is "If the details of the called Process are available, then the shape of the Call Activity will be the same as a expanded  Sub-Process, but the boundary of the shape MUST have a thick line (see Figure 10.41)."    Please update the enumeration

Resolution:
Revised Text:
Actions taken:
January 14, 2011: received issue

Issue 15959: number of start events for sub-processes (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

The specification defines that the type for start-events of sub-processes can only be the none-type... However, the allowed number of start events for sub-processes is not mentioned... at least I couldn't find it throughout the whole specification.     As far as I understood BPMN, two none-typed start-events in sub-processes would not make sense but the point should clearly be described in a specification.

Resolution:
Revised Text:
Actions taken:
January 14, 2011: received issue

Issue 15970: Typo on page 76 (bpmn2-rtf)

Click here for this issue's archive.
Source: TIBCO (Mr. Justin Brunt, jbrunt(at)tibco.com)
Nature: Revision
Severity: Minor
Summary:

In the final line on page 76 (106 in physical document) there is a typo:  "For each Message that is exhanged as part of a particular Conversation". The word "exchanged" is missing the letter "c".

Resolution:
Revised Text:
Actions taken:
January 18, 2011: received issue

Issue 15971: Typo on page 77 (physical page 107) (bpmn2-rtf)

Click here for this issue's archive.
Source: TIBCO (Mr. Justin Brunt, jbrunt(at)tibco.com)
Nature: Revision
Severity: Minor
Summary:

Typo on page 77 (physical page 107) in the penultimate paragraph "atleast" should be "at least".

Resolution:
Revised Text:
Actions taken:
January 18, 2011: received issue

Issue 15973: Relationship from Choreography to Artifacts (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

According to Figure 8.8, Process and Sub-Process as well as Collaboration and Sub-Choreography have a relationship to artifacts. However, Choreography is missing.      In the text above, Choreography is mentioned:   When an Artifact is defined it is contained within a Collaboration or a FlowElementsContainer (a Process or Choreography).       Furthermore, section 11.3.2 specifies:  Both Text Annotations and Groups can be used within Choreographies and all BPMN diagrams. There are no restrictions on their use.

Resolution:
Revised Text:
Actions taken:
January 20, 2011: received issue

Discussion:

Issue 15974: Cardinality of id in BaseElement (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

According to Table 8.5 the id of BaseElement is of type string, and since no cardinality is specified, the cardinality is assumed to be [1]. However, according to the corresponding text:  If the element is not currently referenced and is never intended to be referenced, the id MAY be omitted.    If the id can be omitted, then the cardinality should be [0..1].

Resolution:
Revised Text:
Actions taken:
January 20, 2011: received issue

Discussion:

Issue 15990: Wrong document reference in dtc/2010-06-02 (bpmn2-rtf)

Click here for this issue's archive.
Source: Object Management Group (Ms. Linda Heaton, linda(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:

OLD  BPMN 2.0 by Example  Version 1.0 (non-normative)  _______________________________________________  OMG Document Number: dtc/2010-06-02  Standard document URL: https://www.omg.org/spec/BPMN/2.0/examples/PDF  Associated File: https://www.omg.org/spec/BPMN/2.0/examples/ZIP            NEW  BPMN 2.0 by Example  Version 1.0 (non-normative)  _______________________________________________  OMG Document Number: dtc/2010-06-02  Standard document URL: https://www.omg.org/spec/BPMN/20100601  Associated File*: https://www.omg.org/spec/BPMN/20100602  ________________________________________________  * dtc/2010-06-03 (machine-readable files)

Resolution:
Revised Text:
Actions taken:
January 26, 2011: received issue

Issue 15992: Incorrect Section References (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Revision
Severity: Minor
Summary:

Section 2.2.1 refers to Chapter 14 (Execution Semantics). But this chapter is actually Chapter 13.  Section 2.3 refers to Chapter 15 (BPEL Mapping). But this chapter is actually Chapter 14.  These references should be fixed.

Resolution:
Revised Text:
Actions taken:
January 27, 2011: received issue

Discussion:

Issue 16003: Incoming/Outgoing Data Associations of DataInputs/Outputs (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

According to page 213:  Data Inputs MAY have incoming Data Associations      and page 215:  Data Outputs MAY have outgoing DataAssociations    I think that it should be the other way round. A Data Input should have an outgoing Data Association and a Data Output should have an incoming DataAssociation. This would correspond with Figure 7.8. The Data Input "Part Requisition" only has an outgoing Data Association and vice versa, the Data Output "Part Requisition" only has an incoming Data Association.

Resolution:
Revised Text:
Actions taken:
February 2, 2011: received issue

Discussion:

Issue 16009: CallChoreographyActivity notation for called participants (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

The notation for CallChoreographyActivity  should show which of the caller's participants  (the ones in the bands) are associated with  which called participants by participant  associations. Perhaps this could be shown in  the bands.  Compare to the notation for  participant associations in the  CallConversation notation Figure 9.30  (Call Conversation Links).

Resolution:
Revised Text:
Actions taken:
February 7, 2011: received issue

Issue 16011: The XSLT for transforming to BPMN XMI has errors (bpmn2-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

The XSLT for transforming to BPMN XMI has errors.    There are many places where XML attributes are output after child elements which causes Saxon at least to fail the transformation.    Also, although not a fatal error, the XML namespaces for the source document should be removed from the target document.         I have updated the file so that it works for me � and can make it available.

Resolution:
Revised Text:
Actions taken:
February 7, 2011: received issue

Issue 16049: Procedure not defined (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The word procedure(s) is used 4 times in the document. It is not defined anywhere.  Surely all instances of procedure should read "process".  Otherwise it would be consistent to provide a definition of Procedure in Annex C

Resolution:
Revised Text:
Actions taken:
March 10, 2011: received issue

Issue 16051: Object mispelt (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Change Objec to Object in the Data Object line of Table 7.2

Resolution:
Revised Text:
Actions taken:
March 10, 2011: received issue

Discussion:

Issue 16052: Normal Process Not Defined (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The term "normal Process" is used three times in the document, but it is not defined anywhere

Resolution:
Revised Text:
Actions taken:
March 10, 2011: received issue

Discussion:

Issue 16053: Spello (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Change "recieved" in Fig 11.48 to "received"

Resolution:
Revised Text:
Actions taken:
March 10, 2011: received issue

Issue 16054: Change "recieved" in Fig 11.49 to "received" (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Change "recieved" in Fig 11.49 to "received"

Resolution:
Revised Text:
Actions taken:
March 10, 2011: received issue

Issue 16055: more typos (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Change "recieved" in Fig 11.49 to "received" six times - At least it is consistent.  Perhaps the USA has changed the rule:  "i before e except after c"

Resolution:
Revised Text:
Actions taken:
March 10, 2011: received issue

Issue 16060: BPMN2 issue: Example (DI lanes and nested lanes) appears to be invalid (bpmn2-rtf)

Click here for this issue's archive.
Source: Red Hat (Mr. Gary Brown, gbrown(at)redhat.com)
Nature: Uncategorized Issue
Severity:
Summary:

When opening the example  https://www.omg.org/spec/BPMN/2.0/examples/ZIP/Diagram%20Interchange/Examples%20-%20DI%20-%20Lanes%20and%20Nested%20Lanes.bpmn  throws an exception[1].    This happens because it tries to assign  org.eclipse.bpmn2.impl.DataObjectReferenceImpl object to an array of FlowNodes.    org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Value  'org.eclipse.bpmn2.impl.DataObjectReferenceImpl@6caf4065 (id:  DataObject_Document, anyAttribute: null) (name: Document)' is not legal.  (platform:/resource/Dev/Examples%20-%20DI%20-%20Lanes%20and%20Nested%20Lanes.bpmn2,  -1, -1)      at  org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)      at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:191)      at  org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:180)      at  org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1494)      at  org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1282)  ...  Caused by: org.eclipse.emf.ecore.xmi.IllegalValueException: Value  'org.eclipse.bpmn2.impl.DataObjectReferenceImpl@6caf4065 (id:  DataObject_Document, anyAttribute: null) (name: Document)' is not legal.  (platform:/resource/Dev/Examples%20-%20DI%20-%20Lanes%20and%20Nested%20Lanes.bpmn2,  -1, -1)      at  org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(XMLHandler.java:2663)      at  org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleForwardReferences(XMLHandler.java:1149)  ...  Caused by: java.lang.ArrayStoreException:  org.eclipse.bpmn2.impl.DataObjectReferenceImpl      at org.eclipse.emf.common.util.BasicEList.assign(BasicEList.java:124)      at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList.java:424)      at  org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUnique(NotifyingListImpl.java:331)      at  org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:315)      at  org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.setValue(XMLHelperImpl.java:1179)      at  org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(XMLHandler.java:2658)      ... 99 more

Resolution:
Revised Text:
Actions taken:
March 16, 2011: received issue

Discussion:

Issue 16063: BPMN 2.0 Spec Problems (from Typo's to More Serious Issues) (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Description: * Section 2: Table 2.3, note �a� [page 7]: Should be �Multiple incoming connections�� [incoming vs. outgoing] * Section 7: Tables 7.1 and 7.2 (and others?): Missing 'a' in front of 'company' in "An Activity is a generic term for work that company performs" * Section 7: Table 7.2, Activity [p. 32]: The spec seems to consistently use the spelling �Sub-Process� for sub-processes. Merriam-Webster indicates that �subprocess� is the correct form of the word (i.e. that sub is simply a prefix) and does not offer a hyphenated alternative (even though Microsoft Word complains �subprocess� is misspelled * Table 7.2, Choreography Task [p. 32]: Missing "or more" in "Each Choreography Task involves two (2) Participants", as they can specify more than 2 Participants. * Table 7.2 Conditional Flow [p.35]: Typo; should be �is� vs. �are� in "A Sequence Flow can have a condition Expression that are evaluated" (or should be "Expressions that are"). * Table 7.2 Compensation Association [p. 35]: The activity that is the target of the Compensation Association is missing the compensation indicator. * Section 8.3.1 Artifacts, Text Annotation [p. 71]: May contradict itself on open rectangle. Says �A Text Annotation is an open rectangle that MUST be drawn with a solid single line (as seen in Figure 8.16).� and then �text associated with the Annotation can be placed within the bounds of the open rectangle.� Isn't that "...MUST be placed within"? Why MUST you draw the open rectangle if text doesn't go within it, per Figure 8.16? * Section 10.2 Activities, [p.153]: completionQuantity says "This number of tokens will be sent done any..." and the 'done' should be 'down'. * Section 10.2.3 Tasks, Receive Task [p. 161]: "Once the Message has been received, the Task is completed." Is this worded correctly? If this Task doesn't do anything after the Message is received, then why use it instead of a Receive (Catch) Message Event? * Section 10.2.5 Subprocesses, page 177: The following is missing Timer (at a minimum; also missing Parallel Multiple?): �The Start Event trigger (EventDefinition) MUST be from the following types..." * Section 10.2.5 Subprocesses, page 177, Figure 10.30 is incorrect; it does not show the start event in upper-left corner like text says. * Section 10.2.8: pages 190 & 191, Figures 10.47, 10.48, and 10.49 contradict Table 12.8 on page 382 & 383 on the location of the multi-instance indicator (marker) for Collapsed Subprocesses. I assume Table 12.8 is correct. * Section 10.4: page 233: The word 'trigger' should be 'result' in the following sentence in list item 2: "The throwing of a trigger MAY be..." (Items 1 & 2 say "Events that catch a trigger" and "Events that throw a Result." So triggers are caught and results are thrown, correct? :) * Section 10.4.6, page 276, Figure 10.98: An Intermediate multiple event marker is used for a start event-based gateway, and it should be a start event marker (single line vs. double on the Event within the Gateway). * Section 10.4.6, page 277: The following seems to be missing Escalation Events at a minimum: �...or by running an Event Handler without canceling the Activity (only for Message, Signal, Timer and Conditional Events, not for Error Events).� * Section 10.8, page 309: Figure 10.1 was updated, but the references to activity names in the Figure were not updated in the first and second paragraphs of Section 10.8. For example ��in Figure 10.1 might execute or perform an extra Activity between Task �Receive Issue List� and Task �Review Issue List.�� * Section 11.4.1: Choreography Task [p. 327, 332]: The text is unclear about whether Participants can be multi-instance sequential, but I believe they can. As such, the language on page 327 of �The marker for a Choreography Task that is multi-instance MUST be a set of three vertical lines� and on page 332 of �The marker for a Sub-Choreography that is multi-instance MUST be a set of three vertical lines� seems incorrect and too limiting. If multi-instance sequential can be used, then three horizontal lines are also allowed (as is the 'loopback' repeat?). * Section 13.2.2 Activity [p. 429]: The fifth bullet says "(proposed for BPMN 2.0)" when this is the final spec, and non-interrupting EVent Handlers are part of the spec. This should be removed.

Resolution:
Revised Text:
Actions taken:
March 10, 2011: received issue

Issue 16102: Can Event Sub-Processes Loop? (bpmn2-rtf)

Click here for this issue's archive.
Source: Department of Veterans Affairs (Dr. Stephen White, steve.white(at)bookzurman.com)
Nature: Clarification
Severity: Significant
Summary:

An Event Sub-Process is a type of Sub-Process. Sub-Processes, as Activities, can have loop settings--meaning that the entire Sub-Process, from the start to the end can be repeated. But how does this work for an Event Sub-Process? Is the Start Event trigger for the Event Sub-Process expected to be repeated? or is the Start Event just ignored?

Resolution:
Revised Text:
Actions taken:
March 29, 2011: received issue

Issue 16108: BPMN 2.0: Errors in Section 6.2 Structure of this Document (bpmn2-rtf)

Click here for this issue's archive.
Source: Object Management Group (Dr. Jon M. Siegel, siegel(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:

In BPMN 2.0, formal/2011-01-03, Section 6.2 Structure of this Document is OK up to the reference to Chapter 10. However, it next references Chapter 11 Conversations which does not exist, and every reference after that has its chapter number incorrectly one too high: Chroeographies is 11, not 12. The visual diagram model is 12, not 13. and so on.

Resolution:
Revised Text:
Actions taken:
April 5, 2011: received issue

Issue 16159: Title of Figure 10.66 grammatically wrong (bpmn2-rtf)

Click here for this issue's archive.
Source: Camunda Services GmbH (Mr. Falko Menge, falko.menge(at)camunda.com)
Nature: Revision
Severity: Minor
Summary:

The title of Figure 10.66 seems grammatically wrong to me.      It reads:  "A Data Association used for an Outputs and Inputs into an Activities"      Proposal:  Change title of Figure 10.66 on page 222 (PDF 252) into:  "Data Associations used for Outputs from and Inputs into Activities"

Resolution:
Revised Text:
Actions taken:
April 21, 2011: received issue

Issue 16228: Error in Description for Multiple Instances in Table 7.2 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In the Description field for the Multiple Instances element in Table 7.2, the second sentance states "... three horizontal lines will be displayed ... for sequential Multi-Instances..." while the third sentance states "three vertical lines will be displayed ... for sequential Multi-Instances..."        Note that BOTH sentances refer to "sequential Multi-Instances".    Solution: the third sentance should refer to "parallel Multi-Instances".

Resolution:
Revised Text:
Actions taken:
May 12, 2011: received issue

Issue 16398: XML Schema not valid (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

The official XML Schema for BPMN 2.0 (https://www.omg.org/spec/BPMN/20100501/BPMN20.xsd) is not valid.       - It imports a schema with the schemaLocation "https://www.omg.org/spec/BPMN/20100501/Diagram Interchange.xsd", which does not exist.   Even when using the correct schemaLocation of "https://www.omg.org/spec/BPMN/20100501/DI.xsd", the namespace does not match (http://www.omg.com/di/1.0.0 vs. https://www.omg.org/spec/DD/20100524/DI)  (Note that one uses "omg.com" and the other uses "omg.org".)      - It includes the Schema "https://www.omg.org/spec/BPMN/20100501/Semantic.xsd", but its targetNamespace https://www.omg.org/spec/BPMN/20100524/MODEL does not match the including schema's value.      - The website https://www.omg.org/spec/BPMN/2.0/ has missmatching links for several items:   -- "https://www.omg.org/spec/BPMN/20100501/DI.xsd" links to      "https://www.omg.org/spec/BPMN/20100501/BPMNDI.xsd"  -- "https://www.omg.org/spec/BPMN/20100501/Semantic.xsd" links to "      https://www.omg.org/spec/BPMN/20100501/BPMNDI.xsd"

Resolution:
Revised Text:
Actions taken:
July 28, 2011: received issue

Issue 16546: BPMN 2.0 Choreography issues page 339 of dtc/2010-06-05 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

N.B. In the reminder /dtc/2010-06-05 /is the BPMN 2.0 specification. ------ ISSUE START ------ Page 339 of /dtc/2010-06-05/ reads as follows: “There are situations when a Participant for a Choreography Task is actually a multi-instance Participant. A multi-instance Participant represents a situation where there are more than one possible related Participants (PartnerRoles/ PartnerEntities) that might be involved in the Choreography. For example, in a Choreography that involves the shipping of a product, there can be more than one type of shipper used, depending on the destination.” Page 344 of /dtc/2010-06-05/ reads almost verbatim, but referring to multi-instance participants in Sub-choreographies: “There are situations when a Participant for a Sub-Choreography is actually a multi-instance Participant. A multi-instance Participant represents a situation where there are more than one possible related Participants (PartnerRoles/ PartnerEntities) that can be involved in the Choreography. For example, in a Choreography that involves the shipping of a product, there can be more than one type of shipper used, depending on the destination.” First of all, the above wordings are unclear with respect to which of the following two cases applies at run-time with multi-instance participants: 1. Exactly one partner entity (as defined on Page 117 of /dtc/2010-06-05/) out of many possible ones during the enactment of the choreography. 2. One or more partner entities partake the choreography enactment. We could not find in the /dtc/2010-06-05/any wording that clarifies which of the two possible meanings is the correct one. We assume (2) for consistency with the Orchestration part of the specification. However, having a multi-instance participant resolve to multiple partner entities during the enactment raises several serious issues: * Multi-instance recipient participants in a choreography task violate the assumption that each choreography task involves exactlytwo partner entities, which is a fundamental assumption for the specification of Message Exchange Patterns (MEPs) in Choreography Tasks. * Similarly to the previous case: how to deal with Choreography Task senders that are multi-instance participants? How many initiating messages are actually sent? Even more complicated issues arise from multi-instance participants in terms of the enforceability of choreographies. For example, if the partner entities that resolve a given multi-instance participant are decided at enactment time, how are the other partner entities supposed to know (and therefore be able to deliver messages to them)? It is our opinion that multi-instance participantsis a complicated construct to deal with in Choreographies, and should be thoroughly re-considered (possibly leading to its elimination from the specification).

Resolution:
Revised Text:
Actions taken:
September 14, 2011: received issue

Issue 16547: BPMN 2.0 Choreography issues page 327 of dtc/2010-06-05 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Page 327 of /dtc/2010-06-05/ runs as follows (emphasis in the last sentence added): “To leverage the familiarity of flow charting types of Process models, BPMN Choreographies also have “activities” that are ordered by Sequence Flows. These “activities” consist of one (1) or more interactions between Participants. These interactions are often described as being message exchange patterns (MEPs). A MEP is the atomic unit (“Activity”) of a Choreography. Some MEPs involve a single Message (e.g., a “Customer” requests an “Order” from a “Supplier”). Other MEPs will involve two (2) Messages in a request and response format (e.g., a “Supplier” request a “Credit Rating” from a “Financial Institution,” who then returns the “Credit Rating” to the “Supplier”). There can be even more complex MEPs that involve error Messages, for example.” This wording may result confusing to practitioners. First of all, there is no way in BPMN 2.0 Choreographies to mark a message as an “error message”. What the specification seems to hint at is that some of the messages in the choreography may deliver information over errors. However, since BPMN 2.0 Choreographies (and, more generally, BPMN 2.0 as a whole) does not differentiate among the possible “typologies” of messages (e.g. error, acknowledgement, invocation, or response), there is no immediate way to map WSDL 1.1/2.0 MEPs to single Choreography Taskswithout losing some information (e.g. the distinction between output messages and fault messages). Even using the structureRefof the message(see e.g. Page 7 of /dtc/2010-06-05/) to point to a WSDL 1.1/2.0 message, this would provide no information about what “type” of message it is. In fact, in WSDL 1.1/2.0 a message is “labelled” as input, output or fault only in the WSDL operations, so much that a given WSDL message could, for example, be input in one operation and a fault in another. Secondly, despite the fact that the text mentions Choreography Activities as the realization of MEPs (i.e. also Sub-choreographies), the reference to MEPs as atomic units sounds intuitively related to Choreography Tasks. Given the fact that it is not possible to (1) specify error messages and (2) specify the sequencing in a single Choreography Taskfor more than two messages, a single Choreography Taskallows the specification of only the WSDL 1.1 “one-way messaging” and “notification” MEPs. In fact, the specification of “request/reply” and “solicit/response” MEPs is not possible because their faults cannot be represented in the same Choreography Tasktogether with the input and output messages. To clarify this issues, the specification should address clearly and in detail the relation between BPMN 2.0 Choreographies and MEPs in WSDL 1.1 and WSDL 2.0, in particular with relation to the granularity of the MEPs (Choreography Task-level, Sub-choreography level, etc.). Moreover, it is still an open issue how to map WSDL 2.0 Complex MEPs to BPMN 2.0 Choreographies.

Resolution:
Revised Text:
Actions taken:
September 14, 2011: received issue

Issue 16548: BPMN 2.0 Choreography issues page 338 of dtc/2010-06-05 about Sub-choreographics (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

On Page 338 of /dtc/2010-06-05/, about Sub-choreographies: “The Participant Band of the Participant that does not initiate the interaction MUST be shaded with a light fill.” This wording does not cover some corner cases. Consider the example depicted in the attached image Example Issue Initiating Participant in Sub-Choreographies.png. In the choreography above it is unknown until the enactment of Task 1which participant is the initiator of Sub-choreography 1. But this is only the symptom of a wider-reaching problem. When there is no choreography task that dominates of all the others (or worse, there is a race condition!), and the various choreography tasks that may be executed as first have different initiators, modelers have no way to pick which participant is marked as the initiator of the sub-choreographies. The same issue with initiators of sub-choreographies affects also the messages sent by them. In fact, Page 93 of /dtc/2010-06-05/reads: “Any Message sent by the non-initiating Participant or Sub-Choreography MUST be shaded with a light fill.” We propose two possible, mutually exclusive solutions: 1. Additional constraints are specified for choreographies so that no such corner case can occur. However, this is very likely to result in not being able to model with BPMN 2.0 choreographies some inter-organizational processes that can instead be modeled with BPMN 2.0 Orchestrations. 2. Drop the differentiation between initiator and non-initiator participants in sub-choreographies. We see no real shortcoming resulting from this approach. In particular, with respect to the enactability of choreographies, knowing which participant is the first to act in a sub-choreography gives no guarantees as to the fact that the same participant will also be involved in the “last” choreography activities to be executed in that sub-choreography. Therefore, we can extract no useful information from it with respect to the enactability of what follows that sub-choreography. This is particularly true in the case of collapsed sub-choreographies.

Resolution:
Revised Text:
Actions taken:
September 14, 2011: received issue

Issue 16549: meta-model doesn't provide way to serialize intermediate catch events attached to participant bands of choreography task (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

On pp. 341~343 the specification details some intermediate catch events that can be attached to activity boundaries, namely Message, Timer, Cancel, Compensation, Conditional, Signal and Multiple. This is similar to attaching events to activities in Process diagrams. The meta-model supports attaching of events to activity boundaries in Processes through the BoundaryEvent element. However, no similar element is available for Choreography Activities. Instances of BoundaryEvent obviously cannot be used (because ChoreographyActivity does not extend Activity). Therefore a new Class should be added. This class (called e.g. ChoreographyBoundaryEvent) should (1) have a reference to the ChoreographyActivity to which the event is attached, and (2) depending on the type of event, specify to which of the ParticipantBands the event is attached. This is necessary because some events, namely Message, Cancel and Compensation are "local" (i.e. visible) to only one of the Participants involved in the ChoreographyActivity. The specification should clearly state in which cases this reference to a Participant is compulsory, and in which cases optional. For example, it might be optional in the case of Signal events, to symbolize that the event is trigger by the reception of the signal by one particular participants (which is different than the "firing" of the signal, given the fact that the specification does not seem to require signals to be "immediately" received, but just "eventually" received by the participants).

Resolution:
Revised Text:
Actions taken:
September 14, 2011: received issue

Issue 16550: Process name in property mapping is "statically" derived not "statistically" (bpmn2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

The mapping of "getProcessProperty(propertyName)" to BPEL reads "$[{processName}.propertyName] where the right process-Name is statistically derived."   "statistically" does not fit in this context, the name should be derived "statically" from the process in which the current expression is used.

Resolution:
Revised Text:
Actions taken:
September 15, 2011: received issue

Issue 16551: Unclear introduction of the concept of MEP (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Page 315 reports the following text on MEPs: �To leverage the familiarity of flow charting types of Process models, BPMN Choreographies also have �activities� that are ordered by Sequence Flows. These �activities� consist of one (1) or more interactions between Participants. These interactions are often described as being message exchange patterns (MEPs). A MEP is the atomic unit (�Activity�) of a Choreography. Some MEPs involve a single Message (e.g., a �Customer� requests an �Order� from a �Supplier�). Other MEPs will involve two (2) Messages in a request and response format (e.g., a �Supplier� request a �Credit Rating� from a �Financial Institution,� who then returns the �Credit Rating� to the �Supplier�). There can be even more complex MEPs that involve error Messages, for example.� This wording may result confusing to practitioners for the following reasons. First of all, there is no way in BPMN 2.0 Choreographies to mark a message as an �error message�. What the specification seems to hint at is that some of the messages in the choreography may deliver information over errors. However, since BPMN 2.0 Choreographies (and, more generally, BPMN 2.0 as a whole) does not differentiate among the possible �typologies� of messages (e.g. error, acknowledgement, invocation, or response), there is no immediate way to map WSDL 1.1/2.0 MEPs to single Choreography Tasks without losing some information (e.g. the distinction between output messages and fault messages). Even using the structureRef of the message (see e.g. Page 7 of dtc/2010-06-05) to point to a WSDL 1.1/2.0 message, this would provide no information about what �type� of message it is. In fact, in WSDL 1.1/2.0 a message is �labelled� as input, output or fault only in the WSDL operations, so much that a given WSDL message could, for example, be input in one operation and a fault in another. Secondly, despite the fact that the text mentions Choreography Activities as the realization of MEPs (i.e. also Sub-choreographies), the reference to MEPs as atomic units sounds intuitively related to Choreography Tasks. Given the fact that it is not possible to (1) specify error messages and (2) specify the sequencing in a single Choreography Task of more than two messages, a single Choreography Task allows the specification of only the WSDL 1.1 �one-way messaging� and �notification� MEPs. In fact, the specification of �request/reply� and �solicit/response� MEPs is not possible because their faults cannot be represented in the same Choreography Task alongside the input and output messages. To clarify this issues, the specification should address clearly and in detail the relation between BPMN 2.0 Choreographies and MEPs in WSDL 1.1 and WSDL 2.0, in particular with relation to the granularity of the MEPs (Choreography Task-level, Sub-choreography level, etc.). Additionally, it might be beneficial to for the sake of clarity to explicitly that it is outside the scope of ChoreographyTasks to be able to map entire WSDL 2.0 Complex MEPs, but that, instead, they have to be realized by multiple choreography tasks appropriately sequenced.

Resolution:
Revised Text:
Actions taken:
September 15, 2011: received issue

Issue 16552: Underspecification of initiating/non-initiating participants in non-trivial choreographies (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Resolution:
Revised Text:
Actions taken:
September 15, 2011: received issue

Issue 16553: Underspecification of Multi-instance participants in Choreographies (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Page 327 reports the following text on multi-inistance participants:      "There are situations when a Participant for a Choreography Task is actually a multi-instance Participant. A multiinstance  Participant represents a situation where there are more than one possible related Participants (PartnerRoles/  PartnerEntities) that might be involved in the Choreography. For example, in a Choreography that involves  the shipping of a product, there can be more than one type of shipper used, depending on the destination."      Page 344 of dtc/2010-06-05 reads almost verbatim, but referring to multi-instance participants in Sub-choreographies:      �There are situations when a Participant for a Sub-Choreography is actually a multi-instance Participant. A multiinstance  Participant represents a situation where there are more than one possible related Participants (PartnerRoles/  PartnerEntities) that can be involved in the Choreography. For example, in a Choreography that involves the  shipping of a product, there can be more than one type of shipper used, depending on the destination.�      The above wordings seem unclear with respect to which of the following two cases applies at run-time with multi-instance participants:  1) Exactly one partner entity (as defined on Page 117 of dtc/2010-06-05) out of many possible ones during the enactment of the choreography.  2) One or more partner entities partake the choreography enactment.      We assume (2) for consistency with the Orchestration part of the specification. However, having a multi-instance participant resolve to multiple partner entities during the enactment of the choreography raises several serious issues:      * Multi-instance recipient participants in a choreography task violate the assumption that each choreography task involves exactly two partner entities, which is a fundamental assumption for the specification of Message Exchange Patterns (MEPs) in Choreography Tasks.  * Similarly to the previous case: how to deal with Choreography Task senders that are multi-instance participants? How many initiating messages are actually sent?  * Assuming both the sender and recipient of a ChoreographyTask to be multi-instance, how many message exchanges actually take place? All the possible permutations?    Even more complicated issues arise from multi-instance participants in terms of the enforceability of choreographies. For example, if the partner entities that resolve a given multi-instance participant are decided at enactment time, how are the other partner entities supposed to know (and therefore be able to deliver messages to them)?

Resolution:
Revised Text:
Actions taken:
September 15, 2011: received issue

Issue 16554: Underspecification of ChoreographyLoopType (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

The loop types of choreography activities do not provide any information about: (1) the "hard-coded" cardinality of the loop (how often is the loop repeated) or (2) the expression that must be evaluated during the choreography enactment based on the data contained in the messages exchanged up to that point during the enactment. In the latter case, specifying the expression is not enough: for reasons of enforceability, it should be possible to specified which participant(s) must evaluate the expression.

Resolution:
Revised Text:
Actions taken:
September 16, 2011: received issue

Issue 16566: Some BPEL4People links are dead (bpmn2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

Following links for BPEL4People (chapter 3.2 non-Normative, page 13) are dead and should therefore be removed or replaced:      http://www.active-endpoints.com/active-bpel-for-people.htm (this link is also duplicated)      http://dev2dev.bea.com/arch2arch/    http://www.oracle.com/technology/tech/standards/bpel4people/

Resolution:
Revised Text:
Actions taken:
September 26, 2011: received issue

Issue 16632: XML Schema: Usage of xsd:anyAttribute instead of xsd:attribute (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Table 8.3 ("Definitions XML schema") on page 54 contains the following two lines:      <xsd:anyAttribute name="exporter" type="xsd:ID"/>  <xsd:anyAttribute name="exporterVersion" type="xsd:ID"/>      As the usage of the "name" attribute in combination with the "xsd:anyAttribute" element makes no sense, those lines should be changed to:      <xsd:attribute name="exporter" type="xsd:ID"/>  <xsd:attribute name="exporterVersion" type="xsd:ID"/>    As the XSD-Files given at www.omg.org/spec/BPMN/2.0/ also use "xsd:attribute" for those lines, I suppose this is just a copy&paste error in the specification document.

Resolution:
Revised Text:
Actions taken:
October 19, 2011: received issue

Issue 16877: Use XPath 2.0 as default expression language instead of XPath 1.0 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

XPath 1.0 is the default expression language in BPMN 2.0. Instead of XPath 1.0, the default expression language should be XPath 2.0 which is a W3C Recommendation since 14 December 2010 (and I assume that is why it has not made it into BPMN 2.0).      A major problem with XPath 1.0 is its limited set of functions. For instance, XPath 1.0 does not provide any time-related functions. Consequently, it is impossible to get the current system time in an expression, which might be necessary in Timer Events, without proprietary extensions to the standard. This harms portability of process models and is especially relevant for Process Execution Conformance. XPath 2.0 provides such functions and the time-related data types used in both, BPMN 2.0 and XPath 2.0, are identical (ISO-8601).      This change might affect several parts of the specification:  In section 10.3.3 The usage of XPath as expression language in BPMN 2.0 is discussed. There, several additional XPath-functions are defined, mentioning deficiencies in XPath 1.0. These functions should be redefined with XPath 2.0.  Section 14 Mapping BPMN Models to BPEL might also require changes. XPath 1.0 is the default language required by BPEL 2.0 and XPath 2.0 functions that are not present in XPath 1.0 cannot be mapped as easily.    I would strongly recommend for BPMN 2.0 to require the support for XPath 2.0 instead of XPath 1.0 as default expression language.

Resolution:
Revised Text:
Actions taken:
December 6, 2011: received issue

Issue 16903: Title of Figure 10.122 doesn't match its contents (bpmn2-rtf)

Click here for this issue's archive.
Source: Camunda Services GmbH (Mr. Falko Menge, falko.menge(at)camunda.com)
Nature: Revision
Severity: Minor
Summary:

The title of Figure 10.122 on page 304 (PDF 334) is 'Monitoring Class Diagram', but the figure shows Compensation through a Compensation Event Sub-Process.      The same title is also used for Figure 10.129, where it matches the contents. So this seems to be a copy and paste issue.      Proposal:  Change title of Figure 10.122 on page 304 (PDF 334) to 'Compensation through a Compensation Event Sub-Process'.

Resolution:
Revised Text:
Actions taken:
December 14, 2011: received issue

Issue 16904: Is compensation allways triggered automatically upon uncaught errors? (bpmn2-rtf)

Click here for this issue's archive.
Source: Camunda Services GmbH (Mr. Falko Menge, falko.menge(at)camunda.com)
Nature: Clarification
Severity: Significant
Summary:

Page 180 (PDF 210) states:  'Note that other mechanisms for interrupting a Transaction Sub-Process will not cause compensation (e.g., Error, Timer, and anything for a non-Transaction Activity).'      Whereas page 305 (PDF 335) states:  'If no error Event Sub-Process is specified for a particular Sub-Process and a particular error, the default behavior is to  automatically call compensation for all contained Activities of that Sub-Process if that error is thrown, ensuring the behavior for auditing and monitoring.'      These statements seem contradicting to me and  therefore I'd like to get a clarification on the following questions:      1. Is compensation allways triggered automatically upon uncaught errors?  2. Is there a difference between compensation of a Transaction Sub-Process and any other Sub-Process?

Resolution:
Revised Text:
Actions taken:
December 14, 2011: received issue

Issue 17037: visualization enumeration level (bpmn2-rtf)

Click here for this issue's archive.
Source: University of Applied Sciences Dresden (Mr. Michael Gruenert, nobody)
Nature: Revision
Severity: Minor
Summary:

This Document is hard to read. The enumerations begins all with a rectangle independent from their level. Particularly if  there is a picture or a table between the enumerations.  I think it is better to use different signs for enumeration, depending on the level in the enumeration.  (rectangle filled, rectangle unfilled, circle filled, circle unfilled).    I know, this fact depends on at the OMG-Template (it concerns not only the BPMN-Document, I think). Now, it�s time to change the template. :)

Resolution:
Revised Text:
Actions taken:
January 24, 2012: received issue

Issue 17038: Missing Enumeration (bpmn2-rtf)

Click here for this issue's archive.
Source: University of Applied Sciences Dresden (Mr. Michael Gruenert, nobody)
Nature: Revision
Severity: Significant
Summary:

At page 184 you write �If the Call Activity calls a Process, then there are  two options:� Under this sentence there is only one enumeration (only one  option? Or is the sentence �If the details of the called Process are�  the second option? But this sentence has no enumeration).

Resolution:
Revised Text:
Actions taken:
January 24, 2012: received issue

Issue 17039: item-aware element vs. ItemAwareElement (bpmn2-rtf)

Click here for this issue's archive.
Source: University of Applied Sciences Dresden (Mr. Michael Gruenert, nobody)
Nature: Revision
Severity: Significant
Summary:

ItemAwareElement: item-aware element (Example on page 205) vs. ItemAwareElement (Example on page 204) � there are two different spellings.  There are also two different meanings?

Resolution:
Revised Text:
Actions taken:
January 24, 2012: received issue

Issue 17040: eXclusive Gateway (bpmn2-rtf)

Click here for this issue's archive.
Source: University of Applied Sciences Dresden (Mr. Michael Gruenert, nobody)
Nature: Clarification
Severity: Minor
Summary:

There are two types of signs for the Exclusive Gateway. Why? It is better to use only the sign with the �X�. Finally it is an eXclusive Gateway :)  -> Mr. Juergen Boldt answered: "[..] It is left open to the modeler as a matter of taste."  OK.  -> But IMHO BPMN 2.0 is a standard. There is no leeway for matter of taste. I think.  ---------  (Look at the road traffic or specification of your voltage wich comes from your socket. That is no matter of taste.  )

Resolution:
Revised Text:
Actions taken:
January 24, 2012: received issue

Issue 17043: ItemAwareElement the second (bpmn2-rtf)

Click here for this issue's archive.
Source: University of Applied Sciences Dresden (Mr. Michael Gruenert, nobody)
Nature: Enhancement
Severity: Minor
Summary:

At page S.223: �Model Associations of DataAssociation:   The source/target MUST be an temAwareElement.� Now, I have to look: what is an ItemAwareElement? (So I use strg+F to search. But remember, there are two different spellings*.. :) ) I think it is better to mention the source/target directly.    * have a look on my reported issue 'item-aware element vs. ItemAwareElement'.

Resolution:
Revised Text:
Actions taken:
January 24, 2012: received issue

Issue 17044: MAY NOT (bpmn2-rtf)

Click here for this issue's archive.
Source: University of Applied Sciences Dresden (Mr. Michael Gruenert, nobody)
Nature: Revision
Severity: Significant
Summary:

You use �MAY NOT�. But it is not referenced in RFC-2119. I think it is important in a standard-document to define keywords.   p. 99/111/112/..

Resolution:
Revised Text:
Actions taken:
January 24, 2012: received issue

Issue 17045: Catch None intermediate event (bpmn2-rtf)

Click here for this issue's archive.
Source: University of Applied Sciences Dresden (Mr. Michael Gruenert, nobody)
Nature: Revision
Severity: Significant
Summary:

On page 272 you talk about a �Catch None intermediate event�. But at the table on page 261 there is no �Catch none intermediate event�. There is a �Throw none intermediate event�    -> It would be good, if you would change the text on page 272.

Resolution:
Revised Text:
Actions taken:
January 24, 2012: received issue

Issue 17046: wrong reference on page 292 (bpmn2-rtf)

Click here for this issue's archive.
Source: University of Applied Sciences Dresden (Mr. Michael Gruenert, nobody)
Nature: Clarification
Severity: Minor
Summary:

At page 292 last sentence: �[...] precise synchronization behavior of the Inclusive Gateway can be found on page 292� � I don�t found it.    It would be good, if you correct the reference.

Resolution:
Revised Text:
Actions taken:
January 24, 2012: received issue

Issue 17047: Incomming sequence flow at start event (bpmn2-rtf)

Click here for this issue's archive.
Source: University of Applied Sciences Dresden (Mr. Michael Gruenert, nobody)
Nature: Revision
Severity: Significant
Summary:

An interesting rule (page 245):  �A Start Event MUST NOT be a target for Sequence Flows; it MUST NOT have incoming Sequence Flows. An exception to this is when a Start Event is used in an Expanded Sub-Process and is attached to the boundary of that Sub-Process. In this case, a Sequence Flow from the higher-level Process MAY connect to that Start Event in lieu of connecting to the actual boundary of the Sub-Process.�      I never found a tool who implements this rule. On page 261 a �Boundary Start event� does not exist. Only Intermediate Events are of type �boundary� (interrupting/non-interrupting). Or interrupting/non-interrupting Start Events for an Event-Sub-Process (but they are not of type �boundary�).    -> is it ok to remove this exception?

Resolution:
Revised Text:
Actions taken:
January 24, 2012: received issue

Issue 17069: Reference omitted in BPMN 2 11-01-03 (bpmn2-rtf)

Click here for this issue's archive.
Source: Object Management Group (Dr. Jon M. Siegel, siegel(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:

On page 315, after this sentence about Service Interaction Patterns -      Message exchanges between partners go beyond simple request-response interactions into multi-cast, contingent requests, competing receives, streaming, and other service interaction patterns      comes the cryptic phrase      (REF for SIP)      It looks like this is a stand-in for a Reference for Service Interaction Patterns - right?      If so, it might be replace with a footnote referring to this Barros article -  Service Interaction Patterns: Towards a Reference  Framework for Service-Based Business Process  Interconnection  http://eprints.qut.edu.au/2295/1/ServiceInteractionPatterns.pdf

Resolution:
Revised Text:
Actions taken:
January 27, 2012: received issue

Issue 17106: Table 7.2 Description of Multiple Instances (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In the Table 7.2 description of Multiple Instances, it says in the second sentence that "A set of three horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-instances." In the third sentence, it again says that the set of three vertical lines is also for sequential multi-instances. A revision needs to be made to correctly state what the three horizontal lines and three vertical lines stand for.

Resolution:
Revised Text:
Actions taken:
February 9, 2012: received issue

Issue 17130: Unclear meaning of "�" symbol (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In Table 7.3 - Sequence Flow Connection Rules, under the column designated by the Activity notation, there are "�" (per mil) symbols instead of arrows. Unable to find an explanation in the document for "�", is this an error and should it also be an arrow?

Resolution:
Revised Text:
Actions taken:
February 14, 2012: received issue

Issue 17146: Travel Booking Example (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

On page 27 of the above document there is an explanation of a Travel Booking process model.       In the 7th paragraph, there is a statement which says "If an error arises during the booking activities, the flight and hotel room reservations are reversed and the Client record is updated. The booking is tried again as long as the booking retry limited is not exceeded."        I believe that part of this statement may be incorrect as the client record is only updated if there is an error in the payment activity which is outside of the subprocess.       Could you please clarify?

Resolution:
Revised Text:
Actions taken:
February 20, 2012: received issue

Issue 17365: Looping/Multi-instantiation description error (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Current text reads: "A set of three horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see upper figure to the right).      A set of three vertical lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see lower figure to the right)."    The three vertical lines depict parallel multi-instantiation, not sequential...(according to page 191 of spec)

Resolution:
Revised Text:
Actions taken:
May 9, 2012: received issue

Issue 17468: Wrong attribute name "attachedTo" for Bounday event (bpmn2-rtf)

Click here for this issue's archive.
Source: BonitaSoft S.A. (Mr. Aurelien Pupier, nobody)
Nature: Clarification
Severity: Minor
Summary:

Wrong attribute name "attachedTo" for Bounday event    It should be "attachedToRef".

Resolution:
Revised Text:
Actions taken:
July 9, 2012: received issue

Issue 17528: Revision & clarification for interruption of looping / multi-instance sub-processes (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

In Table 10.88 � End Event Types (page 248) it�s written:      �Terminate � This type of End indicates that all Activities in the Process should be immediately ended. This includes all instances of multi-instances.�      However, in 13.4.6 � End Events (page 443) it�s written:      �For a �terminate� End Event, the Sub-Process is abnormally terminated. In case of a multi-instance Sub-Process, only the affected instance is terminated�no other ongoing Sub-Process instances or higher-level Sub-Process or Process instances are affected.�      So, it seems to be a contradiction: first it�s written all instances of multi-instances are terminated, but after it�s written only one instance is terminated.      CLARIFICATION =============      Since the contradiction mentioned above, I think it�s also needed to clarify how many instances are terminated when a multi-instance Sub-Process is interrupted via Boundary Event or via Event Sub-Process.      The specification also does not mention how the interruption of a looping Sub-Process should be handled: is only the current iteration interrupted (like the �continue� statement in software programming), or the whole loop is interrupted (like the �break� statement in software programming)? So, it�s needed to clarify this behavior for interruptions triggered via terminate End Event, Boundary Events and Event Sub-Processes.    This issue is related to Issue #14824.

Resolution:
Revised Text:
Actions taken:
July 20, 2012: received issue

Issue 17548: Significant typo in BPMN 2.0 v1.0 formal/2011-01-03 (bpmn2-rtf)

Click here for this issue's archive.
Source: Object Management Group (Dr. Jon M. Siegel, siegel(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:

In the definitions of interrupting and non-interrupting events, on the page numbered 280 (which is sequential page 310 of the pdf), under the heading      Interrupting Event Handlers (Error, Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)      the first sentence reads, correctly --      Interrupting Event Handlers are those that have the cancelActivity attribute is set to true.      In the next section, under the heading      Non-interrupting Event Handlers (Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)      the first sentence reads, incorrectly --      Interrupting Event Handlers are those that have the cancelActivity attribute is set to false.      Clearly the authors meant to start this sentence with      Non-interrupting Event Handlers are ...      but forgot to edit in the "Non" after the copy'n'paste. Right?

Resolution:
Revised Text:
Actions taken:
August 9, 2012: received issue

Issue 17563: Association - an Artifact or a Connecting object? (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Section 7.2 states that Association is a Connecting Object, whereas Section 8.3.1 states that Association is an Artifact.  Could you clarify please

Resolution:
Revised Text:
Actions taken:
August 23, 2012: received issue

Issue 18143: Inconsistent Naming of Multi-instance Activity (bpmn2-rtf)

Click here for this issue's archive.
Source: Camunda Services GmbH (Mr. Falko Menge, falko.menge(at)camunda.com)
Nature: Revision
Severity: Minor
Summary:

The caption of section 13.2.7 speaks about a 'Multiple Instances Activity' whereas the rest of the specification uses the term 'Multi-instance Activity'.      Proposal:  Rename section 13.2.7 to 'Multi-instance Activity'.

Resolution:
Revised Text:
Actions taken:
October 8, 2012: received issue

Issue 18246: Incorrect wording for description, should read "parallel" instead of "sequential" (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In Table 7.2, in the description for the Multiple Instances element, it should read   "A set of three vertical lines will be displayed at the bottom-center of the activity for parallel Multi-Instances (see lower figure to the right)."   instead of  "A set of three vertical lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see lower figure to the right)."

Resolution:
Revised Text:
Actions taken:
November 5, 2012: received issue

Issue 18256: flowNodeRefs containment and subprocess clarification (bpmn2-rtf)

Click here for this issue's archive.
Source: BonitaSoft S.A. (Mr. Aurelien Pupier, nobody)
Nature: Clarification
Severity: Significant
Summary:

does FlowNode that are inside a SubProcess should be listed in flowNodeRefs of a lane?      I found no official sample for this use case but several different implementations among BPMN Tools.  All offical samples with SubProcess have them directly in a pool so no flowNodeRefs

Resolution:
Revised Text:
Actions taken:
November 9, 2012: received issue

Issue 18264: Picture doesn't correspond to the description (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

The sentence on page 177 (207)  If the Event Sub-Process is collapsed, then its Start Event will be used as a marker in the upper left  corner of the shape (see Figure 10.30).  does not seem to correspond with the picture (i.e. there is no start event)

Resolution:
Revised Text:
Actions taken:
November 10, 2012: received issue

Issue 18265: Page 217: Send Task Mapping, first sentence (bpmn2-rtf)

Click here for this issue's archive.
Source: NobleProg (Mr Bernard Szlachta, anbo(at)nobleprog.com)
Nature: Clarification
Severity: Minor
Summary:

...there MUST be at most '''one''' outputSet...  Receive Task Mapping  first sentance the same missing word "one" as above  the last sentence:  ... is not present, the '''payload''' (is: payloard  There are quite a few typos I discovered. Is there any easier way of submitting suggestions and small bugs?  Is there anyway to work on the new version (so I do not bother correct errors which already have been corrected)?

Resolution:
Revised Text:
Actions taken:
November 10, 2012: received issue

Issue 18322: Wrong references to ItemAwareElement in UML diagram (bpmn2-rtf)

Click here for this issue's archive.
Source: Munkert Software (Mr. Frank Munkert, )
Nature: Revision
Severity: Significant
Summary:

In the UML diagram "Fig. 10.51 - DataObject class diagram", it looks as if DataObject and DataObjectReference are specializations of ItemAwareElement.       According to "10.3.4 XML Schema for Data" and according to the text above the diagram, this is not true.      Therefore, the "specialization arrows" must be replaced by "associations" (i.e. a simple arrow head instead of a hollow triangle).

Resolution:
Revised Text:
Actions taken:
December 23, 2012: received issue

Issue 18394: Cover Page Title (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Abbreviation of �Business Process Model and Notation�  is incorrect. Change �BMPN� to �BPMN�

Resolution:
Revised Text:
Actions taken:
February 1, 2013: received issue

Issue 18395: Section 3.3 OMG UML (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

This document refers to Unified Modeling Language Specification V2.1.2. However, the ISO standard version is UML 2.4.1. If there isn�t inconsistency, this document should refer to ISO version. Besides, the semantic models use the UML class diagram. Therefore, UML is the normative reference, not non-normative reference. Move UML reference to normative section as well as check the adequate version.

Resolution:
Revised Text:
Actions taken:
February 1, 2013: received issue

Issue 18396: Section 3.2 Normative (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

This document uses �Element�, the MOF element on the Figure 8.7. Therefore, MOF is normative reference. Add the MOF as normative reference

Resolution:
Revised Text:
Actions taken:
February 1, 2013: received issue

Issue 18397: Section 3.3 BPEL4People (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

BPEL specifications refer to non-public documents, such as www.adove.com, dev2dev.bea.com, www-128.ibm.com, www.oracle.com, www.sdn.sap.com. These reference should refer to public standards.  http://docs.oasis-open.org/bpel4people/bpel4people-1.1-spec-cd-06.pdf

Resolution:
Revised Text:
Actions taken:
February 1, 2013: received issue

Issue 18398: Section 7.6 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

This section is informative.  Remove this section or move to informative section.

Resolution:
Revised Text:
Actions taken:
February 1, 2013: received issue

Issue 18399: Section 8.1 Figure 8.2 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

There is an explanation of �infrastructure� following section and figure 8.1. However, there isn�t the package infrastructure on the package diagram on Figure 8.2. Is it O.K.?  Clarify this

Resolution:
Revised Text:
Actions taken:
February 1, 2013: received issue

Issue 18400: Section 8.3.4 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

There are a lot of  � enclosed string, such as, �identity/relationship�. It seems to be meaningless. On page 83, there are �happens� and �event�. Remove ���.

Resolution:
Revised Text:
Actions taken:
February 1, 2013: received issue

Issue 18401: Typo in section 8.4 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

suc clauses ? typo sub clauses

Resolution:
Revised Text:
Actions taken:
February 1, 2013: received issue

Issue 18402: Title (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Spelling error in the title, OMG BMPN should be OMG BPMN

Resolution:
Revised Text:
Actions taken:
February 1, 2013: received issue

Issue 18403: Entire document (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The OMG BPMN 2 Revision Task force is working to resolve editorial and clarification issues against the text in DIS 19510.  It is important that the corrections resolving these defects be reflected in the published ISO/IEC Standard for OCL. The editing group for ISO/IEC DIS 19510 should consider all changes against the text of BPMN 2, resulting from the latest minor revision to BPMN 2 available at the time of the ballot resolution meeting

Resolution:
Revised Text:
Actions taken:
February 1, 2013: received issue

Issue 18501: Repeated use of previous definition for conflicting task attributes (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Table 7.2 - BPMN Extended Modeling Elements      Multiple Instances      Definition of the use of vertical lines as a task attribute is incorrectly captured as the same as horizontal, as follows:      A set of three  horizontal lines will be displayed at the  bottom-center of the activity for sequential  Multi-Instances (see upper figure to the right).      A set of three vertical lines will be displayed at  the bottom-center of the activity for sequential Multi-Instances (see lower figure to the right).      This should read as follows:      A set of three  horizontal lines will be displayed at the  bottom-center of the activity for sequential  Multi-Instances (see upper figure to the right).      A set of three vertical lines will be displayed at  the bottom-center of the activity for parallel Multi-Instances (see lower figure to the right).

Resolution:
Revised Text:
Actions taken:
February 26, 2013: received issue

Issue 18787: Extend BPMN with a element that subclasses an existing BPMN element (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

'Section 8.2.3 Extensibility' on page 57 of the BPMN 2.0 specification states:      "The BPMN metamodel is aimed to be extensible. This allows BPMN adopters to extend the specified metamodel in a way that allows them to be still BPMN-compliant."      On page 58 it is stated that:      "Every BPMN element which subclasses the BPMN BaseElement can be extended by additional attributes. This works by associating a BPMN element with an ExtensionDefinition, which was defined at the BPMN model definitions level (element Definitions)."      Question:  Is it possible to extend BPMN with an element that subclasses an existing BPMN element?      For example, is it possible to extend BPMN with a new task element that subclasses the BPMN Task, similar to how e.g. a ManualTask or UserTask subclasses the BPMN Task? If this is possible, could you provide an example?

Resolution:
Revised Text:
Actions taken:
July 2, 2013: received issue

Issue 18906: BPMN typo (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

There is typo error of the word "variation". It is written as "va riation" in the document

Resolution:
Revised Text:
Actions taken:
September 12, 2013: received issue

Issue 18981: Editorial: Wrong description of Figure 10.79 in the text (bpmn2-rtf)

Click here for this issue's archive.
Source: Camunda Services GmbH (Mr. Falko Menge, falko.menge(at)camunda.com)
Nature: Revision
Severity: Minor
Summary:

There is a Copy & Paste typo on page 265 (PDF 295).      Text: "Figure 10.79 shows the variations of Conditional Events"  Figure Caption: "Figure 10.79 � Error Events"      Proposal:  Change text to "Figure 10.79 shows the variations of Error Events"

Resolution:
Revised Text:
Actions taken:
September 30, 2013: received issue

Issue 19068: An invalid statement regarding Black Box depiction of pools (bpmn2-rtf)

Click here for this issue's archive.
Source: Trisotech (Mr. Denis Gagne, dgagne(at)trisotech.com)
Nature: Revision
Severity: Significant
Summary:

In section 9.2  First paragraph  3rd bullet should be removed.  It states  "If the Pool is a black box (i.e., does not contain a Process), then the label for the Pool MAY be placed  anywhere within the Pool without a single line separator."      This is incorrect a pool always has a line separating the label.  This is how one can visually distinguish between a pool and a a lane.    All depictions in examples were corrected during FTF but this one line stayed behind and should be removed.

Resolution: An invalid statement regarding Black Box depiction of pools
Revised Text:
Actions taken:
November 6, 2013: received issue

Issue 19083: Suspected definition error in DataObject.isCollection (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In Table 10.52 the description of DataObject.IsCollection reads "If an itemDefinition is referenced, then this attribute MUST have the same value as the IsCollection attribute of the referenced itemDefinition".      This description prevents BPMN from defining a collection of DataObjects on a single Item Aware Element referred to by an Item Definition. Therefore, if I wish to model an individual item X and a collection of item X they need to reference different item definitions - surely this is not the intent.      I propose rewording this sentence to read "If a referenced itemDefinitions isCollection attribute is set to true, then this attribute MUST also be set to true".      I don't know if there is a flow-on effect to other areas of the documentation.

Resolution:
Revised Text:
Actions taken:
November 14, 2013: received issue

Issue 19092: References to invalid sub clauses (incorrect sub clause numbers) (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In chapter 2, sub clause 2.1, page 1 it is written that "Process Modeling Conformance type SHALL comply with all of the requirements set forth in sub clause 2.1". However, the requirements are set forth in sub clause 2.2. Also, the sentences after that refer to sub clauses 2.2, 2.3 and 2.4 but these should refer to 2.3, 2.4 and 2.5.     In short: references to the requirements for the different conformance types should be to 2.2, 2.3, 2.4 and 2.5 and not 2.1, 2.2, 2.3 and 2.4.

Resolution:
Revised Text:
Actions taken:
November 18, 2013: received issue

Issue 19166: Allowable start events for event sub-process inconsistently defined (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

There is an apparent conflict in the specification concerning the permissible Start Event types for an Event Sub-Process.      On Page 174, the specification states: "The Start Event of an Event Sub-Process MUST have a defined trigger. The Start Event trigger (EventDefinition) MUST be from the following types: Message, Error, Escalation, Compensation, Conditional, Signal, and Multiple."  This enumeration excludes the Timer and Parallel event types.      This specification appears inconsistent with the restriction on Page 241, which additionally allows Timer and Parallel event types for the Start Event: "A Start Event can also initiate an inline Event Sub-Process (see page 174). In that case, the same Event types as for boundary Events are allowed (see Table 10.86), namely: Message, Timer, Escalation, Error, Compensation, Conditional, Signal, Multiple, and Parallel."    It is consequently unclear whether Timer and Parallel events may be the Start Event in an Event Sub-Process.

Resolution:
Revised Text:
Actions taken:
December 23, 2013: received issue

Issue 19176: Wrong sub clauses are referenced (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Version 2.0.1 is still referring to the sub clauses 2.1-2.4 (as in Version 2.0) even though they have changed to 2.2-2.5

Resolution:
Revised Text:
Actions taken:
January 7, 2014: received issue

Issue 19196: Invalid use of MAY NOT keyword (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

In several occasions, the BPMN 2.0.1 specification uses the keywords "MAY NOT". This keywords, however, are not valid according to RFC 2119.    Probably "MUST NOT" would be correct. (Please note: the opposite of "MAY" is not "MAY NOT"!)

Resolution:
Revised Text:
Actions taken:
January 28, 2014: received issue

Issue 19318: Sequencing rule for Choreography activities causes ambiguous execution semantics? (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

(p.336:) The basic rule of Choreography Activity sequencing is this: ?&#61472;The Initiator of a Choreography Activity MUST have been involved (as Initiator or Receiver) in the previous Choreography Activity. As far as I can tell this rule seems to imply some ambiguity as to the execution semantics of the Choreography diagram. To explain this, I give an example of two different Choreography designs of one and the same collaboration: Design version 1 involves 5 message exchanges , three choreography activities A, B and C and 4 participants, 1,2,3 and 4. The activities are listed below in execution order : 1. Activity A : 1.1. 1 sends message to 2 2. Activity B: 2.1. 3 sends message to 2 2.2. 2 sends message to 4 2.3. 4 returns message to 2 3. Activity C: 3.1. 2 sends confirmation of message sent by 1 (in 1.1.) Design version 2 involves the same 5 message exchanges into two choreography activities A and B involving the same 4 participants listed below in execution order: 1. Activity A : 1.1. 1 sends message to 2 1.2. 2 sends confirmation of message sent by 1 (in 1.1., but after receiving message sent by 4 in 2.3.) 2. Activity B: 2.1. 3 sends message to 2 2.2. 2 sends message to 4 2.3. 4 returns message to 2 {Question 1: are observations below correct or not? } Both designs seem to meet the criterion mentioned in the BPMN standard specification mentioned in the first paragraph above. The second has the advantage that the message exchanges 1.1. and 1.2. which are logically strongly related are combined in one activity. But the execution semantics implied by the two designs are quite different. The first design implies that an activity can only start after completion of the previous activity. The second design implies that an activity can only start after the previous activity has started. The basic rule of Choreography Activity sequencing seems to allow both interpretations. {Question 2: is the issue below a valid point in your opinion ? } If the first interpretation is chosen, then there is the question what is meant by �completion�. That might mean different things for the sender and receiver of the last message exchanged. The sender is finished when he sent the last message. The receiver might first need to do some internal processing before it is completed. So this interpretation runs the risk of being ambiguous. {Question 3: can you please comment on this ? } The second interpretation could make it less straightforward to understand the ordering of activities from the diagram. On the other hand it does allow more room for combining logically related message exchanges in one activity (as 1.1. and 1.2. in activity A in the second interpretation). This raises the general question on how the Choreography diagrams and Conversation diagrams are conceptually related. They seem to be addressing a similar requirement for expressing communication between Business actors, but it is unclear how they are or should be related.

Resolution:
Revised Text:
Actions taken:
March 30, 2014: received issue

Issue 19352: [BPMN 2.0.2] bug issue concerning event sub process (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

I read BPMN 2.0.2 specification and I found a mistake on an illustration??(I think):     p174 (205 of PDF) ??:     If the Event Sub-Process is collapsed, then its Start Event will be used as a marker in the upper left corner of the shape (see Figure 10.30).    P175     There is no marker in the upper left corner of the collapsed event sub-process

Resolution:
Revised Text:
Actions taken:
April 22, 2014: received issue

Issue 19413: bug issue concerning event-based gateway (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

I read BPMN 2.0.2 specification and I found a mistake on a table (I think):     P329 of PDF or p299 of BPMN specification :     The attribute can only be set to parallel when the instantiate attribute is set to true.      I assume its wrong. A better sentence would be :    The attribute can only be set to parallel when the instantiate attribute is set to false.    Am I correct ?

Resolution:
Revised Text:
Actions taken:
May 13, 2014: received issue

Issue 19414: bug issue concerning event-based gateway illustration 10.98 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Figure 10.98 need another type of gateway.     This gateway is not correct because it is lauching process activity.    It would be correct with a complex start event within gateway (not an intermediate as it is).

Resolution:
Revised Text:
Actions taken:
May 13, 2014: received issue

Issue 19461: Section 10.3.4 Human Performer is not peorperly defined for implementation interpretation (bpmn2-rtf)

Click here for this issue's archive.
Source: Trisotech (Mr. Denis Gagne, dgagne(at)trisotech.com)
Nature: Clarification
Severity: Critical
Summary:

It is not specifically stated in the spec whether  "HumaPerformer" is an abstract class.  It seems to be, but then the meta model (fig 10.23) depicts only one specialization  namely "PotentialOwner" leaving in question the need for this abstraction.  Furthermore "PotentialOwner" only

Resolution:
Revised Text:
Actions taken:
June 11, 2014: received issue

Issue 19470: Bug p385 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

??    I found a problem in illustration 11.43 (p385 of pdf & p355 of norm) . The message flow between participant A & participant B is not well definied. Direction need to be change (from participant B to participant A & not from A to B).  It's the same for figure 11.45 (message flow from participant B to participant A and not from participant A to participant B)      ??

Resolution:
Revised Text:
Actions taken:
June 14, 2014: received issue

Issue 19471: figure 13.1 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

I may be wrong but I assume figure 13.1 is wrong

Resolution:
Revised Text:
Actions taken:
June 15, 2014: received issue

Discussion:

Issue 19473: Missing event marker in Figure 10.30 (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

The specification says: "If the Event Sub-Process is collapsed, then its Start Event will be used as a marker in the upper left  corner of the shape (see Figure 10.30)."    But the referenced figure does not show any marker event. Therefore, either the text or the figure is wrong.

Resolution:
Revised Text:
Actions taken:
June 16, 2014: received issue

Discussion:

Issue 19600: word catalogue in the Figure 5.3: Order Fulfillment (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

I found a tiny error in the document which is titled as  dtc-10-06-02.pdf (BPMN 2.0 by Example Version 1.0) i hope you'll  correct it.      the error is in the word catalogue in the Figure 5.3: Order Fulfillment

Resolution:
Revised Text:
Actions taken:
September 15, 2014: received issue

Issue 19614: Artifact used as an example for FlowElement (bpmn2-rtf)

Click here for this issue's archive.
Source: W4 (Mr. Benjamin Michel, benjamin.michel(at)w4software.com)
Nature: Clarification
Severity: Minor
Summary:

On page 71 of the spec, in the Category chapter, in the Table 8.23, the attribute categorizedFlowElements of the CategroyValue element is descibed as follow :      categorizedFlowElements: FlowElement [0..*]  The FlowElements attribute identifies all of the elements (e.g.,Events, Activities, Gateways, and Artifacts) that are within the boundaries of the Group.  But Artifact is not a FlowElement, so it must not appear as an example of the latter

Resolution:
Revised Text:
Actions taken:
September 24, 2014: received issue

Issue 19666: Typo: Data Object spelled Objec (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In the image of Table 7.2 for Data Object, next to the Data Object (Collection) it reads Data Objec (Collection).

Resolution:
Revised Text:
Actions taken:
November 28, 2014: received issue

Issue 19708: Use of per mille symbol unclear (�) (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In table 7.3 the per mille (�) sign is used in the third column. I suspect the arrow was meant.

Resolution:
Revised Text:
Actions taken:
January 14, 2015: received issue

Issue 19709: Second occurance of sequential Multi-Instances should be parallel (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In Table 7.2 the text for Multiple Instances says the three vertical lines mean sequential MI. I believe it nust be parallel, three horizontal lines mean sequential.

Resolution:
Revised Text:
Actions taken:
January 14, 2015: received issue

Issue 19735: Table 7.2 wrong reference to type of multi-instance (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

In table 7.2, page 37 it's written:      ...A set of three  horizontal lines will be displayed at the  bottom-center of the activity for sequential  Multi-Instances (see upper figure to the right).  A set of three vertical lines will be displayed at  the bottom-center of the activity for sequential  Multi-Instances (see lower figure to the right).      It should say:  ...A set of three  horizontal lines will be displayed at the  bottom-center of the activity for sequential  Multi-Instances (see upper figure to the right).  A set of three vertical lines will be displayed at  the bottom-center of the activity for  parallel  Multi-Instances (see lower figure to the right).

Resolution:
Revised Text:
Actions taken:
March 20, 2015: received issue

Issue 19736: Wrong clause reference (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

1. In the first sentence "Special type of Process Execution Conformance that supports the BPMN mapping to WS-BPEL as specified in sub clause  15.1 can claim BPEL Process Execution Conformance." I believe that "clause 15.1" should actually be "clause 14.1".    2. I am not sure about possible error of the same type in the previous chapter: chapter 2.3.1 contains reference to 14.2.2, it might be 13.3.2.

Resolution:
Revised Text:
Actions taken:
March 26, 2015: received issue

Issue 19745: message and error ref in tOperation does not define the correct type name (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

In Table 8.66, the spec says the inMessageRef and outMessageRef should be type of Message, however, in the xml schema below (table 8.68), the element type of inMessageRef  and outMessageRef is a QName, not Message. similar issue happens on errorRef as well. table 8.66 says errorRef type should be Error, but the schema defines its type to a QName.

Resolution:
Revised Text:
Actions taken:
April 17, 2015: received issue

Issue 19762: Default value of DataStore.isUnlimited differs between Table 10.55 and XML Schema (bpmn2-rtf)

Click here for this issue's archive.
Source: Camunda Services GmbH (Mr. Falko Menge, falko.menge(at)camunda.com)
Nature: Revision
Severity: Minor
Summary:

Table 10.55 defines the default value of DataStore.isUnlimited to be false:  isUnlimited : boolean = false      However, the XML Schema says:  <xsd:attribute name="isUnlimited" type="xsd:boolean" default="true"/>      Proposal:  Change the XML Schema to:  <xsd:attribute name="isUnlimited" type="xsd:boolean" default="false"/>

Resolution:
Revised Text:
Actions taken:
May 27, 2015: received issue

Issue 19763: Figure 10.57 does not show that InputOutputSpecification derives from BaseElement (bpmn2-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Figure 10.57 does not show that InputOutputSpecification derives from BaseElement.    The textual description and the related XSD schema correctly show that InputOutputSpecification derives from BaseElement. However, figure 10.57 does not have an arrow for this inheritance.

Resolution:
Revised Text:
Actions taken:
May 28, 2015: received issue

Issue 19765: Attribute name "error" should actually by "errorRef" (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Table 10.96 states that there is attribute, called "error", while the XSD schema contains attribute "errorRef".

Resolution:
Revised Text:
Actions taken:
May 29, 2015: received issue

Discussion:

Issue 19766: Wrong table reference number (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

There are actually 2 errors (wrong Table numbers) in the last 2 sentences on the page:      "The DataObject element inherits the attributes and model associations of FlowElement (see Table 8.44) and  ItemAwareElement (Table 10.52). Table 10.54 presents the additional attributes of the DataObject element."      The correct Table numbers should be:  * ItemAwareElement (Table 10.51)  * DataObject (Table 10.52)

Resolution:
Revised Text:
Actions taken:
May 31, 2015: received issue

Issue 19767: Wrong name of object (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

"Table 10.54  presents the additional attributes and model associations of the DataObject element."      should be:  "Table 10.54  presents the additional attributes and model associations of the DataState element."

Resolution:
Revised Text:
Actions taken:
May 31, 2015: received issue

Issue 19768: Wrong table reference number (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

    "Table  10.54 presents the additional attributes of the Property element."      should be:  "Table  10.57 presents the additional attributes of the Property element."

Resolution:
Revised Text:
Actions taken:
May 31, 2015: received issue

Issue 19769: Wrong table reference number (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

"Figure 10.54 presents the additional attributes and model associations of the  InputOutputSpecification element."      I believe, this should not even be a figure, but a Table, and with different number:      "Table 10.58 presents the additional attributes and model associations of the  InputOutputSpecification element."

Resolution:
Revised Text:
Actions taken:
May 31, 2015: received issue

Issue 19770: Wrong table reference number (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

"Table 10.60 presents the additional attributes and model associations of the  DataInput element."      should be:      "Table 10.60 presents the additional attributes and model associations of the  DataOutput element."

Resolution:
Revised Text:
Actions taken:
May 31, 2015: received issue

Issue 19771: Contradiction - can or cannot show Data Object multiple times on a diagram (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

p.206 states:      Visual representations of Data Objects  Data Object can appear multiple times in a Process diagram. Each of these appearances references the same Data Object instance. Multiple occurrences of a Data Object in a diagram are allowed to simplify diagram connections.        p.368 states:      Multiple depictions of a specific BPMN element in a single diagram is NOT allowed, except for Participants in a choreography (i.e., Participant Bands). For example, it is not allowed to depict a Task twice in the same diagram, but it is allowed to depict the same Task in two different diagrams.      This seems like a contradiction. Only one of the above should be true.

Resolution:
Revised Text:
Actions taken:
May 31, 2015: received issue

Discussion:

Issue 19826: Table 8.51 ref error (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

"Table 8.51 presents the additional model associations for the Resource element."  should be   "Table 8.49 presents the additional model associations for the Resource element."      "Table 8.51 presents the additional model associations for the  ResourceParameter element."  should be  "Table 8.50 presents the additional model associations for the  ResourceParameter element."

Resolution:
Revised Text:
Actions taken:
August 7, 2015: received issue

Issue 19831: Unclear execution semantics of MI activities with complex behavior (bpmn2-rtf)

Click here for this issue's archive.
Source: Munkert Software (Mr. Frank Munkert, )
Nature: Clarification
Severity: Minor
Summary:

"Table 10.31 - ComplexBehaviorDefinition attributes and model associations" contains the following text: "This attribute defines a boolean Expression that when evaluated to true,  cancels the remaining Activity instances and produces a token."      In chapter "13.3.7 Multiple Instances Activity", where the execution semantics are described, however, there is no mentioning that multi-instance activities with complex behavior cancel instances as soon the ComplexBehaviorDefinition's condition becomes true.    Probably the text fragment "cancels the remaining Activity instances and" in the table is wrong and should be removed. Otherwise, the execution semantics chapter should be extended accordingly.

Resolution:
Revised Text:
Actions taken:
September 9, 2015: received issue

Issue 19839: Multiple Instances - Both types of diagram described as Sequential (bpmn2-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Textual description of the two Multiple Instance shape types (2nd column) describe both shapes as "Sequential", whereas one should be "Sequential", and the other "Parallel".      Text copied belowL      "A set of three horizontal lines will be displayed at the bottom-center of the activity for SEQUENTIAL Multi-Instances (see upper figure to the right).    "A set of three vertical lines will be displayed at the bottom-center of the activity for SEQUENTIAL Multi-Instances (see lower figure to the right)."

Resolution:
Revised Text:
Actions taken:
October 12, 2015: received issue

Issue 19887: Missing Element in BPMN 2.0.2 ? (bpmn2-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

I refer to BPMN Spec. Version 2.0.2.     I really miss the data storage element which is supported by all BPMN tools that I know:              in Spec. chapter 7.3.1 or 7.3.2.     What happened with this element ??

Resolution:
Revised Text:
Actions taken:
March 17, 2016: received issue