Issues for Mailing list of the BPMN FInalization Task Force
To comment on any of these issues, send email to bpmn-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 9113: Business Process Diagrams
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 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 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 9356: Is it really the Complete Set?
Issue 9361: Section: 4.6
Issue 9367: BPMN Adopted Spec issue - Clarify behavior of Error intermediate event
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 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 9559: Containment structure is unclear for non-graphical elements
Issue 9560: Some references are not explicit
Issue 9562: Time intervals modeling is imprecise
Issue 9564: Reference Subprocess
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 9928: BPMN: Interrupt Intermediate Event
Issue 9936: Events in subprocesses
Issue 9937: Provide ExpressionLanguage attribute for the element Expression
Issue 10138: Multiple None Start Events inside of a sub-process
Issue 10282: Defining "Main" Pool in diagram
Issue 10340: Clarify whether pools require their activites to be centrally coordinated
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 10373: Add a UML Profile to the BPMN specification
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 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 10657: BPMN Task Attribute "TaskType" Value-related Message Flow Restrictions
Issue 9113: Business Process Diagrams (bpmn-ftf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary: 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.
Resolution:
Revised Text:
Actions taken:
October 21, 2005: received comment
July 26, 2006: moved to bpmn-ftf
April 19, 2007: closed issue
Discussion: 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
Issue 9121: BPMN comment (bpmn-ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: Section 9.5.2, page 71, section title: remove " (XOR)" from section title. Section 9.5.3, page 78, section title: remove " (OR)" from section title.
Section 9.5.5, page 85, section title: remove " (AND)" from section title.
Section 9.5.3, page 80, paragraph 2: replace the first sentence with "When the
Inclusive Gateway is used as a Merge, it will synchronize all Tokens that exist
upstream, but at most one for each incoming Sequence Flow (refer to the section
entitled “XXXX” for a definition of Token flow semantics). Note: Tokens with a
loop are upstream of every node in the loop."
Section 9.5.3, page 80, paragraph 2: remove the second sentence.
Actions taken:
October 26, 2005: received comment
July 26, 2006: moved to bpmn-ftf
April 19, 2007: closed issue
Discussion: 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.
Issue 9139: Section 6 of the current specification should be moved as an appendix (bpmn-ftf)
Click here for this issue's archive.
Source: MEGA International (Mr. Antoine Lonjon, antoine.lonjon@mega.com alonjon@mega.com mblin@mega.com)
Nature: Uncategorized Issue
Severity:
Summary:
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: see below
Revised Text: a) Rename the title of Annex A from "E-Mail Voting Process BPEL4WS" to
"Mapping to BPEL4WS"
b) Add a new introductory paragraph with the text: "This annex provides
information and examples about how BPMN will map to BPEL4WS 1.1."
c) Move Section 11 of the Specification to Appendix A, within the first Heading2
item ("A.1"). All the section, table, and figure headings need to be updated.
d) Section A.1, first paragraph: append the paragraph with the following two
sentences: "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." e) Copy Section 12 ("BPMN by Example") and paste into the second Heading2
item ("A.2") of Appendix A. All the section, table, figure, and example headings
need to be updated. Section 12 will remain, but the mapping sections will be
removed.
f) Section A.2 (new), first paragraph: Append first sentence with the text "...and
will extend Section 11 by adding information about how the example Process will
map to BPEL4WS."
g) Demote the current title ("E-Mail Voting Process BPEL4WS") to Heading2 and
move to the third Heading2 item ("A.3").
h) Remove the current A.1 section title ("Introduction")--but leave the first
paragraph of that section (which will now be in A.3) and the table that follows.
i) Section 11 (was 12), first paragraph: remove last sentence.
j) Section 11 (was 12): remove Section 11.1.1, Section 11.2.1, Section 11.3.1,
and Section 11.4.1.
k) Section 6.2, page 6, first paragraph: replace "...is a normative part..." with "...is
a non-normative part..."
l) Section 6.3, page 6: remove fifth paragraph
m) Section 6.3, page 6, sixth (now fifth) paragraph: remove the following text
from the end of the sentence: " and its particular mapping to BPEL4WS"
n) Section 6.3, page 6: replace the seventh (now sixth) paragraph with: "Annex
A: Mapping to BPEL4WS provides a mechanism for converting a Business
Process to a BPEL4WS document, provides and example of Process mapping,
and provides a full sample of BPEL4WS code based on the example process
mapping."
o) Section 7, page 9, third paragraph. second sentence: replace "...formal
mapping..." with "...mapping..."
p) Section 8.6.1, page 30, Table 8.7, third row (ProcessType), second column:
remove all the sentences after the second sentence.
q) Section 8.6.1, page 31, Table 8.7: remove the fourth row
(SuppressJoinFailure) and the fifth row (EnableInstanceCompensation) on the
page from the table. These rows will remain in a table in Appendix A.
r) Section B.2, page 243, Table B.2: remove the third row (SuppressJoinFailure)
and the fourth row (EnableInstanceCompensation) on the page from the table.
These rows will remain in a table in Appendix A.
s) Section 9, page 33, first paragraph: reset the reference to the BPEL mapping
section to Appendix A t) Section 9.5.2, Sub-Section "Event-Based," page 75, first paragraph, first
sentence: replace the text "...will map to the BPEL4WS pick." to "...was derived
from the BPEL4WS pick."
u) Section 9.5.2, Sub-Section "Event-Based," page 76: move last paragraph on
page to Section A.1.6 (new section as per above changes), Sub-Section "Event-
Based," page TBD, after the section title.
v) Section 9.6, page 86, first paragraph: remove the first two sentences.
w) Section 9.6, page 86, second paragraph: remove the first two sentences.
x) Section 9.6, page 86: combine the first two paragraphs into one paragraph.
y) Section 9.7.4, page 96, last paragraph on page: remove the following text from
the end of the last sentence: " and do not map to any BPEL4WS elements."
z) Section 10.2.1, Sub-Section "Joining Flow," page 114: remove last paragraph
on page.
aa) Section 10.2.1, Sub-Section "Merging Flow," page 121: remove first
paragraph on page.
bb) Section 10.2.2, page 131, last paragraph on page: remove first sentence.
cc) Section 10.2.2, page 132, first paragraph on page (continues from last page):
remove sentence.
dd) Section 10.2.2, page 132: combine the first two paragraphs.
ee) Section B.2, page 242, Table B.2, third row (ProcessType), second column:
remove all the sentences after the second sentence.
ff) Section B.11.7, page 270, Table B.47, third row (Correlation), second column:
remove second paragraph.
gg) Section B.11.11, page 271, Table B.51, first row (Participant), second
column: remove second sentence.
Actions taken:
November 3, 2005: received comment
July 26, 2006: moved to bpmn-ftf
April 19, 2007: closed issue
Discussion: 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.
Issue 9240: Mapping to BPEL should be moved to the appendix (bpmn-ftf)
Click here for this issue's archive.
Source: EDS (Mr. Fred A. Cummins, fred.cummins@eds.com fredcummins@acm.org)
Nature: Clarification
Severity: Significant
Summary: 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.
Resolution:
Revised Text:
Actions taken:
January 12, 2006: received issue
April 19, 2007: closed issue
Discussion: See issue 9139 for disposition
Issue 9312: Missing examples (bpmn-ftf)
Click here for this issue's archive.
Source: Embarcadero Technologies (Ms. Donna Burbank, donna.burbank@embarcadero.com)
Nature: Clarification
Severity: Significant
Summary: 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:
Revised Text: Add the following Figures:
a) New Figure before Figure 9.33 on page 91
b) Add reference to new Figure on page 90, first paragraph of Section 9.6.3,
modify first sentence: "...the entire length of the Pool, either vertically (see Figure
9.XX) or horizontally (see Figure 9.33)." the words "(see Figure 9.XX) " are
added after the word "vertically."
c) Add caption to new Figure: Caption text: "Two Lanes in a Vertical Pool"
d) Modify Figure 9.33 caption: Change text to: "Two Lanes in a Horizontal Pool"
The word "Horizontal" is added.
e) New Figure after the paragraph that is after the Figure 9.33 on page 91 f) Add caption to new Figure: Caption text: "An Example of Nested Lanes"
g) Add reference to Figure on page 91, first paragraph, modify forth sentence: "In
addition, Lanes can be nested (see Figure 9.XX) or..." the words "(see Figure
9.XX) " are added after the word "nested."
Actions taken:
January 25, 2006: received issue
Discussion: Resolution:
We will include an examples for vertical Pools and nested Lanes in the
specification.
Issue 9319: Unclear whether BPEL is part of Conformance (bpmn-ftf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: a) Add the following paragraphs after paragraph 3:
"This version of the specification does not specify a mechanism for exchange of
BPMN diagrams.
This version of the specification does not specify a mechanism for the exchange
of the semantic model of a process depicted by a BPMN diagram."
Note: Exchange of models of BPMN process semantics and diagrams is the
subject of other ongoing standards activities.
This version of the specification does not specify a normative mapping from
BPMN to WSBPEL.
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."
Section 2, page 1:
b) Replace this section with the following text:
"An implementation claiming conformance to this specification shall comply with
all of the requirements set forth in subclauses 2.1, 2.2 and 2.3 below.
2.1 Visual Appearance
A key element of BPMN is the choice of shapes and icons used for the graphical
elements identified in this specification. The intent is to create a standard visual
language that all process modelers will recognize and understand. An implementation that creates and displays BPMN Diagrams shall use the
graphical elements, shapes and markers specified in clauses 8-10 as the
diagrammatic elements that represent the specified concepts.
Note: There is flexibility in the size, color, line style, and text positions of the
defined graphical elements.
The following extensions to a BPMN Diagram are permitted:
o New markers or indicators MAY be added to the specified graphical
elements. These markers or indicators could be used to highlight a
specific attribute of a BPMN element or to represent a new subtype of the
corresponding concept. (See also 2.4 below)
o A new shape representing a kind of Artifact MAY be added to a Diagram,
but the new Artifact shape SHALL NOT conflict with the shape specified
for any other BPMN object or marker.
o Graphical elements MAY be colored, and the coloring may have specified
semantics that extend the information conveyed by the element as
specified in this standard.
o The line style of a graphical element MAY be changed, but that change
SHALL NOT conflict with any other line style required by this specification.
An extension SHALL NOT change the specified shape of a defined graphical
element or marker. (e.g., changing a square into a triangle, or changing rounded
corners into squared corners, etc.).
2.2 Structural Conformance
An implementation that creates and displays BPMN diagrams shall conform to
the specifications and restrictions in Clauses 9-10 with respect to the connections
and other diagrammatic relationships between graphical elements. Where
permitted or required connections are specified as conditional and based on
attributes of the corresponding concepts, the implementation shall ensure the
correspondence between the connections and the values of those attributes.
In general, these connections and relationships have specified semantic
interpretations, which specify interactions among the process concepts
represented by the graphical elements. Conditional relationships based on
attributes represent specific variations in behavior. Structural conformance
therefore guarantees the correct interpretation of the diagram as a specification
of process, in terms of flows of control and information.
Throughout the document, structural specifications will be appear in paragraphs
using a special shaped bullet: ..
Example: .. A Task MAY be a target for Sequence Flow; it can have multiple
incoming Flows. An Incoming Flow MAY be from an alternative path
and/or a parallel paths.
2.3 Semantic Elements
This specification defines many semantic concepts used in defining processes,
and associates them with graphical elements, markers, and connections. To the
extent that an implementation provides an interpretation of the BPMN diagram as
a semantic specification of process, the interpretation shall be consistent with the
semantic interpretation herein specified.
Note -- The intent here is that a BPMN diagram used as a "workflow
specification" will have the interpretation specified in this standard, somewhat
extended or narrowed by the characteristics of the workflow system. Similarly,
when a BPMN diagram used as a specification for the processes and interactions
of software agents, any generated software will reflect the semantics of the
diagram as specified in this standard, possibly narrowed or extended by the
characteristics of the software implementation.
2.4 Attributes and Properties
This specification defines a number of attributes and properties of the semantic
objects represented by the graphical elements, markers, and connections. Some
of these attributes are purely representational and are so marked, and some
have required representations. Some attributes are specified as mandatory, but
have no representation or only optional representation. And some attributes are
specified as optional.
For every attribute or property that is specified as mandatory, a conforming
implementation SHALL provide some mechanism by which values of that
attribute or property can be created and displayed. This mechanism SHALL
permit the user to create or view these values for each BPMN object specified to
have that attribute or property.
Where a graphical representation for that attribute or property is specified as
required, that graphical representation SHALL be used.
Where a graphical representation for that attribute or property is specified as
optional, the implementation MAY use either a graphical representation or some
other mechanism. If a graphical representation is used, it SHALL be the
representation specified.
Where no graphical representation for that attribute or property is specified, the
implementation MAY use either a graphical representation or some other
mechanism. If a graphical representation is used, it SHALL NOT conflict with the
specified graphical representation of any other BPMN object.
2.5 Extended and Optional Elements A conforming implementation is not required to support any element or attribute
that is specified herein to be non-normative or informative.
In each instance in which this specification defines a feature to be "optional", it
specifies whether the option is in:
o how the feature shall be displayed,
o whether the feature shall be displayed
o whether the feature shall be supported.
A conforming implementation is not required to support any feature whose
support is specified to be optional. If an implementation supports an optional
feature, it SHALL support it as specified.
A conforming implementation SHALL support any "optional" feature for which the
option is only in whether or how it shall be displayed."
Section 6.2, page 6:
c) Change the heading to heading level 3 (i.e., make Section 6.1.1)
d) Rename the heading to: "Abbreviations"
e) Delete the first paragraph of the section.
Actions taken:
January 30, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Section 2 of the specification will be updated to clarify the conformance for BPEL
and more general conformance considerations.
Issue 9320: Irrelevant conformance point (bpmn-ftf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary: The Conformance section (2) has 3 points: 3rd of these is somewhat inoperative since it refers to a to-be-defined interchange format.
Resolution:
Revised Text:
Actions taken:
January 30, 2006: received issue
April 19, 2007: closed issue
Discussion: See issue 9319 for disposition
Issue 9321: compliance level to cover core elements/simple business modeling (bpmn-ftf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary: 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."
Resolution:
Revised Text:
Actions taken:
January 30, 2006: received issue
April 19, 2007: closed issue
Discussion: See issue 9319 for disposition
Issue 9322: BPEL over-pervasive in document (bpmn-ftf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution:
Revised Text:
Actions taken:
January 30, 2006: received issue
April 19, 2007: closed issue
Discussion: See issue 9319 for disposition
Issue 9323: BPEL mapping hard to follow (bpmn-ftf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution:
Revised Text:
Actions taken:
January 30, 2006: received issue
April 19, 2007: closed issue
Discussion: See issue 9139 for disposition
Issue 9324: No means to define Categories (bpmn-ftf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: Section 8.1, Table 8.2, seventh row ("Group"), page 17 and Section 8.2, Table
8.3, first row on page ("Group"), page 26:
a) First column: replace text with "Group (a box around a group of objects within
the same category)"
b) Second column: replace text with "A grouping of activities that are within the
same category (“Group” on page XX). This type of grouping does not affect the
Sequence Flow of the activities within the group. The category name appears on
the diagram as the group label. Categories can be used for documentation or
analysis purposes. Groups are one way in which categories of objects can be
visually displayed on the diagram."
Section 9.1, Table 9.2, second row ("Categories"), page 33 and Section B.3,
Table B.3, second row ("Categories"), page 243--this section change for Issue
9377:
c) First column: Change Categories type from "String" to "Category"
d) Second column: replace text with "The modeler MAY add one or more defined
Categories, which have user-defined semantics, and that can be used for purposes such as reporting and analysis. The details of Catogories is defined in
“Category” on page XXX."
Section 9.7.4 "Group," page 95
e) Replace first paragraph with: "The Group object is an Artifact that provides a
visual mechanism to group elements of a diagram informally. The grouping is tied
to the Category supporting element (which is an attribute of all BPMN elements).
That is, a Group is a visual depiction of a single Category. The graphical
elements within the Group will be assigned the Category of the Group. (Note --
Categories can be highlighted through other mechanisms, such as color, as
defined by a modeler or a modeling tool)."
Section 9.7.4 "Group," Table 9.38, page 97 and Section B.9.4, Table B.36, page
265:
f) Replace row 1 with the following:
CategoryRef :
Category
CategoryRef specifies the Category that the Group represents (Further
details about the definition of a Category can be found in “Category
on page XXX.”).
The name of the Category provides the label for the Group. The
graphical elements within the boundaries of the Group will be
assigned the Category.
g) Append the following row to Table 9.38, page 97:
GraphicalElements
(0-n) : Graphical
Element
The GraphicalElements attribute identifies all of the graphical
elements (e.g., Events, Activities, Gateways, and Artifacts) that
are within the boundaries of the Group.
Section B.11.1, page 268:
h) Add new Section of B.11.1 with the section title: "Category"
i) Add a paragraph after the title: "The following table displays the set of attributes
of a Category, which is used in the definition of attributes for all BPMN elements,
and which extends the set of common BPMN element attributes (see Table B.2).
Since a Category is also a BPMN element, a Category can have Categories to
create a hierarchical structure of Categories."
Add a new Table that has the following contents:
j) The table title should be: "Category Attributes"
k) The table should be:
Attributes Description
Name :
String
Name is an attribute that is text description of the Category and is used to
visually distinguish the category.
Actions taken:
January 30, 2006: received issue
April 19, 2007: closed issue
Discussion: 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
Issue 9325: Ambiguous notations for Association (bpmn-ftf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary: Table 8.1: does not explain the difference between the 2 depictions of Associations given (one with an arrow)
Resolution:
Revised Text: Section 8.1, Table 8.2, page 17, third row ("Association"), second column
("Description"), append the paragraph:
a) "An arrowhead on the Association indicates a direction of flow (e.g., data),
when appropriate ("Association" on page XX)."
More generally...
Section 8.1, Table 8.2, page 16, first row ("Event"), second column
("Description"), modify the first sentence:
b) "An event is something that “happens” during the course of a business
process ("Events" on page XX)."
Note that the page number is dynamic and dependent on the final layout of the
specification.
Section 8.1, Table 8.2, page 16, second row ("Activity"), second column
("Description"), modify the first sentence:
c) "An activity is a generic term for work that company performs ("Activities" on
page XX)."
Section 8.1, Table 8.2, page 16, third row ("Gateway"), second column
("Description"), modify the first sentence: d) "A Gateway is used to control the divergence and convergence of Sequence
Flow ("Gateways" on page XX)."
Section 8.1, Table 8.2, page 17, first row ("Sequence Flow"), second column
("Description"), modify the first sentence:
e) "A Sequence Flow is used to show the order that activities will be performed in
a Process ("Sequence Flow" on page XX)."
Section 8.1, Table 8.2, page 17, second row ("Message Flow"), second column
("Description"), modify the first sentence:
f) "A Message Flow is used to show the flow of messages between two
participants that are prepared to send and receive them ("Message Flow" on
page XX)."
Section 8.1, Table 8.2, page 17, fourth row ("Pool"), second column
("Description"), modify the first sentence:
g) "A Pool represents a Participant in a Process ("Pool" on page XX)."
Section 8.1, Table 8.2, page 17, fifth row ("Lane"), second column
("Description"), modify the first sentence:
h) "A Lane is a sub-partition within a Pool and will extend the entire length of the
Pool, either vertically or horizontally ("Lane" on page XX)."
Section 8.1, Table 8.2, page 17, sixth row ("Data Object"), second column
("Description"), modify the first sentence:
i) "... they do provide information about what activities require to be performed
and/or what they produce ("Data Object" on page XX)."
Section 8.1, Table 8.2, page 17, seventh row ("Group"), second column
("Description"), modify the first sentence:
j) "A grouping of activities that does not affect the Sequence Flow ("Group" on
page XX)."
Section 8.1, Table 8.2, page 17, last row ("Text Annotation"), second column
("Description"), modify the first sentence:
k) "Text Annotations are a mechanism for a modeler to provide additional
information for the reader of a BPMN Diagram ("Text Annotation" on page XX)."
Section 8.2, Table 8.3, page 18, first row ("Event"), second column
("Description"), modify the first sentence:
l) "An event is something that “happens” during the course of a business process
("Events" on page XX)." Section 8.2, Table 8.3, page 18, second row ("Flow Dimension"), second column
("Description"),
modify the first sentence of the first paragraph:
m) "As the name implies, the Start Event indicates where a particular process will
start ("Start" on page XX)."
modify the first sentence of the second paragraph:
n) "Intermediate Events occur between a Start Event and an End Event
("Intermediate" on page XX)."
modify the first sentence of the third paragraph:
o) "As the name implies, the End Event indicates where a process will end ("End"
on page XX)."
Section 8.2, Table 8.3, page 19, first row ("Type Dimension"), second column
("Description"),
modify the first sentence of the first paragraph:
p) "Start and most Intermediate Events have “Triggers” that define the cause for
the event (“Start” on page 35 and “Intermediate” on page XX)."
modify the third sentence of the first paragraph:
q) "End Events may define a “Result” that is a consequence of a Sequence Flow
ending (“End” on page XX)."
Section 8.2, Table 8.3, page 19, second row ("Task"), second column
("Description"), modify the first sentence:
r) "A Task is an atomic activity that is included within a Process (“Task” on page
XX)"
Section 8.2, Table 8.3, page 19, third row ("Process/Sub-Process"), second
column ("Description"), modify the first sentence:
s) "A Sub-Process is a compound activity that is included within a Process (“Sub-
Process” on page XX)"
Section 8.2, Table 8.3, page 19, fourth row ("Collapsed Sub-Process"), second
column ("Description"), modify the first sentence:
t) "A Sub-Process is a compound activity that is included within a Process (“Sub-
Process” on page XX)"
Section 8.2, Table 8.3, page 19, fifth row ("Expanded Sub-Process"), second
column ("Description"), modify the first sentence: u) "The boundary of the Sub-Process is expanded and the details (a Process)
are visible within its boundary (“Sub-Process” on page XX)"
Section 8.2, Table 8.3, page 20, first row ("Gateway"), second column
("Description"), modify the first sentence:
v) "A Gateway is used to control the divergence and convergence of multiple
Sequence Flow (“Gateways” on page XX)"
Section 8.2, Table 8.3, page 20, second row ("Gateway Control Types"), second
column ("Description"),
modify the second sentence of the first bullet:
w) "Both Data-Based (“Data-Based” on page XX) and Event-Based (“Event-
Based” on page XX)"
modify the first sentence of the second bullet:
x) "OR -- inclusive decision and merging (“Inclusive Gateways (OR)” on page
XX)."
modify the first sentence of the third bullet:
y) "Complex -- complex conditions and situations (e.g., 3 out of 5; “Complex
Gateways” on page XX)."
modify the first sentence of the fourth bullet:
z) "AND -- forking and joining (“Parallel Gateways (AND)” on page XX)."
Section 8.2, Table 8.3, page 20, third row ("Sequence Flow"), second column
("Description"), modify the first sentence:
aa) "A Sequence Flow is used to show the order that activities will be performed
in a Process (“Sequence Flow” on page XX)"
Section 8.2, Table 8.3, page 20, fourth row ("Normal Flow"), second column
("Description"), modify the first sentence:
bb) "...and continues through activities via alternative and parallel paths until it
ends at an End Event (“Normal Flow” on page XX)"
Section 8.2, Table 8.3, page 20, last row ("Uncontrolled Flow"), second column
("Description"), modify the first sentence:
cc) "Uncontrolled flow refers to flow that is not affected by any conditions or does
not pass through a Gateway (“Gateways” on page XX)"
Section 8.2, Table 8.3, page 21, first row ("Conditional Flow"), second column
("Description"), modify the first sentence: dd) "Sequence Flow can have condition expressions that are evaluated at
runtime to determine whether or not the flow will be used (“Sequence Flow” on
page XX)"
Section 8.2, Table 8.3, page 21, second row ("Default Flow"), second column
("Description"), modify the first sentence:
ee) "For Data-Based Exclusive Decisions or Inclusive Decisions, one type of flow
is the Default condition flow (“Sequence Flow” on page XX)"
Section 8.2, Table 8.3, page 21, third row ("Exception Flow"), second column
("Description"), modify the first sentence:
ff) "...and is based upon an Intermediate Event that occurs during the
performance of the Process (“Exception Flow” on page XX)"
Section 8.2, Table 8.3, page 21, fourth row ("Message Flow"), second column
("Description"), modify the first sentence:
gg) "A Message Flow is used to show the flow of messages between two entities
that are prepared to send and receive them (“Message Flow” on page XX)"
Section 8.2, Table 8.3, page 21, last row ("Compensation Association"), second
column ("Description"), modify the first sentence:
hh) "that is triggered through the failure of a Transaction or a Compensate Event
(“Compensation Association” on page XX)"
Section 8.2, Table 8.3, page 22, first row ("Data Object"), second column
("Description"), modify the first sentence:
ii) "...they do provide information about what activities require to be performed
and/or what they produce (“Data Object” on page XX)"
Section 8.2, Table 8.3, page 22, second row ("Fork (AND-Split)"), second column
("Description"), modify the first sentence:
jj) "BPMN uses the term “fork” to refer to the dividing of a path into two or more
parallel paths (also known as an AND-Split; “Forking Flow” on page XX)"
Section 8.2, Table 8.3, page 22, third row ("Join (AND-Join)"), second column
("Description"), modify the first sentence:
kk) "BPMN uses the term “join” to refer to the combining of two or more parallel
paths into one path (also known as an AND-Join or synchronization; “Joining
Flow” on page XX)"
Section 8.2, Table 8.3, page 22, fourth row ("Decision, Branching Point; (ORSplit)"),
second column ("Description"), modify the first sentence: ll) "Decisions are Gateways within a business process where the flow of control
can take one or more alternative paths (“Exclusive Gateways (XOR)” on page
XX)"
Section 8.2, Table 8.3, page 22, last row ("Exclusive"), second column
("Description"), modify the first sentence:
mm) "An Exclusive Gateway (XOR) restricts the flow such that only one of a set
of alternatives may be chosen during runtime (“Exclusive Gateways (XOR)” on
page XX)"
Section 8.2, Table 8.3, page 23, first row ("Data-Based"), second column
("Description"), modify the first sentence:
nn) "...where Alternatives are based on conditional expressions contained within
the outgoing Sequence Flow (“Data-Based” on page XX)"
Section 8.2, Table 8.3, page 23, last row ("Event-Based"), second column
("Description"), modify the first sentence:
oo) "...where Alternatives are based on an Event that occurs at that point in the
Process (“Event-Based” on page XX)"
Section 8.2, Table 8.3, page 24, first row ("Inclusive"), second column
("Description"), modify the first sentence:
pp) "...where Alternatives are based on conditional expressions contained within
the outgoing Sequence Flow (“Inclusive Gateways (OR)” on page XX)"
Section 8.2, Table 8.3, page 24, second row ("Merging (OR-Join)"), second
column ("Description"), modify the first sentence:
qq) "...the exclusive combining of two or more paths into one path (also known as
an a OR-Join; “Merging Flow” on page XX)"
Section 8.2, Table 8.3, page 24, last row ("Activity Looping"), second column
("Description"), modify the first sentence:
rr) "The attributes of Tasks and Sub-Processes will determine if they are
repeated or performed once (“Looping” on page XX)"
Section 8.2, Table 8.3, page 25, first row ("Sequence Flow Looping"), second
column ("Description"), modify the first sentence:
ss) "Loops can be created by connecting a Sequence Flow to an “upstream”
object (“Looping” on page XX)"
Section 8.2, Table 8.3, page 25, second row ("Multiple Instances"), second
column ("Description"), modify the first sentence: tt) "The attributes of Tasks and Sub-Processes will determine if they are repeated
or performed once (“Looping” on page XX)"
Section 8.2, Table 8.3, page 25, third row ("Process Break"), second column
("Description"), modify the first sentence:
uu) "A Process Break is a location in the Process that shows where an expected
delay will occur within a Process (“Intermediate” on page XX)"
Section 8.2, Table 8.3, page 25, fourth row ("Transaction"), second column
("Description"), modify the first sentence:
vv) "a special protocol (e.g., WS-Transaction) that insures that all parties involved
have complete agreement that the activity should be completed or cancelled
(“Sub-Process Behavior as a Transaction” on page XX)"
Section 8.2, Table 8.3, page 25, last row ("Nested/Embedded Sub-Process"),
second column ("Description"), modify the first sentence:
ww) "A nested (or embedded) Sub-Process is an activity that shares the same
set of data as its parent process (“Embedded Sub-Process” on page XX)"
Section 8.2, Table 8.3, page 26, first row ("Group"), second column
("Description"), modify the first sentence:
xx) "A grouping of activities that does not affect the Sequence Flow (“Group” on
page XX)"
Section 8.2, Table 8.3, page 26, second row ("Off-Page Connector"), second
column ("Description"), modify the first sentence:
yy) "...will show where the Sequence Flow leaves one page and then restarts on
the next page (“Sequence Flow Jumping (Off-Page Connectors and Go To
Objects)” on page XX)"
Section 8.2, Table 8.3, page 26, third row ("Association"), second column
("Description"), modify the first sentence:
zz) "An Association is used to associate information with Flow Objects
(“Association” on page XX)"
Section 8.2, Table 8.3, page 26, fourth row ("Text Annotation"), second column
("Description"), modify the first sentence:
aaa) "Text Annotations are a mechanism for a modeler to provide additional
information for the reader of a BPMN Diagram (“Text Annotation” on page XX)"
Section 8.2, Table 8.3, page 26, fifth row ("Pool"), second column ("Description"),
modify the first sentence:
bbb) "A Pool represents a Participant in a Process (“Pool” on page XX)" Section 8.2, Table 8.3, page 26, last row ("Lanes"), second column
("Description"), modify the first sentence:
ccc) "...will extend the entire length of the Pool, either vertically or horizontally
(“Lane” on page XX)"
Actions taken:
April 19, 2007: closed issue
Discussion: 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.
Issue 9326: Unclear semantics of Group (bpmn-ftf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary: Table 8.1: unclear if a Group groups Activities or objects in general. Can it have a name?
Resolution:
Revised Text:
Actions taken:
January 30, 2006: received issue
April 19, 2007: closed issue
Discussion: 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
Issue 9327: Ambiguous notations for OR (bpmn-ftf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary: Why 2 notations for Data based XOR
Why not data and event options for inclusive OR?
Resolution:
Revised Text: Section 9.5.2, Sub-Section "Data-Based," page 72, Add a Note paragraph after
Figure 9.17:
"Note - The “X” internal indicator for the Data-Based Exclusive Gateway was
included in BPMN to complete the set of indicators for the different types of
Gateways (see Figure 9.15). However, it is also understood that most modelers
would be familiar with an empty decision diamond that represents an exclusive
branching of the process and that most decisions would probably take this form.
Thus, Data-Based Exclusive Gateway internal indicator was made optional so
that modelers and modeling tools could create diagrams that would conform with
the basic flow expectations of modelers."
Actions taken:
January 30, 2006: received issue
April 19, 2007: closed issue
Discussion: 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.
Issue 9343: complicated notation (bpmn-ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: 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
Resolution:
Revised Text:
Actions taken:
January 31, 2006: received issue
April 19, 2007: closed issue
Discussion: 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
Issue 9345: unclear what Figure 13 on p. 71 represents (bpmn-ftf)
Click here for this issue's archive.
Source: Embarcadero Technologies (Ms. Donna Burbank, donna.burbank@embarcadero.com)
Nature: Clarification
Severity: Minor
Summary: 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:
Revised Text: Figure 9.10 will be replaced by the following Figure:
Actions taken:
February 1, 2006: receivrd issue
April 19, 2007: closed issue
Discussion: 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 9353: Which is it, (OR-Join) or (XOR) Gateway? (bpmn-ftf)
Click here for this issue's archive.
Source: Capability Measurement (Mr. Karl Frank, Karl.Frank@ngc.com karl.frank@ngc.com karl.karolus@gmail.com karl.frank@capabilitymeasurement.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution:
Revised Text: Section 8.2, Table 8.3, page 20, second row ("Gateway Control Types"):
a) Third Column: replace figure with figure below:
b) Second Column, first bullet: Remove "XOR -- " from the begriming of the
sentence. Capitalize the "E" in "Exclusive" c) Second Column, second bullet: Remove "OR -- " from the begriming of the
sentence. Capitalize the "I" in "Inclusive"
d) Second Column, fourth bullet: Replace "AND -- " from the begriming of the
sentence with "Parallel ."
Section 8.2, Table 8.3, page 22, second row ("Fork (AND-Split)"):
e) First Column: Remove "(AND-Split)" from the sentence.
f) second Column, fourth paragraph: Remove "(AND)" from the sentence. Thus,
the beginning of the sentence should read "A Parallel Gateway is..."
Section 8.2, Table 8.3, page 22, third row ("Join (AND-Join)"):
g) First Column: Remove "(AND-Join)" from the sentence.
h) second Column, second paragraph: Remove "(AND)" from the sentence.
Thus, the beginning of the sentence should read "A Parallel Gateway is..."
Section 8.2, Table 8.3, page 22, fourth row ("Decision, Branching Point; (ORSplit)"):
i) First Column: Remove "; (OR-Split)" from the sentence.
Section 8.2, Table 8.3, page 22, last row ("Exclusive"):
j) Second Column: Remove "(XOR)" from the first sentence.
Section 8.2, Table 8.3, page 24, first row ("Inclusive"):
k) Second Column: Replace "OR" with "Inclusive" in the sentence.
l) Second Column: Remove "usually in combination with other Gateways" from
the first sentence.
Section 8.2, Table 8.3, page 24, second row ("Merging (OR-Join)"):
m) First Column: Remove "(OR-Join)" from the sentence.
n) Second Column: Replace "(XOR)" with "Exclusive" in the second paragraph.
Section 9.3.2, page 36, second to last paragraph:
o) Remove "(AND-Split)" from the second sentence.
Section 9.4.2, Sub-Section "Sub-Process Behavior as a Transaction," page 61,
forth to last paragraph (above the last two bullets):
p) Remove "(AND-Split)" from the second sentence. Section 9.4.3, Sub-Section "Sequence Flow Connections," page 68, first
paragraph:
q) Remove "(AND-Split)" from the second sentence.
Section 9.5, page 69, second paragraph:
r) Remove "OR-Split;" and "--XOR" and "--OR" and "(OR-Join)" and "(AND-Split)"
and "(AND-Join)" from the first sentence.
s) Replace Figure 9.15 with the following figure:
Section 9.5.1, Table 9.25, page 70, first row and Section B.7.1, Table B.24, page
257, first row:
t) First Column: Replace "XOR" with "Exclusive" in the sentence. This is done
twice.
u) First Column: Replace "OR" with "Inclusive" in the sentence.
v) First Column: Replace "AND" with "Parallel" in the sentence.
w) Second Column: Replace "XOR" with "Exclusive" in the sentence.
x) Second Column: Replace "OR" with "Inclusive" in the sentence.
y) Second Column: Replace "AND" with "Parallel" in the sentence.
Section 9.5.2, page 71, section title and Section B.7.2, page 256, section title:
z) Remove "(XOR)" from the title.
Section 9.5.2, Sub-Section "Data-Based," page 74, second paragraph and
Section B.7.2, Sub-Section "Data-Based," page 258, first paragraph: aa) Replace "XOR" with "Exclusive" in the second sentence.
Section 9.5.2, Sub-Section "Data-Based," Table 9.26, page 74, first row and
Section B.7.2, Sub-Section "Data-Based," Table B.25, page 258, first row:
bb) First Column: Replace "XORType" with "ExclusiveType" in the sentence.
cc) Second Column: Replace "XORType" with "ExclusiveType" in the first and
second sentences. Replace "XOR" with "Exclusive" in the third sentence.
Section 9.5.2, Sub-Section "Data-Based," Table 9.26, page 74, second row and
Section B.7.2, Sub-Section "Data-Based," Table B.25, page 258, first row:
dd) Second Column: Replace "XOR" with "Exclusive" in the third sentence.
Section 9.5.2, Sub-Section "Event-Based," page 77, first paragraph after the set
of bullets and Section B.7.2, Sub-Section "Event-Based," page 259, first
paragraph:
ee) Replace "XOR" with "Exclusive" in the second sentence.
Section 9.5.2, Sub-Section "Event-Based," Table 9.27, page 77, first row and
Section B.7.2, Sub-Section "Event-Based," Table B.26, page 259, first row:
ff) First Column: Replace "XORType" with "ExclusiveType" in the sentence.
gg) Second Column: Replace "XORType" with "ExclusiveType" in the first and
second sentences. Replace "XOR" with "Exclusive" in the third sentence.
Section 9.5.3, page 78, section title and Section B.7.3, page 259, section title:
hh) Remove "(OR)" from the title.
Section 9.5.3, page 79, fifth from the last paragraph (interior bullet):
ii) Replace "AND (Parallel)" with "Parallel" in the first sentence.
Section 9.5.3, page 79, second from last paragraph (before the last bullet) and
Section B.7.3, page 259, first paragraph:
jj) Replace "OR" with "Inclusive" in the first sentence.
Section 9.5.3, page 80, caption for Figure 9.24:
kk) Replace "OR" with "Inclusive" in the caption.
Section 9.5.3, page 80, second paragraph:
ll) Remove "OR " three times in the paragraph.
Section 9.5.3, page 81, first paragraph: mm) Replace "OR" with "Inclusive" in the caption.
Section 9.5.5, page 85, section title and Section B.7.5, page 262, section title:
nn) Remove "(AND)" from the title.
Section 9.5.5, page 86, first paragraph and Section B.7.5, page 262, first
paragraph:
oo) Replace "AND (Parallel)" with "Parallel" in the first sentence.
Section 10.2.1, page 108, first paragraph (continuing from previous page):
pp) Remove last sentence., which is "In addition, we will relate these BPMN
terms to the terms OR-Split (for split), Or-Join (for merge), AND-Split (for fork),
and AND-Join (for join), as defined by the Workflow Management Coalition."
Section 10.2.1, Sub-Section "Splitting Flow," page 117:
qq) Replace Figure 10.29 with the following figure
Section 11.6.2, Sub-Section "Data-Based," Table 11.39, page 172, first row:
rr) First Column: Replace "XOR" with "Exclusive" and Replace "XORType" with
"ExclusiveType" in the sentence.
ss) Second Column: Replace "XORType" with "ExclusiveType" in the first and
second sentences. Replace "XOR" with "Exclusive" in the third sentence.
Section 11.6.2, Sub-Section "Event-Based," Table 11.40, page 173, first row:
tt) First Column: Replace "XOR" with "Exclusive" and Replace "XORType" with
"ExclusiveType" in the sentence.
uu) Second Column: Replace "XORType" with "ExclusiveType" in the first and
second sentences. Replace "XOR" with "Exclusive" in the third sentence. Section 11.6.3, Table 11.41, page 173, first row:
vv) First Column: Replace "OR" with "Inclusive" in the sentence.
Section 11.6.5, Table 11.42, page 178, first row:
ww) First Column: Replace "AND" with "Parallel" in the sentence.
Section C, Sub-Section "D," item "Deferred Choice," page 276:
xx) Replace "XOR-" with "exclusive" in the paragraph.
yy) Replace "AND-Split" with "fork" in the paragraph.
Section C, Sub-Section "M," item "Merge," page 278:
zz) Replace "XOR" with "Exclusive" in the paragraph.
Actions taken:
February 2, 2006: received issue
April 19, 2007: closed issue
Discussion: The specification will modified to remove all references to terms such as OR,
XOR, AND, etc.
Issue 9354: Are there 3 or are there 4 Standard Artifacts? (bpmn-ftf)
Click here for this issue's archive.
Source: Capability Measurement (Mr. Karl Frank, Karl.Frank@ngc.com karl.frank@ngc.com karl.karolus@gmail.com karl.frank@capabilitymeasurement.com)
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution:
Revised Text:
Actions taken:
February 2, 2006: received issue
April 19, 2007: closed issue
Discussion: 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
Issue 9356: Is it really the Complete Set? (bpmn-ftf)
Click here for this issue's archive.
Source: Capability Measurement (Mr. Karl Frank, Karl.Frank@ngc.com karl.frank@ngc.com karl.karolus@gmail.com karl.frank@capabilitymeasurement.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: Section 8.2, page 18: a) Change the section title to "BPD Extended Set"
Section 8.2, page 18, Table 8.3:
b) Change the table title to "BPD Extended Set"
Actions taken:
February 2, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
A more accurate name for Section 8.2 and Table 8.3 would be "BPD Extended
Element Set."
Issue 9361: Section: 4.6 (bpmn-ftf)
Click here for this issue's archive.
Source: Embarcadero Technologies (Ms. Donna Burbank, donna.burbank@embarcadero.com)
Nature: Revision
Severity: Significant
Summary: 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:
Revised Text: Section 9.6.2, page 90, Table 9.33, row 4 (Lanes), column 2: remove the second
and third sentence.
Actions taken:
February 14, 2006: received issue
April 19, 2007: closed issue
Discussion: 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.
Issue 9367: BPMN Adopted Spec issue - Clarify behavior of Error intermediate event (bpmn-ftf)
Click here for this issue's archive.
Source: iGrafx (Mr. Rob Bartel, rob.bartel@igrafx.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: Section 9.3.3 "End," page 41, Table 9.6:
a) Third row, second column: Replace current text with: "This type of End
indicates that a named Error should be generated. The Error will be caught by
the Error intermediate event with the same ErrorCode or no ErrorCode which is
on the boundary of the nearest enclosing parent activity (hierarchically). The
behavior of the process is unspecified if no parent activity has such an Error
intermediate event. The system executing the process may define additional
Error handling in this case, a common one being termination of the process
instance."
Section 9.3.4 "Intermediate," page 45, Table 9.8: Fourth row, second column:
b) Delete the first two sentences.
c) Change the first word of the next sentence from "It" to "This"
Section 9.3.4 "Intermediate," page 46, Table 9.9 and Section B.5.4, page 248,
Table B.8:
Row on page for "Error Code," second column:
d) Delete the first two sentences. Note, this description will be moved for the
proposal to resolved Issue 9377. The description will be in a new table for the
Error Event Detail. But the same two sentences will be deleted.
Section 9.3.4 "Intermediate":
Page 47, Last Bullet item on page:
e) Delete the text ", Error" (was ", Exception") from the first sentence.
f) Replace the text ", and Multiple" with the text ", Error, and Multiple" in the
second sentence.
Page 48, Second Bullet item on page:
g) Delete the text ", Error" from the first sentence.
Section 9.5.2 "Exclusive Gateways," subsection "Event-Based," page 76, first
paragraph (continued from previous page):
h) Delete the text " and Errors" from the end of the last sentence.
Section 10.2.2 "Exception Flow," page 131, first paragraph after Figure 10.53:
i) Append the paragraph with the text "An exception to this is the Error event,
which will only respond to Error triggers generated within the activity or in a
subprocess of that activity"
Actions taken:
February 21, 2006: received issue
April 19, 2007: closed issue
Discussion: 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.
Issue 9377: optional description attribute (bpmn-ftf)
Click here for this issue's archive.
Source: Sandpiper Software, Inc. (Dr. Francis G. McCabe, frankmccabe@mac.com)
Nature: Enhancement
Severity: Significant
Summary: 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:
Revised Text: Set up the Elements so that there is a high-level BPMN Element element so
that both graphical and supporting objects share the same basic attributes,
which are id, category, and documentation:
Create the BPMN Element element:
Section 9.1 "Common Graphical Object Attributes," page 33 and Section B.3
"Common Graphical Object Attributes," page 243:
a) Change the section title to:"Common BPMN Element Attributes." For Annex B,
change the heading level to level 3
b) Change the first sentence of the section to:"The following table displays a set
of common attributes for BPMN Elements (Graphical Elements and Supporting
Elements)."
c) Change the table title to:"Common BPMN Element Attributes"
d) for Section 9.1: add the following paragraph after the table: "These attributes
are used for Flow Objects (Section 9.2, “Common Flow Object Attributes,” on
page XX), Connecting Objects (Section 10.1, “Graphical Connecting Objects,” on
page XX), Swimlanes (Section 9.6, “Swimlanes (Pools and Lanes),” on page
XX), Artifacts (Section 9.7, “Artifacts,” on page XX), and Supporting Elements
(Section B.11, “Supporting Elements,” on page XXX)."
e) For Section B.3: add the following paragraph after the table: "These attributes
are used for Flow Objects (Section B.4, “Common Flow Object Attributes,” on
page XXX), Connecting Objects (Section B.10, “Graphical Connecting Objects,”
on page XXX), Swimlanes (Section B.8, “Swimlanes (Pools and Lanes),” on page
XXX), Artifacts (Section B.9, “Artifacts,” on page XXX), and Supporting Elements
(Section B.11, “Supporting Elements,” on page XXX)." Section 9.2 "Common Flow Object Attributes," page 33 and Section B.4
"Common Flow Object Attributes," page 244 and Section 9.6.1 "Common
Swimlane Attributes," page 87 and Section B.8.1 "Common Swimlane Attributes,"
page 262 and Section 9.7.1 "Common Artifact Attributes," page 92 and Section
B.9.1 "Common Artifact Attributes," page 264 and Section 10.1.1 "Common
Connecting Object Attributes," page 99 and Section B.10.1 "Common
Connecting Object Attributes," page 265:
f) At the end of the first sentence of the section, change: "common graphical
object attributes" to "common BPMN element attributes"
Define the elements that now inherit the common BPMN Element attributes:
Section 8.6.1 "Attributes," page 30 and Section B.2 "Process Attributes," page
242 and Section B.11.1 "Assignment," page 268 and Section B.11.2 "Entity,"
page 268 and Section B.11.3 "Expression," page 269 and Section B.11.4 (new
section) "Input," page 269 and Section B.11.5 (was B.11.4) "Message," page 269
and Section B.11.7 (new section) "Output," page 269 and Section B.11.8 (was
B.11.6) "Participant," page 270 and Section B.11.9 (was B.11.7) "Property," page
270 and Section B.11.10 (was B.11.8) "Role," page 270 and Section B.11.11
(was B.11.9) "Rule," page 271 and Section B.11.13 (was B.11.10) "Transaction,"
page 271 and Section B.11.14 (was B.11.11) "Web Service ," page 271:
g) Append the end of the first sentence of the section with: ", and which extends
the set of common BPMN element attributes (see Table B.2)"
Since Processes now inherit BPMN Element attributes, three attributes can be
removed:
Section 8.6 "Processes," Table 8.7, page 30 and Section B.2 "Process
Attributes," Table B.2, page 242:
h) Remove the first row of the Table ("Id")
i) Remove the last two rows of the Table ("Categories" and "Documentation")
Clean up the order of things:
j) Switch the order of Sections B.2 and B.3
Other changes:
Annex B, prior to Section B.1, after the first paragraph:
k) Add the following sentence after the section title:"The following figure displays
a diagram of the relationship between the main BPMN Event elements and their
attributes (see Figure B.1). Other diagrams in this Annex will provide more
detailed information about specific groups of elements (e.g, Events and their
related elements and attributes)." l) Add the following figure after the above sentence:
m) Add the following figure title after the figure: "Figure B.1 - Main BPMN
Elements and Attributes"
Set up the restructuring of Events so that Triggers and Results are defined
as an EventDetail, which is a Supporting Element:
Change Triggers and Results to be of type EventDetail:
Section 9.3.2 "Start," Table 9.5, page 38 and Section B.5.2, Table B.6, page 245:
n) Remove all the rows except the first row (they will be placed somewhere else) o) Replace the first row with the following:
Trigger (0-n) :
EventDetail
Trigger (EventDetail) is an attribute that defines the type of trigger
expected for a Start Event. Of the set of EventDetailTypes (see
Section 9.3.5, “Event Details,” on page XX), only four (4) can be
applied to a Start Event: Message, Timer, Rule, and Link (see Table
9.4).
If there is no EventDetail is defined, then this is considered a None
End Event and the Event will not have an internal marker (see Table
9.4).
If there is more than one EventDetail is defined, this is considered a
Multiple End Event and the Event will have the star internal marker
(see Table 9.4).
Section 9.3.3 "End," Table 9.7, page 42 and Section B.5.3, Table B.7, page 246:
p) Remove all the rows except the first row (they will be placed somewhere else)
q) Replace the first row with the following:
Result (0-n) :
EventDetail
Result (EventDetail) is an attribute that defines the type of result
expected for an End Event. Of the set of EventDetailTypes (see
Section 9.3.5, “Event Details,” on page XX), only six (6) can be
applied to an End Event: Message, Error, Cancel, Compensation,
Link, and Terminate (see Table 9.6).
If there is no EventDetail is defined, then this is considered a None
End Event and the Event will not have an internal marker (see Table
9.6).
If there is more than one EventDetail is defined, this is considered a
Multiple End Event and the Event will have the star internal marker
(see Table 9.6).
Section 9.3.4 "Intermediate," Table 9.9, page 46 and Section B.5.3, Table B.8,
page 247:
r) Remove all the rows except the first two rows (they will be placed somewhere
else)
s) Second row, first column: replace "Object" with "Activity"
t) Replace the first row with the following:
Trigger (0-n) :
EventDetail
Trigger (EventDetail) is an attribute that defines the type of trigger
expected for an Intermediate Event. Of the set of EventDetailTypes
(see Section 9.3.5, “Event Details,” on page XX), only seven (7) can
be applied to an Intermediate Event: Message, Timer, Error, Cancel,
Compensation, Rule, and Link. (see Table 9.8).
If there is no EventDetail is defined, then this is considered a None
Intermediate Event and the Event will not have an internal marker (see Table 9.8).
If there is more than one EventDetail is defined, this is considered a
Multiple Intermediate Event and the Event will have the star internal
marker (see Table 9.8).
Set up a new Event Details section in Section 9.3
Section 9.3, after sub-section 9.3.4:
u) Add new Header level 3 Section (9.3.5) with the following title: "Event Details"
v) Add a paragraph after the section title: "Event Details refers to the Triggers of
Start and Intermediate Events and the Results of End Events. The types of Event
Details are: Message, Timer, Error, Cancel, Compensation, Rule, Link, and
Terminate. A None Event is determined by an Event that does not specify an
Event Detail. A Multiple Event is determined by an Event that specifies more than
one Event Detail. The different types of Events, (Start, Intermediate, and End)
utilize a subset of the available types of Event Details (see Figure 9.5)."
w) add a figure after the above paragraph:
x) add a figure caption for the above figure: "Event Details as Applied to Start,
Intermediate, and End Events"
y) add a paragraph below the above figure caption: "The following sections will
present the attributes common to all Event Details and the specific attributes for the Event Details that have additional attributes. Note that the Cancel and
Terminate Event Details do not have additional attributes."
z) add new subsection: "Common Event Detail Attributes"
aa) add new paragaph in section: "The following table displays the set of
attributes common to the types of EventDetail, and which extends the set of
common BPMN element attributes (see Table 9.1)."
bb) add a table caption for the table below: "Common Event Detail Attributes"
cc) Add the following table:
Attributes Description
EventDetailType
(Message | Timer
| Error | Rule |
Link |
Compensate |
Cancel |
Terminate)
Message : String
The EventDetailType attribute defines the type of trigger expected for
an Event. The set of types includes Message, Timer, Error, Rule,
Link, Compensate, Cancel, and Terminate. The EventTypes (Start,
Intermediate, and End) will each have a subset of the
EventDetailTypes that can be used.
The EventDetailType list MAY be extended to include new types.
These new types MAY have a new modeler- or tool-defined Marker
to fit within the boundaries of the Event.
dd) add new subsection: "Compensation Event Detail"
ee) add new paragaph in section: "The following table displays the set of
attributes a Compensation Event Detail, and which extends the set of common
Event Detail attributes (see Table 9.10)."
ff) add a table caption for the table below: "Compensation Event Detail Attributes"
gg) Add the following table:
Attributes Description
ActivityRef :
Activity
For an End Event:
If the Result is a Compensation, then the Activity that needs to be
compensated MUST be supplied.
For an Intermediate Event within Normal Flow:
If the Trigger is a Compensation, then the Activity that needs to be
compensated MUST be supplied. This “throws” the compensation.
For an Intermediate Event attached to the boundary of an Activity:
This Event “catches” the compensation. No further information is
required. The Activity the Event is attached to will provide the Id
necessary to match the compensation event with the event that
“threw” the compensation.
hh) add new subsection: "Error Event Detail" ii) add new paragaph in section: "The following table displays the set of attributes
a Error Event Detail, and which extends the set of common Event Detail
attributes (see Table 9.10)."
kk) add a table caption for the table below: "Error Event Detail Attributes"
ll) Add the following table:
Attributes Description
ErrorCode :
String
For an End Event:
If the Result is an Error, then the ErrorCode MUST be supplied.This
“throws” the error.
For an Intermediate Event within Normal Flow:
If the Trigger is an Error, then the ErrorCode MUST be entered. This
“throws” the error.
For an Intermediate Event attached to the boundary of an Activity:
If the Trigger is an Error, then the ErrorCode MAY be entered. This
Event “catches” the error. If there is no ErrorCode, then any error
SHALL trigger the Event. If there is an ErrorCode, then only an error
that matches the ErrorCode SHALL trigger the Event.
mm) add new subsection: "Link Event Detail"
nn) add new paragaph in section: "The following table displays the set of
attributes a Link Event Detail, and which extends the set of common Event Detail
attributes (see Table 9.10)."
oo) add a table caption for the table below: "Link Event Detail Attributes"
pp) Add the following table:
Attributes Description
LinkId : String If the Trigger is a Link, then the LinkId MUST be entered.
ProcessRef :
Process
If the Trigger is a Link, then the ProcessRef MUST be entered. The
identified Process MAY be the same Process as that of the Link
Event.
qq) add new subsection: "Message Event Detail"
rr) add new paragaph in section: "The following table displays the set of attributes
a Message Event Detail, and which extends the set of common Event Detail
attributes (see Table 9.10)."
ss) add a table caption for the table below: "Message Event Detail Attributes"
tt) Add the following table:
Attributes Description
MessageRef : If the EventDetailType is a MessageRef, then the a Message MUST Message be supplied. The attributes of a Message can be found in Section
B.11.8, “Message,” on page XXX.
Implementation
(Web Service |
Other |
Unspecified) Web
Service
This attribute specifies the technology that will be used to send or
receive the message. A Web service is the default technology.
uu) add new subsection: "Rule Event Detail"
vv) add new paragaph in section: "The following table displays the set of
attributes a Rule Event Detail, and which extends the set of common Event Detail
attributes (see Table 9.10)."
ww) add a table caption for the table below: "Rule Event Detail Attributes"
xx) Add the following table:
Attributes Description
RuleName : Rule If the Trigger is a Rule, then a Rule MUST be entered. The attributes
of a Rule can be found in Section B.11.14, “Rule,” on page XXX.
yy) add new subsection: "Timer Event Detail"
zz) add new paragaph in section: "The following table displays the set of
attributes a Timer Event Detail, and which extends the set of common Event
Detail attributes (see Table 9.10)."
aaa) add a table caption for the table below: "Timer Event Detail Attributes"
bbb) Add the following table:
Attributes Description
TimeDate (0-1) :
TimeDateExpression
If the Trigger is a Timer, then a TimeDate MAY be entered. If a
TimeDate is not entered, then a TimeCycle MUST be entered (see
the attribute below). The attributes of a TimeDateExpression can be
found in Section B.11.15, “TimeDateExpression,” on page XXX.
TimeCycle (0-1) :
TimeDateExpression
If the Trigger is a Timer, then a TimeCycle MAY be entered. If a
TimeCycle is not entered, then a TimeDate MUST be entered (see
the attribute above).
Set up the Event Details section in Annex B, which is basically the same as in
Section 9:
Section B.11, after sub-section B.11.2:
ccc) Add new Header level 3 Section (B.11.3) with the following title: "Event
Details" ddd) add a paragraph in the section: "The following sections will present the
attributes common to all Event Details and the specific attributes for the Event
Details that have additional attributes. Note that the Cancel and Terminate Event
Details do not have additional attributes."
fff) add all the Event Detail Sections as defined above, except define references
to tables within Annex B
Other Changes:
Section B.5 "Events":
ggg) Add the following sentence after the section title:"The following figure
displays a diagram of the relationship between BPMN Event elements and their
attributes (see Figure B.X)."
hhh) Add the following figure after the above sentence: iii) Add the following figure title after the figure: "Figure B.X - BPMN Event
Elements and Attributes"
Set up the restructuring of Gateways so that Gates are now a Supporting
Element:
The Common Gateway attributes should also include the Gates attribute, so
Section 9.5.1 "Common Gateway Features," page 70, Table 9.25 and Section
B.7.1 "Common Gateway Attributes," page 257, Table B.24
jjj) Add the following row at the end of the table:
Gates (0-
n) : Gate
There MAY be zero or more Gates (except where noted below). Zero Gates
are allowed if the Gateway is last object in a Process flow and there are no
Start or End Events for the Process. If there are zero or only one incoming Sequence Flow, then there MUST be at
least two Gates.
For Exclusive Data-Based Gateways
When two Gates are required, one of them MAY be the DefaultGate.
For Exclusive Event-Based Gateways
There MUST be two or more Gates. (Note that this type of Gateway does not
act only as a Merge--it is always a Decision, at least.)
For Inclusive Gateways
When two Gates are required, one of them MAY be the DefaultGate.
Section B.7.2 "Exclusive Gateways," page 258, Table B.25 and Section 9.5.2,
page 74, Table 9.26:
kkk) Remove rows 3 through 5 ("Gates," "Outgoing Sequence Flow," and
"Assignments")
lll) Remove the last two rows ("Outgoing Sequence Flow," and "Assignments")
mmm) Second column in remaining third row: append sentence with: "(see
Section B.11.6, “Gate,” on page XXX [Section "Gates" on page XX])"
Section B.7.2 "Exclusive Gateways," page 259, Table B.26 and Section 9.5.2,
page 77, Table 9.27:
nnn) Remove the last three rows ("Gates," "Outgoing Sequence Flow," and
"Assignments")
Section B.7.3 "Inclusive Gateways," page 260, Table B.27 and Section 9.5.3,
page 81, Table 9.28:
ooo) Remove the first three rows ("Gates," "Outgoing Sequence Flow," and
"Assignments")
ppp) Remove the last two rows ("Outgoing Sequence Flow," and "Assignments")
qqq) Second column in remaining row: append sentence with: "(see Section
B.11.6, “Gate,” on page XXX [Section "Gates" on page XX])"
Section B.7.4 "Complex Gateways," page 261, Table B.28 and Section 9.5.4,
page 81, Table 9.29:
rrr) Remove the first three rows ("Gates," "Outgoing Sequence Flow," and
"Assignments")
Section B.7.5 "Parallel Gateways," page 260, Table B.29 and Section 9.5.5, page
86, Table 9.30:
sss) Remove entire Table (there are no additional attributes) ttt) Replace paragraph in section with: "Parallel Gateways do not have any
additional Attributes beyond the common Gateway Attributes (see Table B.24
[Table 9.31]).
Section 9.5.1 "Common Gateway Features," page 70, after the "Message Flow
Connections" subsection
uuu) add new subsection: "Gates"
vvv) add new paragaph in section: "The following table displays the attributes of
Gates, and which extends the set of common BPMN element attributes (see
Table 9.1)"
www) add a table caption for the table below: "Gate Attributes"
yyy) Add the following table:
Attributes Description
OutgoingSequenceFlow
: SequenceFlow
Each Gate MUST have an associated Sequence Flow. The
attributes of a Sequence Flow can be found in the Section
10.1.2, “Sequence Flow,” on page XXX.
For Exclusive Event-Based, Complex, and Parallel Gateways:
The Sequence Flow MUST have its Condition attribute set to
None (there is not an evaluation of a condition expression).
For Exclusive Data-Based, and Inclusive Gateways:
The Sequence Flow MUST have its Condition attribute set to
Expression and MUST have a valid ConditionExpression. The
ConditionExpression MUST be unique for all the Gates within
the Gateway. If there is only one Gate (i.e., the Gateway is
acting only as a Merge), then Sequence Flow MUST have its
Condition set to None.
For DefaultGates:
The Sequence Flow MUST have its Condition attribute set to
Otherwise
Assigments (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 are defined in the Section
B.11.1, “Assignment,” on page XXX.
Section B.11 "Supporting Elements," page 269, after the B.11.3 "Expression"
section
zzz) Add new section: "Gate"
aaaa) Add the same paragraph, Table caption, and Table as shown above
(adjust the references to Annex B)
Other Changes: Section B.7 "Gateways":
bbbb) Add the following sentence after the section title:"The following figure
displays a diagram of the relationship between BPMN Gateway elements and
their attributes (see Figure B.X)."
cccc) Add the following figure after the above sentence:
dddd) Add the following figure title after the figure: "Figure B.X - BPMN Gateway
Elements and Attributes"
Add Model Diagrams to sections of Annex B:
Section B.6 "Activities":
eeee) Add the following sentence after the section title:"The following figure
displays a diagram of the relationship between BPMN activity elements and their
attributes (see Figure B.X)."
ffff) Add the following figure after the above sentence: gggg) Add the following figure title after the figure: "Figure B.X - BPMN Activity
Elements and Attributes"
Section B.8 "Swimlanes":
hhhh) Add the following sentence after the section title:"The following figure
displays a diagram of the relationship between BPMN Swimlane elements and
their attributes (see Figure B.X)."
iiii) Add the following figure after the above sentence: jjjj) Add the following figure title after the figure: "Figure B.X - BPMN Swimlane
Elements and Attributes"
Section B.9 "Artifacts":
kkkk) Add the following sentence after the section title:"The following figure
displays a diagram of the relationship between BPMN Artifacts elements and
their attributes (see Figure B.X)."
llll) Add the following figure after the above sentence: mmmm) Add the following figure title after the figure: "Figure B.X - BPMN Artifact
Elements and Attributes"
Section B.10 "Connecting Objects":
nnnn) Add the following sentence after the section title:"The following figure
displays a diagram of the relationship between BPMN Connecting Objects
elements and their attributes (see Figure B.X)."
oooo) Add the following figure after the above sentence: pppp) Add the following figure title after the figure: "Figure B.X - BPMN
Connecting Objects Elements and Attributes"
Section B.11"Supporting Types":
qqqq) Change the section title to:"Supporting Elements"
rrrr) Add the following sentence after the section title:"The following figure
displays a diagram of the relationship between BPMN Supporting elements and
their attributes (see Figure B.X)."
ssss) Add the following figure after the above sentence: tttt) Add the following figure title after the figure: "Figure B.X - BPMN Supporting
Elements and Attributes" Add Graphical Element section to Annex B:
Section B.2.1"Common BPMN Element Attributes":
uuuu) Add a heading level 2 prior to this section with the title: "BPMN Elements"
vvvv) Add a headling level 3 after this section with the title: "Graphical Elements"
wwww) Add a new paragraph after this section: "Graphical Element is one of two
main elements that are of type BPMN Element (see Figure B.1). The other is
Supporting Element. There are four main types, and many subtypes, of Graphical
Elements. These are: These are: Artifacts (see Section B.9, “Artifacts,” on page
XXX), Connecting Objects (see Section B.10, “Graphical Connecting Objects,” on
page XXX), Flow Objects (see Section B.4, “Common Flow Object Attributes,” on
page XXX), and Swimlanes (see Section B.8, “Swimlanes (Pools and Lanes),” on
page XXX)"
xxxx) Add a headling level 3 after this section with the title: "Supporting
Elements"
yyyy) Add a new paragraph after this section: "Supporting Element (see Section
B.11, “Supporting Elements,” on page XXX) is one of two main elements that are
of type BPMN Element (see Figure B.1). The other is Graphical Element."
Section B.11 "Supporting Elements":
zzzz) Add a new paragraph prior to the first paragraph: "Supporting Element is
one of two main elements that are of type BPMN Element (see Figure B.1). The
other is Graphical Element. There are 16 types, and a few subtypes, of Support
Element. These are: These are: Assignments (see Section B.11.1, “Assignment,”
on page XXX), Categories (see Section B.11.2, “Category,” on page XXX),
Entities (see Section B.11.3, “Entity,” on page XXX), Event Details (see Section
B.11.4, “Event Details,” on page XXX), Expressions (see Section B.11.5,
“Expression,” on page XXX), Gates (see Section B.11.6, “Gate,” on page XXX),
Inputs (see Section B.11.7, “Input,” on page XXX), Messages (see Section
B.11.8, “Message,” on page XXX), Outputs (see Section B.11.10, “Output,” on
page XXX), Participants (see Section B.11.11, “Participant,” on page XXX),
Processes (see Section B.3, “Process Attributes,” on page XXX), Properties (see
Section B.11.12, “Property,” on page XXX), Roles (see Section B.11.13, “Role,”
on page 281), Rules (see Section B.11.14, “Rule,” on page XXX), Transactions
(see Section B.11.16, “Transaction,” on page XXX), and Web Services (see
Section B.11.17, “Web Service,” on page XXX)."
Update Connecting Object Attributes:
Section 10.1.1 "Common Connecting Object Attributes," Table 10.1 and Section
B.10.1, Table B.37:
aaaaa) Second row, first column: Change "Object" to "Graphical Element" bbbbb) Second row, second column: Change "Flow Object" to "Graphical
Element"
ccccc) Third row, first column: Change "Object" to "Graphical Element"
ddddd) Third row, second column: Change "Flow Object" to "Graphical Element"
Actions taken:
February 23, 2006: received issue
April 19, 2007: closed issue
Discussion: 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.
Issue 9378: restriction to be placed on the number of tokens (bpmn-ftf)
Click here for this issue's archive.
Source: Sandpiper Software, Inc. (Dr. Francis G. McCabe, frankmccabe@mac.com)
Nature: Clarification
Severity: Significant
Summary: 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.
Resolution:
Revised Text:
Actions taken:
February 23, 2006: received issue
April 19, 2007: closed issue
Discussion: 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
Issue 9408: Clarify why BPMN separates data and sequence (bpmn-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
Nature: Clarification
Severity: Significant
Summary: 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:
Revised Text: Figure 10.11 will be replaced
Actions taken:
March 2, 2006: received issue
April 19, 2007: closed issue
Discussion: Resolution:
Figure 10.11 will be changed to better show the separation of Data and
Sequence.
Issue 9409: Diagram with an "Invisible Pool" (bpmn-ftf)
Click here for this issue's archive.
Source: Embarcadero Technologies (Ms. Michelle Vanchu-Orosco, michelle.vanchu-orosco@embarcadero.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text: Section 9.6.2, page 87, After first bullet, add new bullet item (two indent levels):
a) "One, and only one, Pool in a diagram MAY be presented without a boundary.
If there is more than one Pool in the diagram, then the remaining Pools MUST
have a boundary."
Section 9.6.2, page 89, first paragraph:
b) Replace Second sentence with: "In most cases, a BPD that consists of a
single Pool will only display the activities of the Process and not display the
boundaries of the Pool."
c) Third sentence: Replace "Furthermore, many BPDs may show..." with
"Furthermore, a BPD may show..." at the beginning of the sentence.
d) Add the following sentence after the third sentence: "In such cases there can
be, at most, only one invisibly-bounded pool in the diagram and the name of that
pool SHALL be the same as the diagram."
e) Last sentence: Replace "That is, " with "Consequently" at the beginning of the
sentence. Replace "...may not be surrounded..." with "...need not be surrounded..." in the middle of the sentence. Replace "...in the Diagram will have
their boundary." with "...in the Diagram must have their boundary." at the end of
the sentence.
Section 9.6.3, first paragraph, add sentence after the first sentence:
f) "If the pool is invisibly bounded, the lane associated with the pool must extend
the entire length of the pool."
Actions taken:
March 2, 2006: received issue
April 19, 2007: closed issue
Discussion: 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).
Issue 9411: Section 12 of the specification should be moved as is to an appendix (bpmn-ftf)
Click here for this issue's archive.
Source: International Business Machines (Dr. Stephen White, wstephe@us.ibm.com sawscape@gmail.com)
Nature: Uncategorized Issue
Severity:
Summary: 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:
Revised Text:
Actions taken:
March 3, 2006: received issue
April 19, 2007: closed issue
Discussion: 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.
Issue 9412: Section 4.3.3 Reference to "missing" shape (bpmn-ftf)
Click here for this issue's archive.
Source: Embarcadero Technologies (Ms. Michelle Vanchu-Orosco, michelle.vanchu-orosco@embarcadero.com)
Nature: Uncategorized Issue
Severity:
Summary: 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 sh