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

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

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

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

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

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

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

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

Reference Subprocess defines Input/OutputPropertyMaps attributes to
define actual parameters, while there is no clean way to define formal
parameters of the process.

No Data Available

Time intervals modeling is imprecise. Specification lists related
field as TimeDate:Date and TimeCycle:String. In fact, modelers typically
need to specify time interval since some event (e.g. starting the
enclosing process). Enumerated cycle values (daily/weekly/monthly) or
cycle interval and number of cycles would also be handy. Consider the
way Outlook calendars handles regular meeting appointments. It would be
nice to model advance reminder as separate entity (timer event occurring
before another scheduled event).

No Data Available

The attribute "SubProcessRef" is of type Task (see page 82). Shouldn't it
be of type "SubProcess"?

No Data Available

BPMN1. Section 6 of the current specification should be moved as an appendix
2. All attributes related to the BPEL mapping should be removed

see below

BPMNOne point that need more precision in the BPMN specification is Inclusive Gateways behavior.
The rule "When the Inclusive Gateway is used as a Merge, it will wait for (synchronize) all Tokens that have been produced upstream" is not clear at all.
It can be applied in very simple situations (when a token is divided in several tokens when going out of an Inclusive Gateway, and merge at another Inclusive Gateway for example), but as no sense in more complex cases. As BPMN is very flexible and allows modeling of business processes that are not "block-structured" as opposed to BPEL, a more precise rule is needed for Inclusive Gateways.
A discussion was opened by Petko Chobantonov on BPMN forum about this problem. He proposed another rule to clarify the Inclusive Gateway behavior but that led to nothing.

Here is another comment:

In the last version of the BPMN specification (Version 1.1 - July 31, 2005), a new rule was added on gateways (p 88):

"If two or more Signals (Tokens) arrive to their respective Gates at the exact same time, then the Signal..."

"exact same time" does not mean anything, and a rule like this has nothing to do in a "Notation" specification.

No Data Available

Sec. 6.16 states that "The Type attribute of the Property will map to the type attribute of the part". This seems to imply that WSDL parts are always defined with a type attribute, which is not the case (i.e. they can also be defined with an element attribute instead of a type attribute).

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

Since BPMN is considered to provide a business-level representation of processes (i.e., a PIM), it is appropriate that the mapping to BPEL be moved to the appendix. In addition, the BPEL mapping should not be defined as a normative part of the specification since BPEL is viewed as a platform/execution language. In other words, the transformation could be different depending on the particular implementation of BPEL. A normative mapping to WSDL and choreography (which might be expressed in BPEL) is needed, but should be a mapping from a normative BPMN metamodel rather than the graphical notation.

No Data Available

I've been checking the BPMN for the connections, My question/comment is that why the spcification didn't introduce a type of connections that compines both Message and Flow (A connection that does both functions at the same time, it models the sequence and also models that data/message is being passed from the source object to the target object). Without having that type of a connection a diagram will contain many objects connected by two connections (one for the sequence and the other for the message) which leads to complexity in the diagram layout.

No Data Available

The spec should specify which additional artifacts (e.g. WSDL files) are required to successfully generate BPEL processes.

For example, sec. 6.16, Message mapping, refers to the "type attribute of the part". In case the type is a complex one, it looks like a WSDL file would be required in order to have the complete type description for BPEL generation purposes, but that is not mentioned in the spec.

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

I believe that there should be a restriction placed on the number of tokens that may be present on a given wire. If a situation arises where there are several tokens on a given wire coming into a merge gateway then there is a correlation problem between the multiple incoming tokens on one wire and tokens arriving on other wires. Such correlation becomes a serious business problem when documents are associated with token flows. E.g. if there are two tokens on one wire and two tokens on another wire then there are two different ways of correlating the merging tokens. Proposed resolution: restrict the number of tokens on a given wire in a single instance of a process to zero or one.

No Data Available

Every element in a diagram should have an optional description attribute. This is in addition to the name and properties' attributes. One issue to decide is whether a description attribute should have structure - whether it refers to a machine-processable description or a human oriented description. Essentially both are important

No Data Available

I feel that the definition of the behavior of the Error intermediate Event is unclear in the BPMN Adopted Specification. We implemented its behavior to closely model the <throw>/<catch> in BPEL, but upon discussion with one of our customers and then with Steve it appears that our interpretation of the spec is not what was intended by its authors.

Error intermediate Events are discussed with any detail in the following places in the spec:

--------------------------

Table 9.6 (p. 41) describes the End event and says - "This type of End indicates that a named Error should be generated. This Error will be caught by an Intermediate Event within the Event Context."

Table 9.8 (p. 45) describes the Error intermediate event - "This is used for error handling--both to set (throw) and to react to (catch) errors. It sets (throws) an error if the Event is part of a Normal Flow. It reacts to (catches) a named error, or to any error if a name is not specified, when attached to the boundary of an activity."

