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").

Close, No Change: The answer to the question is that Data Objects can affect the performance of
individual activities. However, they do not affect the operational semantics of a BPMN diagram—in terms of when and which activities will be performed. This is determined by the Sequence Flow and
Gateways

Add an attribute to a Process that allows the modeler to define which Pool in a BPD is the "main" Pool. This Pool would be the focus of the diagram and the implementation of the Process in the Pool.

see above

Is it valid to have a pool nested within a Lane,

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 expressions are defined as:

"An Expression MUST be entered to provide a mathematical expression to be either tested as True or False or to be evaluated to update the value of Properties (e.g., assignment)."

whereas the diagram has an ExpressionLanguage attribute which is defined as:

"A Language MAY be provided so that the syntax of expressions used in the Diagram can be understood. "

Expressions are used either in the boolean sense (e.g. as Conditions for Conditional flow) or in the imperative sense where expressions are evaulated to update values (e.g. as used in the element Assignment). Hence this can be conflicting with the default settings by the diagram, and is in conflict with the notion of BPMN as a human readable language it is suggested that each expression may contain an expressionlanguage field of type String. While BPMN will still mandate that certain expressions must deliver specific results, it will not standardize the expressionlanguages capable of achieving this goal.

see above

The UML class diagram in the appendix as revised after Ballot 4, is an object model, and it should not be an object model .

More particularly, the new diagram in Appendix B looks like a metamodel for BPMN Element, In particular, it seems to show abstract classes (using italics for names),
shows visibility public '+' for attributes, shows generalization relationships,
and uses the notation for representing classes (or metaclasses), and attributes.

This is misleading at best. It is understood within the FTF that the intent was to show the tables in a concise form,
by using generalization to represent relationships among the tables in the appendix, but the diagram as it stands does not do that, since it includes concepts that are not appropriate to that purpose.isual representation of the tables and the rows of the tables.

see above

These issues refer to the examples in section 10.2.1 Normal Flow in the BPMN Adopted Specification as of february 2006; pages 125-128.

The problem with the use of Link events for synchronizing behaviour is that there also is a need to explicitly state that two link events are the same object. This can be indicated through the use of (directed or undirected) associations, but that still is an indication only; not formalized. Next, use of such "equality associations" has problems with cases where the "same event" occurs both as an end event and a start event, as seen in figure 10.49. Here, the two "B Completed" link events are probably not exactly the same object (with the same id) since they are of different (sub)types.

Such use of link events, which I do indeed consider very useful, should be improved in upcoming versions of BPMN.
The situation in figure 10.49 is quite similar to "message exchange" - but within a pool. Just as there has been identified a need for distinguishing between sending and receving intermediate message events, there is a similar need to distinguish between "generating" and "reacting" intermediate link events. Generating intermediate link events could have the existing symbol; one can pragmatically think of them as "Go-to's". Reacting intermediate link events could have a new symbol with the internal fat arrow pointing right to left; these can be thought of as "Comes-from's". In the example then the topmost "B Completed" event could be changed into an generating intermediate link event. The bottom fragment could be changed into a normal start event, followed by a reacting intermediate "B Completed" link event followed by task D.

No Data Available

