Issues for Mailing list of the BPMN FInalization Task Force

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

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

Issue 9113: Business Process Diagrams
Issue 9115: BPMN comment: additional artifacts
Issue 9116: Sec. 6.16
Issue 9121: BPMN comment
Issue 9139: Section 6 of the current specification should be moved as an appendix
Issue 9240: Mapping to BPEL should be moved to the appendix
Issue 9312: Missing examples
Issue 9318: Attributes not explained with respect to Notation
Issue 9319: Unclear whether BPEL is part of Conformance
Issue 9320: Irrelevant conformance point
Issue 9321: compliance level to cover core elements/simple business modeling
Issue 9322: BPEL over-pervasive in document
Issue 9323: BPEL mapping hard to follow
Issue 9324: No means to define Categories
Issue 9325: Ambiguous notations for Association
Issue 9326: Unclear semantics of Group
Issue 9327: Ambiguous notations for OR
Issue 9328: Sequence Flow is not a Flow Object
Issue 9329: Unclear what complete syntax is for an Attribute
Issue 9342: Semantical difference between activity models and BPMN
Issue 9343: complicated notation
Issue 9345: unclear what Figure 13 on p. 71 represents
Issue 9353: Which is it, (OR-Join) or (XOR) Gateway?
Issue 9354: Are there 3 or are there 4 Standard Artifacts?
Issue 9355: Which is it, Core Elements, or Flow Objects?.
Issue 9356: Is it really the Complete Set?
Issue 9357: Need consistent terminology for Categories, Core Elements
Issue 9361: Section: 4.6
Issue 9363: shared collaboration
Issue 9364: differentiate a business message from a business signal
Issue 9367: BPMN Adopted Spec issue - Clarify behavior of Error intermediate event
Issue 9376: fundamental semantic model of token flows
Issue 9377: optional description attribute
Issue 9378: restriction to be placed on the number of tokens
Issue 9408: Clarify why BPMN separates data and sequence
Issue 9409: Diagram with an "Invisible Pool"
Issue 9410: Update definition of merging behavior of Exclusive Data-Based Gateway
Issue 9411: Section 12 of the specification should be moved as is to an appendix
Issue 9412: Section 4.3.3 Reference to "missing" shape
Issue 9461: Is BPMN just a notation?
Issue 9465: how to model a process where more than one participant (pool) plays a part
Issue 9558: BPEL mapping definition is imprecise
Issue 9559: Containment structure is unclear for non-graphical elements
Issue 9560: Some references are not explicit
Issue 9561: Message Flow ordering along Pool (abst process) is modeled only graphically
Issue 9562: Time intervals modeling is imprecise
Issue 9563: Message/Property/Assignment relations are too complex
Issue 9564: Reference Subprocess
Issue 9565: Reference Task does not define any way to pass parameters and values
Issue 9566: BPEL/WSDL specific properties
Issue 9567: BPEL->BPMN mapping problem
Issue 9568: correlation set
Issue 9569: partner links are not modeled in BPMN explicitly.
Issue 9570: BPMN spec doesn't include join condition
Issue 9571: BPEL faults
Issue 9572: enhance BPMN to provide 'resource modeling'.
Issue 9573: Specify persistent format
Issue 9615: BPMN Issue: Exclusive Gateway Merging
Issue 9716: Gate is a common feature of Gateways
Issue 9717: The list of supporting objects in B.11 is incomplete
Issue 9719: The concept of "Trigger" in ambiguous in the BPMN specification
Issue 9722: p. 282, Table 137
Issue 9801: BPMN TaskType Attribute
Issue 9883: Link does not have clear semantics
Issue 9892: Definition of "Rule"
Issue 9893: Definition of "Expression"
Issue 9894: IORules attribute
Issue 9895: Independent Subprocess
Issue 9896: Performers
Issue 9897: Role association to subprocesses
Issue 9898: Tasks with multiple outgoing message flows
Issue 9899: Intermediate Events with outgoing Message Flow
Issue 9900: "StartQuantity" attribute
Issue 9901: "Quantity" attribute
Issue 9902: DataObject attributes
Issue 9903: MessageFlows to a subprocess boundary
Issue 9904: Optional Start/End Events
Issue 9905: Start Events with triggers on a subprocess
Issue 9906: "Exception" trigger
Issue 9907: SubProcessRef
Issue 9908: BPMN: Attribute definitions
Issue 9917: Multiple Triggers with 'and' semantics
Issue 9925: BPMN: Complex triggers
Issue 9928: BPMN: Interrupt Intermediate Event
Issue 9936: Events in subprocesses
Issue 9937: Provide ExpressionLanguage attribute for the element Expression
Issue 10084: Extending activities with execution time (traversal time) attributes?
Issue 10096: Inclusive Event-Based Decision
Issue 10138: Multiple None Start Events inside of a sub-process
Issue 10139: Message flows in and out of independent sub-processes
Issue 10150: Implicit State Machine for Activities
Issue 10152: Is it valid to have a pool nested within a Lane,
Issue 10282: Defining "Main" Pool in diagram
Issue 10339: Do artifact flows affect execution
Issue 10340: Clarify whether pools require their activites to be centrally coordinated
Issue 10341: Where are tokens queued?
Issue 10348: Page: 23
Issue 10350: BPMN spec not clear on separation of data/display regarding pools and lanes
Issue 10352: Section: 7.1.1/Note
Issue 10355: Section: 8.1, Table 8.1
Issue 10372: The Reference Task and Reference Subprocess should be removed
Issue 10373: Add a UML Profile to the BPMN specification
Issue 10375: Section: 10.1.3
Issue 10384: no way to graphically differentiate an Embedded Subprocess
Issue 10409: Culturally significant icons
Issue 10428: Change the activity Marker for Multiple Instance activities
Issue 10429: Clarify the scope and usage of Compensation Events
Issue 10448: Specify return type of ComplexMI_FlowCondition
Issue 10449: The direction arrow for association seems backwards
Issue 10467: References to Annex D and there is no Annex D in this specification
Issue 10475: examples in section 10.2.1 Normal Flow (01)
Issue 10476: examples in section 10.2.1 Normal Flow (02)
Issue 10503: UML class diagram in the appendix
Issue 10516: Use of link events to synchronize behaviour
Issue 10518: Move Sequence Flow Conditions to Gates
Issue 10519: question raised by Issue 9321 nor addresses by issue 9319
Issue 10520: Should Exception Events be allowed to have no Outgoing Sequence Flow?
Issue 10527: Add Project Management dependencies for activities (FF, FS, SF, SS)
Issue 10657: BPMN Task Attribute "TaskType" Value-related Message Flow Restrictions
Issue 10932: Section: 9.3.4 Intermediate [Events]
Issue 10933: Section: 10:2.1 Normal Flow
Issue 11150: Page: Page 1 (PDF page 25)
Issue 11151: Page 19 (PDF page 43) Table 8.2, definitionof "Pool".
Issue 11241: confusion regarding diagram 10.25
Issue 11277: BPMN does not explicitly identify a model element for "approval."
Issue 11278: BPMN does not have a symbol for a physical storage facility
Issue 11634: Section: 9.4, 9.4.1, 9.4.2
Issue 12243: Why in paragraph 7.1.1 Uses of BPMN, definition of Collaboration (Global)