Table 9.9 (p. 46, 47) has Error intermediate event attributes described. The behavior described there relates to the ErrorCode.

Text on p 59-60 describes its role in modeling a Hazard in a Business Transaction.

Text on p 76 mentions it can be a target of an Event-based Gateway, although on p. 78 under "Changes since the 1.0 draft version" it says that Error was removed as a possible target. I believe the text on p

76 is an editing error.

Text on page 130-131 describes the "Event Context", mentioned in table 9.6. Text on that page in the last paragraph explicitly compares Error to the BPEL4WS fault, and goes on in that paragraph to describe the role of the ErrorCode.

Table 11.5 (p. 141) mentions that Error end events map to BPEL throw elements, again tying it to the notion of faults.

Table 11.10 (p. 145) describes the mapping to BPEL for intermediate Error event, which proposes that a boundary event be mapped to a <catch> within a <scope> that encompasses the activity.

------------------------

From this somewhat limited description, we chose to implement Error as a strictly hierarchical faulting mechanism, as it is in BPEL as well as most programming languages, and which seems a direct consequence of the mapping in Table 11.10. However, in subsequent discussion I have learned it was the intention of the authors that Errors be "subscribed" to in a global scope, and that they will be responded to from any activie location in the process, but that the highest "parent" activity in a subprocess hierarchy will supersede (and terminate) any lower-level Error intermediate events. (This is my interpretation of an email thread with Steve on this subject that is not crisp enough to include verbatim in this issue. I may have interpreted it wrongly, however.)

If the intention of BPMN is to allow Error to be used as a parallel- thread signaling mechanism (supporting a "first one done wins" pattern, for example) as well as a hierarchical faulting mechanism (where the scope in which a thrown Error can be caught is limited to the hierarchy of parents of the activity that causes it, including the activity itself) then the behavior of a number of ambiguous topologies need to be clarified in the spec. Also, I believe the mapping to BPEL is incorrect for the signaling use, and that for some configurations a correct mapping may not exist.

In any event, clarifying the scope of the Event Context with respect to the behavior of the Error event seems necessary.

-------------------------

My proposed resolution will be for the text to make it clear that Error can only be caught by the activity that causes it or one of its parents. There are several other alternatives to use for signaling between parallel sequence flows, including our suggestion to our customers that the Rule event be used.

No Data Available

The spec mandates that "if there is only one lane, then that lane shares the name of the POOL, and only the POOL name is displayed. If there is more than one lane, then each lane has to have its own name and all names are displayed". Request is to remove the requirement making lane name dependent upon pool name. Suggested text "If there is only one lane, only the pool name is displayed. If there is more than one lane, the name of the individual lanes must be displayed as well as the name of the pool." With this change, if there is only one lane, the lane name is not shown, but the user is free to rename the name of the lane, if desired.

No Data Available

Details:
Section 8.2 is entitled "BPD Complete Set", and Table 8.3 is "BPD Complete Element Set", but the text says that that what the table displays is just "... a more extensive list" showing what "...could be depicted through a business process modeling notation". If it is really the complete set, it is misleading to describe it in this way. I guess the topic is not what could be depicted with a business process modeling notation, but rather the full extent of what is provided for with the BPMN notation as specified in this document.

This issue suggest that the provision for extending the notation should not be scattered (as it is now) throughout the document, so that better clarity can be achieved between the notation provided in the spec, and the possiblity of user extensions of that notation. The problem now is that the possiblilty of adding new notations is getting mixed in with the purported presentation of the COMPLETE SET.

No Data Available

See page 23, text just preceding table 8.1, adopted spec 06-01-01
States "There are four standardized Artifacts" but then lists only three, followinng the text: "The current set of Artifacts include..."
The use of "include" suggests there are more and the list is just some "for instance" examples of standardized artifacts."
If their are four, please let us know which four they are.

No Data Available

Section 12 of the specification should be moved as is to an appendix, based on its focus on mapping to BPEL. In addition, the text from that section that does not deal with BPEL mapping should be copied and placed within the Overview section (Section 7).

No Data Available

We have a couple of questions relating to the notion of a diagram with an “invisible pool”.

Per p. 42 “A BPD SHALL contain one or more Pools. The boundary of one of the Pools MAY be invisible (especially if there is only one Pool in the Diagram).”

How would an “invisibly-bordered” pool be represented in the diagram? Or would this be implicit when creating the diagram?
Would you be able to add lanes to an “invisibly-bordered” pool? We should propose the user is not able to add lanes to an “invisibly-bordered” pool as it could become a diagram containing pools…

No Data Available

I am not sure what shape the following information is referring to as no reference to a figure and no shape appear to be provided. I am also not certain how this relates to End Events.

Section 4.3.3. End (p. 52)

This shape is OPTIONAL: a given Process level—a top-level Process or an expanded Sub-Process—MAY (is not required to) have this shape:

No Data Available

Clarify why BPMN separates data and sequence, for example, in Figure 10.11. The proposed resolution to http://www.bpmn.org/FTF/Issues/Issue%209113.htm should respond to this issue, rather than 9113, which is about how to bind sequence and data flow.

No Data Available

Table 8.1: does not explain the difference between the 2 depictions of Associations given (one with an arrow)

No Data Available

Several elements can have Categories attached. This is documented in Table 8-7 as "the Modeler may add one or more defined Categories"...However there is no mechanism for creating the 'defined categories' (as opposed to using them).

No Data Available

Issue B) Unclear whether BPEL is part of Conformance
Section 6.2 states "The BPMN specification supports for the following specifications is a normative part of the BPMN specification: BPEL4WS."
but BPEL is not mentioned in the Conformance section 2

No Data Available

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

Issue summary: Which is it, (OR-Join) or (XOR) Gateway?

Note: This issue is closely related to 9327

Details:
See page 24, adopted spec 06-01-01
Table 8.3, BPD Complete Element Set
row for "Merging (OR-Join)"
Text tells how to use "A Merging (XOR) Gateway", but the name of the model element is given as "Merging (OR-Join)".
Then in row "Gateway control types" on page 20 it bives the names as 'XOR' and 'OR' as names of distinct types of control
It seems to me that the author of the text in the row for "Merging (OR-Join)" was thinking of xor as being a sort of specialization of inclusive or, and so mixed a discussion of the OR and XOR together, but this is inconsistent with defining OR as meaning inclusive or. This needs to be rewritten to be consistent.

No Data Available

I am unclear what Figure 13 on p. 71 represents. The bottom part of the diagram appears to show multiple pools joined together(Employee, Retail, etc.), showing lanes without labels. Is this a single poole or multiple pools?

No Data Available

Sometimes It is too complicated notation.
Can I use standard defacto notation like UML, DSL or others ?
We have limited time to learn the new one to adapt new notation and give
training to other parties.
Maybe you should give more choice for the notation like you can use class
diagram (in UML of course) with stereotypes with limited features, or you
can use pure BPMN notation with full feature; or maybe you can use some
translation or search some equal diagram from BPMN to other diagram
to make the beginners understand.

I suggest you create a templates to plug into MS Visio, Rational Rose
Petal or other CASE tool to make users adapt the notation quickly.
Perhaps you can build the beta version until the release

No Data Available

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.

Why 2 notations for Data based XOR
Why not data and event options for inclusive OR?

No Data Available

Table 8.1: unclear if a Group groups Activities or objects in general. Can it have a name?

No Data Available

found the mapping to BPEL somewhat hard to follow. In particular the use of indentation in tables such as 11.4.1 is not clear.

No Data Available

In general I found the BPEL mapping aspect over-pervasive within the document, and not restricted to section 11. The impression could be gained that nothing can be a business process unless it can be represented in BPEL. This will tend to be off-putting to the business users the spec claims to address (I have no objection to the BPEL Mapping section) - it's just the constant references to BPEL to explain process modeling concepts and the BPMN notation. For example in the definition of the concepts in section 7.1.1 of private, public and abstract business process. Again I'm surprised there is no conformance point related to BPEL mapping.

No Data Available

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

No Data Available

The Conformance section (2) has 3 points: 3rd of these is somewhat inoperative since it refers to a to-be-defined interchange format.

No Data Available

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

No Data Available

Currently, roles can only be associated with tasks, via the "performers"
attribute. However, it is common to associate roles with subprocesses. In
the case of a subprocess, the meaning is one of responsibility for the
subprocess rather than who performs the subprocess.

No Data Available

Currently, only User Tasks and Manual Tasks can have performers. Suggest
this be extended to other types of tasks, that is, allow association of
performers with any kind of task.

No Data Available

What are the semantics of a Start Event with a Trigger in of a subprocess?
When will the subprocess be instantiated ... when it's parent process sends
it a token or when it receives the event trigger?

No Data Available

A Sequence Flow that has an Exclusive Data-Based Gateway or an activity as its source can also be defined with a condition expression of Default. Such Sequence Flow will have a marker to show that it is a Default flow. I believe that the condition expression of Default can be set to Sequence Flow that has an Inclusive Gateway as its source as well as the above mentioned. It naturally results from what is written on page 82 about Inclusive Gateways diverging behaviour

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 source Gateway MUST NOT be of type AND (Parallel). A assume that the gateway MUST NOT be of type XOR as well.

In this case, a Gateway can be Exclusive (XOR), but it cannot be Complex. Thus, the text
requires a modification