All the next five numbered points are BPMN Specification descriptions for Cancel Intermediate Event possible uses. TO SUMMARIZE EXECUTIVELY , text in the table 46 states that Cancel Intermediate MUST NOT be used when the Event is attached to the boundary of a Transaction WHILE text on pages 45, 47 and 60 and figure on page 60 indicate that Cancel Intermediate Event can be ONLY USED attached to the boundary of Sub-Process. I BELIEVE this is CRITICAL issue, because it establishes the completely opposite views and can possibly lead for example to rejection of valid BPMN diagram. 1) Text in chapter 9.3.4 Intermediate [Events] in table 9.9 on page 46 in the first row "Trigger" [attribute] in column Description states that "The Cancel Trigger MUST NOT be used when the Event is attached to the boundary of a Transaction or if the Event is not contained within a Process that is a Transaction." THE CORRECT SENTENCE should be "The Cancel Trigger MAY only be used when Event is attached to the boundary of a Sub-Process that is a Transaction." Read on... 2) At the same time, in chapter 9.4.3 Intermediate [Events] in Table 9.8 on page 45 is stated for Cancel Intermediate Event that "This type of Intermediate Event is used within a Transaction Sub-Process. This type of Event MUST be attached to the boundary of a Sub-Process. It SHALL be triggered if a Cancel End Event is reached within the Transaction Sub-Process. It also SHALL be triggered if a Transaction Protocol “Cancel” message has been received while the Transaction is being performed." 3) Text in the same chapter right below the table 9.9 in section "Activity Boundary Connections" on page 47 says, that "An Intermediate Event with a Cancel Trigger MAY be attached to a Sub-Process boundary only if the Transaction attribute of the Sub-Process is set to TRUE." 4) Except that, also in chapter 9.4.2 Sub-process in section "Sub-Process Behavior as a Transaction" on page 60 the indicates that "A Cancel Intermediate Event, attached to the boundary of the activity, will direct the flow after the Transaction has been rolled back and all compensation has been completed. The Cancel Intermediate Event can only be used when attached to the boundary of a Transaction activity. It cannot be used in any Normal Flow and cannot be attached to a non-Transaction activity." 5) Also the figure 9.11 on page 60 shows Cancel Intermediate Event attached to the boundary of Transaction Sub-Process.

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

. If a task has the TaskType value set to “None”, the task is not allowed to have incoming or outgoing message flows. This restriction should be removed. “None” would logically be interpreted as “not defined”, so the message flow restriction would be overly constraining—one might be early in an analysis and the type of task not yet defined, though a message flow in/out specified. (Note that the ProcessType attribute on Process also has the legal value “None”, and in that case the definition parenthetically states that “None” means “not defined”. Further, no restriction is placed on message flow.)

2. The message flow connect rules in Table 8.5 do not reflect the TaskType value message flow restrictions otherwise defined in Table B.64. An annotation (footnote) should be made to the table to note the restrictions.

see above

Project management models define the start/finish relationships between activities. This is handled in four ways: Finish-Finish; Finish-Start; Start-Finish; and Start-Start. Current BPMN Flow handles two of the four. A sequential flow of activities is a Finish-Start; a parallel set of activities is a Start-Start. But the other two combinations are not definable. The solution may not require graphical canges to BPMN, but there should be some behavioral support for these situations.

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

These issues refer to the examples in section 10.2.1 Normal Flow in the BPMN Adopted Specification as of february 2006; pages 125-128.

A problem with the use of Link events for synchronizing behaviour is that there also is a need to explicitly state that two link events are the same object. This can be indicated through the use of (directed or undirected) associations, but that still is an indication only; not formalized. Next, use of such "equality associations" has problems with cases where the "same event" occurs both as an end event and a start event, as seen in figure 10.49. Here, the two "B Completed" link events are probably not exactly the same object (with the same id) since they are of different (sub)types.
Such use of link events, which I do indeed consider very useful, should be improved in upcoming versions of BPMN.

Two possible solutions for this could be:

1) Introduce a way of specifying that two flow objects within/across diagrams are "equal"; possibly also allowing equality across start and end events. Could be a particular kind of associons with strong semantics.

2) The situation in figure 10.49 is quite similar to "message exchange" - but within a pool. Just as there has been identified a need for distinguishing between sending and receving intermediate message events, there is a similar need to distinguish between "generating" and "reacting" intermediate link events. Generating intermediate link events could have the existing symbol; one can pragmatically think of them as "Go-to's". Reacting intermediate link events could have a new symbol with the internal fat arrow pointing right to left; these can be thought of as "Comes-from's". In the example then the topmost "B Completed" event could be changed into an generating intermediate link event. The bottom fragment could be changed into a normal start event, followed by a reacting intermediate "B Completed" link event followed by task D. There also must be some way of "pairing" the related generating and reacting events; this could be done by adding an attribute to the receiving event which holds the id of the matching generating event.

No Data Available

Issue 9321 was resolved as being addressed by Issue 9319. However, the resolution of Issue 9319 did not adequate address the question raised by Issue 9321. Thus, this question still needs to be addressed. The Issue is:
The start of section 8 has the following which suggests 2 levels of compliance; however this opportunity has been missed in the conformance section: "First, there is the list of core elements that will support the requirement of a simple notation. These are the elements that define the basic look-and-feel of BPMN. Most business processes will be modeled adequately with these elements. Second, there is the entire list of elements, including the core elements, which will help support requirement of a powerful notation to handle more advanced modeling situations."

