We have been puzzling over the meaning of the MultiIinstance Paralllel Marker and believe that there’s a conflict in the description. We saw this in the 1.0 specification and then checked to see if the 1.1 specification had changed in any way but found it to be the same. We believe there needs to be clarification around the MultipleInstance loop MI_Ordering attribute with regards to the task marker symbol that should be used. Here’s the basic description (we’re giving table/figure references from v 1.1 draft of BPMN spec).… BPMN spec says that Standard loop will look like Figure 9.15 Image 1 And Multi Instance loop will look like Figure 9.15 Image 2 However in Table 9.20 Multi-Instance Loop Activity Attributes in the MI_Ordering attribute description it clearly states that… If set to Parallel, the Parallel marker SHALL replace the Loop Marker at the bottom center of the activity shape (see Figure 9.9 and Table 9.18). This suggests that a Multi-Instance Loop task that is set to sequential would actually have the Standard Loop Marker. The question is, which statement is correct, the first… “Standard Loop activities will have a marker that is a circle with an arrow and Multi-Instance Loop activities will have a marker that is two parallel vertical lines” Or the second… “A Parallel Multi-Instance activity will have a marker that is two parallel vertical bars. Standard loops and sequential multi-instance activities will have a marker that is a circle with an arrow on it”. These statements made in the BPMN spec seem to be contradictory. Now, to us, whether the task instances are performed in parallel or sequential is the most significant thing to display visually on the diagram. And therefore we actually think that the second statement should be true. However, whether the condition is evaluated once or on each loop iteration could also be significant enough to be visible in the diagram. We actually think that there are 3 significant pieces of information that BPMN is trying to convey with only 2 markers and associated attributes. § Separate Task instances are run in parallel. § Separate Task instances are run sequentially, and if so… o The loop exit condition is a Boolean expression and is re-evaluated on each loop iteration. o The condition is a Numeric expression that is evaluated only once before loop begins and specifies a maximum value for LoopCounter. We think that there are 2 possibilities to overcome this problem and clarify the meaning… 1) Add a new value to the Standard Loop TestTime attribute – OnceBefore – this states that the expression is numeric and specifies the number of loop iterations. Then remove the MI_Ordering attribute i.e. all Multi-Instance loops are parallel. It may be useful to introduce a new marker symbol to distinguish between OneBefore and Before/After (if it is deemed significant enough to been seen at diagram level). 2) Leave all the attributers as they are but introduce a new marker symbol for “The condition is a Numeric expression that is evaluated only once before loop begins and specifies a maximum value for LoopCounter” (i.e. a Multi-Instance Loop with MI_Ordering set to sequential. In either case, if all three pieces of information are deemed significant enough to been seen at diagram level, here are our suggestions… Multi-Instance + Parallel - use parallel bar symbol Standard Loop Before/After (Evaluated On every iteration) … You could, also distinguish between before and after by say, turning the symbol upside down for evaluate-before… Because the circle as a break in it then it suggests (maybe?) that the process engine stops to re-evaluate things each time round the loop. Multi-Instance + Sequential (or new Standard Loop + OnceBefore… Use circle with no break Because the circle has no break in it then it suggests (maybe?) that the process engine already knows how many times to go around.

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

In clause 9.7.2 and 10.1.4, it is stated that a data object artifact can be associated with a (Sequence or Message) Flow.
But the meaning of association with a Sequence Flow is not
clearly stated.

In Figure 9.40 there is an example of an association of a data object to a Sequence Flow between two Activities. Is such an association only permitted when the Flow is between two Activities? Is it permitted when the flow is between an Activity and a Gateway?

For example, could Figure 9.40 have two activities on the right, with an exclusive data gateway (decision) routing the data object to one or the other under certain conditions?

Is there a meaning to associating the data object with a Sequence Flow that terminates in an Event (throw or catch)?

Proposed Resolution:

When the flow originates from an Activity, the data object is an output of that Activity that is available at the time of the flow. When the flow terminates in an Activity, the data object is an input to that Activity that is available at the time the Activity starts. (This is the conclusion to be drawn from the current text. But these statements are independent of what is on the other end.)

If the flow originates from a gateway or event, BPMN assigns no meaning to the association with respect to that end, but a conforming tool may.

If the flow terminates in a gateway or event, the data object is an "input" artifact that is available when the Gateway decision is made, the Event is thrown, or the wait for the Event begins. The artifact, or the knowledge of its availability, may be used in making the Gateway decision or throwing or handling the Event.

The preferred representation of a data object "flowing" past a gateway or event is to show two (or more) associations:
output from the originating activity and input to the activity (or activities) that use the artifact. (And there should be an example of this.)

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

BPMN does not have a symbol for a physical storage facility. This is important to highlight for management process diagrams since such facilities that may be a source of signifant costs and delays. (This comment is intended for consideration in BPMN 2.0)

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

BPMN does not explicitly identify a model element for "approval." This is important to highlight for control issues and regulatory compliance concerns. An approval symbol is apparently common in management consultant diagrams. A equlateral triangle with one edge at the base has been used for this. (this issue intended for BPMN 2.0).

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

Page 1 (PDF page 25) Section 1 includes the text: "Note – This version does provide a non-normative mapping from BPMN to WSBPEL, but the BPMN specification itself is known to be incomplete with respect to capturing all the required information for WSBPEL. So the mapping is insufficient, in any case." This says one can't make a mapping from WSBPEL to BPMN. It doesn't prevent a mapping from BPMN to WSBPEL.

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

The first sentence on page 171 states:
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.

I think that in the mentioned sentence "User Task" should be replaced by "Manual Task".
The sentence is still in the section of the Manual Task and the User Tasks starts afterwards also providing its own statement stating that the User Task inherits the attributes and model associtations of Activity.

No Data Available

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”

The following text is from page 280:
There are three (3) variations of None
Events: a Start Event, a catch Intermediate Event, and an End Event (see Figure 10.91).

The catch None Intermediate Event MUST only be used in normal flow and, thus, MAY NOT be attached to the boundary of an Activity.

However, according to Table 10.93 and the former text, a None-Trigger is allowed for a Start Event, End Event and for a throw Intermediate Event but not for a catch Intermediate Event.

resolved

On page 273, after the heading Error Event, the following text is displayed: Figure 10.79 shows the variations of Conditional Events.

However, the actual section describes Error Events and Figure 10.79 also shows Error Events.

resolved

It says
“Table 10.3 presents the additional attributes of the Sub-Process element:”

It should say
“Table 10.20 presents the additional attributes of the Sub-Process element:”

“Table 10.3” should be replaced by “Table 10.20”

resolved

I was going through the BPMN 2.0 Specifications and found some conflicting
content regarding choreographies. In section 7.4 Use of Text, Color, Size,
and Lines in a Diagram, the third indented point of the bullet "The fills
that are used for the graphical elements MAY be white or clear" states
that "Participant Bands for Choreography Tasks and Sub-Choreographies that
are not the initiator of the activity MUST have a light fill. This does
not seem to be consistent with what is depicted in Figure 7.7 An example
of a stand-alone choreography diagram. It is also not consistent with the
discussions on Choreography in the same document in Section 11.4.1
Choreography Task.

withdrawn by submitter

Page 203, Table 10-26, multiInstanceLoopCharacteristics: I believe that the motivation behind having events thrown in coordination with the completion of instances of multiInatnce activity is to have non-interrupting boundary events to carry out some desired ackownledgements (or other defined activites), but if the catching boudnary event is interrupting, the alternate flow will be followed potentially resulting in un-expected or suspected behavior.

What is the intended use case if the catching boudnary event is interrupting?

The design of the MI activity was done with the use case in mind that the catching boundary event is non-interrupting.
However, we do not see a strong reason to rule out that the catching boundary event could be interrupting.
Disposition: Closed, No Change

Doc: dtc/06-02-01
Date: February 2006
Version: Final Adopted Specification
Chapter: B.11
Pages: 101
Nature: Editorial
Severity: minor

Description:

The list of supporting object types in B.11 does not include the following:
Gate, which is actually documented under Gateway
Input set, which is documented under Process
Output set, which is documented under Process
Trigger, which is documented under Event.

Each of these supporting objects, together with its proper attributes (extracted from wherever it is documented), should be included in B.11.

Recommendation:

Add 4 subsections to B.11:

Before B.11.4 (Message), add:

B.11.a Gate, with the following attributes:

"Outgoing SequenceFlow: SequenceFlow
Each Gate SHALL have one associated Sequence Flow. The constraints on the SequenceFlow depend on the kind of Gateway.

"Assignments (0..n): Assignment
One or more assignment expressions MAY be made for each Gate. The
Assignment SHALL be performed when the Gate is selected. The details of
Assignment is defined in the Section B.11.1, "Assignment," on page 268."

B.11.b Input(Set), with the following attributes:

"Inputs (1-n) : Artifact
One or More Inputs SHALL be defined for each InputSet. An Input is an Artifact, usually a Document Object."

Before B.11.6 (Participant), add:

B.11.c Output(Set), with the following attributes:

"Outputs (1-n) : Artifact
One or more Outputs MUST be defined for each OutputSet. An Output is an
Artifact, usually a Document Object."

Before B.11.11 (Webservice), add:

B.11.d Trigger, with the following attributes:

Trigger (None | Message | Timer | Rule | Link | Multiple) None : String
Trigger defines the type of trigger, and determines what other attributes are permitted or required. The Trigger list MAY be extended to include new types.

[Message Trigger only]
Message : Message
If the Trigger is a Message, then the Message SHALL be specified. (See B.11.4).

[Message Trigger only]
Implementation (Web Service | Other | Unspecified) Web Service : String
This attribute specifies the technology that will be used to receive the message. A Web service is the default technology.

[Timer Trigger only]
TimeDate (0-1) : Date
If the Trigger is a Timer, then a Date MAY be specified. The TimeDate specifies the point in time at which the Timer Event will occur. If a TimeDate is not specified, then a TimeCycle SHALL be specified (see the attribute below).

[Timer Trigger only]
TimeCycle (0-1) : String
If the Trigger is a Timer, then a TimeCycle MAY be specified. The TimeCycle specifies the elapsed time between TimerEvents. If a TimeCycle is not
specified, then a TimeDate MUST be specified (see the attribute above).

[Rule Trigger only]
RuleName : Rule
If the Trigger is a Rule, then the triggering Rule SHALL be specified. (See B.11.9) The Rule specifies the observable state of affairs that triggers the RuleEvent.

[Link Trigger only]
LinkId : String
If the Trigger is a Link, then the LinkId SHALL be specified. The LinkId specifies the name of the Link (signal) that triggers the LinkEvent when it is presented by the Process designated by the ProcessRef attribute (see below).

[Link Trigger only]
ProcessRef : Process
If the Trigger is a Link, then the ProcessRef SHALL be specified. ProcessRef specifies the Process that is the source of the Link (signal) for which the Trigger is waiting. The identified Process MAY be the same Process as that of the Link Event.

see above

Doc: ptc/06-02-01
Date: February 2006
Version: Final Adopted Specification
Chapter: 9.5
Pages:
Nature: Editorial
Severity: minor

Description:

In 9.5.1 Common Elements of Gateways, the object type Gate is not documented. But Gate appears, with the same two attributes (Outgoing flow, Assignments) in every subtype of Gateway in 9.5, and once for each role of Gate in that kind of Gateway. Moreover, the initial text for its attributes in each occurrence is the same. Some of the specific roles of Gate have special requirements as well, and this must be puzzled out from the current tables for the Gateways.

The common concept Gate and the attributes of Gate with their common characteristics should be specified in 9.5.1, as a supporting object. Then in each of the subsections where the use of a Gate has special rules, only the special rules need to appear, and they should attach to the Gateway attribute that is the particular use/role of the Gate that imposes the constraint.

Recommendation:

In 9.5.1 add a subsection for Gate, e.g.

"Gate

"A Gate represents the point at which a Gateway is connected to an outgoing SequenceFlow. A given Gateway can have several Gates, one for each outgoing SequenceFlow. Each kind of Gateway imposes different constraints on the SequenceFlow, and some types of Gateway distinguish Gates with different kinds of constraints on the SequenceFlow.

"Table 9.xx Gate Attributes

"Outgoing SequenceFlow: SequenceFlow
Each Gate SHALL have one associated Sequence Flow. The constraints on the SequenceFlow depend on the kind of Gateway.

"Assignments (0..n): Assignment
One or more assignment expressions MAY be made for each Gate. The
Assignment SHALL be performed when the Gate is selected. The details of
Assignment is defined in the Section B.11.1, "Assignment," on page 268."

In table 9.27 (XOR Gateway attributes), delete the entries for Outgoing SequenceFlow and Assignments. Under the Gates attribute description, add a paragraph:
"For each Gate, the Outgoing Sequence Flow (See Table 9.xx on page xxx) SHALL have its Condition attribute set to None (there is no evaluation of a condition expression).
The attributes of a Sequence Flow can be found in Section 10.1.2,
"Sequence Flow," on page 100."

In table 9.28 (IOR Gateway attributes), delete both sets of entries for Outgoing SequenceFlow and Assignments.

Under the Gates attribute description, add a paragraph:
"For each Gate, except the DefaultGate, if any, the Outgoing Sequence Flow (See Table 9.xx on page xxx) SHALL have its Condition attribute set to Expression. The Outgoing Sequence Flow SHALL have a valid ConditionExpression, and the ConditionExpression SHALL be unique among all the Gates within the Gateway.
The attributes of a Sequence Flow can be found in Section 10.1.2,
"Sequence Flow," on page 100."

Under the DefaultGate attribute description, add a paragraph:
"For the Default Gate, the Outgoing SequenceFlow (See Table 9.xx on page xxx) SHALL have its Condition attribute set to Default. The SequenceThe
The attributes of a Sequence Flow can be found in Section 10.1.2,
"Sequence Flow," on page 100."

In table 9.29 (Complex Gateway attributes), delete the entries for Outgoing SequenceFlow and Assignments. Under the Gates attribute description, add a paragraph:
"For each Gate, the Outgoing Sequence Flow (See Table 9.xx on page xxx) SHALL have its Condition attribute set to None.
The attributes of a Sequence Flow can be found in Section 10.1.2,
"Sequence Flow," on page 100."

In table 9.30 (Parallel Gateway attributes), delete the entries for Outgoing SequenceFlow and Assignments. Under the Gates attribute description, add a paragraph:
"For each Gate, the Outgoing Sequence Flow (See Table 9.xx on page xxx) SHALL have its Condition attribute set to None.
The attributes of a Sequence Flow can be found in Section 10.1.2,
"Sequence Flow," on page 100."

see above

Message/Property/Assignment relations are too complex. It's not easy
to model values sent along the message flow. Probably Message loaded
with Assignments would help. Also. there is no easy way to model BPEL
construct where full message is assigned to variable. It looks like
there is duplication between Property set and Message. It's not clear
whether it's possible to use Property Set or Message definition as
Property type. Probably BPMN needs better type modeling.

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.

Message Flow ordering along Pool (abstract process) is modeled only
graphically. A specification of in/out indices to message flows is a
solution. Otherwise it's impossible to tell from the model order of
message receive/send for certain pool

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

The attribute definitions for Property are unclear/inconsistent. The attribute names are "Type" and "Correlation". But in the Description for Correlation, the text refers to "ConditionType" and "Condition Expression": "If the ConditionType attribute is set to Expression, then the ConditionExpression attribute must be defined." It is unclear what this is referring to.

No Data Available

The concept of "Trigger" in ambiguous in the BPMN specification. Take, for example, a Timer Start Event. This appears to me as a start event as type timer. But the specification also seems to refer to a trigger as a separate entity--an start event with a trigger somehow 'attached'. This is confusing and should be better explained in the document.

see above

BPEL faults are more complex than simple error name and handler
may be selected basing on fault name and type of the related data. BPMN
supports only error handler selection by name. A way of specifying the
faults at sufficient detail to enable generation of BPEL faults is
needed, by means of some text annotation property perhaps.

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

each action may contain join condition and have associated
'suppressJoinFailure' flag. BPMN spec doesn't include join condition at
all and puts suppressJoinFailure to the Process level only. Borland
created complex structures to reflect behavior of related BPEL elements
to enable generation.

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

A persistent format (XMI?) should be specified, to create possibility
of vendor-independent models

Close, No Change: This issue is out of scope for the RTF and will be addressed by other OMG
specifications, such as BPDM 1.0 and the response to the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

It would be nice to enhance BPMN to provide 'resource modeling'. For
example, a way to model working time available to the process, for
participant. Maybe a clear way to define resources used by activities,
number of available resource items, competition for resources.

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

partner links are not modeled in BPMN explicitly. so some of
related features are impossible to represent (e.g. dynamic partner
links)

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

BPEL model may use correlation set as a way to establish 'session'
BPMN does not have similar construct. One could model a reference to
correlation set in invoke as set of assignments. There should be a way
to mark such set of assignments with a boolean "initiate" flag

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

Borland found we had to add some BPEL/WSDL specific properties like
'target namespace' and 'wsdl path' to Participant for BPEL generation

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

Reference Task does not define any way to pass parameters and values

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

variables having 'message' type are imported as property sets,
reference to message type is lost

• it is hard to model variable as input and assign result of
  <invoke> to variable. If passing arguments can be modeled as sequence of
  assignments, receive part is impossible to model clearly--assignment is
  not symmetric, from is expected to be an expression and there is no way
  to define reference to service call result in expression as BPEL don't
  need it

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

The spec is unclear on when the events are enabled, ie, "listening" for
the event.

For example, suppose an independent process has a start event (either
message, timer, or rule), and this process is used by another (as a
subprocess, for example), as shown below.

P1:

A ---> P2 ----> B

P2:

Start
Event ---> Other activities
(Message,
Timer,
or Rule)

What will happen if A is executing in P1, and the start event for P2
occurs before A is finished?

If P2 is intended to be called only by other processes (it isn't "top
level"). Is there a way to prevent if from being triggered
independently of its callers?

see above

In many business processes, activities may be interrupted for business
reasons. A new Interrupt Event would facilitate modeling of these
processes. This type of Event would have try-catch semantics, similar to
the Error Intermediate Event, but without the error semantics. To support
this, we would need both an Interrupt Intermediate Event and an Interrupt
End Event.

Possible notation: a square, similar to the stop button on a tape player.

see above

What are the states that an activity can transition to? Are these the values of the Status attribute of an Activity? (None, Ready, Active, Cancelled, Aborting, Aborted, Completing, Completed) What, if anything, causes a transition of an Activity from None to Ready? Can you transition from Completed to None? to Ready? And so forth.

In what ways can these transitions occur? I think this is mainly a matter of what effects events have, but also involves the flows (and gateways, and tokens) [See the summary of start event types and their triggers (Table 9.5) and end events and process “endings” (Table 9.6) that has some info on effects on state, though some additional values appear to be mentioned.]

If there are other states (“armed” “ready”, “listening”, “waiting” “dormant”, “inactive” and so on) list them along with basic ones such as
“started” (“instantiated” “activated”) and completed. Are some states synonymous? Which ones? Is singly/multiply instantiated a state (so that an instantiated count could be tracked by numbers of copies active in the system?) How would the above states, if they exist, be related to the value in LoopType, StartQuantity, etc.

Bonus: Link the state machine transistions to the token flow behaviors and when and how Activities after a Merge GW change state. How is a Start or Intermediate Event state with a None trigger different from a transfer of flow control by means of a token? There are connections between state transitions and “flow” as stated, for example, in the ConditionType Attribute where token flow is said to occur when the (source) Activity State goes to Completed. Are there rules relating the generation or consumption of tokens to the state transitions?

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

What would be the semantics of having multiple None Start Events inside of
a sub-process? Should this be allowed.

If the start events are on the sub-process border, then the semantics are
clear. A sequence flow would target the start event and thus determine
which start event would be triggered.
But what happens when the start event is inside the sub-process? Will
multiple instances of the sub-process be created? This doesn't work given
that the sub-process instance is created when a token arrives via a
sequence flow. If one instance is created then we have a conflict with
the current spec semantics, in which each start event results in a new
instance. And would tokens flow out of one start event or both?

see above

It's common to have models with complex triggering conditions. For
example, start this process upon arrival of Message A and Message B or
arrival of Message A and Message C.

A new trigger type, "Complex", would facilitate creation of such models.
The trigger would be represented as an Expression in this case.

A possible graphical notation would be to apply the same icon that is used
in Complex Gateways.

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

In BPMN 1.0, you can create an Event with Multiple triggers. But these
triggers are treated as alternatives ... i.e., they have 'or' semantics.
It is very common to require multiple triggers with 'and' semantics. That
is, all of the triggers must be satisfied before the process will start.

A possible graphical notation is to to use the '+' symbol inside of the
event circle. This would then be consistent with the notation used to
designate 'and' semantics in gateways.

Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

Some attribute descriptions and definitions require corrections:
"Lanes" (Section B.4): Description mentions the "Id" of the lane,
but it's the lane itself that is referenced by this attribute.
"Inputs", "Outputs" (Section B.6.1): Description refers to
"Document Object". Should be "Data Object".
"OutgoingSequenceFlow" (Section B.7.2):

• Should state that the sequence flow must be outgoing from this
  gateway. It's not actually stated, although the reader would
  probably assume that's the case.
• Contradictory statements in the description. One sentence
  states that the Sequence Flow Condition must be Expression. And
  another sentence states that in certain cases the Sequence Flow
  Condition must be None.
  "DefaultGate" (Section B.7.2): The attributes under DefaultGate are
  not needed. The DefaultGate would reference an existing Gate, and
  thus there is no need to redefine the attributes of this Gate.

see above

We may need a way to model more general logic patterns for incoming events. For example, in response to an RFQ, a supplier may send either a decline, or a quote and (as a separate message) terms & conditions. The logic pattern for this use case is

Decline XOR ( Quote AND Terms )

If the Decline is accompanied by a memo giving reasons, then the logic becomes

( Decline AND Memo ) XOR ( Quote AND Terms )

We want to open up three event receivers initially (four in the second case). Then, as a Quote arrives for example, we want to close the receives for Decline and Memo — since we don't expect those any longer — but keep the receive for Terms & Conditions open. When those have arrived as well, the inclusive event-based gateway is complete.

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

Is there a plan for extending activities with execution time (traversal time) attribute???
I mean is to put time on the activities which show how long they will take to finish. Maybe two attributes for the best and worst case (minimum and maximum traversal time).
I can imagine a system, which allows displaying accumulated time for every sub process and task, for every separate flow path with minimum and maximum traversal time.
It is more or less easy to find out estimated time for primitive tasks but it is really hard work to calculate possible execution time for whole process for synchronization purposes.
So when you simulate the whole process at the end you will see how long the process will take in best and worst case.
It is an excellent feature for process estimation. I realize the problems of implementing of such functionality because of merging of sequence flows but anyway it could be great feature.
Unfortunately process execution time (traversal time) is still not supported by BPMN specification but you don’t need to be an oracle to predict that the idea will come through in the closest future.

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

In the following process, assume mulitple tokens are being fed to A
from upstream (<X> = exclusive OR split, <+> = AND Join):

----> A – <X> <+> --> B

I assume two executions of A are required for each execution of B (if
not, correct the parts of the spec that imply this).

Where are tokens queued up that don't have a matching one to get
through the AND join? BPMN should indicate where the queuing happens,
because it affects execution. If queuing is at the the exclusive-OR
split, then conditions could change over time and the guard could
direct the token to a different path after the token as been queued a
while. Or token could queue at the join, and only be tested by the
guards once.

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred

Clarify whether pools require their activites to be centrally coordinated. In particular, above Table 85, the specification says: "Note that Message Flow cannot connect to objects that are within the same Participant Lane boundary." (I think this should say "pool", rather than "lane".) Does this mean the entities represented by lanes must not coordinate their activities directly through messages to each other (ie, the coordination must be centralized)?

see above

Do artifact flows affect execution? Table 8.2 (BPD Core Element) says: Data Objects are considered Artifacts because they do not have any direct effect on the Sequence Flow or Message Flow of the Process, but they do provide information about what activities require to be performed and/or what they produce. Not sure, but the above seems to imply that artifact flows do not affect execution (it does not affect sequencing or messaging). Compare Table 9.10 (Common Activity Attributes): [Input: for InputSets only] Inputs (1-n) : Artifact One or more Inputs MUST be defined for each InputSet. An Input is an Artifact, usually a Document Object. InputSets (0-n) : Input The InputSets attribute defines the data requirements for input to the activity. Zero or more InputSets MAY be defined. uEach InputSet is sufficient to allow the activity to be performed (if it has first been instantiated by the appropriate signal arriving from an incoming Sequence Flow). which seems to imply an execution semantics ("Each InputSet is sufficient to allow the activity to be performed").