Issue 9113: Business Process Diagrams (bpmn-ftf)

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.

Discussion:
The basic question of the Issue was deemed invalid in that BPMN does provide a
mechanism to bind Data Objects through association as shown in the Final
Adopted Specification (FAS) Figure 9.35. Thus, the concern about the complexity
in the diagram layout, for this particular reason, is unwarranted.
Disposition: Closed, no change

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.

Discussion:
While the Issue is valid, it represents a part of a larger issue reviewing and
repairing a lot BPEL mapping issues. Thus, this Issue will be deferred and
handled by a later version of BPMN. The work could be done as part of the
BPDM RFP or as part of a new RFP or RTF.
Thus, the Issue will be deferred, but a minor text revision will be included in the
specification
Revised Text:
Section 11 (this section will probably be moved to an appendix), page 137,
append the paragraph in that section: "Note that there are known issues with the
mapping as specified. Fixes to these issues will be incorporated in a later
revision of the specification."
Disposition: Deferred

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

Discussion:
While the Issue is valid, it represents a part of a larger issue reviewing and
repairing a lot BPEL mapping issues. Thus, this Issue will be deferred and
handled by a later version of BPMN. The work could be done as part of the
BPDM RFP or as part of a new RFP or RTF.
Disposition: Deferred

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.

Resolution:
We will enhance the definition of the merging behavior of the Inclusive Gateway
to include the definition as stated in the revised text section below.
The second part of the Issue is considered out of scope of the FTF since it refers
to a version (draft V1.1 by BPMI) of the specification that is not under
consideration of the FTF and never will be under consideration of an OMG Task
Force.
The use of formal terms such as XOR, OR, and AND was considered as
potentially confusing when the description of Gateway behavior is considered.
The names of the Gateways was considered a better (but not perfect) indicator of
the behavior. Thus, we decided to remove parenthetical additions of the formal
terms, especially in the section titles.

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

Resolution:
Section 11 of the Specification will be moved to Annex A. The current contents of
Annex A will remain as a section. Other changes will be made to make the
specification more readable (in terms of BPEL mapping) following the concerns
raised in Issues 9322 and 9323.

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.

See issue 9139 for disposition

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 

Resolution:
We will include an examples for vertical Pools and nested Lanes in the
specification.

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.
 

Defer: The OMG roadmap for BPMN and BPDM indicates that the two specifications will be
consolidated for a BPMN/BPDM 2.0. When this occurs all issues regarding notation vs.
metamodel will no longer be problematic. Since this issue involves a discussion of the
notational aspects vs. an underlying metamodel for BPMN, we can defer this issue to version
2.0.

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
 