see above

Right now flow conditionality is maintained in the Sequence Flow. This should be moved to the Gates and then the Sequence Flow become purely a mechanism to advance the flow (Token).

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 problem with the use of Link events for synchronizing behaviour is that there also is a need to explicitly state that two link events are the same object. This can be indicated through the use of (directed or undirected) associations, but that still is an indication only; not formalized. Next, use of such "equality associations" has problems with cases where the "same event" occurs both as an end event and a start event, as seen in figure 10.49. Here, the two "B Completed" link events are probably not exactly the same object (with the same id) since they are of different (sub)types.

Such use of link events, which I do indeed consider very useful, should be improved in upcoming versions of BPMN.
Two possible solutions for this could be:
1) Introduce a way of specifying that two flow objects within/across diagrams are "equal"; possibly also allowing equality across start and end events. Could be a particular kind of associons with strong semantics.

see above

There is a confusion regarding diagram 10.25. The word Condition means that the condition has to be met before the Activity/Process is initiated. However, the word ‘Default Condition’ conveys a wrong meaning. It is the word ‘Condition’ in the ‘Default Condition’ that is causing the confusion. Instead of saying ‘Default Condition’ can rather call it ‘Default’ or ‘Mandatory’. OR, if it mandatory then it should not branch out of a decision box and rather branch out of the Original Process.

The following minor text modifications will be made to the BPMN 1.1 Specification

Section - Forking Flow, page 111 - there is a typo: "Even when not required as a “best practice,” there are situations were the Parallel Gateway provides a useful indicator of the behavior of the Process." ... The sentence should state: "... are situations WHERE [capitalization added] the ..."

The following minor text modification will be made to the BPMN 1.1 Specification

Exception Events (i.e., attached to an activity) are required to have an outgoing Sequence Flow. However, if the model being created is simple and does not use Start and End Events (see figure below), and the exception is extended to end the process, should we allow the modeler to forgo the use of Start and End Events (which would be currently required)?

see above

Currently there is no description of the fundamental semantic model of token flows in the spec. Clearly it is based on a variety of petri net; however a description of the particular semantics assumed in BPMN could be very useful in reading the spec. Such a description should be formal in the sense that it should be mathematically clear what the procedural semantics of BPMN is

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

Comment to BPMN FTF:

• Currently there is no standard way to differentiate a business
  message from a business signal, which have fundamental different
  characteristics.

========
During the ebBP-BPMN discussions last week, I was asked to summarize what business signals are and how they function. There has been some initial discussion on the bpmn@omg.org list re: signals in general. I'd like to make a necessary distinction about the similarities and differences.

• What is a business signal? [1]
  o "Business signals have a specific business purpose and are
  separate from lower protocol and transport signals. One or
  more Business Signals can be exchanged as part of a Business
  Transaction to ensure state alignment between both parties.
  Evaluation of business signals enable the state of a
  Business Collaboration to be explicitly calculated at run
  time. The ebBP technical specification provides both the
  structure and choreography of Business Signals, including
  allowing for user defined signals....

A Business Signal is computable. This provides the
collaborating parties with a mutual understanding of the
business activity. This function allows the parties to know
if their expectations in a Business Transaction are
realized. This is state alignment, and is important in order
for the ebBP specification to have commercial viability. The
ebBP specification provides the ability to conduct intended
transactions if that is the intent of the collaborating
parties."

• Where does the business signal fit in eBusiness and business
  messaging? [2]
  o State alignment: (almost quoting from our specification for
  specifics) The process of exchanging signals and state
  changes of a Business Transaction enables state alignment
  between the parties involved. If the standard signals are
  used, the structures of ebXML Business Signals are
  ‘universal’ and do not vary from transaction to transaction.
  Business signal schema can be found at:
  http://www.oasis-open.org/committees/document.php?document_id=16460&wg_abbrev=ebxml-bp
  (detailed schema documentation also exists on this public
  page). The ebBP technical specification provides both the
  structure and choreography of Business Signals. The ebXML
  Message Service Specification (and other evolving
  technologies) provides a reliable messaging infrastructure.
  This is the basis upon which the ebBP technical
  specification builds its protocol for business state
  alignment using Business Signals. The Business Signal
  payload structures are optional and normative and are
  intended to provide business semantics to the Business Signals.
  o Part of process definition: Defined in the BT pattern and
  bounded by partner expectations. Map back to business
  transaction activity. Map back to service and action context
  for agreement (such as CPP/A).
  o Transition and determination of several types of successes
  and failures: Condition guards exist on transition in
  process steps and activities. Business signals are integral
  here. In ebBP and in business collaboration, there is
  protocol and business success whereby one supports the
  other. Reference:
  http://www.oasis-open.org/committees/document.php?document_id=16457&wg_abbrev=ebxml-bp
  (See Section 3.6.3)
