Business Process Model and Notation Avatar
  1. OMG Specification

Business Process Model and Notation — All Issues

  • Acronym: BPMN
  • Issues Count: 743
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
BPMN21-443 Ad-Hoc Sub-Process falsely listed as BPMN 2.0.2 open
BPMN21-442 second instance of BPMN 2.0 open
BPMN2-318 Mistake in Table 7.2 BPMN 2.0.2 open
BPMN21-441 Wrong word used. And wrong page reference BPMN 2.0 open
BPMN21-440 fairly basic errors in some of your example flows BPMN 2.0.1 open
BPMN21-439 Description for "Mutiple Instances" is not correct. BPMN 2.0.1 open
BPMN21-438 The returning message flow to the "Ask Developer" Manual Task BPMN 2.0 open
BPMN21-437 No correct validation rules mentioned BPMN 2.0.2 open
BPMN21-436 Clarify the possible catchers of error and escalation events BPMN 2.0.2 open
BPMN21-435 wrong word for parallel multi instance in description BPMN 2.0.2 open
BPMN21-434 Mismatch between text and table BPMN 2.0 open
BPMN21-433 All None Start Events should get a token at instantiation, if the Top-level Process or Global Process (or even Sub-Process) contains multiple Non Start Events BPMN 2.0.2 open
BPMN21-432 Confusing definition of LinkEventDefinition's fields "sources" and "target" BPMN 2.0.2 open
BPMN21-431 Page directs you to see itself BPMN 2.0 open
BPMN21-430 Addition of Blockchain Element BPMN 2.0 open
BPMN21-429 FlowNode.outgoing [0..*] should be an ordered set BPMN 2.0 open
BPMN21-428 Incorrect description of inheritance BPMN 2.0 open
BPMN21-427 Please clarify if the usage of a XOR Join is not redundant BPMN 2.0.2 open
BPMN21-426 Is there a definite reason to exist for a XOR join gateway? BPMN 2.0.2 open
BPMN2-317 Event list seems to be not complete BPMN 2.0.2 open
BPMN2-316 Misprint in call activity view BPMN 2.0.2 open
BPMN2-315 Different explanation and example. BPMN 2.0.2 open
BPMN21-425 Example uses invalid DI attributes and wrong namespaces BPMN 2.0.2 open
BPMN21-167 Pages 312-457. Nonexistent attribute “compensable” mentioned BPMN 2.0 open
BPMN11-95 Contradiction about process data input and output allowed connection with data association BPMN 2.0 open
BPMN21-424 Inclusive Gateway - circular cross-reference BPMN 2.0 open
BPMN21-423 Typo: Sequential for Parallel BPMN 2.0 open
BPMN21-422 Typo: Outgoing for Incoming BPMN 2.0 open
BPMN21-421 "Flow Object" should be "Flow Node" BPMN 2.0.2 open
BPMN21-420 Typo: BPMN 2.0.2 open
BPMN21-419 Typo in example BPMN 2.0.2 open
BPMN21-418 Diagram 8.1 looks amateurish BPMN 2.0.2 open
BPMN21-417 Wrong sub-section reference numbers BPMN 2.0.2 open
BPMN21-416 tDefinitions should have an extensionElements Element like in CMOF BaseElement BPMN 2.0 open
BPMN21-415 Inconsistent BPMNShape Attributes in tables BPMN 2.0.2 open
BPMN21-414 Typos - Incorrect internal references/pointers BPMN 2.0.1 open
BPMN21-413 Inconsistent semantics of multiple none start events BPMN 2.0.2 open
BPMN21-412 Attribute called BPMN 2.0.2 open
BPMN21-411 Relationship relates CMOF::Element, not Artifact BPMN 2.0.2 open
BPMN21-410 Unclear how to add new Artifact Types BPMN 2.0.2 open
BPMN21-409 Derivation of categorizedFlowElements is only given by visual nesting BPMN 2.0.2 open
BPMN21-371 Artifact used as an example for FlowElement BPMN 2.0 open
BPMN21-181 Page 72. Artifact incorrectly identified as a Flow Element BPMN 2.0 open
BPMN21-408 Some of the descriptions in the bpmnElement column of the table are incorrect BPMN 2.0.2 open
BPMN21-407 Incorrect table column header BPMN 2.0 open
BPMN21-406 Add start and intermediate events of type "User" BPMN 2.0.2 open
BPMN21-405 Outgoing sequence flows from event gateways should allow conditional expressions BPMN 2.0.2 open
BPMN21-403 Probable contradiction: Implicit compensation and Throwing Compensation Events BPMN 2.0.2 open
BPMN21-404 Define "Cancellation" more precisely BPMN 2.0.2 open
BPMN21-402 Intermediate Compensation Events can have outgoing Sequence Flows BPMN 2.0.2 open
BPMN21-401 Wrong Word - Says "sequential", Should Say "parallel" BPMN 2.0 open
BPMN12-35 Execution semantics of Activity with conditional outgoing Sequence Flows BPMN 2.0.2 open
BPMN21-400 p.172 Reference pointing to wrong figure, p.174/175 Event marker missing in figure BPMN 2.0.2 open
BPMN21-399 Inconsistent default value of dataStore/@isUnlimited BPMN 2.0.2 open
BPMN21-398 Clarification needed regarding converging exclusive gateway and slash marker BPMN 2.0.2 open
BPMN21-397 Task Description -- Internal Conflict BPMN 2.0.2 open
BPMN21-396 Missing Element in BPMN 2.0.2 ? BPMN 2.0b1 open
BPMN21-395 Sequential and Parallel multiple instances are have same description BPMN 2.0 open
BPMN21-394 data storage element is missing in overview BPMN 2.0.2 open
BPMN21-393 Confusion over dataOutput attributes BPMN 2.0.2 open
BPMN21-392 Multiple Instances - Both types of diagram described as Sequential BPMN 2.0b1 open
BPMN21-391 Unclear execution semantics of MI activities with complex behavior BPMN 2.0b1 open
BPMN21-390 Table 8.51 ref error BPMN 2.0b1 open
BPMN21-389 Wrong table reference number BPMN 2.0.2 open
BPMN21-388 Contradiction - can or cannot show Data Object multiple times on a diagram BPMN 2.0b1 open
BPMN21-387 Wrong table reference number BPMN 2.0b1 open
BPMN21-386 Wrong table reference number BPMN 2.0b1 open
BPMN21-384 Wrong table reference number BPMN 2.0b1 open
BPMN21-385 Wrong name of object BPMN 2.0b1 open
BPMN21-383 Attribute name "error" should actually by "errorRef" BPMN 2.0b1 open
BPMN21-382 Figure 10.57 does not show that InputOutputSpecification derives from BaseElement BPMN 2.0b1 open
BPMN21-381 Default value of DataStore.isUnlimited differs between Table 10.55 and XML Schema BPMN 2.0b1 open
BPMN21-380 message and error ref in tOperation does not define the correct type name BPMN 2.0 open
BPMN21-379 Wrong clause reference BPMN 2.0 open
BPMN21-377 Table 7.2 wrong reference to type of multi-instance BPMN 2.0 open
BPMN2-301 Text User Task instead of Manual Task BPMN 2.0 BPMN 2.0.1 Resolved closed
BPMN2-300 Page 345. “Sub-Choreographies” instead of “Choreography Activities” BPMN 2.0 BPMN 2.0.1 Resolved closed
BPMN2-299 None Events not for catch Intermediate Event BPMN 2.0 BPMN 2.0.1 Resolved closed
BPMN2-298 Conditional Event instead of Error Event BPMN 2.0 BPMN 2.0.1 Resolved closed
BPMN2-297 Page 181. Wrong reference to table 10.20 BPMN 2.0 BPMN 2.0.1 Resolved closed
BPMN2-296 Conflicting content regarding choreographies. BPMN 2.0b1 BPMN 2.0 Closed; No Change closed
BPMN2-295 Page 203, Table 10-26, MultiInstance Activity: What is the intended use case if the catching boudnary event is interrupt BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-246 BPMN CMOF File problems BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-245 Mutiple depictions of a single semantic element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-244 Depictable element without a reference semantic element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-249 The example provided in Figure 10-22 and its serilization in Table 10-19 are incorrect or at least misleading BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-248 Add an attribute that can identify a rulebase/rule engine for Business Rule Task BPMN 2.0b1 BPMN 2.0 Closed; No Change closed
BPMN2-247 Confusing semantics for Terminate End Event BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-237 Ambiguity when multiple message flows associated with a choreography task BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-251 ResourceParameter::type attribute should be of type ItemDefinition, not Element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-250 Parallel Event Based Gateway capability is hidden away BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-239 Inconsistent/confusing statements around CallActivities and IOSpecifications BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-243 Table 10-4 page 162 List of possible states of an Activity instance BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-242 Clarify "Instance of this Conversation." BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-241 Change plural "flow" to "flows" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-240 Correlation key property values from process instances BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-252 Clarification of Temporal Sematics of Sequence Flow BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-238 Exclusive Gateway (missing sub-heading) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-273 For DI: All graphical elements should have a Semantic Counterpart BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-272 Review the use of RFC2119 keywords BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-277 Rename "Call" Elements BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-276 XML Schema is not strict enough BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-282 Missing loopCharacteristics for Choreography stuff in MM BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-281 Figure 12-21, Sub-process marker missing BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-280 Mismatch in DataAssociation definition between spec and XSD BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-279 Receive Task is not mentioned as an instantiating element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-278 Merge Collaboration and Choreography in Metamodel BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-284 Missing in XML example BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-283 Missing label of a compensation activity BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-286 Missing marker in Compensation Activity BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-285 Process Model and Model Description are not consistent BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-274 Allow referencing scripts instead of enfocing inline specification BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-275 How to reference particular instances of Data Objects that are Collections BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-271 Choreography should be a Sub-Class of Collaboration BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-270 Additional participants in called/subconversation BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-261 Hexagons and message flow linked to activities BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-260 For Process within Collaboration, section 9.3 title is wrong and section 10.11 is empty BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-264 Data Objects should be defined with the same pattern a Data Stores and DataStoreRefs BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-263 Correlation on message flow and choreography activities BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-262 Label call conversation links BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-257 LaneSet should have an optional ‘name’ attribute BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-256 Simplify Use of Callable Elements BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-266 No way to identify the format of Documentation and TextAnnotation connect BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-265 Extending via inheritancy is problematic using the BPMN xsd format BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-259 How to represent Process Diagrams and Lanes? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-258 Figure 10.121 mis-described BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-254 CorrelationKey should be a concrete element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-253 Required definitions to invoke an existing function by means of a service task BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-268 Add Attribute Table for Global Task BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-267 Incorrect attribute name used for Start Event definition BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-269 Contradictory/redundant handing of data and subprocesses BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-255 DataInputs, DataOuputs, and DataStores should be FlowElements BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-291 Missing definition of the participant Buyer BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-290 Exporter Information Required for BPMN 2 files BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-289 Inclusive Gateway Semantics BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-288 Missing Message Flow BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-287 Choreography is not enforcable BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-294 The Two Multi-Instance Markers should be reversed BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-293 A Collaboration should be able to reference more than one Choreography BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-292 Conversation lanes BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-236 INCORRECT/IMCOMPLETE REFERENCES AND DEFINITIONS IN GLOSSARY BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-153 parallelMultiple attribute missing from CatchEvent table BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-152 CorrelationSubscription - Description & use-cases BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-154 The Category section has incorrect/inconsistent content BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-157 V0.9.7: Section 10 Process: Add ProcessResource Attribute to Process BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-156 Notation for supports association BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-151 XML-Schema type for 'from' and 'to' elements in Data Assignment must not be abstract BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-150 XSD: mixed="true" is redundant in tFormalExpression element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-149 Multiple PartnerEntities per Participant BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-160 Beta 1 Section 12.4 Choreography Activities: Fix redundancy in the definition of these elements BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-159 Beta 1 Section 2.2 Process Execution Conformance: Describe this conformance apart from Process Modeling Conformance BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-158 Use "item" terminology more uniformly BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-148 Service Task => Operation Task BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-155 Editorial: Incorrect containment statement for EventDefinitions BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-110 Misleading copy/paste para regarding Properties BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-102 URL referenced for WfMC Gloassary is incorrect BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-101 Definition of Participant Band Shadings not clear BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-108 Missing DataStore from the enumeration of item-awre elements at top of the page BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-107 Merge Conversation and Collaboration BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-100 Variable Id TO Variation Id BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-106 Conversation Muddle BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-105 Correlation on Choregraphy BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-104 Typo in Section 7.2 paragraph 1 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-109 Missing details regarding the visualisation of a DataState for a DataObject BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-103 URL referenced for XPDL specification is incorrect BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-143 Need to revisit and test the process example in the spec (Figure 7-8) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-142 Service Package => Interface Package BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-147 Lanes and Sequence Flow BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-146 Grouping message flow in Collaboration BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-137 CorrelationSubscription Ownership BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-138 Semantic metamodel => Abstract syntax BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-144 Error class has no 'name' attribute BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-140 Conversation/Communication switch BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-141 Choreography Subprocess => Subchoreography BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-145 Typo in Terminate Event description BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-139 MessageFlowRefs missing from Conversation metamodel diagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-117 Beta 1 Section 11 Conversation: BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-116 Private process example correction BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-112 Multiple properties / keys clarification BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-115 isImmediate default BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-114 Subprocess / CallActivity switch BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-123 Processes supporting interactions BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-122 Private process type BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-118 Complex gateway merging rule in choreography too restrictive BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-121 Conversation/Process switch BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-113 Key-based Correlation => ? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-120 Correlation Class Diagram missing Process association BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-119 Promote correlationKeys association to ConversationContainer BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-220 Cardinality of the "sourceRef" association between DataAssociation and ItemAwareElement BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-219 Unclear/contradictory handling of visualized Data Inputs/Outputs BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-218 Data Inputs/Outputs on Subprocesses BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-213 Can a sub-process (embedded) have Lanes? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-212 Section 10.2.3 ScriptTask.scriptLanguage needs to specify format BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-215 Section 12.4.1 [Choreo] How many message flows per choreography task? Missing meta-model BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-214 Section 8.3.15 [Choreo] ParticipantMultiplicity must allow to specify 1..2, possibly also 0..1 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-211 Section 10.5.1/10.5.6 Need to clarify how initiating gateway is specifed: via sequence flow, attribute, or both BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-217 Formalizing the Source-Target relationships between Link Intermediate Event BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-216 Allow Choreographies within a Conversation Diagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-210 General [Metamodel] Double-check attributes that are enumerated types, and their extensibility needs BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-209 Section 9.2: Pool description needs revisiting BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-221 Data Inputs the target of multiple Data Associations BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-208 Default execution semantics for an activity with multiple incoming branches needs to be clarified BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-133 Are Conditional Start Events executable? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-132 Contradiction in constraint for Start Events in Event Subprocess BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-129 Error vs ErrorCode & Escalation vs EscalationCode BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-125 Choreography Complex Gateway example BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-124 Exclusive gateways in choreography cover splitting but not merging BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-128 Fix difference between MessageFlowNode definition in specification vs the semantic.xmi file BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-127 Meaning of + symbol on Communication undefined BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-131 Mention of "isInterrupting" attribute still in the spec BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-130 Incorrect description for the Transaction.protocol attribute BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-135 Section 11 Conversation: Fix Conversation figures for proper notation for Pools BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-136 Merge Conversation and Collaboration BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-134 Correlation Key & Correlation Properties are missing 'name' attributes BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-126 isClosed on Conversation BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-230 Property name mismatch between Spec and Schema for Item Definition BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-229 "isInterrupting" attribute of Start Events BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-224 Event marker quality is poor BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-223 Persistent versus transient event trigger BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-232 Reference ProcessRef missing in Figure 8.40 - The Participant Class Diagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-231 The Message element structureRef association should be renamed to itemRef BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-234 Execution semantics for Data Objects and Properties must be enhanced to properly describe concurrent modification situat BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-233 Does CallChoreography need a MessageFlowAssociation? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-226 Called conversations without keys of the caller BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-228 Allow Overlapping Matrix Construction of Lanes in a Diagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-227 Order of outgoing sequence flows from exclusive gateway BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-222 The description of operationRef is not accurate BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-235 Visibility and permissions for Data Objects and Properties must be described BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-225 Confusion about Performers and other roles that Resources play for Activities BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-203 Generalize message flow BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-202 Semantics for data flow without sequence flow BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-201 Enabling multiple events at the same time for the same message BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-197 Annex D Glossary [Specification]: Update Glossary BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-200 Section 10.3.1 [Data-MM]: Events can contain properties but the relationship is not shown in the MM diagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-199 Business Rule Task description doesn't describe purpose (section 10.2.3, Beta 1) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-198 Tasks vs Global Tasks BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-196 Section 8.1.5 [Infra] Import statement description is not clear enough BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-195 Section 2 Conformance [Specification]: Explicitly define BPMN compliance criteria, with focus on "model" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-205 Section 10.2.8 [Execution Semantics] Loops: Loop names misleading BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-204 Reuse of processes in orchestration and choreography BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-192 Pools multiplicity BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-191 [Meta-model] Exclusive gateway is missing specification of order of leaving sequence flows BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-190 Diagram Interchange should align with Diagram Type Definition BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-207 Section 10.2.5: Sub-Process: Figure 10.25; Add a minus sign to the bottom of an expanded Sub-Process? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-206 Section 8.2.1 [Service Model] How to model a request-reply use case? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-194 Data flow in/out of events BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-193 Beta 1: Section 10.3.1 Data Objects [Data]: Change Multiplicity of datastate attribute from 0..1 to 0..* BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-187 Beta 1: Is a Message a DataInput for an Activity; Is Message Flow a Data Association BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-186 Beta 1 [Section 12.1.2] - Use of the term "BPMN" in class names BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-185 Beta 1 [Section 12.1.2] - OrchestrationDiagram should be called ProcessDiagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-184 Relationship navigation (both in MM and XSD) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-183 Beta 1: Section 10.2 Activities: Reference Task and Sub-Process from BPMN 1.1 not in BPMN 2.0 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-176 Global Task should have performer, Call Activity should have capability to overwrite performer BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-182 Aliases for imported definitions BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-181 Beta 1: Section 10.2 Activities: Move User Task Instance Attributes to the higher level Activity element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-189 [Section 10.2.3] Editorial BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-188 [Section 10.6] Editorial: We need more explicit descriptions of Compensation behaviour regarding scopes BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-180 Add business-level presentation attributes to user task: subject and description BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-179 Data Association should be specialized from Association BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-175 Editorial: Rename FlowElement::categoryValue to ::categoryValueRef BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-174 Data Assignment 'from' and 'to' should be formal expressions BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-177 [XSD] Documentation and ScriptTask (and probably expressions) should be stored as CData elements and not String attribut BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-178 Lanes should be described in Process section BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-169 Beta 1: Section 10.4.5 Handling Events: When does the interrupting Event Sub-Process cancel its Parent? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-168 TimerEventDefinition: clarification of the expected result of the timeCycle and timeDate expressions BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-167 Correlation properties must have name and type (was dropped in 4/22 XSD and MM) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-166 tActivityResource::resourceRef should be optional BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-165 Section 10.3.1 Data Inputs and Outputs: Schema change: change minOccurs of inputSet for ioSpecification from 0 to 1 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-172 Beta 1: Set the name attribute of DataInputs and DataOutputs to optional BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-171 V0.9.9.1: Display of Messages and Associations in Choreography BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-164 XSD DataAssociation should own source and target refs and mistake in text spec BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-163 DataAssociations: How do we support literals? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-162 Metaelement missing for DI to show connection between ChoreographyActivity to Message BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-170 Beta 1: Section 10.4 Events: Statement "Signals are triggers generated in the Pool they are published" needs clarificati BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-173 XSD: Data Association sourceRef and targetRef should be of type QName BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-161 Beta 1 Section 13.2.4 ChoreographyActivityShape: Add Choreography Activity Bands to DI model BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-98 logic error in the PDF document BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-97 Target namespace mismatch between the XML Schemas in the spec (PDF) and the XML Schemas files (XSD) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-95 Clarification on relationship between MEP and Choreography Task in BPMN2 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-94 Initiating message flow for ChoreographyTask BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-92 Page 160, Figure 10-6 vs. Table 10-3. The "property" class is not depicted in the class diagram Figure 10-6 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-91 Page 161, Table 10-3, Error in attribute name. "resources" should be "activityResource" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-93 Page 161, Table 10-3, Issues regarding properties in the Activity attribute table BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-96 Allow Choreography Task to have more than 2 Participants BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-3 The case of some attribute name is not consistent. BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-2 Typos BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-1 Conformance Classes are overley Broad BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-6 Page 052, Table 7-2, Wrong figure of all event possibilities BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-5 Page 227 Table 10-56 the attributes optionalOutput and whileExecutingOuput are wrongly typed DataInput BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-4 Page 199 class model for the global tasks BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-8 Page 029, Section 2.1.3 Usage of normal bullets vs diamond shape to indicate structural specifications BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-7 Page 199, Figure 10-40 Types of Global Task (Text,Class Diagram and Schema do not match) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-9 Page 044, Figure 7-3, Pool names not separated from content by a single line BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-21 Page 044, Figure 7-4, The initiating party is wrongly identified in the figure BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-20 Page 395, Figure 12-51, Intermediate Event instead of End Event in Choreography diagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-19 Page 115, Section 8.3.13 Copy/paste BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-25 Page 351, Figure 12-7 Caption of the Figure Name BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-24 Page 348, Section 12.3.1, end of sentence confusing BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-23 Page 346, Section 12.1 Reference of Figure 12-4 instead of Figure 12-3? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-22 Page 345, Section 12.1 Typo, the word "Events" should be "Activities" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-14 Page 372, Table 12-7 Blank sections BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-13 Page 338, section 11.7 Section name versus content BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-17 Page 064, Section 7.5.1, wrong reference to Table 8.4 (should be Table 7-3) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-16 Page 042, Section 7.1.1 Reference to Figure 10-5 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-12 Page 259, Table 10-82, Missing "Catch" label above depiction of Parallel Multiple Event BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-11 Page 130, section 8.3.17 Copy/Paste error BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-15 Page 028, Section 1, Missing Conversation diagram in list of diagrams defined in BPMN BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-18 Page 065, Section 7.5.2, Wrong reference to Table 8.5 (Should be Table 7-4) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-10 Page 119, section 8.3.14 Copy/Paste error wrong term "Pool" vs "Message Flow" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-83 BPMN 2 FTF issue on XSDs for DD / DI model transfer BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-88 Method of specifying a default SequenceFlow is awkward BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-87 Lane.partitionElementRef incorrectly defined BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-82 Page 24, Table 7.2 Gateway control types row - Redundant forms for XOR Gateway BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-81 Page 121, Figures 7.3 and 10-1 ­ Redundant ways to model receiving messages BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-90 Page 204, Table 10-26, MultiInstance Activity: Potential error and clarification regarding **BehaviorEventRef BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-80 Page 26, Normal Flow row of Table 7.2 - Modeling Activities that are only ended by Events BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-79 Page 26, Normal Flow row of Table 7.2 - Modeling activities that do not complete before process completion BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-78 Page 22, Section 7.2.1 ­ Associating Data Objects with process as a whole BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-67 Page 331, Figure 11-4, Message Flows part of a Conversation diagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-77 Page 29, Section 7.2.2 ­ Fork and Join Differentiation BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-76 Page 121, Figure 10-1 - Redundant ways to model receiving messages BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-73 Page 22, Section 7.2.1 - Associating Data Objects with process as a whole BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-72 Page 190, sub-section "Transaction" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-74 Page 26, Normal Flow row of Table 7.2 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-69 Page 361, Figure 12-23, Sub-process marker missing BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-68 Page 337, section 11.5 Typo should be "Call Conversation" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-75 Page 26, Normal Flow row of Table 7.2 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-70 Page 032, section 2.4.1, Referencing wrong chapter BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-71 Page 076, Figure 8-5, Figure Caption incorrect BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-57 Page 244, section 10.4.2 Last two structural specifications for Start Event BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-56 Page 187, Do sub-process markers also apply for Call Activity and Event Subprocess BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-61 Page 253, section 10.4.3 End Event Sequence Flow Connections BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-60 Page 192, Table 10-21 Transaction types need explanation BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-65 Page 265, Sequence Flow Connections for Intermediate Events BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-64 Page 265, Activity Boundary Connections BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-62 Page 255, Message Flow connection for End Event BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-59 Page 251, Exceptions for Sequence Flow connections for Start Event BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-55 Page 159, Section 10.1.2 number of types of diagrams BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-58 Page 247 section Start Event for Event Sub-Processes BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-66 Page 328, Section 11, Communication Link or Conversation Link BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-63 Page 257, Intermediate Event Types in Normal flow BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-47 Page 223, Figure 10-57 Unclear usage of IsCollection attribute for DataOutput BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-46 Page 149, Figure 9-6 Multi-instance marker no depiction for white box pools BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-45 Page 149, Figure 9-6 Vertical pool markers placement depiction BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-50 Page 028, Section 1, Wrong term for BPMN : Business Process Modeling Notation BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-49 Page 115-120 Distinguishing Initiating and Non-Inititating Messages BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-54 Page 153, Figure10-1, Link Events not paired may lead to confusion BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-53 Page 056, Table 7-2, Compensation Association: Usage of term Compensate Event BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-43 Page 063, Section 7.4 Undefined term "Flow" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-42 Page 050, 061 and 417 Group text implies that only activites can be within a Group BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-52 Page 054, Table 7-2, Gateway Control Types: Incomplete statement BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-51 Page 049, Table 7-1 Depiction of Lanes with single lines to separate Lane name to Lane content BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-41 Page 060, Table 7-2, Merging: No depiction of implicit merge BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-40 Page 058, Table 7-2, Fork: Questionable affirmation BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-44 Page 187, Figure 10-27 Inconsistent use of class hierarchy vs. attributes to define types of subprocess BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-48 Page 253 and 257, Table 10-81 and 10-82 EventDefintion used for Events BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-28 Page 357, Figure 12-17 and 12-18 Participant names not identical BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-27 Page 353, Figure 12-11, inapropriate caption BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-26 Page 352, Figure 12-9, inapropriate caption BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-34 Page 408, Section 13.2.5 Event Sub-process not included BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-33 Page 242-243 Tables 10-75 and 10-76 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-32 Page 243, Table 10-76 eventDefinitionRefs and eventDefinitions descriptions BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-31 Page 242, Table 10-75 eventDefintionsRefs and eventDefinitions descriptions are identical BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-30 Page 175, Table 10-11, Spelling of Business in Attribute Name BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-29 Page 370, Table 12-6, references to Event Sub-Process BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-37 Page 243 Table 10-76 the definition of EventDefinitionRefs and eventDefinitions is duplicated in ThrowEvent and CatchEve BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-36 Page 165, Table 10-7 Required attribute cardinality explicitly defined BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-39 Page 047, Section 7.2 Properties is presented as a Data element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-38 The attribute name is duplicated across many, many, many classes BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-35 Page 331, Typo Figure references 11-3 but should be 11-4 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN21-376 Page 29, Section 7.2.2 - Fork and Join Differentiation BPMN 2.0b1 open
BPMN21-372 Typo: Data Object spelled Objec BPMN 2.0 open
BPMN21-370 word catalogue in the Figure 5.3: Order Fulfillment BPMN 2.0 open
BPMN21-369 Missing event marker in Figure 10.30 BPMN 2.0.2 open
BPMN21-368 figure 13.1 BPMN 2.0 open
BPMN21-367 Bug p385 BPMN 2.0 open
BPMN21-366 Section 10.3.4 Human Performer is not peorperly defined for implementation interpretation BPMN 2.0.2 open
BPMN21-365 bug issue concerning event-based gateway illustration 10.98 BPMN 2.0 open
BPMN21-364 bug issue concerning event-based gateway BPMN 2.0 open
BPMN21-363 [BPMN 2.0.2] bug issue concerning event sub process BPMN 2.0 open
BPMN21-362 Sequencing rule for Choreography activities causes ambiguous execution semantics? BPMN 2.0 open
BPMN21-359 Allowable start events for event sub-process inconsistently defined BPMN 2.0.1 open
BPMN21-358 References to invalid sub clauses (incorrect sub clause numbers) BPMN 2.0.1 open
BPMN21-361 Invalid use of MAY NOT keyword BPMN 2.0.1 open
BPMN21-360 Wrong sub clauses are referenced BPMN 2.0.1 open
BPMN21-278 major error in figures for corresponding diagrams BPMN 2.0 open
BPMN21-277 conversion of choreographies to collaboration diagrams BPMN 2.0 open
BPMN21-282 number of start events for sub-processes BPMN 2.0 open
BPMN21-281 enumeration missing BPMN 2.0 open
BPMN21-290 CallChoreographyActivity notation for called participants BPMN 2.0 open
BPMN21-289 Incoming/Outgoing Data Associations of DataInputs/Outputs BPMN 2.0 open
BPMN21-286 Cardinality of id in BaseElement BPMN 2.0 open
BPMN21-285 Relationship from Choreography to Artifacts BPMN 2.0 open
BPMN21-288 Incorrect Section References BPMN 2.0 open
BPMN21-287 Wrong document reference in dtc/2010-06-02 BPMN 2.0 open
BPMN21-292 Procedure not defined BPMN 2.0 open
BPMN21-291 The XSLT for transforming to BPMN XMI has errors BPMN 2.0 open
BPMN21-280 Content of Section missing BPMN 2.0 open
BPMN21-279 Wrong diagram BPMN 2.0 open
BPMN21-284 Typo on page 77 (physical page 107) BPMN 2.0 open
BPMN21-283 Typo on page 76 BPMN 2.0 open
BPMN21-294 Normal Process Not Defined BPMN 2.0 open
BPMN21-293 Object mispelt BPMN 2.0 open
BPMN21-374 Second occurance of sequential Multi-Instances should be parallel BPMN 2.0.2 open
BPMN21-373 Use of per mille symbol unclear (‰) BPMN 2.0.2 open
BPMN21-375 Is compensation allways triggered automatically upon uncaught errors? BPMN 2.0 open
BPMN21-354 BPMN typo BPMN 2.0 open
BPMN21-353 Extend BPMN with a element that subclasses an existing BPMN element BPMN 2.0 open
BPMN21-356 An invalid statement regarding Black Box depiction of pools BPMN 2.0 open
BPMN21-355 Editorial: Wrong description of Figure 10.79 in the text BPMN 2.0 open
BPMN21-357 Suspected definition error in DataObject.isCollection BPMN 2.0.1 open
BPMN21-352 Repeated use of previous definition for conflicting task attributes BPMN 2.0 open
BPMN21-351 Entire document BPMN 2.0 open
BPMN21-350 Title BPMN 2.0 open
BPMN21-346 Section 7.6 BPMN 2.0 open
BPMN21-345 Section 3.3 BPEL4People BPMN 2.0 open
BPMN21-348 Section 8.3.4 BPMN 2.0 open
BPMN21-347 Section 8.1 Figure 8.2 BPMN 2.0 open
BPMN21-344 Section 3.2 Normative BPMN 2.0 open
BPMN21-349 Typo in section 8.4 BPMN 2.0 open
BPMN21-333 Revision & clarification for interruption of looping / multi-instance sub-processes BPMN 2.0 open
BPMN21-332 Wrong attribute name "attachedTo" for Bounday event BPMN 2.0 open
BPMN21-331 Looping/Multi-instantiation description error BPMN 2.0 open
BPMN21-330 Travel Booking Example BPMN 2.0 open
BPMN21-335 Association - an Artifact or a Connecting object? BPMN 2.0 open
BPMN21-334 Significant typo in BPMN 2.0 v1.0 formal/2011-01-03 BPMN 2.0 open
BPMN21-341 Wrong references to ItemAwareElement in UML diagram BPMN 2.0 open
BPMN21-340 Page 217: Send Task Mapping, first sentence BPMN 2.0 open
BPMN21-338 flowNodeRefs containment and subprocess clarification BPMN 2.0 open
BPMN21-337 Incorrect wording for description, should read "parallel" instead of "sequential" BPMN 2.0 open
BPMN21-343 Section 3.3 OMG UML BPMN 2.0 open
BPMN21-342 Cover Page Title BPMN 2.0 open
BPMN21-336 Inconsistent Naming of Multi-instance Activity BPMN 2.0 open
BPMN21-329 Unclear meaning of "‰" symbol BPMN 2.0 open
BPMN21-339 Picture doesn't correspond to the description BPMN 2.0 open
BPMN21-316 Use XPath 2.0 as default expression language instead of XPath 1.0 BPMN 2.0 open
BPMN21-315 XML Schema: Usage of xsd:anyAttribute instead of xsd:attribute BPMN 2.0 open
BPMN21-327 Reference omitted in BPMN 2 11-01-03 BPMN 2.0 open
BPMN21-326 Incomming sequence flow at start event BPMN 2.0 open
BPMN21-318 visualization enumeration level BPMN 2.0 open
BPMN21-317 Title of Figure 10.122 doesn't match its contents BPMN 2.0 open
BPMN21-322 ItemAwareElement the second BPMN 2.0 open
BPMN21-321 eXclusive Gateway BPMN 2.0 open
BPMN21-320 item-aware element vs. ItemAwareElement BPMN 2.0 open
BPMN21-319 Missing Enumeration BPMN 2.0 open
BPMN21-328 Table 7.2 Description of Multiple Instances BPMN 2.0 open
BPMN21-324 Catch None intermediate event BPMN 2.0 open
BPMN21-325 wrong reference on page 292 BPMN 2.0 open
BPMN21-323 MAY NOT BPMN 2.0 open
BPMN21-299 BPMN 2.0 Spec Problems (from Typo's to More Serious Issues) BPMN 2.0 open
BPMN21-298 BPMN2 issue: Example (DI lanes and nested lanes) appears to be invalid BPMN 2.0 open
BPMN21-306 BPMN 2.0 Choreography issues page 327 of dtc/2010-06-05 BPMN 2.0 open
BPMN21-305 BPMN 2.0 Choreography issues page 339 of dtc/2010-06-05 BPMN 2.0 open
BPMN21-308 meta-model doesn't provide way to serialize intermediate catch events attached to participant bands of choreography task BPMN 2.0 open
BPMN21-307 BPMN 2.0 Choreography issues page 338 of dtc/2010-06-05 about Sub-choreographics BPMN 2.0 open
BPMN21-310 Unclear introduction of the concept of MEP BPMN 2.0 open
BPMN21-309 Process name in property mapping is "statically" derived not "statistically" BPMN 2.0 open
BPMN21-312 Underspecification of Multi-instance participants in Choreographies BPMN 2.0 open
BPMN21-311 Underspecification of initiating/non-initiating participants in non-trivial choreographies BPMN 2.0 open
BPMN21-304 XML Schema not valid BPMN 2.0 open
BPMN21-303 Error in Description for Multiple Instances in Table 7.2 BPMN 2.0 open
BPMN21-302 Title of Figure 10.66 grammatically wrong BPMN 2.0 open
BPMN21-314 Some BPEL4People links are dead BPMN 2.0 open
BPMN21-313 Underspecification of ChoreographyLoopType BPMN 2.0 open
BPMN21-301 BPMN 2.0: Errors in Section 6.2 Structure of this Document BPMN 2.0 open
BPMN21-300 Can Event Sub-Processes Loop? BPMN 2.0 open
BPMN21-297 more typos BPMN 2.0 open
BPMN21-296 Change "recieved" in Fig 11.49 to "received" BPMN 2.0 open
BPMN21-295 Spello BPMN 2.0 open
BPMN21-276 Meaning of 'behavior' attribute on MultiInstanceLoopCharacteristics quite confusing BPMN 2.0 open
BPMN21-275 Subclasses of Interaction Node (Task vs. Activity) BPMN 2.0 open
BPMN21-274 Inheritance and Relationship of ResourceParameter BPMN 2.0 open
BPMN21-187 Page 140-141. Wrong name of model associations BPMN 2.0 open
BPMN21-186 Page 132. “Communication” instead of “Conversation” Figure 9.23 BPMN 2.0 open
BPMN21-196 Page 283. The number of types of Event handlers BPMN 2.0 open
BPMN21-195 Page 281. Wrong name of Figure 10.92 BPMN 2.0 open
BPMN21-190 Page 171. “Manual Task” instead of “User Task” BPMN 2.0 open
BPMN21-189 Pages 165-167. “implementation” attribute of Send and Receive Tasks BPMN 2.0 open
BPMN21-185 Page 130. Nonexistent Conversation “Special Cover” is mentioned BPMN 2.0 open
BPMN21-184 Page 128. Wrong name of Conversation “Delivery/Dispatch Plan” BPMN 2.0 open
BPMN21-193 Page 246. Typo BPMN 2.0 open
BPMN21-192 Page 224. Typos BPMN 2.0 open
BPMN21-188 Page 154. “Choreography” instead of “Process BPMN 2.0 open
BPMN21-194 Page 255. Message End Event sends Messages BPMN 2.0 open
BPMN21-191 Page 190. Paragraph needs to be nested BPMN 2.0 open
BPMN21-183 Page 78. Wrong association type in Table 8.32 BPMN 2.0 open
BPMN21-158 Pages 221-223. Inheritance of DataInput, DataOutput. Wrong table reference BPMN 2.0 open
BPMN21-157 Page 221. Nonexistent attribute “optional” mentioned BPMN 2.0 open
BPMN21-166 Page 308. Incorrect name of Parallel Event-Based Gateway 1 BPMN 2.0 open
BPMN21-156 Page 202. Wrong multiplicity of model association “event” BPMN 2.0 open
BPMN21-155 Page 192. Association “calledElementRef”: wrong name, location and description BPMN 2.0 open
BPMN21-161 Pages 230-231. Wrong name of Table 10.64 BPMN 2.0 open
BPMN21-160 Page 230. Super-class of ”Assignment” not shown in any diagram BPMN 2.0 open
BPMN21-164 Page 266. Wrong role name "attachedToRef" in Table 10.91 BPMN 2.0 open
BPMN21-163 Page 241. Wrong role names in Figure 10.69 BPMN 2.0 open
BPMN21-159 Page 230. Wrong type of model association “transformation” BPMN 2.0 open
BPMN21-154 Page 185. Nonexistent enumeration used in Table 10.21 BPMN 2.0 open
BPMN21-162 Page 231. Activity is not an Item Aware Element BPMN 2.0 open
BPMN21-165 Page 274. Wrong role name “errorRef” in Table 10.96 BPMN 2.0 open
BPMN21-133 Chapter 10. Typos BPMN 2.0 open
BPMN21-132 Chapter 9. Typos BPMN 2.0 open
BPMN21-131 Chapter 8. Typos BPMN 2.0 open
BPMN21-130 Chapter 7. Typos BPMN 2.0 open
BPMN21-134 Chapter 11. Typos BPMN 2.0 open
BPMN21-136 Chapter14. Typos BPMN 2.0 open
BPMN21-135 Chapter 13. Typos BPMN 2.0 open
BPMN21-129 Page 485. Wrong reference to figure 14.2 BPMN 2.0 open
BPMN21-128 Page 313. Wrong references to figures 10.123 10.124 BPMN 2.0 open
BPMN21-123 Page 231. Wrong reference to table 10.63 2 BPMN 2.0 open
BPMN21-122 Page 231. Wrong reference to table 10.63 1 BPMN 2.0 open
BPMN21-125 Page 248. Wrong reference to table 10.85 BPMN 2.0 open
BPMN21-124 Page 245. Wrong reference to table 10.83 BPMN 2.0 open
BPMN21-127 Page. 300. Wrong reference to page 450 BPMN 2.0 open
BPMN21-126 Page 266. Wrong reference to table 10.91 BPMN 2.0 open
BPMN21-137 Left over restrictions on use of Start and End Events BPMN 2.0 open
BPMN21-248 Conditions for completion of Process and Sub-Process BPMN 2.0 open
BPMN21-247 Apparent contradiction concerning compensation handler invocations BPMN 2.0 open
BPMN21-258 Table 10.56 is named Data Store attributes instead of Data Store Reference attributes BPMN 2.0 open
BPMN21-257 Outgoing Paths after Inclusive Gateway BPMN 2.0 open
BPMN21-253 Wrong configuration of Event-Based Gateway BPMN 2.0 open
BPMN21-252 Page 473.Wrong reference to figure BPMN 2.0 open
BPMN21-250 In Chapter 14 Figures are not numbered BPMN 2.0 open
BPMN21-249 Legal BPMN models and “lack of synchronization" BPMN 2.0 open
BPMN21-246 “empty Start Event” is used instead of “None Start Event” BPMN 2.0 open
BPMN21-245 Terminate End Event in a Choreography with many Participants BPMN 2.0 open
BPMN21-256 Reference calledChoreographyRef of CallChoreography refers to Choreography and to CallableElement BPMN 2.0 open
BPMN21-255 Figure 10.127, private process supports public process BPMN 2.0 open
BPMN21-244 Restrictions for Relative and Absolute Timers are the same BPMN 2.0 open
BPMN21-251 Pages 467-468. Missing Figure BPMN 2.0 open
BPMN21-254 Table 7.2 Element Data Object column "Notation" typo Data ObjecT (Collection) BPMN 2.0 open
BPMN21-223 Service Tasks can be the source or target of Messages Flows BPMN 2.0 open
BPMN21-222 Messages Flows can be attached to Events BPMN 2.0 open
BPMN21-221 Incorrect multiplicity of dataStoreRef BPMN 2.0 open
BPMN21-220 Inconsistencies concerning Item-Aware Elements BPMN 2.0 open
BPMN21-219 Inconsistencies concerning Flow Elements BPMN 2.0 open
BPMN21-228 Page 288. Typos BPMN 2.0 open
BPMN21-227 “cancelActivity” is not an attribute of Activity BPMN 2.0 open
BPMN21-226 Intermediate Message Event can be source or target of Message Flow BPMN 2.0 open
BPMN21-225 Participant multi-instance instead of Sub-Choreography multi-instance BPMN 2.0 open
BPMN21-218 Page 345. Sub-Choreographies instead of Choreography Activities BPMN 2.0 open
BPMN21-217 Page 224. Typos BPMN 2.0 open
BPMN21-214 Multiple Instances Description: Sequential instead of parallel, Typos BPMN 2.0 open
BPMN21-213 Text mentiones keyword "MUST NOT" 2 times BPMN 2.0 open
BPMN21-216 Figure 10.30 doesn't correspond with Text: Start Event as Marker BPMN 2.0 open
BPMN21-215 Text references DataObject Element although DataState is meant BPMN 2.0 open
BPMN21-224 Examples - DI - Lanes and Nested Lanes.bpmn example is not according to the specifications BPMN 2.0 open
BPMN21-169 Page 338. Wrong name, multiplicity and description of “messageFlowRefs” BPMN 2.0 open
BPMN21-168 Page 317. Ambiguous associations “partitionElement” and “partitionElementRef” BPMN 2.0 open
BPMN21-182 Page 77. Incomplete sentence BPMN 2.0 open
BPMN21-177 Page 440. Incorrect name of Parallel Event-Based Gateway 2 BPMN 2.0 open
BPMN21-176 Page 370. Wrong Parallel Gateway in Figure 11.47 BPMN 2.0 open
BPMN21-172 Page 342. Wrong reference to Table 11.3 BPMN 2.0 open
BPMN21-171 Page 341. Choreography Activity instead of Task BPMN 2.0 open
BPMN21-178 Page 441. “Task” instead of “Activity” BPMN 2.0 open
BPMN21-180 Page 57. Associations are incorrectly drawn Figure 8.6 BPMN 2.0 open
BPMN21-179 Page 452. Incorrect name of Parallel Event-Based Gateway 3 BPMN 2.0 open
BPMN21-175 Pages 366-368. Wrong direction of Message Flow BPMN 2.0 open
BPMN21-174 Page 359. Missing markers in Send and Receive Tasks BPMN 2.0 open
BPMN21-170 Page 341. Choreography instead of Sub-Choreography BPMN 2.0 open
BPMN21-173 Page 345. Wrong type of "calledChoreographyRef" BPMN 2.0 open
BPMN21-147 Page 117. Wrong name of model association “interfaceRefs”. BPMN 2.0 open
BPMN21-146 Page 115. Confusion over subtypes of Collaboration 1. BPMN 2.0 open
BPMN21-145 Page 111. Association “participants” not shown in Figure 9.1 BPMN 2.0 open
BPMN21-149 Page 117 & 118. Confusion over subtypes of Collaboration 2 BPMN 2.0 open
BPMN21-148 Page 117 & 118. Wrong name of association “participantRefs BPMN 2.0 open
BPMN21-153 Page 185. Nonexistent attribute shown in Figure 10.29 BPMN 2.0 open
BPMN21-152 Page 182. Missing Start event triggers for Event Sub-Process BPMN 2.0 open
BPMN21-141 Page 99. Wrong inheritance of FlowNode BPMN 2.0 open
BPMN21-140 Page 97. Wrong multiplicity of association in Table 8.50 BPMN 2.0 open
BPMN21-139 Page 96. ResourceParameter is not subclass of RootElement BPMN 2.0 open
BPMN21-138 Page 84. Event is not direct subclass of FlowElement BPMN 2.0 open
BPMN21-143 Page 109. Wrong multiplicity in Figure 9.1 BPMN 2.0 open
BPMN21-142 Page 104. Navigation (arrowhead) is needed if Figure 8.36 BPMN 2.0 open
BPMN21-150 Page 139. Ambiguous multiplicities of associations BPMN 2.0 open
BPMN21-144 Page 110. Wrong use of UML concept “aggregation”. BPMN 2.0 open
BPMN21-151 Page 151. Wrong role name and multiplicity of association “artifacts” BPMN 2.0 open
BPMN21-99 Unclear and incorrect specification of Expressions and Formal Expressions BPMN 2.0 open
BPMN21-98 Cardinality of sources for Data Association BPMN 2.0 open
BPMN21-97 How many source are allowed for data association? BPMN 2.0 open
BPMN21-107 Page153 Wrong reference to section 8.3.2 BPMN 2.0 open
BPMN21-106 Page 96. Wrong reference to table 8.50 BPMN 2.0 open
BPMN21-96 Typo: "Interrupting" should be "Non-Interrupting" BPMN 2.0 open
BPMN21-95 Figure 10.98 needs Updating BPMN 2.0 open
BPMN21-104 Page 29 Wrong reference to page 240 BPMN 2.0 open
BPMN21-103 Definition of Signal Missing BPMN 2.0 open
BPMN21-105 Page 96 Wrong reference to table 8.49 BPMN 2.0 open
BPMN21-101 Definition of Association is to strict BPMN 2.0 open
BPMN21-100 Contradictory mandatoryness of category for category values BPMN 2.0 open
BPMN21-102 Wrong metaclass name in attribute description BPMN 2.0 open
BPMN21-268 Multiple uncontrolled incoming Sequence Flows BPMN 2.0 open
BPMN21-267 Element Repository BPMN 2.0 open
BPMN21-266 Attributes of GlobalScriptTask BPMN 2.0 open
BPMN21-265 Connection Rules for Message Flow BPMN 2.0 open
BPMN21-272 Relationship type of CorrelationProperty BPMN 2.0 open
BPMN21-271 Attribute Description of Class Signal missing BPMN 2.0 open
BPMN21-260 CompensateEventDefinition vs. CompensationEventDefinition BPMN 2.0 open
BPMN21-259 Attributes and Model Associations of EndEvent BPMN 2.0 open
BPMN21-273 Model Associations of class Event BPMN 2.0 open
BPMN21-264 Attributes of StandardLoopCharacteristics BPMN 2.0 open
BPMN21-263 Attributes of Transaction Element BPMN 2.0 open
BPMN21-270 Attributes of Element Resource Role BPMN 2.0 open
BPMN21-269 Converging Gateway has multiple outgoing connections BPMN 2.0 open
BPMN21-262 Cardinality of Relationship from CategoryValue to Category BPMN 2.0 open
BPMN21-261 Model Association participantMultiplicity(Ref) of element Participant BPMN 2.0 open
BPMN21-239 Events that can be located after an Event-Based Gateway BPMN 2.0 open
BPMN21-238 Inconsistencies concerning attribute “activationCount” BPMN 2.0 open
BPMN21-233 None Intermediate Event: “catch” or “throw” BPMN 2.0 open
BPMN21-232 Inconsistencies concerning Link Events BPMN 2.0 open
BPMN21-229 Message Flow Connections for Start, End and Intermediate Events BPMN 2.0 open
BPMN21-236 Pages 285-287. Missing Events types BPMN 2.0 open
BPMN21-235 Page 281. Typo in Table 10.100 BPMN 2.0 open
BPMN21-241 Number of internal markers for Choreography Activities BPMN 2.0 open
BPMN21-240 Wrong Public Process in Figure 10.127 BPMN 2.0 open
BPMN21-243 Page 350. Typo BPMN 2.0 open
BPMN21-242 Sub-Choreography is not a compound Activity BPMN 2.0 open
BPMN21-234 Event Sub-Processes use Multiple and Parallel Multiple Start Events BPMN 2.0 open
BPMN21-231 Page 270. Typo BPMN 2.0 open
BPMN21-230 Page 247. “Parallel” instead of “Parallel Multiple” BPMN 2.0 open
BPMN21-237 Table 8.14: Example for BPMN's extension mechanism is not schema-valid BPMN 2.0 open
BPMN21-211 Inconsistencies and contradictions concerning Error element BPMN 2.0 open
BPMN21-210 Page 106. Wrong role name “errorRef” in Table 8.66 BPMN 2.0 open
BPMN21-212 Inconsistencies and contradictions concerning Escalation element BPMN 2.0 open
BPMN21-207 Number of Participant bands and Messages in a Choreography Task BPMN 2.0 open
BPMN21-206 Is “Association” a type of “Artifact” or not? BPMN 2.0 open
BPMN21-209 Page 83. Wrong reference to Table 8.42 BPMN 2.0 open
BPMN21-208 Inconsistencies related to Default Sequence Flow BPMN 2.0 open
BPMN21-205 Some Tokens consumed by Complex Gateways don’t reach end nodes BPMN 2.0 open
BPMN21-204 Is a Choreography a type of Process? BPMN 2.0 open
BPMN21-201 Page 364. Number of Choreography Activities preceding an Inclusive Gateway BPMN 2.0 open
BPMN21-200 Page 363. Wrong names of Choreography Tasks BPMN 2.0 open
BPMN21-198 Page 352. “escalation” instead of “non- interrupting BPMN 2.0 open
BPMN21-197 Page 312. Wrong name of Figure 10.122 BPMN 2.0 open
BPMN21-203 Page 274. Wrong role name “errorRef” in Table 10.96 BPMN 2.0 open
BPMN21-202 Figure 10.30 is incorrect BPMN 2.0 open
BPMN21-199 Page 352. “Cancel” instead of “Compensation BPMN 2.0 open
BPMN21-109 Adding child attributes and child elements in XSLT causes errors BPMN 2.0 open
BPMN21-108 Page154. Wrong reference to chapter 13 BPMN 2.0 open
BPMN21-111 Page168. Wrong reference to figure 10.18 BPMN 2.0 open
BPMN21-110 Page167. Wrong reference to page 171 BPMN 2.0 open
BPMN21-114 Page170. Wrong references to figures 10.17 10.18 BPMN 2.0 open
BPMN21-113 Page 169. Wrong reference to figure 10.20 BPMN 2.0 open
BPMN21-121 Page 219. Wrong reference to table 10.58 BPMN 2.0 open
BPMN21-120 Page 217. Wrong reference to table 10.57 BPMN 2.0 open
BPMN21-117 Page 181. Wrong reference to figure 10.29 BPMN 2.0 open
BPMN21-116 Page 180. Wrong reference to figure 10.25 BPMN 2.0 open
BPMN21-118 Page 191. Wrong reference to figure 10.42 BPMN 2.0 open
BPMN21-119 Page 212. Wrong references to tables 10.51 10.52 BPMN 2.0 open
BPMN21-112 Page168 . Wrong reference to figure 10.19 BPMN 2.0 open
BPMN21-115 Page 172. Wrong reference to table 10.4 BPMN 2.0 open
BPMN21-91 Ambiguous statement about DataObjects and DataObjectReference BPMN 2.0 open
BPMN21-90 Replace "process" attribute of a laneSet with "flowElementsContainer"? BPMN 2.0 open
BPMN21-89 Incorrect reference in loopcharacteristics class diagram BPMN 2.0 open
BPMN21-84 Define rules for placement of multiple activity markers BPMN 2.0b1 open
BPMN21-83 Data associations need to be revisited and their use clarified. BPMN 2.0b1 open
BPMN21-87 Inconsistency between Boundary Event attribute names in Table 10.91 and Table 10.102 BPMN 2.0 open
BPMN21-86 Clarify Relationship between Collabration Message Flow and Choreography Tasks BPMN 2.0 open
BPMN21-94 Incorrect N-to-N relationships in participants class diagram BPMN 2.0 open
BPMN21-93 Activity as InteractionNode BPMN 2.0 open
BPMN21-82 Add Link Events to a sub-conformance level (Descriptive) BPMN 2.0b1 open
BPMN21-81 Messages and User Tasks BPMN 2.0b1 open
BPMN21-78 Rethink implementation attribute in Send/Receive/Service Tasks BPMN 2.0b1 open
BPMN21-74 Notation for expanded hexagons BPMN 2.0b1 open
BPMN21-73 definitionalCollaborationRef should be 0..* BPMN 2.0b1 open
BPMN21-71 Multi-language labels for diagram elements BPMN 2.0b1 open
BPMN21-70 Ambiguous statements about Sequence Flow BPMN 2.0b1 open
BPMN21-66 Add Brief Description for Error and Escalation Event Definitions BPMN 2.0b1 open
BPMN21-72 Redundancy in specifying data in processes BPMN 2.0b1 open
BPMN21-77 Integrate temporal and token semantics BPMN 2.0b1 open
BPMN21-76 Enforcability rules not complete BPMN 2.0b1 open
BPMN21-80 Choreography activities sharing message flow BPMN 2.0b1 open
BPMN21-79 Lists of values BPMN 2.0b1 open
BPMN21-85 CorrelationSubscription Ownership - Sub Process BPMN 2.0 open
BPMN21-88 Event Sub-Process only in Sub-Processes? BPMN 2.0 open
BPMN21-69 How to represent Activities that might fit in more than one Lane? BPMN 2.0b1 open
BPMN21-92 XML Schema for dataObjectReference and dataStoreReference are missing BPMN 2.0 open
BPMN21-75 Notation for shared correlation properties BPMN 2.0b1 open
BPMN21-68 The spec should clearly state what visual features are available for extensions and which are restricted to core spec BPMN 2.0b1 open
BPMN21-67 UML interface operations do not match BPMN interface operations BPMN 2.0b1 open
BPMN21-60 Section 10.2.3: Task description needs revisiting BPMN 2.0b1 open
BPMN21-59 More description for "Process as a callable element" BPMN 2.0b1 open
BPMN21-54 Correlation across conversations BPMN 2.0b1 open
BPMN21-53 Throughout Spec [Specification]: Define explicit separation of "modeling" vs "implementation" attributes BPMN 2.0b1 open
BPMN21-55 Define "Pool" BPMN 2.0b1 open
BPMN21-57 Annex A {Spec]: Add a section that documents the changes between V1.1 and V2.0 BPMN 2.0b1 open
BPMN21-64 Continue versus terminate in loop BPMN 2.0b1 open
BPMN21-58 Section 8.3.3 [Data] Inconsistency between usage of expressions in Sequence Flows and in Data Associations BPMN 2.0b1 open
BPMN21-61 Section 10.5 Text duplicated from 8.3.10 BPMN 2.0b1 open
BPMN21-56 Beta 1 - Section 14.3 [Execution Semantics]: Examples for the use of gateways are missing BPMN 2.0b1 open
BPMN21-23 Exclusive gateway Choreography rules too restrictive, only sender needed BPMN 2.0b1 open
BPMN21-19 Parallel Gateway participants BPMN 2.0b1 open
BPMN21-18 Event-based gateways in choreography should be exclusive BPMN 2.0b1 open
BPMN21-22 Beta 1 Section 15.1.2 Sub-Process Mappings: Table referenced is missing BPMN 2.0b1 open
BPMN21-21 Section 10.5.5 Complex Gateway: The general description of Complex Gateways needs improving BPMN 2.0b1 open
BPMN21-15 Interactions supporting interactions BPMN 2.0b1 open
BPMN21-14 PartnerRole underspecified and misnamed BPMN 2.0b1 open
BPMN21-20 Figure 11-4 description BPMN 2.0b1 open
BPMN21-12 Gateways in Choreography missing split or merge BPMN 2.0b1 open
BPMN21-11 Message flow to/from events in Collaboration diagrams BPMN 2.0b1 open
BPMN21-13 CorrelationClassDiagram missing conversation association end name BPMN 2.0b1 open
BPMN21-17 Multiple senders after event-based gateway in choreography BPMN 2.0b1 open
BPMN21-16 Rules for exclusive gateway in choreography too strict BPMN 2.0b1 open
BPMN21-65 A New Hook for Organizational Models? BPMN 2.0b1 open
BPMN21-32 Notation for alternaitve data input/output sets BPMN 2.0b1 open
BPMN21-31 Exclusive Gateway Choreography Rule too Restrictive, starting new process BPMN 2.0b1 open
BPMN21-27 Multiple processes per participant BPMN 2.0b1 open
BPMN21-26 optional source and target refs for data association BPMN 2.0b1 open
BPMN21-36 Beta 1: Section 10.2.2 Human Interactions: The Parameter class should be described BPMN 2.0b1 open
BPMN21-35 Section 14.2.2 Activity (semantics): BPMN 2.0b1 open
BPMN21-30 Initializing and updating properties is not straight-forward BPMN 2.0b1 open
BPMN21-25 Beta 1: Section 17 BPMN Example: Include full BPMN example for this section BPMN 2.0b1 open
BPMN21-24 Roles for Entities BPMN 2.0b1 open
BPMN21-29 Add an example of Mutlple Start Events on the Boundary of a Sub-Process BPMN 2.0b1 open
BPMN21-28 Beta 1 Section 15.1.2 Mapping to BPEL Activities: Message Mapping snippet refers to StructureDefinition BPMN 2.0b1 open
BPMN21-37 Beta 1: Section 10.1.2: Use of BPMN Common Elements [Process] -- Return removed TBD sections and complete text BPMN 2.0b1 open
BPMN21-34 Beta 1: Section 10.2.4 Performer: Relate Performer to Human Performer BPMN 2.0b1 open
BPMN21-33 Beta 1: Section 9.1 Collaboration: Expand description of Collaboration in section BPMN 2.0b1 open
BPMN21-63 Link Events - Constraints and Usage not clearly documented BPMN 2.0b1 open
BPMN21-62 Section 10.2 Clearer separation between conceptual and visual model needed BPMN 2.0b1 open
BPMN21-52 Section 9 Collaboration [Choreography; Specification, Metamodel]: BPMN 2.0b1 open
BPMN21-51 Beta 1 Spec: New Annex?: Enumerate the validation rules of BPMN BPMN 2.0b1 open
BPMN21-50 Beta 1 Spec: Section 10.3 Data [Data]: BPMN 2.0b1 open
BPMN21-49 Beta 1 Spec: Section 14 BPEL Mapping: Better clarify the subset of BPMN diagrams that are BPEL-mappable (roundtrippable! BPMN 2.0b1 open
BPMN21-48 Provide example: Basic process structure BPMN 2.0b1 open
BPMN21-47 Provide example: Inline Subprocess BPMN 2.0b1 open
BPMN21-46 Provide example: Basic gateway examples BPMN 2.0b1 open
BPMN21-45 Provide example: Multi-instance activity BPMN 2.0b1 open
BPMN21-42 Provide example: Choreography BPMN 2.0b1 open
BPMN21-41 Section 14.4 [BPEL mapping] Missing intermediate send event; mapping of participant ref BPMN 2.0b1 open
BPMN21-40 Beta 1 Section 8.3.17 Sequence Flow and 14.2.1 Sequence Flow Considerations BPMN 2.0b1 open
BPMN21-44 Provide example: Complex gateway BPMN 2.0b1 open
BPMN21-43 Provide example: Conversation View BPMN 2.0b1 open
BPMN21-39 [Chroeography] Complete section 11.4: Events BPMN 2.0b1 open
BPMN21-38 Beta 1: Section 11.2: Use of BPMN Common Elements [Choreography] -- Return removed TBD sections and complete text BPMN 2.0b1 open
BPMN21-6 Page 251, Start Event on the boundary of a sub-process BPMN 2.0b1 open
BPMN21-5 Page 070, section 8 list of Core elements BPMN 2.0b1 open
BPMN21-2 Concept definition for Business Process BPMN 2.0b1 open
BPMN21-1 Allow a Process to be Ad Hoc (in addition to a Sub-Process) BPMN 2.0b1 open
BPMN21-9 Page 203, Table 10-26, The text describing the none and all behavior have been inverted BPMN 2.0b1 open
BPMN21-8 Add a User Event BPMN 2.0b1 open
BPMN21-7 This is a style suggestion to make diagrams clearer BPMN 2.0b1 open
BPMN21-4 Depiction of diagram fragments BPMN 2.0b1 open
BPMN21-3 Page 046, Section 7.2, Message not listed as a BPMN element BPMN 2.0b1 open
BPMN21-10 Example of Lane, Laneset, and Partitions BPMN 2.0b1 open

Issues Descriptions

Ad-Hoc Sub-Process falsely listed as

  • Key: BPMN21-443
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    There is a list of non-operational elements in the introduction to the section *13. BPMN Execution Semantics. The Ad-Hoc Process is in the list. However, in chapter **13.3.5 Ad-Hoc Sub-Process* its execution semantics is described in detail. So, I think the "details needed to execute them on an engine" are given. It seems, the Ad-Hoc Sub-Process is in fact operational and should be removed from the list.

    PS: There is no "Ad-Hoc Process". The "Sub-" is missing.

  • Reported: BPMN 2.0.2 — Thu, 15 Feb 2024 10:09 GMT
  • Updated: Thu, 15 Feb 2024 19:40 GMT

second instance of

  • Key: BPMN21-442
  • Status: open  
  • Source: Benchling ( Angela Yang )
  • Summary:

    In the "Multiple Instances" row in table 7.2 (page 39), the last sentence should read "A set of three vertical lines will be displayed at the bottom-center of the activity for parallel Multi-Instances (see lower figure to the right)." to match the diagram on the right.

  • Reported: BPMN 2.0 — Mon, 15 May 2023 19:14 GMT
  • Updated: Mon, 15 May 2023 20:15 GMT

Mistake in Table 7.2

  • Key: BPMN2-318
  • Status: open  
  • Source: - ( Sebastian Handwerker)
  • Summary:

    I found a mistake in the BPMN 2.0.2 specification.

    https://www.omg.org/spec/BPMN/2.0.2/PDF

    On Page 37:

    "The attributes of Tasks and Sub-Processes will determine if they are repeated or performed once (see page 190). A set of three horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see upper figure to the right).
    A set of three vertical lines will be displayed at the bottom-center of the activity for SEQUENTIAL Multi-Instances (see lower figure to the right)."

    The second "sequential" is wrong. The vertical lines are for PARALLEL Multi-Instances.

    The corrected form is the following:

    "The attributes of Tasks and Sub-Processes will determine if they are repeated or performed once (see page 190). A set of three horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see upper figure to the right).
    A set of three vertical lines will be displayed at the bottom-center of the activity for PARALLEL Multi-Instances (see lower figure to the right)."

  • Reported: BPMN 2.0.2 — Mon, 2 May 2022 20:54 GMT
  • Updated: Tue, 3 May 2022 16:55 GMT

Wrong word used. And wrong page reference

  • Key: BPMN21-441
  • Status: open  
  • Source: Public servant at the Customs office ( Johan Clemmesen)
  • Summary:

    I believe I have found one small mistake in the BPMN specification 2.0, but it has two occurrences.

    The mistake is where the sentence states two times "business process runtime", that perhaps should be altered to "business process engine"?

    It is here:

    10.2.4 Human Interactions
    10.2.4.1 Tasks with Human involvement
    In many business workflows, human involvement is needed to complete certain Tasks specified in the workflow model.
    BPMN specifies two different types of Tasks with human involvement, the Manual Task and the User Task.
    A User Task is executed by and managed by a business process runtime. Attributes concerning the human involvement, like people assignments and UI rendering can be specified in great detail. A Manual Task is neither executed by nor managed by a business process runtime.

    Also on page 163.

    There is a wrong page referencelink, because it links to itself on page 163, where it should link to "10.2.4.1 Tasks with Human involvement" instead.

    "See “User Task” on page 163 within the larger section of “Human Interactions” for the details of User Tasks"

  • Reported: BPMN 2.0 — Wed, 6 Apr 2022 13:24 GMT
  • Updated: Wed, 6 Apr 2022 15:55 GMT

fairly basic errors in some of your example flows

  • Key: BPMN21-440
  • Status: open  
  • Source: Ealing Council ( Louise McDonagh)
  • Summary:

    I have just started going through the 'Business Process Model and Notation, v2.0' document and come across some fairly basic errors in some of your example flows. On the one hand BPMN is very prescriptive, yet in the execution of the examples it is extremely lax and erroneous. I have not got very far into the document yet as it very heavy going, but 2 cases in point where your examples are poor: figure 7.1, 'Approve or Reject Policy' should be two mutually exclusive processes, one to reject and the other to approve, which should have 2 separate outcomes. If you are wishing just to show a high level articulation of this dependency, then the process should be phrased as 'Make Policy Application [Request] Decison'. The other process that jumps out as logically unsound is figure 7.3, example of collaboration process. There are 2 swimlanes, one for patient and one for doctor surgery. 'receive medicine request' is a 'pharmacy' function so should be in a '!
    pharmacy' pool. The way this process flows, there is no point in issuing a prescription request to the patient whose only duty is to present it back to the same surgery. Prescriptions requests have to go to a pharmacy, not the doctor. If the notation is being so prescriptive and requiring accurate conformance, the the examples need to be sensible, clear and error-free or there can be no confidence in the notation.

  • Reported: BPMN 2.0.1 — Fri, 28 Jan 2022 16:02 GMT
  • Updated: Fri, 28 Jan 2022 16:06 GMT

Description for "Mutiple Instances" is not correct.

  • Key: BPMN21-439
  • Status: open   Implementation work Blocked
  • Source: Oracle (Colombia) ( Carlos Alfredo Biscione Vecino)
  • Summary:

    On the referred chapter/section/table/page, the description cell for the item "Multiple Instances" must describe and differentiate sequential multiple instances and parallel multiple instances. The text in this table´s cell says the same for both sequential and parallel multiple instances, as shown (i enclosed the error within double brackets):
    " The attributes of Tasks and Sub-Processes will determine if they are repeated or performed once (see page 190).
    A set of three horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see upper figure to the right).
    A set of three vertical lines will be displayed at the bottom-center of the activity for [[sequential]] Multi-Instances (see lower figure to the right).".
    The description for the round box with vertical lines should read "parallel" instead of "sequential".

    Thanks in advance.
    Carlos Biscione - Oracle Colombia.

  • Reported: BPMN 2.0.1 — Thu, 27 Jan 2022 01:46 GMT
  • Updated: Fri, 28 Jan 2022 16:05 GMT

The returning message flow to the "Ask Developer" Manual Task

  • Key: BPMN21-438
  • Status: open  
  • Source: Bilge Adam Teknoloji ( Sahil Özyazıcı)
  • Summary:

    The returning message flow to the "Ask Developer" manual task from the "Provide feedback for 2nd level support" manual task should be go to the "Document 2nd level result" manual task in the same pool?

  • Reported: BPMN 2.0 — Wed, 24 Nov 2021 07:48 GMT
  • Updated: Wed, 24 Nov 2021 15:32 GMT

No correct validation rules mentioned

  • Key: BPMN21-437
  • Status: open  
  • Source: BBW ( Dieter Proost)
  • Summary:

    Dear Team

    On the provider www.bpmn.io I can create a flow that is exportable to a .BPMN/XML file. In order to check this XML validation the library links to:

    <?xml version="1.0" encoding="UTF-8"?>
    <bpmn:definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" id="Definitions_13r4fun" targetNamespace="http://bpmn.io/schema/bpmn" exporter="bpmn-js (https://demo.bpmn.io)" exporterVersion="8.8.0">

    The URLS to Omg.org are giving a page 404.

    Question:
    Is it possible to support me the correct Omg URLs for the XML header? so the XML can be validated

    Kind regards

    Dieter Proost

  • Reported: BPMN 2.0.2 — Wed, 20 Oct 2021 08:17 GMT
  • Updated: Wed, 3 Nov 2021 16:11 GMT

Clarify the possible catchers of error and escalation events

  • Key: BPMN21-436
  • Status: open   Implementation work Blocked
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    I always took for granted, that error and escalation events can only be catched in the same process instance at the same or a higher level as the throw event. A recent discussion in the OCEB group revealed, that the specification doesn't really support that view, without some reading between the lines.

    The semantics of these important events should not be open to debate. I suggest to add a clarification.

  • Reported: BPMN 2.0.2 — Wed, 18 Aug 2021 13:02 GMT
  • Updated: Fri, 20 Aug 2021 14:18 GMT

wrong word for parallel multi instance in description

  • Key: BPMN21-435
  • Status: open  
  • Source: None ( Jan Ruhstrat)
  • Summary:

    The attributes of Tasks and Sub-Processes
    will determine if they are repeated or
    performed once (see page 190). A set of three
    horizontal lines will be displayed at the
    bottom-center of the activity for sequential
    Multi-Instances (see upper figure to the right).
    A set of three vertical lines will be displayed at
    the bottom-center of the activity for sequential
    Multi-Instances (see lower figure to the right).

    Above the description of the multi instances from the document.
    In the last sentence the parallel multi instance ist described. But instead of using the word parallel its sequential.

    Best regards, Jan

  • Reported: BPMN 2.0.2 — Sun, 15 Aug 2021 22:53 GMT
  • Updated: Mon, 16 Aug 2021 14:19 GMT

Mismatch between text and table

  • Key: BPMN21-434
  • Status: open  
  • Source: Consultant ( Andrew Barbet)
  • Summary:

    Text:

    The Start Event trigger (EventDefinition) MUST be from the following types: Message, Error,
    Escalation, Compensation, Conditional, Signal, and Multiple (see page 259 for more details)

    Table on Page 259:

    Lists the above start events but also includes the Timer, and Parallel Multiple events.

  • Reported: BPMN 2.0 — Mon, 2 Aug 2021 07:30 GMT
  • Updated: Mon, 2 Aug 2021 18:34 GMT

All None Start Events should get a token at instantiation, if the Top-level Process or Global Process (or even Sub-Process) contains multiple Non Start Events

  • Key: BPMN21-433
  • Status: open   Implementation work Blocked
  • Source: TU Berlin ( Kai Grunert)
  • Summary:

    Section 10.5.2 on page 238 states:

    If the Process is used as a global Process (a callable Process that can be invoked from Call Activities of other Processes) and there are multiple None Start Events, then when flow is transferred from the parent Process to the global Process, only one of the global Process’s Start Events will be triggered. The targetRef attribute of a Sequence Flow incoming to the Call Activity object can be extended to identify the appropriate Start Event.

    1. Bug: the text only mentions "Global" processes and not "Top-level" processes, which is another but similar category of processes (p. 239). I find no semantic definition about multiple None Start Events in Top-level processes. I think, it should be the same semantic as for Global processes.

    2. Bug:

    As already mentioned in Bug report BPMN21-413 (https://issues.omg.org/issues/BPMN21-413) there is a semantic inconsistency with the definition of the process instantiation (also Section 10.5.2 on page 238):

    All Flow Objects that do not have an incoming Sequence Flow (i.e., are not a target of a Sequence Flow) SHALL be instantiated when the Process is instantiated.

    To bring both text passages together, I assume the term "Flow Objects" refers more likely to "Activities", because multiple start events are usually handled in an exclusive manner (defined at multiple places in the specification).
    *But, in my mind there is no semantic difference between an Activity A with no incoming sequence flow and Activity A connected to a None Start Event.* (This just seems to be a modelling preference.)
    So, the question is, how to handle multiple None Start Events in a Global and Top-level process? Exclusive (like the other typed start events) or Inclusive (like Activities without an incoming sequence flow) semantics?

    Solution:

    To stay consistent (no semantic difference between an Activity with or without a None Start Event), I plead for the inclusive semantic, i.e. to put a token into every None Start Event if the process was instantiated via a None Start Event.
    If the process is instantiated via a typed start event, the exclusive semantic should remain.

    Additionally, this is more user-friendly from a modeling perspective than the alternative: if Start Events have to be used (maybe because of a modeling guideline), the parallel semantic would require to have one None Start Event connected to a Parallel Gateway connected to all parallel-executable Activities. This could look very messy compared to one None Start Event at each Activity.

    The disadvantage is the difficulty to model/implement the exclusive start if it is needed. In my experience I have rarely seen it and the inclusive start is way more often required for multiple None Start Events.
    But let's look into that: For a Global (callable) process you can still use the existing targetRef attribute on the incoming sequence flow to refer to/instantiate just one None Start Event.
    None Start Events are also typically used for a manual process start in a process automation engine. If it is really intended to just put a token into one specific None Start Event, you could alternatively 1. use a Message Start Event or 2. the process engine can offer a way to just start a specific None Start Event.

    3. Related Improvement:

    If the semantic will be defined as suggested in Bug 2 for multiple None Start Events, it is also possible and useful to allow multiple None Start Events in embedded Sub-Processes. The entry into the Sub-Process would put a token into every existing None Start Event.

  • Reported: BPMN 2.0.2 — Wed, 27 Jan 2021 16:43 GMT
  • Updated: Fri, 29 Jan 2021 17:57 GMT

Confusing definition of LinkEventDefinition's fields "sources" and "target"

  • Key: BPMN21-432
  • Status: open  
  • Source: signavio.com ( Philipp Maschke)
  • Summary:

    We recently had a dispute with a customer, who wanted to use a different BPMN tool for downstream processing of certain process models exported from our tool.
    While analysing their claim, I found confusing definitions for the LinkEventDefinition:

    The textual specification for the LinkEventDefinition (and especially the table 10.98) defines three additional fields (compared to the EventDefinition): name, sources and target. All three are listed in the table 10.98 as "attributes":

    However, the following XSD definition actually specifies only the name to be an XML attribute while target and sources are defined as XML child elements - see table 10.115.

    As far as I could tell from a quick scan, all other "attributes" listed in tables with such a name are actually also XML attributes.
    So I can see how there could an interpretation, that the target of a link event should be an XML attribute and not a child element.
    Am I correct in assuming that the XSD is binding and thus "target" should really not be an attribute of the linkEventDefinition element, but rather a child element?
    If so, then this section should be defined in a less ambiguous way.

  • Reported: BPMN 2.0.2 — Thu, 17 Sep 2020 15:35 GMT
  • Updated: Tue, 22 Sep 2020 19:24 GMT

Page directs you to see itself

  • Key: BPMN21-431
  • Status: open  
  • Source: Semaphore Solutions ( Michael Gillis)
  • Summary:

    On page 292, the spec reads, "The precise synchronization behavior of the Inclusive Gateway can be found on page 292."

    It should refer to Section 13.3.3, page 435.

    (It would be helpful if other gateways in section 10.5 also referred to their respective execution semantics in section 13.3.)

  • Reported: BPMN 2.0 — Mon, 27 Jul 2020 18:20 GMT
  • Updated: Mon, 3 Aug 2020 14:38 GMT

Addition of Blockchain Element

  • Key: BPMN21-430
  • Status: open  
  • Source: SOLYD LLC ( Prabhat Kumar Singh)
  • Summary:

    Hello,

    My startup company has developed extension to BPMN2.0 to include blockchain. I have built a Javascript library for the same at this link on BitBucket: https://bitbucket.org/solyd/solyd-moddle/src
    Can I please request to make necessary amendments in BPMN specs to include the same?
    Please advice.

  • Reported: BPMN 2.0 — Thu, 14 May 2020 00:01 GMT
  • Updated: Thu, 28 May 2020 20:36 GMT

FlowNode.outgoing [0..*] should be an ordered set

  • Key: BPMN21-429
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    In Table 8.52 the specification says:

    outgoing: Sequence Flow [0..*]: This attribute identifies the outgoing Sequence Flow of the FlowNode. This is an ordered collection.

    In the xmi-file the property outgoing doesn't have ordered=true, as it should.

  • Reported: BPMN 2.0 — Fri, 24 Apr 2020 18:12 GMT
  • Updated: Tue, 28 Apr 2020 18:50 GMT

Incorrect description of inheritance

  • Key: BPMN21-428
  • Status: open  
  • Source: Freelancer ( Alejandro Gomez Auad)
  • Summary:

    It says "The DataStore element inherits the attributes and model associations of FlowElement (see Table 8.44) through its relationship to RootElement, and ItemAwareElement (see Table 10.51). [...]" while the diagram depict DataStore as being a direct descendant of FlowElement.

  • Reported: BPMN 2.0 — Sun, 22 Mar 2020 06:20 GMT
  • Updated: Fri, 3 Apr 2020 18:41 GMT

Please clarify if the usage of a XOR Join is not redundant

  • Key: BPMN21-427
  • Status: open  
  • Source: Blume ( Steffen)
  • Summary:

    Software vendors seem to implement it as a mandatory step to close every XOR Gateway with a XOR Join.
    It seems that even the majority of users which can be found in the internet, assume or state that the XOR Join element has to used everytime a XOR Gateway is opened.
    Just a few sources state that the usage of the XOR Join gateway is optional.

    Since i don't see a definitie logical reason, to use the XOR Join gateway at all, i was researching the OMG BPNPs specifications, which seem not to clrarly state how to handle XOR Joins either.
    Therefore i open up this issue. Could you please state:

    1. is there really an imgainable situation, in which the XOR Join makes sense? Is this element really needed?
    2. What is your recommendation in usage?

    Thank you very much for any clarification

  • Reported: BPMN 2.0.2 — Mon, 2 Mar 2020 10:56 GMT
  • Updated: Mon, 2 Mar 2020 15:58 GMT

Is there a definite reason to exist for a XOR join gateway?

  • Key: BPMN21-426
  • Status: open  
  • Source: Blume ( Steffen)
  • Summary:

    Please excuse that i ask this question by opening this bug report. SInce i wasn't able to find a definite answer to the given question in the specification, it may more be a bug in terms of an missing clarification, which seem to lead to the situation, that certain software providers handle the use of a XOR Join Gateway in a way, that seem to be redundant, from a strictly logical perspective, by stating the use of a XOR Gateway without the following mandatory use of a XOR Join Gateway as an error.

    There seem to be two different understandings of the handling of the XOR Join gateway. The Majority seems to state, that using this in general would be the best practise, whereas I think, that the logical aspect should be paramount. (Form follows function). That is why I was starting to research for an official explanation.

    So, could the OMG point out:
    A: Which possible Situation could logically justify the existance of this element?
    B: What a desired best practice in the use of this element would be?

    Thank you very much for your help
    sincerly yours

  • Reported: BPMN 2.0.2 — Wed, 26 Feb 2020 09:28 GMT
  • Updated: Wed, 26 Feb 2020 17:34 GMT

Event list seems to be not complete

  • Key: BPMN2-317
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    On p. 241 is written:

    A Start Event can also initiate an inline Event Sub-Process (see page 174). In that case, the same Event types as for
    boundary Events are allowed (see Table 10.86), namely: Message, Timer, Escalation, Error, Compensation,
    Conditional, Signal, Multiple, and Parallel.

    and on p. 174:

    The Start Event trigger (EventDefinition) MUST be from the following types: Message, Error,
    Escalation, Compensation, Conditional, Signal, and Multiple (see page 259 for more details).

    It seems that Timer and Parallel are missing the list on p. 174.

  • Reported: BPMN 2.0.2 — Thu, 16 Jan 2020 17:50 GMT
  • Updated: Fri, 17 Jan 2020 20:32 GMT

Misprint in call activity view

  • Key: BPMN2-316
  • Status: open  
  • Source: Kyiv ( Yevhen Mazhuha)
  • Summary:

    “Call activity” in the table looks like “None” (not market in bold).

  • Reported: BPMN 2.0.2 — Wed, 15 Jan 2020 14:12 GMT
  • Updated: Fri, 17 Jan 2020 20:32 GMT

Different explanation and example.

  • Key: BPMN2-315
  • Status: open  
  • Source: Kyiv ( Yevhen Mazhuha)
  • Summary:

    Example about figure 6.52 shows not about driver`s story

  • Reported: BPMN 2.0.2 — Wed, 15 Jan 2020 14:11 GMT
  • Updated: Fri, 17 Jan 2020 20:31 GMT

Example uses invalid DI attributes and wrong namespaces

  • Key: BPMN21-425
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    The example in section 15.3.1 Document Structure on page 475 (PDF 505) uses invalid Diagram Interchange (DI) attributes and fails XML schema validation. The example seems to use an older DI version than the one published with BPMN 2.0. This is also visible in the different namespace URLs used.

    diagram1.bpmn:7: element BPMNDiagram: Schemas validity error : Element '{http://www.omg.org/spec/BPMN/20100524/DI}BPMNDiagram', attribute 'scale': The attribute 'scale' is not allowed.
    diagram1.bpmn:7: element BPMNDiagram: Schemas validity error : Element '{http://www.omg.org/spec/BPMN/20100524/DI}BPMNDiagram', attribute 'unit': The attribute 'unit' is not allowed.diagram1.bpmn:8: element BPMNPlane: Schemas validity error : Element '{http://www.omg.org/spec/BPMN/20100524/DI}BPMNPlane', attribute 'element': The attribute 'element' is not allowed.
    diagram1.bpmn fails to validate
    

    A fixed version that passes XML schema validation is available at:
    https://github.com/bpmn-miwg/bpmn-miwg-demos/tree/master/2020-06-omg-technical-meeting-boston/discussion/BPMN%202.0.2%20Section%2015.3.1%20Document%20Structure%20Example

  • Reported: BPMN 2.0.2 — Thu, 7 Nov 2019 08:46 GMT
  • Updated: Mon, 11 Nov 2019 19:57 GMT

Pages 312-457. Nonexistent attribute “compensable” mentioned

  • Key: BPMN21-167
  • Legacy Issue Number: 15547
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    On page 312, it says:
    “It is possible to specify that a Sub-Process can be compensated without having to define the compensation handler. The Sub-Process attribute compensable, when set, specifies that default compensation is implicitly defined, which recursively compensates all successfully completed Activities within that Sub-Process.”

    On page 457 (section 13.4.4), it says:
    “It is possible to specify that a Sub-Process can be compensated without having to define the compensation handler. The Sub-Process attribute compensable, when set, specifies that default compensation is implicitly defined, which recursively compensates all successfully completed Activities within that Sub-Process, invoking them in reverse order of their forward execution.”

    The mentioned attribute “compensable” doesn’t appear in any Class Diagram or Table. In particular, Figure 10.29 and Table 10.20 (p.181), where the Sub-Process element is described.

    These paragraphs should be removed; or the attribute “compensable” should be added in Table 10.20 and Figure 10.29.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Thu, 8 Aug 2019 10:04 GMT

Contradiction about process data input and output allowed connection with data association

  • Key: BPMN11-95
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Page 213 states the following restriction about process data input and incoming data association:

    • Data Inputs MAY have incoming Data Associations:
      • If the Data Input is directly contained by the top-level Process, it MUST not be the target of Data Associations within the underlying model. Only Data Inputs that are contained by Activities or Events MAY be the target of Data Associations in the model.

    Page 215 states the following restriction about process data output and outgoing data association:

    • Data Outputs MAY have outgoing DataAssociations.
      • If the Data Output is directly contained by the top-level Process, it MUST not be the source of Data Associations within the underlying model. Only Data Outputs that are contained by Activities or Events MAY be the target of Data Associations in the model.

    So according to those, a Process Data Input MUST NOT have incoming data association and a process Data Output MUST NOT have outgoing data association.

    But on page 225, the following is stated:

    In the case of a Start Event, the Data Inputs of the enclosing process are available as targets to the DataOutputAssociations of the Event. This way the Process Data Inputs can be filled using the elements that triggered the Start Event.

    In the case of an End Event, the Data Outputs of the enclosing process are available as sources to the DataInputAssociations of the Event. This way the resulting elements of the End Event can use the Process Data Outputs as sources.

    So according to those paragraphs, a process data input might have incoming data association if the source is a start event and a process data output might have outgoing data association if the target is an end event.

    Those exceptions should be written on page 213 and 215 to avoid confusion.

  • Reported: BPMN 2.0 — Tue, 30 Apr 2019 20:49 GMT
  • Updated: Wed, 1 May 2019 18:49 GMT

Inclusive Gateway - circular cross-reference

  • Key: BPMN21-424
  • Status: open  
  • Source: University of Manchester ( Anthony Fargher)
  • Summary:

    On page 292 of the document, it says in the last line:

    [The] precise synchronization behavior of the Inclusive Gateway can be found on page 292.

    Obviously, we are on page 292 already.

    I assume the cross-reference should be to page 435.

    That said, the synchronization behavior of the Inclusive Gateway is not described on pages 435-436 - or not in enough detail to be useful.

  • Reported: BPMN 2.0 — Mon, 25 Mar 2019 14:49 GMT
  • Updated: Mon, 1 Apr 2019 18:54 GMT

Typo: Sequential for Parallel

  • Key: BPMN21-423
  • Status: open  
  • Source: Home ( Avisek Jena)
  • Summary:

    "A set of three vertical lines will be displayed at the bottom-center of the activity for sequential parallel Multi-Instances "

  • Reported: BPMN 2.0 — Thu, 6 Dec 2018 12:08 GMT
  • Updated: Mon, 14 Jan 2019 20:21 GMT

Typo: Outgoing for Incoming

  • Key: BPMN21-422
  • Status: open  
  • Source: Home ( Avisek Jena)
  • Summary:

    Table 2.3, Footnote 'a'
    It should probably be,
    "Multiple incoming connections are only allowed for converging Gateways"

  • Reported: BPMN 2.0 — Thu, 6 Dec 2018 07:38 GMT
  • Updated: Mon, 14 Jan 2019 20:20 GMT

"Flow Object" should be "Flow Node"

  • Key: BPMN21-421
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says in the (non normative) glossary:

    Flow Object - A graphical object that can be connected to or from a Sequence Flow. In a Process, Flow Objects are Events, Activities, and Gateways. In a Choreography, Flow Objects are Events, Choreography Activities, and Gateways.

    In the metamodel, the common superclass of Event, Activity, Choreography Activity, and Gateway is FlowNode. Does that mean, Flow Object and Flow Node are synonyms? Or is Flow Object the graphical object and Flow Node the model element? Both words are used throughout the specification, e.g.

    Table 7.3 displays the BPMN Flow Objects and shows how these objects can connect to one another through Sequence Flows.

    Of the types of Flow Node, only Activities, Gateways, and Events can be the target [of a Sequence Flow].

    Does it serve any purpose to have different names for the two? I find it confusing.

    Suggestion
    Replace all occurrences of "Flow Object" with "Flow Node".

  • Reported: BPMN 2.0.2 — Wed, 14 Nov 2018 17:22 GMT
  • Updated: Tue, 27 Nov 2018 20:46 GMT

Typo:

  • Key: BPMN21-420
  • Status: open  
  • Source: DAQRI ( Paul Chen)
  • Summary:

    Section 12.1.1 includes the text "miss-interpretations"

    The correct spelling is "misinterpretations"

  • Reported: BPMN 2.0.2 — Thu, 1 Nov 2018 23:40 GMT
  • Updated: Fri, 2 Nov 2018 14:01 GMT

Typo in example

  • Key: BPMN21-419
  • Status: open  
  • Source: DAQRI ( Paul Chen)
  • Summary:

    Section 6.1.1 includes this bullet point on conventions:

    • The cardinality of any content part is specified using the following operators:
    • <none> — exactly once

    I don't know whether this should be:
    • <1> — exactly once
    or
    • <one> — exactly once

    I could not find any examples of this syntax in the standard.

  • Reported: BPMN 2.0.2 — Thu, 1 Nov 2018 23:36 GMT
  • Updated: Fri, 2 Nov 2018 14:01 GMT

Diagram 8.1 looks amateurish

  • Key: BPMN21-418
  • Status: open  
  • Source: DAQRI ( Paul Chen)
  • Summary:

    Diagram 8.1 looks amateurish: the non-horizontal text labels are not aligned linearly, nor are the letters spaced evenly. The circular rings look like they were cut out of construction paper. This diagram doesn't have the quality one would expect to see in a formal international standard published by the OMG.

  • Reported: BPMN 2.0.2 — Thu, 1 Nov 2018 23:20 GMT
  • Updated: Fri, 2 Nov 2018 14:00 GMT

Wrong sub-section reference numbers

  • Key: BPMN21-417
  • Status: open  
  • Source: DAQRI ( Paul Chen)
  • Summary:

    The third paragraph of section 2.1 says:

    "The implementation claiming conformance to the Process Modeling Conformance type SHALL comply with all of the requirements set forth in sub clause 2.1. The implementation claiming conformance to the Process Execution Conformance type SHALL comply with all of the requirements set forth in sub clause 2.2. The implementation claiming conformance to the BPEL Process Execution Semantics Conformance type SHALL comply with all of the 2 Business Process Model and Notation (BPMN), v2.0.2 requirements set forth in sub clause 2.3. The implementation claiming conformance to the Choreography Conformance type SHALL comply with all of the requirements set forth in sub clause 2.4. The implementation is said to have BPMN Complete Conformance if it complies with all of the requirements stated in sub clauses 2.1, 2.2, 2.3, and 2.4."

    Each of the sub-section numbers referenced is off by 1. The correct paragraph text should be:

    "The implementation claiming conformance to the Process Modeling Conformance type SHALL comply with all of the requirements set forth in sub clause 2.2. The implementation claiming conformance to the Process Execution Conformance type SHALL comply with all of the requirements set forth in sub clause 2.3. The implementation claiming conformance to the BPEL Process Execution Semantics Conformance type SHALL comply with all of the 2 Business Process Model and Notation (BPMN), v2.0.2 requirements set forth in sub clause 2.4. The implementation claiming conformance to the Choreography Conformance type SHALL comply with all of the requirements set forth in sub clause 2.5. The implementation is said to have BPMN Complete Conformance if it complies with all of the requirements stated in sub clauses 2.2, 2.3, 2.4, and 2.5."

  • Reported: BPMN 2.0.2 — Thu, 1 Nov 2018 21:16 GMT
  • Updated: Fri, 2 Nov 2018 14:00 GMT

tDefinitions should have an extensionElements Element like in CMOF BaseElement

  • Key: BPMN21-416
  • Status: open  
  • Source: Inspire Technologies GmbH ( Harald Lübeck)
  • Summary:

    The definitions Element in the XSD should have an extensionElements like in the CMOF Definitions.

    <xsd:element name="definitions" type="tDefinitions"/>
    <xsd:complexType name="tDefinitions">
    <xsd:sequence>
    <xsd:element ref="import" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="extension" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="rootElement" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="bpmndi:BPMNDiagram" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="relationship" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="extensionElements" minOccurs="0" maxOccurs="1" />
    </xsd:sequence>

  • Reported: BPMN 2.0 — Fri, 12 Oct 2018 13:02 GMT
  • Updated: Tue, 16 Oct 2018 19:37 GMT

Inconsistent BPMNShape Attributes in tables

  • Key: BPMN21-415
  • Status: open  
  • Source: PragmaDev ( Mihal Brumbulli)
  • Summary:

    Collapsed activities have "None or isExpanded is false" as BPMNShape Attributes, while their corresponding Expanded form have "None or isExpanded is true".
    "None" should not appear in both forms as it creates confusion.
    This issue is present in the tables of Ad Hoc Sub-Process, Transaction, and Call Activity, but not in those of Sub-Process, Event Sub-Process, and Call Choreography Activity.
    Hence, the former group of tables should be corrected based on the later.

  • Reported: BPMN 2.0.2 — Thu, 19 Jul 2018 09:59 GMT
  • Updated: Tue, 7 Aug 2018 14:09 GMT

Typos - Incorrect internal references/pointers

  • Key: BPMN21-414
  • Status: open  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    (1) On page 204, the last sentence reads:
    The DataObject element inherits the attributes and model associations of FlowElement (see Table 8.44) and ItemAwareElement (Table 10.52). Table 10.54 presents the additional attributes of the DataObject element.

    However, the first Table reference should be to Table 10.51 (not 10.52), and the second should be to 10.52 (not 10.54).

    (2) On page 205, the first full sentence (not in a table) reads:
    The Data Object Reference element inherits the attributes and model associations of ItemAwareElement (Table 10.52) and FlowElement (see Table 8.44). Table 10.53 presents the additional attributes of the Data Object Reference element.

    However, the first Table reference should be to Table 10.51 (not 10.52). The reference to Table 10.53 is correct.

  • Reported: BPMN 2.0.1 — Mon, 16 Jul 2018 15:50 GMT
  • Updated: Tue, 7 Aug 2018 14:07 GMT

Inconsistent semantics of multiple none start events

  • Key: BPMN21-413
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    10.5.2 Start Event All Flow Objects that do not have an incoming Sequence Flow SHALL be instantiated when the Process is instantiated.

    There are some exceptions to this rule, but they don't touch the following discussion. Since Events are Flow Objects, this applies also to Start Events: When the process with multiple Start Events is instantiated, all Start Events of this instance are instantiated (i.e. they get a token).

    Further down it says however:

    There MAY be multiple Start Events for a given Process level. Each Start Event is an independent Event. That is, a Process instance SHALL be generated when the Start Event is triggered.

    That means on instantiating a process, each Start Event gets instantiated, which in turn instantiates a new process. I don't think this was intended.

    In the same section the semantics for calling global processes is defined differently (without mentioning it as an exception to the above rule):

    If the Process is used as a global Process and there are multiple None Start Events, then when flow is transferred from the parent Process to the global Process, only one of the global Process’s Start Events will be triggered.

    So called global Processes are treated differently from Subprocesses (I know, somewhere else it is stated, that a Subprocess can only have a unique Start Event - a rule that is contradicted in the immediately following sentence). I think this is confusing.

    Suggestion
    Change the above sentence

    All Flow Objects that could have but do not have an incoming Sequence Flow SHALL be instantiated when the Process is instantiated.

    This way, multiple Start Events are always alternative. This would be in line with many other sections of the specification:

    13.2 Process Instantiation and Termination A Process is instantiated when one of its Start Events occurs. Each occurrence of a Start Event creates a new Process Instance [...] Note that two Start Events are alternative [...]

    and

    13.3.4 Sub-Process/Call Activity If the Sub-Process does not have incoming Sequence Flows but Start Events that are target of Sequence Flows from outside the Sub-Process, the Sub-Process is instantiated when one of these Start Events is reached by a token. Multiple such Start Events are alternative. [...]

  • Reported: BPMN 2.0.2 — Thu, 28 Jun 2018 18:01 GMT
  • Updated: Tue, 7 Aug 2018 14:03 GMT

Attribute called

  • Key: BPMN21-412
  • Status: open  
  • Source: Salient Process ( Neil Kolban)
  • Summary:

    The text today reads:

    An ItemAwareElement MAY be underspecified, meaning that the structure attribute of its ItemDefinition is optional if the modeler does
    not wish to define the structure of the associated data.

    I believe it should be:

    An ItemAwareElement MAY be underspecified, meaning that the structureRef attribute of its ItemDefinition is optional if the modeler does
    not wish to define the structure of the associated data.

    The ItemDefininition doesn't have an attribute called "structure".

  • Reported: BPMN 2.0.2 — Thu, 7 Jun 2018 19:15 GMT
  • Updated: Tue, 12 Jun 2018 15:11 GMT

Relationship relates CMOF::Element, not Artifact

  • Key: BPMN21-411
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says about External Relationships:

    These extensions’ intention is to extend the semantics of a given BPMN Artifact.

    The following text then refers consistently to BPMN Artifacts.

    The metamodel however specifies that a Relationship links all kinds of CMOF::Elements, not just BPMN::Artifacts.

    My guess is, that "BPMN Artifacts" was meant to read "BPMN elements", e.g.

    typed relationships that enable BPMN and non-BPMN Artifacts to be related

    should probably read

    typed relationships that enable BPMN and non-BPMN Artifacts elements to be related

  • Reported: BPMN 2.0.2 — Thu, 31 May 2018 12:33 GMT
  • Updated: Tue, 12 Jun 2018 15:11 GMT

Unclear how to add new Artifact Types

  • Key: BPMN21-410
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says about Extension:

    It provides a set of extension elements, which allows BPMN adopters to attach additional attributes and elements to standard and existing BPMN elements.

    In other words, extension can only add something to existing elements, but not create new element types.
    However about Artifacts it says:

    A modeler or modeling tool MAY extend a BPMN diagram and add new types of Artifacts to a Diagram.

    Given the extension mechanism, it is unclear, how new types of Artifacts can be added. And since the Metaclass Artifact is abstract, it is not possible to use the generic Artifact and extend it to create something resembling a new type. A modeler would always need to specify the concrete subclass, such as Group or TextAnnotation and thus inherit attributes and semantics he probably doesn't need.
    So either the sentence is wrong, or there is another extension mechanism, that needs some explanation here.

  • Reported: BPMN 2.0.2 — Thu, 31 May 2018 12:20 GMT
  • Updated: Tue, 12 Jun 2018 15:11 GMT

Derivation of categorizedFlowElements is only given by visual nesting

  • Key: BPMN21-409
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The specification says:

    categorizedFlowElements:FlowElement [0..*] - The FlowElements attribute identifies all of the elements (e.g., Events, Activities, Gateways, and Artifacts) that are within the boundaries of the Group.

    This attribute is derived and the elements are found by looking at the diagram and determining, which elements are within the boundaries of the dashed box representing the Group. As far as I know, this is the only place in the specification, where the location of an element in the diagram is relevant for the semantics. I think there should be a more formal way.
    Further down the specification says:

    Groups are one way in which Categories of objects can be visually displayed on the diagram.

    If the only way to define a group is to show it in the diagram (as the first sentence implies), this sentence is wrong.

  • Reported: BPMN 2.0.2 — Wed, 30 May 2018 13:24 GMT
  • Updated: Tue, 12 Jun 2018 15:10 GMT

Artifact used as an example for FlowElement

  • Key: BPMN21-371
  • Legacy Issue Number: 19614
  • Status: open  
  • Source: Itesoft ( Benjamin Michel)
  • Summary:

    On page 71 of the spec, in the Category chapter, in the Table 8.23, the attribute categorizedFlowElements of the CategroyValue element is descibed as follow :

    categorizedFlowElements: FlowElement [0..*]
    The FlowElements attribute identifies all of the elements (e.g.,Events, Activities, Gateways, and Artifacts) that are within the boundaries of the Group.
    But Artifact is not a FlowElement, so it must not appear as an example of the latter

  • Reported: BPMN 2.0 — Wed, 24 Sep 2014 04:00 GMT
  • Updated: Wed, 30 May 2018 13:26 GMT

Page 72. Artifact incorrectly identified as a Flow Element

  • Key: BPMN21-181
  • Legacy Issue Number: 15578
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 8.23. Row “categorizedFlowElements”

    It says
    “The FlowElements attribute identifies all of the elements (e.g., Events, Activities, Gateways, and Artifacts) that are within the boundaries of the Group.”

    The name of the model association is “categorizedFlowElements”, not “FlowElements”.

    Model Association “categorizedFlowElements” is of type “FlowElement”, but “Artifact” is not a “FlowElement” (see Figure 8.8, page 66; and Figure 8.22, page 87). So “Artifacts” cannot be examples of elements identified by “categorizedFlowElements”.

    Then, it should say
    “The categorizedFlowElements model association identifies all of the Flow Elements (e.g., Events, Activities, and Gateways) that are within the boundaries of the Group.”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Wed, 30 May 2018 13:26 GMT

Some of the descriptions in the bpmnElement column of the table are incorrect

  • Key: BPMN21-408
  • Status: open  
  • Source: PragmaDev ( Mihal Brumbulli)
  • Summary:

    The description in the bpmnElement column of the table for the Sequence Flow, Conditional Sequence Flow, and Default Sequence Flow elements is incorrect. default neither is an attribute of the listed elements, nor it is of type boolean. It belongs to the element referenced by the sourceRef attribute, and can either reference an element or be undefined (it cannot be false).

  • Reported: BPMN 2.0.2 — Tue, 20 Mar 2018 16:36 GMT
  • Updated: Fri, 6 Apr 2018 19:33 GMT

Incorrect table column header

  • Key: BPMN21-407
  • Status: open  
  • Source: PragmaDev ( Mihal Brumbulli)
  • Summary:

    In the table in pg 411, the rightmost column header is named BPMNShape Attributes. However this should be a table concerning BPMNEdge, and thus the header should be named BPMNEdge Attributes.

  • Reported: BPMN 2.0 — Tue, 20 Mar 2018 14:25 GMT
  • Updated: Fri, 6 Apr 2018 19:29 GMT

Add start and intermediate events of type "User"

  • Key: BPMN21-406
  • Status: open  
  • Source: Atom Software Pty Ltd ( Paul Hopkins)
  • Summary:

    Introduce start and intermediate events of type “User”. Events of type User can be used to identify user initiated actions for example pressing a door-bell or selecting a menu item on a computer. At the moment the BPMN specification only allows these events to be modelled as conditional events or alternatively through the BPMN extension mechanism. Unfortunately the majority of vendors do not support the extension mechanism, they only support the main specification. Adding this to the main specification would greatly improve the BPMN's applicability and usability.

  • Reported: BPMN 2.0.2 — Mon, 19 Mar 2018 11:57 GMT
  • Updated: Fri, 6 Apr 2018 19:29 GMT

Outgoing sequence flows from event gateways should allow conditional expressions

  • Key: BPMN21-405
  • Status: open  
  • Source: Atom Software Pty Ltd ( Paul Hopkins)
  • Summary:

    Allow event-based gateways to have outgoing conditional flows. Section 10.6.6 of the BPMN specification v2.0.2 states that “The outgoing sequence flows of the event gateway must not have a conditional expression”. I suggest that this clause be changed because an initiating event-based gateway is an excellent way to model, for example, a menu, where not all items on a menu are available all the time (as they might depend upon user roles or the application’s state). With outgoing conditional flows from the event-based gateway this situation can be modelled easily. Of course modelling a menu is only one such scenario, and I appreciate that the conditions to be applied to the conditional flows could instead be applied to the events following the event-based gateway, but the use of conditional flows is simply a cleaner implementation.

  • Reported: BPMN 2.0.2 — Mon, 19 Mar 2018 11:52 GMT
  • Updated: Fri, 6 Apr 2018 19:28 GMT

Probable contradiction: Implicit compensation and Throwing Compensation Events

  • Key: BPMN21-403
  • Status: open  
  • Source: omninet.de ( Frank Munkert)
  • Summary:

    In table 10.88 "End Event Types", the table row with header "Compensation" contains this statement:
    "To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process."
    The same applies to Table 10.89 "Intermediate Event Types in Normal Flow" on page 251.

    On page 234, however, there is this statement: "The compensation handler is either user defined or implicit."

    The two statements, taken together, would mean that an implicit compensation handler cannot be called by a Throwing Compensation Event.

    This probably is not intended.

    Either the concept of implicit compensation should be removed alltogether (which is not my preference), or alternatively the sentence
    "To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process."
    should be changed like this:
    "To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process, or the Activity must be a Sub-Process or a Call Activity calling a Process."
    because sub-processes and called processes always are implicitly compensable (unless the compensable attribute is set to false).

  • Reported: BPMN 2.0.2 — Thu, 5 Oct 2017 09:46 GMT
  • Updated: Wed, 18 Oct 2017 06:09 GMT

Define "Cancellation" more precisely

  • Key: BPMN21-404
  • Status: open  
  • Source: omninet.de ( Frank Munkert)
  • Summary:

    Chapter "10.5.1 Concepts" contains the following statement on page 234:
    "Cancellation will terminate all running Activities and compensate all successfully completed Activities in the Sub-
    Process it is applied to. If the Sub-Process is a Transaction, the Transaction is rolled back."

    The standard, however, is a little bit vague about what actually triggers cancellation.
    Here are just a few examples of scenarios in whose descriptions the standard applies the term "cancel":

    • Throwing Cancel Event
    • 'cancelRemainingInstances' attribute of Ad-Hoc Sub-Processes
    • 'completionCondition' attribute of Multi-Instance Activities
    • 'condition' attribute of ComplexBehaviorDefinitions
    • 'isInterrupting' attribute of Start Events in Event Sub-Processes
    • 'cancelActivity' attribute of boundary events

    Do all these scenarios trigger a cancellation in the sense of the above mentioned statement?
    This should be explained more precisely in the standard.

    Furthermore, on page 301, there is this statement:
    "Cancellation in turn can result in compensation of already successfully completed
    portions of an active Activity, in case of a Sub-Process."

    Why does the statement use "can result" instead of e.g. "always results"?
    The standard should describe precisely under which circumstances cancellation results in compensation, and the circumstances under which cancellation does not result in compensation.

  • Reported: BPMN 2.0.2 — Thu, 5 Oct 2017 12:47 GMT
  • Updated: Wed, 18 Oct 2017 05:55 GMT

Intermediate Compensation Events can have outgoing Sequence Flows

  • Key: BPMN21-402
  • Status: open  
  • Source: omninet.de ( Frank Munkert)
  • Summary:

    In chapter 10.5.4 "Intermediate Event", on page 258, there is the following sentence:
    "An exception to this: an Intermediate Event with a Compensation trigger MUST NOT have an outgoing Sequence Flow (it MAY have an outgoing Association)."

    This statement seems to be wrong. For example, figure 10.32 on page 176 shows several throwing Intermediate Events with outgoing sequence flows.

  • Reported: BPMN 2.0.2 — Wed, 4 Oct 2017 08:45 GMT
  • Updated: Wed, 4 Oct 2017 20:13 GMT

Wrong Word - Says "sequential", Should Say "parallel"

  • Key: BPMN21-401
  • Status: open  
  • Source: DXC Technology ( Craig Hawkins)
  • Summary:

    The last sentence of the description text for the "Multiple Instances" activity symbol is incorrect:

    AS-IS
    A set of three vertical lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see lower figure to the right).

    SHOULD BE
    A set of three vertical lines will be displayed at the bottom-center of the activity for parallel Multi-Instances (see lower figure to the right).

  • Reported: BPMN 2.0 — Mon, 11 Sep 2017 22:36 GMT
  • Updated: Tue, 12 Sep 2017 20:51 GMT

Execution semantics of Activity with conditional outgoing Sequence Flows

  • Key: BPMN12-35
  • Status: open  
  • Source: Munkert Software Consulting ( Frank Munkert)
  • Summary:

    In chapter "13.3.2 Activity", on page 429, there is the following bullet point:

    "* After all completion dependencies have been fulfilled, the state of the Activity changes to Completed. The outgoing
    Sequence Flows becomes active and a number of tokens, indicated by the attribute CompletionQuantity, is
    placed on it. If there is more than one outbound Sequence Flows for an Activity, it behaves like an implicit
    Parallel Gateway."

    The last cited sentence does not take into consideration that the outgoing sequence flows might have conditions. Therefore, the statement "behaves like an implicit Parallel Gateway" is not entirely correct.

    Suggestion for a revised version of the last sentence:
    If there is more than one outbound Sequence Flows for an Activity, and if all outbound sequence flows are unconditional, the Activity behaves like an implicit Parallel Gateway. If there conditional outgoing sequence flows, the behavior is as described in "13.3.1 Sequence Flow Considerations".

  • Reported: BPMN 2.0.2 — Mon, 29 May 2017 08:38 GMT
  • Updated: Tue, 27 Jun 2017 15:16 GMT

p.172 Reference pointing to wrong figure, p.174/175 Event marker missing in figure

  • Key: BPMN21-400
  • Status: open  
  • Source: Combitech Systems AB ( Hakan Davidsson)
  • Summary:

    p.172: "... Sub-Process marker, seen in Figure 10.24 ..." Should be Figure 10.25

    p.174/175: p.174, "... its Start Event will be used as a marker in the upper left corner of the shape (see Figure 10.30)." There is no marker in Figure 10.30 (I suppose it should be the Message Event from Figure 10.31).

  • Reported: BPMN 2.0.2 — Thu, 3 Nov 2016 11:35 GMT
  • Updated: Fri, 4 Nov 2016 20:55 GMT

Inconsistent default value of dataStore/@isUnlimited

  • Key: BPMN21-399
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    Table 10.55 (Data Store attributes) defines the default value of isUnlimited as false whereas the XML Schema says:

    <xsd:attribute name="isUnlimited" type="xsd:boolean" default="true"/>
    

    Proposal:
    In Table 10.55 (Data Store attributes) on page 208 (PDF 238) replace:
    > isUnlimited: boolean = false
    with:
    > isUnlimited: boolean = false

  • Reported: BPMN 2.0.2 — Tue, 13 Sep 2016 17:55 GMT
  • Updated: Tue, 27 Sep 2016 20:16 GMT

Clarification needed regarding converging exclusive gateway and slash marker

  • Key: BPMN21-398
  • Status: open  
  • Source: Munkert Software Consulting ( Frank Munkert)
  • Summary:

    On page 290, in section "10.6.2 Exclusive Gateway", there is the following text:
    "A converging Exclusive Gateway is used to merge alternative paths. Each incoming Sequence Flow token is routed
    to the outgoing Sequence Flow without synchronization."

    On page 435, in section "13.4.2 Exclusive Gateway (Exclusive Decision (data-based) and Exclusive Merge)", there is the following text in the table:
    "Exception Issues - The exclusive gateway throws an exception in case all conditions evaluate to false and a default flow has not been specified."

    I.e. according to the table, in order not to throw an exception, a converging exclusive gateway would need to have a default flow marker on its single outgoing sequence flow. This seems to be a contradiction to the description in section 10.6.2. Therefore, this should be clarified in both sections, e.g. using a sentence like this: "The single outgoing sequence flow of a merging exclusive gateway is implicitly assumed to be the default sequence flow. A slash marker MAY be shown in diagrams for such sequence flows."

    Without such a clarification, BPMN process diagrams where an outgoing sequence flow of a converging exclusive gateway has no slash marker would be wrong. Since those diagrams are very common (e.g. OMG's "BPMN 2.0 by Example", v1.0, page 36), it should be explicitly mentioned that omitting the slash marker is allowed.

  • Reported: BPMN 2.0.2 — Tue, 16 Aug 2016 06:35 GMT
  • Updated: Fri, 19 Aug 2016 13:25 GMT

Task Description -- Internal Conflict

  • Key: BPMN21-397
  • Status: open  
  • Source: US Army ( Michael Gilsdorf)
  • Summary:

    Sect 10.3.3 states, "A Task is used when the work in the Process cannot be broken down to a finer level of detail."

    However, the task definition in the glossary states, "A Task is used when the work in the Process is not broken down to a finer level of Process Model detail."

    The phrase, "cannot be broken down" is much different than the phrase, " is not broken down". The latter suggests that an activity could be broken down further, but was not.

    The glossary definition is correct since a task can often be broken down into tiny actions (e.g., Click the left mouse button), but a person modeling the process may choose not to model to that low a level. Thus, a task is the lowest level shown on a diagram, but may not necessarily be the lowest possible level.

    Recommend that the sentence in Sect 10.3.3 be changed to be consistent with the one in the glossary. As an option, you also may wish to make that statement, "Any conflicts between the glossary and other parts of the specification, the glossary takes precedence."

  • Reported: BPMN 2.0.2 — Sat, 6 Aug 2016 18:49 GMT
  • Updated: Wed, 10 Aug 2016 14:06 GMT

Missing Element in BPMN 2.0.2 ?

  • Key: BPMN21-396
  • Legacy Issue Number: 19887
  • Status: open  
  • Source: Anonymous
  • Summary:

    I refer to BPMN Spec. Version 2.0.2.

    I really miss the data storage element which is supported by all BPMN tools that I know:

    in Spec. chapter 7.3.1 or 7.3.2.

    What happened with this element ??

  • Reported: BPMN 2.0b1 — Thu, 17 Mar 2016 04:00 GMT
  • Updated: Tue, 21 Jun 2016 12:50 GMT

Sequential and Parallel multiple instances are have same description

  • Key: BPMN21-395
  • Status: open  
  • Source: Tech Mahindra ( Abraham Sundaresan J.E)
  • Summary:

    A set of three horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see upper figure to the right).

    A set of three vertical lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see lower figure to the right).

    This should read as

    A set of three vertical lines will be displayed at the bottom-center of the activity for Parallel Multi-Instances (see lower figure to the right).

  • Reported: BPMN 2.0 — Fri, 6 May 2016 10:58 GMT
  • Updated: Fri, 6 May 2016 15:59 GMT

data storage element is missing in overview

  • Key: BPMN21-394
  • Status: open  
  • Source: Diartis AG ( Daniel Canonica)
  • Summary:

    In the overview 'Basic BPMN Modeling Elements', table 7.1, the data storage element (hard disk Symbol) is missing. (Refer to section 10.4.1, Figure 10.54).

  • Reported: BPMN 2.0.2 — Wed, 13 Apr 2016 13:13 GMT
  • Updated: Wed, 13 Apr 2016 15:36 GMT

Confusion over dataOutput attributes

  • Key: BPMN21-393
  • Status: open  
  • Source: Cognitect ( David Chelimsky)
  • Summary:

    Table 10.60, which describes the attributes of DataOutput objects, describes "outputSetwithOptional" with "Each OutputSet that uses this DataOutput can determine if the Activity can complete executing without producing this DataInput. This attribute lists those OutputSets." I believe that "DataInput" should be replaced with "DataOutput".

    Similarly, the same table describes the "outputSetWithWhileExecuting" attribute with "Each OutputSet that uses this DataInput can determine if the Activity can produce this DataOutput while executing. This attribute lists those OutputSets." Same correction applies.

  • Reported: BPMN 2.0.2 — Mon, 29 Feb 2016 21:57 GMT
  • Updated: Wed, 2 Mar 2016 07:12 GMT

Multiple Instances - Both types of diagram described as Sequential

  • Key: BPMN21-392
  • Legacy Issue Number: 19839
  • Status: open  
  • Source: Anonymous
  • Summary:

    Textual description of the two Multiple Instance shape types (2nd column) describe both shapes as "Sequential", whereas one should be "Sequential", and the other "Parallel".

    Text copied belowL

    "A set of three horizontal lines will be displayed at the bottom-center of the activity for SEQUENTIAL Multi-Instances (see upper figure to the right).

    "A set of three vertical lines will be displayed at the bottom-center of the activity for SEQUENTIAL Multi-Instances (see lower figure to the right)."

  • Reported: BPMN 2.0b1 — Mon, 12 Oct 2015 04:00 GMT
  • Updated: Wed, 14 Oct 2015 16:35 GMT

Unclear execution semantics of MI activities with complex behavior

  • Key: BPMN21-391
  • Legacy Issue Number: 19831
  • Status: open  
  • Source: Munkert Software ( Frank Munkert)
  • Summary:

    "Table 10.31 - ComplexBehaviorDefinition attributes and model associations" contains the following text: "This attribute defines a boolean Expression that when evaluated to true,
    cancels the remaining Activity instances and produces a token."

    In chapter "13.3.7 Multiple Instances Activity", where the execution semantics are described, however, there is no mentioning that multi-instance activities with complex behavior cancel instances as soon the ComplexBehaviorDefinition's condition becomes true.

    Probably the text fragment "cancels the remaining Activity instances and" in the table is wrong and should be removed. Otherwise, the execution semantics chapter should be extended accordingly.

  • Reported: BPMN 2.0b1 — Wed, 9 Sep 2015 04:00 GMT
  • Updated: Wed, 9 Sep 2015 17:23 GMT

Table 8.51 ref error

  • Key: BPMN21-390
  • Legacy Issue Number: 19826
  • Status: open  
  • Source: Anonymous
  • Summary:

    "Table 8.51 presents the additional model associations for the Resource element."
    should be
    "Table 8.49 presents the additional model associations for the Resource element."

    "Table 8.51 presents the additional model associations for the
    ResourceParameter element."
    should be
    "Table 8.50 presents the additional model associations for the
    ResourceParameter element."

  • Reported: BPMN 2.0b1 — Fri, 7 Aug 2015 04:00 GMT
  • Updated: Fri, 7 Aug 2015 15:31 GMT

Wrong table reference number

  • Key: BPMN21-389
  • Legacy Issue Number: 19766
  • Status: open  
  • Source: ERP Bulgaria Ltd. ( Ivan Argentinski)
  • Summary:

    There are actually 2 errors (wrong Table numbers) in the last 2 sentences on the page:

    "The DataObject element inherits the attributes and model associations of FlowElement (see Table 8.44) and
    ItemAwareElement (Table 10.52). Table 10.54 presents the additional attributes of the DataObject element."

    The correct Table numbers should be:

    • ItemAwareElement (Table 10.51)
    • DataObject (Table 10.52)
  • Reported: BPMN 2.0.2 — Sun, 31 May 2015 04:00 GMT
  • Updated: Mon, 22 Jun 2015 06:12 GMT

Contradiction - can or cannot show Data Object multiple times on a diagram

  • Key: BPMN21-388
  • Legacy Issue Number: 19771
  • Status: open  
  • Source: Anonymous
  • Summary:

    p.206 states:

    Visual representations of Data Objects
    Data Object can appear multiple times in a Process diagram. Each of these appearances references the same Data Object instance. Multiple occurrences of a Data Object in a diagram are allowed to simplify diagram connections.

    p.368 states:

    Multiple depictions of a specific BPMN element in a single diagram is NOT allowed, except for Participants in a choreography (i.e., Participant Bands). For example, it is not allowed to depict a Task twice in the same diagram, but it is allowed to depict the same Task in two different diagrams.

    This seems like a contradiction. Only one of the above should be true.

  • Reported: BPMN 2.0b1 — Sun, 31 May 2015 04:00 GMT
  • Updated: Mon, 1 Jun 2015 14:27 GMT

Wrong table reference number

  • Key: BPMN21-387
  • Legacy Issue Number: 19770
  • Status: open  
  • Source: Anonymous
  • Summary:

    "Table 10.60 presents the additional attributes and model associations of the
    DataInput element."

    should be:

    "Table 10.60 presents the additional attributes and model associations of the
    DataOutput element."

  • Reported: BPMN 2.0b1 — Sun, 31 May 2015 04:00 GMT
  • Updated: Mon, 1 Jun 2015 14:27 GMT

Wrong table reference number

  • Key: BPMN21-386
  • Legacy Issue Number: 19768
  • Status: open  
  • Source: Anonymous
  • Summary:

    "Table
    10.54 presents the additional attributes of the Property element."

    should be:
    "Table
    10.57 presents the additional attributes of the Property element."

  • Reported: BPMN 2.0b1 — Sun, 31 May 2015 04:00 GMT
  • Updated: Mon, 1 Jun 2015 14:27 GMT

Wrong table reference number

  • Key: BPMN21-384
  • Legacy Issue Number: 19769
  • Status: open  
  • Source: Anonymous
  • Summary:

    "Figure 10.54 presents the additional attributes and model associations of the
    InputOutputSpecification element."

    I believe, this should not even be a figure, but a Table, and with different number:

    "Table 10.58 presents the additional attributes and model associations of the
    InputOutputSpecification element."

  • Reported: BPMN 2.0b1 — Sun, 31 May 2015 04:00 GMT
  • Updated: Mon, 1 Jun 2015 14:27 GMT

Wrong name of object

  • Key: BPMN21-385
  • Legacy Issue Number: 19767
  • Status: open  
  • Source: Anonymous
  • Summary:

    "Table 10.54
    presents the additional attributes and model associations of the DataObject element."

    should be:
    "Table 10.54
    presents the additional attributes and model associations of the DataState element."

  • Reported: BPMN 2.0b1 — Sun, 31 May 2015 04:00 GMT
  • Updated: Mon, 1 Jun 2015 14:27 GMT

Attribute name "error" should actually by "errorRef"

  • Key: BPMN21-383
  • Legacy Issue Number: 19765
  • Status: open  
  • Source: Anonymous
  • Summary:

    Table 10.96 states that there is attribute, called "error", while the XSD schema contains attribute "errorRef".

  • Reported: BPMN 2.0b1 — Fri, 29 May 2015 04:00 GMT
  • Updated: Fri, 29 May 2015 22:14 GMT

Figure 10.57 does not show that InputOutputSpecification derives from BaseElement

  • Key: BPMN21-382
  • Legacy Issue Number: 19763
  • Status: open  
  • Source: Anonymous
  • Summary:

    Figure 10.57 does not show that InputOutputSpecification derives from BaseElement.

    The textual description and the related XSD schema correctly show that InputOutputSpecification derives from BaseElement. However, figure 10.57 does not have an arrow for this inheritance.

  • Reported: BPMN 2.0b1 — Thu, 28 May 2015 04:00 GMT
  • Updated: Thu, 28 May 2015 15:38 GMT

Default value of DataStore.isUnlimited differs between Table 10.55 and XML Schema

  • Key: BPMN21-381
  • Legacy Issue Number: 19762
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    Table 10.55 defines the default value of DataStore.isUnlimited to be false:
    isUnlimited : boolean = false

    However, the XML Schema says:
    <xsd:attribute name="isUnlimited" type="xsd:boolean" default="true"/>

    Proposal:
    Change the XML Schema to:
    <xsd:attribute name="isUnlimited" type="xsd:boolean" default="false"/>

  • Reported: BPMN 2.0b1 — Wed, 27 May 2015 04:00 GMT
  • Updated: Wed, 27 May 2015 15:09 GMT

message and error ref in tOperation does not define the correct type name

  • Key: BPMN21-380
  • Legacy Issue Number: 19745
  • Status: open  
  • Source: Anonymous
  • Summary:

    In Table 8.66, the spec says the inMessageRef and outMessageRef should be type of Message, however, in the xml schema below (table 8.68), the element type of inMessageRef and outMessageRef is a QName, not Message. similar issue happens on errorRef as well. table 8.66 says errorRef type should be Error, but the schema defines its type to a QName.

  • Reported: BPMN 2.0 — Fri, 17 Apr 2015 04:00 GMT
  • Updated: Tue, 21 Apr 2015 19:41 GMT

Wrong clause reference

  • Key: BPMN21-379
  • Legacy Issue Number: 19736
  • Status: open  
  • Source: Anonymous
  • Summary:

    1. In the first sentence "Special type of Process Execution Conformance that supports the BPMN mapping to WS-BPEL as specified in sub clause
    15.1 can claim BPEL Process Execution Conformance." I believe that "clause 15.1" should actually be "clause 14.1".

    2. I am not sure about possible error of the same type in the previous chapter: chapter 2.3.1 contains reference to 14.2.2, it might be 13.3.2.

  • Reported: BPMN 2.0 — Thu, 26 Mar 2015 04:00 GMT
  • Updated: Thu, 26 Mar 2015 13:26 GMT

Table 7.2 wrong reference to type of multi-instance

  • Key: BPMN21-377
  • Legacy Issue Number: 19735
  • Status: open  
  • Source: Anonymous
  • Summary:

    In table 7.2, page 37 it's written:

    ...A set of three
    horizontal lines will be displayed at the
    bottom-center of the activity for sequential
    Multi-Instances (see upper figure to the right).
    A set of three vertical lines will be displayed at
    the bottom-center of the activity for sequential
    Multi-Instances (see lower figure to the right).

    It should say:
    ...A set of three
    horizontal lines will be displayed at the
    bottom-center of the activity for sequential
    Multi-Instances (see upper figure to the right).
    A set of three vertical lines will be displayed at
    the bottom-center of the activity for parallel
    Multi-Instances (see lower figure to the right).

  • Reported: BPMN 2.0 — Fri, 20 Mar 2015 04:00 GMT
  • Updated: Fri, 20 Mar 2015 18:08 GMT

Text User Task instead of Manual Task

  • Key: BPMN2-301
  • Legacy Issue Number: 15681
  • Status: closed  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    The first sentence on page 171 states:
    The User Task inherits the attributes and model associations of Activity (see Table 10.3), but does not have any
    additional attributes or model associations.

    I think that in the mentioned sentence "User Task" should be replaced by "Manual Task".
    The sentence is still in the section of the Manual Task and the User Tasks starts afterwards also providing its own statement stating that the User Task inherits the attributes and model associtations of Activity.

  • Reported: BPMN 2.0 — Mon, 4 Oct 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0.1
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 9 Mar 2015 21:32 GMT

Page 345. “Sub-Choreographies” instead of “Choreography Activities”

  • Key: BPMN2-300
  • Legacy Issue Number: 15594
  • Status: closed  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “Both Sub-Choreographies can have standard loops and multi-instances. Examples of Choreography Activities with the appropriate markers can be seen in Figure 11.12 and Figure 11.22.”

    The purpose of this paragraph is to explain that both Choreography Task and Sub-Choreography can have loop markers. Figure 11.12 shows Choreography Task Markers, and Figure 11.22 shows Sub-Choreography Markers

    Then, it should say:
    “Both Choreography Activities can have standard loops and multi-instances. Examples of Choreography Activities with the appropriate markers can be seen in Figure 11.12 and Figure 11.22.”

    “Sub-Choreographies” should be replaced by “Choreography Activities”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0.1
  • Disposition Summary:
  • Updated: Mon, 9 Mar 2015 21:32 GMT

None Events not for catch Intermediate Event

  • Key: BPMN2-299
  • Legacy Issue Number: 15687
  • Status: closed  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    The following text is from page 280:
    There are three (3) variations of None
    Events: a Start Event, a catch Intermediate Event, and an End Event (see Figure 10.91).

    The catch None Intermediate Event MUST only be used in normal flow and, thus, MAY NOT be attached to the boundary of an Activity.

    However, according to Table 10.93 and the former text, a None-Trigger is allowed for a Start Event, End Event and for a throw Intermediate Event but not for a catch Intermediate Event.

  • Reported: BPMN 2.0 — Thu, 7 Oct 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0.1
  • Disposition Summary:

    resolved

  • Updated: Mon, 9 Mar 2015 04:11 GMT

Conditional Event instead of Error Event

  • Key: BPMN2-298
  • Legacy Issue Number: 15686
  • Status: closed  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    On page 273, after the heading Error Event, the following text is displayed: Figure 10.79 shows the variations of Conditional Events.

    However, the actual section describes Error Events and Figure 10.79 also shows Error Events.

  • Reported: BPMN 2.0 — Thu, 7 Oct 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0.1
  • Disposition Summary:

    resolved

  • Updated: Mon, 9 Mar 2015 04:11 GMT

Page 181. Wrong reference to table 10.20

  • Key: BPMN2-297
  • Legacy Issue Number: 15463
  • Status: closed  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “Table 10.3 presents the additional attributes of the Sub-Process element:”

    It should say
    “Table 10.20 presents the additional attributes of the Sub-Process element:”

    “Table 10.3” should be replaced by “Table 10.20”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0.1
  • Disposition Summary:

    resolved

  • Updated: Mon, 9 Mar 2015 04:11 GMT

Conflicting content regarding choreographies.

  • Key: BPMN2-296
  • Legacy Issue Number: 17094
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I was going through the BPMN 2.0 Specifications and found some conflicting
    content regarding choreographies. In section 7.4 Use of Text, Color, Size,
    and Lines in a Diagram, the third indented point of the bullet "The fills
    that are used for the graphical elements MAY be white or clear" states
    that "Participant Bands for Choreography Tasks and Sub-Choreographies that
    are not the initiator of the activity MUST have a light fill. This does
    not seem to be consistent with what is depicted in Figure 7.7 An example
    of a stand-alone choreography diagram. It is also not consistent with the
    discussions on Choreography in the same document in Section 11.4.1
    Choreography Task.

  • Reported: BPMN 2.0b1 — Wed, 1 Feb 2012 05:00 GMT
  • Disposition: Closed; No Change — BPMN 2.0
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Sat, 7 Mar 2015 08:48 GMT

Page 203, Table 10-26, MultiInstance Activity: What is the intended use case if the catching boudnary event is interrupt

  • Key: BPMN2-295
  • Legacy Issue Number: 14539
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Page 203, Table 10-26, multiInstanceLoopCharacteristics: I believe that the motivation behind having events thrown in coordination with the completion of instances of multiInatnce activity is to have non-interrupting boundary events to carry out some desired ackownledgements (or other defined activites), but if the catching boudnary event is interrupting, the alternate flow will be followed potentially resulting in un-expected or suspected behavior.

    What is the intended use case if the catching boudnary event is interrupting?

  • Reported: BPMN 2.0b1 — Thu, 8 Oct 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The design of the MI activity was done with the use case in mind that the catching boundary event is non-interrupting.
    However, we do not see a strong reason to rule out that the catching boundary event could be interrupting.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 23:15 GMT

BPMN CMOF File problems

  • Key: BPMN2-246
  • Legacy Issue Number: 15031
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    The Beta-1 CMOF files on the server (spec/BPMN/2.0/20090501/cmof.xmi <http://www.omg.org/spec/BPMN/2.0/20090501/cmof.xmi>, spec/BPMN/2.0/20090501/Infrastructure.xmi <http://www.omg.org/spec/BPMN/2.0/20090501/Infrastructure.xmi>, spec/BPMN/2.0/20090501/Semantic.xmi <http://www.omg.org/spec/BPMN/2.0/20090501/Semantic.xmi>) are invalid in several ways:

    (1) The schemaLocation for the UML Infrastructure schema is an EMF URI that returns Error 404. The only elements actually used in the BPMN model are the primitive types. It is preferable to provide only the standard UML URI and assume that any CMOF implementation will have a known source for it.

    (2) The modularization of the Infrastructure Package makes no sense.
    The Infrastructure Package must import Core::Foundation in order to define the associations from Definitions to RootElements, Relationships, and Extensions. Otherwise those data types are undefined. And in the current model, only the association ends owned by Definitions are in the Infrastructure Package; the associations themselves and the non-navigable ends are owned by the Foundation Package.
    [It is not clear what religious motive caused Infrastructure to be removed from the Core Package in the first place. It is documented as part of the Core in the specification. Definitions is a subclass of BaseElement and inheriting the identifier documentation is important.
    If you really want to separate Definitions (and Imports) for some reason, then you need to split Definitions into an Infrastructure version containing only the properties that are wholly contained in the Infrastructure package and a Core version that has the properties that bind Definitions to Foundation elements, including the generalization, and then packageMerge Infrastructure into Core. But then the "reusable" thing in the Infrastructure package has neither a formal id, nor any associated text.]

    (3) Foundation should import the "cmof" Package (which should really be the OMG standard reference) to define Element, for external Relationships and Extensions.

    (4) Infrastructure should import the "interchange" Package that "defines" Diagram, and the "interchange" module should define the class Diagram, not the class NotInSpec. I realize that this is a fudge, but the existing nonsense causes Definitions:diagrams to be a model inconsistency when loading the XMI file into a CMOF repository.

    Yes, it is difficult to get a correct CMOF file out of the EMF libraries, or any UML tool. But it is the only form on the OMG server that can be loaded into a model library for integration with other cmof:Element objects (e.g., from UML or UPDM or SysML or BMM models).
    The XML schemas are worthless for this purpose. So, if you want Extension to work, fix the CMOF file.

  • Reported: BPMN 2.0b1 — Fri, 5 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    All machine-readable files are included in document DTC/2010-05-04, including CMOF files.
    The zip file with these files is attached: 2010-05-04.zip
    There are several sections under chapter 16 (chapter 15 of the final draft) that indicate the location of machine-readable files.
    Introduce a new section before Section 16.2 XSD

    • Section 15.2 Machine readable files
      BPMN 2.0 machine readable files, including XSD, XMI and XSLT files can be found in OMG Document DTC/2010-05-04, which is a zip file containing all the files.
      XSD files are found under the XSD folder of the zip file, and the main file is XSD/BPMN20.xsd.
      XMI files are found under the XMI folder of the zip file, and the main file is XSD/BPMN20.cmof.
      XSLT files are found under the XSLT folder of the zip file.
    • Section 16.2 XSD
      Remove the first two paragraphs (starting "The BPMN 2.0 XSD").
    • Section 16.3 XMI
      Remove the first paragraph (starting "The BPMN 2.0 XMI").
    • Section 16.4 XSLT Transformation between XSD and XMI
      Replace the paragraph with the following text:
    • The XSLT transformation from XSD to XMI is in the file XSLT/BPMN20-ToXMI.xslt
    • The XSLT transformation from XMI to XSD is in the file XSLT/BPMN20-FromXMI.xslt
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Mutiple depictions of a single semantic element

  • Key: BPMN2-245
  • Legacy Issue Number: 15029
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    When a single semantic element has multiple depictions (e.g. DataObjects), this forces the requirement for the target and source information to be duplicated in the DI schema in oder to know where to draw the association (i.e to which instance).

    In the case of DatStore, the solution was to have only one semantic element dataStore and have dataSoreRefs as depictable duplicate elements.

    Maybe the same could be explored for DataObjects

  • Reported: BPMN 2.0b1 — Tue, 2 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 15080 will also resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Depictable element without a reference semantic element

  • Key: BPMN2-244
  • Legacy Issue Number: 15028
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    When a Depictable element does not have a semantic element to reference, this forces the DI to duplicate target and source information in the schema in order to properly depict such elements.

    This is the case for at least the Conversation links which are depicted (e.g. figure 11-11)in conversation diagrams but do not have a semantic element.

  • Reported: BPMN 2.0b1 — Tue, 2 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue is addressed by the porposal at issue 15067
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

The example provided in Figure 10-22 and its serilization in Table 10-19 are incorrect or at least misleading

  • Key: BPMN2-249
  • Legacy Issue Number: 15042
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The example is provided to showcase human performers.

    Figure 10-22 incorrectly depicts a pool in a process diagram. It should be a lane named: Buyer. (i.e. remove the line seperating the label Buyer from its content)

    Table 10-19 provide an incorrect serialization. There should be a laneset element with a single lane named : Buyer.

    The use of the string Buyer as process id is also very misleading.

    This example should be completly revalidated for correctness....critical because it is the only example of a serialization of the semantic of a process.

  • Reported: BPMN 2.0b1 — Fri, 5 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue is addressed by 15163
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add an attribute that can identify a rulebase/rule engine for Business Rule Task

  • Key: BPMN2-248
  • Legacy Issue Number: 15040
  • Status: closed  
  • Source: Intalio, Inc. ( Tammo van Lessen)
  • Summary:

    Currently, a Business Rule Task has only an "implementation" attribute that is used to identify the technology used to interact/communicate with a rule engine (e.g. Web Service or any other protocol).

    However, there is no possibility to identify to which rule engine the data should be sent nor which rule set should be processed. I believe that this information is crucial from a vendor perspective.

    My suggestion is to add an anyURI-attribute called "ruleSet" (perhaps there is more generic term). The attribute's value can be resolved at runtime/deployment time by BPMS to identify both, rule engine and ruleset or other rule engine specific settings.

  • Reported: BPMN 2.0b1 — Sat, 1 Aug 2009 04:00 GMT
  • Disposition: Closed; No Change — BPMN 2.0
  • Disposition Summary:

    Since the business rule task is underspecified, vendor specific extensions are needed anyway. So there is no real value in adding any additional attribute, since
    interoperability will not be possible.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Confusing semantics for Terminate End Event

  • Key: BPMN2-247
  • Legacy Issue Number: 15038
  • Status: closed  
  • Source: Open Text Inc. ( Robert Shapiro)
  • Summary:

    The spec has two confusing statements for Terminate End Event:

    In section 10.4.3: Terminate: This type of End indicates that all activities in the Process should be immediately ended. This includes all instances of Multi-Instances. The Process is ended without compensation or event handling.

    In section 14.4.6: Sub-process level end events: For a “terminate” End Event, the Sub-Process is abnormally terminated. In case of a multi-instance Activity, only the affected instance is terminated.

  • Reported: BPMN 2.0b1 — Thu, 4 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Terminate End Events only interrupt the specific instance of a given Process level (Process or Sub-Process). Any other parallel instances or higher-level instances are
    not affected.
    (a) Section 14.4.6, Sub-Section "Process level end events": Replace the first sentence with the following: "For a "terminate" End Event, the Process instance is
    abnormally terminated—no other ongoing Process instances are affected."
    (b) 14.4.6, Sub-Section "Sub-Process level end events": Replace the first paragraph with the following: "For a "terminate" End Event, the Sub-Process instance is
    abnormally terminated. In case of a multi-instance Sub-Process, only the affected instance is terminated—no other ongoing Sub-Process instances or higher-level Sub-
    Process or Process instances are affected.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Ambiguity when multiple message flows associated with a choreography task

  • Key: BPMN2-237
  • Legacy Issue Number: 14890
  • Status: closed  
  • Source: Red Hat ( Gary Brown)
  • Summary:

    a choreography task is associated with more than two message flows, or with two message flows that are in the same direction (i.e. same sending and receiving participants), then the ordering of the message flows is ambiguous.

    If the choreography is ambiguous, and process models associated with each participant in the choreography are independently developed, it may mean that the resulting process models may not be able to interact correctly.

    There are a couple of possible solutions:

    1) Only permit a choreography task to have a max of two message flows. If two are defined, then they must be in opposite directions.

    2) If more than two message flows are defined, then an MEP (and possibly other additional supporting information) needs to be specified that makes the ordering explicit. For example, request/response/fault MEP could be specified, where only one message flow could be in one direction (i.e. the request), and all others are in the opposite direction - and the semantics would be that only one of the 'response' message flows could occur. Note: not sure whether it would be necessary to distinguish those flows as one normal response and remaining being fault responses - may be necessary to map to standard rpc pattern.

  • Reported: BPMN 2.0b1 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    PDF page 360:
    (a) Replace: "A single Choreography Task can be used for one (1) or more Messages. Most of the time there will be one (1) or two (2) Messages for a Choreography
    Task."
    With: "A single Choreography Task can be used for one (1) or two (2) Messages, with at most one (1) Message per Participant."
    PDF page 388:
    (b) Change schema for tChoreographyTask "<xsd:element name="messageFlowRef" type="xsd:QName" minOccurs="1" maxOccurs="unbounded"/>" so that
    maxOccurs is 2.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ResourceParameter::type attribute should be of type ItemDefinition, not Element

  • Key: BPMN2-251
  • Legacy Issue Number: 15045
  • Status: closed  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Table 8.59 currently describes that the type of the "type" attribute of ResourceParameter is "Element". For consistency with other similar attributes, the type should really be "ItemDefinition".

  • Reported: BPMN 2.0b1 — Wed, 10 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Table 8.59, page 98 (128 pdf), second row, first column: Replace "element" with "itemDefinition"
    (b) Update Figure 8.44, page 97 (127 pdf) to reflect the above change
    (c) Update XSD schema to reflect the above change
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Parallel Event Based Gateway capability is hidden away

  • Key: BPMN2-250
  • Legacy Issue Number: 15044
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Section 10.5.6 (pg 306) talks about the Parallel Event Based Gateway and introduces new notation for it (Figure 10.115). But that concept and notation doesn't appear in other parts of the document.

    I would expect to see it in Section 7.2.2 (pg 56) and also in Figure 10.99 (pg 294). Otherwise, it would be extremely easy to miss this new capability.

  • Reported: BPMN 2.0b1 — Tue, 9 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In Table 7.2 (BPMN Extended Modeling Elements):

    • in the row with left column containing "Gateway Control Types", in
      the right column, to the right of the symbol for Event-Based,
      insert the symbol in Figure 10.115 (Parallel Event-Based Gateway to
      start a Process).
    • in the row with left column containing "Event-Based":
    • in the middle column, at the end, add the paragraph:
      Parallel Event-based gateways start a new instance of the
      process.
    • in the right column, at the bottom, insert a copy of the
      subfigure at the top of the column, except replace the diamond
      shape with the symbol in Figure 10.115 (Parallel Event-Based
      Gateway to start a Process), and remove the rounded rectangle
      and the arrow going out of it.
      In Figure 10.99 (The Different types of Gateways), to the right of the
      symbol for Event-Based, insert the symbol in Figure 10.115 (Parallel
      Event-Based Gateway to start a Process).
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistent/confusing statements around CallActivities and IOSpecifications

  • Key: BPMN2-239
  • Legacy Issue Number: 14921
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Does a CallActivity own data inputs, outputs, etc? And when you draw a data association to/from a CallActivity, is the data association connecting to/from data inputs and outputs of the CallActivity or data inputs and outputs of the CallableElement?

    PDF pg 196 states that "Call Activities must not define their own data inputs, InputSets, and outputs, OutputSets but use the data inputs, InputSets, and outputs, OutputSets defined in the referenced CallableElement"

    This reads like CallActivities don't own data inputs/outputs of their own.

    But then PDF pg 225 states that "... the data inputs and outputs of the Call Activity must match with the data inputs, inputsets and outputs, outputsets defined in the callable element".

    This explicitly states that a CallActivity does own data inputs, etc. So then what's the meaning behind the statements on PDF pg 196?

  • Reported: BPMN 2.0b1 — Wed, 6 Jan 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    a) in section 10.2.6 Call Activity, replace the following paragrah:
    "Since Call Activities rely in the CallableElement being invoked (see Figure 10.40), Call Activities must not define their own data inputs, InputSets, and outputs,
    OutputSets but use the data inputs, InputSets, and outputs, OutputSets defined in the referenced CallableElement."
    with this one:
    "A CallActivity must fullfil the data requirements, as well as return the data produced by the CallableElement being invoked (see Figure 10.40). This means that the
    elements contained in the CallActivity's InputOutputSpecification must exactly match the elements containes in the referenced CallableElement. This includes
    DataInputs, DataOutputs, InputSets and OutputSets."
    b) in section 10.3.1 Data Modeling (Call Activity Mapping) replace the following paragraph:
    "Since Call Activities rely in the callable element being invoked, the data inputs and outputs of the Call Activity must match with the data inputs, inputsets and outputs,
    outputsets defined in the callable element. The data inputs and outputs of the Call Activity are mapped to the corresponding data inputs and output of the Callable
    Element without any explicit data association."
    with this one:
    "The DataInputs and DataOutputs of the CallActivity are mapped to the corresponding elements in the CallableElement without any explicit data association."
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Table 10-4 page 162 List of possible states of an Activity instance

  • Key: BPMN2-243
  • Legacy Issue Number: 15027
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The enumeration of possible states for an Activity does not reflect the possible states as per the execution semantics provided in chapter 14 on the state diagram figure 14-2

  • Reported: BPMN 2.0b1 — Tue, 2 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    > Section 10. Process
    Table 10.2 - Process Instance Attributes
    Change row: state
    Original
    Attribute Name
    state: string = none

    {none | ready | active | cancelled | aborting | aborted | completing | completed}
    Description/Usage
    The current state of this Process instance.
    Proposal
    Attribute Name
    state: string = none
    Description/Usage
    The current state of this Process instance. Cf. Figure 14.2 ("The Lifecycle of a BPMN Activity") in section 14.2.2 for permissible values.
    > Section 10.2 Activities
    Table 10.2 - Activity instance attributes
    Change row: state
    Original
    Attribute Name
    state: string = none{none | ready | active | cancelled | aborting | aborted | completing | completed}

    Description/Usage
    The current state of this activity instance.
    Proposal
    Attribute Name
    state: string = none
    Description/Usage
    The current state of this activity instance. Cf. Figure 14.2 ("The Lifecycle of a BPMN Activity") in section 14.2.2 for permissible values.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarify "Instance of this Conversation."

  • Key: BPMN2-242
  • Legacy Issue Number: 14966
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The text uses the term "instance of this Conversation." This should be clarified.

  • Reported: BPMN 2.0b1 — Wed, 13 Jan 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The problem could not be reproduced so the proposal is to close this issue with no changes to the specification.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Change plural "flow" to "flows"

  • Key: BPMN2-241
  • Legacy Issue Number: 14965
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    BPMN has used Message Flow and Sequence Flow to refer to the terms for both singular and plural uses. In the interest of reducing confusion, change the plural forms to Message Flows and Sequence Flows.

  • Reported: BPMN 2.0b1 — Wed, 13 Jan 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In all cases where the word "flow" is used in plural form, change the word to "flows." This would include all plural instances Sequence Flow and Message Flow.
    Note: there will be change tracking markings, but there will not be an annotation for each occurrence of this change.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Correlation key property values from process instances

  • Key: BPMN2-240
  • Legacy Issue Number: 14932
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    How are correlation key property values pulled from a process instance?
    Correlation Property Retrieval Expression only maps the contents of the
    message instance to a key instance, not to the process instance.

  • Reported: BPMN 2.0b1 — Thu, 7 Jan 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:
    • Added improved description as part of 14703.
    • Correlation key properties are only pulled from a message, on behalf of a process instance (via the associated conversation that the send/receive task or message
      event belongs to), and thus assigned as a key to the process instance. Thus nothing needs to be added.
      Disposition: Closed, No Change
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification of Temporal Sematics of Sequence Flow

  • Key: BPMN2-252
  • Legacy Issue Number: 15049
  • Status: closed  
  • Source: Agile Enterprise Design ( Mr. Fred A. Cummins)
  • Summary:

    While tokens may help explain behavior, the specification should not rely on the concept of tokens to define the normative behavior of model elements.

    Sequence flows represent temporal constraints requiring that an "incoming" constraint be satisfied before a flow element can be executed. The specification should refer to the sequence of execution or the flow of control rather than the flow of tokens.

    While the specification explicitly says that tokens are a theoretical concept for explanation of behavior, the specification refers to the flow of tokens in many places. For example, the end event behavior is described as "The Process will be in a running state until all tokens are consumed."

    Since tokens are not required for compliance, the normative definitions of behavior should not be specified in terms of token flows but in terms of satisfaction of temporal constraints.

    Consistent use of temporal constraint semantics is importnant for specialization of processes (addition of intervening elements) and analysis of processes such as validation of compliance with a choreography.

  • Reported: BPMN 2.0b1 — Fri, 12 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close; No Change. The FTF decided that the issue report does not identify a problem with the BPMN 2.0 specification
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exclusive Gateway (missing sub-heading)

  • Key: BPMN2-238
  • Legacy Issue Number: 14919
  • Status: closed  
  • Source: Atos Origin ( Lyndon Roy)
  • Summary:

    I believe that there is a sub-heading missing between sections 14.3.1 and 14.3.2.; the missing sub-heading relates to the Exlusive gateway description found on pages 399-400 (429-430).

    The text of the sub-heading appears after table 14.1 (the text is 'Exclusive Gateway (Exclusive Decision (data-based) and Exclusive Merge)') but it hasn't been tagged as a sub-heading.

  • Reported: BPMN 2.0b1 — Mon, 4 Jan 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 14.3.1, page 398 (428 pdf), last sentence on page: Reformat sentence to make it a level 3 heading
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

For DI: All graphical elements should have a Semantic Counterpart

  • Key: BPMN2-273
  • Legacy Issue Number: 15102
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Most graphical elements have a semantic counterpart. It should be a design principle that all elements follow this pattern. One exception is the Communication Link, which is merely an association between two Elements. The Communication Link, and any other similar DI situations, should be given its own semantic element.

  • Reported: BPMN 2.0b1 — Mon, 1 Mar 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 15068 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Review the use of RFC2119 keywords

  • Key: BPMN2-272
  • Legacy Issue Number: 15095
  • Status: closed  
  • Source: SAP SE ( Ivana Trickovic)
  • Summary:

    Ensure consistent use of RFC-2119 keywords (“MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “MUST NOT,” “SHOULD,” “SHOULD NOT,” “RECOMMENDED,” “MAY,” and “OPTIONAL”).

  • Reported: BPMN 2.0b1 — Mon, 1 Mar 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Make the following changes in the document (Beta 1, Aug 2009, pdf)
    (1) Change all must occurrences to MUST (in sections 2-12 and 14-16, excluding 3.1 and 3.2)
    (2) Change all must not occurrences to MUST NOT (in sections 2-12 and 14-16, excluding 3.1 and 3.2)
    (3) Change all are NOT/is NOT occurrences to are not/is not (in sections 2-12 and 14-16, excluding 3.1 and 3.2)
    (4) Change all required occurrences to REQUIRED (in sections 2-12 and 14-16, except in figure 10.121; do not change occurrences of 'required' and
    "required")
    (5) Change all shall occurrences to SHALL (in sections 2-12 and 14-16, excluding 3.1 and 3.2)
    (6) Change all shall not occurrences to SHALL NOT (in sections 2-12 and 14-16, excluding 3.1 and 3.2)
    (7) Change all recommended occurrences to RECOMMENDED (in sections 2-12 and 14-16, excluding 3.1 and 3.2)
    (8) In addition make the following changes

    • Page 19: Include
      "A Start Event generates a token that MUST be consumed at an End Event (which is implicit if not graphically displayed)."
      instead of
      "A Start Event generates a token that must eventually be consumed at an End Event (which may be implicit if not graphically displayed)."
    • Pages 131, 221, 225, 236: Include
      "All Message Flow MUST connect two separate Pools. They MAY connect to the Pool boundary or to Flow Objects within the Pool boundary. They MUST NOT
      connect two objects within the same Pool."
      instead of
      "All Message Flow must connect two separate Pools. They can connect to the Pool boundary or to Flow Objects within the Pool boundary. They cannot connect two
      objects within the same Pool."
    • Page 160: Include
      "First, the transaction protocol needs to verify that all the Participants have successfully completed their end of the Transaction."
      instead of
      "First, the transaction protocol must verify that all the Participants have successfully completed their end of the Transaction."
    • Page 164: Include
      "The addition of Sequence Flow between the Tasks (e.g., between "Generate Graphics" and "Include Graphics in Text") creates a dependency where the performance
      of the first Task MUST be followed by a
      performance of the second Task. This does not mean that the second Task is be performed immediately, but there MUST be a performance of the second Task after
      the performance of the first Task."
      instead of
      "The addition of Sequence Flow between the Tasks (e.g., between "Generate Graphics" and "Include Graphics in Text") creates a dependency where the performance
      of the first Task must be followed by a performance
      of the second Task. This does not mean that the second Task must be performed immediately, but there must be a performance of the second Task after the
      performance of the first Task."
    • Page 197: Include
      "The implementation of the element where the OutputSet is defined determines the OutputSet that will be produced."
      instead of
      "The implementation of the element where the OutputSet is defined must determine the OutputSet that will be produced."
    • Page 310: Include
      "However, if there are more than two (2) Participants, then the modeler needs to be careful to sequence the Choreography Activities in such a way that the Participants
      know when they are responsible for initiating the interactions."
      instead of
      "However, if there are more than two (2) Participants, then the modeler must be careful to sequence the Choreography Activities in such a way that the Participants
      know when they are responsible for initiating the nteractions."
    • Page 313: Include
      "The data referenced in the conditions need to be visible to two (2) or more Participants in the Choreography"
      instead of
      "The data referenced in the conditions must be visible to two (2) or more Participants in the Choreography"
    • Page 328: Include
      "The data used to define the loop conditions need to be visible to all Participants"
      instead of
      "The data used to define the loop conditions must be visible to all Participants"
    • Page 328: Include
      "This means that the ordering of Choreography Activities need to take into account when the Participants send or receive..."
      instead of
      "This means that the ordering of Choreography Activities must take into account when the Participants send or receive..."
    • Pages 335, 336: Include
      "The data are be visible to the Participants as it was data of a previously sent Message."
      instead of
      "The data must be visible to the Participants as it was data of a previously sent Message."
    • Page 2: Include
      "Where permitted or requested connections are specified as conditional"
      instead of
      "Where permitted or required connections are specified as conditional"
    • Page 3: Include
      "Some of these attributes are purely representational and are so marked, and some have mandated representations."
      instead of
      "Some of these attributes are purely representational and are so marked, and some have required representations."
    • Page 11: Include
      "Section 8 introduces the BPMN Core that includes basic BPMN elements needed..."
      instead of
      "Section 8 introduces the BPMN Core that includes basic BPMN elements required..."
    • Page 13: Include
      "... it is likely that business analysts need to understand multiple representations..."
      instead of
      "...it is likely that business analysts are required to understand multiple representations..."
    • Pages 15, 124, 126: Include
      "Thus, information needed for execution, such as formal condition expressions are typically not included in a non-executable Process."
      instead of
      "Thus, information required for execution, such as formal condition expressions are typically not included in a non-executable Process."
    • Pages 15, 126. Include
      "...the public Process shows to the outside world the Message Flow and the order of those Message Flow that are necessary to interact..."
      instead of
      "...the public Process shows to the outside world the Message Flow and the order of those Message Flow that are required to interact..."
    • Page 20: Include
      "There are two (2) standardized Artifacts, but modelers or modeling tools are free to add as many Artifacts as necessary."
      instead of
      "There are two (2) standardized Artifacts, but modelers or modeling tools are free to add as many Artifacts as required."
    • Page 51: Include
      "It is the intention of this specification to cover the basic elements necessary for the construction..."
      instead of
      "It is the intention of this specification to cover the basic elements required for the construction"
    • Page 53: Include
      "For example, an EventDefinition may be contained in a Process since it may be only required there."
      instead of
      "For example, an EventDefinition would be contained in a Process if it is used only there."
    • Page 131: Include
      "The following sections define how Resources can be defined..."
      instead of
      "The following sections define how required Resources can be defined..."
    • Page 143: Include
      "In many business workflows, human involvement is required to complete certain..."
      instead of
      "In many business workflows, human involvement is needed to complete certain"
    • Page 162: Include
      "The default setting is parallel and the setting of sequential is a restriction on the performance that may be needed due to shared resources."
      instead of
      "The default setting is parallel and the setting of sequential is a restriction on the performance that may be required due to shared resources."
    • Page 163: Include
      "Although there is no explicit Process structure,..."
      instead of
      "Although there is no required formal Process structure,"
      -Page 190: Include
      "Activities and Processes often require data in order to execute."
      instead of
      "Activities and Processes often required data in order to execute."
      -Page 296: Include
      "For example, Order Id is necessary for in all Messages of Message Flow in Delivery Negotiation."
      instead of
      "For example, Order Id is required for in all Messages of Message Flow in Delivery Negotiation."
    • Page 397: Include
      "In practice, it would entail a special-purpose mediator which not only provides the extraction and data assignment, but also any necessary data transformation."
      instead of
      "In practice, it would entail a special-purpose mediator which not only provides the extraction and data assignment, but also any required data transformation."
    • Page 437: Include
      "Second, the activities that need to be duplicated can be removed from the main Process and placed in a derived process that is called (invoked) from all locations in
      the WSBPEL elements as needed."
      instead of
      "Second, the activities that need to be duplicated can be removed from the main Process and placed in a derived process that is called (invoked) from all locations in
      the WSBPEL elements as required."
    • Page 438: Include
      "...particularly if a WSBPEL pick is requested."
      instead of
      "...particularly if a WSBPEL pick is required"
    • Page 439: Include
      "Such "incomplete" models are ones in which all of the mandatory attributes have not yet been filled in, or the cardinality lowerbound of attributes and associations has
      not been satisfied."
      instead of
      "Such "incomplete" models are ones in which all of the required attributes have not yet been filled in, or the cardinality lowerbound of attributes and associations has not
      been satisfied."
    • Page 4: Include
      "• how the feature will be displayed
      • whether the feature will be displayed
      • whether the feature will be supported"
      instead of
      "• how the feature shall be displayed
      • whether the feature shall be displayed
      • whether the feature shall be supported"
    • Page 68: Include
      "a Conversation may additionally refer to explicitly updateable Process context data to determine whether or not a Message need to be received"
      instead of
      "a Conversation may additionally refer to explicitly updateable Process context data to determine whether or not a Message shall be received"
    • Page 11: Include
      "The following abbreviations are used throughout this document:"
      instead of
      "The following abbreviations may be used throughout this document:"
    • Page 14: Include
      "BPMN 2.0 can be mapped to more than one platform dependent"
      instead of
      "BPMN 2.0 may be mapped to more than one platform dependent"
    • Page 15: Include
      "Collaborations, which can include Processes and/or Choreographies"
      instead of
      "Collaborations, which may include Processes and/or Choreographies"
    • Page 16: Include
      "The Messages associated with the Message Flow can also be shown."
      instead of
      "The Messages associated with the Message Flow may also be shown."
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Rename "Call" Elements

  • Key: BPMN2-277
  • Legacy Issue Number: 15115
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The names Call Conversation and Call Choreography are confusing and incorrect. Conversations and Choreographies are not elements that can be "called."
    Also the Call Activity may be technically correct, it is a term not oriented for business modelers. It would be best to change the terminology for all elements that "call."

  • Reported: BPMN 2.0b1 — Thu, 4 Mar 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Reason:

    • The change will cause a lot of instability in the spec as it touches so much.
    • As the CallActivity in Orchestration keeps the term "Call" the spec becomes inconsistent.
    • Even if "Call" is a technical term, it seems to be accepted by the BPMN community at least for the Orchestration case. Why should it be inaceptable in the
      Choreagraphy area?
    • "Use" is a very unspecific and frequently used term that makes is difficult to explain the meaning of the C-Activites in sentences like "Use a UseConversation actity to
      reference conversations that are used".
    • Even if the spec is not final, the community starts using the terms from the Beta. These people will be confused by such significant term change.
      Reiner.
      Disposition: Closed, No Change
  • Updated: Fri, 6 Mar 2015 20:57 GMT

XML Schema is not strict enough

  • Key: BPMN2-276
  • Legacy Issue Number: 15105
  • Status: closed  
  • Source: SAP SE ( Reiner Hille-Doering)
  • Summary:

    The XML Schemas BPMN20.xsd and Semantic.xsd define lots of global elements. This allows the elements to be used as XML file root. I don't think that this is intended: BPMN 2.0 files should be always rooted with "bpmn:definitions", and only a few elements are allowed as sub elements (including imports, diagrams and all root elements).

    The current design would e.g. make a file be a valid BPMN 2.0 file which consists of a single activity only.

  • Reported: BPMN 2.0b1 — Tue, 2 Mar 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Include the following text to chapter 16.2. For details see attachment (use newer version).
    Document Structure
    A domain-specific set of model elements is interchanged in one or more BPMN files. The root element of each file MUST be <bpmn:definitions>. The set of files must
    be self-contained, i.e. all definitions that are used in a file MUST be imported directly or indirectly using the <bpmn:import> element.
    Each file must declare a "targetNamespace" which MAY differ between multiple files of one model.
    BPMN files MAY import non-BPMN files (such as XSDs and WSDLs) if the contained elements use external definitions.
    Example:
    main.bpmn
    <?xml version="1.0" encoding="UTF-8"?>
    <bpmn:definitions xmlns:bpmn="http://schema.omg.org/spec/BPMN/2.0"
    targetNamespace="sample1.main" xmlns:main="sample1.main" xmlns:s1="sample1.semantic1">
    <bpmn:import location="semantic1.bpmn" namespace="sample1.semantic1"
    importType="http://schema.omg.org/spec/BPMN/2.0" />
    <bpmn:import location="diagram1.bpmn" namespace="sample1.diagram1"
    importType="http://www.omg.org/spec/BPMNDI/1.0.0" />
    <bpmn:collaboration>
    <bpmn:participant processRef="s1:process1" id="collaboration1"></bpmn:participant>
    </bpmn:collaboration>
    </bpmn:definitions>
    semantic1.bpmn
    <?xml version="1.0" encoding="UTF-8"?>
    <bpmn:definitions xmlns:bpmn="http://schema.omg.org/spec/BPMN/2.0" targetNamespace="sample1.semantic1"
    xmlns:s1="sample1.semantic1">
    <bpmn:process id="process1">
    <!-- content here -->
    </bpmn:process>
    </bpmn:definitions>
    diagram1.bpmn
    <?xml version="1.0" encoding="UTF-8"?>
    <bpmn:definitions xmlns:bpmn="http://schema.omg.org/spec/BPMN/2.0"
    targetNamespace="sample1.diagram1"
    xmlns:bpmndi="http://www.omg.org/spec/BPMNDI/1.0.0"
    xmlns:d1="sample1.diagram1" xmlns:s1="sample1.semantic1"
    xmlns:main="sample1.main">
    <bpmndi:BPMNDiagram scale="0.0" unit="Pixel">
    <bpmndi:BPMNPlane element="main:collaboration1">
    </bpmndi:BPMNPlane>
    </bpmndi:BPMNDiagram>
    </bpmn:definitions>
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing loopCharacteristics for Choreography stuff in MM

  • Key: BPMN2-282
  • Legacy Issue Number: 15139
  • Status: closed  
  • Source: SAP SE ( Reiner Hille-Doering)
  • Summary:

    The spec mentions in chapter 12.4.1ff loops for choreography elements, such as ChoreographyTasks, but in the metamodel none caries a loopCharacteristics. Normal orchestration activities inherit the attribute from the “Activity” class, but ChoreographyActivity does not inherit from Activity.

  • Reported: BPMN 2.0b1 — Tue, 23 Mar 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Add a new attribute named loopType the is of the type ChoreographyLoopType enumeration for a Choreography Task.
    (b) Add a new enumeration named ChoreographyLoopType with four literals of None (default), Standard, MultiInstanceSequential, and MultiInstanceParallel
    (c) Update Figure 12.6 to include these changes
    Add a new row to Table 12.2 :
    (d) The first column of the new row should contain:
    "loopType: ChoreographyLoopType = None"
    (e) The second column of the new row should contain:
    "A Choreography Activity may be performed once or may be repeated. The loopType attribute will determine the appropriate marker for the Choreography Activity
    (see below)."
    Section 12.4.1, Page 318 (348 pdf):
    (f) 3rd bullet on page: change "two (2)" to "three (3)"
    (g) 4th bullet on page: add the following to the end of the bullet: "The loopType of the Choreography Task MUST be Standard"
    (h) 5th bullet on page: change "multi-instance" to "parallel multi-instance"
    5th bullet on page: add the following to the end of the bullet: "The loopType of the Choreography Task MUST be MultiInstanceParallel."
    (j) Add a new bullet after the 5th bullet with the following: "The marker for a Choreography Task that is sequential multi-instance MUST be a set of three horizontal
    lines. The loopType of the Choreography Task MUST be MultiInstanceSequential."
    (k) Update Figure 12.12 to show the sequential multi-instance marker.
    (l) Caption for Figure 12.14: Change "Multi-Instance" to "Parallel Multi-Instance"
    Section 12.4.2, Page 324 (354 pdf):
    (m) 3rd bullet on page: change "two (2)" to "three (3)"
    4th bullet on page: add the following to the end of the bullet: "The loopType of the Choreography Sub-Process MUST be Standard."
    (o) 5th bullet on page: change "multi-instance" to "parallel multi-instance"
    (p) 5th bullet on page: add the following to the end of the bullet: "The loopType of the Choreography Sub-Process MUST be MultiInstanceParallel."
    (q) Add a new bullet after the 5th bullet with the following: "The marker for a Choreography Sub-Process that is sequential multi-instance MUST be a set of three
    horizontal lines. The loopType of the Choreography Sub-Process MUST be MultiInstanceSequential."
    (r) Update Figure 12.22 to show the sequential multi-instance marker.
    (s) Section 12.4.5: add the following to the end of the first paragraph: "Examples of Choreography Activities with the appropriate markers can be seen in Figure 12.12
    and Figure 12.22"
    (t) Table 12.11 Choreography Activity XML Schema: Add the following:
    "<xsd:attribute name="loopType" type="tChoreographyLoopType" default="Standard"/>
    ...
    <xsd:simpleType name="tChoreographyLoopType">
    <xsd:restriction base="xsd:string">
    <xsd:enumeration value="Standard"/>
    <xsd:enumeration value="MultiInstanceSequential"/>
    <xsd:enumeration value="MultiInstanceParallel"/>
    </xsd:restriction>
    </xsd:simpleType>"
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 12-21, Sub-process marker missing

  • Key: BPMN2-281
  • Legacy Issue Number: 15137
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The Figure 12-21 shows a Choreography Sub-Process. However the + marker is
    missing

  • Reported: BPMN 2.0b1 — Wed, 17 Mar 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Add the + marker to Figure 12.21
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Mismatch in DataAssociation definition between spec and XSD

  • Key: BPMN2-280
  • Legacy Issue Number: 15133
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    tDataAssociation in the BPMN XSD does not match how it is defined in the spec or UML metamodel.

    Specifically, in the spec and MM, the DataAssociation has source and target associations. In the XSD, those are not on tDataAssocation, but rather on the subclasses.

  • Reported: BPMN 2.0b1 — Tue, 16 Mar 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue is a duplicate of OMG Issue 14718 14718
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Receive Task is not mentioned as an instantiating element

  • Key: BPMN2-279
  • Legacy Issue Number: 15122
  • Status: closed  
  • Source: Intalio, Inc. ( Tammo van Lessen)
  • Summary:

    In 14.1, process instantiation is described. The possibilities described there are message start events and an event based gateway with out incoming sequence flow. However, on page 139, the receive task is described to be capable to instantiate process instance as well. Also the metamodel describes the "instantiate" attribute for that task.

    I suggest to add a paragraph to 14.1 that describes the instantiating behavior of a receive task.

    In addition, is it intentional that in "In order for the Task to Instantiate the Process it must meet one of the following conditions" on p139, "Instantiate" is written with a capital I?

  • Reported: BPMN 2.0b1 — Mon, 8 Mar 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14799 will resolve this issue.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Merge Collaboration and Choreography in Metamodel

  • Key: BPMN2-278
  • Legacy Issue Number: 15119
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Collaborations and Choreographies have a large degree of overlap in underlying capabilities--basically being a collection of Participants and Message Flow. Choreography only adds the sequencing of the Message Flow. It would be useful to be able to take the same interaction model and display it as either a Collaboration or a Choreography. The definition of those views would determine what should be displayed and how they are displayed.
    A merger of the two diagrams in the metamodel would greatly simplify the implementation, add flexibility, and improve BPMN support of other specifications, such as SoaML.

  • Reported: BPMN 2.0b1 — Thu, 4 Mar 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14654 provides the resolution for this issue.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing in XML example

  • Key: BPMN2-284
  • Legacy Issue Number: 15147
  • Status: closed  
  • Source: Camunda Services GmbH ( Gerardo Navarro Suarez)
  • Summary:

    On page 180 begins the serialized XML example (table 10.19) of the process model shown in figure 10.23 . The definition of a sequence flow is missing in the serialized XML.

    The process model has 11 flows, but in the XML example there are only 10 sequence flows defined. So one is missing.

    The missing flow is that one between AND - Join (called "OrderAndShipmentMerge") and the user task "Review order".

    ---Proposal------ 03/24/2010 --------------
    ##Proposed Resolution: Fixed

    (a) Insert the following XML node into the example:
    <sequenceFlow sourceRef="OrderAndShipmentMerge" targetRef="ReviewOrder"/>
    Table 10.19 | Page 152 (182)

    (b) The best position would be on page 152 (182) between the tags <parallelGateway ...> and <userTask id="ReviewOrder" ...> .
    Table 10.19 | Page 152 (182)

  • Reported: BPMN 2.0b1 — Wed, 24 Mar 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Insert the following XML node into the example:<sequenceFlow sourceRef="OrderAndShipmentMerge" targetRef="ReviewOrder"/> Table 10.19 | Page 152
    (182)
    (b) The best position would be on page 152 (182) between the tags <parallelGateway ...> and <userTask id="ReviewOrder" ...> .
    Table 10.19 | Page 152 (182)
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing label of a compensation activity

  • Key: BPMN2-283
  • Legacy Issue Number: 15146
  • Status: closed  
  • Source: Camunda Services GmbH ( Gerardo Navarro Suarez)
  • Summary:

    Figure 10.9 contains three activities with different markers. 2 of them have a label above describing the type of the marker.But the activity on the right hand side misses it's label.

    This issue doesn't appear in the official Beta 1 from August 2009. So the issue appears only in the FTF Beta 1 for Version 2.0 Draft 1.

    ---Proposal------ 03/24/2010 --------------
    ##Proposed Resolution: Fixed

    (a) Insert a label saying "Compensation". Position that label over the task with the compensation marker.
    Figure 10.9 | Page 134 (166)

  • Reported: BPMN 2.0b1 — Wed, 24 Mar 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Insert a label saying "Compensation". Position that label over the task with the compensation marker. Figure 10.9 | Page 134 (166)
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing marker in Compensation Activity

  • Key: BPMN2-286
  • Legacy Issue Number: 15150
  • Status: closed  
  • Source: Camunda Services GmbH ( Gerardo Navarro Suarez)
  • Summary:

    In figure 10.97 the compensation subprocess "Undo Booking" doesn't have a compensation marker.

    In Chapter 10.6.1 of the specification the second paragraph says: "The Compensation Activity, which can be either a Task or a
    Sub-Process, has a marker to show that it is used for compensation only and is outside the normal flow of the
    Process."

    ---- Proposal ------- 03/25/2010 ------------
    ##Proposed Resolution: Fixed

    (a) Position a compensation marker on the left of the supprocess marker in the Compensation activity "Undo Booking".

  • Reported: BPMN 2.0b1 — Thu, 25 Mar 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Insert the missing compensation marker on the left hand side of the Sub-Process marker. Updating figure 10.97 on page 255 (285)
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Process Model and Model Description are not consistent

  • Key: BPMN2-285
  • Legacy Issue Number: 15149
  • Status: closed  
  • Source: Camunda Services GmbH ( Gerardo Navarro Suarez)
  • Summary:

    Figure 11.03; The Communication between Consignee Shipper and Consolidator has the name "Delivery / Dispatch Plan". But the description of the conversation model (below figure 11.3) says something else.

    In the Text this converstation is called "Detailed Shipment Schedule". Quotation out of the paragraph: "More than two participants may be involved in a Conversation, e.g., Consignee, Consolidator and Shipper in Detailed Shipment Schedule."

    ---- Proposal ------- 03/25/2010 ------------
    ##Proposed Resolution: Fixed

    (a) Rename the Communication into "Detailed Shipment Schedule".

  • Reported: BPMN 2.0b1 — Thu, 25 Mar 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Rename the Communication into "Detailed Shipment Schedule".
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Allow referencing scripts instead of enfocing inline specification

  • Key: BPMN2-274
  • Legacy Issue Number: 15103
  • Status: closed  
  • Source: University of Stuttgart - ISW ( Frank Leymann)
  • Summary:

    Use Case: When using BPMN 2.0 in systems management environments many tasks will be implemented as scripts. Especially, a huge amount of scripts already exist in these environments and BPMN 2.0 should support an easy and straightforward way to allow making use of them as script activity implementations.

    Issue: Scripts to be performed must be copied to the already defined @script attribute to make it inline to the script task. In practice, this is not only redundant but also introduces a lot of potential consistency problems because the proper script might be subject to change; in that case, all copies in all script tasks must be found and adapted accordingly.

    Prososed resolution: Add a new attribute @scriptRef (of type URI or QName) to the scriptTask element. This allows to point to the script to be executed.

    Minor comments: There is no need to introduce the script separately as an operation of some (artificial) interface. This should be clarified.

    The script task refers to a NONE task which has been renamed into Abstract Task: needs to be fixed.

    An associated document (BPMN Script Invocation.DOCX) with more background has been sent to Tammo van Lessen

  • Reported: BPMN 2.0b1 — Tue, 2 Mar 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The functionality proposed is provided by other means.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

How to reference particular instances of Data Objects that are Collections

  • Key: BPMN2-275
  • Legacy Issue Number: 15104
  • Status: closed  
  • Source: University of Stuttgart - ISW ( Frank Leymann)
  • Summary:

    How can one address (in an <assignment>, for example) a particular instance of a multi-instance data object, i.e. a data object with attribute isCollection value set to "true"?

    It is unclear why the ioSpecification must be defined with isCollection=true to result in multi-instance execution of the task. Why isn't it sufficient to refer (via the dataInputAssociation/sourceRef element) to a multi-instance data object to trigger multi-instance exection of the task. Is the attribute isCollection needed as attribute of dataInput and dataOutput at all? [Multi Instance Tasks controlled by loopDataInput (Section 10.2.8)]

    I assume that defining a data object with isCollection=false based on an itemDefinition with isCollection=true is not allowed, correct? But the reverse is allowed as shown in the document. The question is why supporting isCollection as attribute of an item definition at all; supporting isCollection with elements using the item definition would suffice. [Item Definition as multi-instance (Section 8.3.12)]

    A corresponding document (BPMN Script invocation.DOCX) with more background has been sent to Tammo van Lessen.

  • Reported: BPMN 2.0b1 — Tue, 2 Mar 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 8.3.12 properly describes the behaviour in the case the data object is a collection.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Choreography should be a Sub-Class of Collaboration

  • Key: BPMN2-271
  • Legacy Issue Number: 15093
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The work on the merger between Conversation and Collaboration is making clear that Choreography is completely overlaps with (the merged) Collaboration, but extends its capabilities. Thus, it would make sense to make Choreography a sub-class of Collaboration. This would simplify the metamodel and make the Interaction Specification class no longer necessary

  • Reported: BPMN 2.0b1 — Fri, 26 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14654 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Additional participants in called/subconversation

  • Key: BPMN2-270
  • Legacy Issue Number: 15091
  • Status: closed  
  • Source: Axway Software ( Dale Moberg)
  • Summary:

    Called and subconversations should be able to have more participants
    than the calling/outer conversation. The additional participants
    would not be associated with any in the calling/outer conversation.

  • Reported: BPMN 2.0b1 — Fri, 26 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Called conversations can have additional participants. Subconversations cannot, they are owned by the containing conversation, but diagrams can show participants
    only in the subconversation, if desired.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Hexagons and message flow linked to activities

  • Key: BPMN2-261
  • Legacy Issue Number: 15067
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Filed for soaML: It should be possible to link hexagons (conversations /
    communications) to activities. This would mean messages flow from
    within the activity, which could be calls or subs. The hexagon can be
    expanded to show message flow connected to the activity, including calls
    and subs.

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Conversation links are groupings of message flows, so they can be linked
    to activities and events just as message flow can. The resolution
    supports conversation links to activities and events, but not message
    flow to conversation nodes a requested by the issue. This restriction
    is only by textual constraint, if a future RTF would like to loosen it.
    Conversation Link is added to the metamodel to simplify implementation
    of this resolution. The notation for conversation links is changed to a
    double lines, to distinguish them from sequence flows when used with
    activities and events. The forked line end notation for conversation
    links ("crow's feet") is removed to simplify usage and implementation,
    since it is redundant with participant multiplicity notation.
    The resolution assumes the resolution of 14654.
    Refer to attached document
    Issue+531+figures-v3.doc
    for figures.
    In the BPMN Core Structure chapter, Message Flow subsection, in the
    figure The Message Flow Class Diagram, rename MessageFlowNode to
    InteractionNode, add ConversationNode as a subclass, and its association
    to Participant. See first figure in attached document.
    In the BPMN Core Structure chapter, Message Flow subsection, in the
    table Message Flow attributes and model associations:

    • replace "MessageFlowNode" with "InteractionNode" in the first two
      rows, both columns.
    • In the first two rows, right column, at the end of the sentences,
      add "of a Message Flow".
      In the BPMN Core Structure chapter, Message Flow section, Message Flow
      Node subsection:
    • Change the title of the subsection to Interaction Node
    • In the two paragraphs of the subsection, replace the two occurrences
      of "MessageFlowNode" in each paragraph with "InteractioNode".
    • In the first paragraph, delete the portion of the sentence starting
      with "and thus" to the end of the sentence.
    • At the end of the first paragraph, add the sentence "The
      InteractionNode element is also used to provide a single element for
      source and target of Conversation Links, see chapter XXXCollaboration.
      In the Collaboration section, in the figure Classes in the Collaboration
      package, add ConversationLink and InteractionNode and their associations
      and generalizations to other elements, see second figure in the attached
      document.
      In the Collaboration chapter, Participants section, in the figure The
      Participant Class Diagram, change the name of the MessageFlowNode
      metaclass to InteractionNode. See third figure in attached document.
      In the Collaboration section, in the table Collaboration Attributes and
      Model Associations, after the row for conversations, insert a new row:
    • conversationLinks: ConversationLink [0..*]
      This provides the Conversation Links that are used in the
      Collaboration.
      In the Collaboration chapter, Conversations section, at the end of the
      first paragraph, add the sentence "In particular, processes can appear
      the participants (pools) of conversation diagrams, to show how
      conversations and activities are related."
      In the Collaboration chapter in the Conversation Link section (was
      CommunicationLink before resolution of 14654), after
      the figure A Conversation Link element, insert a new figure captioned
      "The Conversation Link Class Diagram", showing ConversationLink and
      related classes, see the fourth figure in the attached document.
      After the above new figure, insert:
      The Conversation Link element inherits the attributes and model
      associations of BaseElement (see Table XX). Table XXXX presents the
      additional attributes and model associations for the Conversation Link
      element:
      then insert a table with the caption "Conversation Link attributes and
      model associations", and two columns headed "Attribute Name" and
      "Description/Usage" with the rows:
      name : String [0..1]
      Name is a text description of the Conversation Link.
      sourceRef: ConversationLinkNode
      The ConversationLinkNode that the Conversation Link is connecting
      from. A Conversation Link MUST connect to exactly one
      ConversationNode. If the sourceRef is not a ConversationNode, then
      the targetRef MUST be a ConversationNode.
      targetRef: ConversationLinkNode
      The ConversationLinkNode that the Conversation Link is connecting
      to. A Conversation Link MUST connect to exactly one
      ConversationNode. If the targetRef is not a ConversationNode, then
      the sourceRef MUST be a ConversationNode.
      In the Collaboration chapter in the Conversation Link section (was
      CommunicationLink before resolution of 14654), delete
      the figure Where Conversation Links are derived in the metamodel, and
      the paragraph after it (the last one in the section) and replace it with:
      Processes can appear in the participants (pools) of Conversation
      diagrams, as shown in Figure XXXX. The invoicing and ordering
      conversations have links into activities and events of the process in
      the Order Processor. The other two conversations do not have their
      links "expanded". Conversation links into activities that are not
      send or recieve tasks indicate that the activity will send or receive
      messages of the conversation at some level of nesting.
      After the above text, insert a figure captioned "Conversation links to
      activities and events" with the contents of the fifth figure in the
      attached document.
      In the Collaboration chapter, in the XML Schema section, in the table
      for Collaboration XML schema, under the conversations element, insert a
      new line:
      <xsd:element ref="conversationLink" minOccurs="0" maxOccurs="unbounded"/>
      In the Collaboration chapter, in the XML Schema section, after the table
      for Conversations, insert a new table, captioned "ConversationLink XML
      schema" containing:
      <xsd:element name="conversationLink" type="tConversationLink" substitutionGroup="rootElement"/>
      <xsd:complexType name="tConversationLink">
      <xsd:complexContent>
      <xsd:extension base="tBaseElement">
      <xsd:attribute name="name" type="xsd:string" use="optional"/>
      <xsd:attribute name="sourceRef" type="xsd:QName" use="required"/>
      <xsd:attribute name="targetRef" type="xsd:QName" use="required"/>
      </xsd:extension>
      </xsd:complexContent>
      </xsd:complexType>
      In the Overview chapter, BPMN Scope section, Uses of BPMN subsection,
      figure An example of a Conversation diagram, on the lines coming out of
      the hexagons (the conversation links):
    • Change the line style to double thin lines.
    • Remove the forking on the participant ends of the lines.
      In Collaborations chapter, Conversation section, figure A Conversation,
      figure Conversation diagram depicting several conversations between
      Participants in a related domain, change the figure in the same way as
      the figure above.
      In Process chapter, Activities section, Sub-Processes subsection, Ad-Hoc
      Sub-Process subsubsection, in the bullet just above figure An Ad-Hoc
      Sub-Process with data and sequence dependencies, after "Conversation
      Links" insert "(graphically)".
      In Collaborations chapter, Conversation section, figure A Conversation
      diagram, on the lines coming out of the hexagon (conversation links),
      change the line style to double thin lines.
      In Collaborations chapter, Conversation section, figure Conversational
      view choreographies, on the lines coming out of the hexagon
      (conversation links), change the line style to double thin lines.
      In Collaborations chapter, Conversation section, COnversation Link
      subsection:
    • First paragraph, replace the second sentence with "Conversation
      links MUST be drawn with double thin lines.".
    • In figure A Conversation Link element:
    • On the lines coming out of the hexagon:
    • Change the line style to double thin lines.
    • Remove the forking on the participant ends of the lines.
    • Remove the text annotation on the lower right (the one that
      says "The Conversation Link source is forked if there are
      multiple connections").
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

For Process within Collaboration, section 9.3 title is wrong and section 10.11 is empty

  • Key: BPMN2-260
  • Legacy Issue Number: 15064
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    9.3 title should be “Process within Collaboration” not simple “Collaboration” which is the title for all of section 9. Note that “Process within Collaboration” is also the title of section 10.11 which is completely empty.

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Make the following changes in Beta 1:
    Section 9.3: Change the section heading to read "Process within Collaboration" (instead of "Collaboration").
    Section 10.11: Remove this (empty) chapter.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Data Objects should be defined with the same pattern a Data Stores and DataStoreRefs

  • Key: BPMN2-264
  • Legacy Issue Number: 15080
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    There can be multiple visible occurrences of the same DataObject according to the spec. But this seems to be wrong: there should be multiple occurrences of DataObjectRef, each referring to the same DataObject, as was done with DataStore and DataStoreRef

  • Reported: BPMN 2.0b1 — Mon, 22 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue concerns multiple data objects icons appearing on the same
    diagram, but with the same name and different states, intending to
    represent the same runtime object for the duration of each execution of
    the diagram. The resolution addresses abstract syntax for this, leaving
    execution semantics to be filed as an issue in the RTF.
    In the sentence above Figure 10.47 (ItemAware class diagram), after
    "Data Objects," add "Data Object References,".
    In Figure 10.47 (ItemAware class diagram) add metaclass named
    "DataObjectReference", subclass of ItemAwareElement.
    DataObjectReference has one unidirectional association from it to
    DataObject. This association has multiplicity * on the
    DataObjectReference end and 1 on the DataObject end. The name on
    DataObject end is named dataObjectRef.
    In Section 10.3.1 (Data Modeling), Data Objects subsection, at the end
    of the first paragraph, add:
    Data Object References are a way to reuse Data Objects in the same
    diagram. They can specify different states of the same data object at
    different points in a process. Data Object Reference cannot specify
    item definitions, and Data Objects cannot specify states. The names
    of Data Object References are derived by concatenating the name of the
    referenced Data Object with the state of the Data Object Reference in
    square brackets as follows: <Data Object Name> [ <Data Object Reference
    State> ].
    In Figure 10.48 (DataObject class diagram) add metaclass named
    "DataObjectReference", subclass of FlowElement and ItemAwareElement.
    DataObjectReference with one unidirectional associations from it
    to DataObject as described above for Figure 10.47.
    Under Table 10.47 (DataObject model associations) add the paragraph:
    The DataObjectReference element inherits the attributes and model
    associations of ItemAwareElement (see Table YYY) and FlowElement (see
    Table 8.45). Table XXX presents the additional attributes of the
    DataObjectReference element:
    After the above paragraph add a new model association table with caption
    "DataObjectReference" with one row:

    • dataObjectRef : DataObject
      The DataObject referenced by the DataObjectRef.
      In Section 10.3.1 (Data Modeling), Lifecycle and Visibility subsection,
      second paragraph, at the end of the last sentence, add ", including Data
      Object References referencing the Data Object."
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Correlation on message flow and choreography activities

  • Key: BPMN2-263
  • Legacy Issue Number: 15069
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Should be able to specify correlation directly on message flow and
    choreography activities, without the overhead of conversations.

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Choreography activities are a way of grouping message flow and should
    have correlation like other message flow grouping constructs. Message
    flows themselves do not need correlation, because correlation only works
    if the same key values are in more than one message flow, as identified
    by message flow grouping constructs.
    Remove Subsection 12.3.3 (Correlations) and the sentence in it.
    In Figure 12.6 (The metamodel segment for a Choreography Activity) add
    the CorrelationKey metaclass with a unidirectional association to it
    from ChoreographyActivity. This association has multiplicity 0..1 on
    the ChoreographyActivity end and * on the CorrelationKey end. The
    association end on the CorrelationKey end is named correlationKeys, which
    has composite aggregation (the black diamond appears on the opposite
    end).
    In Table 12.2 (Choreography Activity Model Associations) add a row at
    the end:

    • correlationKeys : CorrelationKey [0..*]
      This association specifies correlationKeys used by the message flow
      in the choreography activity, including subchoreographies and called
      choreographies.
      In Table 12.11 (ChoreographyActivity XML schema), after the
      participantRef element attribute, insert on a new line:
      <xsd:element ref="correlationKeys" minOccurs="0" maxOccurs="unbounded"/>
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Label call conversation links

  • Key: BPMN2-262
  • Legacy Issue Number: 15068
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Filed for soaML: Links from call conversations should be labelled with
    participant names of the called conversation, as identified by nonvisual
    participant associations

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This resolution assumes the resolution of 14654.
    Replace the paragraph at the end of Section 11.7 (Communication Link),
    the one beginning "There is not a specific BPMN metamodel", with the
    following:
    Conversation links for call conversations show the names of
    participants in nested collaborations or global conversations, as
    identified by participant associations. For example, Figure XXX has a
    collaboration on the left with a call conversation to a collaboration
    on the right. The conversation links on the left indicate which
    participants in the called collaboration on the right correspond to
    which participants in the calling collaboration on the left. For
    example, the Credit Agency participant on the right corresponds to the
    Financial Company participant on the left. Participant associations
    (not shown) tie each participant in the collaboration on the left to a
    participant in the collaboration on the right. They can be used to
    show the names of participants in nested collaborations or global
    conversations.
    After above text, insert a figure with caption "Call Conversation
    Links", and contents per the attached document:
    callconversation-532-v2.ppt.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

LaneSet should have an optional ‘name’ attribute

  • Key: BPMN2-257
  • Legacy Issue Number: 15061
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Since a LaneSet represents a “a different way” of slicing up a process (e.g. by role or by department) then it should have a name, not just a (potentially unreadable) id to represent that way. Allowing different diagrams for the same Process to be distinguished.

    There should be also a notation to allow for this: for example <Process Name>: <LaneSet Name>

    So for example Figure 10.121 would have Supplier: By Department

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Make the following changes to the MM (version Beta 1)

    • Add attribute "name" of type "String" to class "LaneSet"
      Make the following changes to the XSD (version Beta 1)
    • Change
      <xsd:complexType name="tLaneSet">
      <xsd:complexContent>
      <xsd:extension base="tBaseElement">
      <xsd:sequence>
      <xsd:element ref="lane" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      </xsd:extension>
      </xsd:complexContent>
      </xsd:complexType>
      to
      <xsd:complexType name="tLaneSet">
      <xsd:complexContent>
      <xsd:extension base="tBaseElement">
      <xsd:sequence>
      <xsd:element ref="lane" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attribute name="name" type="xsd:string"/>
      </xsd:extension>
      </xsd:complexContent>
      </xsd:complexType>
      Make the following changes to the specification text:
    • Insert a new row at the top of table 10.127 (LaneSet attributes and model associations) with the following content:
      Column "Attribute Name":
      name: string
      Column "Description/Usage":
      The name of the LaneSet. A LaneSet is not visually displayed on a BPMN diagram. Consequently, the name of the LaneSet is not displayed as well.
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Simplify Use of Callable Elements

  • Key: BPMN2-256
  • Legacy Issue Number: 15060
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Callable elements can be simplified. For example, a Global Choreography Task can be a sub-type of Choreography. It would be defined as an "empty" Choreography. A Global Task could be a sub-type of Process, with the same restriction.
    By doing this, then calling elements within the diagram can be more specific about what kind of element they can reference. Thus, a CallActivity can reference a Process and a Call Choreography can reference a Choreography, instead of both referencing Callable Elements with an text based restriction as to what kind of callable element can be referenced.

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14654 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

No way to identify the format of Documentation and TextAnnotation connect

  • Key: BPMN2-266
  • Legacy Issue Number: 15083
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    The XSD schema supports mixed-content text within Documentation or Text Annotations. This allows for formatted content (e.g. html tags for bolding or italics).

    The problem occurs when interchanging the XML, since a consumer of the XML has no way of telling what format was used for the text (i.e. to tell that it was html rather than plain text).

    Recommend adding an attribute for a mime-type. Example usages could then be "text/plain" for regular text and "text/html" for html structured text.

  • Reported: BPMN 2.0b1 — Wed, 24 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    1. Spec tables 8.6 and 8.24: Add an attribute to both
    Name: "textFormat: string"
    Description: This attribute identifies the format of the text. It must follow the mime-type format. The default is "text/plain".
    2. UML metamodel: Update the UML metamodel to add the same attribute to the Documentation and TextAnnotation classes.
    Replace all spec figures that show the Documentation and TextAnnotation classes.
    3. XSD: Add an attribute to the tDocumentation and tTextAnnotation complexTypes
    <xsd:attribute name="textFormat" type="xsd:string" default="text/plain"/>
    Update the XSD snippets in tables 8.17 and 8.29 to match.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Extending via inheritancy is problematic using the BPMN xsd format

  • Key: BPMN2-265
  • Legacy Issue Number: 15082
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Extending via inheritancy is problematic using the BPMN xsd format.

    The presence of the 'any' element on tBaseElement creates issues if you create subclasses that reside in a non-BPMN namespace. You cannot add elements to the subclass without violating the Unique Particle Attribution (UPA) rule in XML Schema (http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/structures.html#non-ambig)

  • Reported: BPMN 2.0b1 — Wed, 24 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Update tBaseElement and tBaseElementWithMixedContent in the XSD (see Semantic-Snippet.xsd attached to this issue)
    (b) Update the XSD snippets (Table 8.17) in the spec
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

How to represent Process Diagrams and Lanes?

  • Key: BPMN2-259
  • Legacy Issue Number: 15063
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Taking Figure 10.121 as an example, it’s unclear what the outer box represents in the diagram – is it a graphical Pool representing a Participant named Supplier linked to a PartnerEntityRole also named ‘Supplier’ in turn linked to a Process also called Supplier? Or is it merely a Process called Supplier (in which case it could be better named ‘Supply Process’)? I would have thought the latter, but that does not tie in with my reading of 13.2.3 which states that “A Lane is a sub-partition with a Pool” and “A Pool is the graphical representation of a Participant in a Collaboration (see page 146). It is also acts as a graphical container for partitioning a set of Activities from other Pools, usually in the context of B2B situations.” Likewise Figure 13.4 provides only one interpretation – as Lanes within a Pool not within a Process.

    Though Table 13.1 states that a Process Diagram has at least one LaneCompartment (which is inconsistent with 13.2.3 which states that Lanes are only within Pools) this is inconsistent with the serialization (in Table 10.19) of Figure 10.23 which has no instance of Lane at all. And Figure 10.23 appears to use the Pool notation shown in Figure 13.3

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close; No Change. The FTF decided that the issue report does not identify a problem with the BPMN 2.0 specification
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 10.121 mis-described

  • Key: BPMN2-258
  • Legacy Issue Number: 15062
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The text beneath it states that it shows “the Lane class diagram”: it’s not a class diagram at all but a Process Diagram

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In beta version 09-08-14,

    • Figure 10.121 title is "An Example of Nested Lanes" and it describes a process diagram with lanes.
    • Figure 10.122 title is " The Lane class diagram" and it describes the UML Class Diagram for Lane and LaneSet
      Disposition: Closed, No Change
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CorrelationKey should be a concrete element

  • Key: BPMN2-254
  • Legacy Issue Number: 15058
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The CorrelationKey element is currently an abstract element in the metamodel. Since it has no concrete sub-classes, it should made a concrete class

  • Reported: BPMN 2.0b1 — Wed, 17 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Update Figure 8.18, page 66 (96 pdf) to show that CorrelationKey is a concrete class
    (b) Update XSD schema to reflect the above change
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Required definitions to invoke an existing function by means of a service task

  • Key: BPMN2-253
  • Legacy Issue Number: 15055
  • Status: closed  
  • Source: University of Stuttgart - ISW ( Frank Leymann)
  • Summary:

    It is not precisely defined what definitions must be made in order to specify that a particular executable is to be invoked as an implementation of an operation of a service task (for example).

    The specification should clearly spell out which definition are mandatory in order to capture the major scenarios, e.g. using an operation of WSDL port; using a java class;...

    I submitted a document with more details on the problem area to issues@omg.org, without any response since weeks. I am happy to send this document to the person assigned to this issue, and discuss it.

  • Reported: BPMN 2.0b1 — Wed, 17 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:
    • To "Table 8.80 - Interface attributes and model associations", add the following row:
      implementationRef: Element[0..1] This attribute allows to reference a concrete artifact in the underlying implementation technology representing that interface, such as
      a WSDL porttype.
    • To "Table 8.81 - Operation attributes and model associations", add the following row:
      implementationRef: Element[0..1] This attribute allows to reference a concrete artifact in the underlying implementation technology representing that operation, such as
      a WSDL operation.
    • Update the UML meta-model and XSD schema accordingly.
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add Attribute Table for Global Task

  • Key: BPMN2-268
  • Legacy Issue Number: 15086
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    A Global Task has a performers attribute. This should be listed in a table in Section 10.2.7

  • Reported: BPMN 2.0b1 — Wed, 24 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of this issue is included as part of 14732
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect attribute name used for Start Event definition

  • Key: BPMN2-267
  • Legacy Issue Number: 15085
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Bullet items for Start Event Message Flow Connections refers to the "Trigger" attribute of the Start Event. The name of this attribute was changed to "eventDefinitionRefs."
    These items, and other similar uses of the word Trigger, should be corrected.

  • Reported: BPMN 2.0b1 — Wed, 24 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The statements of those bullets is actually wrong, the trigger attribute do not have a value of "Message" or "Multiple", they are EventDefinition elements. Also they do
    not add any value since the connection rules are properly described in Section 7.5.2 Mesage Flow Connection Rules
    So the proposed fix is to remove these 2 bullets:
    • The Trigger attribute of the Start Event MUST be set to Message or Multiple if there are any incoming Message Flow.
    • The Trigger attribute of the Start Event MUST be set to Multiple if there are more than one incoming Message Flow.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Contradictory/redundant handing of data and subprocesses

  • Key: BPMN2-269
  • Legacy Issue Number: 15087
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Consider a process with a Data Object and a Subprocess. The subprocess has an activity. Can you draw a data association from the data object (in the process) directly to the activity (in the subprocess).

    • The introduction of Data Inputs/Outputs for subprocesses implies you should always go through the Data Inputs/Outputs. That is, you must draw the data association from the Data Object to the subprocess Data Input, and then draw another data association from the subprocess Data Input to the Activity inside the subprocess.
    • But then page 216 states that the data object is 'visible' to the subprocess and the activity inside the subprocess, which implies the activity can access it directly without necessarily going through the subprocess data input.

    So, two different means of doing the same thing, with likely different tools assuming/supporting one or the other or both.

  • Reported: BPMN 2.0b1 — Thu, 25 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue has the same resolution as OMG 14817 (14817)
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

DataInputs, DataOuputs, and DataStores should be FlowElements

  • Key: BPMN2-255
  • Legacy Issue Number: 15059
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Data Object is a Flow Element because it can apppear in a Flow Element Container (e.g., a Process). Data Inputs, Data Outputs, and Data Stores should also be Flow Elements for the same reason.
    These elements would not need there own name attribute in this case.

  • Reported: BPMN 2.0b1 — Wed, 17 Feb 2010 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close, no Change. The FTF decided that the reported issue does not identify a problem with BPMN 2.0
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing definition of the participant Buyer

  • Key: BPMN2-291
  • Legacy Issue Number: 15163
  • Status: closed  
  • Source: Camunda Services GmbH ( Gerardo Navarro Suarez)
  • Summary:

    Table 10.19, the XML serialization of the Buyer process in figure 10.23 (pg. 150) is shown. The process model in figure 10.23 shows a Pool named Buyer. The metamodell provides the possibility to define pools as participants, which have a reference to the process definition. But Table 10.19 doesn’t contain any definition of a participant.

    ---Proposal--------------- 04/07/2010 -------------------------
    ##Proposed Resolution: Fixed

    (a) Update Table 10.19 by replacing the XML with the following XML,which adds a collaboration with a participant and a laneSet. The collaboration represents the pool Buyer in figure 10.23 (pg. 150).

    <definitions id="Definition"
    targetNamespace="http://www.example.org/UserTaskExample"
    typeLanguage="http://www.w3.org/2001/XMLSchema"
    expressionLanguage="http://www.w3.org/1999/XPath"
    xmlns="http://schema.omg.org/spec/BPMN/2.0"
    xmlns:tns="http://www.example.org/UserTaskExample">

    <resource id="regionalManager" name="Regional Manager">
    <resourceParameter id="buyerName" isRequired="true" name="Buyer Name" type="xsd:string"/>
    <resourceParameter id="region" isRequired="false" name="Region" type="xsd:string"/>
    </resource>

    <resource id="departmentalReviewer" name="Departmental Reviewer">
    <resourceParameter id="buyerName" isRequired="true" name="Buyer Name" type="xsd:string"/>
    </resource>

    <collaboration id="BuyerCollaboration" name="Buyer Collaboration">
    <participant id="BuyerParticipant" name="Buyer" processRef="BuyerProcess"/>
    </collaboration>

    <!-- Process definition -->
    <process id="BuyerProcess" name="Buyer Process">

    <laneSet id="BuyerLaneSet">
    <lane id="ByerLane">
    <flowElementRef>StartProcess</flowElementRef>
    <flowElementRef>QuotationHandling</flowElementRef>
    <flowElementRef>ApproveOrder</flowElementRef>
    <flowElementRef>OrderApprovedDecision</flowElementRef>
    <flowElementRef>TerminateProcess</flowElementRef>
    <flowElementRef>OrderAndShipment</flowElementRef>
    <flowElementRef>OrderHandling</flowElementRef>
    <flowElementRef>ShipmentHandling</flowElementRef>
    <flowElementRef>OrderAndShipmentMerge</flowElementRef>
    <flowElementRef>ReviewOrder</flowElementRef>
    <flowElementRef>EndProcess</flowElementRef>
    </lane>
    </laneSet>

    <startEvent id="StartProcess"/>

    <sequenceFlow sourceRef="StartProcess" targetRef="QuotationHandling"/>

    <task id="QuotationHandling" name="Quotation Handling"/>

    <sequenceFlow sourceRef="QuotationHandling" targetRef="ApproveOrder"/>

    <userTask id="ApproveOrder" name="ApproveOrder">
    <potentialOwner resourceRef="tns:regionalManager">
    <resourceParameterBinding parameterRef="tns:buyerName">
    <formalExpression>getDataInput('order')/address/name</formalExpression>
    </resourceParameterBinding>
    <resourceParameterBinding parameterRef="tns:region">
    <formalExpression>getDataInput('order')/address/country</formalExpression>
    </resourceParameterBinding>
    </potentialOwner>
    </userTask>

    <sequenceFlow sourceRef="ApproveOrder" targetRef="OrderApprovedDecision"/>

    <exclusiveGateway id="OrderApprovedDecision" gatewayDirection="diverging"/>

    <sequenceFlow sourceRef="OrderApprovedDecision" targetRef="OrderAndShipment">
    <conditionExpression>Was the Order Approved?</conditionExpression>
    </sequenceFlow>

    <sequenceFlow sourceRef="OrderApprovedDecision" targetRef="TerminateProcess">
    <conditionExpression>Was the Order NOT Approved?</conditionExpression>
    </sequenceFlow>

    <endEvent id="TerminateProcess">
    <terminateEventDefinition id="TerminateEvent"/>
    </endEvent>

    <parallelGateway id="OrderAndShipment" gatewayDirection="diverging"/>

    <sequenceFlow sourceRef="OrderAndShipment" targetRef="OrderHandling"/>

    <sequenceFlow sourceRef="OrderAndShipment" targetRef="ShipmentHandling"/>

    <task id="OrderHandling" name="Order Handling"/>

    <task id="ShipmentHandling" name="Shipment Handling"/>

    <sequenceFlow sourceRef="OrderHandling" targetRef="OrderAndShipmentMerge"/>

    <sequenceFlow sourceRef="ShipmentHandling" targetRef="OrderAndShipmentMerge"/>

    <parallelGateway id="OrderAndShipmentMerge" gatewayDirection="converging"/>

    <sequenceFlow targetRef="OrderAndShipmentMerge" sourceRef="ReviewOrder"/>

    <userTask id="ReviewOrder" name="Review Order">
    <potentialOwner resourceRef="tns:departmentalReviewer">
    <resourceParameterBinding parameterRef="tns:buyerName">
    <formalExpression>getDataInput('order')/address/name</formalExpression>
    </resourceParameterBinding>
    </potentialOwner>
    </userTask>

    <sequenceFlow sourceRef="ReviewOrder" targetRef="EndProcess"/>

    <endEvent id="EndProcess"/>
    </process>
    </definitions>

  • Reported: BPMN 2.0b1 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Update Table 10.19 by replacing the XML with the following
    XML,which adds a collaboration with a participant and a laneSet. The
    collaboration represents the pool Buyer in figure 10.23 (pg. 150).
    <definitions id="Definition"
    targetNamespace="http://www.example.org/UserTaskExample"
    typeLanguage="http://www.w3.org/2001/XMLSchema"
    expressionLanguage="http://www.w3.org/1999/XPath"
    xmlns="http://schema.omg.org/spec/BPMN/2.0"
    xmlns:tns="http://www.example.org/UserTaskExample">
    <resource id="regionalManager" name="Regional Manager">
    <resourceParameter id="buyerName" isRequired="true" name="Buyer Name" type="xsd:string"/>
    <resourceParameter id="region" isRequired="false" name="Region" type="xsd:string"/>
    </resource>
    <resource id="departmentalReviewer" name="Departmental Reviewer">
    <resourceParameter id="buyerName" isRequired="true" name="Buyer Name" type="xsd:string"/>
    </resource>
    <collaboration id="BuyerCollaboration" name="Buyer Collaboration">
    <participant id="BuyerParticipant" name="Buyer" processRef="BuyerProcess"/>
    </collaboration>
    <!-- Process definition -->
    <process id="BuyerProcess" name="Buyer Process">
    <laneSet id="BuyerLaneSet">
    <lane id="ByerLane">
    <flowElementRef>StartProcess</flowElementRef>
    <flowElementRef>QuotationHandling</flowElementRef>
    <flowElementRef>ApproveOrder</flowElementRef>
    <flowElementRef>OrderApprovedDecision</flowElementRef>
    <flowElementRef>TerminateProcess</flowElementRef>
    <flowElementRef>OrderAndShipment</flowElementRef>
    <flowElementRef>OrderHandling</flowElementRef>
    <flowElementRef>ShipmentHandling</flowElementRef>
    <flowElementRef>OrderAndShipmentMerge</flowElementRef>
    <flowElementRef>ReviewOrder</flowElementRef>
    <flowElementRef>EndProcess</flowElementRef>
    </lane>
    </laneSet>
    <startEvent id="StartProcess"/>
    <sequenceFlow sourceRef="StartProcess" targetRef="QuotationHandling"/>
    <task id="QuotationHandling" name="Quotation Handling"/>
    <sequenceFlow sourceRef="QuotationHandling" targetRef="ApproveOrder"/>
    <userTask id="ApproveOrder" name="ApproveOrder">
    <potentialOwner resourceRef="tns:regionalManager">
    <resourceParameterBinding parameterRef="tns:buyerName">
    <formalExpression>getDataInput('order')/address/name</formalExpression>
    </resourceParameterBinding>
    <resourceParameterBinding parameterRef="tns:region">
    <formalExpression>getDataInput('order')/address/country</formalExpression>
    </resourceParameterBinding>
    </potentialOwner>
    </userTask>
    <sequenceFlow sourceRef="ApproveOrder" targetRef="OrderApprovedDecision"/>
    <exclusiveGateway id="OrderApprovedDecision" gatewayDirection="diverging"/>
    <sequenceFlow sourceRef="OrderApprovedDecision" targetRef="OrderAndShipment">
    <conditionExpression>Was the Order Approved?</conditionExpression>
    </sequenceFlow>
    <sequenceFlow sourceRef="OrderApprovedDecision" targetRef="TerminateProcess">
    <conditionExpression>Was the Order NOT Approved?</conditionExpression>
    </sequenceFlow>
    <endEvent id="TerminateProcess">
    <terminateEventDefinition id="TerminateEvent"/>
    </endEvent>
    <parallelGateway id="OrderAndShipment" gatewayDirection="diverging"/>
    <sequenceFlow sourceRef="OrderAndShipment" targetRef="OrderHandling"/>
    <sequenceFlow sourceRef="OrderAndShipment" targetRef="ShipmentHandling"/>
    <task id="OrderHandling" name="Order Handling"/>
    <task id="ShipmentHandling" name="Shipment Handling"/>
    <sequenceFlow sourceRef="OrderHandling" targetRef="OrderAndShipmentMerge"/>
    <sequenceFlow sourceRef="ShipmentHandling" targetRef="OrderAndShipmentMerge"/>
    <parallelGateway id="OrderAndShipmentMerge" gatewayDirection="converging"/>
    <sequenceFlow targetRef="OrderAndShipmentMerge" sourceRef="ReviewOrder"/>
    <userTask id="ReviewOrder" name="Review Order">
    <potentialOwner resourceRef="tns:departmentalReviewer">
    <resourceParameterBinding parameterRef="tns:buyerName">
    <formalExpression>getDataInput('order')/address/name</formalExpression>
    </resourceParameterBinding>
    </potentialOwner>
    </userTask>
    <sequenceFlow sourceRef="ReviewOrder" targetRef="EndProcess"/>
    <endEvent id="EndProcess"/>
    </process>
    </definitions>
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exporter Information Required for BPMN 2 files

  • Key: BPMN2-290
  • Legacy Issue Number: 15161
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    There is a requirement for the “Exporter” of a BPMN 2 file to be identified. Such identification will allow an importing tool to take various appropriate actions to ensure ease of exchange and interchange of BPMN 2 files (for both semantic and diagrams).

    There is substantial practical evidence of the benefits of such information. In fact XMI provides support for such information. You can refer to MOF 2.0/XMI Mapping Specification, v2.1.1, section 4.5.2 and section 4.5. in the XMI spec for description of the <documentation> class, which is part of the XMI model. It contains the nested element <exporter>, and <exporterVersion> which serves this purpose.

    The intention is that any model that is an instance of MOF and serialized in XMI is able to include an instance of <documentation> nested in the root. As the example given by Pete shows:

    More specifically there is the following in the XMI spec :

    <xsd:complexType name="Documentation">

    …

    <xsd:element name="exporter" type="xsd:string"/>

    <xsd:element name="exporterVersion" type="xsd:string"/>

    For example:

    <xmi:XMI>

    <documentation xmi:type=xmi:Documentation>

    <exporter>MagicDraw UML</exporter>

    <exporterVersion>16.8 Beta</exporterVersion>

    </documentation>

    …

    This would require changes to section 8.1 and 8.1.3 of the BPMN 2 spec

    Proposal:

    Add to the tDefinitions xsd complexType:

    <xsd:attribute name="exporter" type="xsd:string" />

    <xsd:attribute name="exporterVersion" type="xsd:string"/>

    This will give two new optional properties (exporter and exporterVersion).

  • Reported: BPMN 2.0b1 — Tue, 6 Apr 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Add to the tDefinitions xsd complexType:
    "<xsd:attribute name="exporter" type="xsd:string" />
    <xsd:attribute name="exporterVersion" type="xsd:string"/>"
    (b) Update Figure 8.4, Figure 8.5, and Figure 8.6 to reflect this change
    (c) Update Table 8.1 and Table 8.3 to include these attributes
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inclusive Gateway Semantics

  • Key: BPMN2-289
  • Legacy Issue Number: 15155
  • Status: closed  
  • Source: International Business Machines ( Mr. Hagen Voelzer)
  • Summary:

    In the current semantics description of the inclusive gateway:

    The Inclusive Gateway is activated if
    • At least one incoming sequence flow has at least one Token and
    • for each empty incoming sequence flow, there is no Token in the
    graph anywhere upstream of this sequence flow, i.e., there is no
    directed path (formed by Sequence Flow) from a Token to this
    sequence flow unless

    • the path visits the inclusive gateway or
    • the path visits a node that has a directed path to a non-empty
      incoming sequence flow of the inclusive gateway.

    it does not get clear that the latter path is also not allowed to visit the inclusive gateway.

    I suggest to reword the entire sentence.

    The same applies to the semantics of the complex gateway.

  • Reported: BPMN 2.0b1 — Tue, 30 Mar 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Table 14.3, first row, second column: replace the contents of the column with the following:
    "The Inclusive Gateway is activated if
    1. At least one incoming sequence flow of the inclusive gateway has at least one Token and
    2. for every directed path formed by sequence flow that
    i. starts with a sequence flow f of the diagram that has a Token,
    ii. ends with an incoming sequence flow of the inclusive gateway that has no Token, and
    iii. does not visit the inclusive gateway,
    there is also a directed path formed by sequence flow that
    iv. starts with f,
    v. ends with an incoming sequence flow of the inclusive gateway that has a Token, and
    vi. does not visit the inclusive gateway.
    If the inclusive gateway is contained in a sub-process, then no paths are considered that cross the boundary of that sub-process.
    Upon execution, a Token is consumed from each incoming sequence flow that has a Token. A Token will be produced on some of the outgoing sequence flows.
    In order to determine the outgoing sequence flows that receive a Token, all conditions on the outgoing sequence flows are evaluated. The evaluation does not have to
    respect a certain order.
    For every condition, which evaluates to true, a Token must be passed on the respective sequence flow.
    If and only if none of the conditions evaluates to true, the Token is passed on the default sequence flow.
    In case all conditions evaluate to false and a default flow has not been specified, the inclusive gateway throws an exception."
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing Message Flow

  • Key: BPMN2-288
  • Legacy Issue Number: 15154
  • Status: closed  
  • Source: Camunda Services GmbH ( Gerardo Navarro Suarez)
  • Summary:

    The last table record on page 27 (57) misses a picture of a message flow.

    The record "Nested/Embedded Sub-Process (Inline Block)" on page 32 (62) shows a message flow, which does't belong there. It might be the message flow missed on page 27 (57).

    ---Proposal------ 03/26/2010 --------------
    ##Proposed Resolution: Fixed

    (a) Update the table record "Message Flow" in Table 7.2, inserting a figure of a message flow.
    Update table record Table 7.2 page 27 (57)

    (b) Update the table record "Nested/Embedded Sub-Process (Inline Block)" in Table 7.2, deleting the figure of the message flow. Update table record Table 7.2 page 32 (62)

  • Reported: BPMN 2.0b1 — Fri, 26 Mar 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Update the table record "Message Flow" in Table 7.2, inserting a figure of a message flow. Update table record Table 7.2 page 27 (57)
    (b) Update the table record "Nested/Embedded Sub-Process (Inline Block)" in Table 7.2, deleting the figure of the message flow. Update table record Table 7.2 page
    32 (62)
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Choreography is not enforcable

  • Key: BPMN2-287
  • Legacy Issue Number: 15152
  • Status: closed  
  • Source: Camunda Services GmbH ( Gerardo Navarro Suarez)
  • Summary:

    Figure 12.4; The Choreography model is not locally enforcable.

    In the last interaction the Supplier doesn't participate in the previous interaction.

    But in chapter 12.4.6 on page 328 (358) it is said: "The Initiator of a Choreography Activity MUST have been involved (as Initiator or Receiver) in the
    previous Choreography Activity."

    The lane in the middle of the Collaboration model (Figure 12.3 page 311 (341)) has a wrong name. It should be Supplier not Shipper.

    ---Proposal------ 03/25/2010 --------------
    ##Proposed Resolution: Fixed

    (a) Update the Collaboration model, renaming the name of the lane in the middle of the model into "Supplier".
    Figure 12.3 page 311 (341)

    (b) Update the Choreography, changing the order of the last interactions. Put the fourth from last interaction "Accept PO and
    Delivery Schedule" right behind the last interaction "Finalized PO and Delivery Schedule".
    Figure 12.4 page 312 (342)

    (c) Update the Collaboration model, changing the position of the interaction between the Retailer and the Supplier about the message "PO & Delivery Schedule". Put the Send Message Task in the lane "Retailer" right behind the last Recieve Message Task in that lane.
    Figure 12.3 page 311 (341)

    (d) Update the last sentence in the paragraph under the Collaboration model. Exchange the 2 words "Retailer" and "Supplier". The sentence should look like this: "´accordingly, the
    Retailer interacts with the Consignee and Supplier for final confirmations."

  • Reported: BPMN 2.0b1 — Thu, 25 Mar 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Update the Collaboration model, renaming the name of the lane in the middle of the model into "Supplier". Figure 12.3 page 311 (341)
    (b) Update the Choreography, changing the order of the last interactions. Put the fourth from last interaction "Accept PO and Delivery Schedule" right behind the last
    interaction "Finalized PO and Delivery Schedule". Figure 12.4 page 312 (342)
    (c) Update the Collaboration model, changing the position of the interaction between the Retailer and the Supplier about the message "PO & Delivery Schedule". Put
    the Send Message Task in the lane "Retailer" right behind the last Recieve Message Task in that lane. Figure 12.3 page 311 (341)
    (d) Update the last sentence in the paragraph under the Collaboration model. Exchange the 2 words "Retailer" and "Supplier". The sentence should look like this:
    "´accordingly, the Retailer interacts with the Consignee and Supplier for final confirmations."
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

The Two Multi-Instance Markers should be reversed

  • Key: BPMN2-294
  • Legacy Issue Number: 15169
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The two versions of the Multi-Instance loop marker should be reversed. The three horizontal lines looks more like parallism and the three vertical lines look more like sequentialism.

  • Reported: BPMN 2.0b1 — Fri, 9 Apr 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Reason: Changing the icon for multi-instance activities now will cause a lot of confusions. It will be difficult to ensure that the whole document stays in a consistent state.
    There are also already publications out on the market that use the current notation.
    Even for BPMN 1.x there are examples that use the current "vertical" notation for parallel, e.g. see Steves
    http://www.bpmn.org/Documents/Notations_and_Workflow_Patterns.pdf , Figure 30. So, there would be some kind of incompatibility introduced.
    Which orientation is better to understand for parallel and sequential depends mainly on taste on which axis one assumes time. If you model vertically top to bottom, the
    current notation is good. This is similar like writing a text, or also similar to UML activity and sequence diagrams. Only for the case that you model left-to-right the other
    proposal might make little more sense.
    Conclusion: Changing the meaning now has much higher risk than advantages.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

A Collaboration should be able to reference more than one Choreography

  • Key: BPMN2-293
  • Legacy Issue Number: 15168
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    To support SoaML modeling a Collaboration will need to be able to reference more than one Choreographies. These Choreographies would then be associated with the Conversations of the Collaboration.

  • Reported: BPMN 2.0b1 — Thu, 8 Apr 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 9, Collaboration
    Change the multiplicity of Collaboration's choreographyRef model association from 0..1 to 0..*
    (a) Update Figure 9.1 to reflect this change
    Table 9.1, second row:
    (b) First column: Change "[0..1]" to "[0..*]"
    (c) Second column: change the first sentence to "The choreographyRef model association defines the Choreographies that can be shown between the Pools of the
    Collaboration."
    (d) Table 9.2, Collaboration XML Schema: change:
    "<xsd:attribute name="choreographyRef" type="xsd:QName" use="optional"/>"
    To
    "<xsd:element ref="choreographyRef " minOccurs="0" maxOccurs="unbounded"/>"
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Conversation lanes

  • Key: BPMN2-292
  • Legacy Issue Number: 15165
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Lanes representing conversations should require activities in those
    lanes to send or receive message flows in the conversation.

  • Reported: BPMN 2.0b1 — Thu, 8 Apr 2010 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution assumes the resolution of 14654.
    In the Collaborations chapter, Conversations section, at the end of the
    Conversation Link subsection, add the paragraph
    When a lane represents a conversation, the flow elements in the lane
    (or elements nested or called in them) that send or receive messages
    must do so as part of the conversation represented by the lane.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

INCORRECT/IMCOMPLETE REFERENCES AND DEFINITIONS IN GLOSSARY

  • Key: BPMN2-236
  • Legacy Issue Number: 14880
  • Status: closed  
  • Source: Atos Origin ( Lyndon Roy)
  • Summary:

    Glossary in Annex C contains a number of definitions of, and references to, workflow patterns that were incorrect in version 1.0 of the spec and are still incorrect in version 2.0.

    For example, see the following definitions:
    Deferred Choice references workflow pattern #17 ­ actually Deferred Choice is pattern #16;
    Discriminator references workflow pattern #8 ­ actually Discriminator is pattern #9;
    Implicit Termination references workflow pattern #12 ­ actually Implicit Termination is pattern #11

    Also the URL for these workflow patterns has changed (All pages from 'tmitwww.tm.tue.nl' have moved to the server 'is.ieis.tue.nl' - although the latest patterns can actually be found at http://www.workflowpatterns.com/).

    May I suggest that the entire contents of the Glossary are reviewed against the latest set of workpatterns (http://www.workflowpatterns.com/documentation/documents/BPM-06-22.pdf) and ensure that the correct pattern numbers are used. I would also like the glossary to be extended to cover the extra workflow patterns that have been defined beyond van der Aalst's original 20 (or 21 if you include pattern #9a)and that can can be implemented using BPMN notation - (www.workflowpatterns.com/documentation/documents/BPM-06-17.pdf might give useful guidance for this (even though it relates to BPMN v1)).

  • Reported: BPMN 2.0b1 — Fri, 18 Dec 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14778 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

parallelMultiple attribute missing from CatchEvent table

  • Key: BPMN2-153
  • Legacy Issue Number: 14705
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    The CatchEvent has a "parallelMultiple" attribute, but it's not listed in the table in the spec. Table 10.75 on page 212 (242 pdf).

    Comments:
    From: wstephe created: Wed, 23 Sep 2009 16:52:11 -0500 (CDT)
    The Section and page numbers were added to match the Beta 1 spec.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Add a row to Table 10.75 - CatchEvent attributes and model associations
    Attribute Name: parallelMultiple
    Description/Usage:
    This attribute is only relevant when the CatchEvent has more than event definition (Multiple).
    If this value is true, then all of the types of triggers that are listed in the CatchEvent MUST be triggered before the Process is instantiated.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

CorrelationSubscription - Description & use-cases

  • Key: BPMN2-152
  • Legacy Issue Number: 14703
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    The Correlation Subscription concepts in the spec are difficult to follow and understand.

    We need improved explanations in the spec, with descriptions of when and how someone would use this, and the motivations behind it.

    Comments:
    From: wstephe created: Fri, 24 Jul 2009 13:05:02 -0500 (CDT)
    Yes, Section 8.3.3 (V0.9.14) needs a complete overhaul.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    1. Add the following introductory paragraph motivating the need for correlation:
    Business processes typically may run for days or even months, requiring asynchronous communication via messages. Also, many instances of a particular business
    process will typically run in parallel, e.g., many instances of an order process, each representing a particular order. Correlation is used to associate a particular
    message to an ongoing conversation between too particular business process instances. BPMN allows using existing message data for correlation purposes, e.g., for
    the order process, a particular instance can be identified by means of its order ID and/or customer ID, rather than requiring the introduction of technical correlation
    data.
    2. Add a footnote to the next paragraph clarifying that it also refers to message events – here is the original paragraph with the suggested footnote in *** ***:
    The concept of Correlation facilitates the association of a Message to a Send Task or Receive Task***All references to Send or Receive Tasks in this section also
    include message catch or throw events – they behave identically with respect to correlation*** in a
    Conversation, a mechanism BPMN refers to as instance routing. It is a particular useful concept where there is no
    infrastructure support for instance routing. Note that this association can be viewed at multiple levels, namely the
    Conversation, Choreography, and Process level. However, the actual correlation happens during runtime (e.g., at
    the Process level). Correlations describe a set of predicates on a Message (generally on the application payload) that
    need to be satisfied in order for that Message to be associated to a distinct Send Task or Receive Task. By the same
    token, each Send Task and each Receive Task participates in one or many Conversations. Furthermore, it identifies
    the Message it sends or receives and thereby establishes the relationship to one (or many) CorrelationKeys.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

The Category section has incorrect/inconsistent content

  • Key: BPMN2-154
  • Legacy Issue Number: 14706
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    It states that the name of the Category provides the label for the Group. And yet Category does not have a name attribute. So where is the name coming from.

    Also, given that Group references CategoryValue (and not Category), shoudn't the Group label be the CategoryValue.value, rather than the Category name? In Figure 8-14, what is "Handle Medicine" ... is it a Category name or a CategoryValue.value?

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Beta 1, August 2009 (pdf version)
    (a) Page 59: Change
    "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)."
    to
    "The Group object is an Artifact that provides a visual mechanism to group elements of a diagram informally. The grouping is tied to the CategoryValue supporting
    element. That is, a Group is a visual depiction of a single CategoryValue. The graphical elements within the Group will be assigned the CategoryValue of the Group.
    (Note – CategorieValues can be highlighted through other mechanisms, such as color, as defined by a modeler or a modeling tool)."
    (b) Figure 8.14 - no change required
    (c) Figure 8.15 - The Group class diagram
    Add attribute "name" of type sting to class "Category". Change "categoryRef" to "categoryValueRef".

    • Update the XSD file accordingly.
      (d) Page 60:
      Change
      "The Group element inherits the attributes and model associations of BaseElement (see Table 8.5)."
      to
      "The Group element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to Artifact."
      (e) Table 8.21 - Group model associations
      Change
      categoryRef: Category [0..1]
      to
      categoryValueRef: CategoryValue [0..1]
    • Update the XSD file accordingly.
      Change: "The categoryRef attribute specifies the Category that the Group represents (Further details about the definition of a Category can be found on page 92). 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."
      to
      "The categoryValueRef attribute specifies the CategoryValue that the Group represents (Further details about the definition of a Category and Category Value can be
      found on page 92 ). The label of the Group is provided by the value of the CategoryValue, optionally prepended by the Category name and delineator ":". The
      graphical elements within the boundaries of the Group will be assigned the CategoryValue."
      (f) Page 60:
      Change
      "Groups are one way in which Categories of objects can be visually displayed on the diagram. 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. The Category name appears on the diagram as the Group label."
      to
      "Groups are one way in which Categories of objects can be visually displayed on the diagram. That is, a Group is a visual depiction of a single CategoryValue. The
      graphical elements within the Group will be assigned the CategoryValue of the Group. The value of CategoryValue, optionally prepended by the Category name and
      delineator ":", appears on the diagram as the Group label. "
      (g) Table 8.22 Category model associations
      Add row:
      Atttribute: name: string
      Description: The descriptive name of the element.
      (h) Page 61
      Change
      "The Category element inherits the attributes and model associations of BaseElement (see Table 8.5). Table 8.23 displays the attributes and model associations of the
      CategoryValue element."
      to
      "The CategoryValue element inherits the attributes and model associations of BaseElement (see Table 8.5). Table 8.23 displays the attributes and model associations of
      the CategoryValue element."
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

V0.9.7: Section 10 Process: Add ProcessResource Attribute to Process

  • Key: BPMN2-157
  • Legacy Issue Number: 14710
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The Process does not have a way to have a resource, e.g., a supervisor, assigned. Thus, a ProcessResouce, similar to the ActivityResource, should be added.

    Comments:
    From: wstephe created: Wed, 23 Sep 2009 17:04:05 -0500 (CDT)
    This is suitable for the FTF

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Change the name of the ActivityResource element to ResourceRole
    (b) Update Figures 10.6, 10.7, 10.20, 10.21, and 10.22 to reflect this name change
    (c) Update Table 10.3, row 3, to reflect this name change
    (d) Update Section 10.2.1, Sub-Section ActivityResource, to reflect this name change. Five (5) changes are required.
    (e) Update Section 10.2.1, Sub-Section Expression Assignment, to reflect this name change. Two (2) changes are required.
    (f) Update Section 10.2.2, to reflect this name change. One (1) change is required.
    (g) Update Section 10.2.4, Sub-Section Human Performers, to reflect this name change. One (1) change is required.
    (h) Update Table 10.29 to reflect this name change. One (1) change is required.
    Update Table 10.30 to reflect this name change. Four (4) changes are required.
    (j) Update Table 10.135 to reflect this name change. Two (2) changes are required.
    (k) The Process element can now contain zero (0) to many ResourceRole elements.
    (l) Update Figures 10.3 and 10.7 to reflect this change
    Add one row to Table 10.1
    (m) The first column of the new row for Table 10.1 will have the following text: "resources: ResourceRole [0..*]"
    The second column of the new row for Table 10.1 will have the following text: "Defines the resource that will responsible for or in some way associated with the
    Process. The resource, e.g., a performer, can be specified in the form of a specific individual, a group, an organization role or position, or an organization. Note that the
    assigned resources of the Process does not determine the assigned resources of the Activities that are contained by the Process. See more details about resource
    assignment in Section 10.2.1"
    (o) Add the following text to Table 10.129: "<xsd:element ref="ResourceRole" minOccurs="0" maxOccurs="unbounded"/>"
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for supports association

  • Key: BPMN2-156
  • Legacy Issue Number: 14708
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Filed for Frank: The supports association between processes should have
    a notation

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close; Out of Scope. The issue requests a notation that would require a new diagram added to BPMN. While there might be value in such a diagram, it is out of scope
    for the FTF or any RTFs.
    Disposition: Closed, Out Of Scope

  • Updated: Fri, 6 Mar 2015 20:57 GMT

XML-Schema type for 'from' and 'to' elements in Data Assignment must not be abstract

  • Key: BPMN2-151
  • Legacy Issue Number: 14701
  • Status: closed  
  • Source: Oracle ( Ralf Mueller)
  • Summary:

    The XML-Schema type for elements "from" and "to" in complex type "tAssignment" is
    "tBaseElementWithMixedContent". However this type is declared abstract and forces to specify
    a xsi:type attribute for elements "from" and "to".
    The proposal is to use a non-abstract XML-schema type for "from" and "to" elements. A good
    candidate would be "tExpression" which is a non-abstract extension of "tBaseElementWithMixedContent":
    <xsd:complexType name="tAssignment">
    <xsd:complexContent>
    <xsd:extension base="tBaseElement">
    <xsd:sequence>
    <xsd:element name="from" type="tExpression" minOccurs="1" maxOccurs="1"/>
    <xsd:element name="to" type="tExpression" minOccurs="1" maxOccurs="1"/>
    </xsd:sequence>
    <xsd:attribute name="language" type="xsd:anyURI"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    1. Spec table 10.58
    a. Remove attribute "language".
    b. Modify attributes "from" and "to". Make both of type "Expression". Remove "body of the" from the attribute descriptions.
    2. XSD
    a. Remove attribute "language".
    b. Change the type of the "from" and "to" attributes in tAssignment to tExpression.
    c. Modify XSD snippet in Table 10.63 to match.
    3. UML metamodel
    a. Remove attribute "language".
    b. Change the "from" and "to" attributes in the Assignment class to be of type Expression.
    c. Replace Figure 10.61.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

XSD: mixed="true" is redundant in tFormalExpression element

  • Key: BPMN2-150
  • Legacy Issue Number: 14700
  • Status: closed  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    Since it inherits from a base element with mixed content, it does not need to define itself as mixed.

    Comments:
    From: ssamoojh@ca.ibm.com created: Tue, 19 May 2009 11:47:40 -0500 (CDT)
    The 'mixed' setting does not need to be redeclared. It is transitively inherited. tExpression inherits it from tBaseElementWithMixedContent. tFormalExpression also (and thus it does not need to be redeclared there).

    So there's a minor consistency issue (with tFormalExpression), but no technical issue to my knowledge.

    [Reducing the severity based on this information.]

    From: mariano.benitez created: Tue, 19 May 2009 12:23:01 -0500 (CDT)
    suggest to defer but agree the resolution (remove mixed=True from tFormalExpression)

    From: mariano.benitez created: Thu, 6 Aug 2009 09:20:03 -0500 (CDT)
    Testing notification scheme

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Table 8.68, page 103 (133 pdf): remove attribute 'mixed="true"' in the tFormalExpression complex type definition.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multiple PartnerEntities per Participant

  • Key: BPMN2-149
  • Legacy Issue Number: 14699
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Collaborations and other C models might be in reusable libraries, but
    currently their participants cannot be linked to multiple entities, and
    cannot be linked with modifying the C model. For example, a
    collaboration might describe a contract that many entities can enter
    into. This contract might be in a library and not be modifiable.
    Entities should still be able to refer to participants in it to indicate
    they commit to the contract. This commitment is made jointly by
    multiple entities, each linked to their own participants.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The associations from Participant to PartnerEntity and PartnerRole
    should be unidirectional from PartnerEntity and PartnerRole, rather than
    Participant, and have unbounded multiplicity on both ends. This enables
    modelers to assign entities and roles to interaction models in libraries
    without modifying the library.
    The resolution assumes the resolution of 14654.
    In the Collaborations chapter, Participants section, figure The
    Participant Class Diagram, on the partnerRoleRef and partnerEntityRef
    associations from Participant:

    • Change the 0..1 multiplicities to *.
    • Insert a "/" just before the association end names (but not part of
      the names).
    • Reverse the navigation direction of the associations (leaving the
      association end names where they are).
    • Name the unamed association ends "participantRef".
      In the Collaborations chapter, Participants section, in the table
      Participant attributes and model associations:
    • In the partnerRoleRef row, right column, at the end, add the
      sentence, "This attribute is derived from the participantRefs of
      Partner Roles."
    • In the partnerEntityRef row, right column, at the end, add the
      sentence, "This attribute is derived from the participantRefs of
      Entity Roles."
      In the Collaborations chapter, Participants section, PartnerEntity
      subsection, in the table PartnerEntity attributes, add a row at the end:
    • participantRef [0..*]
      Specifies how the Partner Entity participates in collaborations
      and choreographies.
      In the Collaborations chapter, Participants section, PartnerRole
      subsection, in the table PartnerEntity attributes, add a row at the end:
    • participantRef [0..*]
      Specifies how the Partner Role participates in collaborations
      and choreographies.
      In the Collaborations chapter, Collaboration Package XML Schemas
      section, in table Participant XML schema, remove:
      <xsd:attribute name="partnerRoleRef" type="xsd:QName" use="optional"/>
      <xsd:attribute name="partnerEntityRef" type="xsd:QName" use="optional"/>
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Section 12.4 Choreography Activities: Fix redundancy in the definition of these elements

  • Key: BPMN2-160
  • Legacy Issue Number: 14714
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    There is some redundancy in the definition of Choreography Activities. For example, Participants are listed as well as MF, which have source and targer Participants. Also, for one-way Tasks, the initiating Participant can be derived from the MF.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The initiatingParticipantRef is necessary for non one-way Choreography Activities. Removing the ParticipantRefs would not allow modelers to create Choreography
    Activities before defining the Message Flow.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Section 2.2 Process Execution Conformance: Describe this conformance apart from Process Modeling Conformance

  • Key: BPMN2-159
  • Legacy Issue Number: 14713
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Add a description of how a tool might conform to Process Execution independent of Process Modeling Conformance.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Make the following changes in section 2.2.1 Execution Semantics

    • Add the following text
      "The tool claiming Process Execution Conformance type is not expected to support Process Modeling Conformance. More precisely, the tool is not required to
      support graphical syntax and semantics defined in this specification. It MAY use different graphical elements, shapes and markers, then those defined in this
      specification."
      instead of
      "The tool claiming Process Execution Conformance type is not expected to support Process Modeling Conformance."
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use "item" terminology more uniformly

  • Key: BPMN2-158
  • Legacy Issue Number: 14712
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    > Terminology is perhaps the hardest part of standards such
    > as BPMN. There is no way to pick terms that will be
    > acceptable to all potential users of BPMN. Different groups
    > will come into BPMN with different expectations. Some of
    > the terms will fit those expectations and other will not.
    > [From <a href="http://www.omg.org/archives/bpmn2-eval/msg00048.html">http://www.omg.org/archives/bpmn2-eval/msg00048.html</a>]

    In this particular case, the submission has one already ("item", as in
    ItemDefinition, ItemAwareElement, and ItemKind), introduced to
    accomodate informational and physical flows. I think it would be good
    to have uniform terminology covering both information and physical
    things, for example:

    Message Flow => Item Flow
    (Message appears redundant with ItemDefinition, or Message could be
    a subclass of ItemDefinition for those items that happen
    to be used in Item Flows)
    Data Object => Item Object
    DataInput => ItemInput
    DataOutput => ItemOutput
    DataState => ItemState
    DataAssociations => ItemAssociations

    So much of BPMN's market is modeling businesses in general rather than
    business software specifically, that I think it's important for adoption
    to have the appropriate terminology.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    DataInputs/Outputs/Objects, Messages, and other BPMN elements can be
    physical, as defined in ItemDefinition, and it would be better if the
    names reflected that possibility. However, implementations are too far
    along to change at this point.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Service Task => Operation Task

  • Key: BPMN2-148
  • Legacy Issue Number: 14697
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Since the term "service" isn't used anymore in the interface and
    operation model, it would be better if ServiceTask were renamed, perhaps
    to OperationTask.

    Comments:
    From: ssamoojh@ca.ibm.com created: Thu, 28 May 2009 17:57:44 -0500 (CDT)
    Actually I was just about to open an issue, suggesting we rename "Interface" to "Service Interface", given that "Interface" is generally an overloaded term.

    From: conrad.bock created: Fri, 29 May 2009 08:15:35 -0500 (CDT)
    True, although I think it's less overloaded than "service", which has a
    very different business meaning than in software. I thought "operation"
    was more neutral, and it's what is actually invoked by a Service Task
    (see the operationRef attribute on ServiceTask).

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Business modelers will usually take the term "service" in the business
    sense, rather than in the operation invocation sense of WSDL or UML,
    which is the current meaning of ServiceTask. However, implementations
    are too far along to change the name at this point.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Editorial: Incorrect containment statement for EventDefinitions

  • Key: BPMN2-155
  • Legacy Issue Number: 14707
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Beta 1 spec page 238 (268 pdf) states that:
    "When one of the EventDefinition sub-types (e.g., TimerEventDefinition) is defined it is contained in Definitions."

    This is of course incorrect, since an EventDefinition can be contained by either the Definitions or the Catch/ThrowEvent.

    Comments:
    From: wstephe created: Wed, 23 Sep 2009 17:03:15 -0500 (CDT)
    The page number was updated to match the Beta 1 spec

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Change the paragraph to:
    "When one of the EventDefinition sub-types (e.g., TimerEventDefinition) is defined, it is either a reusable event definition contained in Definitions, or a contained event
    definition contained in a Throw/Catch Event."
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Misleading copy/paste para regarding Properties

  • Key: BPMN2-110
  • Legacy Issue Number: 14646
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    In the Lifecycle and Visibility section of Properties, the second para is misleading. The Para starts with "The visibility of a Property" this may lead to the misconception that Properties have depictions, which they don't. The para also refers to Process as flow elements and the scope example below does not really present the concept very well.

  • Reported: BPMN 2.0b1 — Tue, 17 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Beta 1, August 2009 (pdf version)
    (a) Page 183
    Change: "A DataObject has a well-defined lifecycle, with resulting visibility constraints."
    to
    "A DataObject has a well-defined lifecycle, with resulting access constraints."
    (b) Page 184
    Change: "Data Object elements are visible in a Process diagram."
    to
    "Data Object elements are visually displayed on a Process diagram."
    (c) Page 186
    Change heading "Lifecycle and Visibility"
    to "Lifecycle and Accessability"
    Change: "The visibility of a Data Object is driven by its lifecycle. "
    to
    "The accessibility of a Data Object is driven by its lifecycle. "
    Change:
    "Data object 1" is visible to: "Process A," "Task A," "Sub-Process A," "Task B," "Sub-Process B," "Sub-Process C,"
    "Task C," and "Task D."
    "Data object 2" is visible to: "Sub-Process A" and "Task B."
    "Data object 3" is visible to: "Sub-Process B," "Sub-Process C," "Task C," and "Task D."
    "Data object 4" is visible to: "Sub-Process C" and "Task C."
    to
    "Data object 1" can be accessed by: "Process A," "Task A," "Sub-Process A," "Task B," "Sub-Process B," "Sub-Process C," "Task C," and "Task D."
    "Data object 2" can be accessedby: "Sub-Process A" and "Task B."
    "Data object 3" can be accessed by: "Sub-Process B," "Sub-Process C," "Task C," and "Task D."
    "Data object 4" can be accessed by: "Sub-Process C" and "Task C."
    (d) Page 188
    Change
    "Properties, like Data Objects, are item-aware elements. But, unlike Data Objects, they are not visible within a Process diagram."
    to
    "Properties, like Data Objects, are item-aware elements. But, unlike Data Objects, they are not visually displayed on a Process diagram."
    Change
    "Property elements are NOT visible in a Process diagram."
    to
    "Property elements are NOT visually displayed on a Process diagram."
    (e) Page 189
    Change heading "Lifecycle and Visibility"
    to "Lifecycle and Accessability"
    Change
    "The visibility of a Property is driven by its lifecycle. The data within a Property can only be accessed when there is guaranteed to be a live Property instance present.
    As a result, a Property can only be accessed by its parent Flow Element or, when its parent Flow Element is a Process or Sub-Process, then by the immediate children
    of that Process or Sub-Process."
    to
    "The accessibility of a Property is driven by its lifecycle. The data within a Property can only be accessed when there is guaranteed to be a live Property instance
    present. As a result, a Property can be accessed by its parent Process, Sub-process or Flow Element. In case the parent is a Process or Sub-Process, then a property
    can be accesses by the immediate children (including children elements) of that Process or Sub-Process."
    (f) Page 190
    Change
    The Properties of "Process A" are visible to: All elements (including children elements) of this Process
    The Properties of "Sub-Process A" are visible to: "Sub-Process A" and "Task B."
    The Properties of "Task C" are visible to: "Task C."
    to
    The Properties of "Process A" are accessible by: "Process A", "Task A", "Sub-Process A", "Task B", "Sub_Process B", "Sub-Process C", "Task C" and "Task D"
    The Properties of "Sub-Process A" are accessible by: "Sub-Process A" and "Task B."
    The Properties of "Task C" are accessible by: "Task C."
    (g) Page 191
    Change
    "The DataInput is an item-aware element. DataInput elements may appear in a Process diagram to show the inputs to the Process as whole, which are passed along as
    the inputs of Activities by DataAssociations"
    to
    "The DataInput is an item-aware element. DataInput elements are visually displayed in on a Process diagram to show the inputs to the Process as whole, which are
    passed along as the inputs of Activities by DataAssociations."
    (h) Page 193
    Change
    "The DataOutput is an item-aware element. DataOutput elements appear in a Process diagram to show the outputs of the Process as whole, which are passed along
    from the outputs of Activities by DataAssociations."
    to
    "The DataOutput is an item-aware element. DataOutput elements are visually displayed on a Process diagram to show the outputs of the Process as whole, which are
    passed along from the outputs of Activities by DataAssociations. "
    Table 10.57 - DataAssociation model associations
    Change
    "Specifies an optional transformation expression. The actual scope of visible data for that expression is defined by the source and target of the specific data association
    types."
    to
    "Specifies an optional transformation expression. The actual scope of accessible data for that expression is defined by the source and target of the specific data
    association types."
    (j) Page 202
    Change
    "The source of such a DataAssociation can be every item-aware element visible to the current scope, e.g., a Data Object, a Property or an Expression."
    to
    "The source of such a DataAssociation can be every item-aware element accessible in the current scope, e.g., a Data Object, a Property or an Expression."
    Change
    "The DataOutputAssociation can be used to associate a DataOutput contained within an ACTIVITY with any item-aware element visible to the scope the association
    will be executed in. The target of such a DataAssociation can be every item-aware element visible to the current scope, e.g, a Data Object, a Property or an
    Expression."
    to
    "The DataOutputAssociation can be used to associate a DataOutput contained within an ACTIVITY with any item-aware element accessible in the scope the
    association will be executed in. The target of such a DataAssociation can be every item-aware element accessible in the current scope, e.g, a Data Object, a Property
    or an Expression."
    (k) Page 203
    Change
    "The visibility to the Expression language is defined based on the entities visibility to the Activity that contains the expression. All elements visible from the enclosing
    element of an XPath expression must be made available to the XPath processor."
    to
    "The accessibility by the Expression language is defined based on the entities accessibility by the Activity that contains the expression. All elements accessible from the
    enclosing element of an XPath expression must be made available to the XPath processor. "
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

URL referenced for WfMC Gloassary is incorrect


Definition of Participant Band Shadings not clear

  • Key: BPMN2-101
  • Legacy Issue Number: 14589
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The participant bands of Choreography Activities have different shadings, but chapter 12 does not define the shadings or the reasons. The differences are shown in a figure, but not defined in the text.

  • Reported: BPMN 2.0b1 — Fri, 30 Oct 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Section 12.4.1, page 316 (346 pdf): Add the following diamond bullet prior to Figure 12.8:
    "The Participant Band of the Participant that does not initiate the interaction MUST be shaded with a light fill."
    (b) Section 12.4.2, page 322 (352 pdf): Add the following diamond bullet prior to Figure 12.17:
    "The Participant Band of a Participant that does not initiate the interaction MUST be shaded with a light fill."
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing DataStore from the enumeration of item-awre elements at top of the page

  • Key: BPMN2-108
  • Legacy Issue Number: 14644
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The first para at the top of page 212 lists the possible item-aware elements but is missing the DataSore as per the class diagram below it Figure 10-46

  • Reported: BPMN 2.0b1 — Tue, 17 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 10.3,1 Sub-Section "Item-Aware Elements," page 182 (212 pdf), last sentence on page: add "Data Stores" to list of elements in the sentence.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Merge Conversation and Collaboration

  • Key: BPMN2-107
  • Legacy Issue Number: 14641
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Conversation and Collaboration currently differ because Conversation
    messages can grouped, and Conversation can be reused. Since these
    capabilities are useful on collaboration, it would be simpler for users
    and implementers to merge these diagrams. Then there would be two
    interactions diagrams, one highlighting communication between
    participants (collaboration/conversation) and one highlighting the
    sequence of message flow (Choreography). This would be easier to
    explain and reduce the terminology complexity of the "three C models".

  • Reported: BPMN 2.0b1 — Mon, 16 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14654 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Variable Id TO Variation Id

  • Key: BPMN2-100
  • Legacy Issue Number: 14579
  • Status: closed  
  • Source: Red Hat ( Gary Brown)
  • Summary:

    Page 326 of pdf: para below Figure 11.4 refers to "(keyed on Variable Id and Order Id)", however the figure 11.4 uses Variation ID and Order ID.

    Proposal: change "Variable Id" in paragraph to "Variation Id".

  • Reported: BPMN 2.0b1 — Mon, 26 Oct 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 11, page 296 (page 326 pdf), first paragraph after Figure 11.4, second sentence: change "Varable ID" to "Variation ID"
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Conversation Muddle

  • Key: BPMN2-106
  • Legacy Issue Number: 14623
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The concept of conversation is muddled in the idea of a logical grouping of message flow and a diagram that contains a set of these groupings. Conversations should be a light-weight element defined to be used in any diagram that has message flow.

  • Reported: BPMN 2.0b1 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14654 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Correlation on Choregraphy

  • Key: BPMN2-105
  • Legacy Issue Number: 14622
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    It should be possible to add correlation to
    choreography, without creating a conversation.
    Sometimes interactions are only described with
    choreograpies, and they might need correlation

  • Reported: BPMN 2.0b1 — Thu, 12 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution to this issue was resolved through Issue 14654 (14654)
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Typo in Section 7.2 paragraph 1

  • Key: BPMN2-104
  • Legacy Issue Number: 14617
  • Status: closed  
  • Source: TIBCO ( Justin Brunt)
  • Summary:

    The second sentence of the first paragraph in section 7.2 states: "The goal of
    the specification is to enable portability of Process definitions, so that users can take Process definitions created in
    one vendor’s environment and use them is another vendor’s environment."

    The final part of the sentence should read "and use them in another vendor’s environment."

    i.e. "is" should become "in"

  • Reported: BPMN 2.0b1 — Tue, 10 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 7.1, page 14 (page 44 pdf), first paragraph, second sentence: change "use them is another" to "use them in another"
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing details regarding the visualisation of a DataState for a DataObject

  • Key: BPMN2-109
  • Legacy Issue Number: 14645
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The section discussing States of DataObject at the bottom of page 213 refers to Figure 7-8 to examplify the visualization of a DataState attribute of a DataObject but fails to specify the details of this visualizaton (i.e. in this particular case using square brackets surrounding the DataState value).

    Or is the visualization left to the vendor tool?

  • Reported: BPMN 2.0b1 — Tue, 17 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close this issue as a duplicate.
    The proposals for OMG 15080 (15080) will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

URL referenced for XPDL specification is incorrect


Need to revisit and test the process example in the spec (Figure 7-8)

  • Key: BPMN2-143
  • Legacy Issue Number: 14692
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Need to revisit and test the process example in the spec (Figure 7-8). I'm not convinced this example 'works'.

    Some immediate concerns:

    • Process Parts does not have any data output. So I'm not sure what the conditional sequence flow out of it would evaluate against.
    • The 'artifact extensions' appear to be used like data-aware elements, but they're not really.

    I'd suggest we validate the example further.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Replace Figure 7.8 with the figure shown here:
    (Figure+7-8+Proposal+2010-04-01.png)
    To address the first concern, a data output has been introduced to the sub-process 'Procure Parts', which the conditional sequence flow can now evaluate against.
    The artifact extension 'Order Folder' and the associations connected to it have been substituted by two data associations from the data objects 'Assemblies (1..n)' and
    'Invoice' to the human task 'Send Assemblies & Invoice to Customer'.
    This usage of an artifact extension is possible, but miss-leading, because it suggests that the artifact is a data object connected via data associations. However, a data
    association can only connect a data object with an activity or event, but not data objects with each other. See also page 198 (230): 'The DataAssociation class is a
    BaseElement contained by an Activity or Event, [...]'
    All remaining artifact extensions have also been removed.
    Besides this, we made some minor layout improvements that did not change the semantics.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Service Package => Interface Package

  • Key: BPMN2-142
  • Legacy Issue Number: 14691
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Since the term "service" isn't used anymore in the interface and
    operation model, it would be better if the Service Package were renamed,
    perhaps to Interface Package.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The proposal is to close the issue with no changes to the specification. Concepts "interface" and "operation" are used to model services. There is no need to rename
    "Service Package" as term "service" is a "superordinate" concept.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Lanes and Sequence Flow

  • Key: BPMN2-147
  • Legacy Issue Number: 14696
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    As per the current spec, a Lane references FlowElements. But FlowElements include SequenceFlow, which introduces issues given that SequenceFlow can span Lanes (e.g. the source is in one Lane while the target is in another).

    Recommendation: The spec text should indicate that SequenceFlow are not included in the list of FlowElements referenced by a Lane. Tools are then responsible for presenting and laying out the SequenceFlow appropriately, based on its source and targets.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Lanes will reference FlowNodes, which exclude SequenceFlows (only activities, events and gateways are FlowNodes).
    We will change the semantic metamodel to reflect this change.
    a) in Figure 10.122 - The Lane class diagram , replace FlowElement with FlowNode
    b) below Figure 10.122, replace Flow Element with FlowNodes in these sentences:

    • "Each LaneSet and its Lanes can partition the Flow Elements in a different way."
    • "a tool can use to determine the list of Flow Elements to be partitioned into this Lane"
      c) in Table 10.128 - Lane attributes and model associations
      Replace flowElementRefs with flowNodeRefs, and FlowElement with FlowNode
      d) in Table 10.132 - Lane XML Schema
      Replace flowElementRef with flowNodeRef in this snippet
      <xsd:sequence>
      <xsd:element name="partitionElement" type="tBaseElement" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="flowElementRef" type="xsd:IDREF" minOccurs="0" maxOccurs="
      unbounded"/>
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Grouping message flow in Collaboration

  • Key: BPMN2-146
  • Legacy Issue Number: 14695
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Message flow can be grouped in Choreography and Conversation, and should
    be in Collaboration also. For example, a collaboration participant
    might have a process with a call activity that send/receives many
    messages. The modeler should be able to show these as a single line
    between the activity and the other participant, as in a conversation.
    otherwise, the modeler can only show the most detailed view of the
    interaction, with every lowest level message flow in the diagram.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14564 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

CorrelationSubscription Ownership

  • Key: BPMN2-137
  • Legacy Issue Number: 14685
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 8-18 (The Correlation Class Diagram) shows only one-way
    references away from CorrelationSubscription. What owns
    CorrelationPropertyBindings? Table 8-35 (CorrelationSubscription model
    associations) says it's a BaseElement, and that it has a Process
    attribute. The subsection on Context-based Correlation in Section 8.3.3
    (Correlation) implies it is owned by Process.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    > Section 8.3.3 Correlation
    Figure 8.18 - The Correlation Class Diagram
    Change metamodel
    Original
    CorrelationSubscription is contained in Common package but is not contained by any concept
    Proposal (in accordance with Table 8.35 - CorrelationSubscription model associations)
    1 Process contains n CorrelationSubscriptions. Each CorrelationSubscription is contained by exactly 1 Process. Add association from Process to
    CorrelationSubscription.
    > Section 10 Process
    Figure 10.3 - Process Details class diagram
    Change metamodel
    Original
    Process class has no association to CorrelationSubscription class.
    Proposal
    Add containment Process CorrelationSubscription: 1 Process contains n CorrelationSubscriptions.
    Table 10.1 - Process Attributes & Model Associations
    Append row: subscriptions: CorrelationSubscription [0..*]
    Original
    N/A
    Proposal
    Attribute Name
    subscriptions: CorrelationSubscription [0..*]
    Description/Usage
    Correlation Subscriptions are a feature of context-based correlation (cf. section 8.3.3). Subscriptions are used to correlate incoming messages against data in the
    Process context. A Process may several subscriptions.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantic metamodel => Abstract syntax

  • Key: BPMN2-138
  • Legacy Issue Number: 14687
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The term "semantics" is used in execution to refer to how a model is
    translated to runtime (or business) behavior, which is the technical
    meaning of the word. Metamodels, on the other hand, are a kind of
    syntax that omits some details of the pictures appearing on the screen.
    Would be better to use the term "Abstract syntax" instead of "Semantic
    metamodel" when it's necessary to distinguish it from the diagram
    metamodel.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Metamodels are an abstract form of syntax that omits some aspects of
    visual (concrete) syntax. Semantics is about how a business behaves
    given a model defined with the syntax.
    Above Figure 8.2 (Class diagram showing the core packages), first
    bullet, replace "semantic modeling" with "modeling".
    Section 8.2 (Foundation), first sentence, replace "semantic model"
    with "abstract syntax model".
    Section A.1 (Changes from BPMN, v1.2), third paragraph, second bullet,
    replace "semantic model" with "abstract syntax model".
    Section 8.1 (Infrastructure), first sentence, replace "semantic models"
    with "abstract syntax models".
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Error class has no 'name' attribute

  • Key: BPMN2-144
  • Legacy Issue Number: 14693
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    For it to be usable, it needs a 'name' attribute

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Table 8.43: Add a new attribute called "name", with description "The descriptive name of the error".
    (b) Table 8.64 (schema snippet): Update XSD snippet to add the 'name' attribute.
    <xsd:element name="error" type="tError" substitutionGroup="rootElement"/>
    <xsd:complexType name="tError">
    <xsd:complexContent>
    <xsd:extension base="tRootElement">
    <xsd:attribute name="name" type="xsd:string"/>
    <xsd:attribute name="structureRef" type="xsd:QName"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>
    (c) Figure 8.20: Replace with
    (Error+Metamodel.jpg)
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Conversation/Communication switch

  • Key: BPMN2-140
  • Legacy Issue Number: 14689
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    A number of places in the text use the word "conversation" that should
    be "communication", for example Figure 11-1 and in Section 11 (eg, A
    Conversation is set of Message exchanges (Message Flow) that share the
    same correlation).

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This is addressed by the resolution of 14654.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Choreography Subprocess => Subchoreography

  • Key: BPMN2-141
  • Legacy Issue Number: 14690
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    To avoid confusion of Choreography with Process, and to be consistent
    with naming of analogous elements in Process, it seems like Choreography
    Subprocess should be renamed to Subchoreography.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Change all occurrences of "Choreography Sub-Process" to "Sub-Choreography"
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Typo in Terminate Event description

  • Key: BPMN2-145
  • Legacy Issue Number: 14694
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    See pg. 270 of spec version 0.9.13.

    The section is for the Terminate Event, but it talks about the CancelEventDefinition rather than the TerminateEventDefinition.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Change CancelEventDefinition with TerminateEventDefinition in the paragraph
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

MessageFlowRefs missing from Conversation metamodel diagram

  • Key: BPMN2-139
  • Legacy Issue Number: 14688
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    MessageFlowRefs missing from Conversation metamodel diagram (compare to
    Conversation attributes table).

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14654 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Section 11 Conversation:

  • Key: BPMN2-117
  • Legacy Issue Number: 14654
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Beta 1 Section 11 Conversation: The concepts of Conversation, Conversation Diagram, and Communication are too confusing. The distinctions between Conversation and Communication are not clear. It appears as though the Conversation is used for multiple concepts, including a diagram. This should be clarified.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The proposal is to merge the Collaboration and Conversation diagrams.
    While the proposal is complicated it will:

    • Significantly simplify implementation by reducing the number of metamodel elements, metamodel complexity, and required text restriction
    • Provides a better alignment with another standard: SoaML
    • There would be no loss of current end-user functionality
      The Proposal includes:
      (a) Delete Chapter 11. It's contents will be moved to Chapter 9 as detailed below
      Modifications to Section 8
      (b) Section 8, page 39 (69 pdf), last paragraph: change "Choreography, Collaboration, and Conversation" to "Choreography, and Collaboration"
      (c) Figure 8.3, replace figure with new organization of Core elements (see Specification Convenience Document)
      (d) Section 8.3, page 55 (85 pdf), first sentence: change "Collaboration, Conversation, and Choreography" to "Collaboration, and Choreography"
      (f) Figure 8.8, replace figure with new organization of Artifact elements (see Specification Convenience Document)
      (g) Section 8.3.2, page 63 (93 pdf), replace first sentence with: "CallableElement is the abstract super class of all elements that have been defined outside of a Process,
      but which can be called (or reused), by a Call Activity, from within a Process."
      (h) Section 8.3.2, page 63 (93 pdf), add at the end of the first paragraph: "The BPMN elements that can be called by Call Activities (i.e., are Callable Elements) are:
      Process and GlobalTask (see Figure 8.17)."
      Figure 8.17, replace figure with new organization of Callable elements (see Specification Convenience Document)
      (j) Move Section 8.3.2 to a subsection of Section 10.2.6
      (k) Section 8.3.3, page 65 (95 pdf), change first sentence to: "The concept of Correlation facilitates the association of a Message to a Send Task or Receive Task,
      often in the context of a Conversation, which is also known as instance routing."
      (l) Section 8.3.3, page 65 (95 pdf), second sentence: change "Conversation, Choreography" to "Collaboration (Conversation), Choreography"
      (m) Figure 8.18, replace figure with new organization of Correlation elements (see Specification Convenience Document)
      Table 8.32, CorrelationKey: delete the row for the conversation attribute
      (o) Section 8.3.4, page 71 (101 pdf), replace first paragraph with "These elements are used to do mapping between two elements that both contain Conversation
      Nodes. The ConverstaqionAssociation provides the mechanism to match up the Conversation Nodes."
      (p) Section 8.3.4, page 71 (101 pdf), second paragraph, delete second sentence
      (q) Section 8.3.4, page 71 (101 pdf), replace first bullet on page with: "A Collaboration references a Choreography for inclusion between the Collaboration's Pools
      (Participants). The Conversation Nodes of the Choreography (the inner diagram) need to be mapped to the Conversation Nodes of the Collaboration (the outer
      diagram)."
      (r) Section 8.3.4, page 71 (101 pdf), delete second bullet on page
      (s) Figure 8.18, replace figure with new organization of Conversation elements (see Specification Convenience Document)
      (t) Table 8.42, page 72 (102 pdf), delete first row of table
      (u) Table 8.42, page 72 (102 pdf), replace first column of second row with: "innerConversationNodeRef: ConversationNode"
      (v) Table 8.42, page 72 (102 pdf), replace second column of second row with: "This attribute defines the Conversation Nodes of the referenced element (e.g., a
      Choreography to be used in a Collaboration) that will be mapped to the parent element (e.g., the Collaboration)."
      (w) Table 8.42, page 72 (102 pdf), replace first column of third row with: "outerConversationNodeRef: ConversationNode"
      Table 8.42, page 72 (102 pdf), replace second column of third row with: "This attribute defines the Conversation Nodes of the parent element (e.g., a
      Collaboration references a Choreography) that will be mapped to the referenced element (e.g., the Choreography)."
      Move Section 8.3.4 to Section 11 after Section 11.7. The Contents of Section 11 will be moved to Section 9 as described below.
      (z) Figure 8.24, replace figure with new organization of Flow Element Container elements (see Specification Convenience Document)
      (a2) Table 8.46: delete second row (artifacts attribute)
      (b2) Delete section 8.3.11, Interaction Specification. All Interaction Specification characters have been moved to Collaboration (Section 9 and detailed below)
      (c2) Section 8.3.14, page 87 (117 pdf), first paragraph (non-bullet): delete "(the view showing the Choreography Process Combined with Orchestration Processes)"
      from first sentence.
      (d2) Section 8.3.14, page 88 (118 pdf), first paragraph : Change "Choreography Task" to "Choreography"
      (e2) Figure 8.24, replace figure with new organization of Flow Element Container elements (see Specification Convenience Document)
      (f2) Section 8.3.14, Sub-Section Message Flow Association, page 90 (120 pdf), second paragraph: Delete second sentence
      (g2) Section 8.3.14, Sub-Section Message Flow Association, page 90 (120 pdf): Delete the second and third bullet on the page.
      (h2) Figure 8.39, replace figure with new organization of Message Flow Association elements (see Specification Convenience Document)
      (i2) Move Section 8.3.14 to Section 9 and make it Section 9.3
      (j2) Section 8.3.15, page 91 (121 pdf), second paragraph, second sentence: Change "InteractionSpecification" to "Collaboration"
      (k2) Section 8.3.15, page 91 (121 pdf), second paragraph, second sentence: Change "Collaboration, a Choreography, a Conversation, a Global Communication, or a
      GlobalChoreographyTask" to "Choreography, GlobalConversation, or GlobalChoreographyTask"
      (l2) Figure 8.40, replace figure with new organization of Participant elements (see Specification Convenience Document)
      (m2) Section 8.3.15, Sub-Section Participant Multiplicity, second paragraph: Change "Choreography" to "Collaboration"
      (n2) Section 8.3.15, Sub-Section Participant Association, second paragraph: Change "three (3)" to "four (4)"
      (o2) Section 8.3.15, Sub-Section Participant Association: replace the second bullet with the following: "A CallConversation references a Collaboration or
      GlobalConversation. Thus, the Participants of the Collaboration or GlobalConversation (the inner diagram) need to be mapped to the Participants referenced by the
      CallConversation (the outer element). Each CallConversation contains its own set of ParticipantAssociations."
      (p2) Section 8.3.15, Sub-Section Participant Association: replace the third bullet with the following: "A CallChoreography references a Choreography or
      GlobalChoreographyTask. Thus, the Participants of the Choreography or GlobalChoreographyTask (the inner diagram) need to be mapped to the Participants
      referenced by the CallChoreography (the outer element). Each CallChoreography contains its own set of ParticipantAssociations."
      (q2) Section 8.3.15, Sub-Section Participant Association: add a forth bullet with the following: "A CallActivity within a Process that has a definitional Collaboration
      references another Process that also has a definitional Collaboration. The Participants of the definitional Collaboration of the called Process (the inner diagram) need to
      be mapped to the Participants of the definitional Collaboration of the calling Process (the outer diagram)."
      (r2) Figure 8.43, replace figure with new organization of Participant Association elements (see Specification Convenience Document)
      (s2) Move Section 8.3.15 to Section 9 and make it Section 9.2.1
      (t2) Move Table 8.62 to Section 10.2.9
      (u2) Table 8.63, replace the "extension" section of the table with the following:
      "<xsd:extension base="tBaseElement">
      <xsd:sequence>
      <xsd:element name="innerConversationNodeRef" type="xsd:QName"/>
      <xsd:element name="outerConversationNodeRef" type="xsd:QName"/>
      </xsd:sequence>
      </xsd:extension>"
      (v2) Move Tables 8.63, 8.72, 8.73, 8.74, 8.75, 8.76, and 8.77 to Section 9.5 Collaboration Package XML Schemas
      Modifications to Section 7
      (w2) Section 7.1.1, Sub-Section Conversations, first paragraph, first sentence: change "The Conversation diagram is similar to a Collaboration diagram" to "The
      Conversation diagram is a particular usage of and an informal description of a Collaboration diagram"
      (x2) Section 7.1.1, Sub-Section Conversations, first paragraph, second sentence: change "Pools of a Conversation are not allowed to contain a Process and a
      Choreography is not allowed to be placed in between the Pools" to "Pools of a Conversation are usually do not contain a Process and a Choreography is usually not
      placed in between the Pools"
      (y2) Section 7.1.1, Sub-Section Conversations, second paragraph: change "Communication" to "Conversation"
      Modifications to Section 9
      (z2) Section 9, second paragraph: after the first sentence add the following sentence: "A Choreography is an extended type of Collaboration."
      (a3) Figure 9.1, replace figure with new organization of Collaboration elements (see Specification Convenience Document)
      (b3) Section 9, paragraph before Table 9.1: delete ", and InteractionSpecification (see Table 8.48)"
      (c3) Table 9.1: add row to top of table with "name: string [0..1]" in the first column and "The descriptive name of the Collaboration." in the second column.
      (d3) Table 9.1, choreographyRef attribute row: replace the second column with the following:
      "The choreographyRef model association defines a Choreography that is shown between the Pools of the Collaboration. A Choreography specifies a business contract
      (or the order in which messages will be exchanged) between interacting Participants. See page 327 for more details on Choreography.
      The participantAssociations (see below) are used to map the Participants of the Choreography to the Participants of the Collaboration.
      The MessageFlowAssociations (see below) are used to map the Message Flows of the Choreography to the Message Flows of the Collaboration.
      The ConversationAssociations (see below) are used to map the Conversations of the Choreography to the Conversations of the Collaboration.
      Note that this attribute is not applicable for Choreography or GlobalConversation which are a subtypes of Collaboration. Thus, a Choreography cannot reference
      another Choreography."
      (e3) Table 9.1: add row after ChoreographyRef attribute row with "correlationKey: CorrelationKey [0..*]" in the first column and "This association specifies
      correlationKeys used to associate Messages to a particular Collaboration." in the second column.
      (f3) Table 9.1, conversationAssociations attribute row: replace the second column with the following:
      "This attribute provides a list of mappings from the Conversations of a referenced Collaboration to the Conversations of another Collaboration. It is used when:
      • When a Choreography is referenced by a Collaboration."
      (g3) Table 9.1, conversations attribute row: replace "Conversation" with "ConversationNode"
      (h3) Table 9.1, conversations attribute row: replace the second column with the following:
      "The conversations model aggregation relationship allows a Collaboration to contain Conversation elements, in order to group Message Flow of the Collaboration and
      associate correlation information, as is required for the definitional Collaboration of a Process model. The Conversation elements will be visualized if the Collaboration
      is a Collaboration, but not for a Choreography."
      (i3) Table 9.1: add row after artifacts attribute row with "participants: Participant [0..*]" in the first column and "This provides the list of Participants that are used in the
      Collaboration. Participants are visualized as Pools in Collaboration and as Participant Bands in Choreography Activities for Choreography." in the second column.
      (j3) Table 9.1, participantAssociations attribute row: replace the second column with the following:
      "This attribute provides a list of mappings from the Participants of a referenced Collaboration to the Participants of another Collaboration. It is used in the following
      situations:
      • When a Choreography is referenced by a Collaboration.
      • When a definitional Collaboration for a Process is referenced through a CallActivity (and mapped to definitional Collaboration of the calling Process)."
      (l3) Table 9.1: add row after participantAssociations attribute row with "messageFlow: Message Flow [0..*]" in the first column and "This provides the list of Message
      Flow that are used in the Collaboration. Message Flow are visualized in Collaboration (as dashed line) and hidden in Choreography." in the second column.
      (m3) Table 9.1, messageFlowAssociations attribute row: replace the second column with the following:
      "This attribute provides a list of mappings for the Message Flow of the Collaboration to Message Flow of a referenced model. It is used in the following situations:
      • When a Choreography is referenced by a Collaboration. This allows the "wiring up" of the Collaboration Message Flow to the appropriate Choreography Activities."
      (n3) Section 9, after Table 9.1: split first paragraph into two paragraphs after the first sentence
      (o3) Section 9, after Table 9.1: replace the first sentence of the newly created paragraph (the second paragraph) with the following: "Correlations are the mechanism
      that is used to assign the Messages to the proper Process instance, and can be defined for the Message Flow that belong to a Conversation."
      (p3) Move the text from the newly created paragraph until the end of the section (stopping at Section 9.1) to a new section (to be created) and label that section "9.4.8
      Correlations"
      (q3) Section 9.2, first paragraph, first sentence: delete "or a Choreography"
      (r3) Section 9.3: Change title of section to "Process within Collaboration"
      (s3) Figure 9.8, replace figure with new organization of Choreography and Collaboration elements (see Specification Convenience Document)
      (t3) Table 9.2, Collaboration XML Schema: Change "<xsd:element ref="conversation"" to "<xsd:element ref="conversationNode""
      (u3) Table 9.2, Collaboration XML Schema: add the following to the <xsd:sequence> section:
      "<xsd:element ref="correlationKey" minOccurs="0" maxOccurs="unbounded"/>"
      Modifications to Section 10
      (v3) Figure 10.2, replace figure with new organization of Process detail elements (see Specification Convenience Document)
      (w3) Table 10.3: add row after laneSets attribute row with "artifacts: Artifact [0..*]" in the first column and "This attribute provides the list of Artifacts that are
      contained within the Process." in the second column.
      (x3) Figure 10.28, replace figure with new organization of Sub-Process elements (see Specification Convenience Document)
      (y3) Table 10.3: add row after triggeredByEvent attribute row with "artifacts: Artifact [0..*]" in the first column and "This attribute provides the list of Artifacts that are
      contained within the Sub-Process." in the second column.
      Modifications to Section 11
      (z3) Section 11: Replace "Communication" with "Conversation" throughout section
      (a4) Section 11: Replace "GlobalCommunication" with "GlobalConversation" throughout section
      (b4) Section 11: Replace "CommunicationLink" with "ConversationLink" throughout section
      (c4) Section 11: replace first paragraph with the following: "The Conversation diagram is a particular usage of and an informal description of a Collaboration diagram.
      In general, it is a simplified version of Collaboration, but Conversation diagrams do maintain all the features of a Collaboration."
      (d4)Section 11: replace first bullet in section with the following: "Conversation Node elements (Conversation, Sub-Conversation, and Call Conversation)"
      (e4) Section 11, first sentence after second bullet: replace sentence with the following: "A Conversation is a logical grouping of Message exchanges (Message Flow)
      that can share a Correlation."
      (f4) Section 11, first paragraph after Figure 11.1: add the following to the end of the paragraph: "Note that the diagram looks the same as a simple Collaboration
      diagram (as in Figure 9.3, above)."
      (g4) Section 11, second paragraph after Figure 11.2: add the following to the end of the sentence: ", but the Conversations are not visualized in a Choreography"
      (h4) Section 11, third paragraph after Figure 11.2, first sentence: replace "Choreography" with "Collaboration"
      (i4) Section 11: delete Figure 11.5 and the paragraph above it.
      (j4) Section 11: delete Table 11.1, the paragraph above it and the paragraph below it.
      (k4) Delete Section 11.1
      (l4) Section 11.2, first paragraph: replace "all elements that can appear in a Conversation diagram" with "all elements that comprise the Conversation elements of a
      Collaboration diagram"
      (m4) Section 11.2: add figure after first paragraph with the title: "Metamodel of ConversationNode Related Elements" (see Specification Convenience Document)
      (n4) Table 11.3: add row with "messageFlowRefs: MessageFlow [0..*]" in the first column and "A reference to all Message Flows (and consequently Messages)
      grouped by a Conversation element." in the second column.
      (o4) Table 11.3 : add row with "correlationKeys: CorrelationKey [0..*]" in the first column and "This is a list of the ConversationNode's correlationKeys, which are
      used to group Message Flows for the ConversationNode." in the second column.
      (p4) Section 11.3, first sentence: change "Conversation diagram" to "Conversation (Collaboration) diagram"
      (q4) Section 11.3. second sentence: replace "single" with "concept and/or a"
      (r4) Section 11.3, first paragraph before Table 11.4: Delete second sentence and add the following to the end of the first sentence: "but does not contain any additional
      attributes or model associations"
      (s4) Delete Table 11.4
      (t4) Section 11.4, first paragraph, first sentence: replace "parent Conversation" with "parent Collaboration"
      (u4) Section 11.4, first paragraph, second sentence: replace "within a Conversation" with "within a Collaboration"
      (v4) Table 11.5: replace the first column of the first row with the following: "conversationNodes: ConversationNode [0..*]"
      (w4) Table 11.5: replace the second column of the first row with the following: "The ConversationNodes model aggregation relationship allows a Sub-Conversation to
      contain other ConversationNodes, in order to group Message Flow of the Sub-Conversation and associate correlation information."
      (x4) Section 11.5, first sentence: change "in the Conversation" to " in the Conversation (Collaboration)"
      (y4) Section 11.5, second bullet: change "calls a Conversation" to "calls a Collaboration"
      (z4) Table 11.6, first row, first column: change "calledElementRef" to "calledCollaborationRef" and change "CallableElement" to "Collaboration"
      (a5) Table 11.6, first row: replace second column with the following:
      "The element to be called, which MAY be either a Collaboration or a GlobalConversation.
      The called element MUST NOT be a Choreography or a GlobalChoreographyTask (which are subtypes of Collaboration)"
      (b5) Section 11.5: add the following after Table 11.6: "Note - The ConversationNode attribute messageFlowRef doesn't apply to Call Conversations."
      (c5) Section 11.6, first sentence: Change "within any Conversation" to "within any Collaboration"
      (d5) Section 11.6: Replace the second paragraph with the following:
      "The GlobalConversation element inherits the attributes and model associations of Collaboration (see Table 8.48), but does not have any additional attributes or model
      associations.
      A GlobalConversation is a restricted type of Collaboration, it is an "empty Collaboration."
      [diamond bullet] A GlobalConversation MUST NOT contain any ConversationNodes.
      Since a GlobalConversation does not have any Flow Elements, it does not require MessageFlowAssociations, ParticipantFlowAssociations, or
      ConversationFlowAssociations or Artifacts. It is basically a set of Participants, Message Flows , and correlationKeys intended for reuse. Also, the Collaboration
      attribute choreographyRef is not applicable to GlobalConversation."
      (e5) Delete Table 11.7
      (f5) Move all tables in Section 11.8 (XML Schemas) to Section 9.5
      (g5) Move all remaining contents of Section 11 to Section 9.4 and name that section "Conversations"
      Modifications to Section 12
      (h5) Replace "Choreography Sub-Process" with "Sub-Choreography" throughout section
      (i5) Figure 12.1, replace figure with new organization of Choreography elements (see Specification Convenience Document)
      (j5) Section 12.1, first paragraph after Figure 12.1: replace "CallableElement" with "Collaboration"
      (k5) Section 12.1, first paragraph after Figure 12.1: Delete the second sentence and add the following to the end of the first sentence: ", but does not have any
      additional attributes or model associations.
      (l5) Delete Table 12.1
      (m5) Add the following paragraph to the end of the section (before Section 12.1): "Note - The Collaboration attribute choreographyRef is not applicable to
      Choreography."
      (n5) Section 12.3.1, page 313 (343 pdf), last bullet on page, first sentence: replace "the isClosed attribute of a Choreography" with "the isClosed attribute (from
      Collaboration)"
      (o5) Figure 12.6: replace figure with new organization of Choreography Activity elements (see Specification Convenience Document)
      (p5) Section 12.4.2, last paragraph in section (before Section 12.4.3): replace the second sentence with the following: "Table 12.X presents the additional model
      associations of the Sub-Choreography element"
      (q5) Section 12.4.2, after last paragraph in section: Add a table entitled "Sub-Choreography Model Associations" with one row, with "artifacts: Artifact [0..*]" in the
      first column and "This attribute provides the list of Artifacts that are contained within the Sub-Choreography." in the second column
      (r5) Replace "Call Choreography Activity" with "Call Choreography" throughout section
      (s5) Figure 12.27, replace figure with new organization of Call Choreography elements (see Specification Convenience Document)
      (t5) Table 12.4, first row, first column: change "calledElementRef" to "calledChoreographyRef" and change "CallableElement" to "Choreography"
      (u5) Table 12.4, first row, second column: delete second sentence of column
      (v5) Table 12.4, second row, second column: change "containing" to "referenced by"
      (w5) Section 12.4.4, second paragraph, first sentence: Change "CallableElement" to "Collaboration" and add the following to the end of the sentence: "through its
      relationship to Choreography"
      (x5) Section 12.4.4: add the following after Table 12.5:
      "A GlobalChoreographyTask is a restricted type of Choreography, it is an "empty Choreography."
      [diamond bullet] A GlobalChoreographyTask MUST NOT contain any Flow Elements.
      Since a GlobalChoreographyTask does not have any Flow Elements, it does not require MessageFlowAssociations, ParticipantFlowAssociations, or
      ConversationFlowAssociations or Artifacts. It is basically a set of Participants and Message Flows intended for reuse."
      (y5) Table 12.9: change "substitutionGroup="rootelement"" to "substitutionGroup="collaboration""
      (z5) Table 12.9: change "base="tCallableElement"" to "base="tCollaboration""
      (a6) Table 12.9: delete the following:
      "<xsd:element ref="artifact" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element ref="messageFlow" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element ref="participant" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element ref="conversation" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element name="conversationAssociation" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element ref="messageFlowAssociation" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element ref="participantAssociation" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:attribute name="isClosed" type="xsd:boolean" default="false"/>"
      (b6) Table 12.10: change "substitutionGroup="rootelement"" to "substitutionGroup="choreography""
      (c6) Table 12.10: change "base="tCallableElement"" to "base="tChoreography""
      (d6) Table 12.10: delete the following:
      "<xsd:sequence>
      <xsd:element ref="participant" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element ref="messageFlow" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>"
      (e6) Table 12.13: change "calledElement" to "calledChoreographyRef"
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Private process example correction

  • Key: BPMN2-116
  • Legacy Issue Number: 14652
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The private process in Figure 10-122 (One Process supporting to another)
    should have activity X and event B in parallel, because event B may
    arrive while X is executing, which would be lost in the current example.
    See webinar example on slide 51 in bmi/09-06-02.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Replace Figure 10.123 (One Process supporting to another) with the one given in the attachment
    BPMNFTF-341-private-process-example.pdf.
    (b) In paragraph above Figure 10.123, next to last sentence (the one beginning "It also introduces"), replace "Activity" with "Activities".
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multiple properties / keys clarification

  • Key: BPMN2-112
  • Legacy Issue Number: 14648
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    http://www.osoa.org/jira/browse/BPMN-585
    Does the first message in an Conversation need to have values for all
    the properties of a correlation key, or can some values appear in later
    messages?

    When a conversation has multiple correlation keys, do all the properties
    of all the keys need to match in each message, or just the properties
    for one of the keys?

    Can a message later in a conversation send values for only some of the
    properties in a key?

    Comments:
    From: conrad.bock created: Tue, 4 Aug 2009 14:15:01 -0500 (CDT)
    Conrad,

    I doubt the spec is precise enough on that yet - so here is my
    personal take on what we want it to say:

    • All properties constituting a correlation key MUST (SHOULD?) be set
      by a single message in a conversation (Rationale: We don't want a
      partially set key.)
    • Not all correlation keys of a given conversation need to be set at
      any given time. (Rationale: Conversation keys could be added over
      the lifetime of a conversation, no reason to prevent this.)
    • When associating an (inbound) message with a conversation, all
      properties of all correlation keys contained in that message must
      match those already set for the conversation (instance). (Rationale:
      We could relax that, having it strict simplifies the rules and
      increases usability; I don't see why a message would ever contain
      multiple correlation keys some of which do not match, but could be
      convinced otherwise through scenarios. Of course a message does not
      have to contain properties for all correlation keys that may be used
      for a conversation, but those that it uses must match.)

    With that the answers to your questions would be:

    • Not all must be contained, some could be delivered later - for
      those correlation happens based on the keys that were already set
      by the first message.
    • Yes, all must match - see rationale above, we could relax that if
      we see a good reason.

    Hopefully that makes sense - and hopefully I got the terminology
    right, admittedly I didn't check back with the spec but answered from
    memory.

    Viele Grüße/Kind regards,
    -Matthias

    From: conrad.bock created: Wed, 5 Aug 2009 08:40:28 -0500 (CDT)
    These clarification affects the second paragraph of the Key-based
    Correlation subsection of Section 8.3.3 (Correlation):

    At runtime the first Send Task or Receive Task in a Conversation
    populates the CorrelationKey instance by extracting the values of the
    CorrelationProperties according to the
    CorrelationPropertyRetrievalExpression from the initially sent or
    received Message. Later in the Conversation, this CorrelationKey
    instance is used for the described matching procedure where from
    incoming Messages a composite key is extracted and used to identify
    the associated Conversation.

    New keys might appear during the converstion. For example, the initial
    message from a customer placing an order might not include the order
    number. This is assigned by a new process instance and used to
    correlate messages later in the conversation.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    under Section 8.3.3, replace the text of the first bullet with this text:
    In plain, key-based correlation, Messages that are exchanged within a Conversation are logically correlated by means of one or more common CorrelationKeys. That
    is, any Message that is sent or received within this Conversation needs to carry the value of at least one of these CorrelationKey instances within its payload. A
    CorrelationKey basically defines a (composite) key. The first Message that is initially sent or received initializes one or more CorrelationKey instances associated with
    the Conversation, i.e., assigns values to its CorrelationProperty instances which are the fields (partial keys) of the Correlation-Key. A CorrelationKey is only
    considered valid for use, if the Message has resulted in all CorrelationProperty fields within the key being populated with a value. If a follow-up Message derives a
    CorrelationKey instance, where that CorrelationKey had previously been initialized within the Conversation, then the CorrelationKey value in the Message and
    Conversation MUST match. If the follow-up Message derives a CorrelationKey instance associated with the Conversation, that had not previously been initialized, then
    the CorrelationKey value will become associated with the Conversation. As a Conversation may comprise different Messages that may be differently structured, each
    CorrelationProperty comes with as many extraction rules (CorrelationPropertyRetrievalExpression) for the respective partial key as there are different Messages.
    under section 8.3.3 Correlation, the under the title "Key-based Correlation", replace the second paragraph with this text:
    At runtime the first Send Task or Receive Task in a Conversation MUST populate atleast one of the CorrelationKey instances by extracting the values of the
    CorrelationProperties according to the CorrelationPropertyRetrievalExpression from the initially sent or received Message. Later in the Conversation, the populated
    CorrelationKey instances are used for the described matching procedure where from incoming Messages a composite key is extracted and used to identify the
    associated Conversation. Where these non-initiating Messages derive values for CorrelationKeys, associated with the Conversation but not yet populated, then the
    derived value will be associated with the Conversation instance.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

isImmediate default

  • Key: BPMN2-115
  • Legacy Issue Number: 14651
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    isImmediate on SequenceFlow currently defaults to true for all private
    processes. It should default to false for non-executable processes,
    because these are not intended to be completely specified.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In Table 8.60 (SequenceFlow attributes and model associations), isImmediate row:
    (a) Second bullet: Replace "a public Processes" with "non-executable Processes (public Processes and non-executable private Processes)"
    (b) Third bullet: Replace "an executable and non-executable (internal)" with "executable".
    In Section 10.8 (Process Instances, Unmodeled Activities, and Public Processes):
    Second bullet, replace the
    (c) Two occurrences of "processType" with "isExecutable".
    (d) First occurrence of "public" with "non-executable".
    (e) Second occurrence of "public" with "false, or defaults to false".
    (f) "private" with "executable".
    (g) "executable or non-executable" with "true, or defaults to true"
    (h) In XMI/XSD, change isImmediate attribute on SequenceFlow to be optional.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Subprocess / CallActivity switch

  • Key: BPMN2-114
  • Legacy Issue Number: 14650
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Section 10.4.2 (Start Event) uses the BPMN 1.x term "subprocess" to
    include called processes. In BPMN 2 "subprocess" means embedded. See
    Table 10-78 (Sub-Process Start Event Types) and under the heading "Start
    Event Triggers". Might be in other places also.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Section 13.2.5, Sub-Section CalledSubProcessShape, Page 383 (412 pdf): Replace the first paragraph with the following: "A Call Activity is used for invoking a
    global Process. It has the same symbol as the subprocess (embedded). Expanding the Call Activity should display the called Process."
    (b) Table 13.13 - CalledSubProcessShape , first row, second column: replace contents of column with the following: "A reference to another BPMN diagram defining
    the details of the called Global Process. "
    (c) Table 13.13 - CalledSubProcessShape styles: , first row, second column: replace contents of column with the following: "Indicates whether the Call Activity is
    expanded or collapsed."
    Section 10.4.2 Start Event
    (d) First bullet below Figure 10.67 Start Event, page 214 (244 pdf): Replace "or an expanded Sub-Process" with ", a Sub-Process (embedded), or a Global Process
    (called Process)"
    (e) First paragraph after first bullet below Figure 10.67 Start Event, page 214 (244 pdf): Replace the first sentence of the paragraph with the following: "Note - A
    Process may have more than one Process level (i.e., it can include Expanded Sub-Processes or Call Activities that call other Processes)."
    (f) Page 215 (245 pdf), First paragraph after the bullets: Replace the paragraph with the following: "If the Process is used as a Global Process (callable Process that
    can be invoke from Call Activities of other Processes) and there are multiple None Start Events, then when flow is transferred from the parent Process to the Global
    Process (child Process), only one of the Global Process's Start Events will be triggered. The TargetRef attribute of the Sequence Flow incoming to the Global Process
    object can be extended to identify the appropriate Start Event."
    Sub-Section Start Event Triggers, page 215 (245 pdf)
    (g) Second bullet: delete " and called (reusable)"
    (h) Add new bullet after second bullet with the following: "Global Processes (called)
    Sub-Section Start Events for Top-level Processes: add new paragraph after the first paragraph with the following: "A top-level that has at least one (1) None Start
    Event MAY be called by a Call Activity in another Process. The None Start Event is used for invoking the Process from the Call Activity. All other types of Start
    Events are only applicable when the Process is used as a top-level Process."
    Section 10.4.3 End Event
    (j) Page 222 (252 pdf), second bullet on page: delete "top-level" from first sentence.
    (k) Page 222 (252 pdf), first paragraph after bullets: replace first sentence of the paragraph with the following: "Note - A Process may have more than one Process
    level (i.e., it can include Expanded Sub-Processes or a Call Activities that call other Processes)."
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Processes supporting interactions

  • Key: BPMN2-123
  • Legacy Issue Number: 14664
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    When a private process supports an interaction, this currently can only
    be captured by defining a public process for the private one to support,
    and including the public process in a collaboration, with further links
    to choreographies or conversations, if those were the interaction model
    being supportted. Private processes should be able to support any of
    the interaction models directly

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Private process type

  • Key: BPMN2-122
  • Legacy Issue Number: 14662
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Modelers should be able to declare a process private without committing
    to whether it is executable or non-executable. Add private as a value
    for the type attribute.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) In Figure 10.2, 10.3, and other metamodel figures where Process appears with its attributes, insert a new attribute beneath processType: "isExecutable : Boolean".
    In Table 10.1 (Process Attributes & Model Associations), processType row, change as follows:
    left column
    (b) replace "executable | non-executable" with "private".
    right column
    (c) replace the second through fourth paragraphs (from "The BPMN 1.2 processType" through "not included in a
    non-executable Process.") with "A private process is one that is internal to a specific organization."
    insert new row below processType:
    left column
    isExecutable : Boolean [0..1]
    right column
    (d) First paragraph: "An optional Boolean value specifying whether the process is executable".
    (e) Move the current third and fourth paragraphs from the processType row to this row after the first paragraph (starting from "An
    executable Process" through "included in a non-executable Process.")
    (f) Add paragraph at end:
    "For public processes, no value has the same semantics as if the value were false. The value may not be true for public processes."
    In the following tables and rows, in the right column, replace all occurrences of "processType" with "isExecutable" and and all occurrences
    of "executable" with "true".
    (g) Table 10.3 (Activity attributes and model associations), loopCharacteristics row.
    (h) Table 10.88 (ConditionalEventDefinition model associations), condition row.
    Table 10.89 (ErrorEventDefinition attributes and model associations), errorCode row.
    (j) Table 10.90 (EscalationEventDefinition attributes and model associations), escalationCode and timeCycle rows.
    (k) Table 10.92 (MessageEventDefinition model associations), messageRef.
    (l) In Section 10.8 (Process Instances, Unmodeled Activities, and Public Processes), second bullet, next to last sentence, replace "executable or non-executable" with
    "private".
    In Table 10.129 (Process XML schema):
    (m) In tProcessType element, replace enumeration values "executable" and "non-executable" with a single value "private ".
    Add element after processType for isExecutable boolean attribute, no default: <xsd:attribute name="isExecutable" type="xsd:boolean"/>
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Complex gateway merging rule in choreography too restrictive

  • Key: BPMN2-118
  • Legacy Issue Number: 14655
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The rule fo merging complex gateway in choreography is

    "In order to enforce the synchronizing merge of the Gateway, the
    senders or receivers Choreography Activities preceding the Gateway
    need to be the same Participant. This ensures that the merge can be
    enforced."

    but if the sender of the activity after the gateway participates in the
    activties before the gateway, and has access to the complex decision
    data, then it has everything needed to perform the synchronization.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The quote in the issue is from the inclusive gateway, rather than the
    complex merge.
    In the Choreography chapter, in section Gateways, subsection Inclusive
    Gateway, under the third paragraph, first bullet, second subbullet (the
    one beginning "Merge:"), in the sentence immediately after the colon
    (the one beginning "In order to enforce"), replace the portion of the
    sentence after the comma with:
    the sender of the Choreography Activity after the Gateway must
    participate in the Choreography Activities immediately preceding the
    gateway.
    In the Choreography chapter, in section Gateways, subsection Inclusive
    Gateway, in the paragraph just above the first figure, third sentence,
    replace the portion of the sentence after the comma with:
    the initiator of Choreography Activities immediately following the
    Gateway participates in the Choreography Activities immediately
    preceding the Gateway.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Conversation/Process switch

  • Key: BPMN2-121
  • Legacy Issue Number: 14660
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Section 8.3.3 (Correlation), first bullet says "dispatched to this
    particular Conversation". This should describe dispatching to a process
    instance, there are no conversation instances. Another example is in
    the CorrelationKey paragraph under Figure 8-18 (The Correlation Class
    Diagram). Might be other places in the spec refering to conversations as
    if they were executed.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 8.3.3
    > Subsection "CorrelationKey", first paragraph
    Original
    For each Message that is received within a particular Conversation, the CorrelationProperties need to provide a CorrelationPropertyRetrievalExpression which
    references a FormalExpression to the Message payload.
    Proposal
    For each Message that is exchanged as part of a particular Conversation, the CorrelationProperties need to provide a CorrelationPropertyRetrievalExpression which
    references a FormalExpression to the Message payload.
    > Subsection "Key-based Correlation", first paragraph
    Original
    Messages will be routed to the Conversation whose extracted composite key matches the respective CorrelationKey instance.
    Proposal
    Messages are associated to a particular Conversation if the composite key extracted from their payload matches the CorrelationKey initialized for this Conversation.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Key-based Correlation => ?

  • Key: BPMN2-113
  • Legacy Issue Number: 14649
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Key-based correlation could have a better name, because context-based
    correlation (subscription) also uses keys, it just enables values for
    process keys to change over time. Perhaps the term could be "static
    correlation", meaning the values of process properties do not change
    over time (though values and keys can be added). BTW, "context-based"
    for subscription is equally vague. How about static vs dynamic
    correlation?

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The terms "key-based" and "context-based" are common in the area of
    correlation, it's best to leave them as they are.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Correlation Class Diagram missing Process association

  • Key: BPMN2-120
  • Legacy Issue Number: 14659
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 8-18 (The Correlation Class Diagram) is missing the association
    between CorrelationSubscription and Process that appears in Table 8-35
    (CorrelationSubscription model associations).

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of this issue is covered by 14685 OMG-14685
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Promote correlationKeys association to ConversationContainer

  • Key: BPMN2-119
  • Legacy Issue Number: 14658
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    correlationKeys is on Conversation and Subconversation in Figure 8-18
    (The Correlation Class Diagram). Promote it to ConversationContainer

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14654 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Cardinality of the "sourceRef" association between DataAssociation and ItemAwareElement

  • Key: BPMN2-220
  • Legacy Issue Number: 14819
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    See figure 10.61. The "sourceRef" assocation.

    The cardinality on the DataAssociation end is 1. This tells me that any given DataAwareElement must be the source of exactly one DataAssociation.

    This doesn't work:

    • DataAwareElement are not required to participate in data associations.
    • Data Objects can be the source of multiple data associations.

    So the cardinality should be 0..n

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Replace Figure 10.61. See here in particular, the corrected cardinality (circled in red):
    (10583_MM_DataAssociation.jpg)
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unclear/contradictory handling of visualized Data Inputs/Outputs

  • Key: BPMN2-219
  • Legacy Issue Number: 14818
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    The spec does not provide much clarification on how the Data Inputs/Outputs notation is used.

    As an example, consider a process that is calling another process. The called process has Data Inputs and Data Outputs.

    If I create a data association from the calling process to the Call Activity, clearly the target of that data association would be a data input of the called process.
    And yet the spec states that:

    • DataInputs MUST NOT have incoming DataAssociations.
      So, there's a contradiction here. DataAssociations do and should target DataInputs.

    Or, is that statement intended to describe visualization of the DataAssociation (i.e. the DataAssociation visually stops at the CallActivity boundary and does not visually connect to the Data Input, even if it is actually connected in the semantic model)?

    If the latter, why not allow the Data Association to connect to the Data Inputs? Doing so would result in a more explicit visualization of the underlying semantics. If I had multiple Data Inputs, I would be able to tell at a glance which Data Input is being targetted by which Data Association.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    1. Pdf pg 221, section titled "Data Inputs". Replace entire second paragraph (including sub-bullets) with the following:
    [See word doc for formatted version: 10_process-data_updatedFor317.doc]
    The Data Input is an item-aware element. Data Inputs may be visualized in a Process diagram to show the inputs to the top-level Process or to show the inputs of a
    called Process (i.e. one that is referenced by a Call Activity, where the Call Activity has been expanded to show the called Process within the context of a calling
    Process).

    • Visualized DataInputs have the same notation as DataObjects, except MUST contain a small, unfilled block arrow (see Figure 10.55).
    • DataInputs MAY have incoming DataAssociations.
    • If the Data Input is directly contained by the top-level Process, it MUST NOT be the target of Data Associations within the underlying model. Only Data
      Inputs that are contained by Activities or Events may be the target of Data Associations in the model.
    • If the Process is being called from a Call Activity, the Data Associations that target the data inputs of the Call Activity in the underlying model may be
      visualized such that they connect to the corresponding data inputs of the called Process, visually crossing the Call Activity boundary. But note that this is visualization
      only. In the underlying model, the Data Associations target the data inputs of the Call Activity and not the data inputs of the called Process.
      2. Pdf pg 223, section titled "Data Outputs". Replace entire second paragraph (including sub-bullets) with the following:
      [See word doc for formatted version: 10_process-data_updatedFor317.doc]
      The DataOutput is an item-aware element. DataOutput elements may be visualized in a Process diagram to show the outputs of the top-level Process, or to show the
      outputs of a called Process (i.e. one that is referenced by a Call Activity, where the Call Activity has been expanded to show the called Process within the context of a
      calling Process)..
    • Visualized DataOutputs have the same notation as DataObjects, except MUST contain a small, filled block arrow (see Figure 10.57).
    • DataOutputs MAY have outgoing DataAssociations.
    • If the Data Output is directly contained by the top-level Process, it MUST NOT be the source of Data Associations within the underlying model. Only Data
      Outputs that are contained by Activities or Events may be the source of Data Associations in the model.
    • If the Process is being called from a Call Activity, the Data Associations that originate from the data outputs of the Call Activity in the underlying model may
      be visualized such that they connect from the corresponding data outputs of the called Process, visually crossing the Call Activity boundary. But note that this is
      visualization only. In the underlying model, the Data Associations originate from the data outputs of the Call Activity and not the data outputs of the called Process
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Data Inputs/Outputs on Subprocesses

  • Key: BPMN2-218
  • Legacy Issue Number: 14817
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    The spec isn't clear on the relationship between visual Data Inputs/Outputs and embedded subprocesses.

    Pg 191 states that "DataInput elements may appear in a Process diagram to show the inputs the Process as a whole ...". There's a similar statement on pg. 193 for Data Outputs.

    The phrase "the Process as a whole" almost reads like visualized Data Inputs/Outputs are only applicable to Processes (and not to embedded subprocesses).

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Modify/include the following text to chapter 10.3 - "Data Input and Output", directly before Figure 10.8:
    Not every Activity type defines inputs and outputs, only Tasks, CallableElements (Global Tasks and Processes) MAY define their data requirements. Embedded
    MUST NOT define Data Inputs and Data Outputs directly, however they MAY define them indirectly via Multi Instance Loop Characteristics.
    Modify/include the following text to chapter 10.2.8 - "Multi-Instance Characteristics":
    Table 10.3 - MultiInstanceLoopCharacteristics attributes and model associations
    loopDataInputRef: ItemAwareElement [0..1]
    This ItemAwareElement is used to determine the number of Activity instances, one Activity instance per item in the collection of data stored in that ItemAwareElement
    element.
    For Tasks it is a reference to a DataInput which is part of the Activity's InputOutputSpecification.
    For Sub Processes it is a reference to a collection-valued DataObject in the context that is visible to the Sub Process.
    In order to initialize a valid multi-instance, either the loopCardinality Expression or the loopDataInput MUST be specified.
    loopDataOutputRef: ItemAwareElement [0..1]
    This ItemAwareElement specifies the collection of data, which will be produced by the multi-instance.
    For Tasks it is a reference to a DataOutput which is part of the Activity's InputOutputSpecification.
    For Sub Processes it is a reference to a collection-valued DataObject in the context that is visible to the Sub Process.
    inputDataItem: DataInput [0..1]
    A DataInput, representing for every Activity instance the single item of the collection stored in the loopDataInput. This DataInput can be the source of
    DataInputAssociation to a data input of the Activity's InputOutputSpecification. The type of this DataInput MUST the scalar of the type defined for the loopDataInput.
    outputDataItem: DataOutput [0..1]
    A DataOutput, representing for every Activity instance the single item of the collection stored in the loopDataOutput. This DataOutput can be the target of
    DataOutputAssociation to a data output of the Activity's InputOutputSpecification. The type of this DataOutput MUST the scalar of the type defined for the
    loopDataOutput.
    Table 10.37 - MultiInstanceLoopCharacteristics XML schema
    (change loopDataInput to loopDataInputRef with new type QName; change loopDataOutput to loopDataOutputRef with new type QName; change of inputDataItem
    to type tDataInput; change of outputDataItem to type tDataOutput)
    <xsd:complexType name="tMultiInstanceLoopCharacteristics">
    <xsd:complexContent>
    <xsd:extension base="tLoopCharacteristics">
    <xsd:sequence>
    <xsd:element name="loopCardinality" type="tExpression" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="loopDataInputRef" type="xsd:QName" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="loopDataOutputRef" type="xsd:QName" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="inputDataItem" type="tDataInput" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="outputDataItem" type="tDataOutput" minOccurs="0" maxOccurs="1"/>
    <xsd:element ref="complexBehaviorDefinition" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element name="completionCondition" type="tExpression" minOccurs="0" maxOccurs="1"/>
    </xsd:sequence>
    <xsd:attribute name="isSequential" type="xsd:boolean" default="false"/>
    <xsd:attribute name="behavior" type="tMultiInstanceFlowCondition" default="all"/>
    <xsd:attribute name="oneBehaviorEventRef" type="xsd:QName" use="optional"/>
    <xsd:attribute name="noneBehaviorEventRef" type="xsd:QName" use="optional"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>
    Note: The attached diff from Tammo is not complete, so better use the schema above.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Can a sub-process (embedded) have Lanes?

  • Key: BPMN2-213
  • Legacy Issue Number: 14803
  • Status: closed  
  • Source: Oracle ( Meera Srinivasan)
  • Summary:

    ##Source: Oracle (Meera Srinivasan, meera.srinivasan@oracle.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-59
    ##Original Info: (Severity: Significant - Nature: Enhancement)

    Section 10.2.5, Page 152 (page 182 in PDF)

    Can a sub-process (embedded) have Lanes? My understanding is no. Can the specification clarify this clearly?

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Move the laneSets attribute from Process to FlowElementContainer:
    (a) Table 10.1, page 124 (154 pdf): remove 4th row from table (laneSets)
    (b) Table 8.46, page 78 (108 pdf): add the following row to the table:
    laneSets: LaneSet [0..*] || This attribute defines the list of LaneSets used in the Flow Element Container (e.g., Process, Sub-Process). LaneSets are not used for
    Choreographies or Sub-Choreographies."
    (c) Section 9.2.1, page 117 (147 pdf): replace the first sentence in section with the following: "A Lane is a sub-partition within a Process (often within a Pool) or Sub-
    Process and will extend the entire length of the Process level, either vertically or horizontally."
    (d) Section 10.7, page 282 (312 pdf): replace the first sentence in section with the following: "A Lane is a sub-partition within a Process (often within a Pool) or Sub-
    Process and will extend the entire length of the Process level, either vertically (see figure XX) or horizontally (see figure XX)."
    (e) Section 10.7, page 282 (312 pdf): remove second sentence in section.
    (f) Figure 10.122, page 285 (315 pdf): replace figure to show the change in the laneSet attribute
    (g) Table 10.43, page 181 (211 pdf): add the "laneSet" element to the Sub-Process schema snippet. Also add this element to the BPMN XSD.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.2.3 ScriptTask.scriptLanguage needs to specify format

  • Key: BPMN2-212
  • Legacy Issue Number: 14801
  • Status: closed  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: The scriptLanguage is currently specified to be a String, this risks clashes across different implementations. It should either be required to be an URI, or an example should suggest this to be an URI.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    1. expressionLanguage, typeLanguage
    a. Spec tables 8.1 (Definitions), 8.44 (FormalExpression)
    Add the following to the descriptions for the expressionLanguage and typeLanguage attributes: "The language must be specified in a URI format."
    There are no changes to the XSD or UML metamodel.
    2. scriptLanguage
    a. Change the name of the attribute to "scriptFormat". Applies to the XSD, UML metamodel, and spec (table 10.10).
    b. The type of the attribute will consistently be "string". Impacts the XSD only. The UML metamodel and spec currently use "string".
    c. Replace the description of the attribute in table 10.10 with: Defines the format of the script. This attribute value must be specified with a mime-type format. And it
    must be specified if a script is provided.
    d. Replace figure 10.10
    e. Update the XSD snippet in table 10.35
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 12.4.1 [Choreo] How many message flows per choreography task? Missing meta-model

  • Key: BPMN2-215
  • Legacy Issue Number: 14805
  • Status: closed  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: The text reads "A choreography task ... represents a coherent set of Message exchanges." Neither "coherent" nor "set" is further detailed, nor is a schema shown that clarifies the relationship between Choreography Task and Message Flow.

    Proposal: Provide further explanation of "coherent set", and provide meta-model for Choreography Task.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14890 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 8.3.15 [Choreo] ParticipantMultiplicity must allow to specify 1..2, possibly also 0..1

  • Key: BPMN2-214
  • Legacy Issue Number: 14804
  • Status: closed  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: The attributes minimum and maximum are mandated to have a min value of 2. Why would multiplicities such as 1..2 be excluded? Couldn't there even be optional participants?

    Proposal: At the very least, the minimum attribute should allowed to have a minimum of 1. Possibly, minimum should be allowed to start at 0, and maximum at 1.

    Comments:
    From: wstephe created: Fri, 11 Sep 2009 13:19:42 -0500 (CDT)
    The section, table, and page numbers were updated to match the Beta 1 Spec.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    8.3.15 Participants
    p94
    "When the minimum attribute of the ParticipantMultiplicty element has been set by the modeler, then the multiinstance
    marker will be displayed in bottom center of the Pool (Participant - see Figure 8-41) or the Participant Band
    of a Choreography Activity (see page 356)."
    change to:
    "The multi-instance marker will be displayed in bottom center of the Pool (Participant - see Figure 8-41), or the Participant Band of a Choreography Activity (see page
    356), when the ParticipantMultiplicity is associated with the Participant, and the maximum attribute is either not set, or has a value of two (2) or more."
    Table 8.56 ParticipantMultiplicity attributes
    Change from "minimum: integer [0..1] = 2" to "minimum: integer = 0" - mandatory with default value of 0
    with suitable update to schema.
    "The minimum attribute defines minimum number of Participants that
    MUST be involved in the Collaboration. The value of minimum MUST be
    two (2) or greater."
    change to:
    "The minimum attribute defines minimum number of Participants that
    MUST be involved in the Collaboration. If a value is specified in the
    maximum attribute, it MUST be greater or equal to this minimum value."
    Change from "maximum: integer [0..1] = 2" to "maximum: integer [0..1] = 1" - optional with default value of 1.
    "The maximum attribute defines maximum number of Participants that
    MAY be involved in the Collaboration. The value of maximum MUST be
    two (2) or greater."
    change to:
    "The maximum attribute defines maximum number of Participants that
    MAY be involved in the Collaboration. The value of maximum MUST be
    one (1) or greater, AND must be equal or greater than the minimum value."
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.5.1/10.5.6 Need to clarify how initiating gateway is specifed: via sequence flow, attribute, or both

  • Key: BPMN2-211
  • Legacy Issue Number: 14799
  • Status: closed  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: Section 8.4.1 states that a gateway's behavior is performed at instantiation time of the process if there is a gateway with no incoming sequence flow (top of p. 126). However, section 8.4.6 introduces an "instantiate" flag for Event-base Gateways, which seems to have the exact same purpose (table 8-85 on p. 128). These two ways of tying process instantiation and gateway execution together need to be reconciled.

    Proposal: Preferably, get rid of the instantiate flag and allow the behavior described in 8.4.1 for all gateways, including the event-based gateway. Alternatively, introduce an instantiate flag for all gateways (or for those where it makes sense), and describe the relationship between no incoming sequence flow and the flag.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 10.2.3, Sub-Section Receive Tasks, page 139 (169 pdf):
    (a) delete the three bullets on page.
    (b) Third paragraph: replace the second sentence of the paragraph with the following: "In order for the Task to instantiate the Process its instantiate attribute must be set
    to true and it must not have any incoming Sequence Flow."
    (c) Last paragraph on page: add the following to the paragraph: "If the instantiate attribute is set to true, the envelope marker looks like a Message Start Event (as
    shown in Figure 10.X)."
    (d) Add new figure after Figure 10.15 that shows the instantiate version of the Receive Task (see
    (10698_New+Icon+for+Instantiating+Receive+Task.jpg)
    ), which is a Task with a marker that looks like a small Message Start Event.
    (e) The new Figure will have the following caption: "A Receive Task Object that instantiates a Process"
    (f) Table 10.10, second row, second column: delete "after the Start Event or a starting Task if there is no Start Event"
    Section 10.5.6:
    (g) Delete the first three bullets after Figure 10.114
    (h) First paragraph after Figure 10.114: replace "meet one of the following conditions:' with "not have any incoming Sequence Flow."
    Section 14.1, Second paragraph, First sentence:
    Replace "Event-Based Gateway" with "Event-Based Gateway or a Receive Task"
    (j) Replace "Instantiate flag is true" with "instantiate flag set to true"
    (k) Section 14.2.3, Bullet for Receive Task: Add the following to the bullet: "If the Receive Task's instantiate attribute is set to true, the Receive Task itself can start a
    new Process instance."
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Formalizing the Source-Target relationships between Link Intermediate Event

  • Key: BPMN2-217
  • Legacy Issue Number: 14816
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Currently, there is no formalized way to relate Throw Link Events with their corresponding Catch Link Event(s). The spec briefly mentions that their names must be the same, but names are unreliable.

    • There is no constraint on names, so I could create multiple Catch Link Events with the same name, thus breaking the model.
    • Names are not used, in general throughout the spec, for formalizing relationships. Instead IDs are.
    • Users do sometimes assign different names to the Throw and Catch (for example "A" for the throw and "from A" for the catch).

    Recommendation: Add an explicit assocation from the Throw Link Event to the Catch Link Event

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Add a new bidirectional association to the LinkEventDefinition.
    (Updated+Link+Event+Metamodel.jpg)
    If the LinkEventDefinition represents a 'throw' or 'source' link event, it will reference 1 LinkEventDefinitions representing the corresponding 'catch' or 'target' link event.
    If the LinkEventDefinition represents a 'catch' or 'target' link event, it will reference 1 or more LinkEventDefinitions representing the corresponding 'throw' or 'source'
    link events.
    Spec updates:
    (a) - Update Figure 10.70 to add new bidirectional association to the LinkEventDefinition class:
    (Updated+Link+Event+Metamodel.jpg)

    • Add two new associations to Table 10.91:
      (b) sources: Used to reference the corresponding 'catch' or 'target' LinkEventDefinitions, when this LinkEventDefinition represents a 'throw' or 'source'
      LinkEventDefinition.
      (c) target: Used to reference the corresponding 'throw' or 'source' LinkEventDefinition, when this LinkEventDefinition represents a 'catch' or 'target'
      LinkEventDefinition.
      Corresponding additions will be made to the BPMN XSD.
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Allow Choreographies within a Conversation Diagram

  • Key: BPMN2-216
  • Legacy Issue Number: 14809
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Currently, Choreographies are not allowed between the Pools of a Conversation diagram. However, this capability would be very useful for some modeling problems, such as the linking of BPMN diagrams to SoaML

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14654 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

General [Metamodel] Double-check attributes that are enumerated types, and their extensibility needs

  • Key: BPMN2-210
  • Legacy Issue Number: 14798
  • Status: closed  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: The meta-model contains attributes that are conceptually enumerated types. Sometimes their set of values needs to be extensible, sometimes their set of values is closed within the scope of the spec. The spec needs a consistent approach for both types of enums.

    Proposal: Presumably, enums with a closed list should be defined as enums in the metamodel, while enums that are extensible should be defined as string. Better ways to render this may exist. The outcome of the decision must be applied consistently throughout the spec

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The FTF has reviewed the list of attributes through the resolution of multiple issues. No further work is required on this topic.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 9.2: Pool description needs revisiting

  • Key: BPMN2-209
  • Legacy Issue Number: 14797
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Description of issue: Page 114 (144 in PDF) states that a "Pool acts as the container for a Process". This is not true. Pools simply reference Processes.

    Proposal: Rewording to something like: A Pool may have internal details, in the form of the Process that will be executed. Or a Pool may have no internal details, i.e., it can be a "black box".

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    1) in Page 22 Table 7.1 BPMN Modeling Elements
    Original Text
    A Pool is the graphical representation of a Participant in a Collaboration (see page 146). It is also acts as a "swimlane" and a graphical container for partitioning a set of
    Activities from other Pools, usually in the context of B2B situations.
    Append the following to the original text
    A Pool may have internal details, in the form of the Process that will be executed. Or a Pool may have no internal details, i.e., it can be a "black box".
    (2) in Page 144 Section 9.2 - Pool and Participant
    Replace the following text:
    Graphically, a Pool is a container for partitioning a Process from other Pools
    with this:
    A Pool may or may not reference a Process.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Data Inputs the target of multiple Data Associations

  • Key: BPMN2-221
  • Legacy Issue Number: 14820
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Can a single Data Input be the target of multiple Data Associations? The spec does not explicitly disallow this.

    What would be the outcome of executing this model - would the last data association defined always overwrite the results of executing prior ones?

    Is there a use-case or scenario where this produces meaning results, or should this pattern be disallowed?

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Add the following paragraph after the last paragraph in Section 10.3.2 Execution Semantics for Data
    Once an InputSet becomes "available", all DataAssociations whose target is any of the DataInputs of the InputSet are executed. These executions fill the Activity
    DataInputs and the execution of the Activity can begin.
    When an Activity finishes execution, all DataAssociations whose sources are any of the DataOutputs of the OutputSet are executed. These executions copy the values
    from the DataOutputs back to the container's context (DataObjects, Properties, etc).
    Execution Semantics for DataAssociation
    The execution of any DataAssociation must follow these semantics:
    a) If the DataAssociation specifies a "transformation" Expression, this expression is evaluated and the result is copied to the targetRef. This operation replaces
    completely the previous value of the targetRef element.
    b) For each "assignment" element specified:
    ) Evaluate the Assignment's "from" expression and obtain the *source value
    ) Evaluate the Assignment's "to" expression and obtain the *target element. The target element can be any element in the context or a sub-element of it (e.g. a
    DataObject or a sub-element of it).
    ) Copy the *source value to the target element.
    c) If no "transformation" Expression nor any "assignment" elements are defined in the DataAssociation:
    *) copy the DataAssociation "sourceRef" value into the "targetRef". Only one sourceRef element is allowed in this case.

    Add the following sentence in Section 14.2.2 Activity, at the end of the bullet that starts with "When some data InputSet becomes available,"
    Please refer to section 10.3.2 for a description of the execution semantics for DataAssociations.
    "
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Default execution semantics for an activity with multiple incoming branches needs to be clarified

  • Key: BPMN2-208
  • Legacy Issue Number: 14795
  • Status: closed  
  • Source: Oracle ( Vishal Saxena)
  • Summary:

    The current execution semantics apparently implies that the said activity with two incoming connections will be executed twice. Instead it should be a merge semantics that is the activity is executed once when token arrives on both branches.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The proposal in the issue description is in conflict with start events on the boundary of a sub-process as explained above and also conflicts compatibility with BPMN
    1.1. Thus, we propose to close with no change.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Are Conditional Start Events executable?

  • Key: BPMN2-133
  • Legacy Issue Number: 14680
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Are ConditionalStartEvents executable? What data are they able to access?

    Note that the spec states that executable ConditionalStartEvents must have a FormalExpression. So the spec implies they are executable. But it doesn't provide guidance on what data context would be provided for that FormalExpression.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 10.4.2 Start Event
    Table 10.3 - Top-Level Process Start Event Types
    Change row: Conditional
    Original (Description column)
    This type of event is triggered when a Condition such as "S&P 500 changes by more than 10% since opening", or "Temperature above 300C" become true. The
    Condition Expression for the Event must become false and then true before the Event can be triggered again.
    If there is only one (1) EventDefinition associated with the Start Event and that EventDefinition is of the subclass ConditionalEventDefinition, then the Event is a
    Conditional Start Event and MUST be displayed with a lined paper marker (see the figure to the right).
    Proposal (Description column)
    This type of event is triggered when a Condition such as "S&P 500 changes by more than 10% since opening", or "Temperature above 300C" become true. The
    Condition Expression for the Event must become false and then true before the Event can be triggered again.
    The Condition Expression of a Conditional Start Event MUST NOT refer to the data context or instance attribute of the process (as the Process instance has not yet
    been created). Instead, it may refer to static process attributes and states of entities in the environment. The specification of mechanisms to access such states is out of
    scope of the standard.
    If there is only one (1) EventDefinition associated with the Start Event and that EventDefinition is of the subclass ConditionalEventDefinition, then the Event is a
    Conditional Start Event and MUST be displayed with a lined paper marker (see the figure to the right).
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Contradiction in constraint for Start Events in Event Subprocess

  • Key: BPMN2-132
  • Legacy Issue Number: 14679
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Apparent contradiction, assuming I'm reading the constraint right.

    The spec states that "An Event Sub-Process MUST have a single Start Event". I interpret this to mean exactly one.
    And yet the spec allows a Start Event with a Multiple or Parallel Multiple event definition. These are short-hand for multiple Start Events, each with a single event definition. Hence a contradiction in functionality and intent.

    Recommend updating the spec constraint to state "An Event Sub-Process MUST have at least one Start Event".

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This is not a problem with the specification, so we close with no change
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Error vs ErrorCode & Escalation vs EscalationCode

  • Key: BPMN2-129
  • Legacy Issue Number: 14676
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    The ErrorEventDefinition contains an errorCode and references an Error class. Wouldn't it make sense for errorCode to be moved into the Error class. I'd expect that all usages of that Error class would specify the same errorCode.

    Same pattern is there for Escalation.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Insert new subsection, under 8.3, for Escalation.
    An Escalation identifies a business situation that a process may need to react to.
    Insert Figure
    (Escalation_MM.jpg)
    The Escalation element inherits the attributes and model associations of Base Element through its relationship to RootElement.
    New table, with attributes
    name: The descriptive name of the escalation
    structureRef: An ItemDefinition that defines the payload of the escalation
    (b) Move the "errorCode" attribute from Table 10.89 to Table 8.43
    (c) Move the "escalationCode" attribute from Table 10.90 to new table for Escalation
    (d) Replace Figure 8.20 with
    (Error_MM.jpg)
    (e) Replace Figure 10.70 with
    (EventDefinitions_MM.jpg)
    (f) Replace Figure 10.75 with
    (ErrorEventDefinition_MM.jpg)
    (g) Replace Figure 10.77 with
    (EscalationEventDefinition_MM.jpg)
    (h) Table 8.64 (schema snippet): Updated XSD snippet to add the errorCode attribute to tError
    <xsd:element name="error" type="tError" substitutionGroup="rootElement"/>
    <xsd:complexType name="tError">
    <xsd:complexContent>
    <xsd:extension base="tRootElement">
    <xsd:attribute name="name" type="xsd:string"/>
    <xsd:attribute name="structureRef" type="xsd:QName"/>
    <xsd:attribute name="errorCode" type="xsd:string"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>
    New table under 8.3.18, for the Escalation schema snippet
    <xsd:element name="escalation" type="tEscalation" substitutionGroup="rootElement"/>
    <xsd:complexType name="tEscalation">
    <xsd:complexContent>
    <xsd:extension base="tRootElement">
    <xsd:attribute name="name" type="xsd:string"/>
    <xsd:attribute name="structureRef" type="xsd:QName"/>
    <xsd:attribute name="escalationCode" type="xsd:string"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>
    (j) Table 10.101: Updated XSD snippet to remove the errorCode attribute from tErrorEventDefinition
    <xsd:element name="errorEventDefinition" type="tErrorEventDefinition" substitutionGroup="eventDefinition"/>
    <xsd:complexType name="tErrorEventDefinition">
    <xsd:complexContent>
    <xsd:extension base="tEventDefinition">
    <xsd:attribute name="errorRef" type="xsd:QName"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>
    (k) New table under 10.4.8, for the EscalationEventDefinition schema snippet
    <xsd:element name="escalationEventDefinition" type="tEscalationEventDefinition" substitutionGroup="eventDefinition"/>
    <xsd:complexType name="tEscalationEventDefinition">
    <xsd:complexContent>
    <xsd:extension base="tEventDefinition">
    <xsd:attribute name="escalationRef" type="xsd:QName"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Choreography Complex Gateway example

  • Key: BPMN2-125
  • Legacy Issue Number: 14670
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Section 12.6.5 (Complex Gateway) has a figure that doesn't match the
    text example

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Exchange Figure 12.48 with the diagram depicted here:
    (Compex+Gateway+in+Choreography+%28Choreography%29+Proposal+2010-04-20.png)
    (b) Exchange Figure 12.49 with the diagram depicted here:
    (Compex+Gateway+in+Choreography+%28Collaboration%29+Proposal+2010-04-20.png)
    (c) Section 12.7.5: Exchange the second paragraph:
    "Consider an e-tender which sends a request for quote to service providers (e.g., warehouse storage) in a marketplace. The e-tender Process sends out each request
    and anticipates a response through two Choreography Activities with a sequential flow between these. The request-response branches merge at a Complex Gateway to
    model the requirement that when 60% responses have arrived, an assessment of the tender can proceed. The assessment occurs after the Complex Gateway. If the
    assessment reports that the reserve amount indicated by the customer cannot be met, a new iteration of the tender is made. All up a maximum of 3 tenders is run. A key
    issue is to ensure that the responses should not be mixed across tender iterations."
    with the following text:
    "Consider an e-tender which sends a request for quote to multiple service providers (e.g., warehouse storage) in a marketplace. The e-tender Process sends out
    requests to each service provider and anticipates their response through three Choreography Activities. The response branches merge at a Complex Gateway to model
    the requirement that when 66% responses have arrived, an assessment of the tender can proceed. The assessment occurs after the Complex Gateway. If the
    assessment reports that the reserve amount indicated by the customer cannot be met, a new iteration of the tender is made. A key issue is to ensure that the responses
    should not be mixed across tender iterations. A Terminate End Event ensures that all activities are terminated, when a tender has been successful."
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exclusive gateways in choreography cover splitting but not merging

  • Key: BPMN2-124
  • Legacy Issue Number: 14665
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The section on exclusive gateways in choreography covers splitting but not merging gateways

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of this issue is covered by 14656 OMG-14656
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Fix difference between MessageFlowNode definition in specification vs the semantic.xmi file

  • Key: BPMN2-128
  • Legacy Issue Number: 14675
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    From Mohamed Keshk (via email):

    In "Semantic.xmi" file, the only sub-classes of "MessageFlowNode" are: Task, Event, and Participant.

    While in pdf specs, page 122, first section entitled with "MessageFlowNode", first paragraph, the following is written:
    "Only the Pool/Participant, Activity, and Event elements can connect to Message Flow and thus, these elements are the only ones that are sub-classes of MessageFlowNode".

    Am I missing something here, or some changes should be made?

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The elements listed in the schema are correct. If a Task or Event is contained within a Sub-Process that is collapsed, then the tool will be able to derived that the
    connection should be redirected to the boundary of the Sub-Process.
    Am I missing something here, or some changes should be made?
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Meaning of + symbol on Communication undefined

  • Key: BPMN2-127
  • Legacy Issue Number: 14672
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Sections 11.4 and 11.5 don't defined the meaning of + symbol on
    Communication. I thought it meant the expansion included at least one
    communication. If this is the definition, then Figure 11-3 has a nested
    communication symbol for Delivery Negotiations, but Figure 11-4 expands
    it without a communication.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The definition given by the filer appears under Figure 11.4, but it is incorrect. The plus sign only indicates the presence of a SubConversation, or CallConversation to a
    Collaboraton, as described in those sections.
    In the paragraph under Figure 11.4 (Conversational view choreographies), next to last sentence, starting with "to alert", replace the rest of the sentence with ", indicating
    a Sub-Conversation or a CallConversation calling a Collaboration."
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Mention of "isInterrupting" attribute still in the spec

  • Key: BPMN2-131
  • Legacy Issue Number: 14678
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Spec v0.9.14.

    Section 14.4.4 (Execution Semantics) mentions the "isInterrupting" attribute. This attribute was renamed to "cancelActivity".

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue was based on an earlier draft of the specification and is no longer valid. Thus, we will close.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect description for the Transaction.protocol attribute

  • Key: BPMN2-130
  • Legacy Issue Number: 14677
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Spec v0.9.14. Table 10-21 contains an incorrect description for the Transaction.protocol attribute.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue is a duplicate of issue OMG 14750 (14750)
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 11 Conversation: Fix Conversation figures for proper notation for Pools

  • Key: BPMN2-135
  • Legacy Issue Number: 14682
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The figures of the Conversation show the Pools without the proper notation (as defined in <a href="http://www.osoa.org/jira/browse/BPMN-305" title="V0.5.6: Section 9 Collaboration [Choreography; Specification, Metamodel]: Pool and lane. Provide distinct shapes since their semantics are so different">BPMN-305</a>). These should be fixed. There are also two figures in the Collaboration chapter that also need fixing.

    Comments:
    From: wstephe created: Sun, 13 Sep 2009 23:14:29 -0500 (CDT)
    Version number removed from summary so that it will apply to the Beta 1 spec

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close this issue as a duplicate of 14250.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Merge Conversation and Collaboration

  • Key: BPMN2-136
  • Legacy Issue Number: 14684
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Conversation and Collaboration currently differ because Conversation
    messages can grouped, and Conversation can be reused. Since these
    capabilities are useful on collaboration, it would be simpler for users
    and implementers to merge these diagrams. Then there would be two
    interactions diagrams, one highlighting communication between
    participants (collaboration/conversation) and one highlighting the
    sequence of message flow (Choreography). This would be easier to
    explain and reduce the terminology complexity of the "three C models".

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close this issue as a duplicate.
    The resolution of issue 14641 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Correlation Key & Correlation Properties are missing 'name' attributes

  • Key: BPMN2-134
  • Legacy Issue Number: 14681
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    I'd think that CorrelationKey at a minimum needs a name.
    I'm not too sure that CorrelationProperty does, but give it is a RootElement, a name might be prudent.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Duplicate. This issue will be resolved through the disposition of Issue 14721 (JIRA 14721).
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

isClosed on Conversation

  • Key: BPMN2-126
  • Legacy Issue Number: 14671
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    isClosed is on Collabration and Choreography, but not Conversation. It
    should be promoted to Interaction

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14654 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Property name mismatch between Spec and Schema for Item Definition

  • Key: BPMN2-230
  • Legacy Issue Number: 14859
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The MM and spec shows ItemDefinition with a property named "structure." The schema names this property "structureRef." These two should be synchronized. Mostly likely, the spec and MM should be changed.

  • Reported: BPMN 2.0b1 — Fri, 11 Dec 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Update the UML metamodel, renaming ItemDefinition.structure to structureRef
    Replace Figures 8.20, 8.22, 8.27, 8.34, 10.47, 10.48, 10.52, 10.53, 10.56, 10.58, 10.61, 10.70, 10.75, 10.77, 10.84, 10.89
    (b) Update Table 8.49 (pg 113)
    Rename structure to structureRef
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

"isInterrupting" attribute of Start Events

  • Key: BPMN2-229
  • Legacy Issue Number: 14858
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The "isInterrupting" attribute is introduced in the start events to deal with the possible non interrupting nature of start events in the context of Event Sub-processes. It is to be ignored for other Start Events.

    A few issues:
    In Table 10-112 on page 294. The schema snippet is missing the "isInterrupting" attribute.

    In Table 10-80 on page 251 the isInterrupting attribute has no default value whereas the semantic.xsd file does set it by default to "false"

    Should we remove the default value from the schema or should we set the "isInterrupting" attribute to "true" by default so that if that attribute is pushed in the context of a normal start event the proper depiction will be rendered. (Eventhough it should have been ignored..)

  • Reported: BPMN 2.0b1 — Fri, 11 Dec 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Table 10.80, first row, first column: add " = true"
    (b) Table 10.122, replace "<xsd:extension base="tCatchEvent"/>" with the following:
    "<xsd:extension base="tCatchEvent">
    <xsd:attribute name="isInterrupting" type="xsd:boolean" default="true"/>
    </xsd:extension>"
    (c) change the default of the isInterrupting attribute to true in the schema and metamodel
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Event marker quality is poor

  • Key: BPMN2-224
  • Legacy Issue Number: 14826
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    The markers that appear in the Beta spec are of really poor quality (they look almost hand-drawn). They have a negative impact on the overall quality of the spec.
    See table 10.86 for examples, but really is prevalent in a lot of the markers throughout the document.

    Note that the same markers in prior versions (e.g. the v0.9.14) were of much greater quality. Somehow the marker quality degraded, probably an accidental side-effect of some sort of document conversion

  • Reported: BPMN 2.0b1 — Tue, 1 Dec 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    ALL images were updated with replacements of adequate resolution, we are not including specific diagrams because most of the were updated based on the
    resolutions of other issues.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Persistent versus transient event trigger

  • Key: BPMN2-223
  • Legacy Issue Number: 14823
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Define for intermediate messages (intermediate event trigger) if the message should be persisted in the process scope when the intermediate message is not yet active.

    (See also workflow patterns from van der Aalst; e.g. http://www.workflowpatterns.com/evaluations/standard/index.php and
    http://www.workflowpatterns.com/patterns/control/new/wcp24.php
    ).

    It relates to e.g. the following on page 226 in the BPMN 2.0 Beta 1 specification:

    “If the Event is used to “catch” the Event Trigger, then the token will remain at the Event until the Trigger occurs (e.g., the Message is received).”

    Differentiation is required between whether one wants to persist (or "defer") the trigger, or whether one wants to "lose" the trigger when the process is not yet in state to react.

  • Reported: BPMN 2.0b1 — Wed, 25 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue cannot be fixed in this FTF.
    Disposition: Closed, Out Of Scope

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reference ProcessRef missing in Figure 8.40 - The Participant Class Diagram

  • Key: BPMN2-232
  • Legacy Issue Number: 14863
  • Status: closed  
  • Source: SAP SE ( Rouven Day)
  • Summary:

    In the class diagram for Participant (Figure 8.40 - The Participant Class Diagram) the reference to a Process is missing.
    In the list of attributes it is available but not in the diagram.
    Since this is a very prominent reference, it should also be visible in the class diagram.

  • Reported: BPMN 2.0b1 — Tue, 15 Dec 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Beta 1, August 2009 (pdf version)
    Make the following change in the specification: Update figure "The Participant Class Diagram" (figure 8.40 in Beta 1, draft 1) to include class "Process" and association
    (s) between the Participant and Process classes.
    This is important as table "Participant attributes and model associations" (table 8.53, in Beta 1, draft 1) defines attribute processRef, but it is not shown in figure 8.40.
    No MM and XSD updates are necessary.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

The Message element structureRef association should be renamed to itemRef

  • Key: BPMN2-231
  • Legacy Issue Number: 14860
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The Message element has an association named "structureRef," which points to the ItemDefinition element. It should be renamed "itemRef."

  • Reported: BPMN 2.0b1 — Sat, 12 Dec 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Replace Figure 8.34 (pg 116)
    Update the UML metamodel, renaming Message.structureRef to itemRef
    (b) Update Table 8.50 (pg 116)
    Rename structureRef to itemRef
    (c) Update Table 8.71 (pg 134) - XSD snippet
    Rename structureRef to itemRef
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Execution semantics for Data Objects and Properties must be enhanced to properly describe concurrent modification situat

  • Key: BPMN2-234
  • Legacy Issue Number: 14877
  • Status: closed  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    Does it make sense to describe the runtime behaviour of updating DataObjects and/or Properties by different executions?

    Should we leave this up to interpretations by implementers? Should we describe the expected behaviour or multiple executions updating the same DataObject/Property. This is specially important for multi-instance activities

  • Reported: BPMN 2.0b1 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This is considered to be an enhancement.
    Disposition: Closed, Out Of Scope

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Does CallChoreography need a MessageFlowAssociation?

  • Key: BPMN2-233
  • Legacy Issue Number: 14869
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Choreographies contain Message Flow. The CallChoreographyActivity will call another Choreography or a GlobalChoreographyTask, both of which have there own Message Flow. There are similar relationships to Participant. A CallChoreographyActivity has a ParticipantAssociation, so it should also have a MessageFlowAssociation or should not have the ParticipantAssociation.

  • Reported: BPMN 2.0b1 — Wed, 16 Dec 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The Message Flow within the called Choreography will not be used or interact within the calling Choreography, so no mapping is required. Thus, there is no change
    required to the specification.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Called conversations without keys of the caller

  • Key: BPMN2-226
  • Legacy Issue Number: 14833
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Called conversations might have messages that don't have the correlation keys of the caller. Clarify whether this is allowed or not.

  • Reported: BPMN 2.0b1 — Thu, 3 Dec 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Called collaborations can have messages that don't have the correlation
    keys of the caller. The internal structure of messages is not specified
    in BPMN, but correlation keys applying to message flow establish
    property requirements on the contents of the message. The correlation
    keys applying to a message flow are all the keys of the containers of
    the message flow, including containers transitively through calls of
    collaborations or choreographies.
    Above Figure 8.18 (The Correlation Class Diagram) insert a new
    paragraph:
    Correlation can be applied to message flows in Collaboration and
    Choreography, as described in Chapters XXXCollaboration and
    XXXChoreography. The keys applying to a message flow are the keys of
    containers or groupings of the message flow, such as Collaborations,
    Choreographies, and Conversation Nodes, and Choreography Activities.
    This might result in multiple correlation keys applying to the same
    message flow, perhaps due to multiple layers of containment. In
    particular, calls of Collaborations and Choreographies are special
    kinds of Conversation Nodes and Choreography Activities, respectively,
    and are considered a kind of containment for the purposes of
    correlation. The correlation keys specified in the caller apply to
    message flow in a called collaboration or choreography.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Allow Overlapping Matrix Construction of Lanes in a Diagram

  • Key: BPMN2-228
  • Legacy Issue Number: 14848
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The spec has always described the ability to create matrix types of Lanes in diagrams. The current DI MM does not allow this.

  • Reported: BPMN 2.0b1 — Wed, 9 Dec 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue is outdated given the rewrite of Chapter 13 (Diagram Interchange) under issue 14423
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Order of outgoing sequence flows from exclusive gateway

  • Key: BPMN2-227
  • Legacy Issue Number: 14834
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Metamodel does not capture order of outgoing message flows from exclusive gateway, which is needed to evaluate the conditions in order,
    per Table 14.2.

  • Reported: BPMN 2.0b1 — Thu, 3 Dec 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close this issue as a duplicate.
    The resolution of issue 14753 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

The description of operationRef is not accurate

  • Key: BPMN2-222
  • Legacy Issue Number: 14822
  • Status: closed  
  • Source: IBM ( Yu)
  • Summary:

    in this page, for Send Task, in Table 10.9 ­ Send Task model associations. the description of operationRef is:

    This attribute specifies the operation that is invoked by the Service Task.

    But this description is not accurate because Send task is not a Service Task. the better description may be:

    This attribute specifies the operation that the Send Task will inovke to.

    This issue also happens on the Receive Task's operationRef's description because for Receive Task, the operationRef should describe what operation the Receive task will listen on.

  • Reported: BPMN 2.0b1 — Wed, 25 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Table 10.9, page 169 (199 pdf), second row, second column: change "Service Task" to "Send Task"
    (b) Table 10.10, page 170 (200 pdf), third row, second column: change "operation that is invoked by the Receive Task" to "operation through which the Receive Task
    receives the message"
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Visibility and permissions for Data Objects and Properties must be described

  • Key: BPMN2-235
  • Legacy Issue Number: 14878
  • Status: closed  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    We should be clear in the spec the places/actions that can read and write on a DataObject or Property.

    For example: is it valid to update an activity property in another activity? We should be extensive in this, otherwise it will be left to vendor interpretation and this can create confusion.

    This was discussed in the BPMN 2.0 FTF in December 2009.

  • Reported: BPMN 2.0b1 — Thu, 17 Dec 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Under section 10.3.1 Data Modeling, paragraphs name "Lifecycle and Visibility" clearly defines the visibility and permissions for Data Object and Properties.
    Hence, this issue is already answered in the specification, and no change is required.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Confusion about Performers and other roles that Resources play for Activities

  • Key: BPMN2-225
  • Legacy Issue Number: 14832
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Should Performers be reusable--at least within a Process? How do tools add additional types of Resource/Activity Roles (e.g., overseer, manager, etc.)? Are the current extension mechanisms sufficient?
    Should Performer be a sub-class of ActivityResource or referenced by it?

  • Reported: BPMN 2.0b1 — Wed, 2 Dec 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The ActivityResource/Performer are not reusable, the Resource element referenced by them is. This schema allows most of reuse use cases.
    So the FTF conclusion is to close with no change, since there is no change needed.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Generalize message flow

  • Key: BPMN2-203
  • Legacy Issue Number: 14785
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    The specification contains this constraint: Note that Message Flow cannot connect to objects that are within the same Pool.

    There is no reason to have this constraint and it artificially constrains the model. Many process modeling paradigms (including UML) provide for flows between activities within a process. It is common to refactor processes in which case the interactions don't change - but they may move to another pool. From a business perspective we may well have a message between activities, even if we have not delineated all the participants. The constraint should be removed. This could be acheaved by a more general treatment of interactions.

    Comments:
    From: conrad.bock created: Wed, 15 Oct 2008 09:48:03 -0500 (CDT)
    Related to <a href="http://www.osoa.org/jira/browse/BPMN-229">http://www.osoa.org/jira/browse/BPMN-229</a> (Mariano is working on it).

    From: bruce created: Fri, 5 Dec 2008 18:52:24 -0600 (CST)
    This would fundamentally change one of BPMN's core concepts, message, which currently is any type of signal exchanged between processes (pools).

    From: mariano.benitez created: Wed, 10 Jun 2009 13:36:58 -0500 (CDT)
    One way or another, we need a resolution for this problem with pools and processes.

    I personally think we should allow message flows between activities of the same process, or even between processes, but without a collaboration diagram. Collaboration diagrams seems like an overkill for me in the case of simple inter-process synchronization (private processes that add up to the big business process).

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This proposal would change basic design principles in BPMN. Hence, we do not want to fix this.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantics for data flow without sequence flow

  • Key: BPMN2-202
  • Legacy Issue Number: 14783
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    An activity with data flow input and no incoming sequence flows
    should be given an executable semantics. Then the modeler can focus
    on what data activities accept and provide, without the
    complications of sequencing activities. The semantics could apply
    when input data is taken only at the beginning of activity
    execution, and only from output data that is provided at the end of
    execution of a previous activity in the flow. This isn't the same
    as sequence flow with associated data, because each incoming token
    on a sequence flow "enables the activity independently" (see
    13.1.1. Sequence Flow Considerations). An inclusive merge semantics
    for multiple incoming sequence flows (as in
    <a href="http://www.osoa.org/jira/browse/BPMN-117),">http://www.osoa.org/jira/browse/BPMN-117),</a> helps, but doesn't work
    with mult-token activities or subgraphs in common cases (see
    <a href="http://www.osoa.org/jira/browse/BPMN-254)">http://www.osoa.org/jira/browse/BPMN-254)</a>.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    We propose to relax the sequence flow (SF) connection rules for activities. Any activity may or may not have incoming or outgoing SF, irrespective of the presence of
    start and end events. The semantics we propose for activities without incoming/outgoing SF is as follows:

    • each activity that does not have any incoming SF is triggered (ie receives an implicit token) upon instantiation of the containing (sub-) process
    • each activity that does not have any outgoing SF is treated as if it would be connected to an implicit undecorated end event.
      This requires the following changes to the spec document (referring to dtc/2009-08-14 ):
      in Sect. 10.2 Paragraph "Sequence Flow Connections"
    • in the sentence "If the Activity does not have an incoming Sequence Flow, and there is no Start Event for the Process, then the Activity MUST be instantiated when
      the Process is instantiated.", delete "and there is no Start Event for the Process,"
    • in the sentence "If the Activity does not have an outgoing Sequence Flow, and there is no End Event for the Process, then the Activity marks the end of one or more
      paths in the Process", delete "and there is no End Event for the Process"
      in Sect. 10.4.2 "Start event",
    • delete this:
      "If the Start Event is used, then there MUST NOT be other flow elements that do not have incoming Sequence Flow—all other Flow Objects MUST be a target of at
      least one Sequence Flow. u Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation Marker). Compensation
      Activities MUST NOT have any incoming Sequence Flow, even if there is a Start Event in the Process level. See page 314 for more information on Compensation
      Activities. u An exception to this is the Intermediate Event, which MAY be without an incoming Sequence Flow (when attached to an Activity boundary). "
      Change this:
      "If the Start Event is not used, then all Flow Objects that do not have an incoming Sequence Flow (i.e., are not a target of a Sequence Flow) SHALL be instantiated
      when the Process is instantiated. There is an assumption that there is only one implicit Start Event, meaning that all the starting Flow Objects will start at the same time.
      u Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation marker). Compensation Activities are not considered a
      part of the normal flow and MUST NOT be instantiated when the Process is instantiated. See page 314 for more information on Compensation Activities. "
      into this:
      "All Flow Objects that do not have an incoming Sequence Flow (i.e., are not a target of a Sequence Flow) SHALL be instantiated when the Process is instantiated.
      u Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation marker). Compensation Activities are not considered a
      part of the normal flow and MUST NOT be instantiated when the Process is instantiated. See page 314 for more information on Compensation Activities.
      in Sect. 10.4.3 "End event":
      Delete this:
      "If an End Event is used, then there MUST NOT be other flow elements that do not have any outgoing Sequence Flow—all other Flow Objects MUST be a source of
      at least one Sequence Flow.
      • Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation marker). Compensation Activities MUST NOT have any
      outgoing Sequence Flow, even if there is an End Event in the Process level. See page 314 for more information on Compensation Activities. "
      In this:
      "If the End Event is not used, then all Flow Objects that do not have any outgoing Sequence Flow (i.e., are not a source of a Sequence Flow) mark the end of a path in
      the Process. However, the Process MUST NOT end until all parallel paths have completed."
      delete "If the End Event is not used, then "
      in Sect. 14.2.1. "Sequence Flow Considerations"
      change this:
      "If an Activity has no incoming Sequence Flow, and there are no Start Events in the containing Process or Sub- Process, the Activity will be instantiated when the
      containing Process or Sub-Process is instantiated. Exceptions to this are Event Sub-Processes and Activities marked as Compensation Activities, as they have
      specialized instantiation behavior. "
      into this:
      "If an Activity has no incoming Sequence Flow, the Activity will be instantiated when the containing Process or Sub-Process is instantiated. Exceptions to this are
      Compensation Activities, as they have specialized instantiation behavior. "
      change this:
      "If the Activity has no outgoing Sequence Flow and there are no End Events in the containing Process or Sub- Process, the Activity will terminate and termination
      semantics for the container applied. "
      into this:
      "If the Activity has no outgoing Sequence Flow, the Activity will terminate without producing any tokens and termination semantics for the container is then applied. "
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Enabling multiple events at the same time for the same message

  • Key: BPMN2-201
  • Legacy Issue Number: 14782
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    When multiple message events for the same message (payload type) are
    enabled at the same time ("executed" at the same time), can they
    receive the same transmitted message? For example, suppose a process
    has parallel gateways resulting in two message events for an Order
    message being executed at the same time. If an order message is sent
    at execution time, can it be received by both message events?

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Change text in section "14.2.3 Task":
    Current:
    Receive Task: Upon instantiation, the Receive Task begins waiting for the associated Message. When the Message arrives, the Receive Task completes.
    New:
    Receive Task: Upon instantiation, the Receive Task begins waiting for the associated Message. When a message with the right correlation information for that process
    instance arrives, the Receive Task completes. For key-based correlation, only a single receive for a given correlation key can be active, and thus the message matches
    at most one process instance. For predicate-based correlation, the message can be passed to multiple receive tasks.
    Change text in section "14.4.2 Intermediate Events"
    Current:
    For Intermediate Events, the handling consists of waiting for the Event to occur. Waiting starts when the Intermediate Event is reached. Once the Event occurs, it is
    consumed. Sequence flow leaving the Event is followed as usual.
    New:
    For Intermediate Events, the handling consists of waiting for the Event to occur. Waiting starts when the Intermediate Event is reached. Once the Event occurs, it is
    consumed. Sequence flow leaving the Event is followed as usual.
    For intermediate message catch events, the message correlation behavior is the same as for receive tasks – see section "14.2.3 Task".
    Change text in section "14.4.3 Intermediate Boundary Events"
    Current:
    For boundary Events, handling first consists of consuming the Event occurrence. If the cancelActivity attribute is set, the Activity the Event is attached to is then
    cancelled (in case of a multi-instance, all its instances are cancelled); if the attribute is not set, the Activity continues execution (only possible for Message, Signal, Timer,
    and Conditional Events, not for Error Events). Execution then follows the Sequence Flow connected to the boundary Event.
    New:
    For boundary Events, handling first consists of consuming the Event occurrence. If the cancelActivity attribute is set, the Activity the Event is attached to is then
    cancelled (in case of a multi-instance, all its instances are cancelled); if the attribute is not set, the Activity continues execution (only possible for Message, Signal, Timer,
    and Conditional Events, not for Error Events). Execution then follows the Sequence Flow connected to the boundary Event.
    For intermediate boundary message events, the message correlation behavior is the same as for receive tasks – see section "14.2.3 Task".
    Change text in section "14.4.4 Event Sub-Processes"
    Current:
    A non-interrupting Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The non-interrupting Event
    Handler may only be initiated after the parent Activity is Running. More than one non-interrupting Event Handler may be initiated and they may be initiated at different
    times. There might be multiple instances of the non-interrupting Event Handler at a time.
    New:
    A non-interrupting Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The non-interrupting Event
    Handler may only be initiated after the parent Activity is Running. More than one non-interrupting Event Handler may be initiated and they may be initiated at different
    times. There might be multiple instances of the non-interrupting Event Handler at a time.
    For Event Sub-Processes triggered via message start events, the message correlation behavior is the same as for receive tasks – see section "14.2.3 Task".
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Annex D Glossary [Specification]: Update Glossary

  • Key: BPMN2-197
  • Legacy Issue Number: 14778
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The Glossary has been taken from V1.1 and needs to be updated.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Changes to Annex C: Glossary
    (a) Reformat the descriptions of the definitions so that the definition is not repeated in the description. For example, change the beginning of the Activity definition from:
    "An activity is a generic term for work that a company or organization performs via business processes"
    To:
    "Work that a company or organization performs using business processes."
    (b) Remove WfMC definitions from Glossary (some of these definitions will be merged with BPMN terms (see below)
    (c) Remove Workflow Pattern definitions from Glossary
    (d) "Abstract Process" Definition: change definition to "A process that represents the interactions between a private business process and another process or
    participant."
    (e) "AND-Join" Definition: Delete this topic and merge the definition with "Join" (see below)
    (f) "Join" Definition: Replace definition with the following: "A point in the Process where two or more parallel Sequence Flow paths are combined into one Sequence
    Flow path. BPMN uses a Parallel Gateway to perform a Join. Also known as "AND-Join.""
    (g) "AND-Split" Definition: Delete this topic and merge the definition with "Fork"
    (h) "Fork" Definition: Replace definition with the following: "A point in the Process where one Sequence Flow path is split into two or more paths that are run in parallel
    within the Process, allowing multiple activities to run simultaneously rather than sequentially. BPMN uses multiple outgoing Sequence Flows from Activities or Events or
    a Parallel Gateway to perform a Fork. Also known as "AND-Split."
    "Artifact" Definition: remove last two sentences.
    (j) "Association" Definition: replace definition with the following: "A connecting object that is used to link information and Artifacts with Flow Objects. An association is
    represented as a dotted graphical line with an arrowhead to represent the direction of flow."
    (k) "Business Analyst" Definition: replace the definition with "A specialist who analyzes business needs and problems, consults with users and stakeholders to identify
    opportunities for improving business return through information technology, and defines, manages, and monitors the requirements into business processes."
    (l) "Business Process" definition: replace definition with the following: "A defined set of business activities that represent the steps required to achieve a business
    objective. It includes the flow and use of information and resources."
    (m) Remove the "Business Process Definition" item.
    "Business Process Management" definition: replace definition with the following: "management (for example, process analysis, definition, processing, monitoring and
    administration), including support for human and application-level interaction. BPM tools can eliminate manual processes and automate the routing of requests between
    departments and applications."
    (o) "Choreography" definition: replace definition with the following: "An ordered sequence of message exchanges between two or more Participants. In a Choreography
    there is no central controller, responsible entity, or observer of the Process."
    (p) "Collaboration" definition: replace definition with the following: "of message exchanges between two or more Participants."
    (q) "Compensation Flow" definition: replace definition with the following: "Flow that defines the set of activities that are performed while the transaction is being rolled
    back to compensate for activities that were performed during the Normal Flow of the Process. A Compensation Flow can also be called from a Compensate End or
    Intermediate Event."
    (r) Remove the "Controlled Flow" item.
    (s) "Decision" definition: replace definition with the following: "A gateway within a business process where the Sequence Flow can take one of several alternative paths.
    Also known as "Or-Split.""
    (t) "End Event" definition: replace first sentence with: "An event that indicates where a path in the process will end."
    (u) "Event Context" definition: replace definition with the following: "An activity or group of activities in an expanded Subprocess that can be interrupted by an exception
    (such as an Error Intermediate Event)."
    (v) "Exception" definition: replace definition with the following: "An event that occurs during the performance of the Process that causes a diversion from the Normal
    Flow of the Process. Exceptions can be generated by Intermediate Events, such as time, error, or message."
    (w) "Exception Flow" definition: replace definition with the following: "A Sequence Flow path that originates from an Intermediate Event attached to the boundary of an
    activity. The Process does not traverse this path unless the Activity is interrupted by the triggering of a boundary Intermediate Event (an Exception - see above)."
    "Expanded Sub-Process" definition: replace definition with the following: "A Sub-Process that exposes its flow detail within the context of its Parent Process. An
    Expanded Sub-Process is displayed as a rounded rectangle that is enlarged to display the Flow Objects within."
    "Flow" definition: replace definition with the following: "A directional connector between elements in a Process, Collaboration, or Choreography. A Sequence Flows
    represents the sequence of Flow Objects in a Process or Choreography. A Message Flow represents the transmission of a Message between Collaboration
    Participants.The term Flow is often used to represent the overall progression of how a Process or Process segment would be performed."
    (z) "Flow Object" definition: replace definition with the following: "A graphical object that can be connected to or from a Sequence Flow. In a Process, Flow Objects
    are Events, Activities, and Gateways. In a Choreography, Flow Objects are Events, Choreography Activities, and Gateways."
    (a2) "Intermediate Event" definition: replace the definition with: "An event that occurs after a Process has been started. An Intermediate Event affects the flow of the
    process by showing where messages and delays are expected, distributing the Normal Flow through exception handling, or showing the extra flow required for
    compensation. However, an Intermediate Event does not start or directly terminate a process. An Intermediate Event is displayed as a circle, drawn with a thin double
    line."
    (b2) "Lane" definition: replace the definition with: "A partition that is used to organize and categorize activities within a Pool. A Lane extends the entire length of the Pool
    either vertically or horizontally. Lanes are often used for such things as internal roles (e.g., Manager, Associate), systems (e.g., an enterprise application), or an internal
    department (e.g., shipping, finance),"
    (c2) "Merge" definition: replace the definition with: "A point in the Process where two or more alternative Sequence Flow paths are combined into one Sequence Flow
    path. No synchronization is required because no parallel activity runs at the join point. BPMN uses multiple incoming Sequence Flows for an Activity or an Exclusive
    Gateway to perform a Merge. Also know as "OR-Join.""
    (d2) Remove "OR-Join" and merge it's definition with the "Merge" item.
    (e2) "Message" definition: replace the definition with: "An Object that depicts the contents of a communication between two Participants. A message is transmitted
    through a Message Flow and has an identity that can be used for alternative branching of a Process through the Event-Based Exclusive Gateway."
    (f2) "Message Flow" definition: replace the definition with: "A Connecting Object that shows the flow of messages between two Participants. A Message Flow is
    represented by a dashed lined."
    (g2) "Normal Flow" definition: replace the definition with: "A flow that originates from a Start Event and continues through activities on alternative and parallel paths until
    reaching an End Event."
    (h2) Remove OR-Split and merge definition with Decision
    (i2) Remove Parallel Split item
    (j2) "Participant" definition: replace last sentence in definition with: "In a Collaboration, Participants are informally known as "Pools."
    (k2) "Pool" definition: replace the definition with: "A Pool represents a Participant in a Collaboration. Graphically, a Pool is a container for partitioning a Process from
    other Pools/Participants. A Pool is not required to contain a Process, i.e., it can be a "black box." "
    (l2) "Private Business Process" definition: replace the definition with: "A process that is internal to a specific organization, generally called a workflow or BPM process."
    (m2) "Process" definition: replace the definition with: "A sequence or flow of Activities in an organization with the objective of carrying out work. In BPMN, a Process
    is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and Sequence Flow that adhere to a finite execution semantics."
    (n2) "Result" definition: replace the definition with: "The consequence of reaching an End Event. Types of Results include Message, Error, Compensation, Signal, Link,
    and Multiple."
    (o2) "Start Event" definition: replace the definition with: "An Event that indicates where a particular Process starts. The Start Event starts the flow of the Process and
    does not have any incoming Sequence Flow, but can have a Trigger. The Start Event is displayed as a circle, drawn with a single thin line."
    (p2) "Sequence Flow" definition: replace the definition with: "A connecting object that shows the order in which activities are performed in a Process and is represented
    with a solid graphical line. Each Flow has only one source and only one target. A Sequence Flow can cross the boundaries between Lanes of a Pool but cannot cross
    the boundaries of a Pool."
    (r2) "Task" definition: Replace third sentence of the definition with the following: "Generally, an end-user, an application, or both will perform the Task."
    (s2) "Token" definition: replace the definition with: "A theoretical concept that is used as an aid to define the behavior of a Process that is being performed. The
    behavior of Process elements can be defined by describing how they interact with a token as it "traverses" the structure of the Process. For example, a token will pass
    through an Exclusive Gateway, but continue down only one of the Gateway's outgoing Sequence Flow."
    (t2) "Transaction" definition: in first sentence, replace "A Transaction is" with "A Sub-Process that represents"
    (u2) "Trigger" definition: replace first sentence with "A mechanism that detects an occurrence and can cause additional processing in response, such as the start of a
    business Process."
    (v2) "Uncontrolled Flow" definition: replace the definition with: "Flow that proceeds without dependencies or conditional expressions. Typically, an Uncontrolled Flow
    is a Sequence Flow between two Activities that do not have a conditional indicator (mini-diamond) or an intervening Gateway."
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.3.1 [Data-MM]: Events can contain properties but the relationship is not shown in the MM diagram

  • Key: BPMN2-200
  • Legacy Issue Number: 14781
  • Status: closed  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    Figure 10-53 describes the class diagram for properties, they have a containment relation with Activity and Process, but not with Events. In the spec text reads:

    • "Certain flow elements may contain properties, in particular only Processes, Activities and Events may contain Properties"

    We already agreed that events activities (throw or catch) can contain properties, so we need to add this to the MM and update the diagram

    Proposal: add relation between Properties and Events in the MM and update the diagram 10-53

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Add relation between Properties and Events in the MM and update the diagram 10-53
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Business Rule Task description doesn't describe purpose (section 10.2.3, Beta 1)

  • Key: BPMN2-199
  • Legacy Issue Number: 14780
  • Status: closed  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue:The description of the business rule task just describes its shape, but doesn't state its purpose.

    Proposal: Add a single sentence such as "A business rule task calls a business rule and returns its result into the process."

    Comments:
    From: mkloppmann created: Tue, 14 Oct 2008 10:27:45 -0500 (CDT)
    <a href="http://www.osoa.org/jira/browse/BPMN-143" title="0.5.1. Section 10.1 [Execution semantics]: Clarify completion of tasks">BPMN-143</a> assumes the proposed resolution for <a href="http://www.osoa.org/jira/browse/BPMN-268" title="Business Rule Task description doesn't describe purpose (section 10.2.3, Beta 1)">BPMN-268</a>.

    From: bruce created: Fri, 5 Dec 2008 18:21:24 -0600 (CST)
    I propose the following tweak as more informative and more consistent w/language of business rule people:

    "A business rule task is a specific type of service task that calls a decision or ruleset on a business rule engine and returns its result to the process."

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue has been fixed before the Beta. There is a description for the BR Task in section 10.2.3 (page 141/pdf 171) and in execution semantics, section 14.2.3
    (page 393/pdf 424)
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Tasks vs Global Tasks

  • Key: BPMN2-198
  • Legacy Issue Number: 14779
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The various kinds of tasks could also be global tasks. Section
    10.2.7. Global Task says:

    There are different types of Tasks identified within BPMN to
    separate the types of inherent behavior that Tasks might
    represent. This is true for both Global Tasks and standard Tasks,
    where the list of task types is the same for both. For the sake of
    efficiency in this specification, the list task types is presented
    once on page 167.

    "Globalness" should be an attribute of Task, so the taxonomy of
    tasks does not need to be repeated.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    We do not consider making all tasks global something necessary. Besides simplicity and simetry, there is no added value to business users, since the refactoring would
    be done by tooling anyway, so they would not see a difference if the metamodel changes in one way or the other.
    We consider this issue to be part of this FTF, maybe a new RFP can handle it.
    Disposition: Closed, Out Of Scope

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 8.1.5 [Infra] Import statement description is not clear enough

  • Key: BPMN2-196
  • Legacy Issue Number: 14776
  • Status: closed  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    The intention of the import statement is to include an ENTIRE file as a namespace, so I can reference elements defined inside that file.

    The current text says:
    "The Import class is used when referencing external element, either BPMN elements contained in other BPMN Definitions or non-BPMN elements. Imports must be explicitly defined."

    It is not clear that you are importing the entire file (ala BPEL). Also, it is not clear what is the meaning of "Imports must be explicitly defined"

    – Proposal by Mariano Benitez 23/Oct —
    Change the wording to:

    The import class is used to import elements defined externally and make them available for use by elements defined within the scope of the import element.
    The importType attribute defines the style of associated with the element. Both BPMN and non-BPMN imports are allowed.
    For example: This allows importing an XML Schema that will be used inside StructureDefinition elements, or invoking a global task defined in another file.
    Import elements can be defined globally as part of the definitions, so it is available to all elements defined in that definitions, or it can be defined inside a StructureDefinition, which restricts the scope to that element only.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Change in Table 8.2 Import Attributes, the description of the importType attribute to:
    "Identifies the type of document being imported by providing an absolute URI that identifies the encoding language used in the document.The value of the importType
    attribute MUST be set to http://www.w3.org/2001/XMLSchema when importing XML Schema 1.0 documents, to http://www.w3.org/TR/wsdl20/ when importing
    WSDL 2.0 documents, and http://schema.omg.org/spec/BPMN/2.0 when importing BPMN 2.0 documents. Other types of documents MAY be supported.
    Importing Xml Schema 1.0, WSDL 2.0 and BPMN 2.0 types MUST be supported."
    Note on 2010-04-26:
    The FTF acknowldges the proposed namespace does not follow OMG guidelines for namespace conventions. The final namespaces will be:

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 2 Conformance [Specification]: Explicitly define BPMN compliance criteria, with focus on "model"

  • Key: BPMN2-195
  • Legacy Issue Number: 14772
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Beta 1: Section 2 Conformance [Specification]: Explicitly define BPMN compliance criteria, with focus on "model" (as defined above) portability between tools.

    ##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-301
    ##Original Info: (Severity: Significant - Nature: Enhancement)

    This is number 4 of 12 issues submitted by Bruce Silver

    Explicitly define BPMN compliance criteria, with focus on "model" (as defined above) portability between tools. What elements and attributes MUST be supported. There can and should be multiple levels here. You don't have to certify it if you are explicit enough and connect it with #3 above. There will be no shortage of available tools that can check compliance.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close this issue as a duplicate.
    The resolution of issue 14240 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.2.8 [Execution Semantics] Loops: Loop names misleading

  • Key: BPMN2-205
  • Legacy Issue Number: 14789
  • Status: closed  
  • Source: SAP SE ( Rouven Day)
  • Summary:

    The names "Standard Loop" and "Multi Instance Loop" are misleading. Actually both allow for creation of a desired number of Activity instances, not just Multi Instance Loops as the spec text states it. So the multiple instance characteristics is true for all loops, also Standard Loops. Thus the naming of the loop types is very misleading.

    Proposal: Go for the well known names (<a href="http://en.wikipedia.org/wiki/Control_flow#Loops">http://en.wikipedia.org/wiki/Control_flow#Loops</a>). Rename Standard Loop to Condition-controlled Loop (or Conditional Loop or Condition-based Loop). Also find a better name for Multi Instance Loop. I´ll try to post some name proposals soon.

    Comments:
    From: wstephe created: Fri, 20 Mar 2009 19:15:16 -0500 (CDT)
    The results of Issue 193 will also resolve this issue.

    From: wstephe created: Sat, 12 Sep 2009 13:45:16 -0500 (CDT)
    The section number was updated to match the Beta 1 spec.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This is not an implementation issue so the proposal is to close the issue with no changes to the specification.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reuse of processes in orchestration and choreography

  • Key: BPMN2-204
  • Legacy Issue Number: 14787
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Modelers should be able to define processes independently of whether
    they will be reused in processes or choreographies. Currently the
    information coming in or out of a process is either through data flow or
    through messages, I understand it. The modeler must commit to one of
    these in advance, or define two copies of the process, one with
    messages, the other with data flow. Suzette brought this up separately
    and says a solution was agreed that Mariano will write up. Didn't see
    any issue from her on this, sorry if this is a duplicate.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In section 10.3.2 Executions Semantics for Data, add the following text at the end of the section:

    In the case of Throw and Catch Events, given their nature, the execution semantics for data is different.
    When a ThrowEvent is activated, all DataInputAssociations of the event are executed, filling the DataInputs of the Event. Finally DataInputs are then copied to the
    elements thrown by the event (Messages, Signal, etc). Since there are no InputSets defined for Events, the execution will never wait.
    When a CatchEvent is activated, DataOutputs of the event are filled with the element that triggered the event. Then all DataOutputAssociations of the event are
    executed. There are no OutputSets defined for Events.
    To allow invoking a Process from both a CallActivity and via MessageFlow, the StartEvent and EndEvent support an additional case.
    In the case of a StartEvent, the DataInputs of the enclosing process are available as targets to the DataOutputAssociations of the Event. This way the Process
    DataInputs can be filled using the elements that triggered the StartEvent.
    In the case of a EndEvent, the DataOutputs of the enclosing process are available as sources to the DataInputAssociations of the Event. This way the resulting elements
    of the EndEvent can use the Process DataOutputs as sources.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pools multiplicity

  • Key: BPMN2-192
  • Legacy Issue Number: 14754
  • Status: closed  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    Table 9-1 says a diagram containing pools, i.e. Collaboration, must contain 2 or more. Then is says "Note that the multiplicity of the pools model association is an open issue and may be changed in a later revision of the specification," but it is unclear whether this means the minimum of 2 pools in a diagram or relates to the MI marker on pools. If the former, I think the minimum should be 1 and it should not wait until a later revision of the sepcification. The reasons are
    1) backward compatibility with BPMN 1.1, in which all BPDs were assumed to have at least one pool, whether boundary visible or not; and
    2) ability for modelers to create diagrams with just one pool, labeled with name of the process... and be able to create schema-valid xml from it.

    Also... following fig 9-4 it says " ...the Activities that represent the work performed from the point of view of the modeler or the modeler's organization may be considered "internal" Activities and are not required to be surrounded by the boundary of their Pool...". This is only true if all the activities are part of a single process (orchestration). I think better to say, "...a single process that represents the work performed from the point of view of the modeler or the modeler's organization may be considered "internal" and is not required to be surrounded by the boundary of its Pool...".

    Comments:
    From: trickovic created: Wed, 21 Jan 2009 07:01:18 -0600 (CST)
    Bruce's comment: Second part is editorial issue. First part is MM issue.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The metamodel allows for Collaborations to have zero (0) or more Pools. Thus, it is possible to create a Collaboration with just one Pool. The statement that a
    Collaboration contains two (2) Pools is inaccurate and will be fixed.
    The statement about multiplicity of Pools being an open issue was removed from the specification prior to the completion of the Beta version.
    Section 9.2, page 116 (146 pdf), first paragraph below Figure 9.4:
    (a) Change first sentence to:
    "A Collaboration can contain at two (2) or more Pools (i.e., Participants)."
    (b) Change second sentence to:
    "However, a Process that represents the work performed from the point of view of the modeler or the modeler's organization may be considered "internal" and is not
    required to be surrounded by the boundary of the Pool, while the other Pools in the Diagram MUST have their boundary."
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

[Meta-model] Exclusive gateway is missing specification of order of leaving sequence flows

  • Key: BPMN2-191
  • Legacy Issue Number: 14753
  • Status: closed  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Type: Technical

    Description of issue: The execution semantics for exclusive gateways correctly states that "the conditions [of the outgoing sequence flows] are evaluated in order". However, the meta-model for an exclusive gateway does not allows for the specification of that order.

    Proposal: Using the "appropriate means" (prototype statement?), ensure the relationship from a FlowNode to its outgoing sequence flows is an ordered collection, rather than a set. This provides ordering not only for an exclusive gateway, but for all FlowNodes, but that doesn't seem to harm.
    In the XSD, where the sequence flows reference their source node rather than vice versa, an additional attribute or element to render the order may be needed, or the representation of sequence flow in the XSD may need to be revised.

    (Assigning to Suzette as representative of MM team who also is concerned with the XSD)

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Update Table 8.61 (pg 131)
    Append the following to the description for the 'outgoing' association: This is an ordered collection.
    The UML Metamodel used as base for XSD and XMI will be updated to reflect this change
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Diagram Interchange should align with Diagram Type Definition

  • Key: BPMN2-190
  • Legacy Issue Number: 14752
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    This summarizes a conversation with Maged, we agreed an issue should be
    filed. He said there were two approaches to diagram interchange (which
    he can explain more about). The one in the IOS submission was chosen
    for expediency and IBM will not be submitting it to the OMG's Diagram
    Type Definition RFP (DTD). The differences between the approaches is
    too much to resolve in an FTF. The IOS submission should use the same
    diagram interchange as IOS members (IBM at least) are submitting for
    DTD. Then any remaining differences between IOS and the later DTD
    adoption can be resolved in FTF.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close this issue as a duplicate.
    The resolution of issue 14423 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.2.5: Sub-Process: Figure 10.25; Add a minus sign to the bottom of an expanded Sub-Process?

  • Key: BPMN2-207
  • Legacy Issue Number: 14793
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The collapsed Sub-Process has a "plus" sign marker. Should the expanded Sub-Process have a "minus" sign marker. Many tools already do this.

    Comments:
    From: wstephe created: Thu, 5 Mar 2009 19:41:21 -0600 (CST)
    Given the current schedule, this issue will not be addressed in the RFP process. This issue can be reopened by the BPMN 2.0 FTF.

    From: wstephe created: Sat, 12 Sep 2009 13:35:55 -0500 (CDT)
    The Section and Figure numbers were updated to match the Beta 1 spec

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close; no change
    The FTF decided that the issue report does not identify a problem with this specification
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 8.2.1 [Service Model] How to model a request-reply use case?

  • Key: BPMN2-206
  • Legacy Issue Number: 14791
  • Status: closed  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    In BPMN 1.1 there is no way to model a request-reply model based on a single interface operation.

    Right now we don't have a way to relate a Receive Task and Service/Reply Task that generates the response to the message received.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close, no Change. The FTF decided that the reported issue does not identify a problem with BPMN 2.0
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Data flow in/out of events

  • Key: BPMN2-194
  • Legacy Issue Number: 14760
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Data flow should work with events, rather than just send and receive
    tasks and activities. Modelers sh9uldn't need to change the model so
    much just to add data flow.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This is not a problem with the specification, so we close with no change
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 10.3.1 Data Objects [Data]: Change Multiplicity of datastate attribute from 0..1 to 0..*

  • Key: BPMN2-193
  • Legacy Issue Number: 14758
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    A Data Object can have multiple states at the same time. Change Multiplicity of datastate attribute from 0..1 to 0..*

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The FTF decided this change is not required, since it implementing another way extending state multiplicity for data objects (DataObjectRefs). See 15080.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Is a Message a DataInput for an Activity; Is Message Flow a Data Association

  • Key: BPMN2-187
  • Legacy Issue Number: 14748
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Is Message Flow another type of Data Association? This would mean that Messages can be mapped to the Data Inputs of Activities.
    Is there another way to use Message as an Activity Input?

    Comments:
    From: conrad.bock created: Thu, 5 Feb 2009 08:54:23 -0600 (CST)
    This would be a subtopic of <a href="http://www.osoa.org/jira/browse/BPMN-229" title="Reuse of processes in orchestration and choreography">BPMN-229</a>.

    From: ings_osoa created: Tue, 10 Mar 2009 10:32:59 -0500 (CDT)
    Steve notes that this issue may arise during our samples work and if so we can resolve it in that context. Otherwise he agrees it should be deferred.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Formatted versions are available here:
    10_process-activities_updatedFor359_v2.doc
    10_process-data_updatedFor359_v2.doc
    10_process-events_updatedFor359_v3.doc
    14_execsem_updatedFor359_v2.doc
    (a) Replace the first paragraph after Figure 10.11 with the following:
    "The Service Task inherits the attributes and model associations of Activity (see Table 103). In addition the following constraints are introduced when the Service Task
    references an Operation: The Service Task has exactly one InputSet and at most one OutputSet. It has a single data input with an ItemDefinition equivalent to the one
    defined by the Message referenced by the inMessageRef attribute of the associated operation. If the operation defines output Messages, the Service Task has a single
    data output that has an ItemDefinition equivalent to the one defined by the Message referenced by the outMessageRef attribute of the associated operation."
    (b) Add a new paragraph immediately after Figure 10.14 with the following:
    "The Send Task inherits the attributes and model associations of Activity (see Table 10.1 ). In addition the following constraints apply when the Send Task references a
    Message: The Send Task has at most one input set and one data input. If the data input is present, it must have an ItemDefinition equivalent to the one defined by the
    associated Message. At execution time, when the Send Task is executed, the data automatically moves from the data input on the Send Task into the Message to be
    sent. If the data input is not present, the Message will not be populated with data from the process."
    (c) Add a new paragraph immediately after Figure 10.15 with the following:
    "The Receive Task inherits the attributes and model associations of Activity (see Table 10.1 ). In addition the following constraints apply when the Receive Task
    references a Message: The Receive Task must have at most one output set and at most one data output on the Receive Task. If the data output is present, it must have
    an ItemDefinition equivalent to the one defined by the associated Message. At execution time, when the Receive Task is executed, the data automatically moves from
    the Message to the data output on the Receive Task. If the data output is not present, the payload within the Message will not flow out of the task and into the
    process."
    (d) Section 10.3.1, last paragraph on page 182 (212 pdf): delete ", Messages" from the last sentence.
    (e) Table 10.52, attributes "dataInputs" and "dataOutputs": add "This is an ordered set" to their descriptions.
    (f) First paragraph after Table 10.54, change "outputs to the specific Activity implementations" to "outputs to specific Activity and Event implementations"
    (g) Section 10.3.1, Sub-Section Service Task Mapping: replace the two (2) paragraphs of the section with the following:
    "If the Service Task is associated with an Operation there must be a single data input on the Service Task and it must have an ItemDefinition equivalent to the one
    defined by the Message referred to by the inMessageRef attribute of the operation. If the operation defines output Messages, there must be a single data output and it
    must have an ItemDefinition equivalent to the one defined by Message referred to by the outMessageRef attribute of the operation."
    (h) Add a new Sub-Section after Sub-Section Service Task Mapping, with a title of "Send Task Mapping" and contents of the following:
    "If the Send Task is associated with a Message, there must be at most one input set and at most one data input on the Send Task. If the data input is present, it must
    have an ItemDefinition equivalent to the one defined by the associated Message. If the data input is not present, the Message will not be populated with data at
    execution time."
    Add a new Sub-Section after Sub-Section Service Task Mapping, with a title of "Receive Task Mapping" and contents of the following:
    "If the Receive Task is associated with a Message, there must be at most one output set and at most one data output on the Receive Task. If the data output is present,
    it must have an ItemDefinition equivalent to the one defined by the associated Message. If the data output is not present, the payload within the Message will not flow
    out of the Event and into the process."
    (j) Add a new Sub-Section after Sub-Section Script Task Mapping, with a title of "Events" and contents of the following:
    If any of the EventDefinitions for the Event is associated with an element that has an Item Definition (such as a Message, Escalation, Error, Signal), the following
    constraints apply:
    [bullet] If the Event is associated with multiple Event Definitions, there must be one data input (in the case of Throw Events) or one data output (in the case of Catch
    Events) for each Event Definition. The order of the Event Definitions and the order of the data inputs/outputs determine which input/output corresponds with which
    Event Definition.
    [bullet] For each Evant Definition and input/output pair, if the input/output is present, it must have an ItemDefinition equivalent to the one defined by the Message,
    Signal, Error or Signal on the associated Event Definition. In the case of a ThrowEvent, if the data input is not present, the Message, Escalation, Error, or Signal will not
    be populated with data. In the case of a CatchEvent, if the data output is not present, the payload within the Message, Escalation, Error, or Signal will not flow out of
    the event and into the process.
    (k) Replace Figure 10.66: ThrowEvent.dataInputs and CatchEvent.dataOutputs to have multiplicity of 0..n
    (l) Section 10.4.1, Sub-Section Data Modeling and Events: Replace the 2nd sentence of the 1st paragraph with the following:
    "For such Events, the following constraints apply:
    [bullet]If the Event is associated with multiple Event Definitions, there must be one data input (in the case of Throw Events) or one data output (in the case of Catch
    Events) for each Event Definition. The order of the Event Definitions and the order of the data inputs/outputs determine which input/output corresponds with which
    Event Definition.
    [bullet]For each Evant Definition and input/output pair, if the input/output is present, it must have an ItemDefinition equivalent to the one defined by the Message,
    Signal, Error or Signal on the associated Event Definition. In the case of a ThrowEvent, if the data input is not present, the Message, Escalation, Error, or Signal will not
    be populated with data. In the case of a CatchEvent, if the data output is not present, the payload within the Message, Escalation, Error, or Signal will not flow out of
    the event and into the process.
    The execution behavior is then as follows:
    [bullet]For Throw Events: When the event is activated, the data in the data input is automatically assigned to the Message, Signal, Escalation or Error referenced by the
    corresponding EventDefinition.
    [bullet]For Catch Events: When the trigger of the event occurs (for example, the Message is received), the data is automatically assigned to the data output that
    corresponds to the EventDefinition that described that trigger."
    (m) Section 10.4.1: Delete Sub-Section "Catch Event Data Association" and delete Sub-Section "Throw Event Data Association"
    Table 10.75, attributes "eventDefinitionRefs", "eventDefinitions", and "dataOutputs": add "This is an ordered set" to their descriptions.
    (o) Table 10.76, attributes "eventDefinitionRefs", "eventDefinitions", and "dataInputs": add "This is an ordered set" to their descriptions.
    (p) Section 14.2.3: Replace the description of the bullet for Service Task with the following: "Upon activation, the data in the inMessage of the Operation is assigned
    from the data in the data input of the Service Task, and the Operation is invoked. On completion of the service, the data in the data output of the Service Task is
    assigned from the data in the outMessage of the Operation, and the Service Task completes. If the invoked service returns a fault, that fault is treated as interrupting
    error, and the Activity fails."
    (q) Section 14.2.3: Replace the description of the bullet for Send Task with the following:
    "Upon activation, the data in the associated Message is assigned from the data in the data input of the Send Task. The Message is sent and the Send Task completes."
    (r) Section 14.2.3: Replace the description of the bullet for Receive Task with the following:
    "Upon activation, the Receive Task begins waiting for the associated Message. When the Message arrives, the data in the data output of the Receive Task is assigned
    from the data in the Message, and Receive Task completes."
    (s) Section 14.2.3, Bullet for User Task: Replace "instantiation" with "activation"
    (t) Section 14.2.3, Bullet for Manual Task: Replace "instantiation" with "activation"
    (u) Section 14.2.3, Bullet for Business Rule Task: Replace "instantiation" with "activation"
    (v) Section 14.2.3, Bullet for Script Task: Replace "instantiation" with "activation"
    (w) Section 14.2.3, Bullet for Abstract Task: Replace "instantiation" with "activation"
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 [Section 12.1.2] - Use of the term "BPMN" in class names

  • Key: BPMN2-186
  • Legacy Issue Number: 14747
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Many classes in the visual model start with BPMN. For example, BPMNDiagram, BPMNShape, etc.

    Given that this metamodel is part of the BPMN spec, including BPMN in class names seem extraneous. Certainly we don't do so in the semantic metamodel, so there is an inconsistency in style. Also, this style of naming generally isn't considered a recommended practice. What if BPMN is renamed in the next version?

    Is there a real need for this pattern?

    Comments:
    From: oliver.kieselbach created: Thu, 15 Jan 2009 06:29:07 -0600 (CST)
    I personally don't have a strong opinion about the general naming. Two motivations were driving us here: 1) we wanted to have names which clearly differentiate between a visual MM element from the corresponding semantic element to avoid confusion when talking/discussing/describing elements. 2) when Maged has shown us the Diagram Definition concept and the examples for the UML intrumentation of this DD MM, he also used names like "UMLClassDiagram", "UMLConnector" etc.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    We need the prefix for Domain Specific refinement of the generic DD specification to differentiate it from the referenced element. This pattern was also done with
    UML.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 [Section 12.1.2] - OrchestrationDiagram should be called ProcessDiagram

  • Key: BPMN2-185
  • Legacy Issue Number: 14746
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    In the visual metamodel, a Choreography is visualized in a ChoreographyDiagram, a Collaboration is visualized in a CollaborationDiagram, and yet a Process is not visualized with a ProcessDiagram as I would expect but rather an OrchestrationDiagram.

    For consistency and clarity in terminology, the OrchestrationDiagram should be called ProcessDiagram. Was there a reason it couldn't be?

    Comments:
    From: oliver.kieselbach created: Thu, 15 Jan 2009 06:30:52 -0600 (CST)
    I don't think there was a special reason behind the decision to use "OrchestrationDiagram". So, it would be fine with me to rename it to "ProcessDiagram"

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The BPMN DI does not contain diagram type as this is not needed for Diagram interchange.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Relationship navigation (both in MM and XSD)

  • Key: BPMN2-184
  • Legacy Issue Number: 14743
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Beta 1, Section 8.4

    Currently the MM contains a bidirectional relationship between Interface and ServiceRef. This is also represented in the XSD, where the Interface complexType has an element that references a ServiceReference, and the ServiceReference complexType has an element that references an Interface.

    In the Samples meeting, it was raised that the Interface->ServiceReference relationship was not needed in the XSD. This discussion resulted in several outstanding questions:

    • If it doesn't belong in the XSD, should it be in the MM?
    • Tool vendors would find this convenient to have. But is that an implementation issue?
    • This likely isn't the only case. Need to have a broader discussion.
    • What is the purpose of the MM? How are we positioning it?
    • If the MM is for portability, then should the arguments used against the XSD also apply to the MM?
  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:
    • This issue has been carried over from the BPMN 2.0 submission team
    • Ongoing implementation projects do not indicate this is an issue. Close with no changes to the specification (as it is not a problem)
      Disposition: Closed, No Change
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 10.2 Activities: Reference Task and Sub-Process from BPMN 1.1 not in BPMN 2.0

  • Key: BPMN2-183
  • Legacy Issue Number: 14742
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    In BPMN 1.1, there were Reference Tasks and Sub-Processes, which provided a type of within Diagram reusability--as opoposed to Global Tasks reused across diagrams. Any feature that is in 1.1, but not 2.0 should have some documentation as to why it is not there. This issue could be used to re-introduce the elements or to document why they were excluded in this version.

    Comments:
    From: wstephe created: Tue, 3 Feb 2009 17:39:41 -0600 (CST)
    This could be potential resolved by modifying the Call Activity so that it can also call activities within the same diagram (which was what the Reference Task and Reference Sub-Process did).

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In Changes annex (Annex A) add:
    "Reference Tasks are removed. These provided reusability within a single diagram, as compared to GlobalTasks, which are resuable across multiple diagrams.
    GlobalTasks can be used instead of Reference Tasks, to simplify the language and implementations."
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Global Task should have performer, Call Activity should have capability to overwrite performer

  • Key: BPMN2-176
  • Legacy Issue Number: 14732
  • Status: closed  
  • Source: Oracle ( Ralf Mueller)
  • Summary:

    A Global Task should have a (default) performer. Right now that is missing in the meta model.
    A Call Activity then should have the capability to overwrite the performer of the global task it is calling.

    Example: (Global User Task)

    <globalUserTask id="approveOrder" name="Approve Order" implementation="humanTaskWebService">
    <documentation>
    Given an order and customer data, approve or reject the order.
    </documentation>
    <ioSpecification>
    <dataInput id="approveOrder-input1" structureDefinitionRef="tns:customerStructure" optional="false"/>
    <dataInput id="approveOrder-input2" structureDefinitionRef="tns:orderStructure" optional="false"/>
    <dataOutput id="approveOrder-output" structureDefinitionRef="tns:resultStructure"/>
    <inputSet id="approveOrder-is">
    <dataInputRefs>aproveOrder-input1</dataInputRefs>
    <dataInputRefs>aproveOrder-input2</dataInputRefs>
    <outputSetRefs>approveOrder-os</outputSetRefs>
    </inputSet>
    <outputSet id="approveOrder-os">
    <dataOutputRefs>aproveOrder-output</dataOutputRefs>
    <inputSetRefs>approveOrder-is</inputSetRefs>
    </outputSet>
    </ioSpecification>
    <performer name="Regional Manager" id="regionalManager"/>
    <potentialOwner>
    <peopleAssignmentPeopleGroup definition="regionalManagers">
    <parameter parameter="city">
    <formalExpression>getDataInput('approveOrder-input1')/address/city</formalExpression>
    </parameter>
    <parameter parameter="country">
    <formalExpression>getDataInput('approveOrder-input1')/address/country</formalExpression>
    </parameter>
    </peopleAssignmentPeopleGroup>
    </potentialOwner>
    <rendering>
    <documentation>HTML Rendering</documentation>
    <html xmlns="<a href="http://w3c.org/html">http://w3c.org/html</a>">
    <h1>Approve Order</h1>
    </html>
    </rendering>
    </globalUserTask>

    Comments:
    From: trickovic created: Tue, 7 Apr 2009 04:03:59 -0500 (CDT)
    As per 4/6 BPMN 2.0 meeting: Defer <a href="http://www.osoa.org/jira/browse/BPMN-467" title="Global Task should have performer, Call Activity should have capability to overwrite performer">BPMN-467</a>

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Change the MM relationship in GlobalTask from Performer to ResourceRole (ex ActivityResource, see issue 408) and rename the relationship from "performers" to
    "resources".
    1. Change Figure 10.42 to reflect this change
    2. Change the sentence below Figure 10.42 to the following content: "The Global Task inherits the attributes and model associations of Callable Element (see Table
    8.30). Table 10.XX presents the additional model associations of the GlobalTask:"
    3. Create a new table:
    resources: ResourceRole [0..*] => Defines the resource that will perform or will be responsible for the GlobalTask. In the case where the CallableElement that
    references this GlobalTask defines its own resources, they will override the ones defined here.
    (b) Add the following sentence to section 10.2.6 CallAcivity: "When the CallActivity defines one or more ResourceRole elements, the elements defined by the
    CallableElement are ignored and the elements defined in the CallActivity are used instead."
    (c) Change Table 10.131 - GlobalTask XML schema: replace "performer" with "resource".
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Aliases for imported definitions

  • Key: BPMN2-182
  • Legacy Issue Number: 14740
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Filed for Martin and Steve, based on choreograph discussions. When importing definitions, names of imported elements might not be suitable for the application of the importing definitions. The importing definitions should be able to assign aliases to the imported elements for use within the importing definitions.

    -------------------------------------------------------------------------------------------------------------------
    Proposal to review: [Suzette Samoojh - March 18, 2009]
    -------------------------------------------------------------------------------------------------------------------

    Assumption: "Aliasing" is required when you need to use an existing element, but wish to label it differently based on a usage context.
    Two known use-cases:

    • A Participant references a Role (or Entity) and wishes to apply a name that is different from the Role (or Entity) name.
    • A CallActivity references a CallableElement and wishes to show a name that is different from the name of the CallableElement.

    Proposal: Use existing 'name' attributes to achieve this.

    • Participant.name: If specified, serves as the 'alias' for the referenced Role or Entity. If unspecified, the original name of the Role or Entity is used.
    • CallActivity.name [inherited from FlowElement]: Ditto
      No MM changes needed. Just spec text.

    If anyone has an example that the above does not satisfy, please post it.
    [Note that a concrete example then means we will tackle this issue in a samples-driven manner].

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue cannot be fixed in this FTF.
    Disposition: Closed, Out Of Scope

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 10.2 Activities: Move User Task Instance Attributes to the higher level Activity element

  • Key: BPMN2-181
  • Legacy Issue Number: 14739
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Since all activities have performers and priorities. it makes sense to be able to use the actual performer or priority of any activity in the definition of any other activity. E.g., the performer of this activity cannot be the same as that activity. Performers can do the work as in User Tasks, or just be stakeholders or authorizers, etc. for any activity (including sub-processes). Right now only User Activities have these instance attributes. Moving the attributes to the Activity level would allow other activities this capability.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    These instance attributes are defined for User Tasks only, as they are needed for different human interaction scenarios.
    For other task types, e.g. Receive Task, Send Task, Service Task, Business Rule Task the value of having these instance attributes is not clear. E.g. It is not clear what
    would be the Actual Owner of a Receive Task or a Send Task.
    The proposal is to close this issue with no changes to the specification.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

[Section 10.2.3] Editorial

  • Key: BPMN2-189
  • Legacy Issue Number: 14750
  • Status: closed  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    [OMG 14750] [Section 10.2.3] Editorial: protocol attribute on the transaction subprocess class seems to have a wrong description - TransactionMethod values not explained
    This is the description Transaction->protocol attribute in 0.9.2 (page 156):

    The elements that make up the internal Sub-Process flow.
    This association is only applicable when the XSD Interchange is used. In the case
    of the XMI interchange, this association is inherited from the
    FlowElementsContainer class.

    Also, the TransactionMethod values are not fully explained. I can infer compensate, but I don't understand Store or Image.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Clarification: Attribute "protocol" is not needed as Transaction Sub-Process has attribute "flowElements" inherited from class Sub-Process.
    Proposal for 14335 resolves the second part of the issue.
    The proposal is to make the following changes in Beta 1:
    (1) Section 10.2.5
    Table 10.21: Remove attribute "protocol" (the complete row).
    (2) Update the XSD, so that Transaction inherits from SubProcess as stated in the specification text and MM:
    Add
    <xsd:complexType name="tTransaction">
    <xsd:complexContent>
    <xsd:extension base="tSubProcess"/>
    ...
    </xsd:complexContent>
    </xsd:complexType>
    instead of
    <xsd:complexType name="tTransaction">
    <xsd:complexContent>
    <xsd:extension base="tActivity"/>
    ...
    </xsd:complexContent>
    </xsd:complexType>
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

[Section 10.6] Editorial: We need more explicit descriptions of Compensation behaviour regarding scopes

  • Key: BPMN2-188
  • Legacy Issue Number: 14749
  • Status: closed  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    I believe we need to be more clear/explicit when describing several aspects of compensations. I base this on 0.9.2

    • We should made clear on each case what context is used in compensation. This is a refinement of the snapshot concept, but it needs clarification in this cases:
      • Boundary event handlers: it only mention "black-box" compensation, when it should clearly state that the current state is used.
      • inline event sub-processes: they mention the snapshot when the process is completed, but there is no mention to the case when the compensation is triggered while the subprocess is still running. Also it should be described that the parent scope used in the compensation is the current one, even when the compensated subprocess uses the snapshot context.
  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The assumption made when reporting this issues was that a compensation can compensate a running activity, which is wrong, only completed activities can be
    compensated. So this issue is invalid.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add business-level presentation attributes to user task: subject and description

  • Key: BPMN2-180
  • Legacy Issue Number: 14736
  • Status: closed  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    From the human interactions example:
    Need to add business-level presentation attributes known from BPEL4People, namely subject and description. This should include the ability to specify presentation parameters - needs discussion. Without these, the user task capability is not rich enough for serious direct execution, but will always require mapping to and enrichment in BPEL4People.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Rather than copying the various BPEL4People elements to the BPMN spec, we should modify the BPMN spec as follows:
    Text in section "10.2.4 Human Interactions"
    Current:
    The User Task inherits the attributes and model associations of Activity (see Table 10.3). Table 10.13 presents the additional attributes and model associations of the
    User Task.
    New:
    The User Task inherits the attributes and model associations of Activity (see Table 10.3). Table 10.13 presents the additional attributes and model associations of the
    User Task. If implementations extend these attributes (e.g., to introduce subjects or descriptions with presentation parameters), they SHOULD use attributes defined
    by the OASIS WS-HumanTask specification.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Data Association should be specialized from Association

  • Key: BPMN2-179
  • Legacy Issue Number: 14735
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Association has a source and target of BaseElement which should inherit
    to DataAssociation, instead of being defined again on Data Association.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close, no change. The issue requests a metamodel simplification that would be confusing and would not provide sufficient benefits.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Editorial: Rename FlowElement::categoryValue to ::categoryValueRef

  • Key: BPMN2-175
  • Legacy Issue Number: 14731
  • Status: closed  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    As per discussion in examples working session on 2009.03.26

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Replace Figure 8.15. See the change is circled in red in
    (MM_Group.jpg)
    (b) Replace Figure 8.23 to include the CategoryValue element and the association to Flow Element
    (c) Update Table 8.45. Add attribute "categoryValueRef" with description "A reference to the category values that are associated with this flow element".
    (d) Update the XSD snippet (Table 8.66) to rename "categoryValue" to "categoryValueRef".
    No change needed to the actual XSD. It already contains the correct name.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Data Assignment 'from' and 'to' should be formal expressions

  • Key: BPMN2-174
  • Legacy Issue Number: 14728
  • Status: closed  
  • Source: Oracle ( Ralf Mueller)
  • Summary:

    In Data Assignment, the 'from' and 'to' attributes are Object. The Assignment class should be modified as following
    1. Remove 'language' attribute
    2. Data Type of 'from' and 'to' is FormalExpression

    Apart from that, the attribute 'evaluatesToTypeRef' in FormalExpression class should be optional

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue has the same resolution as OMG 14701 (14701)
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

[XSD] Documentation and ScriptTask (and probably expressions) should be stored as CData elements and not String attribut

  • Key: BPMN2-177
  • Legacy Issue Number: 14733
  • Status: closed  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    Documentation and the scripts are formatted text, we should keep the format (spaces, tabs) that the user defined.

    Storing formatted text as string attributes makes it impossible to do so, since it turns the attributes quite big and looses the format.

    It would be better if we store any formatted text as a CDATA element, so we can easily keep the format.

    Proposal: change the XSD for documentation, script task and formal expressions to use a CDATA element instead of a string attribute.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The issue was opened against an older (pre-Beta) version of the BPMN XSD. The problems described no longer occur.
    Examples of how text can store any formatted text as a CDATA element can be seen here:
    testXMLFor_BPMNFTF-424b.xml
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Lanes should be described in Process section

  • Key: BPMN2-178
  • Legacy Issue Number: 14734
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Lanes are pat of process modeling and should be described in the Process section. They
    are currently documented in the Collaboration chapter, which happens to use process models.

    Comments:
    From: wstephe created: Tue, 14 Apr 2009 10:30:41 -0500 (CDT)
    The resolution to this issue was applied in V0.9.9.5

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue was mistakenly added to the list. The issue had already been fixed.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 10.4.5 Handling Events: When does the interrupting Event Sub-Process cancel its Parent?

  • Key: BPMN2-169
  • Legacy Issue Number: 14723
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    In this section there is the following text: "They execute synchronously and after their completion, the hosting Activity is immediately canceled."

    This means that the parent process will continue work while the Event SP is active, which could be a long time. If the triggering Event is an error, this doesn't make much sense. Note that the Execution Semantics section doesn't specify when the parent activity is terminated.

    ------------------------------ Proposal ---------------- 2009-04-15 -------------------------------------

    Modify text so that it states that the activity of the parent Process is terminated when the interrupting Event SP is triggered

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) * Section 10.4.6, p.257
    Original: "They execute synchronously and after their completion, the hosting Activity is immediately terminated."
    Replace: "They interrupt normal execution of the parent Activity and after their completion, the parent Activity is immediately terminated."
    (b) * Section 10.4.6, p.257
    Original: "The same restrictions apply for boundary Events."
    Append: "The same restrictions apply for boundary Events. During execution of a non-interrupting Event Sub-Process, execution of the parent Activity continues as
    normal."
    (c) * Section 10.4.6, p.258
    Original: "Whenever the Event occurs, regardless of whether the Event is handled inline or on the boundary, the associated Activity is canceled."
    Replace: "Whenever the Event occurs, regardless of whether the Event is handled inline or on the boundary, the associated Activity is interrupted."
    (d) * Section 10.4.6, p.258
    Original: "If a boundary Error Event is present, Sequence Flow from that boundary Event is then followed."
    Append: "If a boundary Error Event is present, Sequence Flow from that boundary Event is then followed. The parent Activity is canceled after either the error handler
    completes or Sequence Flow from the boundary Event is followed."
    (e) * Section 14.2.2, p.392
    Original: Figure 14.2, missing addt'l states Failing and Terminating
    Replace: Figure 14.2, added states Failing and Terminating
    (f) * Section 14.2.2, p.393
    Original: N/A
    Append: below bullet "• If an Activity's execution ends without anomalies, the Activity's state changes to Completing. [...]" --> the following text: "• An Activity's
    execution is interrupted if an interrupting Event is raised (such as an Error) or if an interrupting Event Sub Process is initiated, In this case, the Activity's state changes to
    Failing (in case of an Error) or Terminating (in case any other interrupting Event). All nested activities that are not in Ready, Active or a final state (Completed,
    Compensated, Failed, etc.) and non-interrupting Event Sub-Processes are terminated. The data context of the Activity is preserved in case an interrupting Event Sub-
    Process is invoked. The data context is released after the Event Sub-Process reaches a final state."
    (g) * Section 14.4.4, p.404
    Original:
    "• A non-interrupting Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The non-interrupting Event
    Handler may only be initiated after the parent Activity is Running. More than one non-interrupting Event Handler may be initiated and they may be initiated at different
    times. There might be multiple instances of the non-interrupting Event Handler at a time.
    • An Event Sub-Process completes when all tokens have reached an End Event, like any other Sub-Process. If the parent Activity enters the state Completing, it
    remains in that state until all contained active Event Sub-Processes have completed. While the parent Activity is in that Completing, no new Event Sub-Processes can
    be initiated."
    Replace:
    "•An Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The Event Handler may only be initiated after
    the parent Activity is Running.
    • More than one non-interrupting Event Handler may be initiated and they may be initiated at different times. There might be multiple instances of the non-interrupting
    Event Handler at a time.
    • Only one interrupting Event Handler may be initiated for a given Event Definition within the context of the parent Activity. Once the interrupting Event Handler is
    started, the parent Activity is interrupted and no new Event Handlers can be initiated or started.An Event Sub-Process completes when all tokens have reached an End
    Event, like any other Sub-Process. If the parent Activity enters the state Completing, it remains in that state until all contained active Event Sub-Processes have
    completed. While the parent Activity is in that Completing, no new Event Sub-Processes can be initiated.
    • If an interrupting Event Sub-Process is started by an Error, then the parent Activity enters the state Failing and remains in this state until the interrupting Event Handler
    reaches a final state. During this time, the running Event Handler can access to the context of the parent Activity. However, no new Event Handlers may be started.
    • Similarly, if an interrupting Event Sub-Process is started by a Non Error (e.g., Escalation), then the parent Activity enters the state Terminating and remains in this
    state until the interrupting Event Handler reaches a final state. During this time, the running Event Handler can access to the context of the parent Activity. However, no
    new Event Handlers may be started."
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

TimerEventDefinition: clarification of the expected result of the timeCycle and timeDate expressions

  • Key: BPMN2-168
  • Legacy Issue Number: 14722
  • Status: closed  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    These attributes of the TimerEventDefinition are expressions, there is no mention of the result type. Also it would be useful to describe how this values are used (timeDate defines the next moment the time will trigger, while timeCycle defines an interval that is added to "now" to define the next moment).

    Another thing that is not described is the moment when theses expressions are evaluated. Intuitively I think it is in the moment after the trigger is executed, and for the first time, the moment it is activated.

    Following the BPEL mapping, the timeDate expression should return an XSD DateTime element and the timeCycle an XSD Interval (Period).

    I think it is necessary to clarify this in the execution semantics so people understand what type of behaviour is expected from this event.

    I can make the changes if necessary.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 10.4.5 Event Definitions
    Subsection Timer Event, Table 10.20 - TimerEventDefinition model associations
    > Change row: attribute timeDate
    Original
    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 attribute below—if the processType
    attribute of the Process is set to executable).
    Proposal
    If the Trigger is a Timer, then a timeDate MAY be entered. Timer attributes are mutually exclusive and if any of the other Timer attributes is set, timeDate MUST NOT
    be set (see attribute below—if the processType attribute of the Process is set to executable). The return type of the attribute timeDate MUST conform to the ISO8601
    format for date and time representations.
    > Change row: attribute timeCycle
    Original
    If the Trigger is a Timer, then a timeCycle MAY be entered. Timer attributes are mutually exclusive and if any of the other Timer attributes is set, timeCycle MUST
    NOT be set (see attribute below—if the processType attribute of the Process is set to executable).
    The return type of the attribute timeDate MUST conform to ISO-8601 interval format.
    Proposal
    If the Trigger is a Timer, then a timeCycle MAY be entered. Timer attributes are mutually exclusive and if any of the other Timer attributes is set, timeCycle MUST
    NOT be set (see attribute below—if the processType attribute of the Process is set to executable). The return type of the attribute timeCycle MUST conform to the
    ISO-8601 format for recurring time interval representations.
    > Append row: attribute timeDuration
    Original
    N/A
    Proposal
    Attribute Name
    timeDuration: Expression [0..1]
    Description/Usage
    If the Trigger is a Timer, then a timeDuration MAY be entered to specify a relative point in time. Timer attributes are mutually exclusive and if any of the other Timer
    attributes is set, timeDuration MUST NOT be set (see attribute below—if the processType attribute of the Process is set to executable). The return type of the
    attribute timeDuration MUST conform to the ISO-8601 format for time interval representations.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Correlation properties must have name and type (was dropped in 4/22 XSD and MM)

  • Key: BPMN2-167
  • Legacy Issue Number: 14721
  • Status: closed  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    ##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-493
    ##Original Info: (Severity: Significant - Nature: Revision)

    Correlation properties are specified by means of name and type, e.g., orderID of type integer, or customerName of type string. The properties may typically be specified by means of their name and type only, while retrievalExpressions are added only later, and modified independently. The latest version of the spec dropped name and type.

    Resolution proposal: Re-add correlationProperty::name and ::itemRef.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    UML Schema
    (a) – Add attributes as per XSD above/spec table changes below
    Specification text:
    – Figure 8.18 Correlation Class diagram
    Show the following added attributes in their compartments:
    (b) CorrelationKey::name
    (c) CorrelationProperty::name
    (d) CorrelationProperty::type
    – Table 8.32 CorrelationKey model associations
    Add the following row:
    (e) name[0..1] | String | Specifies the name of the correlation key
    – Table 8.33 CorrelationProperty model associations
    Add the following rows:
    (f) name[0..1] | String | Specifies the name of the correlation property
    (g) type[0..1]='String' | ItemDefinition | Specifies the type of the correlation property
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

tActivityResource::resourceRef should be optional

  • Key: BPMN2-166
  • Legacy Issue Number: 14720
  • Status: closed  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    ##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-494
    ##Original Info: (Severity: Significant - Nature: Revision)

    tActivityResource::resourceRef is a required attribute, but should be optional - in case the resource is resolved via a ResourceAssigmnentExpression there won't be any statically assigned resourceRef (except for a dummy, which is how I resolved the problem in the example).

    <performer resourceRef="dummy">
    <!-Issue: If specified via an expression, a resourceRef is not needed, i.e., the attribute must not be required.->
    <resourceAssignmentExpression>
    <formalExpression>getInputData()/resource</formalExpression>
    </resourceAssignmentExpression>
    </performer>

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Replace Figure 10.7 (pg 161)
    Update the UML metamodel, giving the ActivityResource.resourceRef association a multiplicity of [0..1]
    (b) Update Table 10.5 (pg 162)
    Specify a multiplicity of [0...1] for the resourceRef association
    New description for resourceRef: The Resource that is associated with the Activity. Should not be specified when a resourceAssignmentExpression is provided.
    Append to description for resourceAssignmentExpression: Should not be specified when a resourceRef is provided.
    Append to description for resourceParameterBindings: Is only applicable if a resourceRef is specified.
    (c) Update Table 10.30 (pg 175)
    Replacement XSD snippet
    <xsd:complexType name="tActivityResource">
    <xsd:complexContent>
    <xsd:extension base="tBaseElement">
    <xsd:choice>
    <xsd:sequence>
    <xsd:element name="resourceRef" type="xsd:QName"/>
    <xsd:element ref="resourceParameterBinding" minOccurs="0" maxOccurs="unbounded"/>
    </xsd:sequence>
    <xsd:element ref="resourceAssignmentExpression" minOccurs="0" maxOccurs="1"/>
    </xsd:choice>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>
    [Note: a consequence of formalizing in the XSD as a 'choice' is that the resourceRef is now an element instead of an attribute]
    (d) Update Table 10.19 (pgs 181-182)
    Replace the 'resourceRef' attributes with equivalent 'resourceRef' elements.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.3.1 Data Inputs and Outputs: Schema change: change minOccurs of inputSet for ioSpecification from 0 to 1

  • Key: BPMN2-165
  • Legacy Issue Number: 14719
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The spec says that there must be one InputSet for an ioSpecification. The schema has the minOcurrs at 0. The schema should be changed so that minOccurs is 1.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Spec update: Update the XSD snippet for tInputOutputSpecification (table 10.67) in the spec
    (a) <xsd:element ref="inputSet" minOccurs="1" maxOccurs="unbounded"/>
    (b) <xsd:element ref="outputSet" minOccurs="1" maxOccurs="unbounded"/>
    Note that the actual XSD is already correct. Only the snippet in the spec needs updating.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Set the name attribute of DataInputs and DataOutputs to optional

  • Key: BPMN2-172
  • Legacy Issue Number: 14726
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Names are not require for all DataInputs and DataOutputs. Names would be used mainly for the ones that are shown graphically on the diagram.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Change the name attribute for both DataInput and DataOutput to be optional.
    (a) Table 10.53 DataInput attributes and model associations, name attribute row, first column: change "string" to "string [0..1]
    (b) Table 10.54 DataOutput attributes and model associations, name attribute row, first column: change "string" to "string [0..1]
    (c) Table 10.65 DataInput XML schema: Change "attribute name="name" type="xsd:string"" to "attribute name="name" type="xsd:string" use="optional""
    (c) Table 10.70 DataOutput XML schema: Change "attribute name="name" type="xsd:string"" to "attribute name="name" type="xsd:string" use="optional""
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

V0.9.9.1: Display of Messages and Associations in Choreography

  • Key: BPMN2-171
  • Legacy Issue Number: 14725
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    This was generated from the example for <a href="http://www.osoa.org/jira/browse/BPMN-329" title="Provide example: Process within Collaboration">BPMN-329</a>.
    The current examples of Choreography show Messages connected to ChoreographyTasks through Associations. However, there are additional semantics to these connections. The semantics could be derived from the ChoreographyTask definiition, but we should investigate whether the display of the Message on the diagram requires any additional MM changes or whether this is purely a diagram display issue.
    Section 12, Beta 1 Spec

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution will clarify the use of the Message icon with Choreography Tasks.
    (a) Add a new paragraph below Figure 12.11: add new paragraph after the second paragraph (starting with "The three (3) bands...":
    "The Message sent by either one or both of the Participants of the Choreography Task can be displayed (see Figure 12.10, above). The Message icon is shown
    tethered to the Participant that is the sender of the Message."
    (b) After the new paragraph (item a), add a specification bullet (diamond bullet): "If the Message is the initiating Message of the Choreography Task, then the Message
    icon MUST be unfilled."
    (c) After the new bullet (item b), add a specification bullet (diamond bullet): "if the Message is a return Message for the Choreography Task, then the Message icon
    MUST have a light fill."
    (d) After the new bullet (item c), add a new paragraph: "Note that Messages can be tethered to a Call Choreography that references a GlobalChoreographyTask, but
    cannot be used for Sub-Choreographies or Call Choreography that references another Choreography."
    (e) Delete Figure 8.33
    (f) Delete the paragraph above Figure 8.33
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

XSD DataAssociation should own source and target refs and mistake in text spec

  • Key: BPMN2-164
  • Legacy Issue Number: 14718
  • Status: closed  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    [OMG 14718] XSD DataAssociation should own source and target refs and mistake in text spec

    ##Source: Oracle (Mariano Benitez, mariano.benitez@oracle.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-501
    ##Original Info: (Severity: Significant - Nature: Revision)

    According to the spec text, DataInputAssociation and DataOutputAssociation do not define any attribute.

    In the XSD they both own define sourceRef and TargetRef.

    These elements should be part of the parent class. (there is no problem in moving them up since both definitions are similar (cardinality and types).

    Also:

    In page 202 of Beta 1 it says:
    "The DataInputAssociation element inherits the attributes and model associations of FlowElement (see Table 10-62), but does not contain any additional attributes or model associations."

    But it should say DataAssociation.

    Comments:
    From: mariano.benitez created: Tue, 5 May 2009 09:05:19 -0500 (CDT)
    Proposal for text fix, just replace flowelement with dataassociation.

    From: mariano.benitez created: Tue, 5 May 2009 09:06:35 -0500 (CDT)
    Steve, I just attached the fix for the text issue, can you apply it?

    Regarding the MM (XSD) change, it's not that critical to add it, but it could help.

    From: trickovic created: Wed, 6 May 2009 04:27:47 -0500 (CDT)
    As per 5/4 BPMN team meeting - the issue is valid but to be deferred.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 10.3.1
    For both DataInputAssociation and DataOutputAssociation paragraphs, replace FlowElement (see Table 10.58), with DataAssociation (see Table 10.57).
    In XML Schemas:
    Table 10.64 DataAssociation XML Schema, add the following elements:
    <xsd:element name="sourceRef" type="xsd:QName" minOccurs="1" maxOccurs="unbounded"/>
    <xsd:element name="targetRef" type="xsd:QName" minOccurs="1" maxOccurs="1"/>
    Table 10.66 DataInputAssociation XML Schema and Table 10.71 - DataOutputAssociation XML schema, remove the following:
    <xsd:sequence>
    <xsd:element name="sourceRef" type="xsd:IDREF" minOccurs="1" maxOccurs="unbounded"/>
    <xsd:element name="targetRef" type="xsd:IDREF" minOccurs="1" maxOccurs="1"/>
    </xsd:sequence>
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

DataAssociations: How do we support literals?

  • Key: BPMN2-163
  • Legacy Issue Number: 14717
  • Status: closed  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    DataAssociations and Assigments correctly allow mapping between data elements.

    Now, there is no way to do a simple mapping of a literal to a data input.

    An assignment could be used to solve the problem, but then you are forced to include a dummy sourceRef to fullfil the requirement of at least one source ref.

    A simple solution would be to allow 0 zero source refs, and keeping the restriction of the scope of the assignment to the souce refs.

    Comments:
    From: trickovic created: Wed, 6 May 2009 04:28:07 -0500 (CDT)
    As per 5/4 BPMN team meeting - the issue is valid but to be deferred.

    From: mariano.benitez created: Wed, 2 Sep 2009 15:19:27 -0500 (CDT)
    testing comments... sorry

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Update the UML metamodel, changing the multiplicity of DataAssociation.sourceRef from 1..* to 0..*
    Replace Figure 10.61 (pg 230)
    (b) Update Table 10.57 (pg 231)
    Change the multiplicity of the sourceRef association to 0..*
    (c) Update Tables 10.64, 10.66, 10.71 (schema snippets) to match the updated metamodel
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Metaelement missing for DI to show connection between ChoreographyActivity to Message

  • Key: BPMN2-162
  • Legacy Issue Number: 14716
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The metamodel does not have a element for DI to use for connecting
    ChoreographyActivity and Message (derivable from ChoreographyActivity to
    Message Flow to Message). Associations should not be used for links
    that are derivable from the semantic metamodel.

    Comments:
    From: trickovic created: Wed, 6 May 2009 03:38:35 -0500 (CDT)
    As per 5/4 BPMN team meeting - the issue to be deferred.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue is outdated given the rewrite of Chapter 13 (Diagram Interchange) under issue 14423
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 10.4 Events: Statement "Signals are triggers generated in the Pool they are published" needs clarificati

  • Key: BPMN2-170
  • Legacy Issue Number: 14724
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    OMG 14724] Beta 1: Section 10.4 Events: Statement "Signals are triggers generated in the Pool they are published" needs clarification

    ##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-486
    ##Original Info: (Severity: Minor - Nature: Enhancement)

    in the Concepts sub-section there is the following statement: "Signals are triggers generated in the Pool they are published."
    This is not clear. It implies that Signals are limited to being sent and received in the same Process, which is not true.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 10.4.1 Concepts
    2nd paragraph
    Original
    They typically describe B2B communication. When Messages need to reach a specific Process instance, correlation is used to identify the particular instance. Signals
    are triggers generated in the Pool they are published.
    Proposal
    They are generally used for B2B communication between different Processes in different Pools.. When Messages need to reach a specific Process instance, correlation
    is used to identify the particular instance. Signals are triggers generated in the Pool they are published in. They are typically used for broadcast communication within
    and across Processes, across Pools, and between Business Process Diagrams.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

XSD: Data Association sourceRef and targetRef should be of type QName

  • Key: BPMN2-173
  • Legacy Issue Number: 14727
  • Status: closed  
  • Source: Oracle ( Ralf Mueller)
  • Summary:

    Consider a Call Activity that invokes another Process:
    <callActivity id="CallActivity"
    calledElement="tns:CalledProcessNotServiceEnabled">
    <dataInputAssociation>
    <sourceRef>MyOrder</sourceRef>
    <targetRef>Order</targetRef>
    </dataInputAssociation>
    <dataOutputAssociation>
    <sourceRef>Result</sourceRef>
    <targetRef>MyResult</targetRef>
    </dataOutputAssociation>
    </callActivity>
    In above sample, the targetRef of the data input association refers to a DataInput object of process 'CalledProcessNotServiceEnabled'
    and the sourceRef of the data output association refers to a DataOutput object of the called process.

    The proposal is to modify the XML-Schema type of sourceRef and targetRef from xsd:IDREF to xsd:QName to allow references to
    processes and global tasks data input/output that appear in potentially separate BPMN definitions.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The XML-Schema and the tables 10.66 and 10.71 were not consistent. The proper definition is that sourceRef and targetRef are xsd:IDREF. Technically this is a
    close, no change but we are fixing the inconsistency here.
    The XML-Schema for sourceRef and targetRef to be changed from xsd:QName to xsd:IDREF.
    Tables 10.66, 10.71 are correct.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Section 13.2.4 ChoreographyActivityShape: Add Choreography Activity Bands to DI model

  • Key: BPMN2-161
  • Legacy Issue Number: 14715
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The current DI model doesn't specify the Participant Bands of the shape and should be added. These bands can vary in shading and Association connections to the shape (of a Message) are dependent on the sender of the Message (i.e., the Participant of the appropriate Band).

    Comments:
    From: trickovic created: Wed, 6 May 2009 03:41:57 -0500 (CDT)
    As per 5/4 BPMN team meeting - the issue to be deferred.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue is outdated given the rewrite of Chapter 13 (Diagram Interchange) under issue 14423
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

logic error in the PDF document

  • Key: BPMN2-98
  • Legacy Issue Number: 14564
  • Status: closed  
  • Source: Dresden University of Technology ( Frank Toeppel)
  • Summary:

    maybe I’m wrong, but it seems there’s a logic error in the PDF document mentioned above:

    • Figure 12.36 shows a Choreography starting with communication from A (initiator) to B. Depending on message content based decision next message will be sent from A to B (decision YES) or from A to C (decision NO).
    • Comparing that to the corresponding Collaboration in Figure 12.37 I detected a mismatch, within Pool A the gateway acts inverse: If decision YES message M3 will be sent from A to C, and if decision NO message will be sent from A to B
    • Looks like content of pool A should be adapted (decision YES should result in message from A to B)

    Furthermore there seems to be an offset to Figure indices listed in some chapters vs. the real Figure numbers:

    • Check chapter 10.2.8 (Loop Characteristics in Process Diagrams)
    • Scroll to page 169 (PDF document page 199), chapter Standard Loop Characteristics
    • You will find a link to Figure 10.42 and 10.43 (see Figure 10.42 and Figure 10.43)
    • Corresponding figures instead are 10.43 and 10.44
    • This offset stuff starts somewhere before in the document, maybe an additional picture has been added
  • Reported: BPMN 2.0b1 — Thu, 15 Oct 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Replace Figure 12.36 with a figure that has the positioning of the Participants in the Participant Bands more consistent. See here:
    (Replacement+for+Figure+12.36.jpg)
    (b) Replace Figure 12.37 with a figure that sequence of activities are matching those of Figure 12.36. See here:
    (10571_Replacement+for+Figure+12.37.jpg)
    (c) Section 10.2.8 Loop Characteristics, Sub-Section Standard Loop Characteristics, page 169 (199 pdf), first bullet in section: replace "Figure 10.42" with "Figure
    10.43" and replace "Figure 10.43" with "Figure 10.44."
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Target namespace mismatch between the XML Schemas in the spec (PDF) and the XML Schemas files (XSD)

  • Key: BPMN2-97
  • Legacy Issue Number: 14559
  • Status: closed  
  • Source: International Business Machines ( Mr. Olivier Modica)
  • Summary:

    There is currently a mismatch between the target namespace of the XML Schemas in the spec (PDF) and the XML Schemas files (XSD) themselves. This applies to Beta 1.

    In the PDF specification that are several instances where the target namespace for the XML Schemas is defined as “http://www.omg.org/bpmn20”:

    • Table 8.2 (page 44)
    • Table 8.16 (page 53)
    • Table 10.19 (page 150)

    However the latest available XML Schemas (bmi/09-05-05) have the target namespace set to “http://schema.omg.org/spec/BPMN/2.0”.

    If the XML Schemas are correct then the specification should reflect the same target namespace.

  • Reported: BPMN 2.0b1 — Tue, 13 Oct 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Table 8.2, page 44 (74 pdf), first row, second column: change "http://www.omg.org/bpmn20" to "http://schema.omg.org/spec/BPMN/2.0"
    (b) Table 8.16, page 53 (83 pdf), forth line: change "http://www.omg.org/bpmn20" to "http://schema.omg.org/spec/BPMN/2.0"
    (c) Table 8.16, page 53 (83 pdf), fifth line: change "http://www.omg.org/bpmn20" to "http://schema.omg.org/spec/BPMN/2.0"
    (d) Table 8.16, page 53 (83 pdf), 115h line: change "http://www.omg.org/bpmn20" to "http://schema.omg.org/spec/BPMN/2.0"
    (e) Table 10.19, page 150 (180 pdf), 115h line: change "http://www.omg.org/bpmn20" to "http://schema.omg.org/spec/BPMN/2.0"
    Note on 2010-04-26:
    The FTF acknowldges the proposed namespace does not follow OMG guidelines for namespace conventions. The final namespaces will be:

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification on relationship between MEP and Choreography Task in BPMN2

  • Key: BPMN2-95
  • Legacy Issue Number: 14548
  • Status: closed  
  • Source: Red Hat ( Gary Brown)
  • Summary:

    PDF page 337, page 307:
    "A single MEP is defined as a BPMN Choreography Task (see page 350). Thus, a Choreography defines the order
    in which Choreography Tasks occur. Choreography Sub-Processes allow the composition/decomposition of
    Choreographies."

    If the MEP has a request, response and multiple faults how will the choreography identify which subsequent path based on a decision relates to each response.

    Would propose changing wording to "A single MEP can be defined ..." - allowing an MEP to be defined across separate Choreography Tasks, enabling the decision point and relevant paths based on each response type to be explicitly defined in the choreography. However this may require some additional mechanism to correlate the separate choreography tasks as belonging to the same MEP.

  • Reported: BPMN 2.0b1 — Fri, 9 Oct 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    PDF page 337, page 307:
    Change: "A single MEP is defined as a BPMN Choreography Task"
    To: "A single MEP can be defined as a BPMN Choreography Task"
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Initiating message flow for ChoreographyTask

  • Key: BPMN2-94
  • Legacy Issue Number: 14546
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In BPMN Core Structure, Common Elements,
    Message, second figure, text underneath
    refers to a list of messages for a
    choreography task, but the association
    between ChoreographyTask and MessageFlow
    is not ordered. Or the initial message
    flow of a Choreography Task could be
    identified by a new association if it is not
    intended to order all the messages.

  • Reported: BPMN 2.0b1 — Thu, 8 Oct 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Choreography Tasks can have at most two message flows, with one participant per message flow, see resolution of issue 14890. The initiating message flow can be
    identified from the initiating participant
    Under Figure 8.29 (A non-initiating Message), replace the bullet sentence with "Any Message sent by the non-initiating Participant or SubChoreography MUST be
    shaded with a light fill.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 160, Figure 10-6 vs. Table 10-3. The "property" class is not depicted in the class diagram Figure 10-6

  • Key: BPMN2-92
  • Legacy Issue Number: 14542
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Page 160, Figure 10-6 vs. Table 10-3. The "property" class is not depicted in the class diagram (Figure 10-6) but listed in the attribute (Table10-3).

  • Reported: BPMN 2.0b1 — Thu, 8 Oct 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Figure 10.6 will be updated to include the Property class. The updated figure is shown here:
    (10562_Update+to+Figure+10.6.jpg)
    .
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 161, Table 10-3, Error in attribute name. "resources" should be "activityResource"

  • Key: BPMN2-91
  • Legacy Issue Number: 14541
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Page 161, Table 10-3, Error in attribute name. "resources" should be "activityResource"

  • Reported: BPMN 2.0b1 — Thu, 8 Oct 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14710 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 161, Table 10-3, Issues regarding properties in the Activity attribute table

  • Key: BPMN2-93
  • Legacy Issue Number: 14543
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Page 161, Table 10-3, Issues regrading properties: 1)The text describes properties as being "local" to the activity, yet contibues to mentione a deliation with the activity name as a prefix. If it is local why would we need the activity name as a prefix?
    2) Although I uderstand using the name of the peorperty for presentation in a tool interface, we do not have a guarantee that the name will be unique.

  • Reported: BPMN 2.0b1 — Thu, 8 Oct 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Table 10.3, description for the Properties attribute, page 129 (159 pdf), second sentence: Change " "local" to" to "contained within"
    (b) Table 10.3, description for the Properties attribute, page 129 (159 pdf): delete third sentence
    (c) Table 10.1, description for the Properties attribute, page 125 (155 pdf), second sentence: Change " "local" to" to "contained within"
    (d) Table 10.1, description for the Properties attribute, page 129 (159 pdf): delete 4th and 5th sentence
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Allow Choreography Task to have more than 2 Participants

  • Key: BPMN2-96
  • Legacy Issue Number: 14551
  • Status: closed  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    A Choreography Task now can have only two Participants. But there are situations where one Participant may send the same message to more than one other Participant. Multiple Choreography Tasks would be needed to do this, where it could be done with one if this change was made

  • Reported: BPMN 2.0b1 — Thu, 8 Oct 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The available use cases for this issue are not strong enough to change the specification.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

The case of some attribute name is not consistent.

  • Key: BPMN2-3
  • Legacy Issue Number: 14244
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jun 08, 2009

    It seems that lower case is the standard, but some attributes like
    ReceiveTask.Instanciate, UserTask.Imlementation for example, but there are
    other attributes as well.

    The same comment applies to type name string vs String, Boolean vs
    Boolean, etc…

    Comment 1 by hudoneric, Jun 09, 2009

    The case of the gatewayDirection on p.111 is lower case. The values of other
    enumerations in the document are capitalized.

    Comment 2 by hudoneric, Jun 10, 2009

    Same thing for multi-instance behavior on p.203.

    Comment 3 by hudoneric, Jun 10, 2009

    The case of the enumeration UserTaskImplementation is not the same in the
    specification (p. 179) and the schema (p. 181).

    Comment 4 by hudoneric, Jun 10, 2009

    The case of the methodon p.192is lower case. The values of other
    enumerations in the document are capitalized.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Table 10.10, page 140 (170 pdf), second row, first column: Change "Instantiate:" to "instantiate:"
    (b) Table 10.13, page 146 (176 pdf), first row, first column: Change "Implementation:" to "implementation:"
    (c) Table 10.2, page 135 (165 pdf), first row, first column: Change "String:" to "string:"
    (d) Table 8.47, page 80 (110 pdf), first row, first column: Change "unspecified | converging | diverging |mixed" to "Unspecified | Converging | Diverging |Mixed"
    (e) Table 8.47, page 80 (110 pdf), first row, second column: Change "unspecified" to "Unspecified", "converging" to "Converging ", "diverging" to "Diverging", and
    "mixed" to "Mixed"
    (f) Figure 8.25, page 79 (109 pdf): Capitalize the items within the GatewayDirection enumeration.
    (g) Table 10.26, page 172 (202 pdf), second row on page, first column: Change "none | one | all | complex" to "None | One | All | Complex"
    (h) Table 10.26, page 172 (202 pdf), second row on page, second column: Change "none" to "None", "one" to "One", "all" to "All ", and "complex" to "Complex"
    Table 10.13, page 146 (176 pdf), first row, first column: Change all types of UserTaskImplementation from uppercase to lowercase
    Note that some of the changes to the case of key words such as string, boolean, and integer or the case of enumeration values were not documented.
    Disposition: Resolved
    Voting Record: 22 Yes, 0 No, 3 Abstain (Votes)
    OMG Issue No: 14246
    Title: Page 227 Table 10-56 the attributes optionalOutput and whileExecutingOuput are wrongly typed DataInput
    Source: Trisotech (Denis Gagne dgagne@trisotech.com)
    Severity: Significant
    Summary: (

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Typos

  • Key: BPMN2-2
  • Legacy Issue Number: 14243
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    BPMN 2 FTF typos

    Issue 13: Page 79, Table 8-8 Typo extensionAttributeDefinitions is typed ExtensionDefinition

    Reported by dga...@trisotech.com, Jun 08, 2009

    On p.79, Table 8-8 the attribute extensionAttributeDefinitions is typed
    ExtensionDefinition, it should be typed ExtensionAttributeDefinition.

    ==========================================================================

    Issue 30: Page 141, Table 8-81 Typo in type definition "s" added

    callableElements should be of type CallableElement and not CallableElements

    ==================================================================

    Issue 32: Page 283, Figure 10-90 Typo "CancelEventDefinition" should be reploaced by "TerminateEventDefinition"

    Reported by hudoneric, Jun 25, 2009

    On p. 283 of the specification, we can read CancelEventDefinition element
    inherits...

    Since a TerminateEventDefinition exists, I assume that this is what should
    go there.

    =========================================================================

    Issue 62 : Page 307, section 10.5.6 Copy/paste Typo "Start Event" should be "Event Gateway"

    Comment 1 by dga...@trisotech.com, Jul 10, 2009
    In second structural specification Start Event should be replaced by Event
    Gateway.

    =================================================================

    Issue 63: Page 316, section 10.7 Copy/Paste Typo "Pool" should be replaced by "Lane"

    In second structural specificatio Pool should be replaced by Lane

    =========================================================================

    Issue 74: Page 049, Table 7-1, Typo word "is' extra

    For the element "Pool" the second sentence of the descriptive text is: "It
    is also acts as a “swimlane” and a graphical container for partitioning a
    set of Activities from other Pools, usually in the context of B2B
    situations."
    The word "is" at the beginning of the sentence should be deleted.

    =========================================================================

    Issue 75: Page 052, Table 7-2, Typo missing "a" before Process

    Reported by asir...@trisotech.com, Jul 01, 2009

    For element "Activity" the first sentence is: "An Activity is a generic
    term for work that company performs (see page 159) in Process."

    The word "a" shoud be added before the word "process".

    ===================================================================

    Issue 76: Page 053, Table 7-2, Typo missing "or" in sentence

    Reported by asir...@trisotech.com, Jul 01, 2009

    For element "Choreography Task", the last sentence of the descption
    is:"There are two (2) more Participant Bands and one Task Name Band."

    The word "or" shoud be added after the "two (2)".

    Comment 1 by dga...@trisotech.com, Jul 06, 2009
    For element "Choreography Task", the last sentence of the descption
    is:"There are two (2) more Participant Bands and one Task Name Band."

    The word "or" shoud be added after the "two (2)".

    Summary: Page 053, Table 7-2, Typo missing "or" in sentence
    Labels: Validated
    Comment 2 by asir...@trisotech.com, Jul 07, 2009
    Same apply to last sentence of page 351.

    Comment 3 by asir...@trisotech.com, Jul 07, 2009
    Also apply to Page 356, Section 12.4.2, last sentence of second paragraph.

    ====================================================================

    Issue 80: Page 087, Typo "a" should be "are"

    Reported by asir...@trisotech.com, Jul 01, 2009

    In sub-section "Common Artifact Definitions", the sentence reads:"The
    following sections provide definitions that a common to all Artifacts."

    "That a common" should be replaced by "that are common".

    =====================================================================

    Issue 82: Page 124, Section 8.3.15, Typo Missing "are" in frist sentence

    Reported by asir...@trisotech.com, Jul 01, 2009

    The first sentence of Section 8.3.15 is: "A Participant represents a
    specific PartnerEntity (e.g., a company) and/or a more general PartnerRole
    (e.g., a buyer, seller, or manufacturer) that Participants in a
    collaboration."

    The word "are" should be added to read " ..... that are Participants in a
    collaboration."

    =====================================================================

    Issue 83: Page 145, Section 9, Typo missing "in"

    Reported by asir...@trisotech.com, Jul 02, 2009

    Page 145, last paragraph, first sentence reads: "In some applications it
    is useful to allow more Messages to be sent between Participants when a
    Collaboration is carried out than are contained the Collaboration model."

    The word "in" should be added, for the sentence later part to read: " ....
    are contained in the Collaboration model."

    ======================================================================

    Issue 84: Page 146, Section 9.1 Typo word "main" should be "may"

    Reported by asir...@trisotech.com, Jul 02, 2009

    Section 9.1, second paragraph, first sentence reads:"A Pool may be empty,
    a “black box,” or main show a Process within."

    The word "main" should be replaced by "may".

    ======================================================================

    Issue 87: Page 163, Section 10.2, Typo "An" should replace "A"

    Reported by asir...@trisotech.com, Jul 02, 2009

    In page 163, the second structural specification (just before section
    10.2.1) reads: "A Activity MAY be a source for Message Flow; it can have
    zero or more outgoing Message Flow."

    The first word of the sentence "A" should be replaced by the word "An".

    ======================================================================

    Issue 88: Page 188, Section "Event Sub-Process", Typo missing "is"

    Reported by asir...@trisotech.com, Jul 02, 2009

    The frst sentence after the sub-section title "Event Sub-Process"
    reads: "An Event Sub-Process is a specialized Sub-Process that used within
    a Process (or Sub-Process)."

    The word "is" should be added for the sentence to read: "An Event Sub-
    Process is a specialized Sub-Process that is used within a Process (or Sub-
    Process)."

    ====================================================================

    Issue 89: Page 188, sub-section "Event Sub-Process" Typo

    Reported by asir...@trisotech.com, Jul 02, 2009

    The last structural specification of page 188 reads: "The use of text,
    color, size, and lines for a Sub-Process MUST follow the rules defined in
    Section “Use of Text, Color, Size, and Lines in a Diagram” on page 63 with
    the exception that:"

    The words " a Sub-Process MUST" should be replaced by "an Event Sub-
    Process MUST".

    ====================================================================

    Issue 91: Page 231, sub-section "DataInputAssociation", Typo "an" vs "a"

    Reported by asir...@trisotech.com, Jul 02, 2009

    The first sentence of page 231 reads: "The DataInputAssociation can be
    used to associate a item-aware element with a DataInput contained in
    an Activity."

    The word "a" before "item-aware" should be replaced by the word "an".

    ===================================================================

    Issue 94: Page 308, Section 10.5.6, Typo Replace "follow" by "following"

    Reported by asir...@trisotech.com, Jul 02, 2009

    The fifth structural specification in page 308, reads: "Only the following
    Intermediate Event triggers are valid: Message, Signal, Timer,
    Conditional, and Multiple (which can only include the previous triggers).
    Thus, the follow Intermediate Event triggers are not valid: Error, Cancel,
    Compensation, and Link."

    The word "follow" in the second sentence of the specification should be
    replaced by "following".

    =================================================================

    Issue 95: Page 320, Section 10.8, Typo missing word "in"

    Reported by asir...@trisotech.com, Jul 02, 2009

    Section 10.8, second paragraph, first sentence reads: "In some
    applications it is useful to allow more Activities and Events to occur
    when a Process is executed or performed than are contained the Process
    model."

    The word "in" should be added for the end of the sentence to read " ....
    than are contained in the Process model."

    ================================================================

    Issue 100: Page 343, Section 12, Typo Two verbs used instead of one

    Reported by asir...@trisotech.com, Jul 07, 2009

    The sentence above Figure 12-2 reads: "Figure 12-1 shows displays the
    metamodel ...".

    One of the two verbs, "shows" or "displays" should be deleted.

    ===============================================================

    Issue 109: Page 367, Section 12.4.6, Typo, word "will" to be deleted

    Reported by asir...@trisotech.com, Jul 07, 2009

    The second sentence of page 367 reads: "The Choreography Task that has two
    Messages will is reflected by three Process Tasks."

    The word "will" should be deleted.

    ==============================================================

    Issue 112: Page 164, Table 10-5, Typo "s" added to Type

    Reported by dga...@trisotech.com, Jul 08, 2009

    There is also a typo on p. 164. resourceParameterBindings should be of
    type
    ResourceParameterBinding and not ResourceParameterBindings.

    ==============================================================

    Issue 121: Page 361 Section 12.4.3 Typo "collpased" instead of "collapsed"

    Reported by hudoneric, Jul 27, 2009

    On page Page 361 Section 12.4.3 "collpased" should be read "collapsed". The
    text is located on the third bullet of the section 12.4.3.

    =============================================================

    Issue 124: Page 044, Figure 7-4, Page 345 Figure 12-2 and Page 394 Figure 12-50 Typo in the figure

    Reported by dga...@trisotech.com, Jul 29, 2009

    The last Choreography activity in Figure 7-4, Figure 12-2 and Figure 12-
    50 should be labeled "Handle Medecine".

    ====================================================================

    Issue 134: Page 264 Table 10-85 Typo in table caption "cancel Activity" should be "cancelActivity"

    Reported by dga...@trisotech.com, Jul 29, 2009

    Page 264 Table 10-85 Typo in table caption "cancel Activity" should
    be "cancelActivity"

    ========================================================================

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Table 8.8, page 48 (78 pdf), second row, first column: Change "ExtensionDefinition" to "ExtensionAttributeDefinition"
    (b) Table 8.80, page 108 (138 pdf), third row, first column: Change "CallableElements" to "CallableElement"
    (c) Section 10.4.4 Event Definitions, Sub-Section "Terminate Event," page 251 (281 pdf), first sentence on page: Change "CancelEventDefintion" to
    "TerminateEventDefinition"
    (d) Section 10.5.6 Event Gateway, page 274 (304 pdf), second bullet on page: Change "a Start Event" to "an Event Gateway"
    (e) Section 10.7 Lanes, page 282 (312 pdf), second bullet on page: Change "Pool" to "Lane" three times in bullet
    (f) Table 7.1, page 22 (52 pdf), first row on page, second column: Change "It is also acts" to "It also acts"
    (g) Table 7.2, page 33 (63 pdf), second row on page, second column: Change "It is also acts" to "It also acts"
    (h) Table 7.1, page 21 (51 pdf), second row on page, second column: Change "in Process" to "in a Process"
    Table 7.2, page 24 (54 pdf), second row on page, second column: Change "in Process" to "in a Process"
    (j) Table 7.2, page 24 (54 pdf), last row on page, second paragraph: change "two (2) more" to "two (2) or more"
    (k) Section 12.4.1 Choreography Task, page 316 (346 pdf), second paragraph on page, last sentence in paragraph: change "two (2) more" to "two (2) or more"
    (l) Section 12.4.2 Choreography Sub-Process, page 321 (351 pdf), first paragraph in section, last sentence in paragraph: change "two (2) more" to "two (2) or more"
    (m) Section 13.2.5 BPMN Shapes, Sub-Section "ChoreographyActivityShape," page 379 (409 pdf), first paragraph in section, last sentence in paragraph: change
    "two (2) more" to "two (2) or more"
    Section 8.3.1 Artifacts, Sub-Section "Common Artifact Definitions," page 56 (86 pdf), first paragraph in section, first sentence: change "that a common" to "that are
    common"
    (o) Section 8.3.15 Participants, page 91 (121 pdf), first sentence in section: change "that Participants" to "that are Participants"
    (p) Section 9 Collaboration, page 113 (133 pdf), last paragraph on page, first sentence: change "contained the" to "contained in the"
    (q) Section 9.1 Basic Collaboration Concepts, page 114 (144 pdf), second paragraph in section, first sentence: change "or main show" to "or may show"
    (r) Section 10.2.5 Sub-Process, Sub-Section "Event Sub-Process," page 156 (186 pdf), first sentence in section: change "that used within" to "that is used within"
    (s) Section 10.2.5 Sub-Process, Sub-Section "Event Sub-Process," page 156 (186 pdf), sixth bullet in section: change "for a Sub-Process" to "for an Event Sub-
    Process"
    (t) Section 10.3.1 Data Modeling, Sub-Section "DataInputAssociation," page 202 (232 pdf), first sentence in section: change "a item-aware" to "an item-aware"
    (U) Section 10.8 Process Instances, Unmodeled Activities, and Public Processes, page 286 (316 pdf), second paragraph in section, first sentence: change "contained
    the Process" to "contained in the Process"
    (v) Section 12 Choreography, page 318 (338 pdf), paragraph above Figure 12.1, first sentence: change "Figure 12.1 shows displays" to "Figure 12.1 displays"
    (w) Section 12.4.6 The Sequencing of Activities, page 331 (361 pdf), firt paragraph on page, second sentence: change "Messages will is" to "Messages is"
    Table 10.5, page 132 (162 pdf), third row, first column: change "ResourceParameterBindings [0..*]" to "ResourceParameterBinding [0..*]"
    Section 12.4.3 Call Choreography Activity, page 326 (356 pdf), third bullet on page: change "collpased" to "Collapsed"
    (z) Figure 7.4, Figure 12.2, and Figure 12.5: change the Choreography Task label for the last task in the diagram from "Handle Symptoms" to "Handle Medicine"
    (aa) Table 10.85, page 234 (264 pdf), Table Caption: change "cancel Activity" to "cancelActivity"
    Note: a typo reported for page 131 (163 pdf as reported) was no longer valid.
    Note: a typo reported for page 275 (308 pdf as reported) was no longer valid.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Conformance Classes are overley Broad

  • Key: BPMN2-1
  • Legacy Issue Number: 14240
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    2.1.1 process modeling conformance:
    what could a platform which supports all the diagrams except for conversation
    diagrams claim conformance to? This might be important for migration from BPMN 1
    implementations. Can it claim some form of "partial compliance?

    Proposed Resolution: The FTF should define more granular conformance Classes, to ease migration
    from BPMN 1.2 implementations.

  • Reported: BPMN 2.0b1 — Tue, 1 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Please read the document attached to the link below for a proposal description. We will update the resolution description with more adequate content before we open
    the ballot.
    Conformance+DESCRIPTIVE_ANALYTIC_EXECUTABLE+proposal+for+BPMN2+Spec.doc

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 052, Table 7-2, Wrong figure of all event possibilities

  • Key: BPMN2-6
  • Legacy Issue Number: 14247
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jun 08, 2009

    The old list from BPMN 1.2 is presented there

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Table 7.2, page 24 (54 pdf), first row on page, third column: update figure to match BPMN 2.0 capabilities. See attached figure here:
    (10587_Updated+Event+Type+Figure+for+Table+7.2.jpg)
    (b) Table 7.2, page 24 (54 pdf), first row on page, second column, last sentence in column: change "see page 268" to "see figure to the right"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 227 Table 10-56 the attributes optionalOutput and whileExecutingOuput are wrongly typed DataInput

  • Key: BPMN2-5
  • Legacy Issue Number: 14246
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jun 08, 2009

    On p. 227 the attributes optionalOutput and whileExecutingOuput are typed
    DataInput, they should be typed DataOutput.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Table 10.56, page 199 (229 pdf), row 3, column 1: change "DataInput" to "DataOutput"
    (b) Table 10.56, page 199 (229 pdf), row 4, column 1: change "DataInput" to "DataOutput"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 199 class model for the global tasks

  • Key: BPMN2-4
  • Legacy Issue Number: 14245
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    On p.199, there is a class model for the global tasks, but there no table
    that explains the attributes that are displayed on the diagram like the
    other classes in the document.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In order not to duplicate the information, a reference to the page where tasks are defined is included in that section. So there is no need to add a table describing
    attributes and behaviour, since they are similar to standard tasks.
    Nevertheless, there is a single attribute in Global Task that must be described: performers, which is covered by issue 14732 14732.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 029, Section 2.1.3 Usage of normal bullets vs diamond shape to indicate structural specifications

  • Key: BPMN2-8
  • Legacy Issue Number: 14249
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jun 26, 2009

    Should the list presented use the diamond shape to indicate structural
    specifications?

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The semantic rule statements will be shown with a diamond bullet (changed from the letter "u").
    There will be no change markings to indicate these changes

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 199, Figure 10-40 Types of Global Task (Text,Class Diagram and Schema do not match)

  • Key: BPMN2-7
  • Legacy Issue Number: 14248
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by hudoneric, Jun 25, 2009

    On p. 199 of the specification The figure 10-40 Defines 4 types of global
    tasks: User, Manual, Script, BusinessRule.

    The paragraph "Types of Global Task" on p. 199 says that the list of task
    types is the same for globals task and standard tasks.

    When I look at the xml schema (Semantic.xsd) only User, Manual, Script,
    BusinessRule are defined.

    I wonder which one is true, the text or the schema? Also I wonder why the
    global task redefines the same attributes as standard tasks instead of
    referencing them.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The list of Global Tasks is correctly defined in the metamodel and the XSD schema, not all tasks types are allowed as global tasks.
    Replace the following paragraphs in "Types of Global Tasks":

    • This is true for both Global Tasks and standard Tasks, where the list of Task types is the same for both.
    • The behavior, attributes,and model associations defined in that section also apply to the types of Global Tasks.
      with the following text:
    • The types of Global Tasks are only a subset of standard Tasks types. Only GlobalUserTask, GlobalManualTask, GlobalScriptTask and GlobalBusinessRuleTask are
      defined in BPMN.
    • The behavior, attributes, and model associations defined for each type of task in that section apply to the corresponding types of Global Tasks.
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 044, Figure 7-3, Pool names not separated from content by a single line

  • Key: BPMN2-9
  • Legacy Issue Number: 14250
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jun 26, 2009

    Should the Pool names be separated by a single line as stated in the
    structural specification in Section 9.2, page 146.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Figure 7.3 will be updated to include the proper notation for Pools, which is to have the name of the Pool separated by a single line. The updated figure is shown
    here:
    (10543_Figure+7-3+Update.jpg)
    .
    (b) This issue can be applied for a number of other figures in the specification. These figures are:
    Figure 7.2, Figure 7.5, Figure 7.6, Figure 8.14, Figure 8.30, Figure 8.31, Figure 8.36, Figure 8.37, Figure 8.41, Figure 9.5, Figure 9.6, Figure 10.5, Figure 11.1,
    Figure 11.2, Figure 11.3, Figure 11.4, Figure 11.11, 12.50, and Figure 12.51
    The updates to these figures will not be posted.
    (c) Also, there are a few figures for Lanes, which do not have the single line separator, that need to be updated:
    The figure for Lane in Table 7.1, The figure for Lane in Table 7.2,
    The updates to these figures will not be posted here.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 044, Figure 7-4, The initiating party is wrongly identified in the figure

  • Key: BPMN2-21
  • Legacy Issue Number: 14292
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 06, 2009

    The initial messages and Participant bands are greyed in error, (Reverse
    logic Initiating vs Return)

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Figure 7.4 will be updated to reverse the shading of the Participant Bands. The updated figure can be seen here:
    (10552_Update+to+Figure+7.4.jpg)

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 395, Figure 12-51, Intermediate Event instead of End Event in Choreography diagram

  • Key: BPMN2-20
  • Legacy Issue Number: 14291
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jul 02, 2009

    The Choreography diagram shown in Figure 12-51 end with an Intermediate
    Event. It should be an End Event.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The problem with Figure 12.51 was a image quality problem. The correct elements were used in the figure.
    The quality of Figure 12.51 has been updated by the resolution of 14250.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 115, Section 8.3.13 Copy/paste

  • Key: BPMN2-19
  • Legacy Issue Number: 14290
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jul 01, 2009

    The second structural specification of section 8.3.13 should refer
    to "Message" and not "Task".

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In Section 8.3.13, on page 83 (113 pdf), second bullet in section: change "Task" to "Message"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 351, Figure 12-7 Caption of the Figure Name

  • Key: BPMN2-25
  • Legacy Issue Number: 14297
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Figure 12-7 caption is "A Collaboration view of Choreography Task
    elements" is not representative of the figure.

    According to the text above the figure and the diagram, the caption should
    be: "A Collaboration view of the Participants of the Interaction".

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close the issue without change.
    The figure caption accurately represents the figure and no changes are needed.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 348, Section 12.3.1, end of sentence confusing

  • Key: BPMN2-24
  • Legacy Issue Number: 14296
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jul 07, 2009

    Page 348, last paragraph, first sentence reads: "In some applications it
    is useful to allow more Messages to be sent between Participants when a
    Choreography is carried out than are contained the Choreography model."

    The end of the sentence "... is carried out than are contained in the
    Choreography model." is confusing.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 12.3.1, last non-bullet paragraph in section: replace the first sentence with:
    "In some applications it is useful to allow additional Messages that are not part of the defined Choreography model to be sent between Participants when the
    Choreography is carried out."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 346, Section 12.1 Reference of Figure 12-4 instead of Figure 12-3?

  • Key: BPMN2-23
  • Legacy Issue Number: 14295
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jul 07, 2009

    In the first and second paragraphs of page 346 a reference is made to
    Figure 12-4. Should it be to Figure 12-3 instead?

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Section 12.1, page 311 (341 pdf), first paragraph, first sentence: change "Figure 12-4" to "Figure 12-3"
    (b) Section 12.1, page 311 (341 pdf), second paragraph, third sentence: change "Figure 12-4" to "Figure 12-3"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 345, Section 12.1 Typo, the word "Events" should be "Activities"

  • Key: BPMN2-22
  • Legacy Issue Number: 14294
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jul 07, 2009

    The fourth sentence of the last paragraph of page 345, reads: "For
    example, a Planned Order Variations Message is sent by the Supplier to the
    Retailer; the corresponding send and receive have been modeled using
    regular BPMN messaging Events."

    This text refers to the content of Figure 12-3 (mentionned before). No
    Events are shown in this Figure. The word "Events" should be replaced
    by "Activities".

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In Section 12.1, on page 310 (340 pdf), the forth sentence in the last paragraph of page: change "Events" to "Activities"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 372, Table 12-7 Blank sections

  • Key: BPMN2-14
  • Legacy Issue Number: 14255
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jun 29, 2009

    Why are Table sections for Escalation used in normal flow and Escalation
    attached to activity boundary left blank?

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Table 12.7: Use of Intermediate Events in Choreography
    (a) Row for Escalation: Used in Normal Flow: add the following in column 2: "No. An Escalation is only visible to a single Participant. That Participant will have to send
    a
    Message to the other Participants."
    (b) Row for Escalation: Attached to Activity boundary: add the following in column 2: "No. An Escalation is only visible to a single Participant. That Participant will
    have to send a
    Message to the other Participants."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 338, section 11.7 Section name versus content

  • Key: BPMN2-13
  • Legacy Issue Number: 14254
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jun 29, 2009

    Is the tiltle "Communication Link" or "Conversation Link"? Second term
    used in the text and Figure of this section.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In Section 11.7, on page 302 (332 pdf), Section title: change "Communication" to "Conversation"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 064, Section 7.5.1, wrong reference to Table 8.4 (should be Table 7-3)

  • Key: BPMN2-17
  • Legacy Issue Number: 14288
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jul 01, 2009

    Should the first two words of section 7.5.1 "Table 8.4" be replaced
    by "Table 7-3" ?

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In Section 7.5.1, on page 34 (64 pdf), first sentence in first paragraph of section: change "Table 8.4" to "Table 7.3"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 042, Section 7.1.1 Reference to Figure 10-5

  • Key: BPMN2-16
  • Legacy Issue Number: 14257
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jul 01, 2009

    The last paragraph, first sentence of page 42 is: "A public Process
    represents the interactions between a private Business Process and another
    Process or Participant (see Figure 10-5)."

    Should the reference to Figure 10-5, be replaced by Figure 7-2 presented
    at page 43?

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In Section 7.1.1, on page 15 (45 pdf), first sentence in last paragraph on page: change "Figure 10.5" to "Figure 7.2"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 259, Table 10-82, Missing "Catch" label above depiction of Parallel Multiple Event

  • Key: BPMN2-12
  • Legacy Issue Number: 14253
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jun 29, 2009

    The Parallel Multiple Event in Table 10-82 is the only Event without
    the "Catch" indicated above its diagram object.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In Section 10.4.4, on page 229 (259 pdf), Table 10-82, last row on page (Parallel Multiple): add the text "Catch" above the figure in the 3rd column (as in the other
    rows).

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 130, section 8.3.17 Copy/Paste error

  • Key: BPMN2-11
  • Legacy Issue Number: 14252
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jun 26, 2009

    Second structural specification, should Task be replaced by Sequence Flow?

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In Section 8.3.17, on page 98 (128 pdf), second bullet on page: change "Task" to "Sequence Flow"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 028, Section 1, Missing Conversation diagram in list of diagrams defined in BPMN

  • Key: BPMN2-15
  • Legacy Issue Number: 14256
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jul 01, 2009

    Section 1, third paragraph, first sentence says: "This specification
    represents the amalgamation of best practices within the business modeling
    community to define the notation and semantics of Collaboration diagrams,
    Process diagrams, and Choreography diagrams."

    Should "Conversation diagrams", described in section 13, be added to this
    list?

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14654 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 065, Section 7.5.2, Wrong reference to Table 8.5 (Should be Table 7-4)

  • Key: BPMN2-18
  • Legacy Issue Number: 14289
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jul 01, 2009

    Should the first two words of section 7.5.2 "Table 8.5" be replaced
    by "Table 7-4"?

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In Section 7.5.2, on page 35 (65 pdf), first sentence in first paragraph of section: change "Table 8.5" to "Table 7.4"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 119, section 8.3.14 Copy/Paste error wrong term "Pool" vs "Message Flow"

  • Key: BPMN2-10
  • Legacy Issue Number: 14251
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jun 26, 2009

    The third strtural specification refers to Pool, should it be replaced by
    Message Flow?

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In Section 8.3.14, on page 87 (117 pdf), second bullet on page: change "Pool" to "Message Flow"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN 2 FTF issue on XSDs for DD / DI model transfer

  • Key: BPMN2-83
  • Legacy Issue Number: 14423
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    XSD Schemas for transfer of Model instances of DI and DD Metamodels

    Source: Tom Rutt (Fujitsu)

    Location: BPMN 2.0 Beta 1 ­ Annex B

    Summary of Issue:

    In the current BPMN 2 spec, Model instances of the BPMN2 Metamodel have two
    alternate forms for transfer:

    • XMI derived directly from the BPMN 2 Metamodel
    • Instances of the BPMN XSD schemas defined in BPMN 2 spec.

    The current Annex B of the Beta 1 BPMN 2 spec defines metamodels for Diagram
    Interchange (DI) and Diagram Definition (DD). However there are no BPMN XSD
    schemas defined for the DI and DD metamodels. Thus, it seems that XMI derived
    from these DI and DD metamodels currently the only normative way defined to
    transfer Model instances of these metamodels?

    The current plan is that this Annex B will be replaced with a reference to the
    adopted DI spec.

    Resolving issue involves the FTF answering two questions:

    1) Is there a need to define “custom” XSD schemas, not based on XMI, as an
    alternative for transfer of DI and DD model instances.
    2) If the answer to question 1 is yes, will these “custom” XSD schemas be
    defined by the BPMN 2 FTF, or the DI submitters?

  • Reported: BPMN 2.0b1 — Wed, 16 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    8.3.13 page 115. Change "a Message is a graphical object" to "a Message is a graphical decorator"
    8.3.13 page 115. Remove the part after figure 8-28 where it talks that it can be used on choreography sub process
    8.3.13 page 115. Change "can be displayed as attached (Associated) to a Message Flow" to "can be optionnaly depicted as a graphical decorator on a Message
    Flow"
    Remove Figure 8-30 page 116
    8.3.13 page 116 - Under figure 8-31 change "can be displayed as Associated" to "can be depicted as a decorator"
    Remove the paragraph between Figure 8-32 and Figure 8-33
    Remove Figure 8-33 page 117
    Chapter 13 is to be replaced with the provided Chapter 13 in attached ZIP
    Annex B is to be replaced with the provided Annex B in attached ZIP
    BPMN DI schemas are to be replaced with the schemas provded in attached ZIP
    All files are included in the following zip file:
    Revised+BPMNDI+Ballot+Proposal+Apr+26.zip
    Note on 2010-04-26:
    The FTF acknowldges the proposed namespace does not follow OMG guidelines for namespace conventions. The final namespaces will be:

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Method of specifying a default SequenceFlow is awkward

  • Key: BPMN2-88
  • Legacy Issue Number: 14535
  • Status: closed  
  • Source: Chagford CC ( Frank Millman)
  • Summary:

    I have looked at a few sample BPMN2.0 xml instances, such as those in the draft spec, those in the book 'BPMN Method and Style', and others found on the web.

    In all cases, SequenceFlow elements are shown with a sourceRef and a targetRef, but no id. This seems reasonable.

    However, I have now discovered that, to specify a 'default' SequenceFlow for an Inclusive or Exclusive Gateway, you must populate the 'default' attribute of the Gateway with a reference to the SequenceFlow. As I understand it, this reference must refer to the id of the SequenceFlow.

    This seems unnecessarily complicated. To me, the obvious way of specifying a default SequenceFlow is to have a boolean attribute on the SequenceFlow itself, defaulting to false.

    If there is a good reason to specify it as a reference on the Gateway, I would have thought it would be good practice to always assign an id to a SequenceFlow. Otherwise, to make one of them a default, you have to, first, assign an id to it, and then use the id as a reference on the Gateway. This seems awkward.

  • Reported: BPMN 2.0b1 — Wed, 7 Oct 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The current solution might be confusing if someone was building a BPMN model directly with XML, but we don't expect that to happen much.
    The current definition is simpler for tools to implement default Sequence Flow and the end user should not be impacted.
    By putting the default attribute in the activity and gateway, we ensure in a simple way that there is only one default sequence flow. If the attribute should be part of the
    sequence flow elements, tools would need to validate that only one of the outgoing sequence flows have the attribute set to true.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Lane.partitionElementRef incorrectly defined

  • Key: BPMN2-87
  • Legacy Issue Number: 14446
  • Status: closed  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Consider swim lanes representing performers.

    • The spec states that the Lane.partitionElementRef would reference a Performer. This won't work since Performers are owned by Activities. Hence would result in a different Lane for every Activity.
      Instead the Lane.partitionElementRef should instead reference a Resource, which multiple Performers may reference.
    • The XSD defines Lane.partitionElementRef as an IDREF. It should instead be a QName, to allow references to a Resource in a different Definitions file.
  • Reported: BPMN 2.0b1 — Thu, 1 Oct 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) On spec pg 285, replace "e.g., all Lanes in a LaneSet defines the Performer element as the partition element, but all with different values" with "e.g., all Lanes in a
    LaneSet reference a Resource as the partition element, but each Lane references a different Resource instance".
    (b) Update the tLane type in the XSD, replacing
    <xsd:attribute name="partitionElementRef" type="xsd:IDREF"/>
    with
    <xsd:attribute name="partitionElementRef" type="xsd:QName"/>
    to allow for Resources in a different definitions file.
    (c) The XSD snippet in the spec will also need to be similarly updated.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 24, Table 7.2 Gateway control types row - Redundant forms for XOR Gateway

  • Key: BPMN2-82
  • Legacy Issue Number: 14363
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    This is a style suggestion to make diagrams clearer. The XOR gateway allows two forms
    of diagram: empty diamond, and a diamond with an X in it. While redundancy is OK in
    general, the fact that different vendors make different choices. But an X and a cross look
    very similar.

    While the X should be allowed, the spec should indicate that it is preferred to use the
    blank option, with the eye to eventually eliminating the X.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close this issue as a duplicate.
    The resolution of issue 14354 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 121, Figures 7.3 and 10-1 ­ Redundant ways to model receiving messages

  • Key: BPMN2-81
  • Legacy Issue Number: 14362
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    This is a style suggestion that will make diagrams clearer by removing redundant
    notations. There is a "receive event" to receive any kind of communication. For
    example, and event to receive a message. Or an event to receive a signal. Events are
    circles on the diagram. Additionally, BPMN allows a "receive type" activity, that is a
    rounded rectangle that receives messages. Receiving of a message seems more naturally
    to be an "event" and not an "activity" because an event is something that happens. An
    activity is something you do, and receiving something is really just waiting and not doing
    anything. So picturing receive an activity seems unnatural. The redundancy to two ways
    to draw this causes confusion.

    The spec could encourage the use of a "receive event", and to deprecate the "receive
    activity". Receive activity would still be allowed, but "deprecation" would put the
    standard on a path to eventually remove it, and would send a message to not use it or
    expect it to be there in the future.

    The figure 10-1 should be re-drawn to have receive message events instead of "receive
    activities".

    The doctor/patient example in figure 7-3 should be redrawn to use receive events instead
    of the receive activities.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14353 will resolve this issue
    The spec could encourage the use of a "receive event", and to deprecate the "receive activity". Receive activity would still be allowed, but "deprecation" would put the
    standard on a path to eventually remove it, and would send a message to not use it or expect it to be there in the future.
    The figure 10-1 should be re-drawn to have receive message events instead of "receive activities".
    The doctor/patient example in figure 7-3 should be redrawn to use receive events instead of the receive activities.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 204, Table 10-26, MultiInstance Activity: Potential error and clarification regarding **BehaviorEventRef

  • Key: BPMN2-90
  • Legacy Issue Number: 14540
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Page 204, Table 10-26, There seems to be an error in providing an attribute called noneBehaviorEventRef, it should be allBehaviorEventRef....? Futhermore a complexBehaviorEventRef attribute would be missing....?

    But why do we need multiple ***BehaviorEventRef attributes? Couldn't we just have a BehaviorEventRef attribute that is used for either one, all or complexe?

  • Reported: BPMN 2.0b1 — Thu, 8 Oct 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    There is no issue. The questions in the issue description probably arose from a misunderstanding of the "complex" MI behavior, which refers to multiple event
    descriptions and not necessarily a single one as assumed by the reporter. When behavior is complex, we have multiple event refs, so we cannot unify with the other two
    options. "none" and "one" could indeed be unified; but it would be clearer not to unify.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 26, Normal Flow row of Table 7.2 - Modeling Activities that are only ended by Events

  • Key: BPMN2-80
  • Legacy Issue Number: 14361
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    There are activities that are only ended by events, thus the activity may have one or more
    events located on the border of the activity, but no "normal" non event exit of the activity.

    The request is that the spec include an explicit statement that the activity might have
    events on the border, but no other "natural" ending of the activity.

    If this is not agreed, the spec needs to explain how to model such activities.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close this issue as a duplicate.
    The resolution of issue 14352 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 26, Normal Flow row of Table 7.2 - Modeling activities that do not complete before process completion

  • Key: BPMN2-79
  • Legacy Issue Number: 14360
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    There are activities that are never ended - that is they have no natural completion, but are
    terminated only when the process itself is terminated. Monitoring activities are like that.
    If an activity is started, and there is never a conclusion of that activity, then this should be
    indicated by having no outbound arrow from the activity. This activity is concluded only
    by the termination of the process as a whole. For example, and process may have a main
    thread, but also split early and start a "monitoring" activity. This monitoring activity is
    designed to stay active until the process is concluded for some other reason. There is no
    way for the assignee of the activity to say "I am done monitoring this process" without
    the process itself being terminated. Since there is no "natural" end of the activity, there
    should be no arrow coming out of the activity node. I am not sure if this is a requirement
    of the spec, but there is a common perception that it is a requirement, that all activities
    have an outbound arrow coming out of it.

    This request is that the spec include a statement that it is explicitly OK to not have an
    arrow out of an activity that has no natural end to its execution.

    If this is not agreed, the spec needs to explain how to model such activities

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close this issue as a duplicate.
    The resolution of issue 14351 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 22, Section 7.2.1 ­ Associating Data Objects with process as a whole

  • Key: BPMN2-78
  • Legacy Issue Number: 14359
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Many workflow systems are designed around the concept that there is a process context
    that holds variables shared by all activities within that context. Since the swimming pool
    represents the process instance as a whole, there should be a way to associated process
    variables with the pool itself, which would be accessible by all activities within the pool.

    The spec should clarify how a model can associate data objects with the process as a
    whole.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close this issue as a duplicate.
    The resolution of issue 14350 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 331, Figure 11-4, Message Flows part of a Conversation diagram

  • Key: BPMN2-67
  • Legacy Issue Number: 14342
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    Figure 11-4 presents a list of Message Flows associated to the "Delivery
    Negotiations Conversation".

    Are the message flows listed the correct depiction for the explosion of
    the Conversation?

    If so shouldn't the conversation object have a [+]?
    Are Message Flows graphical elements to be used in a Conversation diagram
    or was it presented exclusively to show the relation between two views?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Note that all of these changes will be moved to Chapter 9 Collaboration through The resolution of issue 14654.
    (a) Paragraph above Figure 11.4: replace first sentence with the following: "Figure 11.4 shows a subset of the larger Conversation diagram of Figure 11.3, above.
    Figures 11.5 and 11.6 show the drill down into the "Delivery Negotiations" Sub-Conversation."
    (b) Replace Figure 11.4 with a figure that only shows the two Pools, two Conversation Links, and a Sub-Conversation element (the plus sign that was missing should
    be added) - the bottom half of the figure would be removed. See attached figure
    (10547_Figure+11-4+Updated.jpg)
    .
    (c) Replace the caption for Figure 11.4 with the following: "An example of a Sub-Conversation"
    (d) Add a figure after Figure 11.4 that shows the expanded version of the Sub-Conversation so that it contains a set of reference Message Flow and Conversation
    element ("Variations"). See attached figure
    (10690_Figure+11-5+%5BNew+Figure%5D.jpg)
    (e) The caption for the new figure should be the following: "An example of a Sub-Conversation expanded to a Conversation and Message Flow"
    (f) Add a new paragraph that precedes the new figure: "Figure 11.5 shows a how the Sub-Conversation of Figure 11.4 is expanded into a set of Message Flow and a
    lower-level Conversation."
    (g) Add another new figure (after item (d)) that shows the Sub-Conversation expanded fully to all of its referenced Message Flow. See attached figure
    (10549_Figure+11-6+%5BNew+Figure%5D.jpg)
    (h) The caption for the new figure should be the following: "An example of a Sub-Conversation that is fully expanded"
    Add a new paragraph that precedes the new figure: "Figure 11.6 shows a how the Conversation of Figure 11.5 is also expanded into a set of Message Flow,
    combined with the Message Flow. Note that the newly exposed Message Flow of the lower-level Conversation will be correlated by the CorrelationKey of both the
    lower-level Conversation ("Variation ID") and the higher-level Sub-Conversation ("Order ID")."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 29, Section 7.2.2 ­ Fork and Join Differentiation

  • Key: BPMN2-77
  • Legacy Issue Number: 14358
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    BPMN says that you use a parallel gateway (diamond with a plus in it) to start a sequence
    of parallel paths, and another AND gateway to end it. The behaviors of these two
    gateways are different, but they look the same. Suggestion is that the first AND gateway,
    that starts the parallel split have a thin line, while the gateway at the end which actually
    waits for multiple inputs will have a thick line. This corresponds to the thin and thick
    lines around start and end nodes.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close this issue as a duplicate.
    The resolution of issue 14349 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 121, Figure 10-1 - Redundant ways to model receiving messages

  • Key: BPMN2-76
  • Legacy Issue Number: 14353
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    This is a style suggestion that will make diagrams clearer by removing redundant notations. There is a "receive event" to receive any kind of communication. For example, and event to receive a message. Or an event to receive a signal. Events are circles on the diagram. Additionally, BPMN allows a "receive type" activity, that is a rounded rectangle that receives messages. Receiving of a message seems more naturally to be an "event" and not an "activity" because an event is something that happens. An activity is something you do, and receiving something is really just waiting and not doing anything. So picturing receive an activity seems unnatural. The redundancy to two ways to draw this causes confusion.

    The spec could encourage the use of a "receive event", and to deprecate the "receive activity". Receive activity would still be allowed, but "deprecation" would put the standard on a path to eventually remove it, and would send a message to not use it or expect it to be there in the future.

    The figure 10-1 should be re-drawn to have receive message events instead of "receive activities".

    The doctor/patient example in figure 7-3 should be redrawn to use receive events instead of the receive activities.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue cannot be fixed in this FTF.
    Disposition: Closed, Out Of Scope

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 22, Section 7.2.1 - Associating Data Objects with process as a whole

  • Key: BPMN2-73
  • Legacy Issue Number: 14350
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Many workflow systems are designed around the concept that there is a process context that holds variables shared by all activities within that context. Since the swimming pool represents the process instance as a whole, there should be a way to associated process variables with the pool itself, which would be accessible by all activities within the pool.

    The spec should clarify how a model can associate data objects with the process as a whole.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Processes define DataObjects, so the scope of DataObjects is the process they are defined. We are opening another issue to create a clarification of the behaviour of
    simultaneous updates on DataObjects.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 190, sub-section "Transaction"

  • Key: BPMN2-72
  • Legacy Issue Number: 14347
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    Can a Transaction Sub-Process be presented collapsed?
    i.e with a + marker at the bottom center.

    NB It is clear in the case of Event Subprocess

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    A new figure will be added in Section 10.2.5 after Figure 10.32.
    The figure will be the one shown posted here:
    (10563_Additional+Transaction+Figure.jpg)

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 26, Normal Flow row of Table 7.2

  • Key: BPMN2-74
  • Legacy Issue Number: 14351
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Page 26, Normal Flow row of Table 7.2 - Modeling activities that do not complete before process completion.

    There are activities that are never ended - that is they have no natural completion, but are terminated only when the process itself is terminated. Monitoring activities are like that. If an activity is started, and there is never a conclusion of that activity, then this should be indicated by having no outbound arrow from the activity. This activity is concluded only by the termination of the process as a whole. For example, and process may have a main thread, but also split early and start a "monitoring" activity. This monitoring activity is designed to stay active until the process is concluded for some other reason. There is no way for the assignee of the activity to say "I am done monitoring this process" without the process itself being terminated. Since there is no "natural" end of the activity, there should be no arrow coming out of the activity node. I am not sure if this is a requirement of the spec, but there is a common perception that it is a requirement, that all activities have an outbound arrow coming out of it.

    This request is that the spec include a statement that it is explicitly OK to not have an arrow out of an activity that has no natural end to its execution.

    If this is not agreed, the spec needs to explain how to model such activities.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The FTF Team agreed that some examples of modeling techniques that can be used to model these situations would be appropriate.
    For now, the issue can be Closed; No Change
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 361, Figure 12-23, Sub-process marker missing

  • Key: BPMN2-69
  • Legacy Issue Number: 14344
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    The Figure 12-23 shows a Choreography Sub-Process. However the + marker is
    missing.

    In addition the caption of the figure should be "Choreography Sub-Process
    with multi-instance Participants".

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Section 12.4.2 Choreography Sub-Process, page 325 (355 pdf), Figure 12.23: Replace current figure with the figure posted here:
    (Replacement+for+Figure+12.23.jpg)
    .
    (b) Section 12.4.2 Choreography Sub-Process, page 325 (355 pdf), Figure 12.23: append current figure title with the following text: " with a multi-instance Participant"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 337, section 11.5 Typo should be "Call Conversation"

  • Key: BPMN2-68
  • Legacy Issue Number: 14343
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    Second structural specification should be "Call Conversation" instead of
    "Call Activity"

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 11.5, page 301 (page 331 pdf), second bullet on page: change "Call Activity" to "Call Conversation."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 26, Normal Flow row of Table 7.2

  • Key: BPMN2-75
  • Legacy Issue Number: 14352
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Modeling Activities that are only ended by Events

    There are activities that are only ended by events, thus the activity may have one or more events located on the border of the activity, but no "normal" non event exit of the activity.

    The request is that the spec include an explicit statement that the activity might have events on the border, but no other "natural" ending of the activity.

    If this is not agreed, the spec needs to explain how to model such activities.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    at Page 26, Normal Flow row of Table 7.2 replace :
    "Normal flow refers to the series of Sequence Flow that originates from a Start Event and continues through activities via alternative
    and parallel paths until it ends at an End Event. This does not include the paths that start from an Intermediate Event attached to the boundary of an Activity."
    with the following text:
    "Normal flow refers to paths of Sequence Flow that do not start from an Intermediate Event attached to the boundary of an Activity."
    beyond that, this issue is resolved by resolution of issue 14783 (Jira issue 14783)

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 032, section 2.4.1, Referencing wrong chapter

  • Key: BPMN2-70
  • Legacy Issue Number: 14345
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    Second bullet of section 2.4.1 is: "Choreography diagrams, which includes
    the elements defined in the Choreography, and Choreography packages (see
    Chapter 10)."

    The reference should be to Chapter 12.

    Third bullet of section 2.4.1 See Chapter 143 should read Chapter 9

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Section 2.4.1 BPMN Choreography Types, page 5 (35 pdf), first bullet on page: Change "Chapter 70" to "Chapter 8"
    (b) Section 2.4.1 BPMN Choreography Types, page 5 (35 pdf), second bullet on page: Change "Chapter 10" to "Chapter 12"
    (c) Section 2.4.1 BPMN Choreography Types, page 5 (35 pdf), third bullet on page: Change "Chapter 143" to "Chapter 9"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 076, Figure 8-5, Figure Caption incorrect

  • Key: BPMN2-71
  • Legacy Issue Number: 14346
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    Figure 8-5 is named "Classes in the Infrastructure package".

    This figure is presented in the section "8.2 Foundation".

    Is the caption incorrect?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 8.2 Foundation, page 45 (75 pdf), Figure 8.5: Replace current figure title with the following text: "Classes in the Foundation Package"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 244, section 10.4.2 Last two structural specifications for Start Event

  • Key: BPMN2-57
  • Legacy Issue Number: 14331
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    In the last two structural specifications of page 244:
    Should Event Sub-process be added to the exceptions that any other
    elements must not have incoming Sequence Flow when a Start Event is used?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The correction to the first structural specification was defined by the resolution of 14334. The remaining items are for the correction to the second structural
    specification.
    (a) Section 10.4.2 Start Event, page 215 (245 pdf), after first bullet on page: Add a second level bullet with the following text: "An exception to this is a Intermediate
    Event, which MAY be without an incoming Sequence Flow (when attached to an Activity boundary)."
    (b) Section 10.4.2 Start Event, page 215 (245 pdf), after first bullet on page: Add a second level bullet with the following text: "An exception to this is a catching Link
    Intermediate Event, which is not allowed to have incoming Sequence Flow. See page 243 for more information on Link Intermediate Events."
    (c) Section 10.4.2 Start Event, page 214 (244 pdf), after last bullet on page: Add a second level bullet with the following text: "An exception to this is an Event Sub-
    Process, which is not allowed to have incoming Sequence Flow and will only be instantiated when its Start Event is triggered. See page 155 for more information on
    Event Sub-Processes."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 187, Do sub-process markers also apply for Call Activity and Event Subprocess

  • Key: BPMN2-56
  • Legacy Issue Number: 14330
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    Sub-process markers are presented at pages 186-187. Does these markers
    (Compensation, Ad Hoc, Loop and MI) also apply to Call Activity and Event
    Sub-process? Is it none, some or all of them?

    According to the Class diagrams a Call Activity could not be Adhoc, but
    since a Call Activity extends from Activity it could be Loop or
    Compensation or Multi-instance?

    According to the same logic, an Event Subprocess could also have the same
    behavior plus Ad hoc.

    We feel these explicit lists should be presented in the spec instead of
    inferred from the class diagrams.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of this issue is part of 14423
    The new Chapter 13 contains a section that describes in detail which combinations are allowed:
    3.2.1 Markers for Activities
    Various BPMN Activities can be decorated with markers at the bottom center of the shape.
    Loop Characteristic markers may need to be rendered when the referenced BPMN model element [bpmnElement] of a BPMNShape is a Task, ServiceTask,
    SendTask, ReceiveTask, UserTask, ManualTask, BusinessRuleTask, ScriptTask, SubProcess, AdHocSubProcess, Transaction or CallActivity. Note that Loop
    Characteristic Markers (Loop, Multi-Instance - Parallel and Multi-Instance - Sequential) are mutually exclusive markers. That is, only one of them can be present on a
    single shape. See Table 8 - Depiction Resolution for Loop Characteristic Markers.
    A Compensation marker may need to be rendered when the referenced BPMN model element [bpmnElement] of a BPMNShape is a Task, ServiceTask, SendTask,
    ReceiveTask, UserTask, ManualTask, BusinessRuleTask, ScriptTask, SubProcess, AdHocSubProcess, Transaction or CallActivity. See Table 9 - Depiction
    Resolution for Compensation Marker
    In the case of expandable kind of shapes, the markers (Compensation or Loop Characteristic) are placed to the left of the + on the shape.
    The Compensation marker may be combined with a Loop Characteristic Marker. All the markers that are present must be grouped and the whole group centered to
    the bottom of the shape. See Figure 3 2 - Combined Compensation and Loop Characteristic Marker Example.
    Note that the in the case where the referenced BPMN model element [bpmnElement] of a BPMNShape is an AdHocSubProcess, the shape has its tilde marker to the
    right of the + (See section 3.2.6).
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 253, section 10.4.3 End Event Sequence Flow Connections

  • Key: BPMN2-61
  • Legacy Issue Number: 14336
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    The third structural specifications for an End Event in page 253 reads:"If
    the End Event is not used, then all Flow Objects that do not have any
    outgoing Sequence Flow (i.e. are not a source of a Sequence Flow) mark the
    end of a path in the Process."

    Is a "Throwing Link Intermediate Event" an exception to this statement?
    And, should it be indicated?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Section 10.4.3 End Event, page 222 (252 pdf), after 5th bullet on page (3rd 2nd level bullet): Add a third level bullet with the following text: "An exception to this
    are throwing Link Intermediate Events, which are not allowed to have outgoing Sequence Flow. See page 243 for more information on Link Intermediate Events."
    (b) Section 10.4.3 End Event, page 222 (252 pdf), after 5th bullet on page (3rd 2nd level bullet): Add a third level bullet with the following text: "An exception to this
    are Event Sub-Processes which are not allowed to have outgoing Sequence Flow. See page 155 for more information on Event Sub-Processes."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 192, Table 10-21 Transaction types need explanation

  • Key: BPMN2-60
  • Legacy Issue Number: 14335
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    At p. 192 of the specification, the TransactionMethod can be of type
    Compensate, Store,Image.

    A small text describing these variants would be useful, since only stating
    terms can lead to various interpretation.

    The same issue apply for the BPMN 1.2 specification at (p.281) B.11.19.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Table 10.21:
    Current:
    method: TransactionMethod = compensate

    { compensate | store | image }

    TransactionMethod is an attribute that defines the technique that will be used to undo a Transaction that has been cancelled. The default is compensate, but the attribute
    MAY be set to store or IMAGE.
    New:
    method: string
    TransactionMethod is an attribute that defines the transaction method used to commit or cancel a transaction. For executable processes, it SHOULD be set to a
    technology specific URI, e.g., http://schemas.xmlsoap.org/ws/2004/10/wsat for WS-AtomicTransaction, or http://docs.oasis-open.org/wstx/
    wsba/2006/06/AtomicOutcome for WS-BusinessActivity. For compatibility with BPMN 1.1, it can also be set to "##compensate", "##store", or "##image".

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 265, Sequence Flow Connections for Intermediate Events

  • Key: BPMN2-65
  • Legacy Issue Number: 14340
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    A structual specification says:"The Intermediate Events with the following
    Triggers MAY be used in normal flow: None, Message, Timer, Compensation,
    Conditional, Link, and Signal. Thus, the following MUST NOT: Canvel,
    Error, Multiple and Parallel Multiple."

    However, Table 10-82 (page 259) says for both (Multiple and Parallel
    Multiple Events) "If used within normal flow, the event can catch ...".

    Are Multiple and Paralle Multiple Events allowed on the normal flow?

    Also Escalation is missing from the list of MAY be used in normal flow

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Move Multiple and Parallel Multiple to the list of Event types that may be used in normal flow.
    Add Escalation to the list of Event types that may be used in normal flow.
    (a) Section 10.4.4, Sub-Section Sequence Flow Connections: replace 7th bullet on page with the following:
    "The Intermediate Events with the following Triggers (EventDefinition) MAY be used in normal flow: None,
    Message, Timer, Escalation, Compensation, Conditional, Link, Signal, Multiple, and Parallel Multiple. Thus, the following MUST NOT:
    Cancel and Error."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 265, Activity Boundary Connections

  • Key: BPMN2-64
  • Legacy Issue Number: 14339
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    In the structural specifications under "Activity Boundary Connections" the
    list of Intermediate Events that can be attached is provided (second
    structural spec.).
    In the structural specifications under "Sequence Flow Connections" the
    same list is provided (first sttructural spec.).
    Is it required to duplicate the list?

    The content of the list is different, Escalation is not included in the
    second list.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Remove redundant text from the Sequence Flow considerations of an Intermediate Event.
    (a) Section 10.4.4, Sub-Section "Sequence Flow Connections," page 237 (267 pdf): Remove first bullet in section
    (b) Section 10.4.4, Sub-Section "Sequence Flow Connections," page 237 (267 pdf): Change indent level to the left for the next bullet (after removing the first bullet

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 255, Message Flow connection for End Event

  • Key: BPMN2-62
  • Legacy Issue Number: 14337
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    The last two structural speficication at bottom of page 255 have errors.
    The first one has an extra sentence starting with If the Intermediate
    Event...

    The second structural specification should not be there.

    (BTW bullet should be diamonds here and many other places)

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The End Event Message Flow Connection definitions should have a parallel construction as the Start Event Message Flow Connections. Thus, the following changes
    will be made to the specification:
    (a) Section 10.4.3 End Event, Sub-Section "Message Flow Connections," page 225 (255 pdf), first bullet in section: Delete second sentence of bullet item.
    (b) Section 10.4.3 End Event, Sub-Section "Message Flow Connections," page 225 (255 pdf), second bullet in section: Delete entire bullet item and replace with the
    following text, "An End Event MAY be the source for Message Flow; it can have 0 (zero) or more outgoing Message Flow. Each Message Flow leaving the End Event
    will have a Message sent when the Event is triggered."
    (c) Section 10.4.3 End Event, Sub-Section "Message Flow Connections," page 225 (255 pdf), after the second bullet in section: Add a new sub-level bullet with the
    following text, "The Result attribute of the End Event MUST be set to Message or Multiple if there are any outgoing Message Flow."
    (d) Section 10.4.3 End Event, Sub-Section "Message Flow Connections," page 225 (255 pdf), after the second bullet in section: Add a new sub-level bullet with the
    following text, "The Result attribute of the End Event MUST be set to Multiple if there is more than one (1) outgoing Message Flow."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 251, Exceptions for Sequence Flow connections for Start Event

  • Key: BPMN2-59
  • Legacy Issue Number: 14334
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    In the structural specification on Sequence Flow Connections (page 251)it
    is written:"When a Start Event is not used, then all Flow Objects that do
    not have an incoming Sequence Flow SHALL be the start of a separate
    parallel path.

    Event Sub-process and Catching Intermediate Event Link are also exceptions
    to that?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Section 10.4.2 Start Event, page 214 (244 pdf), after last bullet on page: Add a second level bullet with the following text: "An exception to this are catching Link
    Intermediate Events, which are not allowed to have incoming Sequence Flow. See page 243 for more information on Link Intermediate Events."
    (b) Section 10.4.2 Start Event, page 214 (244 pdf), after last bullet on page: Add a second level bullet with the following text: "An exception to this are Event Sub-
    Processes, which are not allowed to have incoming Sequence Flow. See page 155 for more information on Link Intermediate Events."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 159, Section 10.1.2 number of types of diagrams

  • Key: BPMN2-55
  • Legacy Issue Number: 14329
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    Section 10.1.2, first sentence reads: "Some BPMN elements are common to
    both Process and Choreography, as well as Collaboration; they are used in
    both types of diagrams."

    Is the last part of the sentence, which reads: "they are used in both
    types of diagrams." applies to only two of them, which one are they?

    If not, the term "both" should be replaced by "all" or eliminated, or this
    statement reworked.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In Section 10.1.2 Use of BPMN Common Elements - first paragraph
    Replace the phrase: "they are used in both types of diagrams."
    With: "they are used in these diagrams."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 247 section Start Event for Event Sub-Processes

  • Key: BPMN2-58
  • Legacy Issue Number: 14332
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    The first sentence says:" A Start Event can also initiate an inline Event
    Sub-Process (see page 188). In that case, the same Event types as for
    boundary Events are allowed (see Table 10-79), namnely: Message, timer,
    Escalation, Error, Cancel, Compensation, Conditional, Signal, Multiple,
    and Parallel."

    Cancel should be removed from the list.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 10.4.2, Sub-Section "Start Events for Event Sub-Processes," page 217 (247 pdf), first paragraph: remove "Cancel" from the list of Event types

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 328, Section 11, Communication Link or Conversation Link

  • Key: BPMN2-66
  • Legacy Issue Number: 14341
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    At beginnig of section 11 it says: "The view includes two(2) additional
    graphical elements that do not exist in other BPMN views: A Communication,
    A CommunicationLink."

    The title of section 11.7 at page 338 is "Communicaion Link", however the
    descriptive text anf Figure refer to "Conversation Link".

    The graphical element a "Communication Link" should be "Conversation
    Link"?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of issue 14654 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 257, Intermediate Event Types in Normal flow

  • Key: BPMN2-63
  • Legacy Issue Number: 14338
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    The sentence above Table 10-82 says: "Nine(9) of the eleven (11)
    Intermediate Event ...."
    Table 10-82 shows 10 Events and not 9 and page 256 indicates and lists
    twelve (12) Intermediate Events.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 10.4.4, page 226 (256 pdf), last sentence on page: change "Nine (9) of the eleven (11)" to "Ten (10) of the twelve (12)"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 223, Figure 10-57 Unclear usage of IsCollection attribute for DataOutput

  • Key: BPMN2-47
  • Legacy Issue Number: 14320
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    In Figure 10-57, we can see that the DataOutput has a isCollection
    attribute as well as in Table 10-54 on page 224. The DataOutput also has
    itemSubjectRef attribute that is inherited from ItemAwareElement. This
    attribute is of type ItemDefinition and specifies the isCollection
    attribute.

    When we read the description on table 10-54 on page 224 for the
    isCollection attribute the following: "Defines if the DataOutput
    represents a collection of elements. This is a projection of the same
    attribute of the referenced ItemDefinition."

    I wonder why we need to have it defined both in DataOutput and
    ItemDefinition if the attribute in DataOutput is the "same".

    Is this denormalisation for the purpose of drawing a collection that has
    not be concretized by a ItemDefinition?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) in Section 10.3.1 Data Modeling, Sub-Section "Data Object," page 184 (214 pdf), Table 10.47, first row, second column: Remove second sentence in table cell,
    which was: This is a projection of the same attribute of the referenced ItemDefinition."
    (b) in Section 10.3.1 Data Modeling, Sub-Section "Data Object," page 184 (214 pdf), Table 10.47, first row, second column: Add the following sentence after the
    first sentence in table cell: "It is needed when no itemDefinition is referenced. If an itemDefinition is referenced, then this attribute MUST have the same value as the
    isCollection attribute of the referenced itemDefinition. The default value for this attribute is "false"."
    (c) in Section 10.3.1 Data Modeling, Sub-Section "Data Input," page 193 (223 pdf), Table 10.53, fifth row, second column: Remove second sentence in table cell,
    which was: This is a projection of the same attribute of the referenced ItemDefinition."
    (d) in Section 10.3.1 Data Modeling, Sub-Section "Data Object," page 293 (223 pdf), Table 10.53, fifth row, second column: Add the following sentence after the
    first sentence in table cell: "It is needed when no itemDefinition is referenced. If an itemDefinition is referenced, then this attribute MUST have the same value as the
    isCollection attribute of the referenced itemDefinition. The default value for this attribute is "false"."
    (e) in Section 10.3.1 Data Modeling, Sub-Section "Data Output," page 195 (225 pdf), Table 10.54, fifth row, second column: Remove second sentence in table cell,
    which was: This is a projection of the same attribute of the referenced ItemDefinition."
    (f) in Section 10.3.1 Data Modeling, Sub-Section "Data Output," page 295 (225 pdf), Table 10.54, fifth row, second column: Add the following sentence after the first
    sentence in table cell: "It is needed when no itemDefinition is referenced. If an itemDefinition is referenced, then this attribute MUST have the same value as the
    isCollection attribute of the referenced itemDefinition. The default value for this attribute is "false"."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 149, Figure 9-6 Multi-instance marker no depiction for white box pools

  • Key: BPMN2-46
  • Legacy Issue Number: 14319
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    The example on p. 149 shows the multi-instance marker for a black box pool.
    But there is no depiction of it for white box pools.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The resolution of this issue in include in 14423
    The Text below Figure 8.42 currently says:
    "When the minimum attribute of the ParticipantMultiplicty element has been set by the modeler, then the multiinstance
    marker will be displayed in bottom center of the Pool (Participant - see Figure 8-41) or the Participant Band
    of a Choreography Activity (see page 356)."
    Propsal:
    We assume that the rendering for the multi instance marker of a pool is rendered regardless if the pool is white box or black box.
    Chapter 13 in the current proposal does not explitily differentiate between black box and white box pools, as the only difference are the (not) contained BPMNShapes.
    And Table 27 in current Chapter 13 defines the depiction of the Multi Instance Marker only dependent on the ParticipantMultiplicity.
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 149, Figure 9-6 Vertical pool markers placement depiction

  • Key: BPMN2-45
  • Legacy Issue Number: 14318
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    It would be good to have a depiction of the Multi-instance marker in the
    Vertical Pool layout

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Figure 9.6 will be updated to include a vertically oriented pool that has a multi-instance marker. The updated figure is shown here:
    (10550_Update+to+Figure+9.6.jpg)
    (b) The figure caption to 9.6 will be changed to: "Pools with a Multi-Instance Participant Markers"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 028, Section 1, Wrong term for BPMN : Business Process Modeling Notation

  • Key: BPMN2-50
  • Legacy Issue Number: 14323
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    BPMN 2.0, term is Business Process Model and Notation

    Same issue at page 40, section 7, 3rd paragraph.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) on Cover Page, Title of Specification: change "Business Process Modeling Notation" to "Business Process Model and Notation"
    (b) In Section 1, on page 1 (31 pdf), first sentence in first paragraph of section: change "Business Process Modeling Notation" to "Business Process Model and
    Notation"
    (c) In Section 1, on page 1 (31 pdf), second sentence in third paragraph of section: change "business process modeling notation" to "business process model and
    notation"
    (d) In Section 7, on page 13 (43 pdf), first sentence in third paragraph of section: change "Business Process Modeling Notation" to "Business Process Model and
    Notation"
    (e) In Footers (most pages): change "Business Process Modeling Notation" to "Business Process Model and Notation"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 115-120 Distinguishing Initiating and Non-Inititating Messages

  • Key: BPMN2-49
  • Legacy Issue Number: 14322
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    Page 115 Structural Specifcation says that Any Message that is after the
    first on the list of Messages for a Choreography Task or Choreography
    Subproces.....

    What about Collaboration Diagrams that do not include Choreography
    tasks...how do we determine Initiating and Non-Initiating

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Collaboration diagrams do not contain the information to define initiating messages. This is done in Choreography through the Choreography Activities (which is a
    mechanism to organize the message flow).
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 153, Figure10-1, Link Events not paired may lead to confusion

  • Key: BPMN2-54
  • Legacy Issue Number: 14328
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    In figure 10-1 the throwing Link Intermediate Event and the catching Link
    Intermediate Event may lead to confusion to the reader, i.e. someone could
    think that they should be paired where probably this is a diagram fragment
    and they should not be paired.

    The diagram presented is not a complete process but a fragment of a
    process due to the presence of Intermediate Link Events not paired and
    the "Discussion Cycle" Sub-process without not directing to a proper "End".

    Should the diagram be replaced or an identification provided that it shows
    an incomplete fragment of a larger process?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    To avoid the potential confusion mentioned in the issue, replace Figure 10.1, page 121 (151 pdf) with the figure seen here:
    (10589_Replacement+for+Figure+10.1.jpg)

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 056, Table 7-2, Compensation Association: Usage of term Compensate Event

  • Key: BPMN2-53
  • Legacy Issue Number: 14326
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    At row "Compensation Association" the text indicates " .... or a throw
    Compensate Event". Throughout the document the term "Compensation Event"
    is used, should this text also use the term "Compensation Event" instead?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Table 7.2, page 28 (58 pdf), first row on page, second column: replace "Compensate Event" with "Compensation Event"
    (b) Section 13.2.4, Sub-Section "CompensationFlowConnector," page 371 (401 pdf), first sentence on page: "Compensate Event" with "Compensation Event"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 063, Section 7.4 Undefined term "Flow"

  • Key: BPMN2-43
  • Legacy Issue Number: 14316
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    The first structural specification bullet of section 7.4 refers to "Flow"
    Where is "Flow" defined?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 7.4, page 34 (64 pdf), bullet on page: change "Flow objects and Flow MAY" to "BPMN elements (e.g., Flow Objects) MAY"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 050, 061 and 417 Group text implies that only activites can be within a Group

  • Key: BPMN2-42
  • Legacy Issue Number: 14315
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    These texts of those pages specifies that a Group is a grouping of
    Actiovities that are within the same category. In fact a Group is tied to
    the Category supporting element (which is an attribute of all BPMN
    elements) (page 089). Thus the texts are somewhat misleading.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Table 7.1, page 22 (52 pdf), fifth row on page, second column, first sentence: change "grouping of Activities" to "grouping of graphical elements"
    (b) Table 7.1, page 22 (52 pdf), fifth row on page, second column, second sentence: remove "of the Activities"
    (c) Table 7.2, page 32 (62 pdf), third row on page, second column, first sentence: change "grouping of Activities" to "grouping of graphical elements"
    (d) Table 7.2, page 32 (62 pdf), third row on page, second column, second sentence: remove "of the Activities"
    (e) Section 13.2.5, Sub-Section "GroupShape," page 380 (410 pdf), first sentence: change "grouping of Activities" to "grouping of graphical elements"
    (f) Section 13.2.5, Sub-Section "GroupShape," page 380 (410 pdf), second sentence: remove "of the Activities"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 054, Table 7-2, Gateway Control Types: Incomplete statement

  • Key: BPMN2-52
  • Legacy Issue Number: 14325
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    The sentence " Both Exclusive (see page 298) and Event-Based (see page
    307). " is incomplete and leads to confusion while reading the text.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Table 7.2, row for "Gateway Control types," second column: replace "Both Exclusive (see page 298) and Event-Based (see page 307)" with "Both Exclusive (see page
    298) and Event-Based (see page 307) perform exclusive decisions and merging."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 049, Table 7-1 Depiction of Lanes with single lines to separate Lane name to Lane content

  • Key: BPMN2-51
  • Legacy Issue Number: 14324
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    The Lane depiction included in the table shows Lanes with single lines to
    seperate Lane name to Lane content.

    According to structural specification of page 316, Section 10.7, these
    lines should not be there. Should the figure presented excludes these
    lines as shown in Figure 10-119 at page 317?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close this issue as a duplicate.
    The resolution of issue 14250 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 060, Table 7-2, Merging: No depiction of implicit merge

  • Key: BPMN2-41
  • Legacy Issue Number: 14314
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    Under the title Merging : The text talks of the possibility of an
    alternative
    representation of a merge (i.e two sequence flows entering an activity)
    but does not
    depict it or specifies it as an implicit merge

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Table 7.2, row for "Merging," third column: add a figure showing implicit merging below the current figure (see
    (Figure+added+to+Table+7-2.jpg)
    )
    (b) Table 7.2, row for "Merging," second column: add appropriate references to the two figures in column 3

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 058, Table 7-2, Fork: Questionable affirmation

  • Key: BPMN2-40
  • Legacy Issue Number: 14313
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    Under the title Fork: it is stated that "uncontrolled" flow is the
    preferred method
    for most situations is a questionable affirmation.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The FTF could not determine a proper resolution and will defer the resolution to a later RTF
    Disposition: Deferred

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 187, Figure 10-27 Inconsistent use of class hierarchy vs. attributes to define types of subprocess

  • Key: BPMN2-44
  • Legacy Issue Number: 14317
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    Both Adhoc and Transaction arepresented as specialized class of
    SubProcess, why not the same for Event SubProcess

    On page 187, Figure 10-27, the attribute triggeredByEvent
    defines if the sub-process is an event sub-process. But on page on p. 188
    it is stated that an event is a specialized sub-process. If I take a look
    at the model is says that an ad hoc and transaction can also be
    event-sub-proceses.

    Leads to confusion regarding possible Event based transactions or Event
    Based Adhoc

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Event Sub-Processes should be allowed to be either Ad Hoc or Transactions. Thus, no change is recommended and this issue should be closed.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 253 and 257, Table 10-81 and 10-82 EventDefintion used for Events

  • Key: BPMN2-48
  • Legacy Issue Number: 14321
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    On p.246 of the specification, The EventDefinition used for each start
    event type are explicitly listed.

    But in table 10-81 and 10-82 it is provided only for the None and
    Multiple. For consistency it should probably listed in all of them here
    too.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The specification text was corrected before the initial Beta 1 version was released. So we can close this issue as it needs no changes.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 357, Figure 12-17 and 12-18 Participant names not identical

  • Key: BPMN2-28
  • Legacy Issue Number: 14300
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jul 07, 2009

    Figure 12-18 is stated to be a different representation of Figure 12-17.

    However, the Participant names are different, Participant 1 and 2 in
    Figure 12-17 and Participant A and B in Figure 12-18.

    They should be the same.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    All figures showing generic Participant names shall use the convention of letters in the name (e.g., Participant A, Participant B)
    (a) Figure 12.17 will be updated with this convention. The update figure can be seen here:
    (10551_Update+to+Figure+12.17.jpg)
    b) Figures 12.8, 12.12, 12.15, 12.21, 12.22 will also be updated .The updates to these figures are not shown here.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 353, Figure 12-11, inapropriate caption

  • Key: BPMN2-27
  • Legacy Issue Number: 14299
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jul 07, 2009

    The caption of Figure 12-11 is "Choreography Task". It should be "A
    Collaboration view of a two-way Choreography Task element".

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close this issue as a duplicate.
    The resolution of issue 14298 will resolve this issue
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 352, Figure 12-9, inapropriate caption

  • Key: BPMN2-26
  • Legacy Issue Number: 14298
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jul 07, 2009

    Figure 12-9 caption is "Choreography Task". It should be "A Collaboration
    view of Choreography Task elements".

    The sentence below this figure makes reference to Figure 12-7. The
    reference should be to Figure 12-9.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) In Section 12.4.1, on page 317 (347 pdf), caption for Figure 12-9: change "A Choreography Task" to "A Collaboration view of a Choreography Task"
    (b) In Section 12.4.1, on page 317 (347 pdf), first sentence in first paragraph on page (change "see Figure 12-7" to "see Figure 12-9")
    (c) In Section 12.4.1, on page 318 (348 pdf), caption for Figure 12-11: change "A Choreography Task" to "A Collaboration view of a two-way Choreography Task"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 408, Section 13.2.5 Event Sub-process not included

  • Key: BPMN2-34
  • Legacy Issue Number: 14307
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jul 09, 2009

    The Event Sub-process is not presented in the list of BPMN shapes, even if
    it has a distinctive aspect.

    Comment 1 by dga...@trisotech.com, Jul 10, 2009

    All shapes are presented in this section, but the Event Sub-process is not presented
    in the list of BPMN shapes, even if it has a distinctive "shape".

  • Reported: BPMN 2.0b1 — Thu, 3 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    A full new chapter covering this issue is included in the final report
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 242-243 Tables 10-75 and 10-76

  • Key: BPMN2-33
  • Legacy Issue Number: 14306
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    eported by dga...@trisotech.com, Jul 08, 2009

    Cardinality of eventDefinitions is not same that in schema of page 290 and
    294

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Replace the contents of Table 10.97, page 258 (288 PDF) with the following:
    <xsd:element name="catchEvent" type="tCatchEvent"/>
    <xsd:complexType name="tCatchEvent" abstract="true">
    <xsd:complexContent>
    <xsd:extension base="tEvent">
    <xsd:sequence>
    <xsd:element ref="dataOutput" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="dataOutputAssociation" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="outputSet" minOccurs="0" maxOccurs="1"/>
    <xsd:element ref="eventDefinition" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element name="eventDefinitionRef" type="xsd:QName" minOccurs="0" maxOccurs="unbounded"/>
    </xsd:sequence>
    <xsd:attribute name="parallelMultiple" type="xsd:boolean" default="false"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>
    (b) Replace the contents of Table 10.114, page 262 (292 PDF) with the following:
    <xsd:element name="throwEvent" type="tThrowEvent"/>
    <xsd:complexType name="tThrowEvent" abstract="true">
    <xsd:complexContent>
    <xsd:extension base="tEvent">
    <xsd:sequence>
    <xsd:element ref="dataInput" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="dataInputAssociation" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element ref="inputSet" minOccurs="0" maxOccurs="1"/>
    <xsd:element ref="eventDefinition" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element name="eventDefinitionRef" type="xsd:QName" minOccurs="0" maxOccurs="unbounded"/>
    </xsd:sequence>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 243, Table 10-76 eventDefinitionRefs and eventDefinitions descriptions

  • Key: BPMN2-32
  • Legacy Issue Number: 14305
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 08, 2009

    The two texts need to be reviewed

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue is resolved as part of issue 14304
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 242, Table 10-75 eventDefintionsRefs and eventDefinitions descriptions are identical

  • Key: BPMN2-31
  • Legacy Issue Number: 14304
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 08, 2009

    Seems to be a copy/paste error

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    a) in Table 10.75 CatchEvent attributes and model associations
    1 - For the eventDefinitionRefs Attribute, replace the following text:

    • "EventDefinitionRefs (EventDefinition) is an attribute that defines the type of reusable triggers expected for a catch Event. "
      with the following text:
    • "References the reusable event definitions that are triggers expected for a CatchEvent. Reusable event definitions are defined as top-level elements. These event
      definitions can be shared by different Catch and Throw Events."
      2 - For the eventDefinitions Attribute, replace the following text:
    • "EventDefinitionRefs (EventDefinition) is an attribute that defines the type of contained results expected for a throw Event."
      with the following text:
    • "Defines the event definitions that are triggers expected for a CatchEvent. These event definitions are only valid inside the current Event."
      b) in Table 10.76 ThrowEvent attributes and model associations
      1 - For the eventDefinitionRefs Attribute, replace the following text:
    • "EventDefinitionRefs (EventDefinition) is an attribute that defines the type of reusable triggers expected for a throw Event."
      with the following text:
    • "References the reusable event definitions that are results expected for a ThrowEvent. Reusable event definitions are defined as top-level elements. These event
      definitions can be shared by different Catch and Throw Events."
      2 - For the eventDefinitions Attribute, replace the following text:
    • "EventDefinitionRefs (EventDefinition) is an attribute that defines the type of contained results expected for a throw Event."
      with the following text:
    • "Defines the event definitions that are results expected for a ThrowEvent. These event definitions are only valid inside the current Event."
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 175, Table 10-11, Spelling of Business in Attribute Name

  • Key: BPMN2-30
  • Legacy Issue Number: 14302
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 08, 2009

    On p. 175 BusinesRuleTaskImplementation should be
    BusinessRuleTaskImplementation and
    BuisnessRuleWebService should be BusinessRuleWebService.

    Spelling of Business

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Table 10.11, Column 1, Row 1: Change "BusinesRuleTaskImplementation" to "BusinessRuleTaskImplementation"
    (b) Table 10.11, Column 1, Row 1: Change "BuisnessRuleWebService" to "BusinessRuleWebService"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 370, Table 12-6, references to Event Sub-Process

  • Key: BPMN2-29
  • Legacy Issue Number: 14301
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by asir...@trisotech.com, Jul 07, 2009

    In Table 12-6, many references are made to the use of different types of
    Start Events for Event Sub-Processes.

    Are Event Sub-Processes part of a Choreography diagram or are Event Sub-
    Processes represented by Choreography Sub-Processes in a Choreography
    diagram, like other Sub-processes involved in Message exchange between
    Participants?

    If Event Sub-Processes are not pat of a Choreography diagram why all these
    references to Event Sub-Processes in the Choreography section?

    Comment 1 by dga...@trisotech.com, Jul 13, 2009

    If Event Sub-Processes are not part of a Choreography diagram why all these
    references to Event Sub-Processes in Table 12-6

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Table 12.6: Use of Start Events in Choreography
    (a) Row for Escalation: add the following in column 2: "No. An Escalation is only visible to a single Participant. That Participant will have to send a Message to the
    other Participants."
    (b) Row for Compensation: add the following in column 2: "No. Compensation is handled within a single Participant (anorchestration Process)."

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 243 Table 10-76 the definition of EventDefinitionRefs and eventDefinitions is duplicated in ThrowEvent and CatchEve

  • Key: BPMN2-37
  • Legacy Issue Number: 14310
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    On p.243, the definition of EventDefinitionRefs and eventDefinitions is
    duplicated in ThrowEvent Table 10-76 and CatchEvent Table 10-75.

    All events either inherit from
    ThrowEvent or CatchEvent, so why not define these attributes in the Event
    class instead, in order to avoid duplication?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue is merged with 14304
    Disposition: Duplicate

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 165, Table 10-7 Required attribute cardinality explicitly defined

  • Key: BPMN2-36
  • Legacy Issue Number: 14309
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 13, 2009

    The cardinality of parameterRef is specified as [1].
    In other cases when attributes are required the cardinality is not
    specified

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Table 10.7, page 133 (163 pdf), first row, first column: delete "[1]"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 047, Section 7.2 Properties is presented as a Data element

  • Key: BPMN2-39
  • Legacy Issue Number: 14312
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    Page 047, Section 7.2 Properties is presented as a Data element
    Not sure we understand that one yet.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    All the elements listed in section 7.2 are graphical elements except for Properties. Thus, it should be removed from the list:
    (a): Section 7.2, page 20 (50 pdf), last bullet in list for Data: remove bullet item
    (b): Section 7.2, page 20 (50 pdf), Data section description: change "five (5) elements" to "four (4) elements"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

The attribute name is duplicated across many, many, many classes

  • Key: BPMN2-38
  • Legacy Issue Number: 14311
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    The attribute "name" is duplicated across many, many, many classes.

    Why not have a new "NamebleElement" class that specify the name or putting
    it in
    BaseElement instead of having it duplicated in many places?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This is not an implementation issue.
    Disposition: Closed, No Change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 331, Typo Figure references 11-3 but should be 11-4

  • Key: BPMN2-35
  • Legacy Issue Number: 14308
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 13, 2009

    The first sentence under figure 11-4 says: In figure 11-3...
    should be figure 11-4

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In Section 11, on page 296 (326 pdf), first sentence in first paragraph after Figure 11-4: change "Figure 11-3" to "Figure 11-4"

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 29, Section 7.2.2 - Fork and Join Differentiation

  • Key: BPMN21-376
  • Legacy Issue Number: 14349
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    BPMN says that you use a parallel gateway (diamond with a plus in it) to start a sequence of parallel paths, and another AND gateway to end it. The behaviors of these two gateways are different, but they look the same. Suggestion is that the first AND gateway, that starts the parallel split have a thin line, while the gateway at the end which actually waits for multiple inputs will have a thick line. This corresponds to the thin and thick lines around start and end nodes.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Typo: Data Object spelled Objec

  • Key: BPMN21-372
  • Legacy Issue Number: 19666
  • Status: open  
  • Source: gmail.com ( William Lopez Campo)
  • Summary:

    In the image of Table 7.2 for Data Object, next to the Data Object (Collection) it reads Data Objec (Collection).

  • Reported: BPMN 2.0 — Fri, 28 Nov 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

word catalogue in the Figure 5.3: Order Fulfillment

  • Key: BPMN21-370
  • Legacy Issue Number: 19600
  • Status: open  
  • Source: Anonymous
  • Summary:

    I found a tiny error in the document which is titled as
    dtc-10-06-02.pdf (BPMN 2.0 by Example Version 1.0) i hope you'll
    correct it.

    the error is in the word catalogue in the Figure 5.3: Order Fulfillment

  • Reported: BPMN 2.0 — Mon, 15 Sep 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing event marker in Figure 10.30

  • Key: BPMN21-369
  • Legacy Issue Number: 19473
  • Status: open  
  • Source: omninet.de ( Frank Munkert)
  • Summary:

    The specification says: "If the Event Sub-Process is collapsed, then its Start Event will be used as a marker in the upper left
    corner of the shape (see Figure 10.30)."

    But the referenced figure does not show any marker event. Therefore, either the text or the figure is wrong.

  • Reported: BPMN 2.0.2 — Mon, 16 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

figure 13.1

  • Key: BPMN21-368
  • Legacy Issue Number: 19471
  • Status: open  
  • Source: Anonymous
  • Summary:

    I may be wrong but I assume figure 13.1 is wrong

  • Reported: BPMN 2.0 — Sun, 15 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bug p385

  • Key: BPMN21-367
  • Legacy Issue Number: 19470
  • Status: open  
  • Source: Anonymous
  • Summary:

    ??

    I found a problem in illustration 11.43 (p385 of pdf & p355 of norm) . The message flow between participant A & participant B is not well definied. Direction need to be change (from participant B to participant A & not from A to B).
    It's the same for figure 11.45 (message flow from participant B to participant A and not from participant A to participant B)

    ??

  • Reported: BPMN 2.0 — Sat, 14 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.3.4 Human Performer is not peorperly defined for implementation interpretation

  • Key: BPMN21-366
  • Legacy Issue Number: 19461
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    It is not specifically stated in the spec whether "HumaPerformer" is an abstract class.
    It seems to be, but then the meta model (fig 10.23) depicts only one specialization namely "PotentialOwner" leaving in question the need for this abstraction.
    Furthermore "PotentialOwner" only

  • Reported: BPMN 2.0.2 — Wed, 11 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

bug issue concerning event-based gateway illustration 10.98

  • Key: BPMN21-365
  • Legacy Issue Number: 19414
  • Status: open  
  • Source: Anonymous
  • Summary:

    Figure 10.98 need another type of gateway.

    This gateway is not correct because it is lauching process activity.

    It would be correct with a complex start event within gateway (not an intermediate as it is).

  • Reported: BPMN 2.0 — Tue, 13 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

bug issue concerning event-based gateway

  • Key: BPMN21-364
  • Legacy Issue Number: 19413
  • Status: open  
  • Source: Anonymous
  • Summary:

    I read BPMN 2.0.2 specification and I found a mistake on a table (I think):

    P329 of PDF or p299 of BPMN specification :

    The attribute can only be set to parallel when the instantiate attribute is set to true.

    I assume its wrong. A better sentence would be :

    The attribute can only be set to parallel when the instantiate attribute is set to false.

    Am I correct ?

  • Reported: BPMN 2.0 — Tue, 13 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

[BPMN 2.0.2] bug issue concerning event sub process

  • Key: BPMN21-363
  • Legacy Issue Number: 19352
  • Status: open  
  • Source: Anonymous
  • Summary:

    I read BPMN 2.0.2 specification and I found a mistake on an illustration??(I think):

    p174 (205 of PDF) ??:

    If the Event Sub-Process is collapsed, then its Start Event will be used as a marker in the upper left corner of the shape (see Figure 10.30).

    P175

    There is no marker in the upper left corner of the collapsed event sub-process

  • Reported: BPMN 2.0 — Tue, 22 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sequencing rule for Choreography activities causes ambiguous execution semantics?

  • Key: BPMN21-362
  • Legacy Issue Number: 19318
  • Status: open  
  • Source: planet.nl ( kwantes)
  • Summary:

    (p.336 The basic rule of Choreography Activity sequencing is this: ?The Initiator of a Choreography Activity MUST have been involved (as Initiator or Receiver) in the previous Choreography Activity.
    As far as I can tell this rule seems to imply some ambiguity as to the execution semantics of the Choreography diagram. To explain this, I give an example of two different Choreography designs of one and the same collaboration:
    Design version 1 involves 5 message exchanges , three choreography activities A, B and C and 4 participants, 1,2,3 and 4. The activities are listed below in execution order :
    1. Activity A :
    1.1. 1 sends message to 2
    2. Activity B:
    2.1. 3 sends message to 2
    2.2. 2 sends message to 4
    2.3. 4 returns message to 2
    3. Activity C:
    3.1. 2 sends confirmation of message sent by 1 (in 1.1.)

    Design version 2 involves the same 5 message exchanges into two choreography activities A and B involving the same 4 participants listed below in execution order:
    1. Activity A :
    1.1. 1 sends message to 2
    1.2. 2 sends confirmation of message sent by 1 (in 1.1., but after receiving message sent by 4 in 2.3.)
    2. Activity B:
    2.1. 3 sends message to 2
    2.2. 2 sends message to 4
    2.3. 4 returns message to 2

    {Question 1: are observations below correct or not? }

    Both designs seem to meet the criterion mentioned in the BPMN standard specification mentioned in the first paragraph above. The second has the advantage that the message exchanges 1.1. and 1.2. which are logically strongly related are combined in one activity. But the execution semantics implied by the two designs are quite different. The first design implies that an activity can only start after completion of the previous activity. The second design implies that an activity can only start after the previous activity has started. The basic rule of Choreography Activity sequencing seems to allow both interpretations.

    {Question 2: is the issue below a valid point in your opinion ? }

    If the first interpretation is chosen, then there is the question what is meant by “completion”. That might mean different things for the sender and receiver of the last message exchanged. The sender is finished when he sent the last message. The receiver might first need to do some internal processing before it is completed. So this interpretation runs the risk of being ambiguous.

    {Question 3: can you please comment on this ? }

    The second interpretation could make it less straightforward to understand the ordering of activities from the diagram. On the other hand it does allow more room for combining logically related message exchanges in one activity (as 1.1. and 1.2. in activity A in the second interpretation). This raises the general question on how the Choreography diagrams and Conversation diagrams are conceptually related. They seem to be addressing a similar requirement for expressing communication between Business actors, but it is unclear how they are or should be related.

  • Reported: BPMN 2.0 — Sun, 30 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Allowable start events for event sub-process inconsistently defined

  • Key: BPMN21-359
  • Legacy Issue Number: 19166
  • Status: open  
  • Source: outlook.com ( Devin Fensterheim)
  • Summary:

    There is an apparent conflict in the specification concerning the permissible Start Event types for an Event Sub-Process.

    On Page 174, the specification states: "The Start Event of an Event Sub-Process MUST have a defined trigger. The Start Event trigger (EventDefinition) MUST be from the following types: Message, Error, Escalation, Compensation, Conditional, Signal, and Multiple." This enumeration excludes the Timer and Parallel event types.

    This specification appears inconsistent with the restriction on Page 241, which additionally allows Timer and Parallel event types for the Start Event: "A Start Event can also initiate an inline Event Sub-Process (see page 174). In that case, the same Event types as for boundary Events are allowed (see Table 10.86), namely: Message, Timer, Escalation, Error, Compensation, Conditional, Signal, Multiple, and Parallel."

    It is consequently unclear whether Timer and Parallel events may be the Start Event in an Event Sub-Process.

  • Reported: BPMN 2.0.1 — Mon, 23 Dec 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

References to invalid sub clauses (incorrect sub clause numbers)

  • Key: BPMN21-358
  • Legacy Issue Number: 19092
  • Status: open  
  • Source: RealDolmen NV ( Steve van den Buys)
  • Summary:

    In chapter 2, sub clause 2.1, page 1 it is written that "Process Modeling Conformance type SHALL comply with all of the requirements set forth in sub clause 2.1". However, the requirements are set forth in sub clause 2.2. Also, the sentences after that refer to sub clauses 2.2, 2.3 and 2.4 but these should refer to 2.3, 2.4 and 2.5.

    In short: references to the requirements for the different conformance types should be to 2.2, 2.3, 2.4 and 2.5 and not 2.1, 2.2, 2.3 and 2.4.

  • Reported: BPMN 2.0.1 — Mon, 18 Nov 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Invalid use of MAY NOT keyword

  • Key: BPMN21-361
  • Legacy Issue Number: 19196
  • Status: open  
  • Source: omninet.de ( Frank Munkert)
  • Summary:

    In several occasions, the BPMN 2.0.1 specification uses the keywords "MAY NOT". This keywords, however, are not valid according to RFC 2119.

    Probably "MUST NOT" would be correct. (Please note: the opposite of "MAY" is not "MAY NOT"!)

  • Reported: BPMN 2.0.1 — Tue, 28 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong sub clauses are referenced

  • Key: BPMN21-360
  • Legacy Issue Number: 19176
  • Status: open  
  • Source: me.com ( Jonas Geißer)
  • Summary:

    Version 2.0.1 is still referring to the sub clauses 2.1-2.4 (as in Version 2.0) even though they have changed to 2.2-2.5

  • Reported: BPMN 2.0.1 — Tue, 7 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

major error in figures for corresponding diagrams

  • Key: BPMN21-278
  • Legacy Issue Number: 15955
  • Status: open  
  • Source: camunda services GmbH ( Matthias Schrepfer)
  • Summary:

    In the choreography diagram in figure 11.42 Participant B sends a message to Participant A.

    Figure 11.43 is the corresponding collaboration view. However, here Participant A sends a message to Participant B... Following, both figures are not equal, 11.43 is not the corresponding figure to 11.42...

    The same error occurs for figures 11.45 and 11.44

  • Reported: BPMN 2.0 — Fri, 14 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

conversion of choreographies to collaboration diagrams

  • Key: BPMN21-277
  • Legacy Issue Number: 15954
  • Status: open  
  • Source: camunda services GmbH ( Matthias Schrepfer)
  • Summary:

    The XOR-Gateways in choreographies are defined. Also the conversion of choreographies with XORs to collaboration diagrams is described, however there are two issues for the conversion.

    1st) The description in the specification states that event-based gateways should be used in collaboration. Figure 11.37 which depicts the example collaboration does not have any event-based gateway. So, please adapt the figure and show event-based gateways as following the description

    2nd) if event-based gateways are used, then a time-out can occur.. on page 361 this likely time-out is mentioned... Please update the section on p359 accordingly to inform and consult the reader.

  • Reported: BPMN 2.0 — Fri, 14 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

number of start events for sub-processes

  • Key: BPMN21-282
  • Legacy Issue Number: 15959
  • Status: open  
  • Source: camunda services GmbH ( Matthias Schrepfer)
  • Summary:

    The specification defines that the type for start-events of sub-processes can only be the none-type... However, the allowed number of start events for sub-processes is not mentioned... at least I couldn't find it throughout the whole specification.

    As far as I understood BPMN, two none-typed start-events in sub-processes would not make sense but the point should clearly be described in a specification.

  • Reported: BPMN 2.0 — Fri, 14 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

enumeration missing

  • Key: BPMN21-281
  • Legacy Issue Number: 15958
  • Status: open  
  • Source: camunda services GmbH ( Matthias Schrepfer)
  • Summary:

    On page the call activity is explained. In the enumeration starting with "If the Call Activity calls a Process, then there are two (2) options:........" there is only option displayed.
    The second option is not shown as enumeration but with pure text. The text for the second option is "If the details of the called Process are available, then the shape of the Call Activity will be the same as a expanded
    Sub-Process, but the boundary of the shape MUST have a thick line (see Figure 10.41)."

    Please update the enumeration

  • Reported: BPMN 2.0 — Fri, 14 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CallChoreographyActivity notation for called participants

  • Key: BPMN21-290
  • Legacy Issue Number: 16009
  • Status: open  
  • Source: University of Bamberg ( Andreas Schörger)
  • Summary:

    The notation for CallChoreographyActivity
    should show which of the caller's participants
    (the ones in the bands) are associated with
    which called participants by participant
    associations. Perhaps this could be shown in
    the bands. Compare to the notation for
    participant associations in the
    CallConversation notation Figure 9.30
    (Call Conversation Links).

  • Reported: BPMN 2.0 — Mon, 7 Feb 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incoming/Outgoing Data Associations of DataInputs/Outputs

  • Key: BPMN21-289
  • Legacy Issue Number: 16003
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to page 213:
    Data Inputs MAY have incoming Data Associations

    and page 215:
    Data Outputs MAY have outgoing DataAssociations

    I think that it should be the other way round. A Data Input should have an outgoing Data Association and a Data Output should have an incoming DataAssociation. This would correspond with Figure 7.8. The Data Input "Part Requisition" only has an outgoing Data Association and vice versa, the Data Output "Part Requisition" only has an incoming Data Association.

  • Reported: BPMN 2.0 — Wed, 2 Feb 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Cardinality of id in BaseElement

  • Key: BPMN21-286
  • Legacy Issue Number: 15974
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to Table 8.5 the id of BaseElement is of type string, and since no cardinality is specified, the cardinality is assumed to be [1]. However, according to the corresponding text:
    If the element is not currently referenced and is never intended to be referenced, the id MAY be omitted.

    If the id can be omitted, then the cardinality should be [0..1].

  • Reported: BPMN 2.0 — Thu, 20 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Relationship from Choreography to Artifacts

  • Key: BPMN21-285
  • Legacy Issue Number: 15973
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to Figure 8.8, Process and Sub-Process as well as Collaboration and Sub-Choreography have a relationship to artifacts. However, Choreography is missing.

    In the text above, Choreography is mentioned:
    When an Artifact is defined it is contained within a Collaboration or a FlowElementsContainer (a Process or Choreography).

    Furthermore, section 11.3.2 specifies:
    Both Text Annotations and Groups can be used within Choreographies and all BPMN diagrams. There are no restrictions on their use.

  • Reported: BPMN 2.0 — Thu, 20 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect Section References

  • Key: BPMN21-288
  • Legacy Issue Number: 15992
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Section 2.2.1 refers to Chapter 14 (Execution Semantics). But this chapter is actually Chapter 13.
    Section 2.3 refers to Chapter 15 (BPEL Mapping). But this chapter is actually Chapter 14.
    These references should be fixed.

  • Reported: BPMN 2.0 — Thu, 27 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong document reference in dtc/2010-06-02


Procedure not defined

  • Key: BPMN21-292
  • Legacy Issue Number: 16049
  • Status: open  
  • Source: Telstra Coorporation ( John Raper)
  • Summary:

    The word procedure(s) is used 4 times in the document. It is not defined anywhere. Surely all instances of procedure should read "process".
    Otherwise it would be consistent to provide a definition of Procedure in Annex C

  • Reported: BPMN 2.0 — Thu, 10 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The XSLT for transforming to BPMN XMI has errors

  • Key: BPMN21-291
  • Legacy Issue Number: 16011
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The XSLT for transforming to BPMN XMI has errors.

    There are many places where XML attributes are output after child elements which causes Saxon at least to fail the transformation.

    Also, although not a fatal error, the XML namespaces for the source document should be removed from the target document.

    I have updated the file so that it works for me – and can make it available.

  • Reported: BPMN 2.0 — Mon, 7 Feb 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Content of Section missing

  • Key: BPMN21-280
  • Legacy Issue Number: 15957
  • Status: open  
  • Source: camunda services GmbH ( Matthias Schrepfer)
  • Summary:

    Just before Section 11.8 XML Schema for choreography there are two headings named "Choreography Task in Combined View" and "Sub-Choreography in Combined View". However, there is no content or description shown.

    Please update the sections with their content.

  • Reported: BPMN 2.0 — Fri, 14 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong diagram

  • Key: BPMN21-279
  • Legacy Issue Number: 15956
  • Status: open  
  • Source: camunda services GmbH ( Matthias Schrepfer)
  • Summary:

    In figure 11.47 the pool Participant B contains a parallel gateway. The parallel gateway is named with a decision and the answers as a XOR-gateway should be named.

    Please remove this description to follow the semantics of the parallel gateway

  • Reported: BPMN 2.0 — Fri, 14 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Typo on page 77 (physical page 107)

  • Key: BPMN21-284
  • Legacy Issue Number: 15971
  • Status: open  
  • Source: TIBCO ( Justin Brunt)
  • Summary:

    Typo on page 77 (physical page 107) in the penultimate paragraph "atleast" should be "at least".

  • Reported: BPMN 2.0 — Tue, 18 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Typo on page 76

  • Key: BPMN21-283
  • Legacy Issue Number: 15970
  • Status: open  
  • Source: TIBCO ( Justin Brunt)
  • Summary:

    In the final line on page 76 (106 in physical document) there is a typo:
    "For each Message that is exhanged as part of a particular Conversation". The word "exchanged" is missing the letter "c".

  • Reported: BPMN 2.0 — Tue, 18 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Normal Process Not Defined

  • Key: BPMN21-294
  • Legacy Issue Number: 16052
  • Status: open  
  • Source: Telstra Coorporation ( John Raper)
  • Summary:

    The term "normal Process" is used three times in the document, but it is not defined anywhere

  • Reported: BPMN 2.0 — Thu, 10 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Object mispelt

  • Key: BPMN21-293
  • Legacy Issue Number: 16051
  • Status: open  
  • Source: Telstra Coorporation ( John Raper)
  • Summary:

    Change Objec to Object in the Data Object line of Table 7.2

  • Reported: BPMN 2.0 — Thu, 10 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Second occurance of sequential Multi-Instances should be parallel

  • Key: BPMN21-374
  • Legacy Issue Number: 19709
  • Status: open  
  • Source: Anonymous
  • Summary:

    In Table 7.2 the text for Multiple Instances says the three vertical lines mean sequential MI. I believe it nust be parallel, three horizontal lines mean sequential.

  • Reported: BPMN 2.0.2 — Wed, 14 Jan 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use of per mille symbol unclear (‰)

  • Key: BPMN21-373
  • Legacy Issue Number: 19708
  • Status: open  
  • Source: Anonymous
  • Summary:

    In table 7.3 the per mille (‰) sign is used in the third column. I suspect the arrow was meant.

  • Reported: BPMN 2.0.2 — Wed, 14 Jan 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Is compensation allways triggered automatically upon uncaught errors?

  • Key: BPMN21-375
  • Legacy Issue Number: 16904
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    Page 180 (PDF 210) states:
    'Note that other mechanisms for interrupting a Transaction Sub-Process will not cause compensation (e.g., Error, Timer, and anything for a non-Transaction Activity).'

    Whereas page 305 (PDF 335) states:
    'If no error Event Sub-Process is specified for a particular Sub-Process and a particular error, the default behavior is to automatically call compensation for all contained Activities of that Sub-Process if that error is thrown, ensuring the behavior for auditing and monitoring.'

    These statements seem contradicting to me and therefore I'd like to get a clarification on the following questions:

    1. Is compensation allways triggered automatically upon uncaught errors?
    2. Is there a difference between compensation of a Transaction Sub-Process and any other Sub-Process?

  • Reported: BPMN 2.0 — Wed, 14 Dec 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN typo

  • Key: BPMN21-354
  • Legacy Issue Number: 18906
  • Status: open  
  • Source: yahoo.com ( Muhammad Saleem)
  • Summary:

    There is typo error of the word "variation". It is written as "va riation" in the document

  • Reported: BPMN 2.0 — Thu, 12 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Extend BPMN with a element that subclasses an existing BPMN element

  • Key: BPMN21-353
  • Legacy Issue Number: 18787
  • Status: open  
  • Source: Perceptive Software ( Mark van Roermund)
  • Summary:

    'Section 8.2.3 Extensibility' on page 57 of the BPMN 2.0 specification states:

    "The BPMN metamodel is aimed to be extensible. This allows BPMN adopters to extend the specified metamodel in a way that allows them to be still BPMN-compliant."

    On page 58 it is stated that:

    "Every BPMN element which subclasses the BPMN BaseElement can be extended by additional attributes. This works by associating a BPMN element with an ExtensionDefinition, which was defined at the BPMN model definitions level (element Definitions)."

    Question:
    Is it possible to extend BPMN with an element that subclasses an existing BPMN element?

    For example, is it possible to extend BPMN with a new task element that subclasses the BPMN Task, similar to how e.g. a ManualTask or UserTask subclasses the BPMN Task? If this is possible, could you provide an example?

  • Reported: BPMN 2.0 — Tue, 2 Jul 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

An invalid statement regarding Black Box depiction of pools

  • Key: BPMN21-356
  • Legacy Issue Number: 19068
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    In section 9.2
    First paragraph
    3rd bullet should be removed.
    It states
    "If the Pool is a black box (i.e., does not contain a Process), then the label for the Pool MAY be placed
    anywhere within the Pool without a single line separator."

    This is incorrect a pool always has a line separating the label. This is how one can visually distinguish between a pool and a a lane.

    All depictions in examples were corrected during FTF but this one line stayed behind and should be removed.

  • Reported: BPMN 2.0 — Wed, 6 Nov 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Editorial: Wrong description of Figure 10.79 in the text

  • Key: BPMN21-355
  • Legacy Issue Number: 18981
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    There is a Copy & Paste typo on page 265 (PDF 295).

    Text: "Figure 10.79 shows the variations of Conditional Events"
    Figure Caption: "Figure 10.79 ­ Error Events"

    Proposal:
    Change text to "Figure 10.79 shows the variations of Error Events"

  • Reported: BPMN 2.0 — Mon, 30 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Suspected definition error in DataObject.isCollection

  • Key: BPMN21-357
  • Legacy Issue Number: 19083
  • Status: open  
  • Source: Atom Software Pty Ltd ( Paul Hopkins)
  • Summary:

    In Table 10.52 the description of DataObject.IsCollection reads "If an itemDefinition is referenced, then this attribute MUST have the same value as the IsCollection attribute of the referenced itemDefinition".

    This description prevents BPMN from defining a collection of DataObjects on a single Item Aware Element referred to by an Item Definition. Therefore, if I wish to model an individual item X and a collection of item X they need to reference different item definitions - surely this is not the intent.

    I propose rewording this sentence to read "If a referenced itemDefinitions isCollection attribute is set to true, then this attribute MUST also be set to true".

    I don't know if there is a flow-on effect to other areas of the documentation.

  • Reported: BPMN 2.0.1 — Thu, 14 Nov 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Repeated use of previous definition for conflicting task attributes

  • Key: BPMN21-352
  • Legacy Issue Number: 18501
  • Status: open  
  • Source: googlemail.com ( Neil Glover)
  • Summary:

    Table 7.2 - BPMN Extended Modeling Elements

    Multiple Instances

    Definition of the use of vertical lines as a task attribute is incorrectly captured as the same as horizontal, as follows:

    A set of three
    horizontal lines will be displayed at the
    bottom-center of the activity for sequential
    Multi-Instances (see upper figure to the right).

    A set of three vertical lines will be displayed at
    the bottom-center of the activity for sequential Multi-Instances (see lower figure to the right).

    This should read as follows:

    A set of three
    horizontal lines will be displayed at the
    bottom-center of the activity for sequential
    Multi-Instances (see upper figure to the right).

    A set of three vertical lines will be displayed at
    the bottom-center of the activity for parallel Multi-Instances (see lower figure to the right).

  • Reported: BPMN 2.0 — Tue, 26 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Entire document

  • Key: BPMN21-351
  • Legacy Issue Number: 18403
  • Status: open  
  • Source: Anonymous
  • Summary:

    The OMG BPMN 2 Revision Task force is working to resolve editorial and clarification issues against the text in DIS 19510. It is important that the corrections resolving these defects be reflected in the published ISO/IEC Standard for OCL. The editing group for ISO/IEC DIS 19510 should consider all changes against the text of BPMN 2, resulting from the latest minor revision to BPMN 2 available at the time of the ballot resolution meeting

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Title

  • Key: BPMN21-350
  • Legacy Issue Number: 18402
  • Status: open  
  • Source: Anonymous
  • Summary:

    Spelling error in the title, OMG BMPN should be OMG BPMN

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 7.6

  • Key: BPMN21-346
  • Legacy Issue Number: 18398
  • Status: open  
  • Source: Anonymous
  • Summary:

    This section is informative. Remove this section or move to informative section.

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 3.3 BPEL4People


Section 8.3.4

  • Key: BPMN21-348
  • Legacy Issue Number: 18400
  • Status: open  
  • Source: Anonymous
  • Summary:

    There are a lot of ‘ enclosed string, such as, ‘identity/relationship’. It seems to be meaningless. On page 83, there are “happens” and “event”. Remove “‘”.

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 8.1 Figure 8.2

  • Key: BPMN21-347
  • Legacy Issue Number: 18399
  • Status: open  
  • Source: Anonymous
  • Summary:

    There is an explanation of “infrastructure” following section and figure 8.1. However, there isn’t the package infrastructure on the package diagram on Figure 8.2. Is it O.K.? Clarify this

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 3.2 Normative

  • Key: BPMN21-344
  • Legacy Issue Number: 18396
  • Status: open  
  • Source: Anonymous
  • Summary:

    This document uses “Element”, the MOF element on the Figure 8.7. Therefore, MOF is normative reference. Add the MOF as normative reference

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Typo in section 8.4

  • Key: BPMN21-349
  • Legacy Issue Number: 18401
  • Status: open  
  • Source: Anonymous
  • Summary:

    suc clauses ? typo sub clauses

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Revision & clarification for interruption of looping / multi-instance sub-processes

  • Key: BPMN21-333
  • Legacy Issue Number: 17528
  • Status: open  
  • Source: gmail.com ( Andre Gomes da Silva)
  • Summary:

    In Table 10.88 ­ End Event Types (page 248) it’s written:

    “Terminate ­ This type of End indicates that all Activities in the Process should be immediately ended. This includes all instances of multi-instances.”

    However, in 13.4.6 ­ End Events (page 443) it’s written:

    “For a ‘terminate’ End Event, the Sub-Process is abnormally terminated. In case of a multi-instance Sub-Process, only the affected instance is terminated—no other ongoing Sub-Process instances or higher-level Sub-Process or Process instances are affected.”

    So, it seems to be a contradiction: first it’s written all instances of multi-instances are terminated, but after it’s written only one instance is terminated.

    CLARIFICATION =============

    Since the contradiction mentioned above, I think it’s also needed to clarify how many instances are terminated when a multi-instance Sub-Process is interrupted via Boundary Event or via Event Sub-Process.

    The specification also does not mention how the interruption of a looping Sub-Process should be handled: is only the current iteration interrupted (like the “continue” statement in software programming), or the whole loop is interrupted (like the “break” statement in software programming)? So, it’s needed to clarify this behavior for interruptions triggered via terminate End Event, Boundary Events and Event Sub-Processes.

    This issue is related to Issue #14824.

  • Reported: BPMN 2.0 — Fri, 20 Jul 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong attribute name "attachedTo" for Bounday event

  • Key: BPMN21-332
  • Legacy Issue Number: 17468
  • Status: open  
  • Source: BonitaSoft S.A. ( Aurelien Pupier)
  • Summary:

    Wrong attribute name "attachedTo" for Bounday event

    It should be "attachedToRef".

  • Reported: BPMN 2.0 — Mon, 9 Jul 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Looping/Multi-instantiation description error

  • Key: BPMN21-331
  • Legacy Issue Number: 17365
  • Status: open  
  • Source: BonitaSoft ( Mickey Farrance)
  • Summary:

    Current text reads: "A set of three horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see upper figure to the right).

    A set of three vertical lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see lower figure to the right)."

    The three vertical lines depict parallel multi-instantiation, not sequential...(according to page 191 of spec)

  • Reported: BPMN 2.0 — Wed, 9 May 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Travel Booking Example

  • Key: BPMN21-330
  • Legacy Issue Number: 17146
  • Status: open  
  • Source: gmail.com ( Alex Schaffer)
  • Summary:

    On page 27 of the above document there is an explanation of a Travel Booking process model.

    In the 7th paragraph, there is a statement which says "If an error arises during the booking activities, the flight and hotel room reservations are reversed and the Client record is updated. The booking is tried again as long as the booking retry limited is not exceeded."

    I believe that part of this statement may be incorrect as the client record is only updated if there is an error in the payment activity which is outside of the subprocess.

    Could you please clarify?

  • Reported: BPMN 2.0 — Mon, 20 Feb 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Association - an Artifact or a Connecting object?

  • Key: BPMN21-335
  • Legacy Issue Number: 17563
  • Status: open  
  • Source: Cardiff University ( YULIA CHERDANTSEVA)
  • Summary:

    Section 7.2 states that Association is a Connecting Object, whereas Section 8.3.1 states that Association is an Artifact.
    Could you clarify please

  • Reported: BPMN 2.0 — Thu, 23 Aug 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Significant typo in BPMN 2.0 v1.0 formal/2011-01-03

  • Key: BPMN21-334
  • Legacy Issue Number: 17548
  • Status: open  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    In the definitions of interrupting and non-interrupting events, on the page numbered 280 (which is sequential page 310 of the pdf), under the heading

    Interrupting Event Handlers (Error, Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)

    the first sentence reads, correctly –

    Interrupting Event Handlers are those that have the cancelActivity attribute is set to true.

    In the next section, under the heading

    Non-interrupting Event Handlers (Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)

    the first sentence reads, incorrectly –

    Interrupting Event Handlers are those that have the cancelActivity attribute is set to false.

    Clearly the authors meant to start this sentence with

    Non-interrupting Event Handlers are ...

    but forgot to edit in the "Non" after the copy'n'paste. Right?

  • Reported: BPMN 2.0 — Thu, 9 Aug 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong references to ItemAwareElement in UML diagram

  • Key: BPMN21-341
  • Legacy Issue Number: 18322
  • Status: open  
  • Source: Munkert Software ( Frank Munkert)
  • Summary:

    In the UML diagram "Fig. 10.51 - DataObject class diagram", it looks as if DataObject and DataObjectReference are specializations of ItemAwareElement.

    According to "10.3.4 XML Schema for Data" and according to the text above the diagram, this is not true.

    Therefore, the "specialization arrows" must be replaced by "associations" (i.e. a simple arrow head instead of a hollow triangle).

  • Reported: BPMN 2.0 — Sun, 23 Dec 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 217: Send Task Mapping, first sentence

  • Key: BPMN21-340
  • Legacy Issue Number: 18265
  • Status: open  
  • Source: NobleProg ( Bernard Szlachta)
  • Summary:

    ...there MUST be at most '''one''' outputSet...
    Receive Task Mapping
    first sentance the same missing word "one" as above
    the last sentence:
    ... is not present, the '''payload''' (is: payloard
    There are quite a few typos I discovered. Is there any easier way of submitting suggestions and small bugs?
    Is there anyway to work on the new version (so I do not bother correct errors which already have been corrected)?

  • Reported: BPMN 2.0 — Sat, 10 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

flowNodeRefs containment and subprocess clarification

  • Key: BPMN21-338
  • Legacy Issue Number: 18256
  • Status: open  
  • Source: BonitaSoft S.A. ( Aurelien Pupier)
  • Summary:

    does FlowNode that are inside a SubProcess should be listed in flowNodeRefs of a lane?

    I found no official sample for this use case but several different implementations among BPMN Tools.
    All offical samples with SubProcess have them directly in a pool so no flowNodeRefs

  • Reported: BPMN 2.0 — Fri, 9 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect wording for description, should read "parallel" instead of "sequential"

  • Key: BPMN21-337
  • Legacy Issue Number: 18246
  • Status: open  
  • Source: Sodexo ( Juan Arocha)
  • Summary:

    In Table 7.2, in the description for the Multiple Instances element, it should read
    "A set of three vertical lines will be displayed at the bottom-center of the activity for parallel Multi-Instances (see lower figure to the right)."
    instead of
    "A set of three vertical lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see lower figure to the right)."

  • Reported: BPMN 2.0 — Mon, 5 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 3.3 OMG UML

  • Key: BPMN21-343
  • Legacy Issue Number: 18395
  • Status: open  
  • Source: Anonymous
  • Summary:

    This document refers to Unified Modeling Language Specification V2.1.2. However, the ISO standard version is UML 2.4.1. If there isn’t inconsistency, this document should refer to ISO version. Besides, the semantic models use the UML class diagram. Therefore, UML is the normative reference, not non-normative reference. Move UML reference to normative section as well as check the adequate version.

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Cover Page Title

  • Key: BPMN21-342
  • Legacy Issue Number: 18394
  • Status: open  
  • Source: Anonymous
  • Summary:

    Abbreviation of “Business Process Model and Notation” is incorrect. Change “BMPN” to “BPMN”

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistent Naming of Multi-instance Activity

  • Key: BPMN21-336
  • Legacy Issue Number: 18143
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    The caption of section 13.2.7 speaks about a 'Multiple Instances Activity' whereas the rest of the specification uses the term 'Multi-instance Activity'.

    Proposal:
    Rename section 13.2.7 to 'Multi-instance Activity'.

  • Reported: BPMN 2.0 — Mon, 8 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unclear meaning of "‰" symbol

  • Key: BPMN21-329
  • Legacy Issue Number: 17130
  • Status: open  
  • Source: International Olympic Committee ( Will Keenan)
  • Summary:

    In Table 7.3 - Sequence Flow Connection Rules, under the column designated by the Activity notation, there are "‰" (per mil) symbols instead of arrows. Unable to find an explanation in the document for "‰", is this an error and should it also be an arrow?

  • Reported: BPMN 2.0 — Tue, 14 Feb 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Picture doesn't correspond to the description

  • Key: BPMN21-339
  • Legacy Issue Number: 18264
  • Status: open  
  • Source: ( Bernard Szlachta)
  • Summary:

    The sentence on page 177 (207)
    If the Event Sub-Process is collapsed, then its Start Event will be used as a marker in the upper left
    corner of the shape (see Figure 10.30).
    does not seem to correspond with the picture (i.e. there is no start event)

  • Reported: BPMN 2.0 — Sat, 10 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use XPath 2.0 as default expression language instead of XPath 1.0

  • Key: BPMN21-316
  • Legacy Issue Number: 16877
  • Status: open  
  • Source: University of Bamberg ( JöLenhard)
  • Summary:

    XPath 1.0 is the default expression language in BPMN 2.0. Instead of XPath 1.0, the default expression language should be XPath 2.0 which is a W3C Recommendation since 14 December 2010 (and I assume that is why it has not made it into BPMN 2.0).

    A major problem with XPath 1.0 is its limited set of functions. For instance, XPath 1.0 does not provide any time-related functions. Consequently, it is impossible to get the current system time in an expression, which might be necessary in Timer Events, without proprietary extensions to the standard. This harms portability of process models and is especially relevant for Process Execution Conformance. XPath 2.0 provides such functions and the time-related data types used in both, BPMN 2.0 and XPath 2.0, are identical (ISO-8601).

    This change might affect several parts of the specification:
    In section 10.3.3 The usage of XPath as expression language in BPMN 2.0 is discussed. There, several additional XPath-functions are defined, mentioning deficiencies in XPath 1.0. These functions should be redefined with XPath 2.0.
    Section 14 Mapping BPMN Models to BPEL might also require changes. XPath 1.0 is the default language required by BPEL 2.0 and XPath 2.0 functions that are not present in XPath 1.0 cannot be mapped as easily.

    I would strongly recommend for BPMN 2.0 to require the support for XPath 2.0 instead of XPath 1.0 as default expression language.

  • Reported: BPMN 2.0 — Tue, 6 Dec 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

XML Schema: Usage of xsd:anyAttribute instead of xsd:attribute

  • Key: BPMN21-315
  • Legacy Issue Number: 16632
  • Status: open  
  • Source: IHK Gesellschaft fuer Informationsverarbeitung mbH ( Sven Joerges)
  • Summary:

    Table 8.3 ("Definitions XML schema") on page 54 contains the following two lines:

    <xsd:anyAttribute name="exporter" type="xsd:ID"/>
    <xsd:anyAttribute name="exporterVersion" type="xsd:ID"/>

    As the usage of the "name" attribute in combination with the "xsd:anyAttribute" element makes no sense, those lines should be changed to:

    <xsd:attribute name="exporter" type="xsd:ID"/>
    <xsd:attribute name="exporterVersion" type="xsd:ID"/>

    As the XSD-Files given at www.omg.org/spec/BPMN/2.0/ also use "xsd:attribute" for those lines, I suppose this is just a copy&paste error in the specification document.

  • Reported: BPMN 2.0 — Wed, 19 Oct 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reference omitted in BPMN 2 11-01-03

  • Key: BPMN21-327
  • Legacy Issue Number: 17069
  • Status: open  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    On page 315, after this sentence about Service Interaction Patterns -

    Message exchanges between partners go beyond simple request-response interactions into multi-cast, contingent requests, competing receives, streaming, and other service interaction patterns

    comes the cryptic phrase

    (REF for SIP)

    It looks like this is a stand-in for a Reference for Service Interaction Patterns - right?

    If so, it might be replace with a footnote referring to this Barros article -
    Service Interaction Patterns: Towards a Reference
    Framework for Service-Based Business Process
    Interconnection
    http://eprints.qut.edu.au/2295/1/ServiceInteractionPatterns.pdf

  • Reported: BPMN 2.0 — Fri, 27 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incomming sequence flow at start event

  • Key: BPMN21-326
  • Legacy Issue Number: 17047
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    An interesting rule (page 245):
    ‘A Start Event MUST NOT be a target for Sequence Flows; it MUST NOT have incoming Sequence Flows. An exception to this is when a Start Event is used in an Expanded Sub-Process and is attached to the boundary of that Sub-Process. In this case, a Sequence Flow from the higher-level Process MAY connect to that Start Event in lieu of connecting to the actual boundary of the Sub-Process.’

    I never found a tool who implements this rule. On page 261 a ‘Boundary Start event’ does not exist. Only Intermediate Events are of type ‘boundary’ (interrupting/non-interrupting). Or interrupting/non-interrupting Start Events for an Event-Sub-Process (but they are not of type ‘boundary’).

    -> is it ok to remove this exception?

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

visualization enumeration level

  • Key: BPMN21-318
  • Legacy Issue Number: 17037
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    This Document is hard to read. The enumerations begins all with a rectangle independent from their level. Particularly if
    there is a picture or a table between the enumerations.
    I think it is better to use different signs for enumeration, depending on the level in the enumeration.
    (rectangle filled, rectangle unfilled, circle filled, circle unfilled).

    I know, this fact depends on at the OMG-Template (it concerns not only the BPMN-Document, I think). Now, it´s time to change the template.

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Title of Figure 10.122 doesn't match its contents

  • Key: BPMN21-317
  • Legacy Issue Number: 16903
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    The title of Figure 10.122 on page 304 (PDF 334) is 'Monitoring Class Diagram', but the figure shows Compensation through a Compensation Event Sub-Process.

    The same title is also used for Figure 10.129, where it matches the contents. So this seems to be a copy and paste issue.

    Proposal:
    Change title of Figure 10.122 on page 304 (PDF 334) to 'Compensation through a Compensation Event Sub-Process'.

  • Reported: BPMN 2.0 — Wed, 14 Dec 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ItemAwareElement the second

  • Key: BPMN21-322
  • Legacy Issue Number: 17043
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    At page S.223: ‘Model Associations of DataAssociation:
    The source/target MUST be an temAwareElement.’ Now, I have to look: what is an ItemAwareElement? (So I use strg+F to search. But remember, there are two different spellings*.. ) I think it is better to mention the source/target directly.

    • have a look on my reported issue 'item-aware element vs. ItemAwareElement'.
  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

eXclusive Gateway

  • Key: BPMN21-321
  • Legacy Issue Number: 17040
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    There are two types of signs for the Exclusive Gateway. Why? It is better to use only the sign with the ‘X’. Finally it is an eXclusive Gateway
    -> Mr. Juergen Boldt answered: "[..] It is left open to the modeler as a matter of taste."
    OK.
    -> But IMHO BPMN 2.0 is a standard. There is no leeway for matter of taste. I think.
    ---------
    (Look at the road traffic or specification of your voltage wich comes from your socket. That is no matter of taste. )

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

item-aware element vs. ItemAwareElement

  • Key: BPMN21-320
  • Legacy Issue Number: 17039
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    ItemAwareElement: item-aware element (Example on page 205) vs. ItemAwareElement (Example on page 204) ­ there are two different spellings.
    There are also two different meanings?

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing Enumeration

  • Key: BPMN21-319
  • Legacy Issue Number: 17038
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    At page 184 you write ‘If the Call Activity calls a Process, then there are
    two options:’ Under this sentence there is only one enumeration (only one
    option? Or is the sentence ‘If the details of the called Process are’
    the second option? But this sentence has no enumeration).

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Table 7.2 Description of Multiple Instances

  • Key: BPMN21-328
  • Legacy Issue Number: 17106
  • Status: open  
  • Source: Data Networks Corporation ( Candido Gonzalez)
  • Summary:

    In the Table 7.2 description of Multiple Instances, it says in the second sentence that "A set of three horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-instances." In the third sentence, it again says that the set of three vertical lines is also for sequential multi-instances. A revision needs to be made to correctly state what the three horizontal lines and three vertical lines stand for.

  • Reported: BPMN 2.0 — Thu, 9 Feb 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Catch None intermediate event

  • Key: BPMN21-324
  • Legacy Issue Number: 17045
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    On page 272 you talk about a ‘Catch None intermediate event’. But at the table on page 261 there is no ‘Catch none intermediate event’. There is a ‘Throw none intermediate event’

    -> It would be good, if you would change the text on page 272.

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

wrong reference on page 292

  • Key: BPMN21-325
  • Legacy Issue Number: 17046
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    At page 292 last sentence: ‘[...] precise synchronization behavior of the Inclusive Gateway can be found on page 292’ ­ I don’t found it.

    It would be good, if you correct the reference.

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

MAY NOT

  • Key: BPMN21-323
  • Legacy Issue Number: 17044
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    You use ‘MAY NOT’. But it is not referenced in RFC-2119. I think it is important in a standard-document to define keywords.
    p. 99/111/112/..

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN 2.0 Spec Problems (from Typo's to More Serious Issues)

  • Key: BPMN21-299
  • Legacy Issue Number: 16063
  • Status: open  
  • Source: iGrafx (Corel Inc.) ( Kim Scott)
  • Summary:

    Description:

    * Section 2: Table 2.3, note ‘a’ [page 7]: Should be “Multiple incoming connections…” [incoming vs. outgoing]

    • Section 7: Tables 7.1 and 7.2 (and others?): Missing 'a' in front of 'company' in "An Activity is a generic term for work that company performs"
    • Section 7: Table 7.2, Activity [p. 32]: The spec seems to consistently use the spelling “Sub-Process” for sub-processes. Merriam-Webster indicates that “subprocess” is the correct form of the word (i.e. that sub is simply a prefix) and does not offer a hyphenated alternative (even though Microsoft Word complains ‘subprocess’ is misspelled
    • Table 7.2, Choreography Task [p. 32]: Missing "or more" in "Each Choreography Task involves two (2) Participants", as they can specify more than 2 Participants.
    • Table 7.2 Conditional Flow [p.35]: Typo; should be ‘is’ vs. ‘are’ in "A Sequence Flow can have a condition Expression that are evaluated" (or should be "Expressions that are").
    • Table 7.2 Compensation Association [p. 35]: The activity that is the target of the Compensation Association is missing the compensation indicator.
    • Section 8.3.1 Artifacts, Text Annotation [p. 71]: May contradict itself on open rectangle. Says “A Text Annotation is an open rectangle that MUST be drawn with a solid single line (as seen in Figure 8.16).” and then “text associated with the Annotation can be placed within the bounds of the open rectangle.” Isn't that "...MUST be placed within"? Why MUST you draw the open rectangle if text doesn't go within it, per Figure 8.16?
    • Section 10.2 Activities, [p.153]: completionQuantity says "This number of tokens will be sent done any..." and the 'done' should be 'down'.
    • Section 10.2.3 Tasks, Receive Task [p. 161]: "Once the Message has been received, the Task is completed." Is this worded correctly? If this Task doesn't do anything after the Message is received, then why use it instead of a Receive (Catch) Message Event?
    • Section 10.2.5 Subprocesses, page 177: The following is missing Timer (at a minimum; also missing Parallel Multiple?): “The Start Event trigger (EventDefinition) MUST be from the following types..."
    • Section 10.2.5 Subprocesses, page 177, Figure 10.30 is incorrect; it does not show the start event in upper-left corner like text says.
    • Section 10.2.8: pages 190 & 191, Figures 10.47, 10.48, and 10.49 contradict Table 12.8 on page 382 & 383 on the location of the multi-instance indicator (marker) for Collapsed Subprocesses. I assume Table 12.8 is correct.
    • Section 10.4: page 233: The word 'trigger' should be 'result' in the following sentence in list item 2: "The throwing of a trigger MAY be..." (Items 1 & 2 say "Events that catch a trigger" and "Events that throw a Result." So triggers are caught and results are thrown, correct?
    • Section 10.4.6, page 276, Figure 10.98: An Intermediate multiple event marker is used for a start event-based gateway, and it should be a start event marker (single line vs. double on the Event within the Gateway).
    • Section 10.4.6, page 277: The following seems to be missing Escalation Events at a minimum: “...or by running an Event Handler without canceling the Activity (only for Message, Signal, Timer and Conditional Events, not for Error Events).”

    * Section 10.8, page 309: Figure 10.1 was updated, but the references to activity names in the Figure were not updated in the first and second paragraphs of Section 10.8. For example “…in Figure 10.1 might execute or perform an extra Activity between Task “Receive Issue List” and Task “Review Issue List.””

    • Section 11.4.1: Choreography Task [p. 327, 332]: The text is unclear about whether Participants can be multi-instance sequential, but I believe they can. As such, the language on page 327 of “The marker for a Choreography Task that is multi-instance MUST be a set of three vertical lines” and

    on page 332 of “The marker for a Sub-Choreography that is multi-instance MUST be a set of three vertical lines” seems incorrect and too limiting. If multi-instance sequential can be used, then three horizontal lines are also allowed (as is the 'loopback' repeat?).

    • Section 13.2.2 Activity [p. 429]: The fifth bullet says "(proposed for BPMN 2.0)" when this is the final spec, and non-interrupting EVent Handlers are part of the spec. This should be removed.
  • Reported: BPMN 2.0 — Thu, 10 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN2 issue: Example (DI lanes and nested lanes) appears to be invalid

  • Key: BPMN21-298
  • Legacy Issue Number: 16060
  • Status: open  
  • Source: Red Hat ( Gary Brown)
  • Summary:

    When opening the example
    http://www.omg.org/spec/BPMN/2.0/examples/ZIP/Diagram%20Interchange/Examples%20-%20DI%20-%20Lanes%20and%20Nested%20Lanes.bpmn
    throws an exception[1].

    This happens because it tries to assign
    org.eclipse.bpmn2.impl.DataObjectReferenceImpl object to an array of FlowNodes.

    org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Value
    'org.eclipse.bpmn2.impl.DataObjectReferenceImpl@6caf4065 (id:
    DataObject_Document, anyAttribute: null) (name: Document)' is not legal.
    (platform:/resource/Dev/Examples%20-%20DI%20-%20Lanes%20and%20Nested%20Lanes.bpmn2,
    -1, -1)
    at
    org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
    at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:191)
    at
    org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:180)
    at
    org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1494)
    at
    org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1282)
    ...
    Caused by: org.eclipse.emf.ecore.xmi.IllegalValueException: Value
    'org.eclipse.bpmn2.impl.DataObjectReferenceImpl@6caf4065 (id:
    DataObject_Document, anyAttribute: null) (name: Document)' is not legal.
    (platform:/resource/Dev/Examples%20-%20DI%20-%20Lanes%20and%20Nested%20Lanes.bpmn2,
    -1, -1)
    at
    org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(XMLHandler.java:2663)
    at
    org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleForwardReferences(XMLHandler.java:1149)
    ...
    Caused by: java.lang.ArrayStoreException:
    org.eclipse.bpmn2.impl.DataObjectReferenceImpl
    at org.eclipse.emf.common.util.BasicEList.assign(BasicEList.java:124)
    at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList.java:424)
    at
    org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUnique(NotifyingListImpl.java:331)
    at
    org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:315)
    at
    org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.setValue(XMLHelperImpl.java:1179)
    at
    org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(XMLHandler.java:2658)
    ... 99 more

  • Reported: BPMN 2.0 — Wed, 16 Mar 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN 2.0 Choreography issues page 327 of dtc/2010-06-05

  • Key: BPMN21-306
  • Legacy Issue Number: 16547
  • Status: open  
  • Source: Anonymous
  • Summary:

    Page 327 of /dtc/2010-06-05/ runs as follows (emphasis in the last
    sentence added):

    “To leverage the familiarity of flow charting types of Process
    models, BPMN Choreographies also have “activities” that are ordered
    by Sequence Flows. These “activities” consist of one (1) or more
    interactions between Participants. These interactions are often
    described as being message exchange patterns (MEPs). A MEP is the
    atomic unit (“Activity”) of a Choreography.

    Some MEPs involve a single Message (e.g., a “Customer” requests an
    “Order” from a “Supplier”). Other MEPs will involve two (2) Messages
    in a request and response format (e.g., a “Supplier” request a
    “Credit Rating” from a “Financial Institution,” who then returns the
    “Credit Rating” to the “Supplier”). There can be even more complex
    MEPs that involve error Messages, for example.”

    This wording may result confusing to practitioners. First of all,
    there is no way in BPMN 2.0 Choreographies to mark a message as an
    “error message”. What the specification seems to hint at is that
    some of the messages in the choreography may deliver information
    over errors. However, since BPMN 2.0 Choreographies (and, more
    generally, BPMN 2.0 as a whole) does not differentiate among the
    possible “typologies” of messages (e.g. error, acknowledgement,
    invocation, or response), there is no immediate way to map WSDL
    1.1/2.0 MEPs to single Choreography Taskswithout losing some
    information (e.g. the distinction between output messages and fault
    messages). Even using the structureRefof the message(see e.g. Page 7
    of /dtc/2010-06-05/) to point to a WSDL 1.1/2.0 message, this would
    provide no information about what “type” of message it is. In fact,
    in WSDL 1.1/2.0 a message is “labelled” as input, output or fault
    only in the WSDL operations, so much that a given WSDL message
    could, for example, be input in one operation and a fault in another.

    Secondly, despite the fact that the text mentions Choreography
    Activities as the realization of MEPs (i.e. also
    Sub-choreographies), the reference to MEPs as atomic units sounds
    intuitively related to Choreography Tasks. Given the fact that it is
    not possible to (1) specify error messages and (2) specify the
    sequencing in a single Choreography Taskfor more than two messages,
    a single Choreography Taskallows the specification of only the WSDL
    1.1 “one-way messaging” and “notification” MEPs. In fact, the
    specification of “request/reply” and “solicit/response” MEPs is not
    possible because their faults cannot be represented in the same
    Choreography Tasktogether with the input and output messages.

    To clarify this issues, the specification should address clearly and
    in detail the relation between BPMN 2.0 Choreographies and MEPs in
    WSDL 1.1 and WSDL 2.0, in particular with relation to the
    granularity of the MEPs (Choreography Task-level, Sub-choreography
    level, etc.). Moreover, it is still an open issue how to map WSDL
    2.0 Complex MEPs to BPMN 2.0 Choreographies.

  • Reported: BPMN 2.0 — Wed, 14 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN 2.0 Choreography issues page 339 of dtc/2010-06-05

  • Key: BPMN21-305
  • Legacy Issue Number: 16546
  • Status: open  
  • Source: Anonymous
  • Summary:

    N.B. In the reminder /dtc/2010-06-05 /is the BPMN 2.0 specification.

    ------ ISSUE START ------
    Page 339 of /dtc/2010-06-05/ reads as follows:

    “There are situations when a Participant for a Choreography Task is
    actually a multi-instance Participant. A multi-instance Participant
    represents a situation where there are more than one possible
    related Participants (PartnerRoles/ PartnerEntities) that might be
    involved in the Choreography. For example, in a Choreography that
    involves the shipping of a product, there can be more than one type
    of shipper used, depending on the destination.”

    Page 344 of /dtc/2010-06-05/ reads almost verbatim, but referring to
    multi-instance participants in Sub-choreographies:

    “There are situations when a Participant for a Sub-Choreography is
    actually a multi-instance Participant. A multi-instance Participant
    represents a situation where there are more than one possible
    related Participants (PartnerRoles/ PartnerEntities) that can be
    involved in the Choreography. For example, in a Choreography that
    involves the shipping of a product, there can be more than one type
    of shipper used, depending on the destination.”

    First of all, the above wordings are unclear with respect to which
    of the following two cases applies at run-time with multi-instance
    participants:

    1. Exactly one partner entity (as defined on Page 117 of
    /dtc/2010-06-05/) out of many possible ones during the enactment
    of the choreography.
    2. One or more partner entities partake the choreography enactment.

    We could not find in the /dtc/2010-06-05/any wording that clarifies
    which of the two possible meanings is the correct one. We assume (2)
    for consistency with the Orchestration part of the specification.
    However, having a multi-instance participant resolve to multiple
    partner entities during the enactment raises several serious issues:

    • Multi-instance recipient participants in a choreography task
      violate the assumption that each choreography task involves
      exactlytwo partner entities, which is a fundamental assumption
      for the specification of Message Exchange Patterns (MEPs) in
      Choreography Tasks.
    • Similarly to the previous case: how to deal with Choreography
      Task senders that are multi-instance participants? How many
      initiating messages are actually sent?

    Even more complicated issues arise from multi-instance participants
    in terms of the enforceability of choreographies. For example, if
    the partner entities that resolve a given multi-instance participant
    are decided at enactment time, how are the other partner entities
    supposed to know (and therefore be able to deliver messages to them)?

    It is our opinion that multi-instance participantsis a complicated
    construct to deal with in Choreographies, and should be thoroughly
    re-considered (possibly leading to its elimination from the
    specification).

  • Reported: BPMN 2.0 — Wed, 14 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

meta-model doesn't provide way to serialize intermediate catch events attached to participant bands of choreography task

  • Key: BPMN21-308
  • Legacy Issue Number: 16549
  • Status: open  
  • Source: IAAS, University of Stuttgart ( Michele Mancioppi)
  • Summary:

    On pp. 341~343 the specification details some intermediate catch events that can be attached to activity boundaries, namely Message, Timer, Cancel, Compensation, Conditional, Signal and Multiple. This is similar to attaching events to activities in Process diagrams. The meta-model supports attaching of events to activity boundaries in Processes through the BoundaryEvent element. However, no similar element is available for Choreography Activities. Instances of BoundaryEvent obviously cannot be used (because ChoreographyActivity does not extend Activity). Therefore a new Class should be added. This class (called e.g. ChoreographyBoundaryEvent) should (1) have a reference to the ChoreographyActivity to which the event is attached, and (2) depending on the type of event, specify to which of the ParticipantBands the event is attached. This is necessary because some events, namely Message, Cancel and Compensation are "local" (i.e. visible) to only one of the Participants involved in the ChoreographyActivity. The specification should clearly state in which cases this reference to a Participant is compulsory, and in which cases optional. For example, it might be optional in the case of Signal events, to symbolize that the event is trigger by the reception of the signal by one particular participants (which is different than the "firing" of the signal, given the fact that the specification does not seem to require signals to be "immediately" received, but just "eventually" received by the participants).

  • Reported: BPMN 2.0 — Wed, 14 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN 2.0 Choreography issues page 338 of dtc/2010-06-05 about Sub-choreographics

  • Key: BPMN21-307
  • Legacy Issue Number: 16548
  • Status: open  
  • Source: Anonymous
  • Summary:

    On Page 338 of /dtc/2010-06-05/, about Sub-choreographies:

    “The Participant Band of the Participant that does not initiate the
    interaction MUST be shaded with a light fill.”

    This wording does not cover some corner cases. Consider the example
    depicted in the attached image Example Issue Initiating Participant
    in Sub-Choreographies.png. In the choreography above it is unknown
    until the enactment of Task 1which participant is the initiator of
    Sub-choreography 1. But this is only the symptom of a wider-reaching
    problem. When there is no choreography task that dominates of all
    the others (or worse, there is a race condition!), and the various
    choreography tasks that may be executed as first have different
    initiators, modelers have no way to pick which participant is marked
    as the initiator of the sub-choreographies.

    The same issue with initiators of sub-choreographies affects also
    the messages sent by them. In fact, Page 93 of /dtc/2010-06-05/reads:

    “Any Message sent by the non-initiating Participant or
    Sub-Choreography MUST be shaded with a light fill.”

    We propose two possible, mutually exclusive solutions:

    1. Additional constraints are specified for choreographies so that
    no such corner case can occur. However, this is very likely to
    result in not being able to model with BPMN 2.0 choreographies
    some inter-organizational processes that can instead be modeled
    with BPMN 2.0 Orchestrations.
    2. Drop the differentiation between initiator and non-initiator
    participants in sub-choreographies. We see no real shortcoming
    resulting from this approach. In particular, with respect to the
    enactability of choreographies, knowing which participant is the
    first to act in a sub-choreography gives no guarantees as to the
    fact that the same participant will also be involved in the
    “last” choreography activities to be executed in that
    sub-choreography. Therefore, we can extract no useful
    information from it with respect to the enactability of what
    follows that sub-choreography. This is particularly true in the
    case of collapsed sub-choreographies.

  • Reported: BPMN 2.0 — Wed, 14 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unclear introduction of the concept of MEP

  • Key: BPMN21-310
  • Legacy Issue Number: 16551
  • Status: open  
  • Source: IAAS, University of Stuttgart ( Michele Mancioppi)
  • Summary:

    Page 315 reports the following text on MEPs:

    “To leverage the familiarity of flow charting types of Process models, BPMN Choreographies also have “activities” that are ordered by Sequence Flows. These “activities” consist of one (1) or more interactions between Participants. These interactions are often described as being message exchange patterns (MEPs). A MEP is the atomic unit (“Activity”) of a Choreography.

    Some MEPs involve a single Message (e.g., a “Customer” requests an “Order” from a “Supplier”). Other MEPs will involve two (2) Messages in a request and response format (e.g., a “Supplier” request a “Credit Rating” from a “Financial Institution,” who then returns the “Credit Rating” to the “Supplier”). There can be even more complex MEPs that involve error Messages, for example.”

    This wording may result confusing to practitioners for the following reasons.

    First of all, there is no way in BPMN 2.0 Choreographies to mark a message as an “error message”. What the specification seems to hint at is that some of the messages in the choreography may deliver information over errors. However, since BPMN 2.0 Choreographies (and, more generally, BPMN 2.0 as a whole) does not differentiate among the possible “typologies” of messages (e.g. error, acknowledgement, invocation, or response), there is no immediate way to map WSDL 1.1/2.0 MEPs to single Choreography Tasks without losing some information (e.g. the distinction between output messages and fault messages). Even using the structureRef of the message (see e.g. Page 7 of dtc/2010-06-05) to point to a WSDL 1.1/2.0 message, this would provide no information about what “type” of message it is. In fact, in WSDL 1.1/2.0 a message is “labelled” as input, output or fault only in the WSDL operations, so much that a given WSDL message could, for example, be input in one operation and a fault in another.

    Secondly, despite the fact that the text mentions Choreography Activities as the realization of MEPs (i.e. also Sub-choreographies), the reference to MEPs as atomic units sounds intuitively related to Choreography Tasks. Given the fact that it is not possible to (1) specify error messages and (2) specify the sequencing in a single Choreography Task of more than two messages, a single Choreography Task allows the specification of only the WSDL 1.1 “one-way messaging” and “notification” MEPs. In fact, the specification of “request/reply” and “solicit/response” MEPs is not possible because their faults cannot be represented in the same Choreography Task alongside the input and output messages.

    To clarify this issues, the specification should address clearly and in detail the relation between BPMN 2.0 Choreographies and MEPs in WSDL 1.1 and WSDL 2.0, in particular with relation to the granularity of the MEPs (Choreography Task-level, Sub-choreography level, etc.).

    Additionally, it might be beneficial to for the sake of clarity to explicitly that it is outside the scope of ChoreographyTasks to be able to map entire WSDL 2.0 Complex MEPs, but that, instead, they have to be realized by multiple choreography tasks appropriately sequenced.

  • Reported: BPMN 2.0 — Thu, 15 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Process name in property mapping is "statically" derived not "statistically"

  • Key: BPMN21-309
  • Legacy Issue Number: 16550
  • Status: open  
  • Source: University of Bamberg ( JöLenhard)
  • Summary:

    The mapping of "getProcessProperty(propertyName)" to BPEL reads "$[

    {processName}

    .propertyName] where the right process-Name is statistically derived."
    "statistically" does not fit in this context, the name should be derived "statically" from the process in which the current expression is used.

  • Reported: BPMN 2.0 — Thu, 15 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Underspecification of Multi-instance participants in Choreographies

  • Key: BPMN21-312
  • Legacy Issue Number: 16553
  • Status: open  
  • Source: IAAS, University of Stuttgart ( Michele Mancioppi)
  • Summary:

    Page 327 reports the following text on multi-inistance participants:

    "There are situations when a Participant for a Choreography Task is actually a multi-instance Participant. A multiinstance
    Participant represents a situation where there are more than one possible related Participants (PartnerRoles/
    PartnerEntities) that might be involved in the Choreography. For example, in a Choreography that involves
    the shipping of a product, there can be more than one type of shipper used, depending on the destination."

    Page 344 of dtc/2010-06-05 reads almost verbatim, but referring to multi-instance participants in Sub-choreographies:

    “There are situations when a Participant for a Sub-Choreography is actually a multi-instance Participant. A multiinstance
    Participant represents a situation where there are more than one possible related Participants (PartnerRoles/
    PartnerEntities) that can be involved in the Choreography. For example, in a Choreography that involves the
    shipping of a product, there can be more than one type of shipper used, depending on the destination.”

    The above wordings seem unclear with respect to which of the following two cases applies at run-time with multi-instance participants:
    1) Exactly one partner entity (as defined on Page 117 of dtc/2010-06-05) out of many possible ones during the enactment of the choreography.
    2) One or more partner entities partake the choreography enactment.

    We assume (2) for consistency with the Orchestration part of the specification. However, having a multi-instance participant resolve to multiple partner entities during the enactment of the choreography raises several serious issues:

    • Multi-instance recipient participants in a choreography task violate the assumption that each choreography task involves exactly two partner entities, which is a fundamental assumption for the specification of Message Exchange Patterns (MEPs) in Choreography Tasks.
    • Similarly to the previous case: how to deal with Choreography Task senders that are multi-instance participants? How many initiating messages are actually sent?
    • Assuming both the sender and recipient of a ChoreographyTask to be multi-instance, how many message exchanges actually take place? All the possible permutations?

    Even more complicated issues arise from multi-instance participants in terms of the enforceability of choreographies. For example, if the partner entities that resolve a given multi-instance participant are decided at enactment time, how are the other partner entities supposed to know (and therefore be able to deliver messages to them)?

  • Reported: BPMN 2.0 — Thu, 15 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Underspecification of initiating/non-initiating participants in non-trivial choreographies

  • Key: BPMN21-311
  • Legacy Issue Number: 16552
  • Status: open  
  • Source: IAAS, University of Stuttgart ( Michele Mancioppi)
  • Summary:
  • Reported: BPMN 2.0 — Thu, 15 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

XML Schema not valid


Error in Description for Multiple Instances in Table 7.2

  • Key: BPMN21-303
  • Legacy Issue Number: 16228
  • Status: open  
  • Source: Cobham Aerospace Communications ( Dale Cureton)
  • Summary:

    In the Description field for the Multiple Instances element in Table 7.2, the second sentance states "... three horizontal lines will be displayed ... for sequential Multi-Instances..." while the third sentance states "three vertical lines will be displayed ... for sequential Multi-Instances..."

    Note that BOTH sentances refer to "sequential Multi-Instances".

    Solution: the third sentance should refer to "parallel Multi-Instances".

  • Reported: BPMN 2.0 — Thu, 12 May 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Title of Figure 10.66 grammatically wrong

  • Key: BPMN21-302
  • Legacy Issue Number: 16159
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    The title of Figure 10.66 seems grammatically wrong to me.

    It reads:
    "A Data Association used for an Outputs and Inputs into an Activities"

    Proposal:
    Change title of Figure 10.66 on page 222 (PDF 252) into:
    "Data Associations used for Outputs from and Inputs into Activities"

  • Reported: BPMN 2.0 — Thu, 21 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Some BPEL4People links are dead


Underspecification of ChoreographyLoopType

  • Key: BPMN21-313
  • Legacy Issue Number: 16554
  • Status: open  
  • Source: IAAS, University of Stuttgart ( Michele Mancioppi)
  • Summary:

    The loop types of choreography activities do not provide any information about: (1) the "hard-coded" cardinality of the loop (how often is the loop repeated) or (2) the expression that must be evaluated during the choreography enactment based on the data contained in the messages exchanged up to that point during the enactment. In the latter case, specifying the expression is not enough: for reasons of enforceability, it should be possible to specified which participant(s) must evaluate the expression.

  • Reported: BPMN 2.0 — Fri, 16 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN 2.0: Errors in Section 6.2 Structure of this Document

  • Key: BPMN21-301
  • Legacy Issue Number: 16108
  • Status: open  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    In BPMN 2.0, formal/2011-01-03, Section 6.2 Structure of this Document is OK up to the reference to Chapter 10. However, it next references Chapter 11 Conversations which does not exist, and every reference after that has its chapter number incorrectly one too high: Chroeographies is 11, not 12. The visual diagram model is 12, not 13. and so on.

  • Reported: BPMN 2.0 — Tue, 5 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Can Event Sub-Processes Loop?

  • Key: BPMN21-300
  • Legacy Issue Number: 16102
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    An Event Sub-Process is a type of Sub-Process. Sub-Processes, as Activities, can have loop settings--meaning that the entire Sub-Process, from the start to the end can be repeated. But how does this work for an Event Sub-Process? Is the Start Event trigger for the Event Sub-Process expected to be repeated? or is the Start Event just ignored?

  • Reported: BPMN 2.0 — Tue, 29 Mar 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

more typos

  • Key: BPMN21-297
  • Legacy Issue Number: 16055
  • Status: open  
  • Source: Telstra Coorporation ( John Raper)
  • Summary:

    Change "recieved" in Fig 11.49 to "received" six times - At least it is consistent.
    Perhaps the USA has changed the rule:
    "i before e except after c"

  • Reported: BPMN 2.0 — Thu, 10 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Change "recieved" in Fig 11.49 to "received"

  • Key: BPMN21-296
  • Legacy Issue Number: 16054
  • Status: open  
  • Source: Telstra Coorporation ( John Raper)
  • Summary:

    Change "recieved" in Fig 11.49 to "received"

  • Reported: BPMN 2.0 — Thu, 10 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Spello

  • Key: BPMN21-295
  • Legacy Issue Number: 16053
  • Status: open  
  • Source: Telstra Coorporation ( John Raper)
  • Summary:

    Change "recieved" in Fig 11.48 to "received"

  • Reported: BPMN 2.0 — Thu, 10 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Meaning of 'behavior' attribute on MultiInstanceLoopCharacteristics quite confusing

  • Key: BPMN21-276
  • Legacy Issue Number: 15911
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    The meaning of the 'behavior' attribute on the MultiInstanceLoopCharacteristics is quite confusing. It is told that:

    • 'None' should throw an event on each instance,
    • 'All' should throw no event at all

    It seems that None and All meaning have been swapped.

    I also think that oneBehaviorEventRef and noneBehaviorEventRef can be merged as they are exclusive, they will never both be filled.

    Another question: what Event will own (composition relationship) the EventDefinition that is referenced by oneBehaviorEventRef or noneBehaviorEventRef ?
    As far as I understood, an EventDefinition can be owned only by an Event.

    My proposed solution:
    ---------------------
    1) Rewrite behavior: MultiInstanceBehavior meaning as following:

    behavior: MultiInstanceBehavior =
    all

    { None | First | Each | Complex}

    :
    -----------------------------------------
    The attribute behavior acts as a shortcut for specifying when events SHALL be thrown
    from an Activity instance that is about to complete. It can assume val-
    ues of None, One, All, and Complex, resulting in the following behav-
    ior:
    • None: no Event is ever thrown; a token is produced after completion
    of all instances
    • First: the EventDefinition referenced through the oneEvent
    association will be thrown upon the first instance completing;
    • Each: the EventDefinition which is associated through the
    noneEvent association will be thrown for each instance
    completing;
    • Complex: the complexBehaviorDefinitions are consulted to
    determine if and which Events to throw.

    For the behaviors of First and Each, a default
    SignalEventDefinition will be thrown which automatically carries
    the current runtime attributes of the MI Activity.
    Any thrown Events can be caught by boundary Events on the Multi-
    Instance Activity.

    3) Change oneBehaviorEventRef and noneBehaviorEventRef composition relationships
    Unless an answer is provided to the referred event definition ownership.

    2) Change the type of oneBehaviorEventRef and noneBehaviorEventRef to ThrowEvent
    Unless an answer is provided to the referred event definition ownership.

    4) Merge oneBehaviorEventRef and noneBehaviorEventRef into 'behaviorEventRef'

  • Reported: BPMN 2.0 — Tue, 4 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Subclasses of Interaction Node (Task vs. Activity)

  • Key: BPMN21-275
  • Legacy Issue Number: 15901
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the Message Flow Class Diagram (Figure 9.14), Interaction Node has four subclasses: Participant, ConversationNode, Task and Event.

    However, according to page 124:
    Of the types of InteractionNode, only Pools/Participants, Activities, and
    Events can be the source of a Message Flow.

    The question now is, whether Task or Activity should be the subclass of Interaction Node.

    Suggestion: The Message Flow Connection Rules on page 44 specify that Message Flows can also connect to Sub-Processes. Therefore, I think it is necessary to define that Activity is a subclass of InteractionNode.

  • Reported: BPMN 2.0 — Wed, 15 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inheritance and Relationship of ResourceParameter

  • Key: BPMN21-274
  • Legacy Issue Number: 15900
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the class diagram (Figure 8.31) and the XML Schema, ResourceParameter inherits from BaseElement and has a relationship with cardinality [0..1] to ItemDefinition.

    However, according to the last paragraph on page 96: The ResourceParameter element inherits the attributes and model associations of BaseElement (see Table 8.5)
    through its relationship to RootElement. In addition, Table 8.50 defines no cardinality for the relationship type and, therefore, leads to the assumption that the cardinality is 1.

    Suggestion: As the element Resource is also derived from RootElement, it would fit to also derive ResourceParameter from RootElement. Considering the cardinality, I would suggest to define a cardinality of [0..1].

  • Reported: BPMN 2.0 — Wed, 15 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 140-141. Wrong name of model associations

  • Key: BPMN21-187
  • Legacy Issue Number: 15584
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    a) Page 140

    It says:
    “A Collaboration uses ParticipantAssociations and MessageFlowAssociations for this purpose.”

    The name of the model associations are: participantAssociatios and messageFlowAssociations (see Figure 9.33, p. 142; Table 9.1, p.111).

    Then, it should say:
    “A Collaboration uses participantAssociatios and messageFlowAssociations for this purpose.”

    “ParticipantAssociations and MessageFlowAssociations” should be replaced by “participantAssociatios and messageFlowAssociations”
    --------------------------------------------------------------------------

    b) Page 140

    It says:
    “To handle the Participants, the innerParticipant of a ParticipantAssociation refers to a Participant in the Choreography, while the outerParticipant refers to …”

    The name of the model associations are: innerParticipantRef and outerParticipantRef (see Figure 9.33, p. 142; Table 9.7, p.121).

    Then, it should say:
    “To handle the Participants, the innerParticipantRef of a ParticipantAssociation refers to a Participant in the Choreography, while the outerParticipantRef refers to …”

    “innerParticipant” should be replaced by “innerParticipantRef”
    “outerParticipant” should be replaced by “outerParticipantRef ”
    --------------------------------------------------------------------------

    c) Page 141

    It says:
    “…Participants could be assumed to be the inner and outerParticipants of a ParticipantAssociation.”

    The name of the model associations are: innerParticipantRef and outerParticipantRef (see Figure 9.33, p. 142; Table 9.7, p.121).

    Then, it should say:
    “…Participants could be assumed to be the innerParticipantRef and outerParticipantRef of a ParticipantAssociation.”

    “inner and outerParticipants” should be replaced by “innerParticipantRef and outerParticipantRef ”
    --------------------------------------------------------------------------

    d) Page 141

    It says:
    “To handle Message Flows, the innerMessageFlow of a MessageFlowAssociation refers to a Message Flow in the Choreography, while the outerMessageFlow refers to …”

    The name of the model associations are: innerMessageFlowRef and outerMessageFlowRef (see Figure 9.33, p. 142; Table 9.9, p.125).

    Then, it should say:
    “To handle Message Flows, the innerMessageFlowRef of a MessageFlowAssociation refers to a Message Flow in the Choreography, while the outerMessageFlowRef refers to …”

    “innerMessageFlow” should be replaced by “innerMessageFlowRef”
    “outerMessageFlow” should be replaced by “outerMessageFlowRef”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 132. “Communication” instead of “Conversation” Figure 9.23

  • Key: BPMN21-186
  • Legacy Issue Number: 15583
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “Figure 9.23 ­ A Communication element”

    “Communication” element in Beta 1 is “Conversation” in Beta 2.

    Then, is should be
    “Figure 9.23 ­ A Conversation element”

    “Communication” should be replaced by “Conversation”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 283. The number of types of Event handlers

  • Key: BPMN21-196
  • Legacy Issue Number: 15593
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “There are three (3) types of Event handlers: those that start a Process, those that are part of the normal Sequence Flow, and those that are attached to Activities, either via boundary Events or via separate inline handlers in case of an Event Sub-Process.”

    Actually, there are four Sub-Sections:
    1) Handling Start Events (p.283)
    2) Handling Events within normal Sequence Flow (Intermediate Events) (p. 284)
    3) Handling Events attached to an Activity (Intermediate boundary Events and Event Sub-Processes) (p.285). With two sub-sub-.sections.
    4) Handling End Events (p.288)

    Then, it should say:
    “There are four (4) types of Event handlers: those that start a Process, those that are part of the normal Sequence Flow, those that are attached to Activities, either via boundary Events or via separate inline handlers in case of an Event Sub-Process, and those that end a Process.”

    “three (3) types” should be replaced by “four (4) types”
    “and those that are attached to Activities” should be replaced by “those that are attached to Activities”
    “Event Sub-Process.” should be replaced by “Event Sub-Process, and those that end a Process.”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 281. Wrong name of Figure 10.92

  • Key: BPMN21-195
  • Legacy Issue Number: 15592
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Figure 10.92.

    It says
    “Figure 10.92 ­ Multiple Events”

    Figure 10.92 shows Parallel Multiple Events, not Multiple Events (see Figure 10.90, p.280).

    It should say
    “Figure 10.92 ­ Parallel Multiple Events”

    “Multiple” should be replaced by “Parallel Multiple”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 171. “Manual Task” instead of “User Task”

  • Key: BPMN21-190
  • Legacy Issue Number: 15587
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    First paragraph says:
    “The User Task inherits the attributes and model associations of Activity (see Table 10.3), but does not have any additional attributes or model associations.”

    This sentence is in sub-section “Manual Task”, which starts on page 170.

    Then, it should say:
    “The Manual Task inherits the attributes and model associations of Activity (see Table 10.3), but does not have any additional attributes or model associations.”

    “User Task” should be replaced by “Manual Task”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pages 165-167. “implementation” attribute of Send and Receive Tasks

  • Key: BPMN21-189
  • Legacy Issue Number: 15586
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    a) Page 165

    Table 10.9. Row “implementation”.

    It says:
    “… that will be used to send and receive the Messages.”

    Table 10.9 describes Send Task element, so the Messages are sent only.

    Then, it should say:
    “… that will be used to send the Messages.”

    “send and receive” should be replaced by “send”
    ---------------------------------------------------------------------

    b) Page 167

    Table 10.10. Row “implementation”.

    It says:
    “… that will be used to send and receive the Messages.”

    Table 10.10 describes Receive Task element, so the Messages are received only.

    Then, it should say:
    “… that will be used to receive the Messages.”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 130. Nonexistent Conversation “Special Cover” is mentioned

  • Key: BPMN21-185
  • Legacy Issue Number: 15582
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “An example is Delivery Planning which leads to Carrier Planning and Special Cover.”

    Conversation “Special Cover” is not shown in Figure 9.18, p.127.

    Maybe Conversation “Special Cover” is the Conversation between Shipper and Insurance (Figure 9.18), which has not name.

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 128. Wrong name of Conversation “Delivery/Dispatch Plan”

  • Key: BPMN21-184
  • Legacy Issue Number: 15581
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “… a Message exchange in the Delivery Negotiation leads to Shipment Schedule, Delivery Planning and Delivery/Dispatch Conversations and these could be combined …”

    The name of the Conversation is “Delivery/Dispatch Plan”, not “Delivery/Dispatch”. See Figure 9.18. p.127.

    Then, it should say:
    “… a Message exchange in the Delivery Negotiation leads to Shipment Schedule, Delivery Planning and Delivery/Dispatch Plan Conversations and these could be combined …”

    “Delivery/Dispatch” should be replaced by “Delivery/Dispatch Plan”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 246. Typo

  • Key: BPMN21-193
  • Legacy Issue Number: 15590
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Sub-Section Start Event Triggers

    It says:
    “Start Events can be used for three types of Processes:”

    But four are listed. The third (Global Process) is explained in Sub-Sections: “Start Event for Top-Level Processes” and “Start Events for Sub-Processes”.

    Then, it should say:
    “Start Events can be used for four types of Processes:”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 224. Typos

  • Key: BPMN21-192
  • Legacy Issue Number: 15589
  • Status: open  
  • Source: Anonymous
  • Summary:

    a) Sub-section Send Task Mapping

    It says:
    “…there MUST be at most inputSet set and at most one Data Input on the Send Task.”

    It should say:
    “…there MUST be at most one inputSet set and at most one Data Input on the Send Task.”

    “at most inputSet” should be replaced by “at most one inputSet”

    b) Sub-section Recieve Task Mapping
    It says:
    “…there MUST be at most outputSet set and at most one Data Output on the Receive Task.”

    It should say:
    “…there MUST be at most one outputSet set and at most one Data Output on the Receive Task.”

    “at most outputSet” should be replaced by “at most one outputSet”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 154. “Choreography” instead of “Process

  • Key: BPMN21-188
  • Legacy Issue Number: 15585
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “Some BPMN elements are common to both Process and Choreography, as well as Collaboration; they are used in these diagrams. The next few sections will describe the use of Messages, Message Flows, Participants, Sequence Flows, Artifacts, Correlations, Expressions, and Services in Choreography.”

    Chapter 10 is devoted to Processes, not to Choreographies. The same paragraph is in 9.1.1 (p.112), where “the next sections” describe the use of BPM elements in Choreography. But in 10.1.2, they describe the use of BPM elements in Processes.

    It should say:
    “Some BPMN elements are common to both Process and Choreography, as well as Collaboration; they are used in these diagrams. The next few sections will describe the use of Messages, Message Flows, Participants, Sequence Flows, Artifacts, Correlations, Expressions, and Services in Process.”

    “and Services in Choreography” should be replaced by “and Services in Process”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 255. Message End Event sends Messages

  • Key: BPMN21-194
  • Legacy Issue Number: 15591
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 10.88. Row “”Message”.

    It says
    “The actual Participant from which the Message is received can be identified …”

    Table 10.88 describes End Event Types, so the Message can only be sent.

    Then, it should say
    “The actual Participant to which the Message is sent can be identified …”

    “from which” should be replaced by “to which”
    “is received” should be replaced by “is sent”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 190. Paragraph needs to be nested

  • Key: BPMN21-191
  • Legacy Issue Number: 15588
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Paragraph:
    “If the details of the called Process are available, then the shape of the Call Activity will be the same as a expanded Sub-Process, but the boundary of the shape MUST have a thick line (see Figure 10.41).”

    This paragraph should be a sub-bullet of “If the Call Activity calls a Process, then there are two (2) options:”, because it describes the second option.

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 78. Wrong association type in Table 8.32

  • Key: BPMN21-183
  • Legacy Issue Number: 15580
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 8.32. Row “type”

    It says
    “type: string [0..1]

    Model Association “type” is an “ItemDefinition” (see Figure 8.17, page 76).

    Then, it should say
    “type: ItemDefinition [0..1]

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pages 221-223. Inheritance of DataInput, DataOutput. Wrong table reference

  • Key: BPMN21-158
  • Legacy Issue Number: 15538
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    a) Page 221

    It says:
    “The DataInput element inherits the attributes and model associations of BaseElement (see Table 8.5) and ItemAwareElement (Table 10.52).”

    DataInput is subclass of ItemAwareElement, which is subclass of BaseElement (see Figure 10.50, p.211). Furthermore, attributes and model associations of ItemAwareElement are shown in Table 10.51.

    Then, it should say:
    “The DataInput element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to ItemAwareElement (Table 10.51).”
    ----------------------------------------------------------------------------------------------------

    b) Page 223
    It says:
    “The DataOutput element inherits the attributes and model associations of BaseElement (see Table 8.5) and ItemAwareElement (Table 10.52).”

    DataOutput is subclass of ItemAwareElement, which is subclass of BaseElement (see Figure 10.50, p.211). Furthermore, attributes and model associations of ItemAwareElement are shown in Table 10.51.

    Then, it should say:
    “The DataOutput element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to ItemAwareElement (Table 10.51).”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 221. Nonexistent attribute “optional” mentioned

  • Key: BPMN21-157
  • Legacy Issue Number: 15537
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “The “optional” attribute defines if a DataInput is valid even if the state is “unavailable”. The default value is false. If the value of this attribute is true, then the execution of the Activity will not begin until a value is assigned to the DataInput element, through the corresponding Data Associations.”

    Problem: The “optional” attribute of “DatInput” is mentioned, but it is not shown in any Table or Figure (in particular Figure 10.59, p. 221; and Table 10.59, p. 222).

    This paragraph should be removed; or the attribute “optional” should be added in Table 10.59 and Figure 10.59.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 308. Incorrect name of Parallel Event-Based Gateway 1

  • Key: BPMN21-166
  • Legacy Issue Number: 15546
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “The Parallel Event Gateway is also a type of race condition...”

    It should say:
    “The Parallel Event-Based Gateway is also a type of race condition ...”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 202. Wrong multiplicity of model association “event”

  • Key: BPMN21-156
  • Legacy Issue Number: 15536
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 10.31. Row “event”.

    It says:
    “event: ImplicitThrowEvent”

    Model association “event” is optional, see Figure 10.45 (p.196).

    Then, it should say:
    “event: ImplicitThrowEvent [0..1]

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 192. Association “calledElementRef”: wrong name, location and description

  • Key: BPMN21-155
  • Legacy Issue Number: 15535
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Figure 10.42. and Table 10.23.

    a) Figure 10.42

    Model association from “CallActivity” to “CallableElement”.
    Role name “calledElementRef” is located near class “CallActivity”, but it must be located near class CallableElement.
    ---------------------------------------------------------------------

    b) Table 10.23. Row “calledElement”
    It says:
    “calledElement: CallableElement [0..1]

    It should say:
    “calledElementRef: CallableElement [0..1]

    “calledElement” should be replaced by “calledElementRef”
    ----------------------------------------------------------------------

    c) Table 10.23. Row “calledElement”

    It says:
    “… MUST NOT be called by the Call Conversation element.”

    Table 10.23 describes “CallActivity” model associations, not “Call Conversation” model associations (Table 9.12, p. 134).

    Then, it should say:
    “… MUST NOT be called by the Call Activity element.”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pages 230-231. Wrong name of Table 10.64

  • Key: BPMN21-161
  • Legacy Issue Number: 15541
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    “Assignment” has no attributes and two model associations (see Figure 10.64, p.229).

    Page 230.

    It says:
    “Table 10.64 presents the additional attributes of the Assignment element:”

    It should say:
    “Table 10.64 presents the additional model associations of the Assignment element:”
    --------------------------------------------------------------------------
    Page 231.

    It says:
    “Table 10.64 ­ Assignment attributes”

    It should say:
    “Table 10.64 ­ Assignment model associations”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 230. Super-class of ”Assignment” not shown in any diagram

  • Key: BPMN21-160
  • Legacy Issue Number: 15540
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “The Assignment element inherits the attributes and model associations of BaseElement (see Table 8.5).”

    But, it is not shown in any diagram that “Assignment” is subclass of “Base Element”.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 266. Wrong role name "attachedToRef" in Table 10.91

  • Key: BPMN21-164
  • Legacy Issue Number: 15544
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 10.91. Row “attachedTo”

    It says:
    “attachedTo: Activity”

    It should say:
    “attachedToRef: Activity”

    See Figure 10.69 (p.241).

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 241. Wrong role names in Figure 10.69

  • Key: BPMN21-163
  • Legacy Issue Number: 15543
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Figure 10.69.

    a) Role name “dataOutputAssociation” (from “CatchEvent” to “DataOutputAssociation”) should be “dataOutputAssociations”.

    See Table 10.82 (p. 243). Row “dataOutputAssociations”
    ---------------------------------------------------------------------------------------

    b) Role name “dataInputAssociation” (from “ThrowEvent” to “DataInputAssociation”) should be “dataInputAssociations”.

    See table 10.83 (p. 245). Row “dataInputAssociations”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 230. Wrong type of model association “transformation”

  • Key: BPMN21-159
  • Legacy Issue Number: 15539
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 10.63. Row “transformation”.

    It says:
    “transformation: Expression [0..1]

    “transformation” is a role name of the association from “DataAssociation” to “FormalExpression” (see Figure 10.64, p.229). So the type is not “Expression”, but “FormalExpression”.

    Then, it should say:
    “transformation: FormalExpression [0..1]

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 185. Nonexistent enumeration used in Table 10.21

  • Key: BPMN21-154
  • Legacy Issue Number: 15534
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 10.21 and Figure 10.29 (p. 181)

    Enumeration TransactionMethod was removed from Figure 10.29 (p.181), but it is still used in Table 10.21 (p.185) in attribute “method”.

    Maybe “method: TransactionMethod” should be replaced by “method: string” as it is defined in Figure 10.29.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 231. Activity is not an Item Aware Element

  • Key: BPMN21-162
  • Legacy Issue Number: 15542
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “…one from a item-aware element (e.g., an Activity) contained by the source of the Sequence Flow, …”

    “Activity” is not an item-aware element, but it contains an item-aware element (see Figure 10.50, p. 211; Figure 10.57, p. 219).

    Then, it should say:
    “…one from an item-aware element contained by the source of the Sequence Flow (e.g., an Activity), …”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 274. Wrong role name “errorRef” in Table 10.96

  • Key: BPMN21-165
  • Legacy Issue Number: 15545
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 10.96. Row “error”

    It says:
    “error: Error [0..1]

    It should say:
    “errorRef: Error [0..1]

    See Figure 10.80 (p.274).

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter 10. Typos

  • Key: BPMN21-133
  • Legacy Issue Number: 15505
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    a) Section 10. Page 151.

    Table 10.1. Row “processType”.

    It says
    “The processType attribute Provides additional information …”

    It should say
    “The processType attribute provides additional information …”

    “Provides” should be replaced by “provides”.
    ----------------------------------------------------------

    b) Section 10.2. Page 157.

    Table 10.3. Row “completionQuantity”.

    It says
    “This number of tokens will be sent done ...”

    It should say
    “This number of tokens will be sent down ...”

    “sent done” should be replaced by “sent down ”
    ----------------------------------------------------------

    c) Section 10.2.3. Page 161.

    The words “marker” and “Marked” are nor used consistently throughout the text. For example:

    On p. 161:
    “The loop Marker MAY be used in combination with the compensation marker.”

    On p. 197:
    “The loop Marker MAY be used in combination with the Compensation Marker.”

    On p.198:
    “The Multi-Instance marker MAY be used in combination with the Compensation marker.”
    ----------------------------------------------------------

    d) Section 10.2.4. Page 170.

    It says
    “Manual Tasks and User Tasks have a Icons to indicate ...”

    It should say
    “Manual Tasks and User Tasks have icons to indicate ...”

    “a Icons” should be replaced by “icons”
    ----------------------------------------------------------

    e) Section 10.3.1. Page 224.

    It says
    “…the payloard within the Message will not flow out of the Receive Task and into the Process.”

    It should say
    “…the payload within the Message will not flow out of the Receive Task and into the Process.”

    “payloard” should be replaced by “payload”
    ----------------------------------------------------------

    f) Section 10.3.1. Page 231.

    It says
    “… a DataOutput contained within an ACTIVITY with any ItemAwareElement accessible …”

    It should say
    “… a DataOutput contained within an Activity with any ItemAwareElement accessible …”

    “ACTIVITY” should be replaced by “Activity”
    ----------------------------------------------------------

    g) Section 10.3.1. Page 231.

    It says
    “…one from a item-aware element … to a item-aware element …”

    It should say
    “…one from an item-aware element … to an item-aware element …”

    “a item-aware” should be replaced (twice) by “an item-aware”
    ----------------------------------------------------------

    h) Section 10.4.2. Page 248.

    Table 10.84. Row “Multiple”
    It says
    “(a pentagon—see the upper figure to the right)”

    It should say
    “(a pentagon—see figure to the right)”

    “see the upper figure” should be replaced by “see figure”
    ----------------------------------------------------------

    i) Section 10.4.4. Page 263.

    Table 10.90. Row “Compensation”.

    It says
    “Note that the interrupting a non-interrupting aspect of ...”

    It should say
    “Note that the interrupting and non-interrupting aspect of ...”

    “a non-interrupting” should be replaced by “and non-interrupting”
    ----------------------------------------------------------

    j) Section 10.4.5. Page 273.

    Paragraph
    “The ConditionalEventDefinition element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to the EventDefinition element (see page 268). Table 10.95 presents the additional model associations of the ConditionalEventDefinition element:”

    It is repeated twice. The first one should be removed.
    ----------------------------------------------------------

    k) Section 10.4.5. Page 275.

    It says
    “When used to “throw” to the target Link, the Event marker will be filled (see Figure 10.84: upper: lower Left).”

    It should say
    “When used to “throw” to the target Link, the Event marker will be filled (see Figure 10.84: lower left).”

    “upper: lower Left” should be replaced by “lower left”

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter 9. Typos

  • Key: BPMN21-132
  • Legacy Issue Number: 15504
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    a) Section 9.4. Page 125.

    9.4 Conversations

    It says
    “The Conversation diagram is particular usage of and an informal description …”

    It should say
    “The Conversation diagram is a particular usage of and an informal description …”

    “is particular usage” should be replaced by “is a particular usage”
    ----------------------------------------------------------

    b) Section 9.4. Page 128.

    It says
    “Figure 9.20 shows a how the Sub-Conversation of ...”

    It should say
    “Figure 9.20 shows how the Sub-Conversation of ...”

    “a how” should be replaced by “how”
    ----------------------------------------------------------

    c) Section 9.4. Page 129.

    It says
    “Figure 9.21 shows a how the Conversation of...”

    It should say
    “Figure 9.21 shows how the Conversation of...”

    “a how” should be replaced by “how”
    ----------------------------------------------------------

    d) Section 9.4.4. Page 134.

    Table 9.12. Row “calledCollaborationRef”

    It says
    “Collaboratioin [0..1]

    It should say
    “Collaboration [0..1]

    “Collaboratioin” should be replaced by “Collaboration”
    ----------------------------------------------------------

    e) Section 9.4.5. Page 134.

    It says
    “The GlobalConversation element inherits the attributes and model associations and Collaboration …”

    It should say
    “The GlobalConversation element inherits the attributes and model associations of Collaboration”

    “and Collaboration” should be replaced by “of Collaboration”
    ----------------------------------------------------------

    f) Section 9.4.6. Page 137.

    It says
    “…on the left with a Call Conversations to a Collaboration on the right.”

    It should say
    “…on the left with a Call Conversation to a Collaboration on the right.”

    “Conversations” should be replaced by “Conversation”
    ----------------------------------------------------------

    g) Section 9.4.6. Page 138.

    It says
    “For example, the Credit Agency Participants on the right corresponds …”

    It should say
    “For example, the Credit Agency Participant on the right corresponds …”

    “Participants” should be replaced by “Participant”
    ----------------------------------------------------------

    h) Section 9.4.8. Page 139.

    It says
    “ … and can be defined for the Message Flows that belong to the a Conversation.”

    It should say
    “…and can be defined for the Message Flows that belong to a Conversation.”

    “to the a” should be replaced by “to a”
    ----------------------------------------------------------

    i) Section 9.4.8. Page 140.

    It says
    “…if the conceptual data comprises of an order than the correlation field might be denoted …”

    It should say
    “…if the conceptual data comprises of an order then the correlation field might be denoted …”

    “than” should be replaced by “then ”

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter 8. Typos

  • Key: BPMN21-131
  • Legacy Issue Number: 15503
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    a) Section 8.2.3. Page 59.

    Table 8.10. Row “value”.

    It says
    “[Element [0..1]

    It should say
    “Element [0..1]

    First “[” should be removed
    ----------------------------------------------------------

    b) Section 8.2.3. Page 59.

    Table 8.10. Row “valueRef”.

    It says
    “[Element [0..1]

    It should say
    “Element [0..1]

    First “[” should be removed
    ----------------------------------------------------------

    c) Section 8.2.4. Page 62.

    It says
    “The ‘identity/relationship’ model it is reduced to the creation of families of typed relationships …”

    It should say
    “The ‘identity/relationship’ model is reduced to the creation of families of typed relationships …”

    “model it is reduced” should be replaced by “model is reduced”
    ----------------------------------------------------------

    d) Section 8.2.4. Page 63.

    Table 8.15. Row “sources”.

    It says
    “[Element [1..*]

    It should say
    “Element [1..*]

    First “[” should be removed
    ----------------------------------------------------------

    e) Section 8.2.4. Page 63.

    Table 8.15. Row “targets”.

    It says
    “[Element [1..*]

    It should say
    “Element [1..*]

    First “[” should be removed
    ----------------------------------------------------------

    f) Section 8.3.1. Page 67.

    It says
    “An Association is line that MUST be drawn …”

    It should say
    “An Association is a line that MUST be drawn …”

    “is line” should be replaced by “is a line”
    ----------------------------------------------------------

    g) Section 8.3.9. Page 90.

    It says
    “The details for the types of Gateways (Exclusive, Inclusive, Parallel, Event-Based, and Complex) is defined on page 295 …”

    It should say
    “The details for the types of Gateways (Exclusive, Inclusive, Parallel, Event-Based, and Complex) are defined on page 295 …”

    “is defined” should be replaced by “are defined”
    ----------------------------------------------------------

    h) Section 8.3.10. Page 92.

    Table 8.47. Row “structureRef”.

    It says
    “[Element [0..1]

    It should say
    “Element [0..1]

    First “[” should be removed
    ----------------------------------------------------------

    i) Section 8.3.11. Page 93.

    It says
    “In a Message is a rectangle with converging diagonal lines in the upper …”

    It should say
    “A Message is a rectangle with converging diagonal lines in the upper …”

    “In a” should be replaced by “A”
    ----------------------------------------------------------

    j) Section 8.3.12. Page 96.

    It says
    “These parameters can be used at runtime to define query e.g., into an …”

    It should say
    “These parameters can be used at runtime to define a query e.g., into an …”

    “define query” should be replaced by “define a query”

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter 7. Typos

  • Key: BPMN21-130
  • Legacy Issue Number: 15502
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    a) Section 7. Page 21.

    It says
    “BPMN provides a multiple diagrams, which are designed for use by the people who design and manage Business Processes.”

    It should say
    “BPMN provides multiple diagrams, which are designed for use by the people who design and manage Business Processes.”

    “a multiple” should be replaced by “multiple”
    ----------------------------------------------------------

    b) Section 7.2.2. Page 34.

    In table 7.2. Row “Conditional flow”

    It says
    “A Sequence Flow can have a condition Expression that are evaluated at runtime …”

    It should say
    “A Sequence Flow can have a condition Expression that is evaluated at runtime …”

    “that are evaluated” should be replaced by “that is evaluated”
    ----------------------------------------------------------

    c) Section 7.2.2. Page 34.

    In table 7.2. Row “Default flow”

    It says
    “These Sequence Flows will have a diagonal slash will be added to the beginning of the connector …”

    It should say
    “These Sequence Flows will have a diagonal slash added to the beginning of the connector …”

    “slash will be added” should be replaced by “slash added”
    ----------------------------------------------------------

    d) Section 7.2.2. Page 36.

    In table 7.2. Row “Fork”.

    It says
    “This represents “uncontrolled” flow is the preferred method for most situations.”

    It should say
    “This represents “uncontrolled” flow which is the preferred method for most situations.”

    “flow is” should be replaced by “flow which is”
    ----------------------------------------------------------

    e) Section 7.2.2. Page 39.

    Table 7.2. Row “Mutiple Instances”.

    It says
    “A set of three (3) horizontal liness will be displayed at the bottom-center of the activity for sequentail Multi-Instances (see upper figure to the right). A set of three (3) vertical liness will be displayed at the bottom-center of the activity for sequentail Multi-Instances (see lower figure to the right).”

    It should say
    “A set of three (3) horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see upper figure to the right). A set of three (3) vertical lines will be displayed at the bottom-center of the activity for parallel Multi-Instances (see lower figure to the right).”

    “horizontal liness” should be replaced by “horizontal lines”
    first “sequentail Multi-Instances” should be replaced by “sequential Multi-Instances”
    “vertical liness” should be replaced by “vertical lines”
    second “sequentail Multi-Instances” should be replaced by “parallel Multi-Instances”

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter 11. Typos

  • Key: BPMN21-134
  • Legacy Issue Number: 15506
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    a) Section 11.3.1. Page 330.

    It says
    “Because the other outgoing Sequence Flows will have appropriately visible of data as described above, …”

    It should say
    “Because the other outgoing Sequence Flows will have appropriate visibility of data as described above, …”

    “have appropriately visible” should be replaced by “have appropriate visibility”
    ----------------------------------------------------------

    b) Section 11.4.1. Page 337.

    It says
    “The width of the Participant Band will be expanded to contain both the name of the Participant and the multi-instance marker.”

    It should say
    “The high of the Participant Band will be expanded to contain both the name of the Participant and the multi-instance marker.”

    “width” should be replaced by “high”

    Note: On page 342 this (equivalent) sentence is a sub-bullet.
    ----------------------------------------------------------

    c) Section 11.4.2. Page 341.

    It says
    “In addition, any Participant Band beyond the first two optional; ...”

    It should say
    “In addition, any Participant Band beyond the first two is optional; ...”

    “two optional” should be replaced by “two is optional”
    ----------------------------------------------------------

    d) Section 11.4.2. Page 342.

    It says
    “The width of the Participant Band will be expanded to contain both the name of the Participant and the multi-instance marker.”

    It should say
    “The high of the Participant Band will be expanded to contain both the name of the Participant and the multi-instance marker.”

    “width” should be replaced by “high”

    Note: On page 337 this (equivalent) sentence is not a sub-bullet.
    ----------------------------------------------------------

    e) Section 11.4.2. Page 342.

    Figure 11.23.

    It says
    “Figure 11.23 - Sub-Choreography Markers with a multi-instance Participant”

    It should say
    “Figure 11.23 ­ A Sub-Choreography with a multi-instance Participant”

    “Sub-Choreography Markers” should be replaced by “A Sub-Choreography”

    Note: Compare it with Figure 11.15, p.337.
    ----------------------------------------------------------

    f) Section 11.4.6. Page 345.

    It says
    “…when the Participants send or receive Messages so that they Participants are NOT REQUIRED to guess about when it is their turn to send a Message.”

    It should say
    “…when the Participants send or receive Messages so that the Participants are NOT REQUIRED to guess about when it is their turn to send a Message.”

    “they Participants” should be replaced by “the Participants”

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter14. Typos

  • Key: BPMN21-136
  • Legacy Issue Number: 15508
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    a) Section 14.1.1. Page 463.

    It says
    “The following figure describes the mapping of a Process, represented by its defining Collaboration, to WS-BPEL. The process itself is described by a contained graph G of flow elements) to WS-BPEL.”

    Maybe it should say
    “The following figure describes the mapping of a Process, represented by its defining Collaboration, to WS-BPEL. The process itself is described by a contained graph G of flow elements.”

    “elements) to WS-BPEL” should be replaced by “elements”
    ----------------------------------------------------------

    b) Section 14.1.2. Page 466.

    It says
    “(i.e., Message Events, Service, send or Receive Tasks)”

    It should say
    “(i.e., Message Events, Service, Send or Receive Tasks)”

    “send” should be replaced by “Send”.

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter 13. Typos

  • Key: BPMN21-135
  • Legacy Issue Number: 15507
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    ) Section 13.1. Page 440.

    It says
    “A token reaching an End Event triggers the behavior associated with the Event type is, …”

    It should say
    “A token reaching an End Event triggers the behavior associated with the Event type, …”

    “type is” should be replaced by “type”
    ----------------------------------------------------------

    b) Section 13.4.5. Page 457.

    It says
    “A compensation Event Sub-Process can in particular recursively trigger compensation for Activities contained in that its parent.”

    It should say
    “A compensation Event Sub-Process can in particular recursively trigger compensation for Activities contained in its parent.”

    “in that its” should be replaced by “in its”
    ----------------------------------------------------------

    c) Section 13.4.5. Page 458.

    It says
    “Second, if no error Event Sub-Process is specified for a particular Sub-Process and a particular error, …”

    It should say
    “Second, if no error Event Sub-Process is specified for a particular Sub-Process and a particular error occurs, …”

    “particular error,” should be replaced by “particular error occurs,”

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 485. Wrong reference to figure 14.2

  • Key: BPMN21-129
  • Legacy Issue Number: 15475
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “End Events can be combined with other BPMN objects to complete the merging or joining of the paths of a WSBPEL structured element (see Figure 7.3).”

    It should say
    “End Events can be combined with other BPMN objects to complete the merging or joining of the paths of a WSBPEL structured element (see Figure 14.2).”

    “Figure 7.3” should be replaced by “Figure 14.2”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 313. Wrong references to figures 10.123 10.124

  • Key: BPMN21-128
  • Legacy Issue Number: 15474
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “A Lane is a sub-partition within a Process (often within a Pool) and will extend the entire length of the Process level,, either vertically (see Figure 10.122) or horizontally (see Figure 10.123).”

    It should say
    “A Lane is a sub-partition within a Process (often within a Pool) and will extend the entire length of the Process level,, either vertically (see Figure 10.123) or horizontally (see Figure 10.124).”

    “Figure 10.122” should be replaced by “Figure 10.123”
    “Figure 10.123” should be replaced by “Figure 10.124”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 231. Wrong reference to table 10.63 2

  • Key: BPMN21-123
  • Legacy Issue Number: 15469
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “The DataOutputAssociation element inherits the attributes and model associations of DataAssociation (see Table 10.64), but does not contain any additional attributes or model associations.”

    It should say
    “The DataOutputAssociation element inherits the attributes and model associations of DataAssociation (see Table 10.63), but does not contain any additional attributes or model associations.”

    “Table 10.64” should be replaced by “Table 10.63

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 231. Wrong reference to table 10.63 1

  • Key: BPMN21-122
  • Legacy Issue Number: 15468
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “The DataInputAssociation element inherits the attributes and model associations of DataAssociation (see Table 10.64), but does not contain any additional attributes or model associations.”

    It should say
    “The DataInputAssociation element inherits the attributes and model associations of DataAssociation (see Table 10.63), but does not contain any additional attributes or model associations.”

    “Table 10.64” should be replaced by “Table 10.63”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 248. Wrong reference to table 10.85

  • Key: BPMN21-125
  • Legacy Issue Number: 15471
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “There is only one (1) type of Start Event for Sub-Processes in BPMN (see Figure 10.82): None.”

    It should say
    “There is only one (1) type of Start Event for Sub-Processes in BPMN (see Table 10.85): None.”

    “Figure 10.82” should be replaced by “Table 10.85”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 245. Wrong reference to table 10.83

  • Key: BPMN21-124
  • Legacy Issue Number: 15470
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “The ImplicitThrowEvent element inherits the attributes and model associations of ThrowEvent (see Table 10.84), …”

    It should say
    “The ImplicitThrowEvent element inherits the attributes and model associations of ThrowEvent (see Table 10.83), …”

    “Table 10.84” should be replaced by “Table 10.83”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page. 300. Wrong reference to page 450

  • Key: BPMN21-127
  • Legacy Issue Number: 15473
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “The precise synchronization behavior of the Inclusive Gateway can be found on page 300.”

    It should say
    “The precise synchronization behavior of the Inclusive Gateway can be found on page 450.”

    “page 300” should be replaced by “page 450”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 266. Wrong reference to table 10.91

  • Key: BPMN21-126
  • Legacy Issue Number: 15472
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “Table 8.46 presents the additional attributes and model associations of the Boundary Event element:”

    It should say
    “Table 10.91 presents the additional attributes and model associations of the Boundary Event element:”

    “Table 8.46” should be replaced by “Table 10.91”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Left over restrictions on use of Start and End Events

  • Key: BPMN21-137
  • Legacy Issue Number: 15509
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Issue 14783 relaxed the restrictions on the use of Start and End Events. But there are two statements in the spec that are left over.
    On page 248:
    "If there is an End Event, then there MUST be at least one Start Event."
    This should be removed

    On page 256:
    "If there is a Start Event, then there MUST be at least one End Event."
    This should be removed

  • Reported: BPMN 2.0 — Fri, 10 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Conditions for completion of Process and Sub-Process

  • Key: BPMN21-248
  • Legacy Issue Number: 15755
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 10.4.2. Page 245. It says:

    “There MAY be multiple Start Events for a given Process level.

    • Each Start Event is an independent Event. That is, a Process instance SHALL be generated when
      the Start Event is triggered.”

    ii) Chapter/Section 13.1. Page 440. It says:

    “To specify that the instantiation of a Process waits for multiple Start Events to happen, a Multiple Parallel Start
    Event can be used.”

    “Note that two Start Events are alternative, A Process instance triggered by one (1) of the Start Events does not wait
    for an alternative Start Event to occur.”

    “Note that there MAY be multiple instantiating Parallel Event-Based Gateways.
    This allows the modeler to express that either all the Events after the first Gateway occur or all the
    Events after the second Gateway and so forth.”

    “Each Start Event that occurs creates a token on its outgoing Sequence Flows, which is followed as described by the
    semantics of the other Process elements.”

    iii) Chapter/Section 13.4.6. Page 458. It says:
    “The Process instance is then completed, if and only if the following two conditions hold:”

    • All start nodes of the Process have been visited. More precisely, all Start Events have been triggered,
      and for all starting Event-Based Gateways, one of the associated Events has been triggered.”

    iv) Chapter/Section 13.4.6. Page 459. It says:
    “The Sub-Process instance is then completed, if and only if the following two conditions hold:

    • All start nodes of the Sub-Process have been visited. More precisely, all Start Events have been triggered,
      And for all starting Event-Based Gateways, one of the associated Events has been triggered.”

    COMMENTS:

    >From and (ii) can be deduced that each tart node (start event or start event-based gateway) is independent, i.e. the activation of one of them generates an new independent instance of the Process.

    But in (iii) and (iv) it is said that all start nodes must be visited as a pre-condition to complete the execution of the Process instance. This contradicts what it is stated in and (ii).

    SUGGESTIONS:

    Modify (iii) and (iv) to make them consistent with what it is stated in and (ii).

    Typo in (ii): “… are alternative, A Process instance…” should be replaced by “… are alternative. A Process instance…”

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Apparent contradiction concerning compensation handler invocations

  • Key: BPMN21-247
  • Legacy Issue Number: 15754
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 13.4.5. Page 457. It says:
    “Triggering compensation for the Multi-Instance Sub-Process individually triggers compensation for all instances within the current scope. If compensation is specified via a boundary compensation handler, this boundary compensation handler also is invoked once for each instance of the Multi-Instance Sub-Process in the current scope.”

    ii) Chapter/Section 13.4.5. Page 458. It says:
    “In case the Activity is a multi-instance or loop, the Compensation Activity is triggered only once, too, and thus has to compensate the effects of all instances.”

    COMMENTS:

    It seems there is a contradiction between and (ii).

    • In there are as many invocations as instances are.
    • In (ii) there is only one invocation for many instances.

    SUGGESTIONS:

    Clarify whether there is a contradiction or not.

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Table 10.56 is named Data Store attributes instead of Data Store Reference attributes

  • Key: BPMN21-258
  • Legacy Issue Number: 15809
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    On page 217 Table 10.56 is named Data Store attributes instead of Data Store Reference attributes.

    Table 10.55 shows the real Data Store attributes. In addition, the last sentence on page 216 rightly specifies: "Table 10.56 presents the additional model associations of the Data Store Reference element:".

  • Reported: BPMN 2.0 — Wed, 10 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Outgoing Paths after Inclusive Gateway

  • Key: BPMN21-257
  • Legacy Issue Number: 15808
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    I think that the number of outgoing paths after an Inclusive Gateway are conflicting. According to page 37 and page 300, all combinations of paths MAY be taken, from zero to all. However, on page 362 it is mentioned several times that one or more alternative branches are chosen (one of more
    branches MAY be activated upstream). The difference is taking zero paths.

    Is it possible to take zero paths after an Inclusive Gateway? If yes, is the process flow interrupted or can the flow just continue after a later merge? What happens if there is no corresponding merge for the split? It seems that taking zero paths is possible based on the conditions which are evaluated separately.

    However, I think, that the specification from page 362 should be taken and that one or more outgoing paths receive a token. Then A OR B can also be transformed to (A XOR B) XOR (A AND B). Also the definition of logical disjunction is that one or more of its operands are true (according to the truth table A OR B is only false if A is false and B is false).

    If the intention behind taking zero paths is that it should be possible to execute non of the tasks, then my second suggestion would be to define that an "empty" path is mandatory and if no task should be executed then a token can be sent on the "empty" path.

    Also if the separately evaluated conditions are the reason for allowing zero paths, again a mandataroy empty default path could be a solution to avoid that the inclusive split contradicts with the logical disjunction.

    As Inclusive Gateways are a very complex topic a discussion would be interesting.

  • Reported: BPMN 2.0 — Tue, 9 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong configuration of Event-Based Gateway

  • Key: BPMN21-253
  • Legacy Issue Number: 15760
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 10.5.6. Page 306. It says:
    “Event-Based Gateways are configured by having outgoing Sequence Flows target an Intermediate Event
    or a Receive Task in any combination (see Figure 10.116 and Figure 10.117) except that:

    • If Message Intermediate Events are used in the configuration, then Receive Tasks MUST NOT be used
      in that configuration and vice versa.”

    ii) Chapter/Section 10.5.
    Page 298: “A diverging Exclusive Gateway (Decision) ...”
    Page 300: “A diverging Inclusive Gateway (Inclusive Decision) …”
    Page 305: “The Event-Based Gateway represents a branching point in the Process where the alternative paths
    that follow the Gateway are based on Events that occur, rather than the evaluation of Expressions
    using Process data (as with an Exclusive or Inclusive Gateway).”

    iii) Chapter/Section 14.1.4. Page 478. Sub-section “Exclusive (Event-based) Decision Pattern”.
    Figure shows tree branches with one Message Intermediate Event, one Receive Task
    and one Timer Intermediate Event.

    COMMENTS:

    According to Message Intermediate Events and Receive Tasks MUST NOT be used in the same configuration of an Event-Based Gateway. Nevertheless, in (iii) both are used in the same configuration.

    According to (ii) Exclusive and Inclusive Gateways are considered “decisions”, but not Event-Based Gateways.

    SUGGESTIONS:

    Modify Figure in Sub-section “Exclusive (Event-based) Decision Pattern”: use Message Intermediate Events or Receive Tasks, but not both.

    Name the Sub-section: “Exclusive (Event-based) Pattern”

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 473.Wrong reference to figure

  • Key: BPMN21-252
  • Legacy Issue Number: 15759
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Chapter/Section 14.1.3. Page 473. Sub-section “Message End Events” It says:
    “A Message Start Event is mapped to WS-BPEL as shown in the following figure:”

    SUGGESTIONS:

    It should say:
    “A Message End Event is mapped to WS-BPEL as shown in the following figure:”

    “Start Event” should be replaced by “End Event”

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

In Chapter 14 Figures are not numbered

  • Key: BPMN21-250
  • Legacy Issue Number: 15757
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    In Chapter 14 Figures and Tables are not numbered.

    COMMENTS:

    The absence of numbers in Figures and Tables complicates the reading.
    Furthermore, in the rest of the document the Figures and Tables are numbered.

    SUGGESTIONS:

    Number Figures and Tables in Chapter 14.

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Legal BPMN models and “lack of synchronization"

  • Key: BPMN21-249
  • Legacy Issue Number: 15756
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    ) Chapter/Section 10.2. Page 157. Table 10.3. Row “completionQuantity”. It says:
    “This attribute defines the number of tokens that MUST be generated from the Activity. This number of tokens will be sent down any outgoing Sequence Flow …”

    ii) Chapter/Section 13.3.5. Page 452. It says:
    “Each incoming gate of the Complex Gateway has an attribute activationCount, which can be used in an Expression as an integer-valued variable. This variable represents the number of tokens that are currently on the respective incoming Sequence Flow.”

    iii) Chapter/Section 14. Page 461. It says:
    “To map a BPMN orchestration Process to WS-BPEL it MUST be sound, that is it MUST contain neither a deadlock nor a lack of synchronization. A deadlock is a reachable state of the Process that contains a token on some Sequence Flow that cannot be removed in any possible future. A lack of synchronization is a reachable state of the Process where there is more than one token on some Sequence Flow.”

    COMMENTS:

    >From and (ii) can be deduced that a correct BPMN model allows Process instances with Sequence Flows containing more than one token.

    According to (iii) this is considered a “lack of synchronization”, which prevents the mapping to WS-BPEL.

    SUGGESTIONS:

    Clarify whether “lack of synchronization” means that the Model is illegal or not.

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

“empty Start Event” is used instead of “None Start Event”

  • Key: BPMN21-246
  • Legacy Issue Number: 15753
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    In Chapter 13 the expression “empty Start Event” is used instead of “None Start Event”, the latter is used in all other Chapters.

    SUGGESTION:

    Use “the expression “None Start Event” in order to be consistent with the rest of the document.

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Terminate End Event in a Choreography with many Participants

  • Key: BPMN21-245
  • Legacy Issue Number: 15752
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 11.5.3. Page 354. Table 11.8. Row “Terminate”. It says:
    “The use of the Terminate End Event really only works when there are
    only two (2) Participants. If there are more than two (2) Participants, then any
    Participant that was not involved in the last Choreography Task would not necessarily
    know that the Terminate End Event had been reached.”

    ii) Chapter/Section 11.6.5. Page 371. Figure 11.48.
    Four (4) Participants (Purchaser and Service Providers A, B, C) are involved, and it ends with a Terminate End Event.

    COMMENTS:

    According to , the Terminate End Event in Choreography depicted in (ii) doesn’t work.

    In it is said “any Participant that was not involved in the last Choreography Task would not necessarily know that the Terminate End Event had been reached”, so it seems that in some cases Terminate End Event could work when there are
    More than two (2) Participants.

    SUGGESTIONS:

    Clarify whether the Terminate End Event in Figure 11.48 works or not.

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reference calledChoreographyRef of CallChoreography refers to Choreography and to CallableElement

  • Key: BPMN21-256
  • Legacy Issue Number: 15807
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    The calledChoreographyRef of CallChoreography refers to different Elements and is therefore conflicting.

    According to the class diagram (Figure 11.27) CallChoreography has a relationship calledChoreographyRef that references Choreography.

    According to the Model Associations on page 345, calledChoreographyRef references CallableElement.

    I think that based on the other text the relationship to Choreography is correct. The Model Associations should be corrected.

  • Reported: BPMN 2.0 — Tue, 9 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 10.127, private process supports public process

  • Key: BPMN21-255
  • Legacy Issue Number: 15806
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    In Figure 10.127, one process supports another. According to the corresponding text a message is sent and afterwards received and the same order is required by the public and the private process.

    However, in the figure the private process sents and receives a message, but the public process first receives message A and then sends message B. The order seems to be not identical.

  • Reported: BPMN 2.0 — Mon, 8 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Restrictions for Relative and Absolute Timers are the same

  • Key: BPMN21-244
  • Legacy Issue Number: 15751
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Chapter/Section 11.6.2. Page 360. It says:

    “For relative timers: All Participants on the right side of the Gateway MUST be involved in the Choreography Activity that immediately precedes the Gateway.”

    “For absolute timers (full time/date): All Participants on the right side of the Gateway MUST be involved in the Choreography Activity that immediately precedes the Gateway.”

    COMMENTS:

    The restrictions for Relative and Absolute Timers are exactly the same.

    SUGGESTIONS:
    If both restrictions are the same, collapse them into one bullet.

    If the restrictions are different, modify them accordingly.

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pages 467-468. Missing Figure

  • Key: BPMN21-251
  • Legacy Issue Number: 15758
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 14.1.2. Page 467. It says:
    “The following figure shows the mapping of a BPMN Sub-Process without an Event Sub-Process:”

    ii) Chapter/Section 14.1.2. Page 468. It says:
    “The following figure shows the mapping of a BPMN Sub-Process with an Event Sub-Process. (Event Sub- Processes could also be added to a top-level Process, in which case their mapping extends correspondingly.)”

    COMMENTS:

    After there is no Figure. The Figure after (ii) seems to be the one that must be located after .

    SUGGESTIONS:

    Verify the correct position of the Figure located after (ii).

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Table 7.2 Element Data Object column "Notation" typo Data ObjecT (Collection)

  • Key: BPMN21-254
  • Legacy Issue Number: 15764
  • Status: open  
  • Source: Vienna University of Economics and Business ( Bernhard Hoisl)
  • Summary:

    Just a typo in Table 7.2 at Element "Data Object" on p. 35 in column "Notation". It is written "Data Objec (Collection)" but should say "Data Object (Collection)". The "t" is missing in the word "object".

  • Reported: BPMN 2.0 — Tue, 19 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Service Tasks can be the source or target of Messages Flows

  • Key: BPMN21-223
  • Legacy Issue Number: 15724
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 9.4.6. Page 135. It says:
    “Conversation Links into Activities that are not Send or Receive Tasks indicate that the Activity will send or receive Messages of the Conversation at some level of nesting.”

    ii) Chapter/Section 10. Page 153. Table 10.1. Row “definitionalCollaborationRef”. It says:
    “The definitional Collaboration specifies the Participants the Process interacts with, and more specifically, which individual service, Send or Receive Task, or Message Event, is connected to which Participant through Message Flows.”

    iii) Chapter/Section 10.2.3. Page 162. It says:
    “The actual Participant whose service is used can be identified by connecting the Service Task to a Participant using a Message Flows within the definitional Collaboration of the Process ­ see Table 10.1.”

    iv) Chapter/Section 10.2.3. Page 163. Figure 10.12.
    According to classes and their associations, ServiceTask is not directly associated to Message, but they are indirectly associated through Operation.

    v) Chapter/Section 11.4.6. Page 348. It says:
    “Usually in these cases, the initiating Participant will use a single Activity to handle both the sending and receiving of the Messages. A BPMN Service Task can be used for this purpose and these types of Tasks are often referred to as “request-response” Tasks for Choreography modelers.”

    vi) Chapter/Section 14.1.2. Page 464. It says:
    “The partner link associated with the WS-BPEL invoke is derived from both the participant Q that the Service Task is connected to by Mesage Flows, and from the interface referenced by the operation of the Service Task.”

    vii) Chapter/Section 14.1.2. Page 466. It says:
    “For those BPMN nodes sending or receiving Messages (i.e., Message Events, Service, send or Receive Tasks)
    that have an associated key-based Correlation Key, …”

    COMMENTS:

    >From (ii) to (vii) it can be deduced that Service Task can be the source and target of Message Flows.

    SUGGESTIONS:
    In it should say:
    “Conversation Links into Activities that are not Send, Receive or Service Tasks indicate that the Activity will send or receive Messages of the Conversation at some level of nesting.”

    Furthermore:
    In (ii) “which individual service, Send or” should be replaced by “which individual Service, Send or”

    In (iii) “Participant using a Message Flows within” should be replaced by “Participant using Message Flows within”

    In (vi) “Task is connected to by Mesage Flows” should be replaced by “Task is connected to by Message Flows”

    In (vii) “Service, send or Receive Tasks” should be replaced by “Service, Send or Receive Tasks”

  • Reported: BPMN 2.0 — Mon, 11 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Messages Flows can be attached to Events

  • Key: BPMN21-222
  • Legacy Issue Number: 15723
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Chapter/Section 9.2. Page 113. It says:
    “Message Flows can cross the Pool boundary to attach to the appropriate Activity”

    COMMENTS:

    Messages Flows can be attached to Message Events (see Table 7.4, p. 44). If a Multiple Event (or Parallel Multiple Event) contains MessageEventDefinitions, it can be the source or the target of one or more Message Flows too.

    SUGGESTION:

    It should say:
    “Message Flows can cross the Pool boundary to attach to the appropriate Activity or Event”

  • Reported: BPMN 2.0 — Mon, 11 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect multiplicity of dataStoreRef

  • Key: BPMN21-221
  • Legacy Issue Number: 15722
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 10.3.1. Page 211. Figure 10.50.
    Role dataObjectRef (from DataObjectReference to DataObject) has multiplicity [1..1].
    Role dataStoreRef (from DataStoreReference to DataStore) has multiplicity [0..1].

    ii) Chapter/Section 10.3.1. Page 212. Figure 10.51.
    Role dataObjectRef (from DataObjectReference to DataObject) has multiplicity [1..1].

    iii) Chapter/Section 10.3.1. Page 213. Table 10.53. Row “dataObjectRef”. It says:
    “dataObjectRef: DataObject”
    It means that dataObjectRef is mandatory (multiplicity [1..1]).

    iv) Chapter/Section 10.3.1. Page 216. Figure 10.55.
    Role dataStoreRef (from DataStoreReference to DataStore) has multiplicity [0..1].

    v) Chapter/Section 10.3.1. Page 217. Table 10.56. Row “dataStoreRef”. It says:
    “dataStoreRef: DataStore”
    It means that dataStoreRef is mandatory (multiplicity [1..1]).

    COMMENTS:

    In and (iv) dataStoreRef is optional ([0..1])., but in (v) it is said that dataStoreRef is mandatory ([1..1]). Clearly there is contradiction concerning the multiplicity of dataStoreRef. Furthermore, a question arises: How can a DataStoreReference exist without a referenced DataStore?

    SUGGESTIONS:

    It seems that dataStoreRef should be mandatory (multiplicity [1..1]), if this is the case:

    In and (iv) change multiplicity of dataStoreRef from [0..1] to [1..1]

    (ii), (iii) and (v) don’t require modifications.

  • Reported: BPMN 2.0 — Mon, 11 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistencies concerning Item-Aware Elements

  • Key: BPMN21-220
  • Legacy Issue Number: 15721
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    ) Chapter/Section 10.3.1. Page 211. It says:
    “The elements in the specification defined as item-aware elements are: Data Objects, Data Object References, Data Stores, Properties, DataInputs and DataOutputs.”

    ii) Chapter/Section 10.3.1. Page 211. Figure 10.50.
    According to classes and their associations item-aware elements are:
    a) Properties
    b) Data Objects
    c) Data Object References
    d) DataInputs
    e) DataOutputs
    f) Data Stores
    g) Data Store References

    iii) Chapter/Section 10.3.1. Page 212. Figure 10.51.
    According to classes and their associations:
    DataObjectReference is subclass of FlowElement
    DataObject is subclass of FlowElement

    iv) Chapter/Section 10.3.1. Page 216. Figure 10.55.
    According to classes and their associations:
    DataStoreReference is subclass of FlowElement
    DataStore is subclass of RootElement

    v) Chapter/Section 10.3.1. Page 216. It says:
    “The DataStore element inherits the attributes and model associations of FlowElement (see Table 8.44) through its relationship to RootElement, and ItemAwareElement (see Table 10.51).”

    COMMENTS:

    In Data Stores Reference is not mentioned, but it is shown as a subclass of ItemAwareElement in (ii).

    In (iv) DataStore is not a subclass of FlowElement, as DataObjectReference, DataObject and DataStoreReference. In the document it is not explained the reason for this exclusion.

    In (v) the sentence is clearly wrong, because it is inconsistent with the class diagrams: RootElement is not subclass of FlowElement.

    SUGGESTIONS:

    In add Data Store References.

    In (iv) remove generalization from DataStore to RootElement, and add generalization from DataStore to FlowElement.

    Replace (v) with “The DataStore element inherits the attributes and model associations of FlowElement (see Table 8.44) and ItemAwareElement (Table 10.51).”

    (ii) and (iii) don’t require modifications.

  • Reported: BPMN 2.0 — Mon, 11 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistencies concerning Flow Elements

  • Key: BPMN21-219
  • Legacy Issue Number: 15720
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 8.3.7. Page 86. It says:
    “FlowElement is the abstract super class for all elements that can appear in a Process flow, which are FlowNodes (see page 99, which consist of Activities (see page 155), Choreography Activities (see page 331) Gateways (see page 295), and Events (see page 240)), Data Objects (see page 212), Data Associations (see page 228), and Sequence Flows (see page 97).”

    In other words, Flow Elements are:
    a) Flow Node
    a.1) Activity
    a.2) Choreography Activity
    a.3) Gateway
    a.4) Event
    b) Data Object
    c) Data Association
    d) Sequence Flow

    ii) Chapter/Section 8.3.7. Page 87. Figure 8.22
    According to classes and their associations Flow Elements are:
    a) Flow Node
    a.1) Activity
    a.2) Choreography Activity
    a.3) Gateway
    a.4) Event
    b) Data Object
    c) DataStoreReference
    d) Sequence Flow

    iii) Chapter/Section 8.3.8. Page 88. It says:
    “Basically, a FlowElementsContainer contains FlowElements, which are Events (see page 240), Gateways (see page 295), Sequence Flows (see page 97), Activities (see page 155), and Choreography Activities (see page 331).”

    In other words, Flow Elements are:
    a) Event
    b) Gateway
    c) Sequence Flow
    d) Activity
    e) Choreography Activity

    iv) Chapter/Section 8.3.8. Page 89. Table 8.45. It says: “Flow elements are Events, Gateways, Sequence Flows, Activities, Data Objects, Data Associations, and Choreography Activities.”

    In other words, Flow Elements are:
    a) Event
    b) Gateway
    c) Sequence Flow
    d) Activity
    e) Data Object
    f) Data Association
    g) Choreography Activity

    v) Chapter/Section 10.3.1. Page 212. Figure 10.51.
    According to classes and their associations:
    DataObjectReference is subclass of FlowElement
    DataObject is subclass of FlowElement

    vi) Chapter/Section 10.3.1. Page 216. Figure 10.55.
    According to classes and their associations:
    DataStoreReference is subclass of FlowElement
    DataStore is subclass of RootElement

    COMMENTS:

    In , (ii), (iii) and (iv) the lists of Flow Elements are different.

    In and (iv) DataAssociation is mentioned as a type of FlowElement, but it is not correct. See Figure 10.64 (p. 229), where it is shown that DataAssociation is direct subclass of BaseElement. Furthermore, DataAssociation in not shown as a subclass of FlowElement in (ii).

    In (ii) Data Association is replaced by DataStoreReference

    In (iii) Data Object, Data Association, and Data Store Reference are not mentioned.

    In (iv) DataObjectReference, DataStore and DataStoreReference are not mentioned.

    In (v) DataObjectReference is subclass of FlowElement, but it is not mentioned in , (ii), (iii) and (iv).

    In (vi) DataStore is not a subclass of FlowElement, as DataObjectReference, DataObject and DataStoreReference. In the document it is not explained the reason for this exclusion.

    SUGGESTIONS:

    It seems that Flow Elements are:

    a) Flow Node
    a.1) Activity
    a.2) Choreography Activity
    a.3) Gateway
    a.4) Event
    b) Data Object
    c) Data Object Reference
    d) Data Store
    e) Data Store Reference
    f) Sequence Flow

    If this is the case, then , (ii), (iii), (iv), and (vi) should be updated accordingly.

    In remove Data Association
    add Data Object Reference, Data Store and Data Store Reference.

    In (ii) add Data Object Reference, and Data Store.

    In (iii) add Data Object, Data Object Reference, Data Store, and Data Store Reference.

    In (iv) remove Data Association
    add Data Object Reference, Data Store and Data Store Reference.

    In (vi) remove generalization from DataStore to RootElement, and add generalization from DataStore to FlowElement.

    (v) doesn’t require modifications

  • Reported: BPMN 2.0 — Mon, 11 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 288. Typos

  • Key: BPMN21-228
  • Legacy Issue Number: 15735
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Description:

    i) It says:
    “Interrupting Event Handlers are those that have the cancelActivity attribute is set to true.”

    It should say:
    “Interrupting Event Handlers are those that have the cancelActivity attribute set to true.”

    “is set to true” should be replaced by “set to true”

    ii) It says:
    “Interrupting Event Handlers are those that have the cancelActivity attribute is set to false.”

    It should say:
    “Non-interrupting Event Handlers are those that have the cancelActivity attribute set to false”

    “Interrupting” should be replaced by “Non-interrupting”

    “is set to false” should be replaced by “set to false”

  • Reported: BPMN 2.0 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

“cancelActivity” is not an attribute of Activity

  • Key: BPMN21-227
  • Legacy Issue Number: 15734
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 10.4. Page 241. Figure 10.69.
    Class BoundaryEvent has attribute cancelActivity
    (See Table 10.91, p. 266)

    ii) Chapter/Section 10.4.4. Page 262. Table 10.90. Rows “Message”, “Timer”, “Escalation”, “Conditional”, “Signal”, “Multiple” and “Parallel Multiple”
    It says:
    “Note that if using this notation, the attribute cancelActivity of the Activity to which the Event is attached is implicitly set to true.”

    or

    “Note that if using this notation, the attribute cancelActivity of the Activity to which the Event is attached is implicitly set to false.”

    iii) Chapter/Section 10.4.4. Page 266. Table 10.92.
    This Table doesn’t contain o row for Parallel Multiple Event.

    iv) Chapter/Section 13.4.3. Page 455. It says:
    “For boundary Events, handling first consists of consuming the Event occurrence. If the cancelActivity attribute is
    set, the Activity the Event is attached to is then cancelled (in case of a multi-instance, all its instances are cancelled); if
    the attribute is not set, the Activity continues execution (only possible for Message, Signal, Timer, and Conditional
    Events, not for Error Events). Execution then follows the Sequence Flow connected to the boundary Event.”

    COMMENTS:

    According to the meta-model cancelActivity is an attribute of BoundaryEvent, but in (ii) it is said that it is an attribute of Activity.

    In (iii) a row is needed for Parallel Multiple.

    In (iv) it is suggested that cancelActivity is optional. This is not the case, cancelActivity is mandatory: it is always set (to true or to false).

    SUGGESTIONS:

    In (ii)
    “the attribute cancelActivity of the Activity” should be replaced by “the attribute cancelActivity of the BoundaryEvent” (14 times)

    In (iii) add an additional row for Parallel Multiple.

    In (iv)
    “If the cancelActivity attribute is set,” should be replaced by “If the cancelActivity attribute is set to true,”

    “if the attribute is not set” should be replaced by “if the attribute is set to false”

  • Reported: BPMN 2.0 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Intermediate Message Event can be source or target of Message Flow

  • Key: BPMN21-226
  • Legacy Issue Number: 15733
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Chapter/Section 10.4.4. Page 259. Table 10.89. Row “Message”. It says:
    “The actual Participant from which the Message is received can be identified by connecting the Event to a Participant using a Message Flow …”

    COMMENTS:

    The description is devoted to both throw and catch Intermediate Message Events, but it is only described the Participant associated with the catch Event.

    SUGGESTION:

    It should say:
    “The actual Participant from which the Message is received or to which the Message is sent can be identified by connecting the Event to a Participant using a Message Flow …”

  • Reported: BPMN 2.0 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Participant multi-instance instead of Sub-Choreography multi-instance

  • Key: BPMN21-225
  • Legacy Issue Number: 15732
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 11.4.1. Page 337.It says:
    “The marker for a Choreography Task that is multi-instance MUST be a set of three vertical lines”

    ii) Chapter/Section 11.4.2. Page 342.It says:
    “The marker for a Sub-Choreography that is multi-instance MUST be a set of three vertical lines.”

    COMMENTS:

    describes the use of a multi-instance marker in the Participant Band for a multi-instance Participant (see Figure 11.15, p. 337). Multi-instance marker for the Choreography Task is described on page 336.

    (ii) describes the use of a multi-instance marker in the Participant Band for a multi-instance Participant (see Figure 11.23, p. 342). Multi-instance marker for the Sub-Choreography is described on page 341.

    SUGGESTION:

    In it should say:
    “The marker for a Participant (of a Choreography Task) that is multi-instance MUST be a set of three vertical lines.”

    In (ii) it should say:
    “The marker for a Participant (of a Sub-Choreography) that is multi-instance MUST be a set of three vertical lines.”

  • Reported: BPMN 2.0 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 345. Sub-Choreographies instead of Choreography Activities

  • Key: BPMN21-218
  • Legacy Issue Number: 15719
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “Both Sub-Choreographies can have standard loops and multi-instances. Examples of Choreography Activities with the appropriate markers can be seen in Figure 11.12 and Figure 11.22.”

    The purpose of this paragraph is to explain that both Choreography Task and Sub-Choreography can have loop markers. Figure 11.12 shows Choreography Task Markers, and Figure 11.22 shows Sub-Choreography Markers

    Then, it should say:
    “Both Choreography Activities can have standard loops and multi-instances. Examples of Choreography Activities with the appropriate markers can be seen in Figure 11.12 and Figure 11.22.”

    “Sub-Choreographies” should be replaced by “Choreography Activities”

  • Reported: BPMN 2.0 — Mon, 11 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 224. Typos

  • Key: BPMN21-217
  • Legacy Issue Number: 15718
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    a) Sub-section Send Task Mapping

    It says:
    “…there MUST be at most inputSet set and at most one Data Input on the Send Task.”

    It should say:
    “…there MUST be at most one inputSet set and at most one Data Input on the Send Task.”

    “at most inputSet” should be replaced by “at most one inputSet”

    b) Sub-section Recieve Task Mapping
    It says:
    “…there MUST be at most outputSet set and at most one Data Output on the Receive Task.”

    It should say:
    “…there MUST be at most one outputSet set and at most one Data Output on the Receive Task.”

    “at most outputSet” should be replaced by “at most one outputSet”

  • Reported: BPMN 2.0 — Mon, 11 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multiple Instances Description: Sequential instead of parallel, Typos

  • Key: BPMN21-214
  • Legacy Issue Number: 15667
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    I found a minor mistake on page 39 concerning multiple instances. The text describes 3 vertical and 3 horizontal lines and declares that both define sequential Multi-Instances. I think that 3 vertical lines should be parallel Multi-Instance (also displayed in the figures).

    In addition, there are three typos in this text: horizontal liness -> lines, vertical liness -> lines, sequentail -> sequential

    In addition, I think that at the following two positions, the numbers are not correct:
    Page 34: See next seven figures. Only five figures concerning Sequence Flow are listed.
    Page 35: See next five rows. Only four following lines contain corresponding figures.

  • Reported: BPMN 2.0 — Thu, 30 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Text mentiones keyword "MUST NOT" 2 times

  • Key: BPMN21-213
  • Legacy Issue Number: 15666
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    In the following text, MUST NOT is listed 2 times:

    The keywords “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “MUST NOT,” “SHOULD,” “SHOULD NOT,”
    “RECOMMENDED,” “MAY,” and “OPTIONAL” in this document are to be interpreted as described in RFC-2119.

  • Reported: BPMN 2.0 — Thu, 30 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 10.30 doesn't correspond with Text: Start Event as Marker

  • Key: BPMN21-216
  • Legacy Issue Number: 15682
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to page 182, a collapsed Event Sub-Process will show the start event as a marker: If the Event Sub-Process is collapsed, then its Start Event will be used as a marker in the upper left corner of
    the shape (see Figure 10.30).

    However, Figure 10.30 doesn't show the mentioned marker and, so, doesn't correspond with the text.

  • Reported: BPMN 2.0 — Mon, 4 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Text references DataObject Element although DataState is meant

  • Key: BPMN21-215
  • Legacy Issue Number: 15679
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    The following line is taken from page 213:

    The DataState element inherits the attributes and model associations of BaseElement (see Table 8.5). Table 10.54
    presents the additional attributes and model associations of the DataObject element:

    I think that "DataState" is meant instead of "DataObject".

  • Reported: BPMN 2.0 — Mon, 4 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Examples - DI - Lanes and Nested Lanes.bpmn example is not according to the specifications

  • Key: BPMN21-224
  • Legacy Issue Number: 15725
  • Status: open  
  • Source: USoft B.V. ( Cristina Constantin)
  • Summary:

    Examples - DI - Lanes and Nested Lanes.bpmn example is not according to the specifications.
    In xml:
    <bpmn:lane name="Lane 2 - 2" id="Lane_Lane2_2">
    <bpmn:flowNodeRef>Task_UserTask</bpmn:flowNodeRef>
    <bpmn:flowNodeRef>DataObject_Document</bpmn:flowNodeRef>
    </bpmn:lane>

    DataObject_Document is a dataObjectReference (and that derives directly from flowElement) and not a flowNode. The documentation clearly states that flowNodeRef should be a reference to a flowNode and not to a flowElement (this has even changed from beta1 to beta2).

  • Reported: BPMN 2.0 — Tue, 12 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 338. Wrong name, multiplicity and description of “messageFlowRefs”

  • Key: BPMN21-169
  • Legacy Issue Number: 15549
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    a)
    Table 11.2. Row “messageFlowRef”.

    It says:
    “messageFlowRef: Message Flow [1..*]

    It should say:
    “messageFlowRefs: Message Flow [1..2]

    See Figures 11.1 (p.326) and 11.6 (p.332), where the multiplicity [1..2] is clear.
    ----------------------------------------------------------------------------

    b)
    In Figures 11.1 (p.326) and 11.6 (p.332) the role name is “messageFlowRef”, but it should be “messageFlowRefs”, because there can be more than one links.
    --------------------------------------------------------------------------------------

    c)
    In Table 11.2. Row “messageFlowRef”, it says “Although not graphical represented, Choreography Task contain one (1) or more Message Flows that represent the interaction(s) between the Participants referenced by the Choreography Task.”

    But, on page 333, it says:
    “A Choreography Task is an atomic Activity in a Choreography Process. It represents an Interaction, which is one (1) or two (2) Message exchanges between two (2) Participants.” Furthermore, the multiplicity is [1..2].

    Then, in Table 11.2. Row “messageFlowRefs”, it should say:
    “Although not graphical represented, Choreography Task contain one (1) or two (2) Message Flows that represent the interaction(s) between the Participants referenced by the Choreography Task.”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 317. Ambiguous associations “partitionElement” and “partitionElementRef”

  • Key: BPMN21-168
  • Legacy Issue Number: 15548
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 10.135.

    a)
    Model associations “partitionElement” and “partitionElementRef” have the same description:
    “A reference to a BaseElement which specifies the partition value and partition type. Using this partition element a BPMN compliant tool can determine the FlowElements which have to be partitioned in this Lane.”

    So, which is the difference between them?
    --------------------------------------------------------------------------

    b)
    Model association “flowNodeRefs” is described as “the list of FlowNodes partitioned into this Lane according to the partitionElement defined as part of the Lane element.”

    “partitionElement” is optional. What happen if “partitionElement” is not defined?

    Does “flowNodeRefs” depend of “partitionElementRef” also?

    Can both “partitionElement” and “partitionElementRef” be defined at the same time?

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 77. Incomplete sentence

  • Key: BPMN21-182
  • Legacy Issue Number: 15579
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    In Sub-Section Key-based Correlation.

    It says
    “The idea is to use a joint Conversation “token” which is used (passed to and received from) and outgoing and incoming Message.”

    The sentence is incomplete.
    Furthermore, the word “incoming” is underlined, but it is not clear the purpose of doing this.

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 440. Incorrect name of Parallel Event-Based Gateway 2

  • Key: BPMN21-177
  • Legacy Issue Number: 15557
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “If the instance was created through an instantiating Parallel Gateway, then all subsequent Events (of that Gateway) MUST have occurred.”

    Normal Parallel Gateways cannot be instantiating elements.

    Then, it should say:
    “If the instance was created through an instantiating Parallel Event-Based Gateway, then all subsequent Events (of that Gateway) MUST have occurred.”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 370. Wrong Parallel Gateway in Figure 11.47

  • Key: BPMN21-176
  • Legacy Issue Number: 15556
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Figure 11.47.

    Participant B: The Parallel Gateway has a “decision”, and its outgoing Sequence Flows have “conditions”.

    It is a mistake. “A Parallel Gateway creates parallel paths without checking any conditions; each outgoing Sequence Flow receives a token upon execution of this Gateway.” (p. 302).

    Then, words “Decision?”, “Yes” and “No” should be removed.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 342. Wrong reference to Table 11.3

  • Key: BPMN21-172
  • Legacy Issue Number: 15552
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “Table 11.3 presents the additional model associations of the GlobalChoreographyTask element:”

    But in Table 11.3 Sub-Choreography element is described.

    Then, it should say:
    “Table 11.3 presents the additional model associations of the Sub-Choreography element:”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 341. Choreography Activity instead of Task

  • Key: BPMN21-171
  • Legacy Issue Number: 15551
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “The three (3) or more partitions in the Sub-Choreography shape provide the distinction between this type of Task and an Orchestration Sub-Process (in a traditional BPMN diagram).”

    A Sub-Choreography is not a “type of Task”, but it is a “type of Choreography Activity”.

    Then, it should say:
    “The three (3) or more partitions in the Sub-Choreography shape provide the distinction between this type of Choreography Activity and an Orchestration Sub-Process (in a traditional BPMN diagram).”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 441. “Task” instead of “Activity”

  • Key: BPMN21-178
  • Legacy Issue Number: 15558
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “Uncontrolled flow means that, for each token arriving on any incoming Sequence Flows into the Activity, the Task will be enabled independently of the arrival of tokens on other incoming Sequence Flows. The presence of multiple incoming Sequence Flows behaves as an exclusive gateway. If the flow of tokens into the Task needs to be ‘controlled,’ then Gateways (other than Exclusive) should be explicitly included in the Process flow prior to the Task to fully eliminate semantic ambiguities.”

    The description is intended for “Activities” in general, not for “Tasks” in particular.

    Then, it should say:
    “Uncontrolled flow means that, for each token arriving on any incoming Sequence Flows into the Activity, the Activity will be enabled independently of the arrival of tokens on other incoming Sequence Flows. The presence of multiple incoming Sequence Flows behaves as an exclusive gateway. If the flow of tokens into the Activity needs to be ‘controlled,’ then Gateways (other than Exclusive) should be explicitly included in the Process flow prior to the Activity to fully eliminate semantic ambiguities.”

    Three times “Task” should be replaced by “Activity”.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 57. Associations are incorrectly drawn Figure 8.6

  • Key: BPMN21-180
  • Legacy Issue Number: 15577
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Figure 8.6.

    Generalization from “Documentation” to “BaseElement” is on top of aggregation from “BaseElement” to “Documentation”.

    Both relationships should be drawn separately. See Figure 8.5 (p.55), where they are correctly drawn.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 452. Incorrect name of Parallel Event-Based Gateway 3

  • Key: BPMN21-179
  • Legacy Issue Number: 15559
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “When used at the Process start as a Parallel Event Gateway, only message-based triggers are allowed.”

    It should say:
    “When used at the Process start as a Parallel Event-Based Gateway, only message-based triggers are allowed.”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pages 366-368. Wrong direction of Message Flow

  • Key: BPMN21-175
  • Legacy Issue Number: 15555
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    a) Figure 11.43 (p.366)

    Direction of M1 is wrong. It should be from Task in Participant B to Task in Participant A.
    ----------------------------------------------------------------------

    b) Figure 11.45 (p.368)
    Direction of M1 is wrong. It should be from Task in Participant B to Task in Participant A.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 359. Missing markers in Send and Receive Tasks

  • Key: BPMN21-174
  • Legacy Issue Number: 15554
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Figure 11.37.

    Participant A:
    Two (of three) Send Tasks without message markers.

    Participant B:
    One (of two) Receive Task without message marker.
    One (of two) Receive Task without incoming Message Flow.

    Participant C:
    Receive Task without message marker.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 341. Choreography instead of Sub-Choreography

  • Key: BPMN21-170
  • Legacy Issue Number: 15550
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “The Choreography Activity shares the same shape as a Sub-Process or any other BPMN Activity, which is in this state.”

    This sentence is within section 11.4.2, where Sub-Choreographies are described.

    Then, it should say:
    “The Sub-Choreography shares the same shape as a Sub-Process or any other BPMN Activity, which is in this state.”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 345. Wrong type of "calledChoreographyRef"

  • Key: BPMN21-173
  • Legacy Issue Number: 15553
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 11.4.

    It says:
    “calledChoreographyRef: CallableElement [0..1]

    The model association is form “CallChoreography” to “Choreography”. See Figure 11.27, p. 344.

    Then, it should say:
    “calledChoreographyRef: Choreography [0..1]

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 117. Wrong name of model association “interfaceRefs”.

  • Key: BPMN21-147
  • Legacy Issue Number: 15519
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 9.2. Row “interfaceRef”.

    The model association name should be “interfaceRefs”, because of its multiplicity ([0..*]), and because this is its name in Figure 9.7 (p.116).

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 115. Confusion over subtypes of Collaboration 1.

  • Key: BPMN21-146
  • Legacy Issue Number: 15518
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “When Participants are defined they are contained within a Collaboration, which includes the sub-types of Choreography, GlobalConversation, or GlobalChoreographyTask.”

    This is not consistent with what is shown in Figure 9.1 (p.109): GlobalConversation and Choreography are sub-types of Collaboration; and GlobalChoreographyTask is sub-type of Choreography.

    Maybe it should say
    “When Participants are defined they are contained within a Collaboration, which includes the sub-types GlobalConversation, Choreography and GlobalChoreographyTask.”

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 111. Association “participants” not shown in Figure 9.1

  • Key: BPMN21-145
  • Legacy Issue Number: 15517
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 9.1. Row “participants”. And Figure 9.1 (p.109).

    Model association “participants” (from “Collaboration” to “Participant”) is not shown in Figure 9.1 (p.109).

    Model association “participants” should be shown in Figure 9.1 because it is the location where all class “Collaboration” relationships must be displayed.

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 117 & 118. Confusion over subtypes of Collaboration 2

  • Key: BPMN21-149
  • Legacy Issue Number: 15521
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 9.3 (p.117). Row “participantRef”.

    It says
    “Specifies how the PartnerEntity participates in Collaborations and Choreographies.”

    It should say
    “Specifies how the PartnerEntity participates in Collaborations.”
    ----------------------------------------------------

    Table 9.4 (p.118). Row “participantRef”.

    It says
    “Specifies how the PartnerRole participates in Collaborations and Choreographies.”

    It should say
    “Specifies how the PartnerRole participates in Collaborations.”
    --------------------------------------------------

    In Beta 2 GlobalConversation and Choreography are sub-types of Collaboration; and GlobalChoreographyTask is sub-type of Choreography.
    Then “Collaborations and Choreographies” is incomplete and ambiguous.

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 117 & 118. Wrong name of association “participantRefs

  • Key: BPMN21-148
  • Legacy Issue Number: 15520
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 9.3 (p.117). Row “participantRef”.

    The model association name should be “participantRefs”, because of its multiplicity ([0..*]). Its name should be modified in Figure 9.7 (p.116) too.
    --------------------------------------

    Table 9.4 (p.118). Row “participantRef”.

    The model association name should be “participantRefs”, because of its multiplicity ([0..*]). Its name should be modified in Figure 9.7 (p.116) too.

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 185. Nonexistent attribute shown in Figure 10.29

  • Key: BPMN21-153
  • Legacy Issue Number: 15533
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 10.21 and Figure 10.29 (p. 181)

    Attribute “protocol” was removed from class Transaction in Table 10.21 (p.185), but it remains in Figure 10.29 (p.181).

    Attribute “protocol” of class Transaction should be removed from Figure 10.29.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 182. Missing Start event triggers for Event Sub-Process

  • Key: BPMN21-152
  • Legacy Issue Number: 15532
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “The Start Event trigger (EventDefinition) MUST be from the following types: Message, Error, Escalation, Compensation, Conditional, Signal, and Multiple (see page 268 for more details).”

    Problem: “Timer” and “Parallel Multiple” are not mentioned, but they are valid Start Event triggers for Event Sub-Process (see Table 10.93, pp. 269 & 270). Then, it should say:

    “The Start Event trigger (EventDefinition) MUST be from the following types: Message, Timer, Error, Escalation, Compensation, Conditional, Signal, Multiple and Parallel Multiple (see page 268 for more details).”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 99. Wrong inheritance of FlowNode

  • Key: BPMN21-141
  • Legacy Issue Number: 15513
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “Since Gateway, Activity, Choreography Activity, and Event have their own attributes, model associations, and inheritances; the FlowNode element does not inherit from any other BPMN element. Table 8.52 presents the additional model associations of the FlowNode element:”

    It should say
    “The FlowNode element inherits the attributes and model associations of FlowElement (see Table 8.44). Table 8.52 presents the additional model associations of the FlowNode element:”

    FlowNode is subclass of FlowElement. (See Figure 8.35, p. 98; and Figure 8.22, p.87.)

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 97. Wrong multiplicity of association in Table 8.50

  • Key: BPMN21-140
  • Legacy Issue Number: 15512
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 8.50. Row “type”

    It says
    “type: ItemDefinition”

    It should say
    “type: ItemDefinition [0..1]

    In Figure 8.31 (p. 96) model association “type” (from ResourceParameter to ItemDefinition) is optional ([0..1])

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 96. ResourceParameter is not subclass of RootElement

  • Key: BPMN21-139
  • Legacy Issue Number: 15511
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “The ResourceParameter element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to RootElement.”

    It should say
    “The ResourceParameter element inherits the attributes and model associations of BaseElement (see Table 8.5).”

    ResourceParameter it is not subclass of RootElement. It is direct subclass of BaseElement. (See Figure 8.31, p.96.)

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 84. Event is not direct subclass of FlowElement

  • Key: BPMN21-138
  • Legacy Issue Number: 15510
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    says
    “The Event element inherits the attributes and model associations of FlowElement (see Table 8.44), but adds no additional attributes or model associations:”

    It should say
    “The Event element inherits the attributes and model associations of FlowElement (see Table 8.44), through its relationship to FlowNode, but adds no additional attributes or model associations.”

    Event is direct subclass of FlowNode, which is direct subclass of FlowElement. (See Figure 8.20, p. 84.)

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 109. Wrong multiplicity in Figure 9.1

  • Key: BPMN21-143
  • Legacy Issue Number: 15515
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Figure 9.1 and Table 9.1 (p.110).

    In Figure 9.1 multiplicity of “conversationAssociations” (from “Collaboration” to “ConversationAssociation”) is [1..1], but it should be [0..*], as it is shown in Table 9.1 (p.110).

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 104. Navigation (arrowhead) is needed if Figure 8.36

  • Key: BPMN21-142
  • Legacy Issue Number: 15514
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Figure 8.36 and Table 8.65 (p.105)

    A navigation (arrowhead) is needed from “Interface” to “CallableElement” in Figure 8.36 in order to be consistent with the model association “callableElement” in Table 8.65 (p.105).

    The inclusion of “callableElements” in Table 8.65 means that “Interface knows about CallableElement”, which (in UML) is graphically represented with an arrowhead from “Interface” to “CallableElement”.

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 139. Ambiguous multiplicities of associations

  • Key: BPMN21-150
  • Legacy Issue Number: 15522
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 9.14. Row “innerConversationNodeRef”.

    In table 9.14 the multiplicity of model association “innerConversationNodeRef” is [0..1], but in Figure 9.31 (p. 139) its multiplicity is [1..1].
    Its description in Table 9.14 (“This attribute defines the ConversationNodes of the referenced element...”) suggests that its multiplicity should be [0..*].

    The multiplicity of “innerConversationNodeRef” should be clearly defined ([0..1], or [1..1], or [0..*]). In case of [0..*] the model association name should be changed to “innerConversationNodeRefs”
    ---------------------------------------------

    Table 9.14. Row “outerConversationNodeRef”.

    In table 9.14 the multiplicity of model association “outerConversationNodeRef” is [0..*], but in Figure 9.31 (p. 139) its multiplicity is [1..1].
    Its description in Table 9.14 (“This attribute defines the ConversationNodes of the parent element...”) suggests that its multiplicity should be [0..*].

    The multiplicity of “outerConversationNodeRef” should be clearly defined ([1..1], or [0..*]). In case of [0..*] the model association name should be changed to “outerConversationNodeRefs”

    Table 9.14 and Figure 9.31 should be updated accordingly.

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 110. Wrong use of UML concept “aggregation”.

  • Key: BPMN21-144
  • Legacy Issue Number: 15516
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    In Table 9.1. Row “conversations”.

    It says
    “The conversations model aggregation relationship allows a Collaboration to contain …”

    It should say
    “The conversations model composition relationship allows a Collaboration to contain …”

    In Figure 9.1 (p. 109), the line “begins” with a filled mini-diamond, which represents a composition, not an aggregation.

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 151. Wrong role name and multiplicity of association “artifacts”

  • Key: BPMN21-151
  • Legacy Issue Number: 15531
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Figure 10.3.

    Name and multiplicity of role from “Process” to “Artifact” are:
    “artifact” and “0..1”

    but they should be:
    “artifacts” and “*” .

    See Table 10.1 (p. 152), row “artifacts”.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unclear and incorrect specification of Expressions and Formal Expressions

  • Key: BPMN21-99
  • Legacy Issue Number: 15422
  • Status: open  
  • Source: USoft ( Rene de Bruin)
  • Summary:

    The use of expression and formalexpression is unclear. The description of 'Expression' states: 'The Expression class is used to specify an Expression using natural-language text. These Expressions are not executable and are considered underspecified '. However, table 8.1 states about 'expressionLanguage': 'This attribute identifies the formal Expression language used in Expressions within the elements of this Definition'. I guess this should be ' This attribute identifies the formal Expression language used in Formal Expressions'.
    Then there are several places where an 'expression' can be entered and not a 'formal expression'. For example table 10.64: assignment attributes. The 'from' and 'to' both are an 'Expression'. Just above the table it says: "The default Expression language for all Expressions is specified in the Definitions element, using the expressionLanguage attribute. It can also be overridden on each individual Assignment using the same attribute". Since the 'from' and 'to' fields are 'Expressions' and not 'Formal Expressions', it is not possible to specify the expressionLanguage. The expression class cleary states it used to specify using "natural-language".
    There are more places where a FormalExpression might be a better choice. Like the conditionExpression of a sequence flow. Since it is an 'Expression' it can only containt the condition in natural language. Venders will need to add vendor specific extension elements to contain the formal expression.
    FormalExpressions are a subclass of Expressions. Maybe it is the intention that FormalExpressions can be used whereever expressions can be used. However, the xsd clearly forbids this (as noticed already by Mr Denis Gagne in issue 14433)
    Finally, the description of 'Expression' states: "The natural language text is captured using the documentation attribute, inherited from BaseElement". In example xml in the document, like in Table 10.19, expressions are just put in the body of the expression:
    <sequenceFlow sourceRef="OrderApprovedDecision" targetRef="OrderAndShipment">
    <conditionExpression>Was the Order Approved?</conditionExpression>
    /sequenceFlow>
    Is this then correct? The description of the Expression class states it should be in the document attribute (which is by the way also not correct since the xsd states 'document' is not an attribute but an element).

  • Reported: BPMN 2.0 — Thu, 19 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Cardinality of sources for Data Association

  • Key: BPMN21-98
  • Legacy Issue Number: 15415
  • Status: open  
  • Source: wu.ac.at ( abaumgra@wu.ac.at)
  • Summary:

    Throughout the text it is stated that a data association has one or more sources and one target (see page 228). First of all, if that is true the meta-model should be adjusted on page 229, figure 10.64. Taking "" as cardinality for sources of a data association would allow a data association to exist without any source. I suggest to change the cardinality to "1..".

    Second, in the description I couldn't find any example explaining for which cases more than one source in a data association makes sense. Is it allowed because a data object can be collection?

  • Reported: BPMN 2.0 — Fri, 13 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

How many source are allowed for data association?

  • Key: BPMN21-97
  • Legacy Issue Number: 15414
  • Status: open  
  • Source: wu.ac.at ( abaumgra@wu.ac.at)
  • Summary:

    In the text on page 228 it says "Data association elements have one or more sources and a target", but in the meta-model in figure 10.64 the association is marked as "*" meaning it is also possible to have 0 sources. As well as in table 10.63: "sourceRef:ItemAwareElement [0..*]".

    It is not clear how many sources of a data association are allowed now.

  • Reported: BPMN 2.0 — Thu, 12 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page153 Wrong reference to section 8.3.2

  • Key: BPMN21-107
  • Legacy Issue Number: 15446
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 10.1. Row “correlationSubscriptions”.

    It says
    “correlationSubscriptions are a feature of context-based correlation (cf. section 8.3.3).”

    It should say
    “correlationSubscriptions are a feature of context-based correlation (cf. section 8.3.2).”

    “section 8.3.3” should be replaced by “section 8.3.2”

  • Reported: BPMN 2.0 — Mon, 6 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 96. Wrong reference to table 8.50

  • Key: BPMN21-106
  • Legacy Issue Number: 15445
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “Table 8.51 presents the additional model associations for the ResourceParameter element:”

    It should say
    “Table 8.50 presents the additional attributes and model associations for the ResourceParameter element:”

    “model associations” should be replaced by “attributes and model associations”
    “Table 8.51” should be replaced by “Table 8.50”

  • Reported: BPMN 2.0 — Mon, 6 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Typo: "Interrupting" should be "Non-Interrupting"

  • Key: BPMN21-96
  • Legacy Issue Number: 15408
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The first sentence of the subsection "Non-interrupting Event Handlers (Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)" starts out: "Interrupting Event Handlers are those..."
    The text should be: "Non-Interrupting Event Handlers are those..."

  • Reported: BPMN 2.0 — Fri, 6 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 10.98 needs Updating

  • Key: BPMN21-95
  • Legacy Issue Number: 15407
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Figure 10.98 shows an Event Gateway that initiates a process, but the Gateway marker is incorrect. The marker needs to be updated to that of a multiple Start Event rather than a multiple Intermediate Event.

  • Reported: BPMN 2.0 — Fri, 6 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 29 Wrong reference to page 240

  • Key: BPMN21-104
  • Legacy Issue Number: 15443
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 7.1. Row “Event”

    It says
    “An Event is something that “happens” during the course of a Process (see page 245)”

    It should say
    “An Event is something that “happens” during the course of a Process (see page 240)”

  • Reported: BPMN 2.0 — Sat, 4 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Definition of Signal Missing

  • Key: BPMN21-103
  • Legacy Issue Number: 15441
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The Section on Common Elements (8.3) should have a subsection that defines Signal, the way that Message, Escalation, and Error are defined.

  • Reported: BPMN 2.0 — Wed, 1 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 96 Wrong reference to table 8.49

  • Key: BPMN21-105
  • Legacy Issue Number: 15444
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “Table 8.51 presents the additional model associations for the Resource element:”

    It should say
    “Table 8.49 presents the additional attributes and model associations for the Resource element:”

    “model associations” should be replaced by “attributes and model associations”
    “Table 8.51” should be replaced by “Table 8.49”

  • Reported: BPMN 2.0 — Mon, 6 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Definition of Association is to strict

  • Key: BPMN21-101
  • Legacy Issue Number: 15428
  • Status: open  
  • Source: USoft ( Rene de Bruin)
  • Summary:

    Page 68 states:
    An Association is used to connect user-defined text (an Annotation) with a Flow Object (see Figure 8.12).
    This is to strict: an association can also be used to associate a compenstaion boundary event with a compenation activity.

  • Reported: BPMN 2.0 — Thu, 26 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Contradictory mandatoryness of category for category values

  • Key: BPMN21-100
  • Legacy Issue Number: 15423
  • Status: open  
  • Source: USoft ( Rene de Bruin)
  • Summary:

    The group class diagram (figure 8.15) states that a category values must reference exactly one category.
    The category values attributes table (table 8.23) however states that the category is not mandatory.

  • Reported: BPMN 2.0 — Fri, 20 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong metaclass name in attribute description

  • Key: BPMN21-102
  • Legacy Issue Number: 15431
  • Status: open  
  • Source: INRIA ( Juan Cadavid)
  • Summary:

    In table 10.58, description of the attribute outputSets mentions "...Every Data Interface must define..." when it should say "...Every InputOutputSpecification must define..."

  • Reported: BPMN 2.0 — Thu, 26 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multiple uncontrolled incoming Sequence Flows

  • Key: BPMN21-268
  • Legacy Issue Number: 15839
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to Section 13.2.1:
    The presence of multiple incoming Sequence Flows behaves as an exclusive gateway.

    However, I think this is only the case for alternative paths (only one token). Otherwise, several instances are created. See the specification from other sections:

    An Activity MAY be a target for Sequence Flows; it can have multiple incoming Sequence Flows. Incoming Sequence Flows MAY be from an alternative path and/or parallel paths.

    If the Activity has multiple incoming Sequence Flows, then this is considered uncontrolled flow. This means that when a token arrives from one of the Paths, the Activity will be instantiated. It will not wait for the arrival of tokens from the other paths. If another token arrives from the same path or another path, then a separate instance of the Activity will be created.

    If all the incoming flow is alternative, then a Gateway is not needed.

    I think that only multiple alternative incoming flows correspond to an exclusive gateway. I, therefore, suggest the following adaptation:

    The presence of multiple "alternative" incoming Sequence Flows behaves as an exclusive gateway.

    or

    The presence of multiple incoming Sequence Flows may instantiate an Activity several times.

  • Reported: BPMN 2.0 — Mon, 22 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Element Repository

  • Key: BPMN21-267
  • Legacy Issue Number: 15819
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    On page 329 it is stated that: As mentioned above, neither Data Objects nor Repositories are used in Choreographies. Both of these elements are used exclusively in Processes and require the concept of a central locus of control.

    Repository is refered to as being an element that can be used in Processes and it is also highlighted like other elements. However, an element with the name Repository is nowhere else mentioned.

  • Reported: BPMN 2.0 — Fri, 12 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Attributes of GlobalScriptTask

  • Key: BPMN21-266
  • Legacy Issue Number: 15818
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    There is no table with attributes and associations of GlobalScriptTask available.

    Basically the attributes should be similar to ScriptTask which has according to Table 10.12 on page 170 two attributes (scriptFormat: string [0..1], script: string [0..1]).

    According to the Global Task class diagram, however, GlobalScriptTask has script: string and striptLanguage: String. The XML schema on page 205 also mentions script [0..1] and scriptLanguage [1].

    The differences are therefore the attributes scriptFormat vs. scriptLanguage as well as their cardinality.

  • Reported: BPMN 2.0 — Fri, 12 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Connection Rules for Message Flow

  • Key: BPMN21-265
  • Legacy Issue Number: 15817
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to Table 7.4 on page 44, Message Flows can only connect to events of type message. According to page 257: The Result attribute of the End Event MUST be set to Message or Multiple if there are any outgoing Message Flows.

    Are events with Multiple Trigger allowed to have outgoing Message Flows? If yes, this should also be specified in Table 7.4.
    Is it further also possible to have a Start Event with Multiple Trigger having multiple incoming Message Flows?

    In addition, Table 7.4 is missing several arrows, e.g. first row (connecting from a Start Event) and last column (connecting to an End Event). Furthermore, the first column might also be possible (connections from a pool to another StartEvent).

  • Reported: BPMN 2.0 — Fri, 12 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Relationship type of CorrelationProperty

  • Key: BPMN21-272
  • Legacy Issue Number: 15893
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the Correlation Class Diagram (Figure 8.17) on page 76, CorrelationProperty has a relationship type with cardinality 0..1 to ItemDefinition.

    However, in Table 8.32 (CorrelationProperty model associations) on page 78, the relationship type has the datatype string.

    Suggestion: Correction of Table 8.32, change type from string to ItemDefinition

  • Reported: BPMN 2.0 — Mon, 13 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Attribute Description of Class Signal missing

  • Key: BPMN21-271
  • Legacy Issue Number: 15892
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    On page 281 Signal Events are described. The Class Diagram of SignalEventDefinition (Fig. 10.93) refers to a class called Signal with an attribute name and a relationship to ItemDefinition with the name structureRef. However, the attributes and model associations of this class are nowhere described in detail.

    Remark: attributes and model associations are also missing for some Global Tasks (GlobalBusinessRuleTask, GlobalScriptTask and GlobalUserTask), however, in this case similar attribute descriptions are available for the classes BusinessRuleTask, ScriptTask and UserTask and might be taken (only problem is the difference described in Issue 15818).

  • Reported: BPMN 2.0 — Mon, 13 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CompensateEventDefinition vs. CompensationEventDefinition

  • Key: BPMN21-260
  • Legacy Issue Number: 15811
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    The same element is sometimes called CompensateEventDefinition and sometimes CompensationEventDefinition.

    CompensateEventDefinition used:

    • Within the Class Diagram Figure 10.76
    • Table 10.106 ­ CompensateEventDefinition XML schema

    CompensationEventDefinition used:

    • in the labeling text of Figure 10.76
    • In the following text and description of the attributes and model associations.

    I would recommend to use CompensationEventDefinition.

  • Reported: BPMN 2.0 — Wed, 10 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Attributes and Model Associations of EndEvent

  • Key: BPMN21-259
  • Legacy Issue Number: 15810
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    Every specified Element has a sentence of the type "The RootElement element inherits the attributes and model associations of BaseElement (see Table 8.5), but does
    not have any further attributes or model associations." or the type "The Association element inherits the attributes and model associations of BaseElement (see Table 8.5). Table 8.20 presents the additional attributes and model associations for an Association" except EndEvent.

    It seems that EndEvent has no attributes, so the sentence "The EndEvent element inherits the attributes and model associations of ThrowEvent (see Table ..), but does
    not have any further attributes or model associations." could be inserted.

  • Reported: BPMN 2.0 — Wed, 10 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Model Associations of class Event

  • Key: BPMN21-273
  • Legacy Issue Number: 15894
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to page 84:
    The Event element inherits the attributes and model associations of FlowElement (see Table 8.44), but adds no additional attributes or model associations.

    However, according to the class diagram in Figure 8.20, Event has one model association to Property with the name 'properties' and the cardinality [0..n].

  • Reported: BPMN 2.0 — Mon, 13 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Attributes of StandardLoopCharacteristics

  • Key: BPMN21-264
  • Legacy Issue Number: 15816
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the LoopCharacteristics class diagram (Figure 10.45, page 196) StandardLoopCharacteristics only has one attribut (testBefore). However, Table 10.28 on page 198 shows two further attributes (loopMaximum and loopCondition).

  • Reported: BPMN 2.0 — Fri, 12 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Attributes of Transaction Element

  • Key: BPMN21-263
  • Legacy Issue Number: 15815
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the class diagram of Sub-Process (Figure 10.29, page 181), Transaction has two attributes (protocol and transaction). However, in Table 10.21 on page 185 only method is mentioned (transaction missing).

    In addition, the class diagram specifies that the data type of method is string. Table 10.21, however, defines that the data type is of TransactionMethod.

    Since an element TransactionMethod is not defined in any metamodel, I would suggest to use data type string. In addition, protocol could be inserted in Table 10.21 with a cardinality of [0..1] or [1].

  • Reported: BPMN 2.0 — Fri, 12 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Attributes of Element Resource Role

  • Key: BPMN21-270
  • Legacy Issue Number: 15891
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the class diagram of Resources on page 158, ResourceRole has an attribute "name" of type string.

    However, in Table 10.5 - Resource Role model associations on page 159, only three relationships are mentioned but no attribute "name".

  • Reported: BPMN 2.0 — Fri, 10 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Converging Gateway has multiple outgoing connections

  • Key: BPMN21-269
  • Legacy Issue Number: 15883
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the footnotes on page 7:
    a.Multiple outgoing connections are only allowed for converging Gateways.
    b.Multiple outgoing connections are only allowed for diverging Gateways.

    Footnote a should be correted to "multiple incoming connections". The right definition is also specified on page 298:

    A Gateway with a gatewayDirection of converging MUST have multiple incoming Sequence Flows, but MUST NOT have multiple outgoing Sequence Flows.

  • Reported: BPMN 2.0 — Thu, 9 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Cardinality of Relationship from CategoryValue to Category

  • Key: BPMN21-262
  • Legacy Issue Number: 15814
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the Group class diagram (Figure 8.15 on page 70) CategoryValue has a relationship with cardinality 1 to Category. However, according to Table 8.23 on page 72, CategoryValue references category with a cardinality of [0..1].

    I would suggest to set the cardinality to 1.

  • Reported: BPMN 2.0 — Fri, 12 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Model Association participantMultiplicity(Ref) of element Participant

  • Key: BPMN21-261
  • Legacy Issue Number: 15812
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    The model association participantMultiplicity(Ref) is twice named participantMultiplicity (in the class diagram and in Table 9.2 on the left side) and once participantMultiplicityRef (in Table 9.2 on the text of the right side). Maybe the text of Table 9.2 can be replaced as follows:

    participantMultiplicity: participant-
    Multiplicity [0..1]
    -->
    participantMultiplicityRef: Participant-
    Multiplicity [0..1]

  • Reported: BPMN 2.0 — Thu, 11 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Events that can be located after an Event-Based Gateway

  • Key: BPMN21-239
  • Legacy Issue Number: 15746
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Chapter/Section 10.5.6. Page 306. It says:

    “Event-Based Gateways are configured by having outgoing Sequence Flows target an Intermediate Event or a Receive Task …”

    “If Message Intermediate Events are used in the configuration, then Receive Tasks MUST NOT …”

    “Only the following Intermediate Event triggers are valid: Message, Signal, Timer, Conditional, and Multiple (which can only include the previous triggers). Thus, the following Intermediate Event triggers are not valid: Error, Cancel, Compensation, and Link.”

    COMMENTS:

    According to Table 10.93 (p. 269) Intermediate catch Events in normal flow are: message, timer, conditional, link, signal, multiple and parallel multiple.

    The Events after an Event-Based Gateway can be only catch Intermediate Events in normal flow, but two of them (Link and parallel Multiple) are not allowed.

    SUGGESTIONS:

    Then, it should say:

    “Event-Based Gateways are configured by having outgoing Sequence Flows target an Intermediate catch Event or a Receive Task …”

    “If Message Intermediate catch Events are used in the configuration, then Receive Tasks MUST NOT …”

    “Only the following Intermediate catch Event triggers in normal flow are valid: Message, Signal, Timer, Conditional, and Multiple (which can only include the previous triggers). Thus, the following Intermediate catch Event triggers in normal flow are not valid: Link, and Parallel Multiple.”

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistencies concerning attribute “activationCount”

  • Key: BPMN21-238
  • Legacy Issue Number: 15745
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 10.5.5. Page 305. Table 10.126. Row “activationCount”. It says:
    “Refers at runtime to the number of tokens that are present on an incoming Sequence Flow of the Complex Gateway.”

    ii) Chapter/Section 13.3.5. Page 452-453. It says:
    “ Each incoming gate of the Complex Gateway has an attribute activationCount, which can be used in an Expression as an
    integer-valued variable. This variable represents the number of tokens that are currently on the respective incoming Sequence
    Flows. The Complex Gateway has an attribute activationExpression. An activationExpression is a boolean Expression that
    refers to data and to the activationCount of incoming gates. For example, an activationExpression could be x1+x2+…+xm >=
    3 stating that it needs 3 out of the m incoming gates to have a token in order to proceed. To prevent undesirable oscillation of
    activation of the Complex Gateway, ActivationCount variables should only be used in subexpressions of the form …”

    COMMENTS:

    In according to Table 10.126 (“Instance attributes related to the Complex Gateway”) for each instance of a certain Complex Gateway there is one “activationCount” attribute, which memorize the “number of tokens that are present on an incoming Sequence Flow”. But a Complex Gateway - by definition ­ has more than one incoming Sequence Flow.

    In (ii) it is described the presence and usage of more than one “activationCount” variable in a single instance of a Complex Gateway.

    In (ii) it is clearly stated that “Each incoming gate of the Complex Gateway has an attribute activationCount”. Then, the “activationCount” attribute should be located in each incoming “SequenceFlow instance”, but it is not what the meta-model says (see Figure 8.35, p. 98).

    “activationCount” cannot be an attribute of Sequence Flow Class , because a “normal” instance of Sequence Flow that reachs a Complex Gateway will be instantiate as many times as the Complex Gateway.

    In (ii) the attribute activationExpression is mentioned, but according to Figure 10.114 and Table 10.125 (p. 304) its real name is activationCondition.

    SUGGESTIONS:

    Somehow the meta-model must represent the fact that there will be many “activationCount” for each instance of a Complex Gateway. An option is to make “activationCount” attribute (of Complex Gateway instance) an array of integers (one for each incoming Sequence Flow).

    In (ii) replace “activationExpression” with “activationCondition”

    Typo: in (ii) “on the respective incoming Sequence Flows” should be replaced by “on the respective incoming Sequence Flow”

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

None Intermediate Event: “catch” or “throw”

  • Key: BPMN21-233
  • Legacy Issue Number: 15740
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Description:

    ANTECEDENTS:
    i) Chapter/Section 10.4.4. Page 259. Table 10.89. Row “None”. It says:
    “The None Intermediate Event is only valid in normal flow, i.e., it MAY NOT be used on the boundary of an Activity. Although there is no specific trigger for this Event, it is defined as throw Event.”

    ii) Chapter/Section 10.4.5. Page 269. Table 10.93. Row “None”.
    None Intermediate Event is shown as a throw Event

    iii) Chapter/Section 10.4.5. Page 280. It says:
    “There are three (3) variations of None Events: a Start Event, a catch Intermediate Event, and …”

    “The catch None Intermediate Event MUST only be used in normal flow and, thus, MAY NOT be attached to the boundary of an Activity.”

    COMMENTS:

    In and (ii) None Intermediate Event is defined as a throw Event, but in (iii) it is considered to be a catch Event

    SUGGESTIONS:

    It seems that it is not important which type (throw or catch) would be chosen, but it is necessary to define one and be consistent in its use.

    Note: see Issue 15687

  • Reported: BPMN 2.0 — Fri, 15 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistencies concerning Link Events

  • Key: BPMN21-232
  • Legacy Issue Number: 15739
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 10.4.4. Page 260. Table 10.89. Row “Link”. It says:
    “There can be multiple source Link Events, but there can only be one target Link Event.”

    ii) Chapter/Section 10.4.4. Page 268. It says:

    • If there is a source Link, there MUST be a matching target Link (they have the same name).
    • There MAY be multiple source Links for a single target Link.
    • There MUST NOT be multiple target Links for a single source Link.

    iii) Chapter/Section 10.4.5. Page 270. Figure 10.73.
    Role “target” (from LinkEventDefinition to LinkEventDefinition) has multiplicity [0..1]
    Role “source” (from LinkEventDefinition to LinkEventDefinition) has multiplicity [0..*]

    iv) Chapter/Section 10.4.5. Page 278. Table 10.98. Row “sources”. It says:
    “sources: LinkEventDefinition [1..*]
    “Used to reference the corresponding ‘catch’ or ‘target’ LinkEventDefinition, when this LinkEventDefinition represents a ‘throw’ or ‘source’ LinkEventDefinition.”

    v) Chapter/Section 10.4.5. Page 278. Table 10.98. Row “target”. It says:
    “target: LinkEventDefinition [1]
    “Used to reference the corresponding ‘throw’ or ‘source’ LinkEventDefinition, when this LinkEventDefinition represents a ‘catch’ or ‘target’ LinkEventDefinition.”

    COMMENTS:

    In (iii) the role name “source” is incorrect, because its multiplicity is “many” and it is not the name shown in (iv)

    In (iv) the multiplicity of “sources” is incorrect, it must be [0..*], because ­ by definition ­ a source (throw) Link doesn’t have any “sources”. Furthermore, in (iii) the multiplicity is [0..*].

    In (iv) the description in misplaced. Actually, it is the description of the role “target”.

    In (v) the multiplicity of “target” is incorrect, it must be [0..1], because ­ by definition ­ a target (catch) Link doesn’t have any “target”. Furthermore, in (iii) the multiplicity is [0..1].

    In (v) the description in misplaced. Actually, it is the description of the role “sources”.

    In (iv) and (v) it is not stated that “target” and “sources” are mutually exclusive.
    A source (throw) Link have one “target” and zero “sources”
    A target (catch) Link have one or more “sources” and no “target”.

    SUGGESTIONS:
    In (iii) change role name from “source” to “sources”.

    In (iv) change multiplicity form “[1..*]” to “[0..*]

    In (iv) replace description by:
    “Used to reference the corresponding ‘throw’ or ‘source’ LinkEventDefinitions (at least one), when this LinkEventDefinition represents a ‘catch’ or ‘target’ LinkEventDefinition. When the LinkEventDefinition represents a ‘throw’ or ‘source’ LinkEventDefinition this model association is not set.”

    In (v) change multiplicity form “[1..1]” to “[0..1]

    In (iv) replace description by:
    “Used to reference the corresponding ‘catch’ or ‘target’ LinkEventDefinition, when this LinkEventDefinition represents a ‘throw’ or ‘source’ LinkEventDefinition. When the LinkEventDefinition represents a ‘catch’ or ‘target’ LinkEventDefinition this model association is not set.”

  • Reported: BPMN 2.0 — Fri, 15 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message Flow Connections for Start, End and Intermediate Events

  • Key: BPMN21-229
  • Legacy Issue Number: 15736
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 10.4.2. Page 253. Message Flow Connections for Start Events
    It says:

    • A Start Event MAY be the target for a Message Flow; it can have zero (0) or more incoming Message Flows. Each Message Flow targeting a Start Event represents an instantiation mechanism (a trigger) for the Process. Only one of the triggers is REQUIRED to start a new Process.
    • A Start Event MUST NOT be a source for a Message Flow; it MUST NOT have outgoing Message Flows.

    ii) Chapter/Section 10.4.3. Page 257. Message Flow Connections for End Events
    It says:

    • An End Event MUST NOT be the target of a Message Flow; it can have no incoming Message Flows..
    • An End Event MAY be the source of a Message Flow; it can have zero (0) or more outgoing Message Flows. Each Message Flow leaving the End Event will have a Message sent when the Event is triggered.
    • The Result attribute of the End Event MUST be set to Message or Multiple if there are any outgoing Message Flows.
    • The Result attribute of the End Event MUST be set to Multiple if there is more than one (1) outgoing Message Flows

    iii) Chapter/Section 10.4.4. Page 268. Message Flow Connections for Intermediate Events
    It says:

    • A Message Intermediate Event MAY be the target for a Message Flow; it can have one (1) incoming Message Flow.
    • A Message Intermediate Event MAY be a source for a Message Flow; it can have one (1) outgoing Message Flow.
    • A Message Intermediate Event MAY have an incoming Message Flow or an outgoing Message Flow, but not both.

    COMMENTS:

    In it is not explained when the Start Event can have incoming Message Flows.
    The rules are:
    The Start Event MUST be associated with one (1) or more MessageEventDefinitions if there are any incoming Message Flows.
    The Start Event will be Message, Multiple or Parallel Multiple if there are any incoming Message Flows.
    The Start Event will be Multiple or Parallel Multiple if there is more than one (1) incoming Message Flows.

    In it is said “Only one of the triggers is REQUIRED to start a new Process”, this is true for a Multiple Start Event, but not for a Parallel Multiple Start Event.

    In (ii) the “Result” attribute is mentioned. It was an attribute of End Event in BPMN 1.2, but not in BPMN 2.0. (see Figure 10.69, p. 241).
    The rules are:
    The End Event MUST be associated with one (1) or more MessageEventDefinitions if there are any outgoing Message Flows.
    The End Event will be Message or Multiple if there are any outgoing Message Flows.
    The End Event will be Multiple if there is more than one (1) outgoing Message Flows.

    In (iii) it is described only the Message Intermediate Event, but Multiple and Parallel Multiple Intermediate Events can be the source or the target of Message Flows too.

    SUGGESTIONS:

    In add the rules that define when the Start Event can have incoming Message Flows, and consider the case when a a Parallel Multiple Start Event is used.

    In (ii) remove references to “Result” attribute and update the rules that define when the End Event can have outgoing Message Flows.

    In (iii) describe the rules concerning Message Flows for Multiple and Parallel Multiple Intermediate Events.

  • Reported: BPMN 2.0 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pages 285-287. Missing Events types

  • Key: BPMN21-236
  • Legacy Issue Number: 15743
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 10.4.2. Page 269. Table 10.93.
    Boundary Interrupting Events are: error, cancel, compensation, message, timer, escalation, conditional, signal, multiple and parallel multiple.

    Boundary Non-interrupting Events are: message, timer, escalation, conditional, signal, multiple and parallel multiple.

    Event Sub-Process Interrupting Events are: error, compensation, message, timer, escalation, conditional, signal, multiple and parallel multiple.

    Event Sub-Process Non-interrupting Events are: message, timer, escalation, conditional, signal, multiple and parallel multiple.

    ii) Chapter/Section 10.4.6. Page 285. Subsection “Handling Events attached to an Activity (Intermediate boundary Events and Event Sub-Processes)”. It says:

    “For boundary Events, handling consists of consuming the Event occurrence and either canceling the Activity the Event is
    attached to, followed by normal Sequence Flows leaving that Activity, or by running an Event Handler without canceling the
    Activity (only for Message, Signal, Timer and Conditional Events, not for Error Events).”

    iii) Chapter/Section 10.4.6. Page 287. It says:
    “For an interrupting Event (Error, Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple),
    only one Event Sub-Process for the same Event Declaration MUST be modeled.”

    COMMENTS:

    In (ii) Escalation, Multiple and Parallel Multiple are not mentioned as Boundary Non-Interrupting. Furthermore,
    Cancel and Compensations are not mentioned as Boundary Events that always interrupt.

    In (iii) Compensation is not mentioned as an interrupting Event for an Event Sub-Process.

    SUGGESTIONS:

    In (ii)
    “(only for Message, Signal, Timer and Conditional Events, not for Error Events)” should be replaced by “(only for Message,
    Signal, Timer, Conditional, Escalation, Multiple and Parallel Multiple Events, not for Error, Cancel and Compensation
    Events)”

    In (iii)
    “(Error, Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)” should be replaced by “Error, Escalation, Message, Signal, Timer, Conditional, Compensation, Multiple, and Parallel Multiple)”

  • Reported: BPMN 2.0 — Fri, 15 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 281. Typo in Table 10.100

  • Key: BPMN21-235
  • Legacy Issue Number: 15742
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 10.100. Row “signalRef”.
    It says:
    “If the trigger is a Signal, then a Signal is provided.”

    “signalRef” is optional and it is similar to “errorRef” (see Table 10.96 p. 274) and “escalationRef” (see Table 10.97 p. 275).

    Then, it should say
    “If the trigger is a Signal, then a Signal payload MAY be provided.”

  • Reported: BPMN 2.0 — Fri, 15 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Number of internal markers for Choreography Activities

  • Key: BPMN21-241
  • Legacy Issue Number: 15748
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 11.4.1. Page 335. It says:
    “There are two types of internal markers (see Figure 11.12):”

    “A Choreography Task MAY have only one of the three (3) markers at one time.”

    ii) Chapter/Section 11.4.2. Page 341. It says:
    “There are two types of internal markers (see Figure 11.22):”

    “A Sub-Choreography MAY have only one of the three (3) markers at one time.”

    COMMENTS:

    In and (ii) it is clear that there are three markers, not two.

    SUGGESTIONS:

    In it should say:
    “There are three (3) types of internal markers (see Figure 11.12):”

    In (ii) it should say:
    “There are three (3) types of internal markers (see Figure 11.22):”

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong Public Process in Figure 10.127

  • Key: BPMN21-240
  • Legacy Issue Number: 15747
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 10.8. Page 318. It says:
    “For example Figure 10.127 shows a public Process at the top with a Send Task and Receive Task. A supporting private Process is shown at the bottom.”

    ii) Chapter/Section 10.8. Page 319. Figure 10.127.
    Public Process (at the top) consists of a Receive Task followed by a Send Task.

    iii) Issue 14652: Private process example correction (bpmn2-ftf). It says:
    “The private process in Figure 10-122 (One Process supporting to another)
    should have activity X and event B in parallel, because event B may
    arrive while X is executing, which would be lost in the current example.
    See webinar example on slide 51 in bmi/09-06-02.”

    COMMENTS:

    In it is stated that the A must be a Send Task, and B must be a Receive Task.

    In (ii) A is a Receive Task, and B is a Send Task. This contradicts .

    In (iii) it is stated that the problem with the example was the location of Activity X and Event B in the Private Process, nothing is said about Tasks A and B.

    SUGGESTIONS:

    Change the types of Tasks in Public Process:
    Task A should be a Send Task (filled envelope marker)
    Task B should be a Receive Task (unfilled envelope marker)

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 350. Typo

  • Key: BPMN21-243
  • Legacy Issue Number: 15750
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Chapter/Section 11.5.1. Page 350. Table 11.6. Row “None”. It says:
    “Sub-Processes, however, we should look at. The Parent Process can be considered the trigger.”

    COMMENTS:

    This sentence (“we should look at”) seems to be a draft.

    Table 11.6 is devoted to Start Events in Choreography, so “Sub-Processes” and “Process” are not pertinent here.

    SUGGESTIONS:

    Remove it.

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sub-Choreography is not a compound Activity

  • Key: BPMN21-242
  • Legacy Issue Number: 15749
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 8.3.7. Page 87. Figure 8.22. According to classes and their relationships:
    Both Activity and Choreography Activity are sub-classes of Flow Node.

    ii) Chapter/Section 11.4.2. Page 338. It says:
    “A Sub-Choreography is a compound Activity in that it has detail that is defined as a flow of other Activities, in this case, a Choreography.”

    COMMENTS:

    According to Choreography Activity is not a type of Activity, because there is not generalization from Choreography Activity to Activity.

    Then, A Sub-Choreography cannot be a “compound Activity”, because a Sub-Choreography is not a type of Activity.

    SUGGESTIONS:

    In (ii) it should say:
    “A Sub-Choreography is a compound ChoreographyActivity in that it has detail that is defined as a flow of other ChoreographyActivities.”

    “Activity” should be replaced by “ChoreographyActivity”
    “Activities” should be replaced by “ChoreographyActivities

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Event Sub-Processes use Multiple and Parallel Multiple Start Events

  • Key: BPMN21-234
  • Legacy Issue Number: 15741
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 10.4.2. Page 248. Table 10.84. Row “Multiple”. It says:
    “This means that there are multiple ways of triggering the Process”

    ii) Chapter/Section 10.4.2. Page 248. Table 10.84. Row “Parallel Multiple”. It says:
    “This means that there are multiple triggers REQUIRED before the Process can be instantiated”

    iii) Chapter/Section 10.4.2. Page 252. Table 10.86. Row “Multiple”. It says:
    “A Multiple Event indicates that that there are multiple ways of triggering the Event Sub-Process.”

    iv) Chapter/Section 10.4.2. Page 252. Table 10.86. Row “Parallel Multiple”. It says:
    “A Parallel Multiple Event indicates that that there are multiple ways of triggering the Event Sub-Process. All of them are REQUIRED to actually …”

    v) Chapter/Section 10.4.5. Page 279. It says:
    “If the trigger is Multiple, there are multiple ways of starting the Process. Only one of them is necessary to trigger the start of the Process. The EventDefinition subclasses will define which triggers apply”

    vi) Chapter/Section 10.4.5. Page 280. It says:
    “If the trigger is Multiple, there are multiple triggers REQUIRED to start the Process. All of them are necessary to trigger the start of the Process. The EventDefinition subclasses will define which triggers apply.”

    COMMENTS:

    and (ii) describe the use of Multiple and Parallel Multiple Start Events in Top-Level Processes.

    (iii) and (iv) describe the use of Multiple and Parallel Multiple Start Events in Event Sub- Processes

    In (v) and (vi) it is not mentioned the fact that Multiple and Parallel Multiple Start Events are used by Event Sub-Processes too.

    SUGGESTIONS:
    In (v) and (vi) “Process” should be replaced by “Process or Event Sub- Process” (4 times)

  • Reported: BPMN 2.0 — Fri, 15 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 270. Typo

  • Key: BPMN21-231
  • Legacy Issue Number: 15738
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “When one of the EventDefinition sub-types (e.g., TimerEventDefinition) is defined it is contained in Definitions, or a contained EventDefinition contained in a throw/catch Event.”

    According Figures 8.4 (p.52), 10.69 (p.241) and 10.73 (p.270), it should say:
    “When one of the EventDefinition sub-types (e.g., TimerEventDefinition) is defined it is contained in Definitions, or in a throw/catch Event.”

  • Reported: BPMN 2.0 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 247. “Parallel” instead of “Parallel Multiple”

  • Key: BPMN21-230
  • Legacy Issue Number: 15737
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “There are seven (7) types of Start Events for top-level Processes in BPMN (see Table 10.84): None, Message, Timer, Conditional, Signal, Multiple, and Parallel.”

    It should say:
    “There are seven (7) types of Start Events for top-level Processes in BPMN (see Table 10.84): None, Message, Timer, Conditional, Signal, Multiple, and Parallel Multiple.”

    “Parallel” should be replaced by “Parallel Multiple”.

  • Reported: BPMN 2.0 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Table 8.14: Example for BPMN's extension mechanism is not schema-valid

  • Key: BPMN21-237
  • Legacy Issue Number: 15744
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    The example for BPMN's extension mechanism in Table 8.14 on page 61 (PDF 91) is not valid with respect to the XML Schema.

    The example uses Extension Elements that are already defined in BPMN as part of ioSpecification, namely dataInput, dataOutput, inputSet, and outputSet. To be valid BPMN, those elements must be contained in an 'extensionElements' element and reside in an own XML namespace.

    I'd suggest to use different Extension Elements to avoid confusion with existing BPMN elements.

  • Reported: BPMN 2.0 — Fri, 15 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistencies and contradictions concerning Error element

  • Key: BPMN21-211
  • Legacy Issue Number: 15663
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    ANTECEDENTS:

    i) Chapter/Section 8.3.3. Page 82. Table 8.41. Row “name”. It says:
    “name : string”
    It means that “name” is mandatory.

    ii) Chapter/Section 8.3.3. Page 82. Table 8.41. Row “errorCode”. It says:
    “errorCode: string”
    It means that “errorCode” is mandatory.
    When describing this attribute three cases are identified:

    • End Event
    • Intermediate Event within normal flow
    • Intermediate Event attached to the boundary of an Activity

    iii) Chapter/Section 8.4.3. Page 105. It says:
    “An Operation defines Messages that are consumed and, optionally, produced when the Operation is called. It can also define zero or more errors that are returned when operation fails.” (see Figure 8.36, p.104, Table 8.66, p. 106).

    iv) Chapter/Section 10.4.1. Page 242. It says:
    “A trigger that is propagated is forwarded from the location where the Event has been thrown to the innermost enclosing scope instance (e.g., Process level) which has an attached Event being able to catch the trigger …. If no catching Event is found for an error or escalation trigger, this trigger is unresolved.”

    v) Chapter/Section 10.4.2. Page 250. Table 10.86. Row “Error”. It says:
    “The Error Start Event is only allowed for triggering an in-line Event Sub- Process. If there is only one (1) EventDefinition associated with the Start Event and that EventDefinition is of the subclass ErrorEventDefinition, then the Event is an Error Start Event and uses a lightning marker (see the figures to the right). Given the nature of Errors, an Event Sub-Process with an Error trigger will always interrupt its containing Process.”

    vi) Chapter/Section 10.4.3. Page 255. Table 10.88. Row “Error”. It says:
    “This type of End indicates that a named Error should be generated. All currently active threads in the particular Sub-Process are terminated as a result. The Error will be caught by a Catch 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 Activity in the hierarchy has such an Error Intermediate Event. The system executing the process can define additional Error handling in this case, a common one being termination of the Process instance.”

    vii) Chapter/Section 10.4.4. Page 263. Table 10.90. Row “Error”. It says:
    “A catch Intermediate Error Event can only be attached to the boundary of an Activity, i.e., it MAY NOT be used in normal flow. If used in this context, it reacts to (catches) a named Error, or to any Error if a name is not specified. Note that an Error Event always interrupts the Activity to which it is attached, i.e., there is not a non-interrupting version of this Event. The boundary of the Event thus always solid (see figure on the right).”

    viii) Chapter/Section 10.4.5. Page 269. Table 10.93. Row “Error”.
    Three Error Event Definitions are shown:
    Start Event Sub-Process (Interrupting)
    Intermediate Event attached to the boundary of an Activity (interrupting)
    End Event.

    ix) Chapter/Section 10.4.5. Page 274. Table 10.96. Row “error”. It says:
    “error: Error [0..1]
    It means that “error” is optional. (By the way, its name should be errorRef, see Figure 10.80, p.274).

    COMMENTS:

    In the name of an Error is mandatory, it means that the expression “named Error” carries no information, because every Error “is named”. Furthermore, the name of the Error is not used to identify it, the attribute errorCode is used instead.
    Then:

    • in (vi) the sentence “This type of End indicates that a named Error should be generated” is incorrect.
    • in (vii) the sentence “If used in this context, it reacts to (catches) a named Error, or to any Error if a name is not specified” is incorrect.

    In (ii) the attribute errorCode should be optional ([0..1]), because sometimes errorCode is not supplied (according to descriptions in Tables 8.41 and 10.88; it is mandatory only when the processType attribute of the Process is set to executable).

    In (ii) Intermediate Event within normal flow is identified, but it is incorrect, because it doesn’t exist as it is stated in (vii) and (viii). Furthermore, Start Event Sub-Process (Interrupting) is not identified in (ii), but it is in (viii).

    In (ii) when describing End Event, it is said “If the result is an Error, then the errorCode MUST be supplied (if the processType attribute of the Process is set to executable) This “throws” the Error.” It is confusing because the Error is actually thrown when an instance of Error (the “errorRef” of the ErrorEventDefinition) is thrown.

    In (iii) it is said that Operations use Errors too. Nevertheless, Errors are described as if they were associated only with Events.

    In (iv), according to meta-model a catching Error Event may not have an Error instance associated or can be associated to an Error instance without errorCode. In both cases “no catching Event is found”, but it is not clear whether both situations must be treated equally or not.

    In (v) nothing is said about the presence or absence of errorCode as in (vi).

    In (vi) the expression “named Error” is used, which (as stated above) is incorrect. It can be deduced that when an Error is thrown by the End Event it must contain an errorCode. But it not clear if an Error End Event must or must not throw an Error (which is optional, see ix). Besides, the Error can be catching by a Event Sub-Process, what it is not mentioned in (vi).

    In (vii) the expression “named Error” is used, which (as stated above) is incorrect. It seems that “name” is used instead of “errorCode”. It is not clear what happen when no Error is associated to de EventDefinition: Does it react as if an Error without errorCode where associated?

    In (ix) attribute errorRef is optional, but there are no rules concerning when and where an Error should be thrown. Nothing is said about processType attribute of the Process. So, it is possible that “processType attribute of the Process is set to executable” and no Error is provided, in consequence no errorCode could be supplied.

    Summary of problems:

    • The name of the Error cannot be used to match Errors, errorCode must be used instead.
    • According to some descriptions errorCode must be optional.
    • According to the meta-model errorRef is optional, but it is not clear when and where this attribute should be provided.
    • Error is described as if it were used by Events only, but it used by Operation too.

    SUGGESTIONS:

    • Remove all references to “named Errors” and the use of attribute “name” as a matching mechanism.
    • Define whether errorRef (in ErrorEventDefinition element) will be optional or not.
    • Define whether errorCode (in Error element) will be optional or not.
    • Describe all rules concerning errorRef and errorCode in Tables 10.86, 10.88 and 10.90 (where Error Start Event, Error End Event and Error Intermediate Event are described).
    • Describe rules concerning the use or Errors by Operations in section 8.4.3.
    • Remove from Tables 8.41 and 10.96 (where Error and ErrorEventDefinition are described) the rules concerning Events (remember that Errors are used by Operations too, and in the future more BPMN element could used Errors too).

    At least these issues should be clarified:

    a) If the processType attribute of the Process is set to executable, must errorRef or errorCode be supplied? or both?
    b) If errorRef (in ErrorEventDefinition element) is optional:

    • Is errorRef optional for a throwing Error End Event?
    • Is errorRef optional for a catching Error Start and Intermediate Events?
      If this is the case, what happens when an Error arrives?

    c) If errorCode (in Error element) is optional:

    • Is errorCode optional for a throwing Error End Event?
    • Is errorCode optional for a catching Error Start and Intermediate Events?

    d) Can two instances of Error share the same errorCode?

    • If the modeler want to match two Error Events (one throwing and one catching),
      must he/she provide the same Error to both ErrorEventDefinitions or two different Errors with the same errorCode? (According to the meta-model both alternatives are allowed, see Figure 10.80.)
  • Reported: BPMN 2.0 — Tue, 28 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 106. Wrong role name “errorRef” in Table 8.66

  • Key: BPMN21-210
  • Legacy Issue Number: 15662
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 8.66. Row “errorRef”

    It says:
    “errorRef: Error [0..*]

    It should say:
    “errorRefs: Error [0..*]

    See Figure 8.36 (p.104).

  • Reported: BPMN 2.0 — Tue, 28 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistencies and contradictions concerning Escalation element

  • Key: BPMN21-212
  • Legacy Issue Number: 15665
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    ANTECEDENTS:

    i) Chapter/Section 8.3.4. Page 83. Table 8.42. Row “name”. It says:
    “name : string”
    It means that “name” is mandatory.

    ii) Chapter/Section 8.3.4. Page 83. Table 8.42. Row “escalationCode”.
    “escalationCode: string”
    It means that “escalationCode” is mandatory.
    When describing this attribute three cases are identified:

    • End Event
    • Intermediate Event within normal flow
    • Intermediate Event attached to the boundary of an Activity

    iii) Chapter/Section 10.4.1. Page 242. It says:
    “A trigger that is propagated is forwarded from the location where the Event has been thrown to the innermost enclosing scope instance (e.g., Process level) which has an attached Event being able to catch the trigger …. If no catching Event is found for an error or escalation trigger, this trigger is unresolved.”

    iv) Chapter/Section 10.4.2. Page 250. Table 10.86. Row “Escalation”. It says:
    “Escalation Event Sub-Processes implement measures to expedite the completion of a business Activity, should it not satisfy a constraint specified on its execution (such as a time-based deadline). The Escalation Start Event is only allowed for triggering an in-line Event Sub- Process. If there is only one (1) EventDefinition associated with the Start Event and that EventDefinition is of the subclass EscalationEventDefinition, then the Event is an Escalation Start Event and uses an arrowhead marker…”

    v) Chapter/Section 10.4.3. Page 255. Table 10.88. Row “Escalation”. It says:
    “This type of End indicates that an Escalation should be triggered. Other active threads are not affected by this and continue to be executed. The Escalation will be caught by a Catch Escalation Intermediate Event with the same escalationCode or no escalationCode which is on the boundary of the nearest enclosing parent Activity (hierarchically). The behavior of the Process is unspecified if no Activity in the hierarchy has such an Escalation Intermediate Event.”

    vi) Chapter/Section 10.4.4. Page 263. Table 10.90. Row “Escalation”. It says:
    “This type of Event is used for handling a named Escalation. If attached to the boundary of an Activity, the Intermediate Event catches an Escalation. In contrast to an Error, an Escalation by default is assumed to not abort the Activity to which the boundary Event is attached...”

    vii) Chapter/Section 10.4.5. Page 269. Table 10.93. Row “Escalation”.
    Six Escalation Event Definitions are shown:
    Start Event Sub-Process (Interrupting and non-interrupting)
    Intermediate Event attached to the boundary of an Activity (interrupting and non-interrupting)
    Intermediate Event within normal flow
    End Event

    viii) Chapter/Section 10.4.5. Page 275. Table 10.97. Row “escalationRef”. It says:
    “escalationRef: Escalation [0..1]
    It means that “escalationRef” is optional.

    COMMENTS:

    In the name of an Escalation is mandatory, it means that the expression “named Escalation” carries no information, because every Escalation “is named”. Furthermore, the name of the Escalation is not used to identify it, the attribute escalationCode is used instead.
    Then:

    • in (vi) the sentence “This type of Event is used for handling a named Escalation” is incorrect.

    In (ii) the attribute escalationCode should be optional ([0..1]), because sometimes escalationCode is not supplied (according to descriptions in Tables 8.42 and 10.88; it is mandatory only when the processType attribute of the Process is set to executable).

    In (ii) Start Event Sub-Process (Interrupting) is not identified in, but it is in (vii).

    In (ii) when describing End Event, it is said “If the Result is an Escalation, then the escalationCode MUST be supplied (if the processType attribute of the Process is set to executable). This “throws” the Escalation.” It is confusing because the Escalation is actually thrown when an instance of Escalation (the “escalationRef” of the EscalationEventDefinition) is thrown.

    In (iii), according to meta-model a catching Escalation Event may not have an Escalation instance associated or can be associated to an Escalation instance without escalationCode. In both cases “no catching Event is found”, but it is not clear whether both situations must be treated equally or not.

    In (iv) nothing is said about the presence or absence of escalationCode as in (v).

    In (v) it can be deduced that when an Escalation is thrown by the End Event it must contain an escalationCode. But it not clear if an Escalation End Event must or must not throw an Escalation (which is optional, see viii). Besides, the Escalation can be catching by a Event Sub-Process, what it is not mentioned in (v).

    In (vi) the expression “named Escalation” is used, which (as stated above) is incorrect. Furthermore, nothing is said about the presence or absence of escalationCode as in (v).

    In (viii) attribute escalationRef is optional, but there no rules concerning when and where an Escalation should be thrown. Nothing is said about processType attribute of the Process. So, it is possible that “processType attribute of the Process is set to executable” and no Escalation is provided, in consequence no escalationCode could be supplied.

    Summary of problems:

    • The name of the Escalation cannot be used to match Escalations, escalationCode must be used instead.
    • According to some descriptions escalationCode must be optional.
    • According to the meta-model escalationRef is optional, but it is not clear when and where this attribute should be provided.
    • Escalation is described as if it were used by Events only, but in the future it could used by others elements (as Error is used by Events and Operations).

    SUGGESTIONS:

    • Remove all references to “named Escalations” and the use of attribute “name” as a matching mechanism.
    • Define whether escalationRef (in EscalationEventDefinition element) will be optional or not.
    • Define whether escalationCode (in Escalation element) will be optional or not.
    • Describe all rules concerning escalationRef and escalationCode in Tables 10.86, 10.88 and 10.90 (where Escalation Start Event, Escalation End Event and Escalation Intermediate Event are described).
    • Remove from Tables 8.42 and 10.97 (where Escalation and EscalationEventDefinition are described) the rules concerning Events (remember that Escalations could be used by other elements too).

    At least these issues should be clarified:

    a) If the processType attribute of the Process is set to executable, must escalationRef or escalationCode be supplied? or both?
    b) If escalationRef (in EscalationrEventDefinition element) is optional:

    • Is escalationRef optional for a throwing Escalation End and Intermediate Events?
    • Is escalationRef optional for a catching Escalation Start and Intermediate Events?
      If this is the case, what happens when an Escalation arrives?

    c) If escalationCode (in Escalation element) is optional:

    • Is escalationCode optional for a throwing Escalation End and Intermediate Events?
    • Is escalationCode optional for a catching Escalation Start and Intermediate Events?

    d) Can two instances of Escalation share the same escalationCode?

    • If the modeler want to match two Escalations Events (one throwing and one catching),
      must he/she provide the same Escalation to both EscalationEventDefinitions or two different Escalations with the same escalationCode? (According to the meta-model both alternatives are allowed, see Figure 10.82)
  • Reported: BPMN 2.0 — Tue, 28 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Number of Participant bands and Messages in a Choreography Task

  • Key: BPMN21-207
  • Legacy Issue Number: 15639
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 7.2.2. Page 32 . Table 7.2. Row “Choreography Task”. It says:
    “A Choreography Task is an atomic Activity in a Choreography (see page 333). It represents a set of one (1) or more Message exchanges. Each Choreography Task involves two (2) Participants. The name of the Choreography Task and each of the Participants are all displayed in the different bands that make up the shape’s graphical notation. There are two (2) or more Participant Bands and one Task Name Band.”
    --------------------------------------------------------------------------

    ii) Chapter/Section 11.4. Page 332. Figure 11.6.
    Model association from “ChoreographyTask” to “MessageFlow” (role name “messageFlowRefs”) has multiplicity [1..2]
    --------------------------------------------------------------------------

    iii) Chapter/Section 11.4. Page 332. Table 11.1. Row “participantRefs”. It says:
    “participantRefs: Participant [2..*]
    --------------------------------------------------------------------------

    iv) Chapter/Section 11.4.1. Page 333. It says:
    “A Choreography Task is an atomic Activity in a Choreography Process. It represents an Interaction, which is one (1) or two (2) Message exchanges between two (2) Participants. Using a Collaboration diagram to view these elements (see page 109 for more information on Collaboration), we would see the two (2) Pools representing the two (2) Participants of the Interaction …”
    --------------------------------------------------------------------------

    v) Chapter/Section 11.4.1. Page 333. It says:
    “There are two (2) or more Participant Bands and one Task Name Band (see Figure 11.8).”
    --------------------------------------------------------------------------

    vi) Chapter/Section 11.4.1. Page 335. It says:
    “The three (3) bands in the Choreography Task shape provide the distinction between this type of Task and an Orchestration Task (in a traditional BPMN diagram).”
    --------------------------------------------------------------------------

    vii) Chapter/Section 11.4.1. Page 338. Table 11.2. Row “messageFlowRef”. It says:
    “messageFlowRef: Message Flow [1..*]
    “Although not graphical represented, Choreography Task contain one (1) or more Message Flows that represent the interaction(s) between the Participants referenced by the Choreography Task.”
    --------------------------------------------------------------------------

    COMMENTS:

    There are inconsistencies concerning the number of Messages, Participants and Participant Bands in a Choreography Task.

    In
    Messages: 1 or more.
    Participants: 2
    Participant bands: 2 or more

    In (ii)
    Messages: 1 or 2.

    In (iii)
    Participants: 2 or more.
    (Because “ChoreographyTask” inherits “participantRefs” from “ChoreographyActivity”.)

    In (iv)
    Messages: 1 or 2.
    Participants: 2

    In (v)
    Participant bands: 2 or more

    In (vi)
    Participant bands: 2.
    (There are 3 bands, one of them is de Task Name band.)

    In (vii)
    Messages: 1 or more.

    It seems that the correct numbers should be:
    Messages: 1 or 2
    Participants: 2
    Task name band: 1
    Participants bands: 2
    Total bands: 3 (= 1 + 2)

    SUGGESTIONS:

    In
    “one (1) or more Message exchanges” should be replaced by “one (1) or two (2) Message exchanges”
    “two (2) or more Participant Bands” should be replaced by “two (2) Participant Bands”

    In (ii) nothing

    In (iii)
    A new model association should be drawn in Figure 11.6 from “ChoreographyTask” to “Participant”, which actually would not be a new model association but a redefinition of “participantsRefs” form “ChoreographyActivity” to “Participant”.

    It should be annotated: [2..2] +participantRefs

    {redefines participantRefs}

    (See OMG Unified Modeling LanguageTM (OMG UML), Infrastructure. formal/2009-02-04. Pages 113, 150)

    In (iv) nothing

    In (v)
    “two (2) or more Participant Bands” should be replaced by “two (2) Participant Bands”

    In (vi) nothing

    In (vii)
    “messageFlowRef: Message Flow [1..*]” should be replaced by “messageFlowRefs: Message Flow [1..2]

    “one (1) or more Message Flows” should be replaced by “one (1) or two (2) Message Flows”

    A new row should be added to Table 11.2
    “participantRefs: Participant [2..2]
    “A Choreography Task has two (2) Participants (see page 115 for more information on Participants). This is a redefinition of participantRefs of ChoreographyActivity (see Table 11.1).”

  • Reported: BPMN 2.0 — Thu, 23 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Is “Association” a type of “Artifact” or not?

  • Key: BPMN21-206
  • Legacy Issue Number: 15638
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    ANTECEDENTS:

    i) Chapter/Section 7.2. Page 28, it says:

    “There are four (4) Connecting Objects:
    Sequence Flows
    Message Flows
    Associations
    Data Associations”

    and

    “The current set of Artifacts includes:
    Group
    Text Annotation”

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

    ii) Chapter/Section 8.3.1. Figure 8.8. Page 66.

    In Figure 8.8 “Association” is a type of “Artifact”.
    --------------------------------------------------------------------------

    iii) Chapter/Section 11.3.2. Page 331.
    When describing Artifacts in Choreographies, it says: “Both Text Annotations and Groups can be used within Choreographies and all BPMN diagrams. There are no restrictions on their use.”

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

    COMMENTS:

    In “Associations” are identified as connectors, and are not included among the “Artifacts”.

    In (ii) According to the Meta-model “Association” is an “Artifact”, and it is described inside Section “8.3.12 Artifacts” (p.67). but in other parts of the document this fact is ignored.

    In (iii) “Associations” are not mentioned as a type of “Artifact”.

    SUGGESTION:

    On pages 28 and 331, state that “Association” is a type of “Artifact” in order to be consistent with the meta-model.

  • Reported: BPMN 2.0 — Thu, 23 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 83. Wrong reference to Table 8.42

  • Key: BPMN21-209
  • Legacy Issue Number: 15645
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “The Escalation element inherits the attributes and model associations of BaseElement (see Table 8.5), through its relationship to RootElement. Table 8.41 presents the additional model associations of the Error element:”

    Table 8.41 is referenced, but it is 8.42 which should be mentioned.

    Then, it should say:
    “The Escalation element inherits the attributes and model associations of BaseElement (see Table 8.5), through its relationship to RootElement. Table 8.42 presents the additional attributes and model associations of the Escalation element:”

    “Table 8.41 presents the additional model associations of the Error element” should be replaced by “Table 8.42 presents the additional attributes and model associations of the Escalation element”

  • Reported: BPMN 2.0 — Mon, 27 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistencies related to Default Sequence Flow

  • Key: BPMN21-208
  • Legacy Issue Number: 15640
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    i) Chapter/Section 7.2.2. Page 34. Table 7.2. Row “Default flow”. It says:
    “For Data-Based Exclusive Gateways or Inclusive Gateways, one type of flow is the Default condition flow …”
    --------------------------------------------------------------------------

    ii) Chapter/Section 8.3.9. Page 90
    According to Figure 8.24 a Sequence Flow can be the “default flow” of many Gateways simultaneously (see multiplicity [0..*] of roles exclusiveGateway, inclusiveGateway and complexGateway).

    The same occurs in Figure 10.104 (p.297); Figure 10.107 (p. 299); Figure 10.109 (p.301); and Figure 10.114 (p.304).
    --------------------------------------------------------------------------

    iii) Chapter/Section 8.3.13. Page 98. Figure 8.35.
    Multiplicity of role “activity” (from “SequenceFlow” to “Activity”) is [1..1].

    The same occurs in Figure 10.6 (p.155).
    --------------------------------------------------------------------------

    iv) Chapter/Section 11.3.1. Page 330. It says:
    “Default Sequence Flows: For Exclusive Gateways, Inclusive Gateways, and Choreography Activities that have Conditional Sequence Flows, one of the outgoing Sequence Flows MAY be a Default Sequence Flow. Because the other outgoing Sequence Flows will have appropriately visible of data as described above, the Participants would know if all the other conditions would be false, thus the Default Sequence Flow would be selected and the Choreography would move down that Sequence Flow.”
    --------------------------------------------------------------------------

    v) Chapter/Section 11.4. Page 332. Figure 11.6.
    “ChoreographyActivity” is not associated with “SequenceFlow” for optional default.

    The same occurs in Figure 8.35, p. 98.
    ---------------------------------------------------------------------------

    COMMENTS:

    In : “Default flows” are used by Complex Gateways and Activities too, but they are not mentioned. Furthermore, in BPMN 2 the name is “Exclusive Gateway” not “Data-Based Exclusive Gateway” (see p. 33)

    In (ii): It is impossible for a Sequence Flow to be the “default flow” of more than one Gateway or Activity simultaneously, because a Sequence Flow has only one FlowNode as its sourceRef (Figure 8.35, p.98; see also Section 8.3.13).

    In (iii): Multiplicity [1..1] of role “activity” (from “SequenceFlow” to “Activity”) means that every Sequence Flow is the default of exactly one Activity, which is not possible.

    In (iv): Complex Gateways can have default in Orchestrations, but they are not mentioned for Choreographies (… For Exclusive Gateways, Inclusive Gateways, and Choreography Activities that have Conditional Sequence Flows …).

    In (v): Choreography Activities can have default, but the corresponding associations between “ChoreographyActivity” and “SequenceFlow” in Figures 8.35 and 11.6 are not shown

    SUGGESTIONS:

    In : It says:
    “For Data-Based Exclusive Gateways or Inclusive Gateways, one type of flow is the Default condition flow …”

    It should say:
    “For Exclusive, Inclusive or Complex Gateways, or Activities one type of flow is the Default condition flow …”

    In (ii): Multiplicity of roles exclusiveGateway, inclusiveGateway and complexGateway in Figures 8.24, 10.104, 10.107, 10.109 and 10.114 should be changed from [0..*] to [0..1].
    Furthermore, in Figures 8.24 and 10.104 a constrain

    {XOR }

    should be used in order to underline that a Sequence Flow cannot be a default flow of two or more Flow Nodes simultaneously (See OMG Unified Modeling LanguageTM (OMG UML), Infrastructure. formal/2009-02-04. Pages 41, 42, 43). This {XOR] must include the associations from “SequenceFlow” to “ExclusiveGateway”, “ EnclusiveGateway”, “ ComplexGateway”, “Activity” and “ ChoreographyActivity”.

    In (iii): Multiplicity of role “activity” (from “SequenceFlow” to “Activity”) in Figures 8.35 and 10.6 should be changed from [1..1] to [0..1].

    In (iv): If default are allowed in Choreographies for Complex Gateways, then “For Exclusive Gateways, Inclusive Gateways, and Choreography Activities that have Conditional Sequence Flows” should be replaced by “For Exclusive Gateways, Inclusive Gateways,, Complex Gateways, and Choreography Activities that have Conditional Sequence Flows”.

    In (v): The corresponding model associations (between “ChoreographyActivity” and “SequenceFlow” : +activity [0..1] --> +default [0..1]) should be added to Figures 8.35 and 11.6.
    Also, the corresponding row “default” should be added to Table 11.1 (p.332). (Similar to row “default” in Table 10.3, p. 156).

  • Reported: BPMN 2.0 — Thu, 23 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Some Tokens consumed by Complex Gateways don’t reach end nodes

  • Key: BPMN21-205
  • Legacy Issue Number: 15637
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    ANTECEDENTS:

    i) Chapter/Section 7.1.1. Page 27 (“Understanding the Behavior of Diagrams”), it says:
    “A Start Event generates a token that MUST eventually be consumed at an End Event. (which MAY be implicit if not graphically displayed).”.
    --------------------------------------------------------------------------

    ii) Chapter/Section 10.4.3. Page 254, it says:
    “All the tokens that were generated within the Process MUST be consumed by an End Event before the Process has been completed.”

    “For Processes without an End Event, a token entering a path-ending Flow Object will be consumed when the processing performed by the object is completed (i.e., when the path has completed), as if the token had then gone on to reach an End Event. When all tokens for a given instance of the Process are consumed, then the Process will reach a state of being completed.”
    --------------------------------------------------------------------------

    iii) Chapter/Section 10.4.3. Page 257, it says:
    “All tokens that are generated at the Start Event for that Process MUST eventually arrive at an End Event.”.
    --------------------------------------------------------------------------

    iv) Chapter/Section 13.1. Page 440, it says:
    “For a Process instance to become completed, all tokens in that instance MUST reach an end node, i.e., a node without outgoing Sequence Flows.”
    --------------------------------------------------------------------------

    COMMENTS:

    These statements are not entirely correct because Complex Gateways can consume tokens and do not generate an outgoing token. These token “are lost” before they could reach and end node, but the Process instance can become complete anyway.

    In the waiting-for-reset phase the Complex Gateway “consumes a token from each incoming Sequence Flow that has a token and from which it had not yet consumed a token in the first phase …the Gateway might not produce any tokens in this phase and no exception is thrown.” (Table 13.5, p.454).
    Then, the tokens are consumed by the Gateway and will never reach any end node. For example, this is the normal behavior of a 3-of-5 discriminator, where the last two tokens will be consumed by the Gateway and lost.

    SUGGESTION:

    State that in order to be completed all tokes in a Process instance MUS be consumed, which is usually (normally) achieved when the tokens reach end nodes.

  • Reported: BPMN 2.0 — Thu, 23 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Is a Choreography a type of Process?

  • Key: BPMN21-204
  • Legacy Issue Number: 15636
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    ANTECEDENTS:

    i) Chapter/Section 7.1.1. Page 23, it says:
    “There are three basic types of sub-models within an end-to-end BPMN model:
    Processes (Orchestration), including:
    Private non-executable (internal) Business Processes
    Private executable (internal) Business Processes
    Public Processes
    Choreographies
    Collaborations, which can include Processes and/or Choreographies
    A view of Conversations”
    -------------------------------------------------------------------

    ii) Chapter/Section 7.3. Page 41, it says:
    “The BPMN 2.0 aims to cover three basic models of Processes: private Processes (both executable and non-executable), public Processes, and Choreographies.”
    --------------------------------------------------------------------

    iii) Chapter/Section 9. Page 109, it says:
    “Collaborations … MAY include Processes within the Pools and/or Choreographies between the Pools”
    --------------------------------------------------------------------

    iv) Chapter/Section 11. Page 325, it says:
    “A Choreography is a type of process, but differs in purpose and behavior from a standard BPMN Process.”
    ----------------------------------------------------------------------

    v) Throughout the entire document.
    In several places it is used the expression “Choreography Process” instead of “Choreography”.

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

    COMMENTS:

    a) Classifications on pages 23 and 41 are different. It is not clear the difference between “types of sub-models within an end-to-end BPMN model” and “basic models of Processes”. In the first case “Choreographies are not Processes”, but in the second “Choreographies are Processes”.

    b) According to UML models “Choreographies are not Processes”. See Figure 9.1 (p 109), Figure 10.2 (p. 150) and Figure 11.1 (p. 326).

    c) Maybe in a broad sense a “Choreography IS a Process”. But the formal definitions (UML models in BPMN 2.0 specification) make a clear distinction between both concepts. Which ­ of course ­are tightly interrelated.

    SUGGESTIONS:

    Modify the classification on page 41 in order to be consistent with the classification on page 23.

    Replace “Choreography Process” by “Choreography”.

    On page 325 replace “A Choreography is a type of process, …” by “A Choreography is like a process, ..”

  • Reported: BPMN 2.0 — Thu, 23 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 364. Number of Choreography Activities preceding an Inclusive Gateway

  • Key: BPMN21-201
  • Legacy Issue Number: 15599
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says:
    “For the split behavior to be enforced, the initiators of Choreography Activities immediately following the Gateway and the receiver of Choreography Activities immediately preceding the Gateway are the same Participant (i.e., A).”

    It is said “initiators of Choreography Activities”, meaning that there will be multiple Choreography Activities after the Gateway.

    But it is said “the receiver of Choreography Activities”, so it is not clear what the author wanted to communicate: One or multiple Choreography Activities before the Gateway. Both cases are possible (see page. 297).

    In the example (Figure 11.42, p.365) only one Choreography Task precedes the Gateways, but it is just one possible configuration.

    Then, it should say:
    1) “For the split behavior to be enforced, the initiators of Choreography Activities immediately following the Gateway and the receiver of Choreography Activity immediately preceding the Gateway are the same Participant (i.e., A).”

    or

    2) “For the split behavior to be enforced, the initiators of Choreography Activities immediately following the Gateway and the receivers of Choreography Activities immediately preceding the Gateway are the same Participant (i.e., A).”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 363. Wrong names of Choreography Tasks

  • Key: BPMN21-200
  • Legacy Issue Number: 15598
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Figure 11.40.

    Choreography Task names are all the same: Choreography Task 1.

    They should be: Choreography Task 1, Choreography Task 2, and Choreography Task 3.

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 352. “escalation” instead of “non- interrupting

  • Key: BPMN21-198
  • Legacy Issue Number: 15596
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 11.7. Row “Timer: Attached to Activity boundary”

    It says:
    “This includes both interrupting and escalation Events.”

    “Escalation” does not make sense here.

    Then, it should say:
    “This includes both interrupting and non- interrupting Events.”

    “escalation” should be replaced by “non- interrupting”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 312. Wrong name of Figure 10.122

  • Key: BPMN21-197
  • Legacy Issue Number: 15595
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “Figure 10.122 - Monitoring Class Diagram”

    Figure describes A Compensation Event Sub-Process (see last paragraph on page 311).

    Then, it should say
    “Figure 10.122 - Compensation Event Sub-Process”

    “Monitoring Class Diagram” should be replaced by “Compensation Event Sub-Process

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 274. Wrong role name “errorRef” in Table 10.96

  • Key: BPMN21-203
  • Legacy Issue Number: 15602
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    Table 10.96. Row “error”

    It says:
    “error: Error [0..1]

    It should say:
    “errorRef: Error [0..1]

    See Figure 10.80 (p.274).

  • Reported: BPMN 2.0 — Sun, 19 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 10.30 is incorrect

  • Key: BPMN21-202
  • Legacy Issue Number: 15601
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Figure 10.30 shows a collapsed Event Sub-Process. This figure is supposed to have an event marker in the upper left of the shape (as described in the bullet directly above it).

  • Reported: BPMN 2.0 — Sun, 19 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 352. “Cancel” instead of “Compensation

  • Key: BPMN21-199
  • Legacy Issue Number: 15597
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    a) Table 11.7. Row “Compensation: in Normal Flow”

    It says:
    “…there would be no indicator as to who is the source of the Cancel.”

    Compensation Event is described here.

    Then, it should say:
    “…there would be no indicator as to who is the source of the Compensation.”

    “Cancel” should be replaced by “Compensation”

    b) Table 11.7. Row “Compensation: Attached to Activity boundary”

    It says:
    “…on the Participant Band that is receiving the Cancel.”

    Compensation Event is described here.

    Then, it should say:
    “…on the Participant Band that is receiving the Compensation.”

    “Cancel” should be replaced by “Compensation

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Adding child attributes and child elements in XSLT causes errors

  • Key: BPMN21-109
  • Legacy Issue Number: 15448
  • Status: open  
  • Source: wu.ac.at ( abaumgra@wu.ac.at)
  • Summary:

    The examples of Business Process Model and Notation (BPMN) Version 2.0 - Beta 2, (May 2010) are valid with the provided XML Schema: spec/BPMN/2.0/20100501/BPMN20.xsd. However, the spec/BPMN/2.0/20100501/BPMN20-ToXMI.xslt does not transform these models into a complete XMI file. For example UserTasks with an implementation and ioSpecification is defined in BPMN as follows:
    <semantic:userTask implementation="##unspecified" completionQuantity="1" isForCompensation="false" startQuantity="1" name="Review Issue List" id="_6-66">
    <semantic:incoming>_6-167</semantic:incoming>
    <semantic:outgoing>_6-169</semantic:outgoing>
    <semantic:ioSpecification>
    <semantic:dataInput id="Din1276277381462"/>
    <semantic:inputSet>
    <semantic:dataInputRefs>Din1276277381462</semantic:dataInputRefs>
    </semantic:inputSet>
    <semantic:outputSet/>
    </semantic:ioSpecification>
    <semantic:dataInputAssociation id="_6-151">
    <semantic:sourceRef>_6-139</semantic:sourceRef>
    <semantic:targetRef>Din1276277381462</semantic:targetRef>
    </semantic:dataInputAssociation>
    </semantic:userTask>

    After the transformation with "BPMN20-ToXMI.xslt" I get the following result (without the specified implementation):
    <flowElements xmi:type="bpmnxmi:UserTask" id="_6-66" name="Review Issue List" outgoing="_6-169 " incoming="_6-167 " isForCompensation="false" startQuantity="1" completionQuantity="1">
    <ioSpecification xmi:type="bpmnxmi:InputOutputSpecification">
    <inputSets xmi:type="bpmnxmi:InputSet" dataInputRefs="Din1276277381462 "/>
    <outputSets xmi:type="bpmnxmi:OutputSet"/>
    <dataInputs xmi:type="bpmnxmi:DataInput" id="Din1276277381462"/>
    </ioSpecification>
    <dataInputAssociations xmi:type="bpmnxmi:DataInputAssociation" id="_6-151" targetRef="Din1276277381462 " sourceRef="_6-139 "/>
    </flowElements>

    I took the "Email Voting 2.bpmn" example from the spec/BPMN/2.0/examples/ZIP. The transformation of "Email Voting 2.bpmn" produces the following error messages:
    /XSLT-Transformation/BPMN20-ToXMI.xslt; Line #8; Column #116; Cannot add attribute dataObjectRef after child nodes or before an element is produced. Attribute will be ignored.
    OR
    /XSLT-Transformation/BPMN20-ToXMI.xslt; Line #8; Column #116; Cannot add attribute implementation after child nodes or before an element is produced. Attribute will be ignored.
    (similar messages for cancelActivity, dataObjectRef, messageRef, attachedToRef, isCollection)

  • Reported: BPMN 2.0 — Mon, 6 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page154. Wrong reference to chapter 13

  • Key: BPMN21-108
  • Legacy Issue Number: 15447
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “…Chapter 14 (see page 440).”

    It should say
    “…Chapter 13 (see page 440).”

    “Chapter 14” should be replaced by “Chapter 13"

  • Reported: BPMN 2.0 — Mon, 6 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page168. Wrong reference to figure 10.18

  • Key: BPMN21-111
  • Legacy Issue Number: 15456
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “A Manual Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a hand figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).”

    It should say
    “A Manual Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a hand figure marker that distinguishes the shape from other Task types (as shown in Figure 10.18).”

    “Figure 10.17” should be replaced by “Figure 10.18”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page167. Wrong reference to page 171

  • Key: BPMN21-110
  • Legacy Issue Number: 15455
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “See “User Task” on page 167 within the larger section of “Human Interactions” for the details of User Tasks.”

    It should say
    “See “User Task” on page 171 within the larger section of “Human Interactions” for the details of User Tasks.”

    “page 167” should be replaced by “page 171

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page170. Wrong references to figures 10.17 10.18

  • Key: BPMN21-114
  • Legacy Issue Number: 15459
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “…the human involvement is REQUIRED to complete the Task (see Figure 10.15 and Figure 10.17, above).”

    It should say
    “…the human involvement is REQUIRED to complete the Task (see Figure 10.17 and Figure 10.18, above).”

    “Figure 10.15” should be replaced by “Figure 10.17”

    “Figure 10.17” should be replaced by “Figure 10.18”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 169. Wrong reference to figure 10.20

  • Key: BPMN21-113
  • Legacy Issue Number: 15458
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Script Task (see Figure 10.11).”

    It should say
    “However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Script Task (see Figure 10.20).”

    “Figure 10.11” should be replaced by “Figure 10.20”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 219. Wrong reference to table 10.58

  • Key: BPMN21-121
  • Legacy Issue Number: 15467
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “Figure 10.54 presents the additional attributes and model associations of the InputOutputSpecification element:”

    It should say
    “Table 10.58 presents the additional attributes and model associations of the InputOutputSpecification element:”

    “Figure 10.54” should be replaced by “Table 10.58”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 217. Wrong reference to table 10.57

  • Key: BPMN21-120
  • Legacy Issue Number: 15466
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “Table 10.54 presents the additional attributes of the Property element:”

    It should say
    “Table 10.57 presents the additional attributes of the Property element:”

    “Table 10.54” should be replaced by “Table 10.57”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 181. Wrong reference to figure 10.29

  • Key: BPMN21-117
  • Legacy Issue Number: 15462
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “Figure 10.28 shows the class diagram related to Sub-Processes.”

    It should say
    “Figure 10.29 shows the class diagram related to Sub-Processes.”

    “Figure 10.28” should be replaced by “Figure 10.29”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 180. Wrong reference to figure 10.25

  • Key: BPMN21-116
  • Legacy Issue Number: 15461
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “The (Collapsed) Sub-Process marker, seen in Figure 10.24, can be combined …”

    It should say
    “The (Collapsed) Sub-Process marker, seen in Figure 10.25, can be combined …”

    “Figure 10.24” should be replaced by “Figure 10.25”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 191. Wrong reference to figure 10.42

  • Key: BPMN21-118
  • Legacy Issue Number: 15464
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “A Call Activity MUST fullfil the data requirements, as well as return the data produced by the CallableElement being invoked (see Figure 10.41).”

    It should say
    “A Call Activity MUST fullfil the data requirements, as well as return the data produced by the CallableElement being invoked (see Figure 10.42).”

    “Figure 10.41” should be replaced by “Figure 10.42”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 212. Wrong references to tables 10.51 10.52

  • Key: BPMN21-119
  • Legacy Issue Number: 15465
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “…and ItemAwareElement (Table 10.52). Table 10.54 presents the additional attributes of the DataObject element:”

    It should say
    “…and ItemAwareElement (Table 10.51). Table 10.52 presents the additional attributes of the DataObject element:”

    “Table 10.52” should be replaced by “Table 10.51”
    “Table 10.54” should be replaced by “Table 10.52”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page168 . Wrong reference to figure 10.19

  • Key: BPMN21-112
  • Legacy Issue Number: 15457
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.11).”

    It should say
    “However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.19).”

    “Figure 10.11” should be replaced by “Figure 10.19”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 172. Wrong reference to table 10.4

  • Key: BPMN21-115
  • Legacy Issue Number: 15460
  • Status: open  
  • Source: craftware.net ( Eduardo Jara)
  • Summary:

    It says
    “The User Task inherits the instance attributes of Activity (see Table 8.49).”

    It should say
    “The User Task inherits the instance attributes of Activity (see Table 10.4).”

    “Table 8.49” should be replaced by “Table 10.4”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Ambiguous statement about DataObjects and DataObjectReference

  • Key: BPMN21-91
  • Legacy Issue Number: 15388
  • Status: open  
  • Source: Rosch Consulting ( Cristina Conrad)
  • Summary:

    In section 10.3.1 there are some confusing statements about DataObjects and DataObjectReference. One statement reads "Data Object Reference cannot specify item definitions, and Data Objects cannot specify states." (page 215) and on the next page there is another statement that reads "Data Object elements can optionally reference a DataState element, which is the state of the data contained in the Data Object (see an example of DataStates used for Data Objects in Figure 7.8)." Can then DataObjects reference a state? Or is the "state" in the first sentence a different kind of state?

    Furthermore the schema (http://www.omg.org/spec/BPMN/2.0/20100501/Semantic.xsd) specifies that the DataOjectReference may have a reference to the item definition:
    <xsd:element name="dataObjectReference" type="tDataObjectReference" substitutionGroup="flowElement" />
    <xsd:complexType name="tDataObjectReference">
    <xsd:complexContent>
    <xsd:extension base="tFlowElement">
    <xsd:sequence>
    <xsd:element ref="dataState" minOccurs="0" maxOccurs="1" />
    </xsd:sequence>
    <xsd:attribute name="itemSubjectRef" type="xsd:QName" />
    <xsd:attribute name="dataObjectRef" type="xsd:IDREF" />
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>

    And that the DataObject may have a state:
    <xsd:element name="dataObject" type="tDataObject" substitutionGroup="flowElement" />
    <xsd:complexType name="tDataObject">
    <xsd:complexContent>
    <xsd:extension base="tFlowElement">
    <xsd:sequence>
    <xsd:element ref="dataState" minOccurs="0" maxOccurs="1" />
    </xsd:sequence>
    <xsd:attribute name="itemSubjectRef" type="xsd:QName" />
    <xsd:attribute name="isCollection" type="xsd:boolean" default="false" />
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>

  • Reported: BPMN 2.0 — Fri, 30 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Replace "process" attribute of a laneSet with "flowElementsContainer"?

  • Key: BPMN21-90
  • Legacy Issue Number: 15386
  • Status: open  
  • Source: USoft B.V. ( Cristina Constantin)
  • Summary:

    In BPMN2.0 beta1 LaneSet had a relationship with Process. This was changed in beta 2 and now LaneSet has a relationship with FlowElementsContainer, with the exception of Choreographies or Sub-Choreographies (see Figure 10.126 - The Lane class diagram ). In Table 10.134 ­ LaneSet attributes and model associations (of BETA2 document ) I see that there is a process attribute described as "the process owing the Lane set". Shouldn’t there be a "flowElementsContainer" attribute (as the LaneSet can be owned by a Sub-Process too) instead of the "process" attribute?

  • Reported: BPMN 2.0 — Thu, 29 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect reference in loopcharacteristics class diagram

  • Key: BPMN21-89
  • Legacy Issue Number: 15385
  • Status: open  
  • Source: USoft ( Rene de Bruin)
  • Summary:

    In the loopcharacteristics class diagram (figure 10.45) there are two references between StandardLoopCharacteristics and Expression. The one named 'loopMaximum' is not correct. LoopMaximum is an integer and is an attribute of StandardLoopCharacteristics (see table 10.28)

  • Reported: BPMN 2.0 — Wed, 28 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Define rules for placement of multiple activity markers

  • Key: BPMN21-84
  • Legacy Issue Number: 15255
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    A Task or Sub-Process may have multiple markers (e.g., looping, compensation, etc.). But the spec does not explicitly define how the markers should be ordered. The examples in the spec are not consistent in how they are presented.

  • Reported: BPMN 2.0b1 — Mon, 17 May 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Data associations need to be revisited and their use clarified.

  • Key: BPMN21-83
  • Legacy Issue Number: 15253
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Data associations need to be revisited and their use clarified.

    Data association should have there own visual depiction. Using the look of association is misleading as data associations have a different meaning than associations.

    A data association is an edge between flow elements (data objects(ref) and data stores(ref))as such they should not cross boundaries of pools or can they? This is not clear.
    It is also not clear if data objects(ref) and data stores (ref) can be drwan outside lanesets or pools.

  • Reported: BPMN 2.0b1 — Thu, 13 May 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistency between Boundary Event attribute names in Table 10.91 and Table 10.102

  • Key: BPMN21-87
  • Legacy Issue Number: 15374
  • Status: open  
  • Source: Camunda Services GmbH ( Mr. Falko Menge)
  • Summary:

    The Boundary Event XML schema in Table 10.102 on page 292 (322) defines an attribute called 'attachedToRef', whereas Table 10.91 on page 268 (298) lists an attribute with the name 'attachedTo'.

    Proposal:
    Replace 'attachedTo' with 'attachedToRef' in Table 10.91.

  • Reported: BPMN 2.0 — Wed, 14 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarify Relationship between Collabration Message Flow and Choreography Tasks

  • Key: BPMN21-86
  • Legacy Issue Number: 15284
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    When a Choreography is included in a Collaboration, the spec says that Message Flow can be "wired up" to Choreography Tasks. This needs to be defined better. Are the objects connected or overlapping? What if the Choreography Task moves, etc.

  • Reported: BPMN 2.0 — Tue, 8 Jun 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect N-to-N relationships in participants class diagram

  • Key: BPMN21-94
  • Legacy Issue Number: 15396
  • Status: open  
  • Source: USoft ( Rene de Bruin)
  • Summary:

    The "Participant attributes and model associations" on page 119 state that a Participant can play 0 or 1 PartnerRole and/or 0 or 1 PartnerEntity. The class diagram on page 118 however displayes an N-to-N relationship between Participant and PartnerRole/PartnerEntity. This is not correct.

  • Reported: BPMN 2.0 — Wed, 4 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Activity as InteractionNode

  • Key: BPMN21-93
  • Legacy Issue Number: 15393
  • Status: open  
  • Source: wu.ac.at ( abaumgra@wu.ac.at)
  • Summary:

    Depicted in the table 7.4 on page 44 and documented on page 124 message flow is allowed from and to activities, but in the meta-model on page 123 only Tasks are InteractionNodes and not activities.

  • Reported: BPMN 2.0 — Tue, 3 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add Link Events to a sub-conformance level (Descriptive)

  • Key: BPMN21-82
  • Legacy Issue Number: 15217
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    There is a proposal to add conformance levels to BPMN 2.0. The proposal for a Descriptive level should include Link Events.

  • Reported: BPMN 2.0b1 — Wed, 21 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Messages and User Tasks

  • Key: BPMN21-81
  • Legacy Issue Number: 15171
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    It is possible that User Tasks may send and/or receive messages. Thus, the mechanisms built into Send, Receive, and Service Tasks should also apply to User Tasks.
    Also, Message Flow can connect to any Task. Thus, there should be some restrictions on this or messaging should be applied at the Task level instead of the individual sub-types

  • Reported: BPMN 2.0b1 — Fri, 9 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Rethink implementation attribute in Send/Receive/Service Tasks

  • Key: BPMN21-78
  • Legacy Issue Number: 15121
  • Status: open  
  • Source: Intalio, Inc. ( Tammo van Lessen)
  • Summary:

    Currently, send/receive/service/user/business rule tasks have an "implementation" attribute. Based on the information in the spec and from the process orchestration subgroup call, this attribute shall identify the technology to be used for interaction. This can be Web Service, WS-HT or any other protocol/coordination protocol.

    While this makes sense for human tasks and business rule tasks, there are a couple of inconsistencies with Send/Receive/Service tasks. Here is why:

    • Receive Task has an implementation attribute, a message event has not.
    • A Receive Task and a subsequent Send Task that deal with messages defined within the same operation may have different values for the implementation attribute. This is however probably not intended.

    My proposed resolution is to remove the implementation attributes for send/receive/service tasks. We should discuss whether this information is really needed or whether it could be inferred by the implementationRef of the interface/operation tuple. The information might be needed to determine in which technology an interface/operation is implemented. See also http://www.osoa.org/jira/browse/BPMNFTF-519#action_15739

    As an alternative, MessageEventDefinition would need such an attribute as well.

  • Reported: BPMN 2.0b1 — Mon, 8 Mar 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for expanded hexagons

  • Key: BPMN21-74
  • Legacy Issue Number: 15066
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Filed for soaML: When multiple hexagons (conversation/communication) are
    expanded, it isn't possible to tell which message flows go with which
    hexagons, because the hexagons disappear. Should have a grouping
    notation to show which message flow came from expanding which hexagons.

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

definitionalCollaborationRef should be 0..*

  • Key: BPMN21-73
  • Legacy Issue Number: 15065
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Table 10.1, definitionalCollaborationRef includes the phrase “For Processes that interact with other Participants,” which implies that Processes are Participants. In fact they are distinct elements in the metamodel.

    More significantly it states “The definitional Collaboration specifies the Participants the Process interacts with, and more specifically, which individual service, Send or Receive Task, or Message Event, is connected to which Participant through Message Flow.” However a Process could be linked to Participants in many Collaborations and so the multiplicity of [0..1] seems over-limiting.

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multi-language labels for diagram elements

  • Key: BPMN21-71
  • Legacy Issue Number: 15043
  • Status: open  
  • Source: Signavio GmbH ( Gero Decker [X] (Inactive))
  • Summary:

    Most diagram elements carry a text label. The current version of the spec only allows to specify one string that is used as label.

    Multi-national companies often document their business processes in multiple languages (English, German, Spanish..). BPMN should therefore allow to set multiple labels per element (+ default language for the diagram)

  • Reported: BPMN 2.0b1 — Tue, 9 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Ambiguous statements about Sequence Flow

  • Key: BPMN21-70
  • Legacy Issue Number: 15030
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    In section 10.4.1, Event Concepts, (page 211 -241 PDF) there are some confusing statements about Sequence Flow. For example, one statement reads: "The Data Association for a Throw Event is performed when the Sequence Flow arrives at the Throw Event."
    Sequence Flow do not "arrive" in this context. The statements should be revised to refer to Tokens arriving at the Events to make consistent with the rest of the specification

  • Reported: BPMN 2.0b1 — Wed, 3 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add Brief Description for Error and Escalation Event Definitions

  • Key: BPMN21-66
  • Legacy Issue Number: 14854
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The other Event Definitions have a brief description of what they are. The Error and Escalation do not have this description.

  • Reported: BPMN 2.0b1 — Thu, 10 Dec 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Redundancy in specifying data in processes

  • Key: BPMN21-72
  • Legacy Issue Number: 15054
  • Status: open  
  • Source: University of Stuttgart - ISW ( Frank Leymann)
  • Summary:

    There is an obvious redundancy in defining data in BPMN 2.0 (data objects, item definitions, messages, import of schema,...). The current spec does not say what is mandatory to be specified in which situation. At least the most common scenarios should clarified in the spec, e.g. what must be specified in case a WSDL doc is already available and the message described in this document should be used by a service task; or what must be specified in case in incoming message (by a start event) should be copied to a data object.

    I submitted a comprehensive document describing the situation to the issues@omg.org address, whithout any reaction since weeks. I am happy to send this document to the one assigned to this issue and discuss it.

  • Reported: BPMN 2.0b1 — Wed, 17 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Integrate temporal and token semantics

  • Key: BPMN21-77
  • Legacy Issue Number: 15101
  • Status: open  
  • Source: Agile Enterprise Design ( Mr. Fred A. Cummins)
  • Summary:

    BPMN uses temporal semantics currently in process abstraction, and token flow in process execution. It isn't currently clear which semantics should be used for what purposes, or if they are compatible. Temporal semantics should be highlighted as one of the semantics for sequence flow, especially in conjunction with definitional collaborations, and it should be related to the token semantics.

  • Reported: BPMN 2.0b1 — Mon, 1 Mar 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Enforcability rules not complete

  • Key: BPMN21-76
  • Legacy Issue Number: 15071
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Filed for Alistar: Enforcability rules not complete.

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Choreography activities sharing message flow

  • Key: BPMN21-80
  • Legacy Issue Number: 15159
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The spec allows multiple choreography activities to share the same
    message flow. Is that intended?

  • Reported: BPMN 2.0b1 — Mon, 5 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Lists of values

  • Key: BPMN21-79
  • Legacy Issue Number: 15158
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The word "list" is used a fair amount in describing attributes and model
    associations. I think these are intended to be sets in most cases,
    rather than lists (no ordering, no duplicates). In UML, the default is
    sets, you need to add "

    {ordered}

    " "

    {non-unique}

    " to get lists.

  • Reported: BPMN 2.0b1 — Mon, 5 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CorrelationSubscription Ownership - Sub Process

  • Key: BPMN21-85
  • Legacy Issue Number: 15256
  • Status: open  
  • Source: SAP SE ( Karsten Ploesser)
  • Summary:

    Currently only Processes can 'own' Correlation Subscriptions. However, also Sub Processes should be able to define and own Correlation Subscriptions.

    Use case: restrict the lifecycle of the correlation subscription to the sub process only (as opposed to activating the subscription for the entire lifecycle of the process. This is particularly required in the case of long running processes.

    Proposed resolution:
    Figure 10.29- The Sub-Process class diagram
    Table 10.20 - Sub-Process attributes
    Table 10.48 - SubProcess XML schema
    > ADD attribute correlationSubscriptions:CorrelationSubscription [0..*] to class Sub-Process

  • Reported: BPMN 2.0 — Mon, 17 May 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Event Sub-Process only in Sub-Processes?

  • Key: BPMN21-88
  • Legacy Issue Number: 15375
  • Status: open  
  • Source: Materna GmbH ( Christoph Eickelmann)
  • Summary:

    Chapter 12.2.5 defines on page 178 (208 pdf)
    'An Event Sub-Process is a specialized Sub-Process that is used within a Process (or Sub-Process)'

    Chapter 13.4.4 defines on Page 452 (482 pdf)
    'Event Sub-Processes allow to handle an Event within the context of a given Sub-Processes or Process.'

    The second paragraph of Chapter 13.4.4 specify the cancel/parallel execution of the enclosing Sub-Process. If the Parent Process is not a Sub-Process but a Process, there is no definition.

    Solution:
    Replace in the second paragraph 'enclosing Sub-Process' with 'Parent Process' (2x).

  • Reported: BPMN 2.0 — Thu, 15 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

How to represent Activities that might fit in more than one Lane?

  • Key: BPMN21-69
  • Legacy Issue Number: 15007
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Some activities (or other elements) may have properties that would allow them to be placed in more than one lane. For example, a Task could be assigned multiple resources. Is there a way to display the activity in multiple lanes? If not, how is would the most appropriate lane be chosen?

  • Reported: BPMN 2.0b1 — Thu, 28 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

XML Schema for dataObjectReference and dataStoreReference are missing

  • Key: BPMN21-92
  • Legacy Issue Number: 15389
  • Status: open  
  • Source: Rosch Consulting ( Cristina Conrad)
  • Summary:

    Schema for dataObjectReference and dataStoreReference is missing from chapter 10.3.4 XML Schema for Data

  • Reported: BPMN 2.0 — Fri, 30 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for shared correlation properties

  • Key: BPMN21-75
  • Legacy Issue Number: 15070
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Filed for Alistar: Conversations / communications sharing correlation
    properties should be linked graphically.

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The spec should clearly state what visual features are available for extensions and which are restricted to core spec

  • Key: BPMN21-68
  • Legacy Issue Number: 14879
  • Status: open  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    Right now there is no clear separation on which graphical features (like line thickness, type of lines, color, etc) vendors are free to use as extensions, and which are restricted for the specification to use.

    We should define which features we want to use in the spec and which ones vendors are free to use. The reason for this is that if a vendor chooses line thickness for some visual extension and in a revision we choose to use the same feature, the vendor is forced to change to adapt (most importantly end-users).

    For example: it is clear that color is open for vendor extensions, and we should pick lines (thickness, dotted, etc) as restricted for our use.

  • Reported: BPMN 2.0b1 — Thu, 17 Dec 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML interface operations do not match BPMN interface operations

  • Key: BPMN21-67
  • Legacy Issue Number: 14876
  • Status: open  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    Currently interface operations in BPMN follow a "Document" model where all the arguments are wrapped in a single "Message" in and out of the operation.
    But in UML, interface operations follow the "RPC" model, where arguments are independent and each one has the "In, Out, InOut" classifier.
    This difference creates several problems when trying to relate/map BPMN and UML operations. Another side effect of the BPMN message model is that you cannot use simple data associations to fill the arguments of a service call. Since the operation is a single type, we have to use transformations to target the arguments (in my case we hide this complexity from the end user, and probably every vendor will do the same.

    So, if the FTF wants to have a reasonable integration with SoaML, we should fix this issue. The proposal is to adopt the UML model, with separate arguments instead of a single document in and out.
    We understand this is a major change, and a migration path from the Beta spec to the final one is a mandatory requirement.

  • Reported: BPMN 2.0b1 — Thu, 17 Dec 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.2.3: Task description needs revisiting

  • Key: BPMN21-60
  • Legacy Issue Number: 14796
  • Status: open  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Description of issue: The description for Task needs revisiting

    • States that "A Task is used when the work in the Process cannot be broken down to a finer level of details". This doesn't reflect typical usage. It's not that it cannot be broken down, but rather many users simply choose to not break down further. Users model at the level of detail most appropriate for their needs and the needs of their audience.
    • States that "Generally, an end-user and/or applications are used to perform the Task when it is executed". What does this mean? A black-box Task is traditionally used for documentation processes, where what the task does is more important than how (whether by an end-user or by an application) it is done. If users know how it should be done then they would use a specialized task (i.e. User Task or Service Task) rather than Task

    Proposal: Reword to make it clear that Task has a purpose and usage in itself, beyond being a superclass for specialized tasks.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

More description for "Process as a callable element"

  • Key: BPMN21-59
  • Legacy Issue Number: 14794
  • Status: open  
  • Source: Oracle ( Vishal Saxena)
  • Summary:

    ##Source: Oracle (Vishal Saxena, vishal.saxena@oracle.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-118
    ##Original Info: (Severity: Minor - Nature: Revision)

    On page 122 (152 in PDF) under fig 10-2 we describe process as a callable element. I think its a good idea to give small introduction.

    Comments:
    From: wstephe created: Fri, 11 Sep 2009 17:12:58 -0500 (CDT)
    The page and section numbers were updated to match the Beta 1 spec

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Correlation across conversations

  • Key: BPMN21-54
  • Legacy Issue Number: 14777
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The metamodel seems to be missing relations between the correlation
    information in multiple conversations of the same collaboration /
    choreography. For example, in Figure 11.3 (Conversation diagram
    depicting several conversations between Participants in a related
    domain) how does the process internal to Consignee handling the
    Consignee-Retailer conversation map its correlation information to the
    correlation info in the Consignee-Supplier conversation? Without this
    the Consignee conversations with the Retailer and Supplier will be
    uncoordinated.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Throughout Spec [Specification]: Define explicit separation of "modeling" vs "implementation" attributes

  • Key: BPMN21-53
  • Legacy Issue Number: 14775
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    This is number 1 of 12 issues submitted by Bruce Silver:

    Define explicit separation of "modeling" vs "implementation" attributes. The current "core" vs "extended" is nowhere close to this, since modeling needs much of the extended set. Modeling is about orchestration of "abstract" activities, abstract meaning they have a name (label), task type, perhaps markers like loop/MI/adhoc, and unique id of course, but not implementation properties. Abstract sequence flow has name, source and target refs; if conditional, the label is sufficient - you don't require a conditionExpression. Message flow or message event does not require a message attribute, timer event does not require TimeDate or TimeCycle (please rename it to Duration) attribute, error event does not require an error code attribute, etc. Those are for implementation; in modeling it's the diagram that counts, i.e. the label.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Define "Pool"

  • Key: BPMN21-55
  • Legacy Issue Number: 14784
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    The term "pool" is used extensively in the specification yet the definition seems inconsistent and not tied to the meta model. Sometimes a pool seems to be the role of a participant in a process context. In other cases it seems to be the essential container of a process. It seems to be a graphical element but shows up on ends of associations and in definitions of the semantics. The term "pool" does not seem to have any semantic relevance to process.
    Examples:
    • While a normal Process exists within a Pool, a Choreography exists between Pools (or Participants).
    • A Pool is the graphical representation of a Participant in a Collaboration (see page 235). It is also acts as a "swimlane" and a graphical container for partitioning a set of Activities from other Pools, usually in the context of B2B situations.
    • Nor can Sequence Flow cross a Pool boundary.
    • For message exchanges between pools, Conversations are used to group several Message Flow
    • A Participant is a specific business entity (e.g., a company) or a more general business role (e.g., a buyer, seller, or manufacturer) responsible for the execution of the Process enclosed in a Pool.

    The semantics behind of pool should be clarified and the spec should not use graphical elements to define semantics.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Annex A {Spec]: Add a section that documents the changes between V1.1 and V2.0

  • Key: BPMN21-57
  • Legacy Issue Number: 14788
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    We need to document the changes from V1.1. For example, we removed two attributes from User Task, because the same functionality is being handled elsewhere. We need to document such changes to make it easier for the implementers that need to migrate.

    Comments:
    From: mariano.benitez created: Wed, 8 Oct 2008 15:57:52 -0500 (CDT)
    We also dropped the concept of "streaming" data, so this should also be included in this section.
    Assignments elements are also removed, converted to DataAssociations.

    From: wstephe created: Sat, 12 Sep 2009 13:47:45 -0500 (CDT)
    Spec Draft version removed to prepare for BPMN 2.0 FTF

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Continue versus terminate in loop

  • Key: BPMN21-64
  • Legacy Issue Number: 14824
  • Status: open  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Introduction of end type break within a loop construct (continue construct is already there, implemented by the terminate end type which can be used inside a loop (multi instance activity) to end the loop).”

    This relates to what is e.g. said on page 407: “For a “terminate” End Event, the Sub-Process is abnormally terminated. In case of a multi-instance Activity, only the affected instance is terminated.”

    So, differentation is required between the two modes of getting out of the loop.

  • Reported: BPMN 2.0b1 — Wed, 25 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 8.3.3 [Data] Inconsistency between usage of expressions in Sequence Flows and in Data Associations

  • Key: BPMN21-58
  • Legacy Issue Number: 14790
  • Status: open  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    We have created some guards around the use of unavailable data in expressions of Data Associations.

    The issue I am raising is about the use case when a conditional sequence flow uses an expression, and the data objects used in that expression are unassigned.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.5 Text duplicated from 8.3.10

  • Key: BPMN21-61
  • Legacy Issue Number: 14800
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: The first three paragraphs in section 8.4 are duplicates of the same paragraphs in 8.3.10 where gateways are introduced.

    Proposal: Replace paragraphs in 10.5 by a short paragraph and a reference to 8.3.10's gateway section.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 - Section 14.3 [Execution Semantics]: Examples for the use of gateways are missing

  • Key: BPMN21-56
  • Legacy Issue Number: 14786
  • Status: open  
  • Source: International Business Machines ( Mr. Hagen Voelzer)
  • Summary:

    The use of some gateways should be described by example, e.g. complex gateway, inclusive gateway, multiple instances

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exclusive gateway Choreography rules too restrictive, only sender needed

  • Key: BPMN21-23
  • Legacy Issue Number: 14686
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Decisions are prevented from being used Choreographies if not all
    participants have access to the information on which the decision is
    made. But if the activities following the gateway are all sent by the
    same participant, only that participant needs to know how the decision
    is made. Using an event-based gateway in this case is confusing, since
    there is no waiting for events to proceed to the activities following
    it. Some sided email below about this.

    Steve,

    > The Gateway would most likely be Event based. The Buyer is
    > probably not going to be aware of the data that would be
    > used to make the decision, particularly a change order.
    > Thus, the Buyer is just going to be waiting for one of the
    > three responses.

    Makes sense for the buyer, but this isn't a model of the buyer (and the
    Seller is making a regular decision, why isn't that shown?).

    It's also odd to see an event-based gateway in a choreography since
    choreography can't don't wait for events, the participants do. The
    figure looks right according to the spec, but I think the spec is too
    restrictive on regular decisions in choreogrpahies.

    Conrad

    Steve,

    > The Seller is making a regular decision internally, but the
    > rationale (i.e., data) used to make the decision is private
    > for the Seller. A Choreography can only use Exclusive
    > Gateways if the data used for them is public.

    I understand that's the rule, but I'm not sure it make sense. In this
    case, the activities following the gateway are all initiated by the
    Seller. The rule should be that the seller has access to the decision
    data.

    > The Buyer does not know ahead of time, what the
    > results of the decision will be since the Buyer has not seen the
    > Seller's internal data.

    And that's fine, because it isn't the Buyer who initiates any of the
    activities after the gateway.

    > All private Exclusive Gateways show up as Event Gateways in a
    > Choreography.

    This is too hard to explain, for example, who receives the event? The
    choreography itself can't received an event, and there's no indication
    that it's the Buyer (other than they Buyer is receiving in the
    activities after the gateway).

    For FTF discussion.

    Conrad

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Parallel Gateway participants

  • Key: BPMN21-19
  • Legacy Issue Number: 14669
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Section 12.6.4 (Parallel Gateway) says "They create parallel paths of
    the Choreography that all Participants are aware of." Not all
    participants, only those involved after the gateway.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Event-based gateways in choreography should be exclusive

  • Key: BPMN21-18
  • Legacy Issue Number: 14668
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    An event-based gateway implies a message is being waited for, but
    choreographies can't receive messages, they have no central controller.
    One of the participants will have an event-based gateway internally, but
    the other will have a exclusive gateway. The choreography can use an
    exclusive gateway with no conditions, with the semantics is that exactly
    one of the following messages will be sent.

    Comments:
    From: conrad.bock created: Mon, 13 Jul 2009 15:53:49 -0500 (CDT)
    Email from Frank about conditions on exclusive gateways in choreographies:

    Hello Conrad,

    In my opinion there is no need to even have data as decision criteria.
    There may be a button, that a user presses (request xy..). Of course you
    can discuss, that the fact, that a button has been pressed is in itself
    data in the system. But it is a different kind of.

    So in the case of two senders there are two users and two buttons.
    Whoever presses first sends first.
    Whoever sends second is in a different branch of the choreography.
    That's how I understand it.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Section 15.1.2 Sub-Process Mappings: Table referenced is missing

  • Key: BPMN21-22
  • Legacy Issue Number: 14683
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Page 453. The first sentance of the section states:
    "The following table displays the mapping of an embedded Sub-Process with Adhoc="False" to a WS-BPEL scope. (This extends the mappings that are defined for all Activities--see page 450):"

    However, the table is not there.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.5.5 Complex Gateway: The general description of Complex Gateways needs improving

  • Key: BPMN21-21
  • Legacy Issue Number: 14674
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The general description of Complex Gateways needs improving. An example or two would be good.

    Comments:
    From: wstephe created: Sun, 13 Sep 2009 23:49:07 -0500 (CDT)
    The version number was removed from the summary so that it will apply to the Beta 1 spec

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Interactions supporting interactions

  • Key: BPMN21-15
  • Legacy Issue Number: 14663
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    When a business commits to an interaction with potential business
    partners, it might be that a particular partner needs only some of the
    interaction. This would be specified in another interaction diagram.
    The modeler needs to link these two interactions to say one supports the
    other, with the same semantics of the currently supports association,
    except applied to messaging rather than activities. The supports
    association should be generalized to cover interactions

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

PartnerRole underspecified and misnamed

  • Key: BPMN21-14
  • Legacy Issue Number: 14661
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    PartnerRole does not specify the context of the role (is it a role in an
    organization?). The examples given (a buyer, seller, or manufacturer)
    could just be Participants, rather than PartnerRoles. The term "role"
    also conflicts with Participants, which are effectively roles in
    Interactions.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 11-4 description

  • Key: BPMN21-20
  • Legacy Issue Number: 14673
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The first sentence of the paragraph under Figure 11-4 (Conversational
    view choreographies) refers to Figure 11-3, but is about Figure 11-4, as
    far as I can tell. How is the parent-child relation referred to at the
    beginning of the paragraph reflected in the notation or metamodel? It
    says the Planned Order Variations as being keyed on Order Id, but the
    figure shows it keyed on Variation ID also (compare to description of
    Retailer Order and Delivery Variations Ack). The paragraph refers to
    Conversations instead of Communication.

    The second paragraph under Figure 11-4 refers to Detailed Shipment
    Schedule and Delivery Monitor, which aren't in Figure 11-3 or 4. The
    paragraph refers to Conversations instead of Communication.

    The third paragraph under Figure 11-4 refers to Delivery Planning and
    Special Cover, which aren't in Figure 11-3 or 4. It mentions messages
    spawning conversations, which isn't described anywhere else. The
    paragraph refers to Conversations instead of Communication.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Gateways in Choreography missing split or merge

  • Key: BPMN21-12
  • Legacy Issue Number: 14656
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The section on gateways in choreography covers splits (diverging)
    gateways but not merges (converging) for parallel, exclusive. Only
    merges are covered for complex gateways.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message flow to/from events in Collaboration diagrams

  • Key: BPMN21-11
  • Legacy Issue Number: 14653
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Send/receive events and tasks have the same meaning, but the
    Collaboration section only shows message flow to/from tasks and other
    activities. Clarify that message flow can be attached to send/receive
    events in Collaboration.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CorrelationClassDiagram missing conversation association end name

  • Key: BPMN21-13
  • Legacy Issue Number: 14657
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 8-18 (The Correlation Class Diagram) is missing the association
    end name listed in Table 8-32 (CorrelationKey model associations).

    Comments:
    From: wstephe created: Fri, 24 Jul 2009 12:40:19 -0500 (CDT)
    I was going to add an issue that would request to remove the conversation model association row from Table 8-32. The model association is uni-directional, so correlationKeys should appear in the Conversation table (11-1), but conversation should not appear in the CorrelationKey table (8-32).

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multiple senders after event-based gateway in choreography

  • Key: BPMN21-17
  • Legacy Issue Number: 14667
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    About event-based gateways in choreography, the spec says:

    [Event-based] Gateways are used in Choreography when the data used to
    make the decision is only visible to the internal Processes of one
    Participant.

    On the right side of the Gateway [CB: I assume this means immediately
    after]: either the senders MUST be the same; or the receivers MUST be
    the same.

    If the decision criteria is private to one participant, how can there
    multiple senders after the gateway?

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Rules for exclusive gateway in choreography too strict

  • Key: BPMN21-16
  • Legacy Issue Number: 14666
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Exclusive gateways in choreography are required to use decision data
    accessible to all participants involved in the gatway. But if if the
    senders after gateway are the same, then receivers can use event
    gateways or event subprocess to wait for event that might never come.
    It isn't necessary for the receivers to have access to the decision
    data.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

A New Hook for Organizational Models?

  • Key: BPMN21-65
  • Legacy Issue Number: 14831
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The hook in BPMN for Resource Models is through the Resource class. Generally, Organization Models are considered separate from Resource Models, but there is not a separate hook for Organization Models in BPMN, the Resource class would have to be used for Organization models, which could be confusing.
    The Resource class could be renamed to make it more generic, or a new class for Organization could be added.

  • Reported: BPMN 2.0b1 — Wed, 2 Dec 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for alternaitve data input/output sets

  • Key: BPMN21-32
  • Legacy Issue Number: 14738
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Notation for data input/output sets is missing. I/O sets have a similar
    execution effect as decision and merge gateways, so it seems like they
    should be visible.

    Comments:
    From: wstephe created: Fri, 13 Mar 2009 13:50:54 -0500 (CDT)
    The decision on this for BPMN 1.X was that there would be no notation for this since it would probably be too complicated. There was a non-normative suggestion that inputs that belong in the same inputSet could be connected to the same point on the activity, but we didn't want to have anything like pins. I haven't seen any other suggestions. If we had something to look at, then we could consider.
    But, in general, in probably should be deferred for now.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exclusive Gateway Choreography Rule too Restrictive, starting new process

  • Key: BPMN21-31
  • Legacy Issue Number: 14737
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Filed for Dale Moberg. The rule illustrated by Figure 12-36 is that the
    choreography activities after an exclusive gateway must have the same
    receivers if the initiators are different. However, the receivers can
    be different if the activity starts a new process in the receiving
    participant, or if the receiving participant has access to the data in
    the decision from earlier in the flow. Steve says the discussions so
    far did not account for activites that start processes in the
    participants.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multiple processes per participant

  • Key: BPMN21-27
  • Legacy Issue Number: 14709
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    From side discussion with Frank: A single public interaction
    (choreography, collaboration, or conversation) might be supported by
    multiple internal processes, but the current metamodel only allows one
    process per participant. The multiplicity should be widened to *.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

optional source and target refs for data association

  • Key: BPMN21-26
  • Legacy Issue Number: 14704
  • Status: open  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    dataOutputAssociation/@sourceRef should be optional, not required.
    dataInputAssociation/@targetRef should be optional, not required.
    This is to support non-executable models (<a href="http://www.osoa.org/jira/browse/BPMN-381" title="Abstract BPMN Profile"><strike>BPMN-381</strike></a>), since these elements are part of the data interface of the parent node, which is unspecified in non-executable models. The other end of the association, the dataObject, is still required.

    Comments:
    From: ssamoojh@ca.ibm.com created: Thu, 14 May 2009 11:04:19 -0500 (CDT)
    Counterproposal - Rather than making the source or target optional, instead 'lighten' the spec text. The spec currently states that the source or target must be an ItemAwareElement. In the case of non-executable models, the source or target may be the FlowElement itself. So my proposal is to tweak the spec text, so as to allow this.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 10.2.2 Human Interactions: The Parameter class should be described

  • Key: BPMN21-36
  • Legacy Issue Number: 14751
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The Parameter class is an association of ProcessRole. Parameter has its own attributes. Thus, there should be a short subsection that describes Parameter, including a table that describes the attributes.
    A general question: Parameter is a very generic name. Should this class be named something more specific?

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 14.2.2 Activity (semantics):

  • Key: BPMN21-35
  • Legacy Issue Number: 14745
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Beta 1: Section 14.2.2 Activity (semantics): The state of a Data Object should be considered as a Performance Constrainst for an Activity Changing from the Ready to Active state

    ##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-411
    ##Original Info: (Severity: Critical - Nature: Enhancement)

    The state of a Data Object should be considered as a Performance Constrainst for an Activity Changing from the Ready to Active state.

    If a Data Object is not in the state defined as an input (e.g., "Approved"), then the InputSet should not yet be considered "available."

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Initializing and updating properties is not straight-forward

  • Key: BPMN21-30
  • Legacy Issue Number: 14730
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    From examples meeting on 2009.03.26:

    When creating the looping example for <a href="http://www.osoa.org/jira/browse/BPMN-281" title="V0.5.6: Section 10.3 Data [Data]: Assignments not defined"><strike>BPMN-281</strike></a>, it is not obvious how to initialize properties. Also, updating a property via a dataInputAssociation or dataOutputAssociation is unnecessarily complicated because sourceRef and targetRef are currently mandatory elements, but not really applicable for properties.

    Proposal:
    (1) Introduce a new entity "initializationAssignment" (or better name) as a contained element for property (and data object for symmetry reasons), which has the same structure as assignment, but with an optional "to" element.
    (2) Make dataInputAssociation::sourceRef and ::targetRef optional, likewise dataOutputAssociation::sourceRef and ::targetRef.

    Comments:
    From: trickovic created: Tue, 7 Apr 2009 04:00:15 -0500 (CDT)
    As per 4/6 BPMN 2.0 meeting: Defer <a href="http://www.osoa.org/jira/browse/BPMN-471" title="Initializing and updating properties is not straight-forward">BPMN-471</a>.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 17 BPMN Example: Include full BPMN example for this section

  • Key: BPMN21-25
  • Legacy Issue Number: 14702
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Section 17 will be temporarily removed until the BPMN example is added.

    The section should have a full example with diagrams, XML, and supporting text.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Roles for Entities

  • Key: BPMN21-24
  • Legacy Issue Number: 14698
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    There is no association between PartnerEntities and PartnerRoles, even
    though entities will play roles. The only link currently is through
    participant, requiring modification of a C models to link a role or
    entity, see <a href="http://www.osoa.org/jira/browse/BPMN-520">http://www.osoa.org/jira/browse/BPMN-520</a>. An association
    between partner entities and roles would enable collections of C models
    to be grouped by roles, with roles reused by entities.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add an example of Mutlple Start Events on the Boundary of a Sub-Process

  • Key: BPMN21-29
  • Legacy Issue Number: 14729
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Add an example of Mutlple Start Events on the Boundary of a Sub-Process as shown in an example for Issue 145 and described in the execution semantics section.
    Section 10.2.5, Beta 1 spec

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Section 15.1.2 Mapping to BPEL Activities: Message Mapping snippet refers to StructureDefinition

  • Key: BPMN21-28
  • Legacy Issue Number: 14711
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The figure for the mapping of Message to BPEL shows a snippet that includes a StructureDefinition element. The actual attribute for Message is structureRef, which points to ItemDefinition.
    This figure should be updated.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 10.1.2: Use of BPMN Common Elements [Process] -- Return removed TBD sections and complete text

  • Key: BPMN21-37
  • Legacy Issue Number: 14755
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Some sections with TBDs were removed for the Nov OMG posting. These sections should be returned and filled with content.
    This section should match a parallel section in Chapter 11 (Choreography).

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 10.2.4 Performer: Relate Performer to Human Performer

  • Key: BPMN21-34
  • Legacy Issue Number: 14744
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Mainly Editorial:

    A HumanPerformer is a type of Performer, but there is no reference to this in the Performer section. There should be more description of how Performer can be used (e.g., through HumanPerformer).

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 9.1 Collaboration: Expand description of Collaboration in section

  • Key: BPMN21-33
  • Legacy Issue Number: 14741
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The background text for the description of Collaboration is rather thin. Add more description and a figure or two.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Link Events - Constraints and Usage not clearly documented

  • Key: BPMN21-63
  • Legacy Issue Number: 14815
  • Status: open  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    The Sequence Flow constraints around the usage of Link Events are not clearly expressed in the spec.

    Very simply, it should express that:

    • A Catch Link Event should have no incoming Sequence Flow.
    • A Throw Link Event should have no outgoing Sequence Flow.

    Instead the spec has several rather confusing statements (pgs 235-236) that make it hard to infer the simple behavior I described above.
    Statements like:

    • If the Intermediate Event is used within normal flow:
    • Intermediate Events MUST be the target of a Sequence Flow.
    • An Intermediate Event MUST be a source for Sequence Flow.
    • An exception to this: a source Link Intermediate Event (as defined below), it is not required to have an outgoing Sequence Flow.
    • A Link Intermediate Event MUST NOT be both a target and a source of a Sequence Flow.
    • A Link Intermediate Event MAY be the target (target Link) or a source (source Link) of a Sequence Flow, but MUST NOT be both a target and a source.

    Recommendation:

    • Tighten up and simplify the constraint descriptions for Link Events.
    • Refrain from introducing new terms "source" and "target", or if the new terms are needed, clearly relate them to the existing "catch" and "throw" terms.
  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.2 Clearer separation between conceptual and visual model needed

  • Key: BPMN21-62
  • Legacy Issue Number: 14802
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: This section mixes conceptual meta-model statements with visual representation statements. A clearer separation of those concepts is needed.
    – p 127 (157 in PDF) "... inclusion of re-usable tasks and processes in the diagram" should be "... invocation of re-usable tasks and other processes from the process"
    – p 127 (157 in PDF) "... a process is not a graphical object. Instead, it is a set of graphical objects." A process is neither, it is a container for activities and other entities, all of which have a graphical representation.
    – p. 133 (163 in PDF) ff "A task is a rounded corner rectangle" should be "A task is represented by a rounded corner rectangle". This occurs frequently for all task types, so globally change "is a rounded corner rectangle" to "is represented by a rounded corner rectangle"

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 9 Collaboration [Choreography; Specification, Metamodel]:

  • Key: BPMN21-52
  • Legacy Issue Number: 14774
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Section 9 Collaboration [Choreography; Specification, Metamodel]: Clarify that a pool represents a single BPMN process, not a "participant" meaning role or business entity

    ##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-299
    ##Original Info: (Severity: Significant - Nature: Enhancement)

    This is number 2 of 12 issues submitted by Bruce Silver

    Clarify that a pool represents a single BPMN process, not a "participant" meaning role or business entity. At least do this for a white box pool (aka private process); a black box pool (abstract process) is empty of activities, so its process is unknown and often labeled as role or business entity. Also remove the language that multiple pools in a BPD are about B2B. This is rarely the case. Multiple white box pools in a BPD are used when the processes involved have independent lifetimes and cardinality, and almost always when both pools represent the same business entity not B2B.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Spec: New Annex?: Enumerate the validation rules of BPMN

  • Key: BPMN21-51
  • Legacy Issue Number: 14773
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    This is number 3 of 12 issues submitted by Bruce Silver

    Enumerate the validation rules of BPMN. Back in the old days when the BPDM guys kept saying BPMN 1.0 had no explicit rules or metamodel, you said it did but it was buried in the narrative. Now you have an explicit metamodel but the rules are still buried in the narrative, and inconsistent from one part to the next. Judging from v1.x it will take years to clean up the narrative, so just enumerate the rules in one place and say this overrides contrary info elsewhere in the narrative.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Spec: Section 10.3 Data [Data]:

  • Key: BPMN21-50
  • Legacy Issue Number: 14771
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Beta 1 Spec: Section 10.3 Data [Data]: If start of an activity is guarded by availability of input data, there should be some visible indication of this in the diagram

    ##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-302
    ##Original Info: (Severity: Significant - Nature: Enhancement)

    This is number 5 of 12 issues submitted by Bruce Silver

    If start of an activity is guarded by availability of input data, there should be some visible indication of this in the diagram. ("Modeling" means you don't need to see the non-diagram attributes). It seems like BPMN 2.0 is trying to make data more a first class citizen, so this is needed.

    Comments:
    From: bruce created: Fri, 5 Dec 2008 17:29:56 -0600 (CST)
    In a user task, it is understood that time can elapse between task ready and active, whereas in service task there is no delay. So the temporal semantics are clear from the diagram. The issue is when service task is guarded by data "availability" - whatever that implies. If service task could incur delay between ready and active because of input data, this should be visible somehow in the diagram.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Spec: Section 14 BPEL Mapping: Better clarify the subset of BPMN diagrams that are BPEL-mappable (roundtrippable!

  • Key: BPMN21-49
  • Legacy Issue Number: 14770
  • Status: open  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    Better clarify the subset of BPMN diagrams that are BPEL-mappable (roundtrippable!)

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide example: Basic process structure

  • Key: BPMN21-48
  • Legacy Issue Number: 14769
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: Missing example for process structure

    Proposal: Add an example showing process structure.

    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.

    Comments:
    From: mkloppmann created: Thu, 19 Feb 2009 12:30:43 -0600 (CST)
    Per the 2009.02.19 examples sub-team meeting:
    – Medium priority
    – The example should contain activities, events, gateways
    – Combine with <a href="http://www.osoa.org/jira/browse/BPMN-316" title="Provide example: Basic gateway examples">BPMN-316</a>

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide example: Inline Subprocess

  • Key: BPMN21-47
  • Legacy Issue Number: 14767
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: Missing example for Inline Subprocess

    Proposal: Add an example showing Inline Subprocess

    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.

    Comments:
    From: mkloppmann created: Thu, 19 Feb 2009 12:33:25 -0600 (CST)
    Per the 2009.02.19 examples sub-team meeting:
    – This item is related to <a href="http://www.osoa.org/jira/browse/BPMN-365" title="Notation for data flow in/out of a process">BPMN-365</a>

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide example: Basic gateway examples

  • Key: BPMN21-46
  • Legacy Issue Number: 14766
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: Missing examples for basic gateways.

    Proposal: Add three examples showing XOR, IOR and AND gateways.

    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.

    Comments:
    From: mkloppmann created: Thu, 19 Feb 2009 12:31:13 -0600 (CST)
    Per the 2009.02.19 examples sub-team meeting:
    – Medium priority
    – Combine with <a href="http://www.osoa.org/jira/browse/BPMN-310" title="Provide example: Basic process structure">BPMN-310</a>

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide example: Multi-instance activity

  • Key: BPMN21-45
  • Legacy Issue Number: 14765
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: Missing example for multi-instance activity.

    Proposal: Add an example showing a multi-instance activities, including data assignments from a set of values to the individual parallel instances, and from the results of the parallel instances to a result set. This will require collaboration with the Data team.

    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide example: Choreography

  • Key: BPMN21-42
  • Legacy Issue Number: 14762
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: Missing choreography example

    Proposal: Add an example showing a choreography with several choreography activities, based on the existing example.

    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 14.4 [BPEL mapping] Missing intermediate send event; mapping of participant ref

  • Key: BPMN21-41
  • Legacy Issue Number: 14761
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Type: Technical

    Description of issue:
    1. The spec misses the mapping for intermediate message send events
    2. The spec misses a mapping for send/receive events and tasks where the other party is specified not by a service-ref, but by a message flow to another participant.

    Proposal:
    1. Include that mapping into spec (see Visio)
    2. Introduce text describing how BPEL partnerLink is derived from either serviceRef or participantRef; use [serviceRef | participantRef] or similar notation as abbreviation.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Section 8.3.17 Sequence Flow and 14.2.1 Sequence Flow Considerations

  • Key: BPMN21-40
  • Legacy Issue Number: 14759
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Beta 1 Section 8.3.17 Sequence Flow and 14.2.1 Sequence Flow Considerations (Execution Semantics): Add Exclusive conditional behavior from activities

    ##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-349
    ##Original Info: (Severity: Significant - Nature: Enhancement)

    Suggested by Michael Rowley: Add Exclusive conditional behavior from activities.

    "Perhaps there should be a new variant of the minidiamond symbol to show that they are exclusive (filled in black, perhaps?). For human activities, it would then be clear that the different flows are different choices that can be made by the user. In B4P they would also be the "outcome" of the task."

    This was discussed on a BLOG (<a href="http://kswenson.wordpress.com/2008/01/01/human-process-trouble-ticket/#comment-8886">http://kswenson.wordpress.com/2008/01/01/human-process-trouble-ticket/#comment-8886</a>)

    Proposal TBD

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide example: Complex gateway

  • Key: BPMN21-44
  • Legacy Issue Number: 14764
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: Missing example for complex gateway.

    Proposal: Add an example showing a complex gateway.

    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide example: Conversation View

  • Key: BPMN21-43
  • Legacy Issue Number: 14763
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Type: Example

    Description of issue: Missing example for Conversation View.

    Proposal: Add an example showing a conversation view.

    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should

    also be provided using BPMN notation.

    Comments:
    From: wstephe created: Mon, 1 Dec 2008 21:45:34 -0600 (CST)
    An example has been started. It needs to be finished (including XML).

    Also, we should use this issue to track the full text requirements for Section 9.5 "Conversations" (V0.9.1)

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

[Chroeography] Complete section 11.4: Events

  • Key: BPMN21-39
  • Legacy Issue Number: 14757
  • Status: open  
  • Source: Oracle ( Martin Chapman)
  • Summary:

    Complete 11.4.1, 11.4.2, and 11.4.3 on choreogrpahy events.
    Each sub-section may require more text, review and some example and pictures.

    Comments:
    From: trickovic created: Fri, 12 Dec 2008 06:37:38 -0600 (CST)
    Issue assigned to Steve/the choreography team.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 11.2: Use of BPMN Common Elements [Choreography] -- Return removed TBD sections and complete text

  • Key: BPMN21-38
  • Legacy Issue Number: 14756
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Some sections with TBDs were removed for the Nov OMG posting. These sections should be returned and filled with content.
    This section should match a parallel section in Chapter 10 (Process).

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 251, Start Event on the boundary of a sub-process

  • Key: BPMN21-6
  • Legacy Issue Number: 14333
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    Is it still allowed to have Start and End Event on the boundary of an
    expended Sub-process?

    This was clearly stated and shown in BPMN 1.2. It is mentionned
    at page 251, but no example are provided.

    Is figure 7-8 page 69 valid?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 070, section 8 list of Core elements

  • Key: BPMN21-5
  • Legacy Issue Number: 14327
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    The figure 8-1 indicates "Infrastructure, Common Elements, and Services".
    Three Core sub-packages are listed in page 71 "Foundation, Service, and
    Common".
    Figure 8-2 shows "Foundation, Common, and Service".
    Section 8.1 describes "Infrastructure", Section 8.2
    describes "Foundation", Section 8.3 describes "Common Elements" and
    Section 8.4 describes "Services".
    The list of BPMN core elements indicated in thre first bullet of section
    2.1.1
    is: "Infrastructure, Foundation, Common, and Service packages."

    Is there 3 or 4 sub-packages and should we use the same naming convention
    within this section of the document?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Concept definition for Business Process

  • Key: BPMN21-2
  • Legacy Issue Number: 14242
  • Status: open  
  • Source: PNA University ( Jean-Paul Koster)
  • Summary:

    Since you still have the concept definition for "Business Process" listed as "TBD" in the Glossary, PNA would like to propose the following definition:

    Business Process:

    A Business Process is a cooperation between several people and/or systems each performing a particular role and possible other entities such as departments within a company or organization, in order to produce a product or to deliver a service to a customer. Within BPMN a Business Process is described using a BPD.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Allow a Process to be Ad Hoc (in addition to a Sub-Process)

  • Key: BPMN21-1
  • Legacy Issue Number: 14223
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Currently only Sub-Processes can be Ad Hoc. However, it would be useful for Processes to be Ad Hoc also. This would allow libraries of Ad Hoc Processes to be defined and re-used

  • Reported: BPMN 2.0b1 — Wed, 26 Aug 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 203, Table 10-26, The text describing the none and all behavior have been inverted

  • Key: BPMN21-9
  • Legacy Issue Number: 14538
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Page 203, Table 10-26, The text describing the none and all behavior of the behavior attribute have been inverted.

  • Reported: BPMN 2.0b1 — Thu, 8 Oct 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add a User Event

  • Key: BPMN21-8
  • Legacy Issue Number: 14422
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    There are many situations where a human involved in a process triggers an Event. The current set of Event types do not adequate reflect this situation. Thus, a new type of Event, a User Event, should be added to BPMN.

  • Reported: BPMN 2.0b1 — Mon, 14 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

This is a style suggestion to make diagrams clearer

  • Key: BPMN21-7
  • Legacy Issue Number: 14354
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    This is a style suggestion to make diagrams clearer. The XOR gateway allows two forms of diagram: empty diamond, and a diamond with an X in it. While redundancy is OK in general, the fact that different vendors make different choices. But an X and a cross look very similar. While the X should be allowed, the spec should indicate that it is preferred to use the blank option, with the eye to eventually eliminating the X.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Depiction of diagram fragments

  • Key: BPMN21-4
  • Legacy Issue Number: 14303
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 08, 2009

    The spec should prescribe how diagram fragments are presented. (e.g.
    three dots at end of continuing flows, ...)

    Given that BPMN has very specific structural requirements, most diagram
    fragments in the spec (and elsewhere) are not valid BPMN models.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 046, Section 7.2, Message not listed as a BPMN element

  • Key: BPMN21-3
  • Legacy Issue Number: 14293
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 06, 2009

    The Message element is not listed in any of the categories

    Comment 1 by dga...@trisotech.com, Jul 10, 2009

    The Message element is not listed in any of the BPMN element categories

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Example of Lane, Laneset, and Partitions

  • Key: BPMN21-10
  • Legacy Issue Number: 14614
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Chapter 10.7 needs a more detailed example of how lanes can use process information/elements to partition flow objects

  • Reported: BPMN 2.0b1 — Fri, 6 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT