1. OMG Mailing List
  2. Business Process Model and Notation 2.1 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: bpmn2-rtf
  • Issues Count: 398

Issues Summary

Key Issue Reported Fixed Disposition Status
BPMN21-401 Wrong Word - Says "sequential", Should Say "parallel" BPMN 2.0 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-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-387 Wrong table reference number BPMN 2.0b1 open
BPMN21-386 Wrong table reference number BPMN 2.0b1 open
BPMN21-388 Contradiction - can or cannot show Data Object multiple times on a diagram 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
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-350 Title BPMN 2.0 open
BPMN21-296 Change "recieved" in Fig 11.49 to "received" BPMN 2.0 open
BPMN21-369 Missing event marker in Figure 10.30 BPMN 2.0.2 open
BPMN21-328 Table 7.2 Description of Multiple Instances BPMN 2.0 open
BPMN21-295 Spello BPMN 2.0 open
BPMN21-287 Wrong document reference in dtc/2010-06-02 BPMN 2.0 open
BPMN21-336 Inconsistent Naming of Multi-instance Activity 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-347 Section 8.1 Figure 8.2 BPMN 2.0 open
BPMN21-330 Travel Booking Example BPMN 2.0 open
BPMN21-365 bug issue concerning event-based gateway illustration 10.98 BPMN 2.0 open
BPMN21-346 Section 7.6 BPMN 2.0 open
BPMN21-359 Allowable start events for event sub-process inconsistently defined BPMN 2.0.1 open
BPMN21-289 Incoming/Outgoing Data Associations of DataInputs/Outputs BPMN 2.0 open
BPMN21-302 Title of Figure 10.66 grammatically wrong BPMN 2.0 open
BPMN21-329 Unclear meaning of "‰" symbol BPMN 2.0 open
BPMN21-356 An invalid statement regarding Black Box depiction of pools BPMN 2.0 open
BPMN21-333 Revision & clarification for interruption of looping / multi-instance sub-processes BPMN 2.0 open
BPMN21-312 Underspecification of Multi-instance participants in Choreographies BPMN 2.0 open
BPMN21-279 Wrong diagram BPMN 2.0 open
BPMN21-293 Object mispelt BPMN 2.0 open
BPMN21-342 Cover Page Title BPMN 2.0 open
BPMN21-276 Meaning of 'behavior' attribute on MultiInstanceLoopCharacteristics quite confusing 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-311 Underspecification of initiating/non-initiating participants in non-trivial choreographies BPMN 2.0 open
BPMN21-339 Picture doesn't correspond to the description BPMN 2.0 open
BPMN21-362 Sequencing rule for Choreography activities causes ambiguous execution semantics? BPMN 2.0 open
BPMN21-317 Title of Figure 10.122 doesn't match its contents BPMN 2.0 open
BPMN21-283 Typo on page 76 BPMN 2.0 open
BPMN21-284 Typo on page 77 (physical page 107) BPMN 2.0 open
BPMN21-361 Invalid use of MAY NOT keyword BPMN 2.0.1 open
BPMN21-325 wrong reference on page 292 BPMN 2.0 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-332 Wrong attribute name "attachedTo" for Bounday event BPMN 2.0 open
BPMN21-294 Normal Process Not Defined 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-344 Section 3.2 Normative BPMN 2.0 open
BPMN21-297 more typos BPMN 2.0 open
BPMN21-291 The XSLT for transforming to BPMN XMI has errors BPMN 2.0 open
BPMN21-351 Entire document BPMN 2.0 open
BPMN21-343 Section 3.3 OMG UML BPMN 2.0 open
BPMN21-277 conversion of choreographies to collaboration diagrams BPMN 2.0 open
BPMN21-324 Catch None intermediate event BPMN 2.0 open
BPMN21-304 XML Schema not valid BPMN 2.0 open
BPMN21-363 [BPMN 2.0.2] bug issue concerning event sub process BPMN 2.0 open
BPMN21-370 word catalogue in the Figure 5.3: Order Fulfillment 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-358 References to invalid sub clauses (incorrect sub clause numbers) BPMN 2.0.1 open
BPMN21-337 Incorrect wording for description, should read "parallel" instead of "sequential" BPMN 2.0 open
BPMN21-368 figure 13.1 BPMN 2.0 open
BPMN21-280 Content of Section missing BPMN 2.0 open
BPMN21-320 item-aware element vs. ItemAwareElement BPMN 2.0 open
BPMN21-327 Reference omitted in BPMN 2 11-01-03 BPMN 2.0 open
BPMN21-322 ItemAwareElement the second 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-357 Suspected definition error in DataObject.isCollection BPMN 2.0.1 open
BPMN21-335 Association - an Artifact or a Connecting object? BPMN 2.0 open
BPMN21-372 Typo: Data Object spelled Objec BPMN 2.0 open
BPMN21-367 Bug p385 BPMN 2.0 open
BPMN21-313 Underspecification of ChoreographyLoopType BPMN 2.0 open
BPMN21-341 Wrong references to ItemAwareElement in UML diagram BPMN 2.0 open
BPMN21-281 enumeration missing BPMN 2.0 open
BPMN21-345 Section 3.3 BPEL4People BPMN 2.0 open
BPMN21-292 Procedure not defined BPMN 2.0 open
BPMN21-321 eXclusive Gateway BPMN 2.0 open
BPMN21-299 BPMN 2.0 Spec Problems (from Typo's to More Serious Issues) BPMN 2.0 open
BPMN21-282 number of start events for sub-processes BPMN 2.0 open
BPMN21-349 Typo in section 8.4 BPMN 2.0 open
BPMN21-298 BPMN2 issue: Example (DI lanes and nested lanes) appears to be invalid BPMN 2.0 open
BPMN21-275 Subclasses of Interaction Node (Task vs. Activity) BPMN 2.0 open
BPMN21-334 Significant typo in BPMN 2.0 v1.0 formal/2011-01-03 BPMN 2.0 open
BPMN21-290 CallChoreographyActivity notation for called participants BPMN 2.0 open
BPMN21-286 Cardinality of id in BaseElement BPMN 2.0 open
BPMN21-314 Some BPEL4People links are dead BPMN 2.0 open
BPMN21-348 Section 8.3.4 BPMN 2.0 open
BPMN21-371 Artifact used as an example for FlowElement BPMN 2.0 open
BPMN21-338 flowNodeRefs containment and subprocess clarification BPMN 2.0 open
BPMN21-374 Second occurance of sequential Multi-Instances should be parallel BPMN 2.0.2 open
BPMN21-364 bug issue concerning event-based gateway BPMN 2.0 open
BPMN21-352 Repeated use of previous definition for conflicting task attributes BPMN 2.0 open
BPMN21-309 Process name in property mapping is "statically" derived not "statistically" BPMN 2.0 open
BPMN21-355 Editorial: Wrong description of Figure 10.79 in the text BPMN 2.0 open
BPMN21-318 visualization enumeration level BPMN 2.0 open
BPMN21-326 Incomming sequence flow at start event BPMN 2.0 open
BPMN21-319 Missing Enumeration BPMN 2.0 open
BPMN21-288 Incorrect Section References BPMN 2.0 open
BPMN21-310 Unclear introduction of the concept of MEP BPMN 2.0 open
BPMN21-331 Looping/Multi-instantiation description error BPMN 2.0 open
BPMN21-353 Extend BPMN with a element that subclasses an existing BPMN element BPMN 2.0 open
BPMN21-354 BPMN typo BPMN 2.0 open
BPMN21-323 MAY NOT BPMN 2.0 open
BPMN21-303 Error in Description for Multiple Instances in Table 7.2 BPMN 2.0 open
BPMN21-340 Page 217: Send Task Mapping, first sentence BPMN 2.0 open
BPMN21-300 Can Event Sub-Processes Loop? BPMN 2.0 open
BPMN21-301 BPMN 2.0: Errors in Section 6.2 Structure of this Document BPMN 2.0 open
BPMN21-285 Relationship from Choreography to Artifacts BPMN 2.0 open
BPMN21-274 Inheritance and Relationship of ResourceParameter BPMN 2.0 open
BPMN21-207 Number of Participant bands and Messages in a Choreography Task BPMN 2.0 open
BPMN21-234 Event Sub-Processes use Multiple and Parallel Multiple Start Events BPMN 2.0 open
BPMN21-165 Page 274. Wrong role name “errorRef” in Table 10.96 BPMN 2.0 open
BPMN21-265 Connection Rules for Message Flow BPMN 2.0 open
BPMN21-200 Page 363. Wrong names of Choreography Tasks BPMN 2.0 open
BPMN21-116 Page 180. Wrong reference to figure 10.25 BPMN 2.0 open
BPMN21-108 Page154. Wrong reference to chapter 13 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-127 Page. 300. Wrong reference to page 450 BPMN 2.0 open
BPMN21-202 Figure 10.30 is incorrect BPMN 2.0 open
BPMN21-213 Text mentiones keyword "MUST NOT" 2 times BPMN 2.0 open
BPMN21-156 Page 202. Wrong multiplicity of model association “event” BPMN 2.0 open
BPMN21-215 Text references DataObject Element although DataState is meant BPMN 2.0 open
BPMN21-163 Page 241. Wrong role names in Figure 10.69 BPMN 2.0 open
BPMN21-251 Pages 467-468. Missing Figure BPMN 2.0 open
BPMN21-219 Inconsistencies concerning Flow Elements BPMN 2.0 open
BPMN21-121 Page 219. Wrong reference to table 10.58 BPMN 2.0 open
BPMN21-95 Figure 10.98 needs Updating BPMN 2.0 open
BPMN21-184 Page 128. Wrong name of Conversation “Delivery/Dispatch Plan” BPMN 2.0 open
BPMN21-80 Choreography activities sharing message flow BPMN 2.0b1 open
BPMN21-261 Model Association participantMultiplicity(Ref) of element Participant BPMN 2.0 open
BPMN21-212 Inconsistencies and contradictions concerning Escalation element BPMN 2.0 open
BPMN21-257 Outgoing Paths after Inclusive Gateway BPMN 2.0 open
BPMN21-144 Page 110. Wrong use of UML concept “aggregation”. BPMN 2.0 open
BPMN21-187 Page 140-141. Wrong name of model associations BPMN 2.0 open
BPMN21-102 Wrong metaclass name in attribute description BPMN 2.0 open
BPMN21-146 Page 115. Confusion over subtypes of Collaboration 1. BPMN 2.0 open
BPMN21-85 CorrelationSubscription Ownership - Sub Process BPMN 2.0 open
BPMN21-169 Page 338. Wrong name, multiplicity and description of “messageFlowRefs” BPMN 2.0 open
BPMN21-268 Multiple uncontrolled incoming Sequence Flows BPMN 2.0 open
BPMN21-86 Clarify Relationship between Collabration Message Flow and Choreography Tasks BPMN 2.0 open
BPMN21-272 Relationship type of CorrelationProperty BPMN 2.0 open
BPMN21-228 Page 288. Typos BPMN 2.0 open
BPMN21-89 Incorrect reference in loopcharacteristics class diagram BPMN 2.0 open
BPMN21-194 Page 255. Message End Event sends Messages BPMN 2.0 open
BPMN21-106 Page 96. Wrong reference to table 8.50 BPMN 2.0 open
BPMN21-130 Chapter 7. Typos BPMN 2.0 open
BPMN21-172 Page 342. Wrong reference to Table 11.3 BPMN 2.0 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-266 Attributes of GlobalScriptTask BPMN 2.0 open
BPMN21-181 Page 72. Artifact incorrectly identified as a Flow Element BPMN 2.0 open
BPMN21-75 Notation for shared correlation properties BPMN 2.0b1 open
BPMN21-66 Add Brief Description for Error and Escalation Event Definitions BPMN 2.0b1 open
BPMN21-91 Ambiguous statement about DataObjects and DataObjectReference BPMN 2.0 open
BPMN21-139 Page 96. ResourceParameter is not subclass of RootElement BPMN 2.0 open
BPMN21-209 Page 83. Wrong reference to Table 8.42 BPMN 2.0 open
BPMN21-244 Restrictions for Relative and Absolute Timers are the same BPMN 2.0 open
BPMN21-97 How many source are allowed for data association? BPMN 2.0 open
BPMN21-242 Sub-Choreography is not a compound Activity BPMN 2.0 open
BPMN21-131 Chapter 8. Typos BPMN 2.0 open
BPMN21-174 Page 359. Missing markers in Send and Receive Tasks BPMN 2.0 open
BPMN21-190 Page 171. “Manual Task” instead of “User Task” BPMN 2.0 open
BPMN21-166 Page 308. Incorrect name of Parallel Event-Based Gateway 1 BPMN 2.0 open
BPMN21-253 Wrong configuration of Event-Based Gateway BPMN 2.0 open
BPMN21-135 Chapter 13. Typos BPMN 2.0 open
BPMN21-199 Page 352. “Cancel” instead of “Compensation BPMN 2.0 open
BPMN21-256 Reference calledChoreographyRef of CallChoreography refers to Choreography and to CallableElement BPMN 2.0 open
BPMN21-70 Ambiguous statements about Sequence Flow BPMN 2.0b1 open
BPMN21-254 Table 7.2 Element Data Object column "Notation" typo Data ObjecT (Collection) BPMN 2.0 open
BPMN21-259 Attributes and Model Associations of EndEvent BPMN 2.0 open
BPMN21-104 Page 29 Wrong reference to page 240 BPMN 2.0 open
BPMN21-175 Pages 366-368. Wrong direction of Message Flow BPMN 2.0 open
BPMN21-179 Page 452. Incorrect name of Parallel Event-Based Gateway 3 BPMN 2.0 open
BPMN21-94 Incorrect N-to-N relationships in participants class diagram BPMN 2.0 open
BPMN21-271 Attribute Description of Class Signal missing BPMN 2.0 open
BPMN21-168 Page 317. Ambiguous associations “partitionElement” and “partitionElementRef” BPMN 2.0 open
BPMN21-223 Service Tasks can be the source or target of Messages Flows BPMN 2.0 open
BPMN21-229 Message Flow Connections for Start, End and Intermediate Events BPMN 2.0 open
BPMN21-248 Conditions for completion of Process and Sub-Process BPMN 2.0 open
BPMN21-214 Multiple Instances Description: Sequential instead of parallel, Typos BPMN 2.0 open
BPMN21-90 Replace "process" attribute of a laneSet with "flowElementsContainer"? BPMN 2.0 open
BPMN21-143 Page 109. Wrong multiplicity in Figure 9.1 BPMN 2.0 open
BPMN21-198 Page 352. “escalation” instead of “non- interrupting BPMN 2.0 open
BPMN21-69 How to represent Activities that might fit in more than one Lane? BPMN 2.0b1 open
BPMN21-231 Page 270. Typo BPMN 2.0 open
BPMN21-243 Page 350. Typo BPMN 2.0 open
BPMN21-255 Figure 10.127, private process supports public process BPMN 2.0 open
BPMN21-141 Page 99. Wrong inheritance of FlowNode BPMN 2.0 open
BPMN21-208 Inconsistencies related to Default Sequence Flow BPMN 2.0 open
BPMN21-72 Redundancy in specifying data in processes BPMN 2.0b1 open
BPMN21-232 Inconsistencies concerning Link Events BPMN 2.0 open
BPMN21-245 Terminate End Event in a Choreography with many Participants BPMN 2.0 open
BPMN21-188 Page 154. “Choreography” instead of “Process BPMN 2.0 open
BPMN21-148 Page 117 & 118. Wrong name of association “participantRefs BPMN 2.0 open
BPMN21-96 Typo: "Interrupting" should be "Non-Interrupting" BPMN 2.0 open
BPMN21-203 Page 274. Wrong role name “errorRef” in Table 10.96 BPMN 2.0 open
BPMN21-99 Unclear and incorrect specification of Expressions and Formal Expressions BPMN 2.0 open
BPMN21-178 Page 441. “Task” instead of “Activity” BPMN 2.0 open
BPMN21-206 Is “Association” a type of “Artifact” or not? BPMN 2.0 open
BPMN21-100 Contradictory mandatoryness of category for category values BPMN 2.0 open
BPMN21-222 Messages Flows can be attached to Events BPMN 2.0 open
BPMN21-128 Page 313. Wrong references to figures 10.123 10.124 BPMN 2.0 open
BPMN21-140 Page 97. Wrong multiplicity of association in Table 8.50 BPMN 2.0 open
BPMN21-153 Page 185. Nonexistent attribute shown in Figure 10.29 BPMN 2.0 open
BPMN21-136 Chapter14. Typos BPMN 2.0 open
BPMN21-157 Page 221. Nonexistent attribute “optional” mentioned BPMN 2.0 open
BPMN21-164 Page 266. Wrong role name "attachedToRef" in Table 10.91 BPMN 2.0 open
BPMN21-155 Page 192. Association “calledElementRef”: wrong name, location and description BPMN 2.0 open
BPMN21-84 Define rules for placement of multiple activity markers BPMN 2.0b1 open
BPMN21-88 Event Sub-Process only in Sub-Processes? BPMN 2.0 open
BPMN21-189 Pages 165-167. “implementation” attribute of Send and Receive Tasks BPMN 2.0 open
BPMN21-263 Attributes of Transaction Element BPMN 2.0 open
BPMN21-210 Page 106. Wrong role name “errorRef” in Table 8.66 BPMN 2.0 open
BPMN21-83 Data associations need to be revisited and their use clarified. BPMN 2.0b1 open
BPMN21-239 Events that can be located after an Event-Based Gateway BPMN 2.0 open
BPMN21-262 Cardinality of Relationship from CategoryValue to Category BPMN 2.0 open
BPMN21-205 Some Tokens consumed by Complex Gateways don’t reach end nodes BPMN 2.0 open
BPMN21-196 Page 283. The number of types of Event handlers BPMN 2.0 open
BPMN21-138 Page 84. Event is not direct subclass of FlowElement BPMN 2.0 open
BPMN21-250 In Chapter 14 Figures are not numbered BPMN 2.0 open
BPMN21-191 Page 190. Paragraph needs to be nested BPMN 2.0 open
BPMN21-120 Page 217. Wrong reference to table 10.57 BPMN 2.0 open
BPMN21-129 Page 485. Wrong reference to figure 14.2 BPMN 2.0 open
BPMN21-98 Cardinality of sources for Data Association BPMN 2.0 open
BPMN21-149 Page 117 & 118. Confusion over subtypes of Collaboration 2 BPMN 2.0 open
BPMN21-119 Page 212. Wrong references to tables 10.51 10.52 BPMN 2.0 open
BPMN21-159 Page 230. Wrong type of model association “transformation” BPMN 2.0 open
BPMN21-78 Rethink implementation attribute in Send/Receive/Service Tasks BPMN 2.0b1 open
BPMN21-204 Is a Choreography a type of Process? BPMN 2.0 open
BPMN21-71 Multi-language labels for diagram elements BPMN 2.0b1 open
BPMN21-147 Page 117. Wrong name of model association “interfaceRefs”. 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-218 Page 345. Sub-Choreographies instead of Choreography Activities BPMN 2.0 open
BPMN21-227 “cancelActivity” is not an attribute of Activity BPMN 2.0 open
BPMN21-114 Page170. Wrong references to figures 10.17 10.18 BPMN 2.0 open
BPMN21-93 Activity as InteractionNode BPMN 2.0 open
BPMN21-238 Inconsistencies concerning attribute “activationCount” BPMN 2.0 open
BPMN21-247 Apparent contradiction concerning compensation handler invocations BPMN 2.0 open
BPMN21-126 Page 266. Wrong reference to table 10.91 BPMN 2.0 open
BPMN21-112 Page168 . Wrong reference to figure 10.19 BPMN 2.0 open
BPMN21-79 Lists of values BPMN 2.0b1 open
BPMN21-192 Page 224. Typos BPMN 2.0 open
BPMN21-180 Page 57. Associations are incorrectly drawn Figure 8.6 BPMN 2.0 open
BPMN21-252 Page 473.Wrong reference to figure BPMN 2.0 open
BPMN21-197 Page 312. Wrong name of Figure 10.122 BPMN 2.0 open
BPMN21-87 Inconsistency between Boundary Event attribute names in Table 10.91 and Table 10.102 BPMN 2.0 open
BPMN21-264 Attributes of StandardLoopCharacteristics BPMN 2.0 open
BPMN21-150 Page 139. Ambiguous multiplicities of associations BPMN 2.0 open
BPMN21-125 Page 248. Wrong reference to table 10.85 BPMN 2.0 open
BPMN21-151 Page 151. Wrong role name and multiplicity of association “artifacts” BPMN 2.0 open
BPMN21-122 Page 231. Wrong reference to table 10.63 1 BPMN 2.0 open
BPMN21-193 Page 246. Typo BPMN 2.0 open
BPMN21-235 Page 281. Typo in Table 10.100 BPMN 2.0 open
BPMN21-162 Page 231. Activity is not an Item Aware Element BPMN 2.0 open
BPMN21-269 Converging Gateway has multiple outgoing connections BPMN 2.0 open
BPMN21-183 Page 78. Wrong association type in Table 8.32 BPMN 2.0 open
BPMN21-81 Messages and User Tasks BPMN 2.0b1 open
BPMN21-134 Chapter 11. Typos BPMN 2.0 open
BPMN21-260 CompensateEventDefinition vs. CompensationEventDefinition BPMN 2.0 open
BPMN21-110 Page167. Wrong reference to page 171 BPMN 2.0 open
BPMN21-240 Wrong Public Process in Figure 10.127 BPMN 2.0 open
BPMN21-115 Page 172. Wrong reference to table 10.4 BPMN 2.0 open
BPMN21-76 Enforcability rules not complete BPMN 2.0b1 open
BPMN21-217 Page 224. Typos BPMN 2.0 open
BPMN21-117 Page 181. Wrong reference to figure 10.29 BPMN 2.0 open
BPMN21-170 Page 341. Choreography instead of Sub-Choreography BPMN 2.0 open
BPMN21-107 Page153 Wrong reference to section 8.3.2 BPMN 2.0 open
BPMN21-154 Page 185. Nonexistent enumeration used in Table 10.21 BPMN 2.0 open
BPMN21-221 Incorrect multiplicity of dataStoreRef BPMN 2.0 open
BPMN21-160 Page 230. Super-class of ”Assignment” not shown in any diagram BPMN 2.0 open
BPMN21-237 Table 8.14: Example for BPMN's extension mechanism is not schema-valid BPMN 2.0 open
BPMN21-152 Page 182. Missing Start event triggers for Event Sub-Process BPMN 2.0 open
BPMN21-137 Left over restrictions on use of Start and End Events BPMN 2.0 open
BPMN21-249 Legal BPMN models and “lack of synchronization" BPMN 2.0 open
BPMN21-171 Page 341. Choreography Activity instead of Task BPMN 2.0 open
BPMN21-92 XML Schema for dataObjectReference and dataStoreReference are missing BPMN 2.0 open
BPMN21-133 Chapter 10. Typos BPMN 2.0 open
BPMN21-216 Figure 10.30 doesn't correspond with Text: Start Event as Marker BPMN 2.0 open
BPMN21-142 Page 104. Navigation (arrowhead) is needed if Figure 8.36 BPMN 2.0 open
BPMN21-201 Page 364. Number of Choreography Activities preceding an Inclusive Gateway BPMN 2.0 open
BPMN21-73 definitionalCollaborationRef should be 0..* BPMN 2.0b1 open
BPMN21-211 Inconsistencies and contradictions concerning Error element BPMN 2.0 open
BPMN21-167 Pages 312-457. Nonexistent attribute “compensable” mentioned BPMN 2.0 open
BPMN21-132 Chapter 9. Typos BPMN 2.0 open
BPMN21-182 Page 77. Incomplete sentence BPMN 2.0 open
BPMN21-185 Page 130. Nonexistent Conversation “Special Cover” is mentioned BPMN 2.0 open
BPMN21-101 Definition of Association is to strict BPMN 2.0 open
BPMN21-103 Definition of Signal Missing BPMN 2.0 open
BPMN21-241 Number of internal markers for Choreography Activities BPMN 2.0 open
BPMN21-145 Page 111. Association “participants” not shown in Figure 9.1 BPMN 2.0 open
BPMN21-123 Page 231. Wrong reference to table 10.63 2 BPMN 2.0 open
BPMN21-67 UML interface operations do not match BPMN interface operations BPMN 2.0b1 open
BPMN21-74 Notation for expanded hexagons BPMN 2.0b1 open
BPMN21-113 Page 169. Wrong reference to figure 10.20 BPMN 2.0 open
BPMN21-105 Page 96 Wrong reference to table 8.49 BPMN 2.0 open
BPMN21-161 Pages 230-231. Wrong name of Table 10.64 BPMN 2.0 open
BPMN21-226 Intermediate Message Event can be source or target of Message Flow BPMN 2.0 open
BPMN21-220 Inconsistencies concerning Item-Aware Elements BPMN 2.0 open
BPMN21-267 Element Repository BPMN 2.0 open
BPMN21-111 Page168. Wrong reference to figure 10.18 BPMN 2.0 open
BPMN21-177 Page 440. Incorrect name of Parallel Event-Based Gateway 2 BPMN 2.0 open
BPMN21-124 Page 245. Wrong reference to table 10.83 BPMN 2.0 open
BPMN21-246 “empty Start Event” is used instead of “None Start Event” BPMN 2.0 open
BPMN21-109 Adding child attributes and child elements in XSLT causes errors BPMN 2.0 open
BPMN21-186 Page 132. “Communication” instead of “Conversation” Figure 9.23 BPMN 2.0 open
BPMN21-195 Page 281. Wrong name of Figure 10.92 BPMN 2.0 open
BPMN21-77 Integrate temporal and token semantics BPMN 2.0b1 open
BPMN21-273 Model Associations of class Event BPMN 2.0 open
BPMN21-118 Page 191. Wrong reference to figure 10.42 BPMN 2.0 open
BPMN21-236 Pages 285-287. Missing Events types BPMN 2.0 open
BPMN21-176 Page 370. Wrong Parallel Gateway in Figure 11.47 BPMN 2.0 open
BPMN21-230 Page 247. “Parallel” instead of “Parallel Multiple” BPMN 2.0 open
BPMN21-173 Page 345. Wrong type of "calledChoreographyRef" BPMN 2.0 open
BPMN21-82 Add Link Events to a sub-conformance level (Descriptive) BPMN 2.0b1 open
BPMN21-270 Attributes of Element Resource Role BPMN 2.0 open
BPMN21-225 Participant multi-instance instead of Sub-Choreography multi-instance BPMN 2.0 open
BPMN21-233 None Intermediate Event: “catch” or “throw” BPMN 2.0 open
BPMN21-158 Pages 221-223. Inheritance of DataInput, DataOutput. Wrong table reference BPMN 2.0 open
BPMN21-65 A New Hook for Organizational Models? BPMN 2.0b1 open
BPMN21-60 Section 10.2.3: Task description needs revisiting BPMN 2.0b1 open
BPMN21-42 Provide example: Choreography 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-38 Beta 1: Section 11.2: Use of BPMN Common Elements [Choreography] -- Return removed TBD sections and complete text BPMN 2.0b1 open
BPMN21-23 Exclusive gateway Choreography rules too restrictive, only sender needed BPMN 2.0b1 open
BPMN21-41 Section 14.4 [BPEL mapping] Missing intermediate send event; mapping of participant ref 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-29 Add an example of Mutlple Start Events on the Boundary of a Sub-Process BPMN 2.0b1 open
BPMN21-62 Section 10.2 Clearer separation between conceptual and visual model needed BPMN 2.0b1 open
BPMN21-15 Interactions supporting interactions BPMN 2.0b1 open
BPMN21-47 Provide example: Inline Subprocess BPMN 2.0b1 open
BPMN21-33 Beta 1: Section 9.1 Collaboration: Expand description of Collaboration in section BPMN 2.0b1 open
BPMN21-45 Provide example: Multi-instance activity BPMN 2.0b1 open
BPMN21-50 Beta 1 Spec: Section 10.3 Data [Data]: BPMN 2.0b1 open
BPMN21-24 Roles for Entities BPMN 2.0b1 open
BPMN21-20 Figure 11-4 description BPMN 2.0b1 open
BPMN21-53 Throughout Spec [Specification]: Define explicit separation of "modeling" vs "implementation" attributes 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-57 Annex A {Spec]: Add a section that documents the changes between V1.1 and V2.0 BPMN 2.0b1 open
BPMN21-10 Example of Lane, Laneset, and Partitions BPMN 2.0b1 open
BPMN21-16 Rules for exclusive gateway in choreography too strict BPMN 2.0b1 open
BPMN21-2 Concept definition for Business Process BPMN 2.0b1 open
BPMN21-44 Provide example: Complex gateway BPMN 2.0b1 open
BPMN21-51 Beta 1 Spec: New Annex?: Enumerate the validation rules of BPMN BPMN 2.0b1 open
BPMN21-30 Initializing and updating properties is not straight-forward BPMN 2.0b1 open
BPMN21-14 PartnerRole underspecified and misnamed BPMN 2.0b1 open
BPMN21-46 Provide example: Basic gateway examples BPMN 2.0b1 open
BPMN21-4 Depiction of diagram fragments BPMN 2.0b1 open
BPMN21-26 optional source and target refs for data association BPMN 2.0b1 open
BPMN21-61 Section 10.5 Text duplicated from 8.3.10 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-3 Page 046, Section 7.2, Message not listed as a BPMN element 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-55 Define "Pool" 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-35 Section 14.2.2 Activity (semantics): BPMN 2.0b1 open
BPMN21-11 Message flow to/from events in Collaboration diagrams BPMN 2.0b1 open
BPMN21-18 Event-based gateways in choreography should be exclusive BPMN 2.0b1 open
BPMN21-5 Page 070, section 8 list of Core elements BPMN 2.0b1 open
BPMN21-22 Beta 1 Section 15.1.2 Sub-Process Mappings: Table referenced is missing BPMN 2.0b1 open
BPMN21-25 Beta 1: Section 17 BPMN Example: Include full BPMN example for this section BPMN 2.0b1 open
BPMN21-63 Link Events - Constraints and Usage not clearly documented BPMN 2.0b1 open
BPMN21-13 CorrelationClassDiagram missing conversation association end name BPMN 2.0b1 open
BPMN21-7 This is a style suggestion to make diagrams clearer BPMN 2.0b1 open
BPMN21-27 Multiple processes per participant BPMN 2.0b1 open
BPMN21-32 Notation for alternaitve data input/output sets BPMN 2.0b1 open
BPMN21-43 Provide example: Conversation View BPMN 2.0b1 open
BPMN21-59 More description for "Process as a callable element" BPMN 2.0b1 open
BPMN21-17 Multiple senders after event-based gateway in choreography 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-31 Exclusive Gateway Choreography Rule too Restrictive, starting new process BPMN 2.0b1 open
BPMN21-54 Correlation across conversations BPMN 2.0b1 open
BPMN21-12 Gateways in Choreography missing split or merge BPMN 2.0b1 open
BPMN21-1 Allow a Process to be Ad Hoc (in addition to 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-52 Section 9 Collaboration [Choreography; Specification, Metamodel]: BPMN 2.0b1 open
BPMN21-48 Provide example: Basic process structure BPMN 2.0b1 open
BPMN21-6 Page 251, Start Event on the boundary of a sub-process BPMN 2.0b1 open
BPMN21-39 [Chroeography] Complete section 11.4: Events BPMN 2.0b1 open
BPMN21-64 Continue versus terminate in loop BPMN 2.0b1 open
BPMN21-8 Add a User Event 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-19 Parallel Gateway participants BPMN 2.0b1 open

Issues Descriptions

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

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

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

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

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

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

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

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

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

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

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

Wrong document reference in dtc/2010-06-02


Inconsistent Naming of Multi-instance Activity

  • Key: BPMN21-336
  • Legacy Issue Number: 18143
  • Status: open  
  • Source: Camunda Services GmbH ( 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

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

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

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

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

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

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

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

Title of Figure 10.66 grammatically wrong

  • Key: BPMN21-302
  • Legacy Issue Number: 16159
  • Status: open  
  • Source: Camunda Services GmbH ( 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

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

An invalid statement regarding Black Box depiction of pools

  • Key: BPMN21-356
  • Legacy Issue Number: 19068
  • Status: open  
  • Source: Trisotech ( 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

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

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

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

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

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

Meaning of 'behavior' attribute on MultiInstanceLoopCharacteristics quite confusing

  • Key: BPMN21-276
  • Legacy Issue Number: 15911
  • Status: open  
  • Source: Fraunhofer FOKUS ( 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

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

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

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

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

Title of Figure 10.122 doesn't match its contents

  • Key: BPMN21-317
  • Legacy Issue Number: 16903
  • Status: open  
  • Source: Camunda Services GmbH ( 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

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

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

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

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

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

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

Section 10.3.4 Human Performer is not peorperly defined for implementation interpretation

  • Key: BPMN21-366
  • Legacy Issue Number: 19461
  • Status: open  
  • Source: Trisotech ( 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

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

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

The XSLT for transforming to BPMN XMI has errors

  • Key: BPMN21-291
  • Legacy Issue Number: 16011
  • Status: open  
  • Source: Adaptive ( 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

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

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

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

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

XML Schema not valid


[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

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

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

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

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

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

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

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

Reference omitted in BPMN 2 11-01-03

  • Key: BPMN21-327
  • Legacy Issue Number: 17069
  • Status: open  
  • Source: Object Management Group ( Jon 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

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

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

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

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

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

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

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

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

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

Section 3.3 BPEL4People


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

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

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

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

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

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

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

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 ( Jon 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

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

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

Some BPEL4People links are dead


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

Artifact used as an example for FlowElement

  • Key: BPMN21-371
  • Legacy Issue Number: 19614
  • Status: open  
  • Source: W4 ( 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: 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

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

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

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

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

Editorial: Wrong description of Figure 10.79 in the text

  • Key: BPMN21-355
  • Legacy Issue Number: 18981
  • Status: open  
  • Source: Camunda Services GmbH ( 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

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

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

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

Incorrect Section References

  • Key: BPMN21-288
  • Legacy Issue Number: 15992
  • Status: open  
  • Source: BPM Advantage Consulting ( 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

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

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

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

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

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

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

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

Can Event Sub-Processes Loop?

  • Key: BPMN21-300
  • Legacy Issue Number: 16102
  • Status: open  
  • Source: BPM Advantage Consulting ( 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

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 ( Jon 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

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

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

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

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

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

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

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

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

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

Figure 10.30 is incorrect

  • Key: BPMN21-202
  • Legacy Issue Number: 15601
  • Status: open  
  • Source: BPM Advantage Consulting ( 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

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

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

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

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

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

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

Figure 10.98 needs Updating

  • Key: BPMN21-95
  • Legacy Issue Number: 15407
  • Status: open  
  • Source: BPM Advantage Consulting ( 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 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

Choreography activities sharing message flow

  • Key: BPMN21-80
  • Legacy Issue Number: 15159
  • Status: open  
  • Source: BPM Advantage Consulting ( 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

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

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

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

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

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

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

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

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

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

Clarify Relationship between Collabration Message Flow and Choreography Tasks

  • Key: BPMN21-86
  • Legacy Issue Number: 15284
  • Status: open  
  • Source: BPM Advantage Consulting ( 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

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

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

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

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

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

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

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

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

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: Fri, 6 Mar 2015 20:57 GMT

Notation for shared correlation properties

  • Key: BPMN21-75
  • Legacy Issue Number: 15070
  • Status: open  
  • Source: NIST ( 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

Add Brief Description for Error and Escalation Event Definitions

  • Key: BPMN21-66
  • Legacy Issue Number: 14854
  • Status: open  
  • Source: BPM Advantage Consulting ( 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

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

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

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

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

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

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

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

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

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

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

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

Ambiguous statements about Sequence Flow

  • Key: BPMN21-70
  • Legacy Issue Number: 15030
  • Status: open  
  • Source: BPM Advantage Consulting ( 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Redundancy in specifying data in processes

  • Key: BPMN21-72
  • Legacy Issue Number: 15054
  • Status: open  
  • Source: International Business Machines ( 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

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

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

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

Typo: "Interrupting" should be "Non-Interrupting"

  • Key: BPMN21-96
  • Legacy Issue Number: 15408
  • Status: open  
  • Source: BPM Advantage Consulting ( 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

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

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

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

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

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

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

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

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

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

Define rules for placement of multiple activity markers

  • Key: BPMN21-84
  • Legacy Issue Number: 15255
  • Status: open  
  • Source: BPM Advantage Consulting ( 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

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

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

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

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

Data associations need to be revisited and their use clarified.

  • Key: BPMN21-83
  • Legacy Issue Number: 15253
  • Status: open  
  • Source: Trisotech ( 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

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 …”