• What happens if you don't model these signals?
  o In configuration: Business and messaging signals are
  explicitly modeled in configuration.
  o In understanding the partner agreement: The partners may
  mutually expect these be used and therefore set criteria
  associated with the progress and outcomes of the business
  process (and its activities).
  o In managing state transitions: See previous comment.
  o In seeking to generate computable artifacts: Without the
  definition of such signals, the artifacts either have to be
  defined out of band or in a potentially proprietary way. We
  allow user-defined signals, although they are still related,
  included and part of the business process.
• Links to the business process [3]
  o Standard signals: Defined structure and semantics related to
  the pattern, activity and transitions
  o User defined signals: Allowed pointers to user-defined structure
  o BT patterns
  + Template: See patterns matrices in the specification
  (sections 3.4.9 and 3.4.9.1) that specify how these
  signals infer content validation, succesful syntactic
  validation and also allow the business process to
  proceed (or not).
  + Profile: Partners identify their expectations using
  the patterns and the selectable criteria to support
  not only the business messages received but the
  business signals that support them.
  o Relevance to model
  + Business Transactions and the Business Service View
  [4. See Chapter 9].
  + Business significance

1. Involves timing parameters, implication to
   business partner expectations, etc. Several
   important criteria are defined around the use of
   the business signals. [4. See Chapter 8. State
   notations and their relevance to partner
   expectations are found in Chapter 9.]

You can see how signals are used in the process definitions found on our public web site at: (ePV, Netherlands example) http://www.oasis-open.org/committees/document.php?document_id=16436&wg_abbrev=ebxml-bp

Facts

• Properties such as line width or color could be used but can't be
  seen if printed on black and white.
• Properties such as message and (add) signal could be used. The
  latter would have to be added. There would also possibly need to
  be a way to differentiate whether or not business signals were
  used as the implementation and runtime results may differ given
  that assumption (different semantics).
• In order to maintain the focus of generation of software
  artifacts, business signals should be considered for modeling in a
  standard way (preferred to a tool specific option).

Additional note: We have seen tools that actually use the properties of messages to delineate a signal (such as a stereotype).

• Business signals differ from underlying messaging infrastructure
  acknowledgements. Several communities including UK Bristol
  government and ePV have indicated the value of the use of business
  signals. Supports monitoring framework as well.

Business example
Two partners agree to engage in a Commercial Transaction pattern and use the BT from the pattern. A BTA is developed in a Business Collaboration to support these expectations. The partners will use reliable messaging and they use the business signals. An intelligibility (syntactic) check is made on the business message before the Receipt Acknowledgement business signal is sent, and successful business processing is required on the business document before an Acceptance Acknowledgement business signal is generated. Both carry timing expectations with them (in support of the BTA). For example, an Order Management system would validate a business document meets the partner expectations before initiating a sales order and sending a Response from a Purchase Order Request. Prior to the Response being sent these signals are used. They also allow the partners to optimize where required. The Buyer (Requesting Role) can understand that the Request was received and then whether or not it was successfully business processed (i.e. alleviating the potential need to query another Seller). Let's assume the Purchase Order doesn't muster in validation processing, then a Negative Acceptance Acknowledgement is sent. The Buyer (Requesting Role) may have an early indication and then can send a Cancel Transaction. Both parties are able to react more quickly to current conditions. In addition the business signals give clear indication of state alignment (the parties have a shared understanding of their condition and state of the business expectations).

Example business signals found at: http://www.oasis-open.org/committees/download.php/16652/ebxmlbp-v2.0.2-cd-ExampleSignals.txt