Resolution:
Section 2 of the specification will be updated to clarify the conformance for BPEL
and more general conformance considerations.

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

See issue 9319 for disposition

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 issue 9319 for disposition

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.

See issue 9319 for disposition

 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.
 

See issue 9139 for disposition

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

Resolution:
A description of Groups is given in Section 9.7.4. A pointer to Section 9.7.4 was
added to Table 8.2 and 8.3 through the resolution of Issue 9325. The resolution
of this issue is dependent on the reorganization of the BPMN attributes and
elements as resolved in Issue 9377. Both categories and groups are mechanisms for adding user-defined semantics
to a model. This resolution proposes to align the category and group concepts in
BPMN, thus removing redundancy and reducing confusion over when to use one
versus the other. The category will now provide the semantic designation, while
the group is merely one way in which a category can be visualized.
A group MUST have exactly one category associated with it. The name of the
category serves as the group label.
All graphical elements within a group must be associated with the category that
the group is associated with.
Use Cases:
o The user draws a group box around several graphical objects, and then
associates the group with a category. The name of the category is shown
on the diagram as the group name. All graphical objects within the group
box will have the group’s category added to their category lists, if it is not
already there.
o The user associates one or more categories with any graphical object.
The User then selects the category and chooses a visualization technique.
One available technique would be to visualize as a group box. Tools can
define additional visualization techniques, but some possibilities include:
colors, lanes, and stereotype labels. It is up to the tool to ensure that the
selected visualization can be applied

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

Resolution:
A description of Associations is given in Section 10.1.4. A brief description will be
added to the table and a pointer to Section 10.1.4 will be added to the
specification (see below).
Note: Table 8.1 and 8.2 will be updated to provide pointers for all elements where
there is additional information provided in later sections of the specification.

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

Resolution:
The concepts of Categories and Groups will be aligned. Issue 9324 will specify
the required changes to the specification, so no further changes are required for
this issue.
Revised Text:
None

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

Resolution:
The specification will be modified in Section 9.5.2 to describe the rationale for
having the two versions of the Exclusive Gateway. A separate Issue will be generated to evaluation the addition of an Inclusive
Event-Based Gateway.

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

Discussion:
While the Issue may be valid, it represents potentially significant modifications.
Thus, this Issue will be deferred and handled by work on a later version of
BPMN.
Disposition: Deferred

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

Discussion:
While the Issue may be valid, it represents potentially significant modifications.
Thus, this Issue will be deferred and handled by work on a later version of
BPMN.
Disposition: Deferred

 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.

Discussion:
The FTF agrees that there is a problem that needs fixing or addressing (Activity
Diagrams and BPMN), but could not agree on a resolution and deferred its
resolution to future work on BPMN.
Disposition: Deferred

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

Discussion:
The FTF decided that the issue report does not, in fact, identify a problem with
this (or any other) OMG specification. A mapping from BPMN to UML2 will be
included in the response to the BPDM RFP and this may alleviate some of the
concerns raised in this issue.
Disposition: Closed, no change

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? 

Resolution:
The FTF agreed that there is a problem that needs fixing, and has proposed a
resolution (which may or may not agree with any resolution the issue submitter
proposed).
Figure 9.10 will be updated to include a Pool Name for the Pool that has Lanes.
This will make this figure consistent with the other figures of Pools that are in the
specification. Also, the figure will be modified so that entire width of the
Processes are not displayed. By reducing the width of the diagram it can be
zoomed in enough to make the diagram more legible.

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.

The specification will modified to remove all references to terms such as OR,
XOR, AND, etc.

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.

Discussion:
The issue was apparently raised after a review of the BPMI version of the BPMN
specification or the Draft Adopted Specification. The text was changed in the
Final Adopted Specification so that the issue is no longer valid.
The FTF decided that the issue report does not, in fact, identify a problem with
this (or any other) OMG specification.
Disposition: Closed, no change

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 

While the Issue may be valid, it represents potentially significant modifications.
Thus, this Issue will be deferred and handled by work on a later version of
BPMN.
Disposition: Deferred

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.

Resolution:
A more accurate name for Section 8.2 and Table 8.3 would be "BPD Extended
Element Set."

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

Discussion:
While the Issue may be valid, it represents potentially significant modifications.
Thus, this Issue will be deferred and handled by work on a later version of
BPMN.
Disposition: Deferred

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.

Resolution:
We agreed that the text in the spec is restrictive and confusing and doesn't let a
tool vendor the appropriate flexibility in designing a system to create and display
Pool and Lane names.
We recommend that the Issue be resolved through a revision in the text.

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

Discussion:
The FTF agrees that there is a problem that needs fixing or addressing, but
considers the resolution to be too complex for a FTF and defers its resolution to
future work on BPMN.
Disposition: 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
# 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.

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.

Resolution:
The text will be modified to specify that an Error can only be caught by the
activity that causes it or one of its parents.

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

Discussion:
While the Issue may be valid, it represents potentially significant modifications.
Thus, this Issue will be deferred and handled by work on a later version of
BPMN.
Disposition: Deferred

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

Resolution:
All elements will be given an optional Documentation attribute. The organization
of BPMN elements and attributes will be modified to accomplish this and to clean
up additional problems found with the way attributes are organization and
presented in the specification. Also, class diagrams of the elements and
attributes will be added to Appendix B to aid in the readers understanding of the
contents of that appendix.

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.

Discussion:
We agreed that multiple Tokens may create complications in some situations, but
we did not believe that it was possible to model all required business situations
by imposing this restriction.
Disposition: Closed, no change

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.

Resolution:
Figure 10.11 will be changed to better show the separation of Data and
Sequence.

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… 

Resolution:
The specification will be updated to clarify the meaning and use of Pools, with
and without boundaries and the use of Lanes within the Pools (see revised text
below).

Update the definition of the merging behavior of the Exclusive Data-Based Gateway. Currently, the Gateway just passes all Tokens through. The behavior should be changed to be exclusive in that it will allow the first Token to arrive through the Gateway, but ignore/consume all other Tokens from the same Token family. 

Discussion:
This issue will be resolved during the next BPMN FTF.
Disposition: Deferred   Defer: The potential complications of resolving this issue, particularly surrounding the formal
definition of Token flow, requires that this issue be deferred so that it can be handled in a
better way in BPMN 2.0. However, a couple of modifications to the specification are required to
correct an error in how the Exclusive Data-Based Gateway was applied in an example.
Revised Text:
Section 10.2 "Sequence Flow Mechanisms," page 119:
a) Second paragraph on the page: replace paragraph with the following paragraph:
"Another merging situation is the Workflow Pattern Discriminator. In this situation, the
multiple incoming Sequence Flow are parallel instead of alternative (see Figure 10.32).
Thus, there will be two Tokens arriving (at different times) at the Complex Gateway
preceding activity “D.” To satisfy the Discriminator pattern, the Complex Gateway must
accept the first Token and immediately pass it on through to the activity. When the second
Token arrives, it will be excluded from the remainder of the flow. This means that the Token
will not be passed on to the activity, but will be consumed." (Note: there is a footnote
included with the "Workflow Pattern Discriminator." text)
b) Figure 10.33 ("Workflow Pattern #8 -- Discriminator"): Replace figure with the following
Figure:
Disposition:

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

Resolution:
A copy of Section 12 shall be placed in Appendix A (which deals with BPEL
mapping). The parts of Section 12 that deal with the mapping to BPEL will be
removed, so that the section only contains a sample process. These changes
have been specified in the resolution of Issue 9139, so no further changes are
required.
Revised Text:
None.

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:

The specification will be changed to remove the ambiguity.

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.

Close; No Change: With the development of BPDM and the planned combining of the BPMN
and BPDM work, this issue will become a non-issue. Thus, we will Close, with No Change.

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? 

Close; No Change: This issue does not require any specification changes. It is mainly a
question. Basically, it appears that the issue submitter is not familiar with Lanes within a Pool.
The Lanes can be used to model the people/groups involved in one process.

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

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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

Resolved: The naming of the BPMN attributes will help define or identify containment or
references. The names of the attributes that are references to other elements will be appended
with "Ref." Some attribute names are already formatted in this way or were changed in the
course of resolving other issues.

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

Resolved: The resolutions to issues 9367 and 10429 are sufficient to satisfy this issue. Thus, no
further changes are required

 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

Discussion:
While the Issue may be valid, it represents potentially significant modifications.
Thus, this Issue will be deferred and handled by work on a later version of
BPMN.
Disposition: Deferred

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

Resolution:
The definition of the Timer Trigger attributes TimeDate and TimeCycle will be
updated to of a (new) type DateTimeExpression, which will be a sub-type of
Expression. Pre-defined Process and activity Properties (such as
ActivityStartTime) are also required to facilitate the definition of appropriate
expressions. Changes to the specification for the updates of the Timer Trigger
attributes are listed below. Changes to the specification for the addition of Predefined
Process and activity Properties will be listed in the resolution of Issue
9563.

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.

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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

Resolution:
The handling of both Properties and Artifacts for inputs, outputs, and mapping
between process levels, needs to be both generalized and synchronized. The
following changes to the specification will be made:

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

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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.

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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.

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

 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.

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

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

The BPMN 1.0 version of the Exclusive Gateway merging (either data or event Gateways) acts as a "pass through" for any Tokens that arrive. This means that there is no "exclusiveness" to the merging as the name of the Gateway would imply. A "discriminator" merging that allows the first Token through and stops any further (parallel) Tokens is a business pattern that cannot be currently modeled. This functionality should either replace the current merging behavior or be added to the behavior.

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

The resolution of Issue 9377 reorganized many of the attributes including the
creating of a Gate supporting element. Thus, Issue 9377's resolution solved this issue. No
further modifications to the specification are required

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.

The resolution of Issue 9377 reorganized many of the attributes including the
completion of the BPMN supporting element list. Thus, Issue 9377's resolution solved this
issue. No further modifications to the specification are required.

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. 

Resolved: The resolution for Issue 9717 is sufficient to address this issue. Thus, no further
changes are required.

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.

Resolution:
The definition of the Correlation attribute will be updated and a new attribute for
"Value" shall be added to the Property element. Also, the description for the Type
attribute will be updated to make the reference to hierachical Properties more
general. These change will result in the text revisions below:

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. 

Resolved: Change the text in the description (column 2) to match the definition (column 1)--the
default still stays None.

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.

Resolved: Link Events will be reduced in scope such that they will be only Intermediate Events
that can only be used within on Process Level. That is, now they are only to be used a Go To
objects or Off Page Connectors.

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

Resolved: The majority of changes for this issue will be the changing of the name of the Rule
Event to Conditional Event. There will be further changes to help explain the uses of
Conditional Events.

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

Resolution:
The description for an Expression will be updated. The Expression attribute (of
the Expression element) will be renamed to ExpressionBody. The
ExpressionLanguage attribute of the Business Process Diagram element will be
moved to the Expression Element. Thus, there is more flexibility in defining
expressions and their language. This will result in the text revisions below:

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

Resolved: The basic answer to the question of whether the IORules attribute should be a Rule
is "no," the attribute is really an expression. However, we determined that there was some
clarification required in the text as to the nature of the expression.

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

Resolved: Change the name of Independent Sub-Process to Reusable Sub-Process.

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.

Resolution:
The Performer attribute will be made more general to apply to all types of
activities. Thus, the attribute will be moved from the User and Manual Tasks to
the Activity and Process elements.

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.

Resolution:
The Performer attribute will be made more general to apply to Sub-Processes as
well as Tasks. The resolution of Issue 9896 will achieve the same result. Thus,
no further changes to the specification are required.
Revised Text:
None
Disposition: Resolved

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.

Resolved: The specification will be clarified to state that if a Task has multiple outgoing
Message Flow, then each Message Flow must carry the same Message and that the Message
will be sent down all Message Flow. The same will be true for incoming Message Flow, will
now be allowed to have multiple incoming Message Flow, except that a Message can arrive
from only one Message Flow for a given instance of the Task.

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

Resolved: The text of the specification will be modified to allow out going Message Flow for a
Message Intermediate Event.

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?

Resolved: The StartQuantity should apply to Tokens arriving from any Sequence Flow. Thus, the
text will be modified by removing the statement "from a single Sequence Flow."

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

Resolved: This attribute should be part of the completion of an activity, rather than an attribute of
a Sequence Flow. Thus, Quantity will be removed from the Sequence Flow list of attributes and
CompletionQuantity will be added to the list of activity attributes.

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.

Resolved: The RequiredToStart and ProducedAtCompletion will be moved from the Data
Object list of attributes. They will be applied to InputSets and OutputSets. This involves some
restructuring of the Supporting Elements to accommodate the move. New elements named
ArtifactInput and ArtifactOutputs (referenced by InputSet and OutputSet, respectively) will hold
the two attributes, respectively

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.

Resolved: The text as shown on page 103 is not correct. Thus, that sentence will be removed.
Given this, it would also be appropriate (and make the text less confusing) to remove Figure
10.7 (and its caption).

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

Resolved: We will modify the specification text to clarify that implicit Start and End Events do not
have a trigger.

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?

See issue 9936 for disposition

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

Resolved: All instances of Exception Events will be changed to Error.

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

Resolution:
The type for the "SubProcessRef" Attribute will be changed to "Sub-Process."

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.

Resolved: The text of the specification will be updated to correct the problems noted by this
issue. Note that the second item about "OutgoingSequenceFlow" and the item on
"DefaultGate" were clarified through changes resulting from Issue 9377.

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.

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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.

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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.

Resolved: The Signal Trigger will be added for Events to solve the case for interrupting and
the more general case of communication within a Pool. It will affect the Intermediate and End
Events. Multiple changes and additions to the specification will have to be made (as defined
below).

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?

Resolved: The specification will be updated to clarify the relationship of Start Events and the
use of Processes as Sub-Processes. This clarification will describe how only the None Start
Event can be used for a Process that will be used for a Sub-Process (whether Independent or
Embedded). In fact, Embedded Sub-Processes MUST only have None Start Events. If a
Process has a Start Event that has a Trigger other than None, then this indicates that the
Process is intended for use as a top-level Process. A given Process can be used an a top-level
Process and an Independent Sub-Process, but it must have the appropriate Start Events.

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. 

Resolved: The resolution of Issue 9893 has addressed this item. No further changes are
required.

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.

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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. 

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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?

Resolved: Multiple None Start Events will continue to be allowed inside a Sub-Process. To
clarify what happens when the flow is transferred from a parent Process to a Sub-Process with
multiple None Start Events, the TargetRef attribute of the incoming Sequence Flow will be
extended. The TargetRef attribute of the incoming Sequence Flow (to the Sub-Process) will be
allowed to identify a particular Start Event within the Sub-Process. This will determine which of
the Sub-Process's Start Events will be triggered when the flow arrives from that Sequence
Flow. A different incoming Sequence Flow, either from the same or different parent Process,
could target a different Start Event.

Where an activity represents an invocation of an independent  
subprocess, the spec does not state how to bin any incoming and  
outgoing message flows to the sub-process. It does state how to bind  
information (input and output sets) but not messages.

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus, this
Issue will be deferred and handled by work on a later version of BPMN. Any changes made for this
version may potentially conflict with later modifications.

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? 

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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. 

Resolved: A new attribute will be added to the Pool element. This attribute will flag the Pool
that is the main Pool for the diagram.

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

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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)? 

Resolved: Lanes do not represent centrally coordinated activities, which was implied by the
wording of Section 8.4. The text will be changed as specified below.

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.

Defer: While the Issue may be valid, it represents potentially significant modifications. Thus,
this Issue will be deferred and handled by work on a later version of BPMN.

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.

Close; No Change: The question raised by the issue can be answered as follows: The text on
page 64 of the specification was referring only to Receive Tasks that can instantiate a Process,
the same way that a Message Start Event can instantiate the Process. Receive Tasks can be
used within the normal activity of a Process and then can be used in for an Event-Based
Decision. No modification of the text is required.

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.

Resolved: For question 1: A Process can be used in more than one diagram (For example,
the Reusable Sub-Process). For Question 2: same as in question 1. For Question 3: The
Process does not own Pools. In general: The resolution of Issue 9559, which clarifies the
attributes and their containment relationships, will cover most of this issue. There were other
instances where attributes referenced elements can could be derived from other attribute
relationships, making them redundant. These redundant attributes will be removed, as
specified below.

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

Resolved: The sentence will be corrected

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

Resolved: The sentence will be corrected both grammatically and for content.

“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.”

Add a UML Profile to the BPMN specification

Close, No Change: The addition of such a profile is out of scope for the FTF. This will be
handled through other OMG mechanisms, such as an RFP for the next version of BPMN.

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.

Defer: The modification suggested by this issue is out of scope for the FTF. This will be handled
through other OMG mechanisms, such as an RFP for the next version of BPMN.

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.

Deferred: While the Issue may be valid, it represents a challenge that could not be solved during
the time frame of the Finalization Task Force. Thus, this Issue will be deferred and handled by work
on a later version of BPMN.

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.

Resolved: The internal marker for multiple Events will be changed to the five-pointed
pentagon shape (not a star).

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.

Resolved: The multiple instance marker will be changed from two vertical parallel lines to
three vertical parallel lines.

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

Resolved: The text will be clarified to specify that a Compensation can be caught by any
activity that has been completed, at any level, during an instance of the top-level Process.
Also, a broadcast compensation ability will be added. This means that any completed activity
that has a Compensation Intermediate Event attached to its boundary will be compensated (in
reverse order).

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. 

Resolved: The return type of the ComplexMI_FlowCondition will be boolean. Additional
clarifications will be added to the descriptions of the Multi-Instance activity behavior.

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

Resolved: The definition of the directionality of Associations will be simplified. The directions
will now be None, One, or Both. If the direction is None, then there will not be an arrowhead. If
the direction is One, then there will be one arrowhead pointing at the Target of the Association.
If the direction is Both, then there will be an arrowhead at both the Source and Target of the
Association.

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)

Resolved: All references to Annex D will be removed

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.

Resolved: The resolutions for Issue 9883 and Issue 9928 were sufficient to address this issue.
Thus, no further changes are required.

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. 
 

We discussed using unfilled Event Icons to represent the "catch" Event and filled Icons to represent
the "throw" Event. This can be seen in the following figure:  ((page 63 of dtc/2007-06-01..pdf)   The blue arrows mark changes to the Event marker set based on this and other issues.
Note that Intermediate Events used in Event-Based Gateways must be "catch" events.
Suggested Resolution:
Resolved: We will add a capability to distinguish between Event that "catch" a Trigger and Events
that "throw" a Trigger or Result. The internal icon for "catching" Events will be unfilled, and the
internal icon for "throwing" Events will be filled. This change will have repercussions throughout the
specification, as listed below.
Revised Text:
Section 8.2,Table 8.3:
a) Page 19, first row "Type Dimension...," second column: append the paragraph with the
following sentence "Start Events can only react to (“catch”) a Trigger. End Events can only
create (“throw”) a Result. Intermediate Events can catch or throw Triggers. For the Events,
Triggers that catch, the markers are unfilled, and for Triggers and Results that throw, the
markers are filled."
b) replace the figure in the third column with:   (pages 64/65 of dtc/2007-06-01)  c) Page 20, second row "Gateway Control types," third column: replace the figure with:
d) Page 21, third row "Exception Flow," third column: replace the figure to show the Error
Intermediate Event marker as unfilled
e) Page 21, last row "Compensation Association," third column: replace the figure to show
the Compensation markers as unfilled f) Page 22, last row "Exclusive," third column: replace the figure to show the Multiple Event
marker as unfilled
g) Page 23, last row "Event-Based," third column: replace the figures to show the Multiple
Event markers as unfilled
Section 9.3.2 "Start," Sub-Section "Start Event Triggers," Table 9.4, page 37:
h) Last row "Multiple," third column: replace the figure to show the Multiple Event marker as
unfilled
Section 9.3.3 "End," Sub-Section "End Event Results," Table 9.6, page 41:
i) Second row "Message," third column: replace the figure to show the Event marker as
filled
j) Sixth row "Signal," third column: replace the figure to show the Event marker as filled
Section 9.3.4 "Intermediate," Sub-Section "Intermediate Event Triggers," Table 9.8, page 45:
k) Second row "Message," second column: replace the last two sentences with the following
sentences: "When used to “catch” the message, then the Event marker will be unfilled (see
top figure on the right). In Normal Flow, Message Intermediate Events can be used for
sending messages to a participant. When used to “throw” the message, the Event marker
will be filled (see bottom figure on the right) If used for exception handling it will change the
Normal Flow into an Exception Flow."
l) Second row "Message," third column: add a figure to show the Event marker as filled
m) Fourth row "Error," second column: Replace the paragraph with the following paragraph:
"This type of Event can only be attached to the boundary of an activity, thus it reacts to
(catches) a named error, or to any error if a name is not specified."
n) Fourth row "Error," third column: replace the figure to show the Event marker as unfilled
o) Fifth row "Cancel," third column: replace the figure to show the Event marker as unfilled
p) Sixth row "Compensation," second column: append the paragraph with the following
sentences: "They can also be used as generic “Go To” objects within the Process level.
There can be multiple Source Link Events, but there can only be one Target Link Event.
When used to “catch” from the Source Link, the Event marker will be unfilled (see the top
figure on the right). When used to “throw” to the Target Link, the Event marker will be filled
(see the bottom figure on the right)."
q) Sixth row "Compensation," third column: add a figure to show the Event marker as
unfilled
r) Eighth row "Link," second column: append the paragraph with the following sentences:
"They can also be used as generic “Go To” objects within the Process level. There can be
multiple Source Link Events, but there can only be one Target Link Event. When used to
“catch” from the Source Link, the Event marker will be unfilled (see the top figure on the
right). When used to “throw” to the Target Link, the Event marker will be filled (see the
bottom figure on the right)."
s) Eighth row "Link," third column: add a figure to show the Event marker as unfilled  t) Ninth row (new) "Signal," second column: before the last sentence of the paragraph,
insert the following sentences: "When used to “catch” the signal, the Event marker will be
unfilled (see the top figure on the right). When used to “throw” the signal, the Event marker
will be filled (see the bottom figure on the right)."
u) Ninth row (new) "Signal," third column: add a figure to show the Event marker as
unfilled
v) Last row "Multiple," second column: replace the paragraph with the following paragraph:
"This means that there are multiple Triggers assigned to the Event. If used within normal
flow, the Event can “catch” the Trigger or “throw” the Triggers. When attached to the
boundary of an activity, the Event can only “catch” the Trigger. When used to “catch” the
Trigger, only one of the assigned Triggers is required and the Event marker will be unfilled
(see the top figure on the right). When used to “throw” the Trigger (the same as a Multiple
End Event), all the assigned Triggers will be thrown and the Event marker will be filled (see
the bottom figure on the right)."
w) Last row "Multiple," third column: add a figure to show the Event marker as unfilled
Section 9.3.5 (new section) "Event Details," page 54 (approximately):
x) Replace Figure 9.5 with the same figure as shown in item B
Section 9.4.2 "Sub-Process," page 55:
y) Replace Figure 9.8 to show the Compensation marker as unfilled
Section 9.4.2 "Sub-Process," Sub-Section "Reusable Sub-Process," page 58 (approximately):
z) Replace Figure 9.12 (new figure) to show the Message End Event with a Filled marker
Section 9.4.2 "Sub-Process," Sub-Section "Sub-Process Behavior as a Transaction," page 60:
aa) Replace Figure 9.11 (old number) "An Example of a Transaction..." to show the Events
with unfilled markers
Section 9.4.3 "Task," page 63:
bb) Replace Figure 9.13 to show the Compensation marker as unfilled
Section 9.5 "Gateways," page 69:
cc) Replace Figure 9.15 to show the same figure as in Item c
Section 9.5 "Gateways," Sub-Section "Event-Based," page 76:
dd) Replace Figure 9.21 to show the Mutliple Event marker as unfilled
ee) Replace Figure 9.22 to show the Mutliple Event marker as unfilled
Section 10.2.1 "Normal Flow," Sub-Section "Splitting Flow," page 117:
ff) Replace Figure 10.29 to show the Mutliple Event marker as unfilled
Section 10.2.1 "Normal Flow," Sub-Section "Sequence Flow Jumping (Off-Page Connectors and Go
To Objects)," page 125:
gg) Replace Figure 10.43 to show the catching Link Event marker as unfilled
hh) Replace Figure 10.45 to show the catching Link Event marker as unfilled
ii) Replace Figure 10.46 to show the catching Link Event marker as unfilled                                Section 10.2.1 "Normal Flow," Sub-Section "Controlling Flow Across Processes," page 128:
jj) Replace Figure 10.49 to show the throwing Signal Event marker as filled
Section 10.3 "Compensation Association," page 134:
kk) Replace Figure 10.58 to show the Compensation markers as unfilled
ll) Replace Figure 10.59 to show the Events with unfilled markers (the same figure as Item
aa)
Section A.1.13 (new section)"Exception Flow," Sub-Subsection "The Exception Flow Merges back
into the Normal Flow After the Activity," page 197:
mm) Replace Figure A.10 to show the Error Event marker as unfilled
Section A.1.13 (new section)"Exception Flow," Sub-Subsection "The Exception Flow Merges back
into the Normal Flow Further Downstream," page 198:
nn) Replace Figure A.11 to show the Error Event marker as unfilled
Section A.1.13 (new section)"Exception Flow," Sub-Subsection "The Exception Flow Loops back into
the Normal Flow Upstream," page 198:
oo) Replace Figures A.13, A.14, and A.15 to show the Error Event marker as unfilled
Section A.1.17 (new section)" Determining the Extent of a BPEL4WS Structured Element," Sub-
Subsection "Handling Link Events as Go To Objects," page 198:
pp) Replace Figures A.13, A.14, and A.15 to show the catch Link Event marker as unfilled

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.

