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 correlation set
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) e