[1] From our FAQ found at: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/16540/ebBPv2.FAQ.html
[2] Not transport level or HTTP acknowledgements.
[3] Business signals defined in Section 3.4.9.3 at: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/ (in technical specification)
[4] This reference was provided on the public bpmn@omg list late last week - N090 UNCEFACT Modeling Methodolgy R10 [1]. The business signals occur in the Business Service View (which is different than a transport level component), see: http://www.ifs.univie.ac.at/untmg/ (UMM_N090R10_2001-11_01.zip) - See chapters 8-9.

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

This was submitted to BPMN members in addition to the OASIS ebBP list 13-14 February 2006. This is sent in an abbreviated fashion to FTF for comment inclusion.

Diagram examples: http://www.oasis-open.org/committees/download.php/16684/ebxmlbp-v2.0.2-Document-pr-BPMN-r02-en.zip

As a subsequent followup between BPMN and ebBP (discussions 7 and 9 February 2006), our team has begun to delve deeper into using (future) joint activity, associate the operation activities to business transaction activities, show the use of business signals and business signal exceptions (such as Negative Receipt Acknowledgement) and understand what questions remain.

Initial thoughts of potential needs (current or future) for BPMN that may be relevant for shared collaboration [1]:

1. Visibility of the BT pattern and its constraints and guidelines
2. Business QoS aspects (guidance that may translate to technical
mechanisms in the messaging infrastructure)
3. More detailed modeling of the business document (this may be part
of properties). This may be too granular for BPMN however.
4. Need for end timers

• Timers are not just for exceptions but may be for receipt of
  a business signal (Receipt or Acceptance Ack), and for the
  overall collaboration, activity, etc.
  5. Need to be able to model simply multiple internal processes to
  support different operations, or the same operation using
  different mechanisms.
  6. How to effectively show how a business partner may assume many
  roles in a pool.
• For example, a Supplier (exposed in Business Collaboration)
  may assume the roles of Buyer, Distributor or Seller. These
  roles may be specific to the activities within a joint
  activity or be associated with the activities defined
  elsewhere but visible in a Complex Business Transaction
  Activity. Visibility and participation in this activity are different but may be associated.
  7. Last year we spoke to some of your team members about the use of inclusive OR gateway, and intermediate or end
  messages for representing that a response could be several different types of responses (cancel, change, accept for
  example). The current BPMN semantics preclude use of message flows into / out of a gateway. In addition, we couldn't
  determine how to indicate that multiple types of business messages (specifically) may occur. We originally used
  exclusive rather than an inclusive OR gateway notation object (per BPMN suggestion in September). With inclusive
  OR, parallelism could result. For example, in a decision, it is modeled that one path is taken. In order to represent the sequence flow into a gateway, and several possible paths out (termed end messages in BPMN), I opted
  to use the inclusive OR gateway as suggested. In ebBP, forks can be non-deterministic intentionally. Forks can
  resemble a non-deterministic OR or parallel ANDs or exclusive OR (like a Decision). This question arose outside of
  the option to use a future joint activity.

What gateway control type is appropriate when you actually could
have n potential paths on a fork or join,
and either only one is actually performed or many could be
performed, and business messages are sent? This is actually a conceptual difference in current BPMN v1.0 and
collaboration whereby not all paths may be rendered executable or be used in execution (monitorable in ebBP context).

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

Issue summary: Need consistent terminology for Categories, Core Elements
aka Graphical Objects

Details:
Note: This issue is related to the one above ???3 under the summary:
Which is it, Core Elements, or Flow Objects?.

The text presentation on page 15 of 06-01-01 (section 8.1) introduces
four "basic categories" of Core Modeling Elements.
compare that with Section 9.1, the text preceding Table 9.1, which reads
in part
>>>> "BPMN graphical objects (Flow Objects, Swimlanes, Artifacts and
Connecting Objects)"
These same four were earlier said to be the basic Categories aka the
Core Modeling Elements. Now they are said to be the four "graphical
objects".
It seems likely that authors of different parts of the text were agreed
that this list of four was speciallly important, but that they did not
use the same terminology for them. They should consistently be termed
"categories", "core elements" or "the BPMN Graphical Objects", but not a
mix of all 3 terminologies.

Since these four categories turn up in so many contexts, they invite
close study, and their seemng importance – at least in the view of the
authors of the spec – suggests that the metamodel of the BPMN domain
should recognize them as important metaclasses. If this implication is
not intended, then the text should get rid of these "categories".

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