Resolved: The diagrams that were added to Annex B will be updated to clarify that they are a
UML representation of the table information of the Annex. The classes in the diagrams will be
stereotyped as "Table." The generalizations will be stereotyped as "extends." and the visibility
marker ("+") will be removed from the attributes. The changes will also reflect all the
modifications to the table attributes that have been the result of other issue resolutions.

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.

Duplicate: This is a duplicate of Issue 10476

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

Defer: The changes to the specification are too extensive to be handled by the FTF. They will be
handled in the next version of BPMN.

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

Close; No Change: We determined that the suggestion of two levels of conformance
suggested by the issue was more of an issue of methodology, such that different tools and
modelers could apply methodologies that resulted in basic BPMN models (utilizing a set of
core BPMN elements) or more advanced BPMN models (utilizing all the BPMN concepts). It
seemed more appropriate for supporting documentation to define how different levels of
diagramming can be achieved with BPMN, rather than updating the 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)? 

Close, No Change: We determined that not requiring an outgoing Sequence Flow from an
attached Intermediate Event (i.e., when there are no Start and End Events) would be
detrimental to the clarity of the diagram. Also, discussion of this issue included a proposal to
not require a Start Event when there is an End Event. We determined that the cost of
maintaining the current requirements did not warrant a change to the specification.

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.

Defer: The modification suggested by this issue is out of scope for the FTF. This will be
handled through other OMG mechanisms, such as an RFP for the next version of BPMN.

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

Resolve: The restriction placed on the incoming and outgoing Message Flow for a None Task
will be removed.

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.

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

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

Page 19 (PDF page 43) Table 8.2, definitionof "Pool". Should lanes within pools be referred to as "Lanes" or "Swimlane"? Both terms are used. It would be good to be consistent. 

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. 

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

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

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

I am beginner in BPM but in order to understand the BPMN standard, I send these questions: 1) Why in paragraph 7.1.1 Uses of BPMN, the definition of Collaboration (Global) Process (page 14) says: The collaboration process can be shown as two or more abstract process communicating with each other (see figure 7.3).... But the Figure 7.3 looks like as "two or more private (internal) business processes communicating with each other", comparing the Figure 7.1 and Figure 7.2 For more emphasis what I saying In the Figure 7.3 both process (patient and Receptionist/Doctor), all activities for both process are shown, this is not agree with definition of Abstract (public) process (page 13), that says: ....All other "internal" activities of the private business process are not shown in the abstract process.... 2) if the difference between Private (internal) business processes and Collaboration (Global) processes is the number of business entities, this mean that : Private (internal) business processes for only one business entity or specific organization. Collaboration (Global) processes for two or more business entities. What about Abstract (Public) processes, how many entities are or can be involved? 3) The Abstract (public) Processes are "abstract" because the activities of the another process or participant are not shown ?, using words of the definition of the Abstract (public) Processes.