Some references are not explicit. Borland, for example, added
reference between matching link events into our metamodel. Apparently,
there may be a reference between error events (one causing error and
another one providing connection to error handler) and possibly for
compensation event

see above

• Containment structure is unclear for non-graphical elements like
  WebService, Message, Rule etc. Borland made deliberate decisions to put
  some of them into Diagram, some to Participant.

No Data Available

Note: This issue is vaguely related to 9321
See section 8.1 "BPD Core Element Set" starting on page 15 of 06-01-01
The text presentation is organized according to four "basic categories" and gives the impresion that some semantic or syntactic commonality underlies each of the four categories. The category Flow Objects are listed on page 15 as bullet items.
.
but the table 8.1 repeats the same list, but now calling them "Core Modelng Elements", and the category "Flow Objects" has been forgotten. This is confusing.
It is additionally confusing to have separate lists of "Core Modeling Elements", "Core

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

BPEL mapping section suggests mapping of flow graph to structural BPEL
construct which calls for the complex flow analysis (e.g. to define
bounds of the switch construct). With this complexity, BPEL mapping
definition is imprecise. Some constructs, like exception handling, don't
map to BPEL constructs suggested by the spec due to the difference in
behavior. I would suggest to redefine mapping using approach described
in article "An Example of Using BPMN to Model a BPEL Process"
http://www.bpmn.org/Documents/Mapping%20BPMN%20to%20BPEL%20Example.pdf

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

Reading over the BPMN spec, my main question is how to model a process where more than one participant (pool) plays a part in it. We have many Visio diagrams where a process is drawn across several swimlanes to denote that several people/groups take part in one process. This seems to be very intuitive for people. Is there any way to model a process across pools, or does BPMN require the modeling of multiple processes (with similar names)? names?

see above

We should clarify the nature of BPMN. If BPMN is just a notation, then Section 2 (BPMN Overview) should be specifically state this and also contrast a notation from other types of process specifications. If BPMN is not just a notation, then this should likewise be stated and its scope and purpose should be made clear.

see above

The usage and scope for non-transactional compensation events, both throwing and catching, is not clear in the spec.

see above

The maker for Multiple Instances (two vertical parallel lines) is a bit confusing. It looks like a "pause" symbol on a tape player. This should be changed. The new marker should indicate multiple instances in both the parallel and serial forms of the activity.

see above

BPMN uses a six-pointed star for events with multiple triggers and for
event-based gateways. This symbol has cultural and religious significance,
and apparently its use will block adoption in certain regions and
countries.

Recommend replacing it with a 5-pointed star.

see above pages 53 through 55 for figures (dtc/2007-06-01)

There is currently no way to graphically differentiate an Embedded Subprocess vs. an Independent Subprocesses. Suggested resolution is to use the "go to" arrow instead of a "+" (plus sign) for the Independent Subproces, similar to the off-page connector. This would indicate that the Independent Subprocess "goes to" another diagram.

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 BPMN specification is not clear on the separation of data and display regarding pools and lanes. In some cases, pools and lanes seem to only be visual containers that are portrayed on diagrams. In other cases (e.g. in property definitions), pools and lanes seem to a part of the actual BPMN data/metadata.

Consider the following use case:

I create a new business process diagram
Within this diagram, I create a pool with two lanes
Within the lanes, I create a sequence of flow objects which collectively create a BP Process (that could be executed).

In the case above, the diagram will reference the pool. The pool will both define the process and reference the lanes within the pool.

The following questions emerge:

1. Can the BP process itself be referenced (i.e. displayed) in more than one business process diagram, either as a new unique pool or an independent sub-process inside another process? Or does a BP process have only one diagram (or set of diagrams if using off-page connectors) associated with it.

2. Consider the case of storing BPMN metadata without diagram representation. In data, is a pool and/or lane considered to be the owner to the BP process inside the pool / lane, or is just a visual attribute of the process? It seems if you have a BP Process (that contains flow objects), you would be able to portray this same process in two BPMD diagrams 1) a pool/lane showing the flow objects in the process 2) an independent sub-process showing flow objects in the process.

3. Is there ever a case where BP process is considered to be the owner of the pool? That is, a process contains more than one pool. From the spec, it appears that a pool can define only one process, and a process cannot own one or more pools.

see above

On page 23 of the BPMN specification, it is stated that Tasks of type Receive can be used after the XOR Event Based Decision. So, such a Receive Task will have an incoming Sequence Flow from an XOR Event Based Decision. But, on page 64 it is stated that no other incoming Sequence Flow (other than from a Start Event)are allowed for the Receive Task." I find these 2 statements contradicting each other. Can you please advise.

No Data Available

Specification: BPMN Final Adopted Specification: dtc/06-02-01
Contact: Stephen White, IBM
Problem: References to Annex D and there is no Annex D in this specification

Exact places to remove Annex D reference:
Section 9.3.2 Start, page 37 (first paragraph on the page)
Page 61 (first Note on the page)
Table 11-5 "End Event Mapping to BPEL4WS" page 141, Cancel (End Event column)
Table 11-11 "Cancel Intermediate Mapping to BPEL4WS" page 145, Trigger = Cancel (Intermediate Event column)
Table 11-26 "Sub-Process Mappings to BPEL4WS" page 167, IsATransaction (Sub-Process column)
Table 11-43 "Exception Flow Mappings to BPEL4WS" page 180, Quantity 1: Integer (Sequence Flow column)

see above

The direction arrow for association seems backwards. For a “To” association, I would expect the arrowhead to be at the target object. This is how most modeling tools work.

A à B would indicate the “flow” goes from A TO B, and would be considered a “To” association. Currently, the BPMN would show this as A ß B (arrowhead at the source), which is not intuitive

see above

After reading the following on BPMN - BPMN OMG Final Adopted Specification of March 6 2006, - Introduction to BPMN by Stephen A.WHite, IBM Corporation. In the latter paper are the following statements: "Pools are used to represent Participants in the process" "Message flow is defined as the mechansism to show the communication between two participants" "Lanes are often used to separate the activities associated with a company function or role" With the above three statements, I am having difficulty understanding the rationale for the below statement about BPMN "Sequence Flow may cross the boundaries of Lanes within a Pool, but Message Flow may not be used between FLow objects in Lanes of the same Pool". To model the process of how a Customer project is executed by a company, I want to model Organisation Units (e.g. Sales, Development) as Pools and roles inside those Units as Lanes (e.g. Project Manager, Team Leader, Architect, Developer etc), Message Flows can be used to represent the interactions between Sales and Development Units. But I am not allowed to use Message Flows to represent the interactions between an Architect and the Developer. WHy? Am I using the pools and lanes in a manner that is against the philosophy of BPMN? I tried to get an answer from BPMN OMG Final Adopted Specification of March 6 2006, but the rationale was not very clear. Please could I have a clarification for the rationale between not allowing message flows between lanes in the same 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

Summary: Specify the return type of ComplexMI_FlowCondition defined in Multi-Instance Loop attributes table

The specification does not specify the expected return type of ComplexMI_FlowCondition expression attribute.

see above

Add a UML Profile to the BPMN specification

see above

“The Reference Task and Reference Subprocess should be removed. With the resolution of issue 9559, containment issues no longer restrict the vendor from making any BPMN object reusable/referenced.”

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 last sentance in the "Activity" "Description" paragraph in Table 8.1 should read "Processes are either unbounded or ARE [capitalization added] contained ... ." The sentance currently, and incorrectly, reads "Processes are either unbounded or A contained ... ."

see above

The second sentance under "Note" in section 7.1.1 should start with the word "See." The word is missing.

see above

The definition of "Rule", as given in section B.11.9, is ambiguous. More
clarification is needed in the spec.

see above

Issue: Link does not have clear semantics. Not clear if it is graphical only (for connecting off page or cross page lines, or has execution semantics. Also, it is not clear what types of elements can be linked. Need to clarify semantics for BPDM. Proposed solution (FTF discussion) Link is a graphical convenience for connecting two points on a graphical representation of a process. The points must be within a single pool and the name/identifier must be unique within the pool. It is only valid where a line without the link(s) would be valid.

see above

Page 64 (Adobe 88) of the BPMN Spec (06-02-01) the first row of table 9.17 reads:

"TaskType (Service | Receive | Send | User | Script | Manual | Reference | None) None : String"

This would mean the default type for the TaskType attribute would be "None". However, the description says « TaskType is an attribute that has a default of Service », which makes more sense to me.

see above

Page 103 states that
If the Message Flow is connected to the boundary of the Expanded
Sub-Process, then this is equivalent to connecting to the Start Event
for incoming Message Flow or the End Event for outgoing Message Flow
(see Figure 10.7).

Does this make sense, considering that the Sub-Process may contain
Send/Receive Tasks and Message Intermediate Events? If we remove this
sentence, then we should also remove Figure 10.7.

see above

The DataObject contains two attributes "RequiredToStart" and
"ProducedAtCompletion". These probably should be on the Activity rather
than the DataObject, since a single DataObject can be associated with
multiple Activities. Also, we may want to relate them in some way to the
Activity Input/Output Sets.

see above

Page 48 states that an Intermediate Event cannot have outgoing Message
Flow. This restriction should be removed.

see above

Page 92 states that a Task may have zero or more outgoing Message Flows.
But the tasks that support outgoing message flows (e.g. SendTask,
ServiceTask, etc) can have at most one outgoing Message. This implies that
all Message Flows leaving a single Task must all be associated with the
same Message. This should be clarified in the spec.

see above

Currently, there is a Quantity attribute on Sequence Flows. Does it belong
there or should it instead be on the Activity?

see above

The "StartQuantity" attribute, as it's currently defined on page 50, needs
revisiting. What happens if an Activity has multiple incoming sequence
flows? Should the StartQuantity instead consist of a list of numbers, each
of which is correlated in some way with a particular sequence flow?

see above

The term "Independent Subprocess" doesn't fully convey the intent of this
construct. Suggest it be renamed to "Reusable Subprocess".

see above

The IORules attribute on Activity is of type Expression. Shouldn't it be a
Rule?

see above

A Start or End Event should only be optional if it has no Trigger or
Result

see above

Page 47 refers to an "Exception" trigger. Should be renamed to "Error".

see above

Most elements have a section called 'attributes' - but nowhere is it explained how these are related to the Notation being specified. Is it expected that each shape will have a 'property sheet' allowing these attributes to be viewed and edited? The end of Section 7.1.1 states "Thus, the graphic elements of BPMN will be supported by attributes that will supply the additional information required". In many cases though the attributes described include information that is redundant with the diagrammatic representation e.g. Name (in several places including 9.6.1) and ParentPool and ParentLane for Lane in section 9.6.3. In general Appendix B has more of the flavor of a metamodel or an interchange definition than a Notation.

Suggested Resolution:
Close, No Change: A requirement of the BPMN 2.0 RFP is to include both notation and a
metamodel in the specification. Thus, the issue will be resolved with the specification that results
from the RFP.
Revised Text: None

I do not see what exactly is the semantical difference between activity
models and BPMN, besides its syntactic constituents. Secondly, BPMN does
not address the objects or nouns which activitiy diagrams do. Process
with objects provide complete meaning, process without objects is
typeless and thus meaningless.

The [previous] FTF disagreed with the statement that a process without objects is meaningless.
The modeling audience that desire/require object-orientation is not the same audience that is the
target of BPMN. Perhaps Activity Diagrams fit the former audience better, and Activity Diagrams
are always an option. However, the FTF recognizes that although the audiences may differ greatly,
the modeling scope of Activity Diagrams and BPMN greatly overlap. At some point, the OMG will
have to deal with this.
This is not an issue that can addressed by the BPMN RTF in terms of the BPMN specification version
1.2.
Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF, but should be addressed by the OMG
community as a whole.

Can anyone provide an example of how the following items should be formatted visually? I don’t see examples in the BPMN spec: 1. Vertical Pools 2. Nested Lanes

No Data Available

6.1.1 should show the complete syntax for an attribute e.g. as BNF.

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

It seems a bit odd that a Sequence Flow is not a Flow Object as its name would appear otherwise: actually the term Flow Object is probably the one that misleads

Close, No Change: Sequence Flow is listed as a Connecting Object, which should be considered a
logical categorization. Given that, the use of Flow Objects for those that are connected by
Sequence Flow also appears logical. However, a surface view of the terms might be somewhat
confusing. However, there would be a large impact on the specification and general understanding
of the practitioners of BPMN if the terminology was changed. Thus, this issue is out of scope for the
RTF and may be addressed by the response to the BPMN 2.0 RFP.