Business Process Model and Notation Avatar
  1. OMG Specification

Business Process Model and Notation — Open Issues

  • Acronym: BPMN
  • Issues Count: 448
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

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

Issues Descriptions

Ad-Hoc Sub-Process falsely listed as

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

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

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

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

second instance of

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

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

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

Mistake in Table 7.2

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

    I found a mistake in the BPMN 2.0.2 specification.

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

    On Page 37:

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

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

    The corrected form is the following:

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

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

Wrong word used. And wrong page reference

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

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

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

    It is here:

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

    Also on page 163.

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

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

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

fairly basic errors in some of your example flows

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

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

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

Description for "Mutiple Instances" is not correct.

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

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

    Thanks in advance.
    Carlos Biscione - Oracle Colombia.

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

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

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

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

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

No correct validation rules mentioned

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

    Dear Team

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

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

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

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

    Kind regards

    Dieter Proost

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

Clarify the possible catchers of error and escalation events

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

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

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

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

wrong word for parallel multi instance in description

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

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

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

    Best regards, Jan

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

Mismatch between text and table

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

    Text:

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

    Table on Page 259:

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

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

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

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

    Section 10.5.2 on page 238 states:

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

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

    2. Bug:

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

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

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

    Solution:

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

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

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

    3. Related Improvement:

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

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

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

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

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

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

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

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

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

Page directs you to see itself

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

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

    It should refer to Section 13.3.3, page 435.

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

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

Addition of Blockchain Element

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

    Hello,

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

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

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

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

    In Table 8.52 the specification says:

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

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

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

Incorrect description of inheritance

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

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

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

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

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

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

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

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

    Thank you very much for any clarification

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

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

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

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

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

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

    Thank you very much for your help
    sincerly yours

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

Event list seems to be not complete

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

    On p. 241 is written:

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

    and on p. 174:

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

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

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

Misprint in call activity view

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

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

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

Different explanation and example.

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

    Example about figure 6.52 shows not about driver`s story

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

Example uses invalid DI attributes and wrong namespaces

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

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

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

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

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

Pages 312-457. Nonexistent attribute “compensable” mentioned

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

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

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

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

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

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

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

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

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

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

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

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

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

    But on page 225, the following is stated:

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

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

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

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

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

Inclusive Gateway - circular cross-reference

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

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

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

    Obviously, we are on page 292 already.

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

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

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

Typo: Sequential for Parallel

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

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

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

Typo: Outgoing for Incoming

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

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

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

"Flow Object" should be "Flow Node"

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

    The specification says in the (non normative) glossary:

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

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

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

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

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

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

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

Typo:

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

    Section 12.1.1 includes the text "miss-interpretations"

    The correct spelling is "misinterpretations"

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

Typo in example

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

    Section 6.1.1 includes this bullet point on conventions:

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

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

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

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

Diagram 8.1 looks amateurish

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

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

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

Wrong sub-section reference numbers

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

    The third paragraph of section 2.1 says:

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

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

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

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

tDefinitions should have an extensionElements Element like in CMOF BaseElement

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

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

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

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

Inconsistent BPMNShape Attributes in tables

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

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

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

Typos - Incorrect internal references/pointers

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

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

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

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

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

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

Inconsistent semantics of multiple none start events

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

    The specification says:

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

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

    Further down it says however:

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

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

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

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

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

    Suggestion
    Change the above sentence

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

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

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

    and

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

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

Attribute called

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

    The text today reads:

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

    I believe it should be:

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

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

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

Relationship relates CMOF::Element, not Artifact

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

    The specification says about External Relationships:

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

    The following text then refers consistently to BPMN Artifacts.

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

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

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

    should probably read

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

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

Unclear how to add new Artifact Types

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

    The specification says about Extension:

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

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

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

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

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

Derivation of categorizedFlowElements is only given by visual nesting

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

    The specification says:

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

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

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

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

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

Artifact used as an example for FlowElement

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

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

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

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

Page 72. Artifact incorrectly identified as a Flow Element

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

    Table 8.23. Row “categorizedFlowElements”

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

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

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

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

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

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

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

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

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

Incorrect table column header

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

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

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

Add start and intermediate events of type "User"

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

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

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

Outgoing sequence flows from event gateways should allow conditional expressions

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

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

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

Probable contradiction: Implicit compensation and Throwing Compensation Events

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

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

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

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

    This probably is not intended.

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

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

Define "Cancellation" more precisely

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

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

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

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

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

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

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

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

Intermediate Compensation Events can have outgoing Sequence Flows

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

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

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

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

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

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

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

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

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

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

Execution semantics of Activity with conditional outgoing Sequence Flows

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

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

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

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

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

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

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

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

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

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

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

Inconsistent default value of dataStore/@isUnlimited

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

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

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

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

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

Clarification needed regarding converging exclusive gateway and slash marker

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

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

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

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

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

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

Task Description -- Internal Conflict

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

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

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

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

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

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

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

Missing Element in BPMN 2.0.2 ?

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

    I refer to BPMN Spec. Version 2.0.2.

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

    in Spec. chapter 7.3.1 or 7.3.2.

    What happened with this element ??

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

Sequential and Parallel multiple instances are have same description

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

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

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

    This should read as

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

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

data storage element is missing in overview

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

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

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

Confusion over dataOutput attributes

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

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

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

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

Multiple Instances - Both types of diagram described as Sequential

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

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

    Text copied belowL

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

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

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

Unclear execution semantics of MI activities with complex behavior

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

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

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

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

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

Table 8.51 ref error

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

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

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

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

Wrong table reference number

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

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

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

    The correct Table numbers should be:

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

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

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

    p.206 states:

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

    p.368 states:

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

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

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

Wrong table reference number

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

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

    should be:

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

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

Wrong table reference number

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

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

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

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

Wrong table reference number

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

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

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

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

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

Wrong name of object

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

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

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

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

Attribute name "error" should actually by "errorRef"

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

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

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

Figure 10.57 does not show that InputOutputSpecification derives from BaseElement

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

    Figure 10.57 does not show that InputOutputSpecification derives from BaseElement.

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

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

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

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

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

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

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

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

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

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

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

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

Wrong clause reference

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

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

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

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

Table 7.2 wrong reference to type of multi-instance

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

    In table 7.2, page 37 it's written:

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

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

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

Page 29, Section 7.2.2 - Fork and Join Differentiation

  • Key: BPMN21-376
  • Legacy Issue Number: 14349
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    BPMN says that you use a parallel gateway (diamond with a plus in it) to start a sequence of parallel paths, and another AND gateway to end it. The behaviors of these two gateways are different, but they look the same. Suggestion is that the first AND gateway, that starts the parallel split have a thin line, while the gateway at the end which actually waits for multiple inputs will have a thick line. This corresponds to the thin and thick lines around start and end nodes.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Typo: Data Object spelled Objec

  • Key: BPMN21-372
  • Legacy Issue Number: 19666
  • Status: open  
  • Source: gmail.com ( William Lopez Campo)
  • Summary:

    In the image of Table 7.2 for Data Object, next to the Data Object (Collection) it reads Data Objec (Collection).

  • Reported: BPMN 2.0 — Fri, 28 Nov 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

word catalogue in the Figure 5.3: Order Fulfillment

  • Key: BPMN21-370
  • Legacy Issue Number: 19600
  • Status: open  
  • Source: Anonymous
  • Summary:

    I found a tiny error in the document which is titled as
    dtc-10-06-02.pdf (BPMN 2.0 by Example Version 1.0) i hope you'll
    correct it.

    the error is in the word catalogue in the Figure 5.3: Order Fulfillment

  • Reported: BPMN 2.0 — Mon, 15 Sep 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing event marker in Figure 10.30

  • Key: BPMN21-369
  • Legacy Issue Number: 19473
  • Status: open  
  • Source: omninet.de ( Frank Munkert)
  • Summary:

    The specification says: "If the Event Sub-Process is collapsed, then its Start Event will be used as a marker in the upper left
    corner of the shape (see Figure 10.30)."

    But the referenced figure does not show any marker event. Therefore, either the text or the figure is wrong.

  • Reported: BPMN 2.0.2 — Mon, 16 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

figure 13.1

  • Key: BPMN21-368
  • Legacy Issue Number: 19471
  • Status: open  
  • Source: Anonymous
  • Summary:

    I may be wrong but I assume figure 13.1 is wrong

  • Reported: BPMN 2.0 — Sun, 15 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bug p385

  • Key: BPMN21-367
  • Legacy Issue Number: 19470
  • Status: open  
  • Source: Anonymous
  • Summary:

    ??

    I found a problem in illustration 11.43 (p385 of pdf & p355 of norm) . The message flow between participant A & participant B is not well definied. Direction need to be change (from participant B to participant A & not from A to B).
    It's the same for figure 11.45 (message flow from participant B to participant A and not from participant A to participant B)

    ??

  • Reported: BPMN 2.0 — Sat, 14 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.3.4 Human Performer is not peorperly defined for implementation interpretation

  • Key: BPMN21-366
  • Legacy Issue Number: 19461
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    It is not specifically stated in the spec whether "HumaPerformer" is an abstract class.
    It seems to be, but then the meta model (fig 10.23) depicts only one specialization namely "PotentialOwner" leaving in question the need for this abstraction.
    Furthermore "PotentialOwner" only

  • Reported: BPMN 2.0.2 — Wed, 11 Jun 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

bug issue concerning event-based gateway illustration 10.98

  • Key: BPMN21-365
  • Legacy Issue Number: 19414
  • Status: open  
  • Source: Anonymous
  • Summary:

    Figure 10.98 need another type of gateway.

    This gateway is not correct because it is lauching process activity.

    It would be correct with a complex start event within gateway (not an intermediate as it is).

  • Reported: BPMN 2.0 — Tue, 13 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

bug issue concerning event-based gateway

  • Key: BPMN21-364
  • Legacy Issue Number: 19413
  • Status: open  
  • Source: Anonymous
  • Summary:

    I read BPMN 2.0.2 specification and I found a mistake on a table (I think):

    P329 of PDF or p299 of BPMN specification :

    The attribute can only be set to parallel when the instantiate attribute is set to true.

    I assume its wrong. A better sentence would be :

    The attribute can only be set to parallel when the instantiate attribute is set to false.

    Am I correct ?

  • Reported: BPMN 2.0 — Tue, 13 May 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

[BPMN 2.0.2] bug issue concerning event sub process

  • Key: BPMN21-363
  • Legacy Issue Number: 19352
  • Status: open  
  • Source: Anonymous
  • Summary:

    I read BPMN 2.0.2 specification and I found a mistake on an illustration??(I think):

    p174 (205 of PDF) ??:

    If the Event Sub-Process is collapsed, then its Start Event will be used as a marker in the upper left corner of the shape (see Figure 10.30).

    P175

    There is no marker in the upper left corner of the collapsed event sub-process

  • Reported: BPMN 2.0 — Tue, 22 Apr 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sequencing rule for Choreography activities causes ambiguous execution semantics?

  • Key: BPMN21-362
  • Legacy Issue Number: 19318
  • Status: open  
  • Source: planet.nl ( kwantes)
  • Summary:

    (p.336 The basic rule of Choreography Activity sequencing is this: ?The Initiator of a Choreography Activity MUST have been involved (as Initiator or Receiver) in the previous Choreography Activity.
    As far as I can tell this rule seems to imply some ambiguity as to the execution semantics of the Choreography diagram. To explain this, I give an example of two different Choreography designs of one and the same collaboration:
    Design version 1 involves 5 message exchanges , three choreography activities A, B and C and 4 participants, 1,2,3 and 4. The activities are listed below in execution order :
    1. Activity A :
    1.1. 1 sends message to 2
    2. Activity B:
    2.1. 3 sends message to 2
    2.2. 2 sends message to 4
    2.3. 4 returns message to 2
    3. Activity C:
    3.1. 2 sends confirmation of message sent by 1 (in 1.1.)

    Design version 2 involves the same 5 message exchanges into two choreography activities A and B involving the same 4 participants listed below in execution order:
    1. Activity A :
    1.1. 1 sends message to 2
    1.2. 2 sends confirmation of message sent by 1 (in 1.1., but after receiving message sent by 4 in 2.3.)
    2. Activity B:
    2.1. 3 sends message to 2
    2.2. 2 sends message to 4
    2.3. 4 returns message to 2

    {Question 1: are observations below correct or not? }

    Both designs seem to meet the criterion mentioned in the BPMN standard specification mentioned in the first paragraph above. The second has the advantage that the message exchanges 1.1. and 1.2. which are logically strongly related are combined in one activity. But the execution semantics implied by the two designs are quite different. The first design implies that an activity can only start after completion of the previous activity. The second design implies that an activity can only start after the previous activity has started. The basic rule of Choreography Activity sequencing seems to allow both interpretations.

    {Question 2: is the issue below a valid point in your opinion ? }

    If the first interpretation is chosen, then there is the question what is meant by “completion”. That might mean different things for the sender and receiver of the last message exchanged. The sender is finished when he sent the last message. The receiver might first need to do some internal processing before it is completed. So this interpretation runs the risk of being ambiguous.

    {Question 3: can you please comment on this ? }

    The second interpretation could make it less straightforward to understand the ordering of activities from the diagram. On the other hand it does allow more room for combining logically related message exchanges in one activity (as 1.1. and 1.2. in activity A in the second interpretation). This raises the general question on how the Choreography diagrams and Conversation diagrams are conceptually related. They seem to be addressing a similar requirement for expressing communication between Business actors, but it is unclear how they are or should be related.

  • Reported: BPMN 2.0 — Sun, 30 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Allowable start events for event sub-process inconsistently defined

  • Key: BPMN21-359
  • Legacy Issue Number: 19166
  • Status: open  
  • Source: outlook.com ( Devin Fensterheim)
  • Summary:

    There is an apparent conflict in the specification concerning the permissible Start Event types for an Event Sub-Process.

    On Page 174, the specification states: "The Start Event of an Event Sub-Process MUST have a defined trigger. The Start Event trigger (EventDefinition) MUST be from the following types: Message, Error, Escalation, Compensation, Conditional, Signal, and Multiple." This enumeration excludes the Timer and Parallel event types.

    This specification appears inconsistent with the restriction on Page 241, which additionally allows Timer and Parallel event types for the Start Event: "A Start Event can also initiate an inline Event Sub-Process (see page 174). In that case, the same Event types as for boundary Events are allowed (see Table 10.86), namely: Message, Timer, Escalation, Error, Compensation, Conditional, Signal, Multiple, and Parallel."

    It is consequently unclear whether Timer and Parallel events may be the Start Event in an Event Sub-Process.

  • Reported: BPMN 2.0.1 — Mon, 23 Dec 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

References to invalid sub clauses (incorrect sub clause numbers)

  • Key: BPMN21-358
  • Legacy Issue Number: 19092
  • Status: open  
  • Source: RealDolmen NV ( Steve van den Buys)
  • Summary:

    In chapter 2, sub clause 2.1, page 1 it is written that "Process Modeling Conformance type SHALL comply with all of the requirements set forth in sub clause 2.1". However, the requirements are set forth in sub clause 2.2. Also, the sentences after that refer to sub clauses 2.2, 2.3 and 2.4 but these should refer to 2.3, 2.4 and 2.5.

    In short: references to the requirements for the different conformance types should be to 2.2, 2.3, 2.4 and 2.5 and not 2.1, 2.2, 2.3 and 2.4.

  • Reported: BPMN 2.0.1 — Mon, 18 Nov 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Invalid use of MAY NOT keyword

  • Key: BPMN21-361
  • Legacy Issue Number: 19196
  • Status: open  
  • Source: omninet.de ( Frank Munkert)
  • Summary:

    In several occasions, the BPMN 2.0.1 specification uses the keywords "MAY NOT". This keywords, however, are not valid according to RFC 2119.

    Probably "MUST NOT" would be correct. (Please note: the opposite of "MAY" is not "MAY NOT"!)

  • Reported: BPMN 2.0.1 — Tue, 28 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong sub clauses are referenced

  • Key: BPMN21-360
  • Legacy Issue Number: 19176
  • Status: open  
  • Source: me.com ( Jonas Geißer)
  • Summary:

    Version 2.0.1 is still referring to the sub clauses 2.1-2.4 (as in Version 2.0) even though they have changed to 2.2-2.5

  • Reported: BPMN 2.0.1 — Tue, 7 Jan 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

major error in figures for corresponding diagrams

  • Key: BPMN21-278
  • Legacy Issue Number: 15955
  • Status: open  
  • Source: camunda services GmbH ( Matthias Schrepfer)
  • Summary:

    In the choreography diagram in figure 11.42 Participant B sends a message to Participant A.

    Figure 11.43 is the corresponding collaboration view. However, here Participant A sends a message to Participant B... Following, both figures are not equal, 11.43 is not the corresponding figure to 11.42...

    The same error occurs for figures 11.45 and 11.44

  • Reported: BPMN 2.0 — Fri, 14 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

conversion of choreographies to collaboration diagrams

  • Key: BPMN21-277
  • Legacy Issue Number: 15954
  • Status: open  
  • Source: camunda services GmbH ( Matthias Schrepfer)
  • Summary:

    The XOR-Gateways in choreographies are defined. Also the conversion of choreographies with XORs to collaboration diagrams is described, however there are two issues for the conversion.

    1st) The description in the specification states that event-based gateways should be used in collaboration. Figure 11.37 which depicts the example collaboration does not have any event-based gateway. So, please adapt the figure and show event-based gateways as following the description

    2nd) if event-based gateways are used, then a time-out can occur.. on page 361 this likely time-out is mentioned... Please update the section on p359 accordingly to inform and consult the reader.

  • Reported: BPMN 2.0 — Fri, 14 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

number of start events for sub-processes

  • Key: BPMN21-282
  • Legacy Issue Number: 15959
  • Status: open  
  • Source: camunda services GmbH ( Matthias Schrepfer)
  • Summary:

    The specification defines that the type for start-events of sub-processes can only be the none-type... However, the allowed number of start events for sub-processes is not mentioned... at least I couldn't find it throughout the whole specification.

    As far as I understood BPMN, two none-typed start-events in sub-processes would not make sense but the point should clearly be described in a specification.

  • Reported: BPMN 2.0 — Fri, 14 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

enumeration missing

  • Key: BPMN21-281
  • Legacy Issue Number: 15958
  • Status: open  
  • Source: camunda services GmbH ( Matthias Schrepfer)
  • Summary:

    On page the call activity is explained. In the enumeration starting with "If the Call Activity calls a Process, then there are two (2) options:........" there is only option displayed.
    The second option is not shown as enumeration but with pure text. The text for the second option is "If the details of the called Process are available, then the shape of the Call Activity will be the same as a expanded
    Sub-Process, but the boundary of the shape MUST have a thick line (see Figure 10.41)."

    Please update the enumeration

  • Reported: BPMN 2.0 — Fri, 14 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CallChoreographyActivity notation for called participants

  • Key: BPMN21-290
  • Legacy Issue Number: 16009
  • Status: open  
  • Source: University of Bamberg ( Andreas Schörger)
  • Summary:

    The notation for CallChoreographyActivity
    should show which of the caller's participants
    (the ones in the bands) are associated with
    which called participants by participant
    associations. Perhaps this could be shown in
    the bands. Compare to the notation for
    participant associations in the
    CallConversation notation Figure 9.30
    (Call Conversation Links).

  • Reported: BPMN 2.0 — Mon, 7 Feb 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incoming/Outgoing Data Associations of DataInputs/Outputs

  • Key: BPMN21-289
  • Legacy Issue Number: 16003
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to page 213:
    Data Inputs MAY have incoming Data Associations

    and page 215:
    Data Outputs MAY have outgoing DataAssociations

    I think that it should be the other way round. A Data Input should have an outgoing Data Association and a Data Output should have an incoming DataAssociation. This would correspond with Figure 7.8. The Data Input "Part Requisition" only has an outgoing Data Association and vice versa, the Data Output "Part Requisition" only has an incoming Data Association.

  • Reported: BPMN 2.0 — Wed, 2 Feb 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Cardinality of id in BaseElement

  • Key: BPMN21-286
  • Legacy Issue Number: 15974
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to Table 8.5 the id of BaseElement is of type string, and since no cardinality is specified, the cardinality is assumed to be [1]. However, according to the corresponding text:
    If the element is not currently referenced and is never intended to be referenced, the id MAY be omitted.

    If the id can be omitted, then the cardinality should be [0..1].

  • Reported: BPMN 2.0 — Thu, 20 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Relationship from Choreography to Artifacts

  • Key: BPMN21-285
  • Legacy Issue Number: 15973
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to Figure 8.8, Process and Sub-Process as well as Collaboration and Sub-Choreography have a relationship to artifacts. However, Choreography is missing.

    In the text above, Choreography is mentioned:
    When an Artifact is defined it is contained within a Collaboration or a FlowElementsContainer (a Process or Choreography).

    Furthermore, section 11.3.2 specifies:
    Both Text Annotations and Groups can be used within Choreographies and all BPMN diagrams. There are no restrictions on their use.

  • Reported: BPMN 2.0 — Thu, 20 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect Section References

  • Key: BPMN21-288
  • Legacy Issue Number: 15992
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Section 2.2.1 refers to Chapter 14 (Execution Semantics). But this chapter is actually Chapter 13.
    Section 2.3 refers to Chapter 15 (BPEL Mapping). But this chapter is actually Chapter 14.
    These references should be fixed.

  • Reported: BPMN 2.0 — Thu, 27 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong document reference in dtc/2010-06-02


Procedure not defined

  • Key: BPMN21-292
  • Legacy Issue Number: 16049
  • Status: open  
  • Source: Telstra Coorporation ( John Raper)
  • Summary:

    The word procedure(s) is used 4 times in the document. It is not defined anywhere. Surely all instances of procedure should read "process".
    Otherwise it would be consistent to provide a definition of Procedure in Annex C

  • Reported: BPMN 2.0 — Thu, 10 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The XSLT for transforming to BPMN XMI has errors

  • Key: BPMN21-291
  • Legacy Issue Number: 16011
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The XSLT for transforming to BPMN XMI has errors.

    There are many places where XML attributes are output after child elements which causes Saxon at least to fail the transformation.

    Also, although not a fatal error, the XML namespaces for the source document should be removed from the target document.

    I have updated the file so that it works for me – and can make it available.

  • Reported: BPMN 2.0 — Mon, 7 Feb 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Content of Section missing

  • Key: BPMN21-280
  • Legacy Issue Number: 15957
  • Status: open  
  • Source: camunda services GmbH ( Matthias Schrepfer)
  • Summary:

    Just before Section 11.8 XML Schema for choreography there are two headings named "Choreography Task in Combined View" and "Sub-Choreography in Combined View". However, there is no content or description shown.

    Please update the sections with their content.

  • Reported: BPMN 2.0 — Fri, 14 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong diagram

  • Key: BPMN21-279
  • Legacy Issue Number: 15956
  • Status: open  
  • Source: camunda services GmbH ( Matthias Schrepfer)
  • Summary:

    In figure 11.47 the pool Participant B contains a parallel gateway. The parallel gateway is named with a decision and the answers as a XOR-gateway should be named.

    Please remove this description to follow the semantics of the parallel gateway

  • Reported: BPMN 2.0 — Fri, 14 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Typo on page 77 (physical page 107)

  • Key: BPMN21-284
  • Legacy Issue Number: 15971
  • Status: open  
  • Source: TIBCO ( Justin Brunt)
  • Summary:

    Typo on page 77 (physical page 107) in the penultimate paragraph "atleast" should be "at least".

  • Reported: BPMN 2.0 — Tue, 18 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Typo on page 76

  • Key: BPMN21-283
  • Legacy Issue Number: 15970
  • Status: open  
  • Source: TIBCO ( Justin Brunt)
  • Summary:

    In the final line on page 76 (106 in physical document) there is a typo:
    "For each Message that is exhanged as part of a particular Conversation". The word "exchanged" is missing the letter "c".

  • Reported: BPMN 2.0 — Tue, 18 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Normal Process Not Defined

  • Key: BPMN21-294
  • Legacy Issue Number: 16052
  • Status: open  
  • Source: Telstra Coorporation ( John Raper)
  • Summary:

    The term "normal Process" is used three times in the document, but it is not defined anywhere

  • Reported: BPMN 2.0 — Thu, 10 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Object mispelt

  • Key: BPMN21-293
  • Legacy Issue Number: 16051
  • Status: open  
  • Source: Telstra Coorporation ( John Raper)
  • Summary:

    Change Objec to Object in the Data Object line of Table 7.2

  • Reported: BPMN 2.0 — Thu, 10 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Second occurance of sequential Multi-Instances should be parallel

  • Key: BPMN21-374
  • Legacy Issue Number: 19709
  • Status: open  
  • Source: Anonymous
  • Summary:

    In Table 7.2 the text for Multiple Instances says the three vertical lines mean sequential MI. I believe it nust be parallel, three horizontal lines mean sequential.

  • Reported: BPMN 2.0.2 — Wed, 14 Jan 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use of per mille symbol unclear (‰)

  • Key: BPMN21-373
  • Legacy Issue Number: 19708
  • Status: open  
  • Source: Anonymous
  • Summary:

    In table 7.3 the per mille (‰) sign is used in the third column. I suspect the arrow was meant.

  • Reported: BPMN 2.0.2 — Wed, 14 Jan 2015 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Is compensation allways triggered automatically upon uncaught errors?

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

    Page 180 (PDF 210) states:
    'Note that other mechanisms for interrupting a Transaction Sub-Process will not cause compensation (e.g., Error, Timer, and anything for a non-Transaction Activity).'

    Whereas page 305 (PDF 335) states:
    'If no error Event Sub-Process is specified for a particular Sub-Process and a particular error, the default behavior is to automatically call compensation for all contained Activities of that Sub-Process if that error is thrown, ensuring the behavior for auditing and monitoring.'

    These statements seem contradicting to me and therefore I'd like to get a clarification on the following questions:

    1. Is compensation allways triggered automatically upon uncaught errors?
    2. Is there a difference between compensation of a Transaction Sub-Process and any other Sub-Process?

  • Reported: BPMN 2.0 — Wed, 14 Dec 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN typo

  • Key: BPMN21-354
  • Legacy Issue Number: 18906
  • Status: open  
  • Source: yahoo.com ( Muhammad Saleem)
  • Summary:

    There is typo error of the word "variation". It is written as "va riation" in the document

  • Reported: BPMN 2.0 — Thu, 12 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Extend BPMN with a element that subclasses an existing BPMN element

  • Key: BPMN21-353
  • Legacy Issue Number: 18787
  • Status: open  
  • Source: Perceptive Software ( Mark van Roermund)
  • Summary:

    'Section 8.2.3 Extensibility' on page 57 of the BPMN 2.0 specification states:

    "The BPMN metamodel is aimed to be extensible. This allows BPMN adopters to extend the specified metamodel in a way that allows them to be still BPMN-compliant."

    On page 58 it is stated that:

    "Every BPMN element which subclasses the BPMN BaseElement can be extended by additional attributes. This works by associating a BPMN element with an ExtensionDefinition, which was defined at the BPMN model definitions level (element Definitions)."

    Question:
    Is it possible to extend BPMN with an element that subclasses an existing BPMN element?

    For example, is it possible to extend BPMN with a new task element that subclasses the BPMN Task, similar to how e.g. a ManualTask or UserTask subclasses the BPMN Task? If this is possible, could you provide an example?

  • Reported: BPMN 2.0 — Tue, 2 Jul 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

An invalid statement regarding Black Box depiction of pools

  • Key: BPMN21-356
  • Legacy Issue Number: 19068
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    In section 9.2
    First paragraph
    3rd bullet should be removed.
    It states
    "If the Pool is a black box (i.e., does not contain a Process), then the label for the Pool MAY be placed
    anywhere within the Pool without a single line separator."

    This is incorrect a pool always has a line separating the label. This is how one can visually distinguish between a pool and a a lane.

    All depictions in examples were corrected during FTF but this one line stayed behind and should be removed.

  • Reported: BPMN 2.0 — Wed, 6 Nov 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Editorial: Wrong description of Figure 10.79 in the text

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

    There is a Copy & Paste typo on page 265 (PDF 295).

    Text: "Figure 10.79 shows the variations of Conditional Events"
    Figure Caption: "Figure 10.79 ­ Error Events"

    Proposal:
    Change text to "Figure 10.79 shows the variations of Error Events"

  • Reported: BPMN 2.0 — Mon, 30 Sep 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Suspected definition error in DataObject.isCollection

  • Key: BPMN21-357
  • Legacy Issue Number: 19083
  • Status: open  
  • Source: Atom Software Pty Ltd ( Paul Hopkins)
  • Summary:

    In Table 10.52 the description of DataObject.IsCollection reads "If an itemDefinition is referenced, then this attribute MUST have the same value as the IsCollection attribute of the referenced itemDefinition".

    This description prevents BPMN from defining a collection of DataObjects on a single Item Aware Element referred to by an Item Definition. Therefore, if I wish to model an individual item X and a collection of item X they need to reference different item definitions - surely this is not the intent.

    I propose rewording this sentence to read "If a referenced itemDefinitions isCollection attribute is set to true, then this attribute MUST also be set to true".

    I don't know if there is a flow-on effect to other areas of the documentation.

  • Reported: BPMN 2.0.1 — Thu, 14 Nov 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Repeated use of previous definition for conflicting task attributes

  • Key: BPMN21-352
  • Legacy Issue Number: 18501
  • Status: open  
  • Source: googlemail.com ( Neil Glover)
  • Summary:

    Table 7.2 - BPMN Extended Modeling Elements

    Multiple Instances

    Definition of the use of vertical lines as a task attribute is incorrectly captured as the same as horizontal, as follows:

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

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

    This should read as follows:

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

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

  • Reported: BPMN 2.0 — Tue, 26 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Entire document

  • Key: BPMN21-351
  • Legacy Issue Number: 18403
  • Status: open  
  • Source: Anonymous
  • Summary:

    The OMG BPMN 2 Revision Task force is working to resolve editorial and clarification issues against the text in DIS 19510. It is important that the corrections resolving these defects be reflected in the published ISO/IEC Standard for OCL. The editing group for ISO/IEC DIS 19510 should consider all changes against the text of BPMN 2, resulting from the latest minor revision to BPMN 2 available at the time of the ballot resolution meeting

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Title

  • Key: BPMN21-350
  • Legacy Issue Number: 18402
  • Status: open  
  • Source: Anonymous
  • Summary:

    Spelling error in the title, OMG BMPN should be OMG BPMN

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 7.6

  • Key: BPMN21-346
  • Legacy Issue Number: 18398
  • Status: open  
  • Source: Anonymous
  • Summary:

    This section is informative. Remove this section or move to informative section.

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 3.3 BPEL4People


Section 8.3.4

  • Key: BPMN21-348
  • Legacy Issue Number: 18400
  • Status: open  
  • Source: Anonymous
  • Summary:

    There are a lot of ‘ enclosed string, such as, ‘identity/relationship’. It seems to be meaningless. On page 83, there are “happens” and “event”. Remove “‘”.

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 8.1 Figure 8.2

  • Key: BPMN21-347
  • Legacy Issue Number: 18399
  • Status: open  
  • Source: Anonymous
  • Summary:

    There is an explanation of “infrastructure” following section and figure 8.1. However, there isn’t the package infrastructure on the package diagram on Figure 8.2. Is it O.K.? Clarify this

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 3.2 Normative

  • Key: BPMN21-344
  • Legacy Issue Number: 18396
  • Status: open  
  • Source: Anonymous
  • Summary:

    This document uses “Element”, the MOF element on the Figure 8.7. Therefore, MOF is normative reference. Add the MOF as normative reference

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Typo in section 8.4

  • Key: BPMN21-349
  • Legacy Issue Number: 18401
  • Status: open  
  • Source: Anonymous
  • Summary:

    suc clauses ? typo sub clauses

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Revision & clarification for interruption of looping / multi-instance sub-processes

  • Key: BPMN21-333
  • Legacy Issue Number: 17528
  • Status: open  
  • Source: gmail.com ( Andre Gomes da Silva)
  • Summary:

    In Table 10.88 ­ End Event Types (page 248) it’s written:

    “Terminate ­ This type of End indicates that all Activities in the Process should be immediately ended. This includes all instances of multi-instances.”

    However, in 13.4.6 ­ End Events (page 443) it’s written:

    “For a ‘terminate’ End Event, the Sub-Process is abnormally terminated. In case of a multi-instance Sub-Process, only the affected instance is terminated—no other ongoing Sub-Process instances or higher-level Sub-Process or Process instances are affected.”

    So, it seems to be a contradiction: first it’s written all instances of multi-instances are terminated, but after it’s written only one instance is terminated.

    CLARIFICATION =============

    Since the contradiction mentioned above, I think it’s also needed to clarify how many instances are terminated when a multi-instance Sub-Process is interrupted via Boundary Event or via Event Sub-Process.

    The specification also does not mention how the interruption of a looping Sub-Process should be handled: is only the current iteration interrupted (like the “continue” statement in software programming), or the whole loop is interrupted (like the “break” statement in software programming)? So, it’s needed to clarify this behavior for interruptions triggered via terminate End Event, Boundary Events and Event Sub-Processes.

    This issue is related to Issue #14824.

  • Reported: BPMN 2.0 — Fri, 20 Jul 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong attribute name "attachedTo" for Bounday event

  • Key: BPMN21-332
  • Legacy Issue Number: 17468
  • Status: open  
  • Source: BonitaSoft S.A. ( Aurelien Pupier)
  • Summary:

    Wrong attribute name "attachedTo" for Bounday event

    It should be "attachedToRef".

  • Reported: BPMN 2.0 — Mon, 9 Jul 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Looping/Multi-instantiation description error

  • Key: BPMN21-331
  • Legacy Issue Number: 17365
  • Status: open  
  • Source: BonitaSoft ( Mickey Farrance)
  • Summary:

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

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

    The three vertical lines depict parallel multi-instantiation, not sequential...(according to page 191 of spec)

  • Reported: BPMN 2.0 — Wed, 9 May 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Travel Booking Example

  • Key: BPMN21-330
  • Legacy Issue Number: 17146
  • Status: open  
  • Source: gmail.com ( Alex Schaffer)
  • Summary:

    On page 27 of the above document there is an explanation of a Travel Booking process model.

    In the 7th paragraph, there is a statement which says "If an error arises during the booking activities, the flight and hotel room reservations are reversed and the Client record is updated. The booking is tried again as long as the booking retry limited is not exceeded."

    I believe that part of this statement may be incorrect as the client record is only updated if there is an error in the payment activity which is outside of the subprocess.

    Could you please clarify?

  • Reported: BPMN 2.0 — Mon, 20 Feb 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Association - an Artifact or a Connecting object?

  • Key: BPMN21-335
  • Legacy Issue Number: 17563
  • Status: open  
  • Source: Cardiff University ( YULIA CHERDANTSEVA)
  • Summary:

    Section 7.2 states that Association is a Connecting Object, whereas Section 8.3.1 states that Association is an Artifact.
    Could you clarify please

  • Reported: BPMN 2.0 — Thu, 23 Aug 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Significant typo in BPMN 2.0 v1.0 formal/2011-01-03

  • Key: BPMN21-334
  • Legacy Issue Number: 17548
  • Status: open  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    In the definitions of interrupting and non-interrupting events, on the page numbered 280 (which is sequential page 310 of the pdf), under the heading

    Interrupting Event Handlers (Error, Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)

    the first sentence reads, correctly –

    Interrupting Event Handlers are those that have the cancelActivity attribute is set to true.

    In the next section, under the heading

    Non-interrupting Event Handlers (Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)

    the first sentence reads, incorrectly –

    Interrupting Event Handlers are those that have the cancelActivity attribute is set to false.

    Clearly the authors meant to start this sentence with

    Non-interrupting Event Handlers are ...

    but forgot to edit in the "Non" after the copy'n'paste. Right?

  • Reported: BPMN 2.0 — Thu, 9 Aug 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong references to ItemAwareElement in UML diagram

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

    In the UML diagram "Fig. 10.51 - DataObject class diagram", it looks as if DataObject and DataObjectReference are specializations of ItemAwareElement.

    According to "10.3.4 XML Schema for Data" and according to the text above the diagram, this is not true.

    Therefore, the "specialization arrows" must be replaced by "associations" (i.e. a simple arrow head instead of a hollow triangle).

  • Reported: BPMN 2.0 — Sun, 23 Dec 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 217: Send Task Mapping, first sentence

  • Key: BPMN21-340
  • Legacy Issue Number: 18265
  • Status: open  
  • Source: NobleProg ( Bernard Szlachta)
  • Summary:

    ...there MUST be at most '''one''' outputSet...
    Receive Task Mapping
    first sentance the same missing word "one" as above
    the last sentence:
    ... is not present, the '''payload''' (is: payloard
    There are quite a few typos I discovered. Is there any easier way of submitting suggestions and small bugs?
    Is there anyway to work on the new version (so I do not bother correct errors which already have been corrected)?

  • Reported: BPMN 2.0 — Sat, 10 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

flowNodeRefs containment and subprocess clarification

  • Key: BPMN21-338
  • Legacy Issue Number: 18256
  • Status: open  
  • Source: BonitaSoft S.A. ( Aurelien Pupier)
  • Summary:

    does FlowNode that are inside a SubProcess should be listed in flowNodeRefs of a lane?

    I found no official sample for this use case but several different implementations among BPMN Tools.
    All offical samples with SubProcess have them directly in a pool so no flowNodeRefs

  • Reported: BPMN 2.0 — Fri, 9 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect wording for description, should read "parallel" instead of "sequential"

  • Key: BPMN21-337
  • Legacy Issue Number: 18246
  • Status: open  
  • Source: Sodexo ( Juan Arocha)
  • Summary:

    In Table 7.2, in the description for the Multiple Instances element, it should read
    "A set of three vertical lines will be displayed at the bottom-center of the activity for parallel Multi-Instances (see lower figure to the right)."
    instead of
    "A set of three vertical lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see lower figure to the right)."

  • Reported: BPMN 2.0 — Mon, 5 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 3.3 OMG UML

  • Key: BPMN21-343
  • Legacy Issue Number: 18395
  • Status: open  
  • Source: Anonymous
  • Summary:

    This document refers to Unified Modeling Language Specification V2.1.2. However, the ISO standard version is UML 2.4.1. If there isn’t inconsistency, this document should refer to ISO version. Besides, the semantic models use the UML class diagram. Therefore, UML is the normative reference, not non-normative reference. Move UML reference to normative section as well as check the adequate version.

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Cover Page Title

  • Key: BPMN21-342
  • Legacy Issue Number: 18394
  • Status: open  
  • Source: Anonymous
  • Summary:

    Abbreviation of “Business Process Model and Notation” is incorrect. Change “BMPN” to “BPMN”

  • Reported: BPMN 2.0 — Fri, 1 Feb 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistent Naming of Multi-instance Activity

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

    The caption of section 13.2.7 speaks about a 'Multiple Instances Activity' whereas the rest of the specification uses the term 'Multi-instance Activity'.

    Proposal:
    Rename section 13.2.7 to 'Multi-instance Activity'.

  • Reported: BPMN 2.0 — Mon, 8 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unclear meaning of "‰" symbol

  • Key: BPMN21-329
  • Legacy Issue Number: 17130
  • Status: open  
  • Source: International Olympic Committee ( Will Keenan)
  • Summary:

    In Table 7.3 - Sequence Flow Connection Rules, under the column designated by the Activity notation, there are "‰" (per mil) symbols instead of arrows. Unable to find an explanation in the document for "‰", is this an error and should it also be an arrow?

  • Reported: BPMN 2.0 — Tue, 14 Feb 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Picture doesn't correspond to the description

  • Key: BPMN21-339
  • Legacy Issue Number: 18264
  • Status: open  
  • Source: ( Bernard Szlachta)
  • Summary:

    The sentence on page 177 (207)
    If the Event Sub-Process is collapsed, then its Start Event will be used as a marker in the upper left
    corner of the shape (see Figure 10.30).
    does not seem to correspond with the picture (i.e. there is no start event)

  • Reported: BPMN 2.0 — Sat, 10 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use XPath 2.0 as default expression language instead of XPath 1.0

  • Key: BPMN21-316
  • Legacy Issue Number: 16877
  • Status: open  
  • Source: University of Bamberg ( JöLenhard)
  • Summary:

    XPath 1.0 is the default expression language in BPMN 2.0. Instead of XPath 1.0, the default expression language should be XPath 2.0 which is a W3C Recommendation since 14 December 2010 (and I assume that is why it has not made it into BPMN 2.0).

    A major problem with XPath 1.0 is its limited set of functions. For instance, XPath 1.0 does not provide any time-related functions. Consequently, it is impossible to get the current system time in an expression, which might be necessary in Timer Events, without proprietary extensions to the standard. This harms portability of process models and is especially relevant for Process Execution Conformance. XPath 2.0 provides such functions and the time-related data types used in both, BPMN 2.0 and XPath 2.0, are identical (ISO-8601).

    This change might affect several parts of the specification:
    In section 10.3.3 The usage of XPath as expression language in BPMN 2.0 is discussed. There, several additional XPath-functions are defined, mentioning deficiencies in XPath 1.0. These functions should be redefined with XPath 2.0.
    Section 14 Mapping BPMN Models to BPEL might also require changes. XPath 1.0 is the default language required by BPEL 2.0 and XPath 2.0 functions that are not present in XPath 1.0 cannot be mapped as easily.

    I would strongly recommend for BPMN 2.0 to require the support for XPath 2.0 instead of XPath 1.0 as default expression language.

  • Reported: BPMN 2.0 — Tue, 6 Dec 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

XML Schema: Usage of xsd:anyAttribute instead of xsd:attribute

  • Key: BPMN21-315
  • Legacy Issue Number: 16632
  • Status: open  
  • Source: IHK Gesellschaft fuer Informationsverarbeitung mbH ( Sven Joerges)
  • Summary:

    Table 8.3 ("Definitions XML schema") on page 54 contains the following two lines:

    <xsd:anyAttribute name="exporter" type="xsd:ID"/>
    <xsd:anyAttribute name="exporterVersion" type="xsd:ID"/>

    As the usage of the "name" attribute in combination with the "xsd:anyAttribute" element makes no sense, those lines should be changed to:

    <xsd:attribute name="exporter" type="xsd:ID"/>
    <xsd:attribute name="exporterVersion" type="xsd:ID"/>

    As the XSD-Files given at www.omg.org/spec/BPMN/2.0/ also use "xsd:attribute" for those lines, I suppose this is just a copy&paste error in the specification document.

  • Reported: BPMN 2.0 — Wed, 19 Oct 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reference omitted in BPMN 2 11-01-03

  • Key: BPMN21-327
  • Legacy Issue Number: 17069
  • Status: open  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    On page 315, after this sentence about Service Interaction Patterns -

    Message exchanges between partners go beyond simple request-response interactions into multi-cast, contingent requests, competing receives, streaming, and other service interaction patterns

    comes the cryptic phrase

    (REF for SIP)

    It looks like this is a stand-in for a Reference for Service Interaction Patterns - right?

    If so, it might be replace with a footnote referring to this Barros article -
    Service Interaction Patterns: Towards a Reference
    Framework for Service-Based Business Process
    Interconnection
    http://eprints.qut.edu.au/2295/1/ServiceInteractionPatterns.pdf

  • Reported: BPMN 2.0 — Fri, 27 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incomming sequence flow at start event

  • Key: BPMN21-326
  • Legacy Issue Number: 17047
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    An interesting rule (page 245):
    ‘A Start Event MUST NOT be a target for Sequence Flows; it MUST NOT have incoming Sequence Flows. An exception to this is when a Start Event is used in an Expanded Sub-Process and is attached to the boundary of that Sub-Process. In this case, a Sequence Flow from the higher-level Process MAY connect to that Start Event in lieu of connecting to the actual boundary of the Sub-Process.’

    I never found a tool who implements this rule. On page 261 a ‘Boundary Start event’ does not exist. Only Intermediate Events are of type ‘boundary’ (interrupting/non-interrupting). Or interrupting/non-interrupting Start Events for an Event-Sub-Process (but they are not of type ‘boundary’).

    -> is it ok to remove this exception?

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

visualization enumeration level

  • Key: BPMN21-318
  • Legacy Issue Number: 17037
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    This Document is hard to read. The enumerations begins all with a rectangle independent from their level. Particularly if
    there is a picture or a table between the enumerations.
    I think it is better to use different signs for enumeration, depending on the level in the enumeration.
    (rectangle filled, rectangle unfilled, circle filled, circle unfilled).

    I know, this fact depends on at the OMG-Template (it concerns not only the BPMN-Document, I think). Now, it´s time to change the template.

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Title of Figure 10.122 doesn't match its contents

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

    The title of Figure 10.122 on page 304 (PDF 334) is 'Monitoring Class Diagram', but the figure shows Compensation through a Compensation Event Sub-Process.

    The same title is also used for Figure 10.129, where it matches the contents. So this seems to be a copy and paste issue.

    Proposal:
    Change title of Figure 10.122 on page 304 (PDF 334) to 'Compensation through a Compensation Event Sub-Process'.

  • Reported: BPMN 2.0 — Wed, 14 Dec 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ItemAwareElement the second

  • Key: BPMN21-322
  • Legacy Issue Number: 17043
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    At page S.223: ‘Model Associations of DataAssociation:
    The source/target MUST be an temAwareElement.’ Now, I have to look: what is an ItemAwareElement? (So I use strg+F to search. But remember, there are two different spellings*.. ) I think it is better to mention the source/target directly.

    • have a look on my reported issue 'item-aware element vs. ItemAwareElement'.
  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

eXclusive Gateway

  • Key: BPMN21-321
  • Legacy Issue Number: 17040
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    There are two types of signs for the Exclusive Gateway. Why? It is better to use only the sign with the ‘X’. Finally it is an eXclusive Gateway
    -> Mr. Juergen Boldt answered: "[..] It is left open to the modeler as a matter of taste."
    OK.
    -> But IMHO BPMN 2.0 is a standard. There is no leeway for matter of taste. I think.
    ---------
    (Look at the road traffic or specification of your voltage wich comes from your socket. That is no matter of taste. )

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

item-aware element vs. ItemAwareElement

  • Key: BPMN21-320
  • Legacy Issue Number: 17039
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    ItemAwareElement: item-aware element (Example on page 205) vs. ItemAwareElement (Example on page 204) ­ there are two different spellings.
    There are also two different meanings?

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missing Enumeration

  • Key: BPMN21-319
  • Legacy Issue Number: 17038
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    At page 184 you write ‘If the Call Activity calls a Process, then there are
    two options:’ Under this sentence there is only one enumeration (only one
    option? Or is the sentence ‘If the details of the called Process are’
    the second option? But this sentence has no enumeration).

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Table 7.2 Description of Multiple Instances

  • Key: BPMN21-328
  • Legacy Issue Number: 17106
  • Status: open  
  • Source: Data Networks Corporation ( Candido Gonzalez)
  • Summary:

    In the Table 7.2 description of Multiple Instances, it says in the second sentence that "A set of three horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-instances." In the third sentence, it again says that the set of three vertical lines is also for sequential multi-instances. A revision needs to be made to correctly state what the three horizontal lines and three vertical lines stand for.

  • Reported: BPMN 2.0 — Thu, 9 Feb 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Catch None intermediate event

  • Key: BPMN21-324
  • Legacy Issue Number: 17045
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    On page 272 you talk about a ‘Catch None intermediate event’. But at the table on page 261 there is no ‘Catch none intermediate event’. There is a ‘Throw none intermediate event’

    -> It would be good, if you would change the text on page 272.

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

wrong reference on page 292

  • Key: BPMN21-325
  • Legacy Issue Number: 17046
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    At page 292 last sentence: ‘[...] precise synchronization behavior of the Inclusive Gateway can be found on page 292’ ­ I don’t found it.

    It would be good, if you correct the reference.

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

MAY NOT

  • Key: BPMN21-323
  • Legacy Issue Number: 17044
  • Status: open  
  • Source: University of Applied Sciences Dresden ( Michael Gruenert)
  • Summary:

    You use ‘MAY NOT’. But it is not referenced in RFC-2119. I think it is important in a standard-document to define keywords.
    p. 99/111/112/..

  • Reported: BPMN 2.0 — Tue, 24 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN 2.0 Spec Problems (from Typo's to More Serious Issues)

  • Key: BPMN21-299
  • Legacy Issue Number: 16063
  • Status: open  
  • Source: iGrafx (Corel Inc.) ( Kim Scott)
  • Summary:

    Description:

    * Section 2: Table 2.3, note ‘a’ [page 7]: Should be “Multiple incoming connections…” [incoming vs. outgoing]

    • Section 7: Tables 7.1 and 7.2 (and others?): Missing 'a' in front of 'company' in "An Activity is a generic term for work that company performs"
    • Section 7: Table 7.2, Activity [p. 32]: The spec seems to consistently use the spelling “Sub-Process” for sub-processes. Merriam-Webster indicates that “subprocess” is the correct form of the word (i.e. that sub is simply a prefix) and does not offer a hyphenated alternative (even though Microsoft Word complains ‘subprocess’ is misspelled
    • Table 7.2, Choreography Task [p. 32]: Missing "or more" in "Each Choreography Task involves two (2) Participants", as they can specify more than 2 Participants.
    • Table 7.2 Conditional Flow [p.35]: Typo; should be ‘is’ vs. ‘are’ in "A Sequence Flow can have a condition Expression that are evaluated" (or should be "Expressions that are").
    • Table 7.2 Compensation Association [p. 35]: The activity that is the target of the Compensation Association is missing the compensation indicator.
    • Section 8.3.1 Artifacts, Text Annotation [p. 71]: May contradict itself on open rectangle. Says “A Text Annotation is an open rectangle that MUST be drawn with a solid single line (as seen in Figure 8.16).” and then “text associated with the Annotation can be placed within the bounds of the open rectangle.” Isn't that "...MUST be placed within"? Why MUST you draw the open rectangle if text doesn't go within it, per Figure 8.16?
    • Section 10.2 Activities, [p.153]: completionQuantity says "This number of tokens will be sent done any..." and the 'done' should be 'down'.
    • Section 10.2.3 Tasks, Receive Task [p. 161]: "Once the Message has been received, the Task is completed." Is this worded correctly? If this Task doesn't do anything after the Message is received, then why use it instead of a Receive (Catch) Message Event?
    • Section 10.2.5 Subprocesses, page 177: The following is missing Timer (at a minimum; also missing Parallel Multiple?): “The Start Event trigger (EventDefinition) MUST be from the following types..."
    • Section 10.2.5 Subprocesses, page 177, Figure 10.30 is incorrect; it does not show the start event in upper-left corner like text says.
    • Section 10.2.8: pages 190 & 191, Figures 10.47, 10.48, and 10.49 contradict Table 12.8 on page 382 & 383 on the location of the multi-instance indicator (marker) for Collapsed Subprocesses. I assume Table 12.8 is correct.
    • Section 10.4: page 233: The word 'trigger' should be 'result' in the following sentence in list item 2: "The throwing of a trigger MAY be..." (Items 1 & 2 say "Events that catch a trigger" and "Events that throw a Result." So triggers are caught and results are thrown, correct?
    • Section 10.4.6, page 276, Figure 10.98: An Intermediate multiple event marker is used for a start event-based gateway, and it should be a start event marker (single line vs. double on the Event within the Gateway).
    • Section 10.4.6, page 277: The following seems to be missing Escalation Events at a minimum: “...or by running an Event Handler without canceling the Activity (only for Message, Signal, Timer and Conditional Events, not for Error Events).”

    * Section 10.8, page 309: Figure 10.1 was updated, but the references to activity names in the Figure were not updated in the first and second paragraphs of Section 10.8. For example “…in Figure 10.1 might execute or perform an extra Activity between Task “Receive Issue List” and Task “Review Issue List.””

    • Section 11.4.1: Choreography Task [p. 327, 332]: The text is unclear about whether Participants can be multi-instance sequential, but I believe they can. As such, the language on page 327 of “The marker for a Choreography Task that is multi-instance MUST be a set of three vertical lines” and

    on page 332 of “The marker for a Sub-Choreography that is multi-instance MUST be a set of three vertical lines” seems incorrect and too limiting. If multi-instance sequential can be used, then three horizontal lines are also allowed (as is the 'loopback' repeat?).

    • Section 13.2.2 Activity [p. 429]: The fifth bullet says "(proposed for BPMN 2.0)" when this is the final spec, and non-interrupting EVent Handlers are part of the spec. This should be removed.
  • Reported: BPMN 2.0 — Thu, 10 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN2 issue: Example (DI lanes and nested lanes) appears to be invalid

  • Key: BPMN21-298
  • Legacy Issue Number: 16060
  • Status: open  
  • Source: Red Hat ( Gary Brown)
  • Summary:

    When opening the example
    http://www.omg.org/spec/BPMN/2.0/examples/ZIP/Diagram%20Interchange/Examples%20-%20DI%20-%20Lanes%20and%20Nested%20Lanes.bpmn
    throws an exception[1].

    This happens because it tries to assign
    org.eclipse.bpmn2.impl.DataObjectReferenceImpl object to an array of FlowNodes.

    org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Value
    'org.eclipse.bpmn2.impl.DataObjectReferenceImpl@6caf4065 (id:
    DataObject_Document, anyAttribute: null) (name: Document)' is not legal.
    (platform:/resource/Dev/Examples%20-%20DI%20-%20Lanes%20and%20Nested%20Lanes.bpmn2,
    -1, -1)
    at
    org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:83)
    at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:191)
    at
    org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:180)
    at
    org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1494)
    at
    org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1282)
    ...
    Caused by: org.eclipse.emf.ecore.xmi.IllegalValueException: Value
    'org.eclipse.bpmn2.impl.DataObjectReferenceImpl@6caf4065 (id:
    DataObject_Document, anyAttribute: null) (name: Document)' is not legal.
    (platform:/resource/Dev/Examples%20-%20DI%20-%20Lanes%20and%20Nested%20Lanes.bpmn2,
    -1, -1)
    at
    org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(XMLHandler.java:2663)
    at
    org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleForwardReferences(XMLHandler.java:1149)
    ...
    Caused by: java.lang.ArrayStoreException:
    org.eclipse.bpmn2.impl.DataObjectReferenceImpl
    at org.eclipse.emf.common.util.BasicEList.assign(BasicEList.java:124)
    at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList.java:424)
    at
    org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUnique(NotifyingListImpl.java:331)
    at
    org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:315)
    at
    org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.setValue(XMLHelperImpl.java:1179)
    at
    org.eclipse.emf.ecore.xmi.impl.XMLHandler.setFeatureValue(XMLHandler.java:2658)
    ... 99 more

  • Reported: BPMN 2.0 — Wed, 16 Mar 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN 2.0 Choreography issues page 327 of dtc/2010-06-05

  • Key: BPMN21-306
  • Legacy Issue Number: 16547
  • Status: open  
  • Source: Anonymous
  • Summary:

    Page 327 of /dtc/2010-06-05/ runs as follows (emphasis in the last
    sentence added):

    “To leverage the familiarity of flow charting types of Process
    models, BPMN Choreographies also have “activities” that are ordered
    by Sequence Flows. These “activities” consist of one (1) or more
    interactions between Participants. These interactions are often
    described as being message exchange patterns (MEPs). A MEP is the
    atomic unit (“Activity”) of a Choreography.

    Some MEPs involve a single Message (e.g., a “Customer” requests an
    “Order” from a “Supplier”). Other MEPs will involve two (2) Messages
    in a request and response format (e.g., a “Supplier” request a
    “Credit Rating” from a “Financial Institution,” who then returns the
    “Credit Rating” to the “Supplier”). There can be even more complex
    MEPs that involve error Messages, for example.”

    This wording may result confusing to practitioners. First of all,
    there is no way in BPMN 2.0 Choreographies to mark a message as an
    “error message”. What the specification seems to hint at is that
    some of the messages in the choreography may deliver information
    over errors. However, since BPMN 2.0 Choreographies (and, more
    generally, BPMN 2.0 as a whole) does not differentiate among the
    possible “typologies” of messages (e.g. error, acknowledgement,
    invocation, or response), there is no immediate way to map WSDL
    1.1/2.0 MEPs to single Choreography Taskswithout losing some
    information (e.g. the distinction between output messages and fault
    messages). Even using the structureRefof the message(see e.g. Page 7
    of /dtc/2010-06-05/) to point to a WSDL 1.1/2.0 message, this would
    provide no information about what “type” of message it is. In fact,
    in WSDL 1.1/2.0 a message is “labelled” as input, output or fault
    only in the WSDL operations, so much that a given WSDL message
    could, for example, be input in one operation and a fault in another.

    Secondly, despite the fact that the text mentions Choreography
    Activities as the realization of MEPs (i.e. also
    Sub-choreographies), the reference to MEPs as atomic units sounds
    intuitively related to Choreography Tasks. Given the fact that it is
    not possible to (1) specify error messages and (2) specify the
    sequencing in a single Choreography Taskfor more than two messages,
    a single Choreography Taskallows the specification of only the WSDL
    1.1 “one-way messaging” and “notification” MEPs. In fact, the
    specification of “request/reply” and “solicit/response” MEPs is not
    possible because their faults cannot be represented in the same
    Choreography Tasktogether with the input and output messages.

    To clarify this issues, the specification should address clearly and
    in detail the relation between BPMN 2.0 Choreographies and MEPs in
    WSDL 1.1 and WSDL 2.0, in particular with relation to the
    granularity of the MEPs (Choreography Task-level, Sub-choreography
    level, etc.). Moreover, it is still an open issue how to map WSDL
    2.0 Complex MEPs to BPMN 2.0 Choreographies.

  • Reported: BPMN 2.0 — Wed, 14 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN 2.0 Choreography issues page 339 of dtc/2010-06-05

  • Key: BPMN21-305
  • Legacy Issue Number: 16546
  • Status: open  
  • Source: Anonymous
  • Summary:

    N.B. In the reminder /dtc/2010-06-05 /is the BPMN 2.0 specification.

    ------ ISSUE START ------
    Page 339 of /dtc/2010-06-05/ reads as follows:

    “There are situations when a Participant for a Choreography Task is
    actually a multi-instance Participant. A multi-instance Participant
    represents a situation where there are more than one possible
    related Participants (PartnerRoles/ PartnerEntities) that might be
    involved in the Choreography. For example, in a Choreography that
    involves the shipping of a product, there can be more than one type
    of shipper used, depending on the destination.”

    Page 344 of /dtc/2010-06-05/ reads almost verbatim, but referring to
    multi-instance participants in Sub-choreographies:

    “There are situations when a Participant for a Sub-Choreography is
    actually a multi-instance Participant. A multi-instance Participant
    represents a situation where there are more than one possible
    related Participants (PartnerRoles/ PartnerEntities) that can be
    involved in the Choreography. For example, in a Choreography that
    involves the shipping of a product, there can be more than one type
    of shipper used, depending on the destination.”

    First of all, the above wordings are unclear with respect to which
    of the following two cases applies at run-time with multi-instance
    participants:

    1. Exactly one partner entity (as defined on Page 117 of
    /dtc/2010-06-05/) out of many possible ones during the enactment
    of the choreography.
    2. One or more partner entities partake the choreography enactment.

    We could not find in the /dtc/2010-06-05/any wording that clarifies
    which of the two possible meanings is the correct one. We assume (2)
    for consistency with the Orchestration part of the specification.
    However, having a multi-instance participant resolve to multiple
    partner entities during the enactment raises several serious issues:

    • Multi-instance recipient participants in a choreography task
      violate the assumption that each choreography task involves
      exactlytwo partner entities, which is a fundamental assumption
      for the specification of Message Exchange Patterns (MEPs) in
      Choreography Tasks.
    • Similarly to the previous case: how to deal with Choreography
      Task senders that are multi-instance participants? How many
      initiating messages are actually sent?

    Even more complicated issues arise from multi-instance participants
    in terms of the enforceability of choreographies. For example, if
    the partner entities that resolve a given multi-instance participant
    are decided at enactment time, how are the other partner entities
    supposed to know (and therefore be able to deliver messages to them)?

    It is our opinion that multi-instance participantsis a complicated
    construct to deal with in Choreographies, and should be thoroughly
    re-considered (possibly leading to its elimination from the
    specification).

  • Reported: BPMN 2.0 — Wed, 14 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

meta-model doesn't provide way to serialize intermediate catch events attached to participant bands of choreography task

  • Key: BPMN21-308
  • Legacy Issue Number: 16549
  • Status: open  
  • Source: IAAS, University of Stuttgart ( Michele Mancioppi)
  • Summary:

    On pp. 341~343 the specification details some intermediate catch events that can be attached to activity boundaries, namely Message, Timer, Cancel, Compensation, Conditional, Signal and Multiple. This is similar to attaching events to activities in Process diagrams. The meta-model supports attaching of events to activity boundaries in Processes through the BoundaryEvent element. However, no similar element is available for Choreography Activities. Instances of BoundaryEvent obviously cannot be used (because ChoreographyActivity does not extend Activity). Therefore a new Class should be added. This class (called e.g. ChoreographyBoundaryEvent) should (1) have a reference to the ChoreographyActivity to which the event is attached, and (2) depending on the type of event, specify to which of the ParticipantBands the event is attached. This is necessary because some events, namely Message, Cancel and Compensation are "local" (i.e. visible) to only one of the Participants involved in the ChoreographyActivity. The specification should clearly state in which cases this reference to a Participant is compulsory, and in which cases optional. For example, it might be optional in the case of Signal events, to symbolize that the event is trigger by the reception of the signal by one particular participants (which is different than the "firing" of the signal, given the fact that the specification does not seem to require signals to be "immediately" received, but just "eventually" received by the participants).

  • Reported: BPMN 2.0 — Wed, 14 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN 2.0 Choreography issues page 338 of dtc/2010-06-05 about Sub-choreographics

  • Key: BPMN21-307
  • Legacy Issue Number: 16548
  • Status: open  
  • Source: Anonymous
  • Summary:

    On Page 338 of /dtc/2010-06-05/, about Sub-choreographies:

    “The Participant Band of the Participant that does not initiate the
    interaction MUST be shaded with a light fill.”

    This wording does not cover some corner cases. Consider the example
    depicted in the attached image Example Issue Initiating Participant
    in Sub-Choreographies.png. In the choreography above it is unknown
    until the enactment of Task 1which participant is the initiator of
    Sub-choreography 1. But this is only the symptom of a wider-reaching
    problem. When there is no choreography task that dominates of all
    the others (or worse, there is a race condition!), and the various
    choreography tasks that may be executed as first have different
    initiators, modelers have no way to pick which participant is marked
    as the initiator of the sub-choreographies.

    The same issue with initiators of sub-choreographies affects also
    the messages sent by them. In fact, Page 93 of /dtc/2010-06-05/reads:

    “Any Message sent by the non-initiating Participant or
    Sub-Choreography MUST be shaded with a light fill.”

    We propose two possible, mutually exclusive solutions:

    1. Additional constraints are specified for choreographies so that
    no such corner case can occur. However, this is very likely to
    result in not being able to model with BPMN 2.0 choreographies
    some inter-organizational processes that can instead be modeled
    with BPMN 2.0 Orchestrations.
    2. Drop the differentiation between initiator and non-initiator
    participants in sub-choreographies. We see no real shortcoming
    resulting from this approach. In particular, with respect to the
    enactability of choreographies, knowing which participant is the
    first to act in a sub-choreography gives no guarantees as to the
    fact that the same participant will also be involved in the
    “last” choreography activities to be executed in that
    sub-choreography. Therefore, we can extract no useful
    information from it with respect to the enactability of what
    follows that sub-choreography. This is particularly true in the
    case of collapsed sub-choreographies.

  • Reported: BPMN 2.0 — Wed, 14 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unclear introduction of the concept of MEP

  • Key: BPMN21-310
  • Legacy Issue Number: 16551
  • Status: open  
  • Source: IAAS, University of Stuttgart ( Michele Mancioppi)
  • Summary:

    Page 315 reports the following text on MEPs:

    “To leverage the familiarity of flow charting types of Process models, BPMN Choreographies also have “activities” that are ordered by Sequence Flows. These “activities” consist of one (1) or more interactions between Participants. These interactions are often described as being message exchange patterns (MEPs). A MEP is the atomic unit (“Activity”) of a Choreography.

    Some MEPs involve a single Message (e.g., a “Customer” requests an “Order” from a “Supplier”). Other MEPs will involve two (2) Messages in a request and response format (e.g., a “Supplier” request a “Credit Rating” from a “Financial Institution,” who then returns the “Credit Rating” to the “Supplier”). There can be even more complex MEPs that involve error Messages, for example.”

    This wording may result confusing to practitioners for the following reasons.

    First of all, there is no way in BPMN 2.0 Choreographies to mark a message as an “error message”. What the specification seems to hint at is that some of the messages in the choreography may deliver information over errors. However, since BPMN 2.0 Choreographies (and, more generally, BPMN 2.0 as a whole) does not differentiate among the possible “typologies” of messages (e.g. error, acknowledgement, invocation, or response), there is no immediate way to map WSDL 1.1/2.0 MEPs to single Choreography Tasks without losing some information (e.g. the distinction between output messages and fault messages). Even using the structureRef of the message (see e.g. Page 7 of dtc/2010-06-05) to point to a WSDL 1.1/2.0 message, this would provide no information about what “type” of message it is. In fact, in WSDL 1.1/2.0 a message is “labelled” as input, output or fault only in the WSDL operations, so much that a given WSDL message could, for example, be input in one operation and a fault in another.

    Secondly, despite the fact that the text mentions Choreography Activities as the realization of MEPs (i.e. also Sub-choreographies), the reference to MEPs as atomic units sounds intuitively related to Choreography Tasks. Given the fact that it is not possible to (1) specify error messages and (2) specify the sequencing in a single Choreography Task of more than two messages, a single Choreography Task allows the specification of only the WSDL 1.1 “one-way messaging” and “notification” MEPs. In fact, the specification of “request/reply” and “solicit/response” MEPs is not possible because their faults cannot be represented in the same Choreography Task alongside the input and output messages.

    To clarify this issues, the specification should address clearly and in detail the relation between BPMN 2.0 Choreographies and MEPs in WSDL 1.1 and WSDL 2.0, in particular with relation to the granularity of the MEPs (Choreography Task-level, Sub-choreography level, etc.).

    Additionally, it might be beneficial to for the sake of clarity to explicitly that it is outside the scope of ChoreographyTasks to be able to map entire WSDL 2.0 Complex MEPs, but that, instead, they have to be realized by multiple choreography tasks appropriately sequenced.

  • Reported: BPMN 2.0 — Thu, 15 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Process name in property mapping is "statically" derived not "statistically"

  • Key: BPMN21-309
  • Legacy Issue Number: 16550
  • Status: open  
  • Source: University of Bamberg ( JöLenhard)
  • Summary:

    The mapping of "getProcessProperty(propertyName)" to BPEL reads "$[

    {processName}

    .propertyName] where the right process-Name is statistically derived."
    "statistically" does not fit in this context, the name should be derived "statically" from the process in which the current expression is used.

  • Reported: BPMN 2.0 — Thu, 15 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Underspecification of Multi-instance participants in Choreographies

  • Key: BPMN21-312
  • Legacy Issue Number: 16553
  • Status: open  
  • Source: IAAS, University of Stuttgart ( Michele Mancioppi)
  • Summary:

    Page 327 reports the following text on multi-inistance participants:

    "There are situations when a Participant for a Choreography Task is actually a multi-instance Participant. A multiinstance
    Participant represents a situation where there are more than one possible related Participants (PartnerRoles/
    PartnerEntities) that might be involved in the Choreography. For example, in a Choreography that involves
    the shipping of a product, there can be more than one type of shipper used, depending on the destination."

    Page 344 of dtc/2010-06-05 reads almost verbatim, but referring to multi-instance participants in Sub-choreographies:

    “There are situations when a Participant for a Sub-Choreography is actually a multi-instance Participant. A multiinstance
    Participant represents a situation where there are more than one possible related Participants (PartnerRoles/
    PartnerEntities) that can be involved in the Choreography. For example, in a Choreography that involves the
    shipping of a product, there can be more than one type of shipper used, depending on the destination.”

    The above wordings seem unclear with respect to which of the following two cases applies at run-time with multi-instance participants:
    1) Exactly one partner entity (as defined on Page 117 of dtc/2010-06-05) out of many possible ones during the enactment of the choreography.
    2) One or more partner entities partake the choreography enactment.

    We assume (2) for consistency with the Orchestration part of the specification. However, having a multi-instance participant resolve to multiple partner entities during the enactment of the choreography raises several serious issues:

    • Multi-instance recipient participants in a choreography task violate the assumption that each choreography task involves exactly two partner entities, which is a fundamental assumption for the specification of Message Exchange Patterns (MEPs) in Choreography Tasks.
    • Similarly to the previous case: how to deal with Choreography Task senders that are multi-instance participants? How many initiating messages are actually sent?
    • Assuming both the sender and recipient of a ChoreographyTask to be multi-instance, how many message exchanges actually take place? All the possible permutations?

    Even more complicated issues arise from multi-instance participants in terms of the enforceability of choreographies. For example, if the partner entities that resolve a given multi-instance participant are decided at enactment time, how are the other partner entities supposed to know (and therefore be able to deliver messages to them)?

  • Reported: BPMN 2.0 — Thu, 15 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Underspecification of initiating/non-initiating participants in non-trivial choreographies

  • Key: BPMN21-311
  • Legacy Issue Number: 16552
  • Status: open  
  • Source: IAAS, University of Stuttgart ( Michele Mancioppi)
  • Summary:
  • Reported: BPMN 2.0 — Thu, 15 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

XML Schema not valid


Error in Description for Multiple Instances in Table 7.2

  • Key: BPMN21-303
  • Legacy Issue Number: 16228
  • Status: open  
  • Source: Cobham Aerospace Communications ( Dale Cureton)
  • Summary:

    In the Description field for the Multiple Instances element in Table 7.2, the second sentance states "... three horizontal lines will be displayed ... for sequential Multi-Instances..." while the third sentance states "three vertical lines will be displayed ... for sequential Multi-Instances..."

    Note that BOTH sentances refer to "sequential Multi-Instances".

    Solution: the third sentance should refer to "parallel Multi-Instances".

  • Reported: BPMN 2.0 — Thu, 12 May 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Title of Figure 10.66 grammatically wrong

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

    The title of Figure 10.66 seems grammatically wrong to me.

    It reads:
    "A Data Association used for an Outputs and Inputs into an Activities"

    Proposal:
    Change title of Figure 10.66 on page 222 (PDF 252) into:
    "Data Associations used for Outputs from and Inputs into Activities"

  • Reported: BPMN 2.0 — Thu, 21 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Some BPEL4People links are dead


Underspecification of ChoreographyLoopType

  • Key: BPMN21-313
  • Legacy Issue Number: 16554
  • Status: open  
  • Source: IAAS, University of Stuttgart ( Michele Mancioppi)
  • Summary:

    The loop types of choreography activities do not provide any information about: (1) the "hard-coded" cardinality of the loop (how often is the loop repeated) or (2) the expression that must be evaluated during the choreography enactment based on the data contained in the messages exchanged up to that point during the enactment. In the latter case, specifying the expression is not enough: for reasons of enforceability, it should be possible to specified which participant(s) must evaluate the expression.

  • Reported: BPMN 2.0 — Fri, 16 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

BPMN 2.0: Errors in Section 6.2 Structure of this Document

  • Key: BPMN21-301
  • Legacy Issue Number: 16108
  • Status: open  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    In BPMN 2.0, formal/2011-01-03, Section 6.2 Structure of this Document is OK up to the reference to Chapter 10. However, it next references Chapter 11 Conversations which does not exist, and every reference after that has its chapter number incorrectly one too high: Chroeographies is 11, not 12. The visual diagram model is 12, not 13. and so on.

  • Reported: BPMN 2.0 — Tue, 5 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Can Event Sub-Processes Loop?

  • Key: BPMN21-300
  • Legacy Issue Number: 16102
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    An Event Sub-Process is a type of Sub-Process. Sub-Processes, as Activities, can have loop settings--meaning that the entire Sub-Process, from the start to the end can be repeated. But how does this work for an Event Sub-Process? Is the Start Event trigger for the Event Sub-Process expected to be repeated? or is the Start Event just ignored?

  • Reported: BPMN 2.0 — Tue, 29 Mar 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

more typos

  • Key: BPMN21-297
  • Legacy Issue Number: 16055
  • Status: open  
  • Source: Telstra Coorporation ( John Raper)
  • Summary:

    Change "recieved" in Fig 11.49 to "received" six times - At least it is consistent.
    Perhaps the USA has changed the rule:
    "i before e except after c"

  • Reported: BPMN 2.0 — Thu, 10 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Change "recieved" in Fig 11.49 to "received"

  • Key: BPMN21-296
  • Legacy Issue Number: 16054
  • Status: open  
  • Source: Telstra Coorporation ( John Raper)
  • Summary:

    Change "recieved" in Fig 11.49 to "received"

  • Reported: BPMN 2.0 — Thu, 10 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Spello

  • Key: BPMN21-295
  • Legacy Issue Number: 16053
  • Status: open  
  • Source: Telstra Coorporation ( John Raper)
  • Summary:

    Change "recieved" in Fig 11.48 to "received"

  • Reported: BPMN 2.0 — Thu, 10 Mar 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Meaning of 'behavior' attribute on MultiInstanceLoopCharacteristics quite confusing

  • Key: BPMN21-276
  • Legacy Issue Number: 15911
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    The meaning of the 'behavior' attribute on the MultiInstanceLoopCharacteristics is quite confusing. It is told that:

    • 'None' should throw an event on each instance,
    • 'All' should throw no event at all

    It seems that None and All meaning have been swapped.

    I also think that oneBehaviorEventRef and noneBehaviorEventRef can be merged as they are exclusive, they will never both be filled.

    Another question: what Event will own (composition relationship) the EventDefinition that is referenced by oneBehaviorEventRef or noneBehaviorEventRef ?
    As far as I understood, an EventDefinition can be owned only by an Event.

    My proposed solution:
    ---------------------
    1) Rewrite behavior: MultiInstanceBehavior meaning as following:

    behavior: MultiInstanceBehavior =
    all

    { None | First | Each | Complex}

    :
    -----------------------------------------
    The attribute behavior acts as a shortcut for specifying when events SHALL be thrown
    from an Activity instance that is about to complete. It can assume val-
    ues of None, One, All, and Complex, resulting in the following behav-
    ior:
    • None: no Event is ever thrown; a token is produced after completion
    of all instances
    • First: the EventDefinition referenced through the oneEvent
    association will be thrown upon the first instance completing;
    • Each: the EventDefinition which is associated through the
    noneEvent association will be thrown for each instance
    completing;
    • Complex: the complexBehaviorDefinitions are consulted to
    determine if and which Events to throw.

    For the behaviors of First and Each, a default
    SignalEventDefinition will be thrown which automatically carries
    the current runtime attributes of the MI Activity.
    Any thrown Events can be caught by boundary Events on the Multi-
    Instance Activity.

    3) Change oneBehaviorEventRef and noneBehaviorEventRef composition relationships
    Unless an answer is provided to the referred event definition ownership.

    2) Change the type of oneBehaviorEventRef and noneBehaviorEventRef to ThrowEvent
    Unless an answer is provided to the referred event definition ownership.

    4) Merge oneBehaviorEventRef and noneBehaviorEventRef into 'behaviorEventRef'

  • Reported: BPMN 2.0 — Tue, 4 Jan 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Subclasses of Interaction Node (Task vs. Activity)

  • Key: BPMN21-275
  • Legacy Issue Number: 15901
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the Message Flow Class Diagram (Figure 9.14), Interaction Node has four subclasses: Participant, ConversationNode, Task and Event.

    However, according to page 124:
    Of the types of InteractionNode, only Pools/Participants, Activities, and
    Events can be the source of a Message Flow.

    The question now is, whether Task or Activity should be the subclass of Interaction Node.

    Suggestion: The Message Flow Connection Rules on page 44 specify that Message Flows can also connect to Sub-Processes. Therefore, I think it is necessary to define that Activity is a subclass of InteractionNode.

  • Reported: BPMN 2.0 — Wed, 15 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inheritance and Relationship of ResourceParameter

  • Key: BPMN21-274
  • Legacy Issue Number: 15900
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the class diagram (Figure 8.31) and the XML Schema, ResourceParameter inherits from BaseElement and has a relationship with cardinality [0..1] to ItemDefinition.

    However, according to the last paragraph on page 96: The ResourceParameter element inherits the attributes and model associations of BaseElement (see Table 8.5)
    through its relationship to RootElement. In addition, Table 8.50 defines no cardinality for the relationship type and, therefore, leads to the assumption that the cardinality is 1.

    Suggestion: As the element Resource is also derived from RootElement, it would fit to also derive ResourceParameter from RootElement. Considering the cardinality, I would suggest to define a cardinality of [0..1].

  • Reported: BPMN 2.0 — Wed, 15 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 140-141. Wrong name of model associations

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

    a) Page 140

    It says:
    “A Collaboration uses ParticipantAssociations and MessageFlowAssociations for this purpose.”

    The name of the model associations are: participantAssociatios and messageFlowAssociations (see Figure 9.33, p. 142; Table 9.1, p.111).

    Then, it should say:
    “A Collaboration uses participantAssociatios and messageFlowAssociations for this purpose.”

    “ParticipantAssociations and MessageFlowAssociations” should be replaced by “participantAssociatios and messageFlowAssociations”
    --------------------------------------------------------------------------

    b) Page 140

    It says:
    “To handle the Participants, the innerParticipant of a ParticipantAssociation refers to a Participant in the Choreography, while the outerParticipant refers to …”

    The name of the model associations are: innerParticipantRef and outerParticipantRef (see Figure 9.33, p. 142; Table 9.7, p.121).

    Then, it should say:
    “To handle the Participants, the innerParticipantRef of a ParticipantAssociation refers to a Participant in the Choreography, while the outerParticipantRef refers to …”

    “innerParticipant” should be replaced by “innerParticipantRef”
    “outerParticipant” should be replaced by “outerParticipantRef ”
    --------------------------------------------------------------------------

    c) Page 141

    It says:
    “…Participants could be assumed to be the inner and outerParticipants of a ParticipantAssociation.”

    The name of the model associations are: innerParticipantRef and outerParticipantRef (see Figure 9.33, p. 142; Table 9.7, p.121).

    Then, it should say:
    “…Participants could be assumed to be the innerParticipantRef and outerParticipantRef of a ParticipantAssociation.”

    “inner and outerParticipants” should be replaced by “innerParticipantRef and outerParticipantRef ”
    --------------------------------------------------------------------------

    d) Page 141

    It says:
    “To handle Message Flows, the innerMessageFlow of a MessageFlowAssociation refers to a Message Flow in the Choreography, while the outerMessageFlow refers to …”

    The name of the model associations are: innerMessageFlowRef and outerMessageFlowRef (see Figure 9.33, p. 142; Table 9.9, p.125).

    Then, it should say:
    “To handle Message Flows, the innerMessageFlowRef of a MessageFlowAssociation refers to a Message Flow in the Choreography, while the outerMessageFlowRef refers to …”

    “innerMessageFlow” should be replaced by “innerMessageFlowRef”
    “outerMessageFlow” should be replaced by “outerMessageFlowRef”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 132. “Communication” instead of “Conversation” Figure 9.23

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

    It says
    “Figure 9.23 ­ A Communication element”

    “Communication” element in Beta 1 is “Conversation” in Beta 2.

    Then, is should be
    “Figure 9.23 ­ A Conversation element”

    “Communication” should be replaced by “Conversation”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 283. The number of types of Event handlers

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

    It says:
    “There are three (3) types of Event handlers: those that start a Process, those that are part of the normal Sequence Flow, and those that are attached to Activities, either via boundary Events or via separate inline handlers in case of an Event Sub-Process.”

    Actually, there are four Sub-Sections:
    1) Handling Start Events (p.283)
    2) Handling Events within normal Sequence Flow (Intermediate Events) (p. 284)
    3) Handling Events attached to an Activity (Intermediate boundary Events and Event Sub-Processes) (p.285). With two sub-sub-.sections.
    4) Handling End Events (p.288)

    Then, it should say:
    “There are four (4) types of Event handlers: those that start a Process, those that are part of the normal Sequence Flow, those that are attached to Activities, either via boundary Events or via separate inline handlers in case of an Event Sub-Process, and those that end a Process.”

    “three (3) types” should be replaced by “four (4) types”
    “and those that are attached to Activities” should be replaced by “those that are attached to Activities”
    “Event Sub-Process.” should be replaced by “Event Sub-Process, and those that end a Process.”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 281. Wrong name of Figure 10.92

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

    Figure 10.92.

    It says
    “Figure 10.92 ­ Multiple Events”

    Figure 10.92 shows Parallel Multiple Events, not Multiple Events (see Figure 10.90, p.280).

    It should say
    “Figure 10.92 ­ Parallel Multiple Events”

    “Multiple” should be replaced by “Parallel Multiple”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 171. “Manual Task” instead of “User Task”

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

    First paragraph says:
    “The User Task inherits the attributes and model associations of Activity (see Table 10.3), but does not have any additional attributes or model associations.”

    This sentence is in sub-section “Manual Task”, which starts on page 170.

    Then, it should say:
    “The Manual Task inherits the attributes and model associations of Activity (see Table 10.3), but does not have any additional attributes or model associations.”

    “User Task” should be replaced by “Manual Task”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pages 165-167. “implementation” attribute of Send and Receive Tasks

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

    a) Page 165

    Table 10.9. Row “implementation”.

    It says:
    “… that will be used to send and receive the Messages.”

    Table 10.9 describes Send Task element, so the Messages are sent only.

    Then, it should say:
    “… that will be used to send the Messages.”

    “send and receive” should be replaced by “send”
    ---------------------------------------------------------------------

    b) Page 167

    Table 10.10. Row “implementation”.

    It says:
    “… that will be used to send and receive the Messages.”

    Table 10.10 describes Receive Task element, so the Messages are received only.

    Then, it should say:
    “… that will be used to receive the Messages.”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 130. Nonexistent Conversation “Special Cover” is mentioned

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

    It says:
    “An example is Delivery Planning which leads to Carrier Planning and Special Cover.”

    Conversation “Special Cover” is not shown in Figure 9.18, p.127.

    Maybe Conversation “Special Cover” is the Conversation between Shipper and Insurance (Figure 9.18), which has not name.

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 128. Wrong name of Conversation “Delivery/Dispatch Plan”

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

    It says:
    “… a Message exchange in the Delivery Negotiation leads to Shipment Schedule, Delivery Planning and Delivery/Dispatch Conversations and these could be combined …”

    The name of the Conversation is “Delivery/Dispatch Plan”, not “Delivery/Dispatch”. See Figure 9.18. p.127.

    Then, it should say:
    “… a Message exchange in the Delivery Negotiation leads to Shipment Schedule, Delivery Planning and Delivery/Dispatch Plan Conversations and these could be combined …”

    “Delivery/Dispatch” should be replaced by “Delivery/Dispatch Plan”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 246. Typo

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

    Sub-Section Start Event Triggers

    It says:
    “Start Events can be used for three types of Processes:”

    But four are listed. The third (Global Process) is explained in Sub-Sections: “Start Event for Top-Level Processes” and “Start Events for Sub-Processes”.

    Then, it should say:
    “Start Events can be used for four types of Processes:”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 224. Typos

  • Key: BPMN21-192
  • Legacy Issue Number: 15589
  • Status: open  
  • Source: Anonymous
  • Summary:

    a) Sub-section Send Task Mapping

    It says:
    “…there MUST be at most inputSet set and at most one Data Input on the Send Task.”

    It should say:
    “…there MUST be at most one inputSet set and at most one Data Input on the Send Task.”

    “at most inputSet” should be replaced by “at most one inputSet”

    b) Sub-section Recieve Task Mapping
    It says:
    “…there MUST be at most outputSet set and at most one Data Output on the Receive Task.”

    It should say:
    “…there MUST be at most one outputSet set and at most one Data Output on the Receive Task.”

    “at most outputSet” should be replaced by “at most one outputSet”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 154. “Choreography” instead of “Process

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

    It says:
    “Some BPMN elements are common to both Process and Choreography, as well as Collaboration; they are used in these diagrams. The next few sections will describe the use of Messages, Message Flows, Participants, Sequence Flows, Artifacts, Correlations, Expressions, and Services in Choreography.”

    Chapter 10 is devoted to Processes, not to Choreographies. The same paragraph is in 9.1.1 (p.112), where “the next sections” describe the use of BPM elements in Choreography. But in 10.1.2, they describe the use of BPM elements in Processes.

    It should say:
    “Some BPMN elements are common to both Process and Choreography, as well as Collaboration; they are used in these diagrams. The next few sections will describe the use of Messages, Message Flows, Participants, Sequence Flows, Artifacts, Correlations, Expressions, and Services in Process.”

    “and Services in Choreography” should be replaced by “and Services in Process”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 255. Message End Event sends Messages

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

    Table 10.88. Row “”Message”.

    It says
    “The actual Participant from which the Message is received can be identified …”

    Table 10.88 describes End Event Types, so the Message can only be sent.

    Then, it should say
    “The actual Participant to which the Message is sent can be identified …”

    “from which” should be replaced by “to which”
    “is received” should be replaced by “is sent”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 190. Paragraph needs to be nested

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

    Paragraph:
    “If the details of the called Process are available, then the shape of the Call Activity will be the same as a expanded Sub-Process, but the boundary of the shape MUST have a thick line (see Figure 10.41).”

    This paragraph should be a sub-bullet of “If the Call Activity calls a Process, then there are two (2) options:”, because it describes the second option.

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 78. Wrong association type in Table 8.32

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

    Table 8.32. Row “type”

    It says
    “type: string [0..1]

    Model Association “type” is an “ItemDefinition” (see Figure 8.17, page 76).

    Then, it should say
    “type: ItemDefinition [0..1]

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pages 221-223. Inheritance of DataInput, DataOutput. Wrong table reference

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

    a) Page 221

    It says:
    “The DataInput element inherits the attributes and model associations of BaseElement (see Table 8.5) and ItemAwareElement (Table 10.52).”

    DataInput is subclass of ItemAwareElement, which is subclass of BaseElement (see Figure 10.50, p.211). Furthermore, attributes and model associations of ItemAwareElement are shown in Table 10.51.

    Then, it should say:
    “The DataInput element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to ItemAwareElement (Table 10.51).”
    ----------------------------------------------------------------------------------------------------

    b) Page 223
    It says:
    “The DataOutput element inherits the attributes and model associations of BaseElement (see Table 8.5) and ItemAwareElement (Table 10.52).”

    DataOutput is subclass of ItemAwareElement, which is subclass of BaseElement (see Figure 10.50, p.211). Furthermore, attributes and model associations of ItemAwareElement are shown in Table 10.51.

    Then, it should say:
    “The DataOutput element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to ItemAwareElement (Table 10.51).”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 221. Nonexistent attribute “optional” mentioned

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

    It says
    “The “optional” attribute defines if a DataInput is valid even if the state is “unavailable”. The default value is false. If the value of this attribute is true, then the execution of the Activity will not begin until a value is assigned to the DataInput element, through the corresponding Data Associations.”

    Problem: The “optional” attribute of “DatInput” is mentioned, but it is not shown in any Table or Figure (in particular Figure 10.59, p. 221; and Table 10.59, p. 222).

    This paragraph should be removed; or the attribute “optional” should be added in Table 10.59 and Figure 10.59.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 308. Incorrect name of Parallel Event-Based Gateway 1

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

    It says:
    “The Parallel Event Gateway is also a type of race condition...”

    It should say:
    “The Parallel Event-Based Gateway is also a type of race condition ...”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 202. Wrong multiplicity of model association “event”

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

    Table 10.31. Row “event”.

    It says:
    “event: ImplicitThrowEvent”

    Model association “event” is optional, see Figure 10.45 (p.196).

    Then, it should say:
    “event: ImplicitThrowEvent [0..1]

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 192. Association “calledElementRef”: wrong name, location and description

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

    Figure 10.42. and Table 10.23.

    a) Figure 10.42

    Model association from “CallActivity” to “CallableElement”.
    Role name “calledElementRef” is located near class “CallActivity”, but it must be located near class CallableElement.
    ---------------------------------------------------------------------

    b) Table 10.23. Row “calledElement”
    It says:
    “calledElement: CallableElement [0..1]

    It should say:
    “calledElementRef: CallableElement [0..1]

    “calledElement” should be replaced by “calledElementRef”
    ----------------------------------------------------------------------

    c) Table 10.23. Row “calledElement”

    It says:
    “… MUST NOT be called by the Call Conversation element.”

    Table 10.23 describes “CallActivity” model associations, not “Call Conversation” model associations (Table 9.12, p. 134).

    Then, it should say:
    “… MUST NOT be called by the Call Activity element.”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pages 230-231. Wrong name of Table 10.64

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

    “Assignment” has no attributes and two model associations (see Figure 10.64, p.229).

    Page 230.

    It says:
    “Table 10.64 presents the additional attributes of the Assignment element:”

    It should say:
    “Table 10.64 presents the additional model associations of the Assignment element:”
    --------------------------------------------------------------------------
    Page 231.

    It says:
    “Table 10.64 ­ Assignment attributes”

    It should say:
    “Table 10.64 ­ Assignment model associations”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 230. Super-class of ”Assignment” not shown in any diagram

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

    It says:
    “The Assignment element inherits the attributes and model associations of BaseElement (see Table 8.5).”

    But, it is not shown in any diagram that “Assignment” is subclass of “Base Element”.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 266. Wrong role name "attachedToRef" in Table 10.91

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

    Table 10.91. Row “attachedTo”

    It says:
    “attachedTo: Activity”

    It should say:
    “attachedToRef: Activity”

    See Figure 10.69 (p.241).

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 241. Wrong role names in Figure 10.69

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

    Figure 10.69.

    a) Role name “dataOutputAssociation” (from “CatchEvent” to “DataOutputAssociation”) should be “dataOutputAssociations”.

    See Table 10.82 (p. 243). Row “dataOutputAssociations”
    ---------------------------------------------------------------------------------------

    b) Role name “dataInputAssociation” (from “ThrowEvent” to “DataInputAssociation”) should be “dataInputAssociations”.

    See table 10.83 (p. 245). Row “dataInputAssociations”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 230. Wrong type of model association “transformation”

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

    Table 10.63. Row “transformation”.

    It says:
    “transformation: Expression [0..1]

    “transformation” is a role name of the association from “DataAssociation” to “FormalExpression” (see Figure 10.64, p.229). So the type is not “Expression”, but “FormalExpression”.

    Then, it should say:
    “transformation: FormalExpression [0..1]

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 185. Nonexistent enumeration used in Table 10.21

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

    Table 10.21 and Figure 10.29 (p. 181)

    Enumeration TransactionMethod was removed from Figure 10.29 (p.181), but it is still used in Table 10.21 (p.185) in attribute “method”.

    Maybe “method: TransactionMethod” should be replaced by “method: string” as it is defined in Figure 10.29.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 231. Activity is not an Item Aware Element

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

    It says:
    “…one from a item-aware element (e.g., an Activity) contained by the source of the Sequence Flow, …”

    “Activity” is not an item-aware element, but it contains an item-aware element (see Figure 10.50, p. 211; Figure 10.57, p. 219).

    Then, it should say:
    “…one from an item-aware element contained by the source of the Sequence Flow (e.g., an Activity), …”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 274. Wrong role name “errorRef” in Table 10.96

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

    Table 10.96. Row “error”

    It says:
    “error: Error [0..1]

    It should say:
    “errorRef: Error [0..1]

    See Figure 10.80 (p.274).

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter 10. Typos

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

    a) Section 10. Page 151.

    Table 10.1. Row “processType”.

    It says
    “The processType attribute Provides additional information …”

    It should say
    “The processType attribute provides additional information …”

    “Provides” should be replaced by “provides”.
    ----------------------------------------------------------

    b) Section 10.2. Page 157.

    Table 10.3. Row “completionQuantity”.

    It says
    “This number of tokens will be sent done ...”

    It should say
    “This number of tokens will be sent down ...”

    “sent done” should be replaced by “sent down ”
    ----------------------------------------------------------

    c) Section 10.2.3. Page 161.

    The words “marker” and “Marked” are nor used consistently throughout the text. For example:

    On p. 161:
    “The loop Marker MAY be used in combination with the compensation marker.”

    On p. 197:
    “The loop Marker MAY be used in combination with the Compensation Marker.”

    On p.198:
    “The Multi-Instance marker MAY be used in combination with the Compensation marker.”
    ----------------------------------------------------------

    d) Section 10.2.4. Page 170.

    It says
    “Manual Tasks and User Tasks have a Icons to indicate ...”

    It should say
    “Manual Tasks and User Tasks have icons to indicate ...”

    “a Icons” should be replaced by “icons”
    ----------------------------------------------------------

    e) Section 10.3.1. Page 224.

    It says
    “…the payloard within the Message will not flow out of the Receive Task and into the Process.”

    It should say
    “…the payload within the Message will not flow out of the Receive Task and into the Process.”

    “payloard” should be replaced by “payload”
    ----------------------------------------------------------

    f) Section 10.3.1. Page 231.

    It says
    “… a DataOutput contained within an ACTIVITY with any ItemAwareElement accessible …”

    It should say
    “… a DataOutput contained within an Activity with any ItemAwareElement accessible …”

    “ACTIVITY” should be replaced by “Activity”
    ----------------------------------------------------------

    g) Section 10.3.1. Page 231.

    It says
    “…one from a item-aware element … to a item-aware element …”

    It should say
    “…one from an item-aware element … to an item-aware element …”

    “a item-aware” should be replaced (twice) by “an item-aware”
    ----------------------------------------------------------

    h) Section 10.4.2. Page 248.

    Table 10.84. Row “Multiple”
    It says
    “(a pentagon—see the upper figure to the right)”

    It should say
    “(a pentagon—see figure to the right)”

    “see the upper figure” should be replaced by “see figure”
    ----------------------------------------------------------

    i) Section 10.4.4. Page 263.

    Table 10.90. Row “Compensation”.

    It says
    “Note that the interrupting a non-interrupting aspect of ...”

    It should say
    “Note that the interrupting and non-interrupting aspect of ...”

    “a non-interrupting” should be replaced by “and non-interrupting”
    ----------------------------------------------------------

    j) Section 10.4.5. Page 273.

    Paragraph
    “The ConditionalEventDefinition element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to the EventDefinition element (see page 268). Table 10.95 presents the additional model associations of the ConditionalEventDefinition element:”

    It is repeated twice. The first one should be removed.
    ----------------------------------------------------------

    k) Section 10.4.5. Page 275.

    It says
    “When used to “throw” to the target Link, the Event marker will be filled (see Figure 10.84: upper: lower Left).”

    It should say
    “When used to “throw” to the target Link, the Event marker will be filled (see Figure 10.84: lower left).”

    “upper: lower Left” should be replaced by “lower left”

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter 9. Typos

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

    a) Section 9.4. Page 125.

    9.4 Conversations

    It says
    “The Conversation diagram is particular usage of and an informal description …”

    It should say
    “The Conversation diagram is a particular usage of and an informal description …”

    “is particular usage” should be replaced by “is a particular usage”
    ----------------------------------------------------------

    b) Section 9.4. Page 128.

    It says
    “Figure 9.20 shows a how the Sub-Conversation of ...”

    It should say
    “Figure 9.20 shows how the Sub-Conversation of ...”

    “a how” should be replaced by “how”
    ----------------------------------------------------------

    c) Section 9.4. Page 129.

    It says
    “Figure 9.21 shows a how the Conversation of...”

    It should say
    “Figure 9.21 shows how the Conversation of...”

    “a how” should be replaced by “how”
    ----------------------------------------------------------

    d) Section 9.4.4. Page 134.

    Table 9.12. Row “calledCollaborationRef”

    It says
    “Collaboratioin [0..1]

    It should say
    “Collaboration [0..1]

    “Collaboratioin” should be replaced by “Collaboration”
    ----------------------------------------------------------

    e) Section 9.4.5. Page 134.

    It says
    “The GlobalConversation element inherits the attributes and model associations and Collaboration …”

    It should say
    “The GlobalConversation element inherits the attributes and model associations of Collaboration”

    “and Collaboration” should be replaced by “of Collaboration”
    ----------------------------------------------------------

    f) Section 9.4.6. Page 137.

    It says
    “…on the left with a Call Conversations to a Collaboration on the right.”

    It should say
    “…on the left with a Call Conversation to a Collaboration on the right.”

    “Conversations” should be replaced by “Conversation”
    ----------------------------------------------------------

    g) Section 9.4.6. Page 138.

    It says
    “For example, the Credit Agency Participants on the right corresponds …”

    It should say
    “For example, the Credit Agency Participant on the right corresponds …”

    “Participants” should be replaced by “Participant”
    ----------------------------------------------------------

    h) Section 9.4.8. Page 139.

    It says
    “ … and can be defined for the Message Flows that belong to the a Conversation.”

    It should say
    “…and can be defined for the Message Flows that belong to a Conversation.”

    “to the a” should be replaced by “to a”
    ----------------------------------------------------------

    i) Section 9.4.8. Page 140.

    It says
    “…if the conceptual data comprises of an order than the correlation field might be denoted …”

    It should say
    “…if the conceptual data comprises of an order then the correlation field might be denoted …”

    “than” should be replaced by “then ”

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter 8. Typos

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

    a) Section 8.2.3. Page 59.

    Table 8.10. Row “value”.

    It says
    “[Element [0..1]

    It should say
    “Element [0..1]

    First “[” should be removed
    ----------------------------------------------------------

    b) Section 8.2.3. Page 59.

    Table 8.10. Row “valueRef”.

    It says
    “[Element [0..1]

    It should say
    “Element [0..1]

    First “[” should be removed
    ----------------------------------------------------------

    c) Section 8.2.4. Page 62.

    It says
    “The ‘identity/relationship’ model it is reduced to the creation of families of typed relationships …”

    It should say
    “The ‘identity/relationship’ model is reduced to the creation of families of typed relationships …”

    “model it is reduced” should be replaced by “model is reduced”
    ----------------------------------------------------------

    d) Section 8.2.4. Page 63.

    Table 8.15. Row “sources”.

    It says
    “[Element [1..*]

    It should say
    “Element [1..*]

    First “[” should be removed
    ----------------------------------------------------------

    e) Section 8.2.4. Page 63.

    Table 8.15. Row “targets”.

    It says
    “[Element [1..*]

    It should say
    “Element [1..*]

    First “[” should be removed
    ----------------------------------------------------------

    f) Section 8.3.1. Page 67.

    It says
    “An Association is line that MUST be drawn …”

    It should say
    “An Association is a line that MUST be drawn …”

    “is line” should be replaced by “is a line”
    ----------------------------------------------------------

    g) Section 8.3.9. Page 90.

    It says
    “The details for the types of Gateways (Exclusive, Inclusive, Parallel, Event-Based, and Complex) is defined on page 295 …”

    It should say
    “The details for the types of Gateways (Exclusive, Inclusive, Parallel, Event-Based, and Complex) are defined on page 295 …”

    “is defined” should be replaced by “are defined”
    ----------------------------------------------------------

    h) Section 8.3.10. Page 92.

    Table 8.47. Row “structureRef”.

    It says
    “[Element [0..1]

    It should say
    “Element [0..1]

    First “[” should be removed
    ----------------------------------------------------------

    i) Section 8.3.11. Page 93.

    It says
    “In a Message is a rectangle with converging diagonal lines in the upper …”

    It should say
    “A Message is a rectangle with converging diagonal lines in the upper …”

    “In a” should be replaced by “A”
    ----------------------------------------------------------

    j) Section 8.3.12. Page 96.

    It says
    “These parameters can be used at runtime to define query e.g., into an …”

    It should say
    “These parameters can be used at runtime to define a query e.g., into an …”

    “define query” should be replaced by “define a query”

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter 7. Typos

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

    a) Section 7. Page 21.

    It says
    “BPMN provides a multiple diagrams, which are designed for use by the people who design and manage Business Processes.”

    It should say
    “BPMN provides multiple diagrams, which are designed for use by the people who design and manage Business Processes.”

    “a multiple” should be replaced by “multiple”
    ----------------------------------------------------------

    b) Section 7.2.2. Page 34.

    In table 7.2. Row “Conditional flow”

    It says
    “A Sequence Flow can have a condition Expression that are evaluated at runtime …”

    It should say
    “A Sequence Flow can have a condition Expression that is evaluated at runtime …”

    “that are evaluated” should be replaced by “that is evaluated”
    ----------------------------------------------------------

    c) Section 7.2.2. Page 34.

    In table 7.2. Row “Default flow”

    It says
    “These Sequence Flows will have a diagonal slash will be added to the beginning of the connector …”

    It should say
    “These Sequence Flows will have a diagonal slash added to the beginning of the connector …”

    “slash will be added” should be replaced by “slash added”
    ----------------------------------------------------------

    d) Section 7.2.2. Page 36.

    In table 7.2. Row “Fork”.

    It says
    “This represents “uncontrolled” flow is the preferred method for most situations.”

    It should say
    “This represents “uncontrolled” flow which is the preferred method for most situations.”

    “flow is” should be replaced by “flow which is”
    ----------------------------------------------------------

    e) Section 7.2.2. Page 39.

    Table 7.2. Row “Mutiple Instances”.

    It says
    “A set of three (3) horizontal liness will be displayed at the bottom-center of the activity for sequentail Multi-Instances (see upper figure to the right). A set of three (3) vertical liness will be displayed at the bottom-center of the activity for sequentail Multi-Instances (see lower figure to the right).”

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

    “horizontal liness” should be replaced by “horizontal lines”
    first “sequentail Multi-Instances” should be replaced by “sequential Multi-Instances”
    “vertical liness” should be replaced by “vertical lines”
    second “sequentail Multi-Instances” should be replaced by “parallel Multi-Instances”

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter 11. Typos

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

    a) Section 11.3.1. Page 330.

    It says
    “Because the other outgoing Sequence Flows will have appropriately visible of data as described above, …”

    It should say
    “Because the other outgoing Sequence Flows will have appropriate visibility of data as described above, …”

    “have appropriately visible” should be replaced by “have appropriate visibility”
    ----------------------------------------------------------

    b) Section 11.4.1. Page 337.

    It says
    “The width of the Participant Band will be expanded to contain both the name of the Participant and the multi-instance marker.”

    It should say
    “The high of the Participant Band will be expanded to contain both the name of the Participant and the multi-instance marker.”

    “width” should be replaced by “high”

    Note: On page 342 this (equivalent) sentence is a sub-bullet.
    ----------------------------------------------------------

    c) Section 11.4.2. Page 341.

    It says
    “In addition, any Participant Band beyond the first two optional; ...”

    It should say
    “In addition, any Participant Band beyond the first two is optional; ...”

    “two optional” should be replaced by “two is optional”
    ----------------------------------------------------------

    d) Section 11.4.2. Page 342.

    It says
    “The width of the Participant Band will be expanded to contain both the name of the Participant and the multi-instance marker.”

    It should say
    “The high of the Participant Band will be expanded to contain both the name of the Participant and the multi-instance marker.”

    “width” should be replaced by “high”

    Note: On page 337 this (equivalent) sentence is not a sub-bullet.
    ----------------------------------------------------------

    e) Section 11.4.2. Page 342.

    Figure 11.23.

    It says
    “Figure 11.23 - Sub-Choreography Markers with a multi-instance Participant”

    It should say
    “Figure 11.23 ­ A Sub-Choreography with a multi-instance Participant”

    “Sub-Choreography Markers” should be replaced by “A Sub-Choreography”

    Note: Compare it with Figure 11.15, p.337.
    ----------------------------------------------------------

    f) Section 11.4.6. Page 345.

    It says
    “…when the Participants send or receive Messages so that they Participants are NOT REQUIRED to guess about when it is their turn to send a Message.”

    It should say
    “…when the Participants send or receive Messages so that the Participants are NOT REQUIRED to guess about when it is their turn to send a Message.”

    “they Participants” should be replaced by “the Participants”

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter14. Typos

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

    a) Section 14.1.1. Page 463.

    It says
    “The following figure describes the mapping of a Process, represented by its defining Collaboration, to WS-BPEL. The process itself is described by a contained graph G of flow elements) to WS-BPEL.”

    Maybe it should say
    “The following figure describes the mapping of a Process, represented by its defining Collaboration, to WS-BPEL. The process itself is described by a contained graph G of flow elements.”

    “elements) to WS-BPEL” should be replaced by “elements”
    ----------------------------------------------------------

    b) Section 14.1.2. Page 466.

    It says
    “(i.e., Message Events, Service, send or Receive Tasks)”

    It should say
    “(i.e., Message Events, Service, Send or Receive Tasks)”

    “send” should be replaced by “Send”.

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Chapter 13. Typos

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

    ) Section 13.1. Page 440.

    It says
    “A token reaching an End Event triggers the behavior associated with the Event type is, …”

    It should say
    “A token reaching an End Event triggers the behavior associated with the Event type, …”

    “type is” should be replaced by “type”
    ----------------------------------------------------------

    b) Section 13.4.5. Page 457.

    It says
    “A compensation Event Sub-Process can in particular recursively trigger compensation for Activities contained in that its parent.”

    It should say
    “A compensation Event Sub-Process can in particular recursively trigger compensation for Activities contained in its parent.”

    “in that its” should be replaced by “in its”
    ----------------------------------------------------------

    c) Section 13.4.5. Page 458.

    It says
    “Second, if no error Event Sub-Process is specified for a particular Sub-Process and a particular error, …”

    It should say
    “Second, if no error Event Sub-Process is specified for a particular Sub-Process and a particular error occurs, …”

    “particular error,” should be replaced by “particular error occurs,”

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 485. Wrong reference to figure 14.2

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

    It says
    “End Events can be combined with other BPMN objects to complete the merging or joining of the paths of a WSBPEL structured element (see Figure 7.3).”

    It should say
    “End Events can be combined with other BPMN objects to complete the merging or joining of the paths of a WSBPEL structured element (see Figure 14.2).”

    “Figure 7.3” should be replaced by “Figure 14.2”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 313. Wrong references to figures 10.123 10.124

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

    It says
    “A Lane is a sub-partition within a Process (often within a Pool) and will extend the entire length of the Process level,, either vertically (see Figure 10.122) or horizontally (see Figure 10.123).”

    It should say
    “A Lane is a sub-partition within a Process (often within a Pool) and will extend the entire length of the Process level,, either vertically (see Figure 10.123) or horizontally (see Figure 10.124).”

    “Figure 10.122” should be replaced by “Figure 10.123”
    “Figure 10.123” should be replaced by “Figure 10.124”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 231. Wrong reference to table 10.63 2

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

    It says
    “The DataOutputAssociation element inherits the attributes and model associations of DataAssociation (see Table 10.64), but does not contain any additional attributes or model associations.”

    It should say
    “The DataOutputAssociation element inherits the attributes and model associations of DataAssociation (see Table 10.63), but does not contain any additional attributes or model associations.”

    “Table 10.64” should be replaced by “Table 10.63

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 231. Wrong reference to table 10.63 1

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

    It says
    “The DataInputAssociation element inherits the attributes and model associations of DataAssociation (see Table 10.64), but does not contain any additional attributes or model associations.”

    It should say
    “The DataInputAssociation element inherits the attributes and model associations of DataAssociation (see Table 10.63), but does not contain any additional attributes or model associations.”

    “Table 10.64” should be replaced by “Table 10.63”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 248. Wrong reference to table 10.85

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

    It says
    “There is only one (1) type of Start Event for Sub-Processes in BPMN (see Figure 10.82): None.”

    It should say
    “There is only one (1) type of Start Event for Sub-Processes in BPMN (see Table 10.85): None.”

    “Figure 10.82” should be replaced by “Table 10.85”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 245. Wrong reference to table 10.83

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

    It says
    “The ImplicitThrowEvent element inherits the attributes and model associations of ThrowEvent (see Table 10.84), …”

    It should say
    “The ImplicitThrowEvent element inherits the attributes and model associations of ThrowEvent (see Table 10.83), …”

    “Table 10.84” should be replaced by “Table 10.83”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page. 300. Wrong reference to page 450

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

    It says
    “The precise synchronization behavior of the Inclusive Gateway can be found on page 300.”

    It should say
    “The precise synchronization behavior of the Inclusive Gateway can be found on page 450.”

    “page 300” should be replaced by “page 450”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 266. Wrong reference to table 10.91

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

    It says
    “Table 8.46 presents the additional attributes and model associations of the Boundary Event element:”

    It should say
    “Table 10.91 presents the additional attributes and model associations of the Boundary Event element:”

    “Table 8.46” should be replaced by “Table 10.91”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Left over restrictions on use of Start and End Events

  • Key: BPMN21-137
  • Legacy Issue Number: 15509
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Issue 14783 relaxed the restrictions on the use of Start and End Events. But there are two statements in the spec that are left over.
    On page 248:
    "If there is an End Event, then there MUST be at least one Start Event."
    This should be removed

    On page 256:
    "If there is a Start Event, then there MUST be at least one End Event."
    This should be removed

  • Reported: BPMN 2.0 — Fri, 10 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Conditions for completion of Process and Sub-Process

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

    i) Chapter/Section 10.4.2. Page 245. It says:

    “There MAY be multiple Start Events for a given Process level.

    • Each Start Event is an independent Event. That is, a Process instance SHALL be generated when
      the Start Event is triggered.”

    ii) Chapter/Section 13.1. Page 440. It says:

    “To specify that the instantiation of a Process waits for multiple Start Events to happen, a Multiple Parallel Start
    Event can be used.”

    “Note that two Start Events are alternative, A Process instance triggered by one (1) of the Start Events does not wait
    for an alternative Start Event to occur.”

    “Note that there MAY be multiple instantiating Parallel Event-Based Gateways.
    This allows the modeler to express that either all the Events after the first Gateway occur or all the
    Events after the second Gateway and so forth.”

    “Each Start Event that occurs creates a token on its outgoing Sequence Flows, which is followed as described by the
    semantics of the other Process elements.”

    iii) Chapter/Section 13.4.6. Page 458. It says:
    “The Process instance is then completed, if and only if the following two conditions hold:”

    • All start nodes of the Process have been visited. More precisely, all Start Events have been triggered,
      and for all starting Event-Based Gateways, one of the associated Events has been triggered.”

    iv) Chapter/Section 13.4.6. Page 459. It says:
    “The Sub-Process instance is then completed, if and only if the following two conditions hold:

    • All start nodes of the Sub-Process have been visited. More precisely, all Start Events have been triggered,
      And for all starting Event-Based Gateways, one of the associated Events has been triggered.”

    COMMENTS:

    >From and (ii) can be deduced that each tart node (start event or start event-based gateway) is independent, i.e. the activation of one of them generates an new independent instance of the Process.

    But in (iii) and (iv) it is said that all start nodes must be visited as a pre-condition to complete the execution of the Process instance. This contradicts what it is stated in and (ii).

    SUGGESTIONS:

    Modify (iii) and (iv) to make them consistent with what it is stated in and (ii).

    Typo in (ii): “… are alternative, A Process instance…” should be replaced by “… are alternative. A Process instance…”

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Apparent contradiction concerning compensation handler invocations

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

    i) Chapter/Section 13.4.5. Page 457. It says:
    “Triggering compensation for the Multi-Instance Sub-Process individually triggers compensation for all instances within the current scope. If compensation is specified via a boundary compensation handler, this boundary compensation handler also is invoked once for each instance of the Multi-Instance Sub-Process in the current scope.”

    ii) Chapter/Section 13.4.5. Page 458. It says:
    “In case the Activity is a multi-instance or loop, the Compensation Activity is triggered only once, too, and thus has to compensate the effects of all instances.”

    COMMENTS:

    It seems there is a contradiction between and (ii).

    • In there are as many invocations as instances are.
    • In (ii) there is only one invocation for many instances.

    SUGGESTIONS:

    Clarify whether there is a contradiction or not.

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Table 10.56 is named Data Store attributes instead of Data Store Reference attributes

  • Key: BPMN21-258
  • Legacy Issue Number: 15809
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    On page 217 Table 10.56 is named Data Store attributes instead of Data Store Reference attributes.

    Table 10.55 shows the real Data Store attributes. In addition, the last sentence on page 216 rightly specifies: "Table 10.56 presents the additional model associations of the Data Store Reference element:".

  • Reported: BPMN 2.0 — Wed, 10 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Outgoing Paths after Inclusive Gateway

  • Key: BPMN21-257
  • Legacy Issue Number: 15808
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    I think that the number of outgoing paths after an Inclusive Gateway are conflicting. According to page 37 and page 300, all combinations of paths MAY be taken, from zero to all. However, on page 362 it is mentioned several times that one or more alternative branches are chosen (one of more
    branches MAY be activated upstream). The difference is taking zero paths.

    Is it possible to take zero paths after an Inclusive Gateway? If yes, is the process flow interrupted or can the flow just continue after a later merge? What happens if there is no corresponding merge for the split? It seems that taking zero paths is possible based on the conditions which are evaluated separately.

    However, I think, that the specification from page 362 should be taken and that one or more outgoing paths receive a token. Then A OR B can also be transformed to (A XOR B) XOR (A AND B). Also the definition of logical disjunction is that one or more of its operands are true (according to the truth table A OR B is only false if A is false and B is false).

    If the intention behind taking zero paths is that it should be possible to execute non of the tasks, then my second suggestion would be to define that an "empty" path is mandatory and if no task should be executed then a token can be sent on the "empty" path.

    Also if the separately evaluated conditions are the reason for allowing zero paths, again a mandataroy empty default path could be a solution to avoid that the inclusive split contradicts with the logical disjunction.

    As Inclusive Gateways are a very complex topic a discussion would be interesting.

  • Reported: BPMN 2.0 — Tue, 9 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong configuration of Event-Based Gateway

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

    i) Chapter/Section 10.5.6. Page 306. It says:
    “Event-Based Gateways are configured by having outgoing Sequence Flows target an Intermediate Event
    or a Receive Task in any combination (see Figure 10.116 and Figure 10.117) except that:

    • If Message Intermediate Events are used in the configuration, then Receive Tasks MUST NOT be used
      in that configuration and vice versa.”

    ii) Chapter/Section 10.5.
    Page 298: “A diverging Exclusive Gateway (Decision) ...”
    Page 300: “A diverging Inclusive Gateway (Inclusive Decision) …”
    Page 305: “The Event-Based Gateway represents a branching point in the Process where the alternative paths
    that follow the Gateway are based on Events that occur, rather than the evaluation of Expressions
    using Process data (as with an Exclusive or Inclusive Gateway).”

    iii) Chapter/Section 14.1.4. Page 478. Sub-section “Exclusive (Event-based) Decision Pattern”.
    Figure shows tree branches with one Message Intermediate Event, one Receive Task
    and one Timer Intermediate Event.

    COMMENTS:

    According to Message Intermediate Events and Receive Tasks MUST NOT be used in the same configuration of an Event-Based Gateway. Nevertheless, in (iii) both are used in the same configuration.

    According to (ii) Exclusive and Inclusive Gateways are considered “decisions”, but not Event-Based Gateways.

    SUGGESTIONS:

    Modify Figure in Sub-section “Exclusive (Event-based) Decision Pattern”: use Message Intermediate Events or Receive Tasks, but not both.

    Name the Sub-section: “Exclusive (Event-based) Pattern”

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 473.Wrong reference to figure

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

    Chapter/Section 14.1.3. Page 473. Sub-section “Message End Events” It says:
    “A Message Start Event is mapped to WS-BPEL as shown in the following figure:”

    SUGGESTIONS:

    It should say:
    “A Message End Event is mapped to WS-BPEL as shown in the following figure:”

    “Start Event” should be replaced by “End Event”

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

In Chapter 14 Figures are not numbered

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

    In Chapter 14 Figures and Tables are not numbered.

    COMMENTS:

    The absence of numbers in Figures and Tables complicates the reading.
    Furthermore, in the rest of the document the Figures and Tables are numbered.

    SUGGESTIONS:

    Number Figures and Tables in Chapter 14.

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Legal BPMN models and “lack of synchronization"

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

    ) Chapter/Section 10.2. Page 157. Table 10.3. Row “completionQuantity”. It says:
    “This attribute defines the number of tokens that MUST be generated from the Activity. This number of tokens will be sent down any outgoing Sequence Flow …”

    ii) Chapter/Section 13.3.5. Page 452. It says:
    “Each incoming gate of the Complex Gateway has an attribute activationCount, which can be used in an Expression as an integer-valued variable. This variable represents the number of tokens that are currently on the respective incoming Sequence Flow.”

    iii) Chapter/Section 14. Page 461. It says:
    “To map a BPMN orchestration Process to WS-BPEL it MUST be sound, that is it MUST contain neither a deadlock nor a lack of synchronization. A deadlock is a reachable state of the Process that contains a token on some Sequence Flow that cannot be removed in any possible future. A lack of synchronization is a reachable state of the Process where there is more than one token on some Sequence Flow.”

    COMMENTS:

    >From and (ii) can be deduced that a correct BPMN model allows Process instances with Sequence Flows containing more than one token.

    According to (iii) this is considered a “lack of synchronization”, which prevents the mapping to WS-BPEL.

    SUGGESTIONS:

    Clarify whether “lack of synchronization” means that the Model is illegal or not.

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

“empty Start Event” is used instead of “None Start Event”

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

    In Chapter 13 the expression “empty Start Event” is used instead of “None Start Event”, the latter is used in all other Chapters.

    SUGGESTION:

    Use “the expression “None Start Event” in order to be consistent with the rest of the document.

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Terminate End Event in a Choreography with many Participants

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

    i) Chapter/Section 11.5.3. Page 354. Table 11.8. Row “Terminate”. It says:
    “The use of the Terminate End Event really only works when there are
    only two (2) Participants. If there are more than two (2) Participants, then any
    Participant that was not involved in the last Choreography Task would not necessarily
    know that the Terminate End Event had been reached.”

    ii) Chapter/Section 11.6.5. Page 371. Figure 11.48.
    Four (4) Participants (Purchaser and Service Providers A, B, C) are involved, and it ends with a Terminate End Event.

    COMMENTS:

    According to , the Terminate End Event in Choreography depicted in (ii) doesn’t work.

    In it is said “any Participant that was not involved in the last Choreography Task would not necessarily know that the Terminate End Event had been reached”, so it seems that in some cases Terminate End Event could work when there are
    More than two (2) Participants.

    SUGGESTIONS:

    Clarify whether the Terminate End Event in Figure 11.48 works or not.

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reference calledChoreographyRef of CallChoreography refers to Choreography and to CallableElement

  • Key: BPMN21-256
  • Legacy Issue Number: 15807
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    The calledChoreographyRef of CallChoreography refers to different Elements and is therefore conflicting.

    According to the class diagram (Figure 11.27) CallChoreography has a relationship calledChoreographyRef that references Choreography.

    According to the Model Associations on page 345, calledChoreographyRef references CallableElement.

    I think that based on the other text the relationship to Choreography is correct. The Model Associations should be corrected.

  • Reported: BPMN 2.0 — Tue, 9 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 10.127, private process supports public process

  • Key: BPMN21-255
  • Legacy Issue Number: 15806
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    In Figure 10.127, one process supports another. According to the corresponding text a message is sent and afterwards received and the same order is required by the public and the private process.

    However, in the figure the private process sents and receives a message, but the public process first receives message A and then sends message B. The order seems to be not identical.

  • Reported: BPMN 2.0 — Mon, 8 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Restrictions for Relative and Absolute Timers are the same

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

    Chapter/Section 11.6.2. Page 360. It says:

    “For relative timers: All Participants on the right side of the Gateway MUST be involved in the Choreography Activity that immediately precedes the Gateway.”

    “For absolute timers (full time/date): All Participants on the right side of the Gateway MUST be involved in the Choreography Activity that immediately precedes the Gateway.”

    COMMENTS:

    The restrictions for Relative and Absolute Timers are exactly the same.

    SUGGESTIONS:
    If both restrictions are the same, collapse them into one bullet.

    If the restrictions are different, modify them accordingly.

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pages 467-468. Missing Figure

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

    i) Chapter/Section 14.1.2. Page 467. It says:
    “The following figure shows the mapping of a BPMN Sub-Process without an Event Sub-Process:”

    ii) Chapter/Section 14.1.2. Page 468. It says:
    “The following figure shows the mapping of a BPMN Sub-Process with an Event Sub-Process. (Event Sub- Processes could also be added to a top-level Process, in which case their mapping extends correspondingly.)”

    COMMENTS:

    After there is no Figure. The Figure after (ii) seems to be the one that must be located after .

    SUGGESTIONS:

    Verify the correct position of the Figure located after (ii).

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Table 7.2 Element Data Object column "Notation" typo Data ObjecT (Collection)

  • Key: BPMN21-254
  • Legacy Issue Number: 15764
  • Status: open  
  • Source: Vienna University of Economics and Business ( Bernhard Hoisl)
  • Summary:

    Just a typo in Table 7.2 at Element "Data Object" on p. 35 in column "Notation". It is written "Data Objec (Collection)" but should say "Data Object (Collection)". The "t" is missing in the word "object".

  • Reported: BPMN 2.0 — Tue, 19 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Service Tasks can be the source or target of Messages Flows

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

    i) Chapter/Section 9.4.6. Page 135. It says:
    “Conversation Links into Activities that are not Send or Receive Tasks indicate that the Activity will send or receive Messages of the Conversation at some level of nesting.”

    ii) Chapter/Section 10. Page 153. Table 10.1. Row “definitionalCollaborationRef”. It says:
    “The definitional Collaboration specifies the Participants the Process interacts with, and more specifically, which individual service, Send or Receive Task, or Message Event, is connected to which Participant through Message Flows.”

    iii) Chapter/Section 10.2.3. Page 162. It says:
    “The actual Participant whose service is used can be identified by connecting the Service Task to a Participant using a Message Flows within the definitional Collaboration of the Process ­ see Table 10.1.”

    iv) Chapter/Section 10.2.3. Page 163. Figure 10.12.
    According to classes and their associations, ServiceTask is not directly associated to Message, but they are indirectly associated through Operation.

    v) Chapter/Section 11.4.6. Page 348. It says:
    “Usually in these cases, the initiating Participant will use a single Activity to handle both the sending and receiving of the Messages. A BPMN Service Task can be used for this purpose and these types of Tasks are often referred to as “request-response” Tasks for Choreography modelers.”

    vi) Chapter/Section 14.1.2. Page 464. It says:
    “The partner link associated with the WS-BPEL invoke is derived from both the participant Q that the Service Task is connected to by Mesage Flows, and from the interface referenced by the operation of the Service Task.”

    vii) Chapter/Section 14.1.2. Page 466. It says:
    “For those BPMN nodes sending or receiving Messages (i.e., Message Events, Service, send or Receive Tasks)
    that have an associated key-based Correlation Key, …”

    COMMENTS:

    >From (ii) to (vii) it can be deduced that Service Task can be the source and target of Message Flows.

    SUGGESTIONS:
    In it should say:
    “Conversation Links into Activities that are not Send, Receive or Service Tasks indicate that the Activity will send or receive Messages of the Conversation at some level of nesting.”

    Furthermore:
    In (ii) “which individual service, Send or” should be replaced by “which individual Service, Send or”

    In (iii) “Participant using a Message Flows within” should be replaced by “Participant using Message Flows within”

    In (vi) “Task is connected to by Mesage Flows” should be replaced by “Task is connected to by Message Flows”

    In (vii) “Service, send or Receive Tasks” should be replaced by “Service, Send or Receive Tasks”

  • Reported: BPMN 2.0 — Mon, 11 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Messages Flows can be attached to Events

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

    Chapter/Section 9.2. Page 113. It says:
    “Message Flows can cross the Pool boundary to attach to the appropriate Activity”

    COMMENTS:

    Messages Flows can be attached to Message Events (see Table 7.4, p. 44). If a Multiple Event (or Parallel Multiple Event) contains MessageEventDefinitions, it can be the source or the target of one or more Message Flows too.

    SUGGESTION:

    It should say:
    “Message Flows can cross the Pool boundary to attach to the appropriate Activity or Event”

  • Reported: BPMN 2.0 — Mon, 11 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect multiplicity of dataStoreRef

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

    i) Chapter/Section 10.3.1. Page 211. Figure 10.50.
    Role dataObjectRef (from DataObjectReference to DataObject) has multiplicity [1..1].
    Role dataStoreRef (from DataStoreReference to DataStore) has multiplicity [0..1].

    ii) Chapter/Section 10.3.1. Page 212. Figure 10.51.
    Role dataObjectRef (from DataObjectReference to DataObject) has multiplicity [1..1].

    iii) Chapter/Section 10.3.1. Page 213. Table 10.53. Row “dataObjectRef”. It says:
    “dataObjectRef: DataObject”
    It means that dataObjectRef is mandatory (multiplicity [1..1]).

    iv) Chapter/Section 10.3.1. Page 216. Figure 10.55.
    Role dataStoreRef (from DataStoreReference to DataStore) has multiplicity [0..1].

    v) Chapter/Section 10.3.1. Page 217. Table 10.56. Row “dataStoreRef”. It says:
    “dataStoreRef: DataStore”
    It means that dataStoreRef is mandatory (multiplicity [1..1]).

    COMMENTS:

    In and (iv) dataStoreRef is optional ([0..1])., but in (v) it is said that dataStoreRef is mandatory ([1..1]). Clearly there is contradiction concerning the multiplicity of dataStoreRef. Furthermore, a question arises: How can a DataStoreReference exist without a referenced DataStore?

    SUGGESTIONS:

    It seems that dataStoreRef should be mandatory (multiplicity [1..1]), if this is the case:

    In and (iv) change multiplicity of dataStoreRef from [0..1] to [1..1]

    (ii), (iii) and (v) don’t require modifications.

  • Reported: BPMN 2.0 — Mon, 11 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistencies concerning Item-Aware Elements

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

    ) Chapter/Section 10.3.1. Page 211. It says:
    “The elements in the specification defined as item-aware elements are: Data Objects, Data Object References, Data Stores, Properties, DataInputs and DataOutputs.”

    ii) Chapter/Section 10.3.1. Page 211. Figure 10.50.
    According to classes and their associations item-aware elements are:
    a) Properties
    b) Data Objects
    c) Data Object References
    d) DataInputs
    e) DataOutputs
    f) Data Stores
    g) Data Store References

    iii) Chapter/Section 10.3.1. Page 212. Figure 10.51.
    According to classes and their associations:
    DataObjectReference is subclass of FlowElement
    DataObject is subclass of FlowElement

    iv) Chapter/Section 10.3.1. Page 216. Figure 10.55.
    According to classes and their associations:
    DataStoreReference is subclass of FlowElement
    DataStore is subclass of RootElement

    v) Chapter/Section 10.3.1. Page 216. It says:
    “The DataStore element inherits the attributes and model associations of FlowElement (see Table 8.44) through its relationship to RootElement, and ItemAwareElement (see Table 10.51).”

    COMMENTS:

    In Data Stores Reference is not mentioned, but it is shown as a subclass of ItemAwareElement in (ii).

    In (iv) DataStore is not a subclass of FlowElement, as DataObjectReference, DataObject and DataStoreReference. In the document it is not explained the reason for this exclusion.

    In (v) the sentence is clearly wrong, because it is inconsistent with the class diagrams: RootElement is not subclass of FlowElement.

    SUGGESTIONS:

    In add Data Store References.

    In (iv) remove generalization from DataStore to RootElement, and add generalization from DataStore to FlowElement.

    Replace (v) with “The DataStore element inherits the attributes and model associations of FlowElement (see Table 8.44) and ItemAwareElement (Table 10.51).”

    (ii) and (iii) don’t require modifications.

  • Reported: BPMN 2.0 — Mon, 11 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistencies concerning Flow Elements

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

    i) Chapter/Section 8.3.7. Page 86. It says:
    “FlowElement is the abstract super class for all elements that can appear in a Process flow, which are FlowNodes (see page 99, which consist of Activities (see page 155), Choreography Activities (see page 331) Gateways (see page 295), and Events (see page 240)), Data Objects (see page 212), Data Associations (see page 228), and Sequence Flows (see page 97).”

    In other words, Flow Elements are:
    a) Flow Node
    a.1) Activity
    a.2) Choreography Activity
    a.3) Gateway
    a.4) Event
    b) Data Object
    c) Data Association
    d) Sequence Flow

    ii) Chapter/Section 8.3.7. Page 87. Figure 8.22
    According to classes and their associations Flow Elements are:
    a) Flow Node
    a.1) Activity
    a.2) Choreography Activity
    a.3) Gateway
    a.4) Event
    b) Data Object
    c) DataStoreReference
    d) Sequence Flow

    iii) Chapter/Section 8.3.8. Page 88. It says:
    “Basically, a FlowElementsContainer contains FlowElements, which are Events (see page 240), Gateways (see page 295), Sequence Flows (see page 97), Activities (see page 155), and Choreography Activities (see page 331).”

    In other words, Flow Elements are:
    a) Event
    b) Gateway
    c) Sequence Flow
    d) Activity
    e) Choreography Activity

    iv) Chapter/Section 8.3.8. Page 89. Table 8.45. It says: “Flow elements are Events, Gateways, Sequence Flows, Activities, Data Objects, Data Associations, and Choreography Activities.”

    In other words, Flow Elements are:
    a) Event
    b) Gateway
    c) Sequence Flow
    d) Activity
    e) Data Object
    f) Data Association
    g) Choreography Activity

    v) Chapter/Section 10.3.1. Page 212. Figure 10.51.
    According to classes and their associations:
    DataObjectReference is subclass of FlowElement
    DataObject is subclass of FlowElement

    vi) Chapter/Section 10.3.1. Page 216. Figure 10.55.
    According to classes and their associations:
    DataStoreReference is subclass of FlowElement
    DataStore is subclass of RootElement

    COMMENTS:

    In , (ii), (iii) and (iv) the lists of Flow Elements are different.

    In and (iv) DataAssociation is mentioned as a type of FlowElement, but it is not correct. See Figure 10.64 (p. 229), where it is shown that DataAssociation is direct subclass of BaseElement. Furthermore, DataAssociation in not shown as a subclass of FlowElement in (ii).

    In (ii) Data Association is replaced by DataStoreReference

    In (iii) Data Object, Data Association, and Data Store Reference are not mentioned.

    In (iv) DataObjectReference, DataStore and DataStoreReference are not mentioned.

    In (v) DataObjectReference is subclass of FlowElement, but it is not mentioned in , (ii), (iii) and (iv).

    In (vi) DataStore is not a subclass of FlowElement, as DataObjectReference, DataObject and DataStoreReference. In the document it is not explained the reason for this exclusion.

    SUGGESTIONS:

    It seems that Flow Elements are:

    a) Flow Node
    a.1) Activity
    a.2) Choreography Activity
    a.3) Gateway
    a.4) Event
    b) Data Object
    c) Data Object Reference
    d) Data Store
    e) Data Store Reference
    f) Sequence Flow

    If this is the case, then , (ii), (iii), (iv), and (vi) should be updated accordingly.

    In remove Data Association
    add Data Object Reference, Data Store and Data Store Reference.

    In (ii) add Data Object Reference, and Data Store.

    In (iii) add Data Object, Data Object Reference, Data Store, and Data Store Reference.

    In (iv) remove Data Association
    add Data Object Reference, Data Store and Data Store Reference.

    In (vi) remove generalization from DataStore to RootElement, and add generalization from DataStore to FlowElement.

    (v) doesn’t require modifications

  • Reported: BPMN 2.0 — Mon, 11 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 288. Typos

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

    Description:

    i) It says:
    “Interrupting Event Handlers are those that have the cancelActivity attribute is set to true.”

    It should say:
    “Interrupting Event Handlers are those that have the cancelActivity attribute set to true.”

    “is set to true” should be replaced by “set to true”

    ii) It says:
    “Interrupting Event Handlers are those that have the cancelActivity attribute is set to false.”

    It should say:
    “Non-interrupting Event Handlers are those that have the cancelActivity attribute set to false”

    “Interrupting” should be replaced by “Non-interrupting”

    “is set to false” should be replaced by “set to false”

  • Reported: BPMN 2.0 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

“cancelActivity” is not an attribute of Activity

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

    i) Chapter/Section 10.4. Page 241. Figure 10.69.
    Class BoundaryEvent has attribute cancelActivity
    (See Table 10.91, p. 266)

    ii) Chapter/Section 10.4.4. Page 262. Table 10.90. Rows “Message”, “Timer”, “Escalation”, “Conditional”, “Signal”, “Multiple” and “Parallel Multiple”
    It says:
    “Note that if using this notation, the attribute cancelActivity of the Activity to which the Event is attached is implicitly set to true.”

    or

    “Note that if using this notation, the attribute cancelActivity of the Activity to which the Event is attached is implicitly set to false.”

    iii) Chapter/Section 10.4.4. Page 266. Table 10.92.
    This Table doesn’t contain o row for Parallel Multiple Event.

    iv) Chapter/Section 13.4.3. Page 455. It says:
    “For boundary Events, handling first consists of consuming the Event occurrence. If the cancelActivity attribute is
    set, the Activity the Event is attached to is then cancelled (in case of a multi-instance, all its instances are cancelled); if
    the attribute is not set, the Activity continues execution (only possible for Message, Signal, Timer, and Conditional
    Events, not for Error Events). Execution then follows the Sequence Flow connected to the boundary Event.”

    COMMENTS:

    According to the meta-model cancelActivity is an attribute of BoundaryEvent, but in (ii) it is said that it is an attribute of Activity.

    In (iii) a row is needed for Parallel Multiple.

    In (iv) it is suggested that cancelActivity is optional. This is not the case, cancelActivity is mandatory: it is always set (to true or to false).

    SUGGESTIONS:

    In (ii)
    “the attribute cancelActivity of the Activity” should be replaced by “the attribute cancelActivity of the BoundaryEvent” (14 times)

    In (iii) add an additional row for Parallel Multiple.

    In (iv)
    “If the cancelActivity attribute is set,” should be replaced by “If the cancelActivity attribute is set to true,”

    “if the attribute is not set” should be replaced by “if the attribute is set to false”

  • Reported: BPMN 2.0 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Intermediate Message Event can be source or target of Message Flow

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

    Chapter/Section 10.4.4. Page 259. Table 10.89. Row “Message”. It says:
    “The actual Participant from which the Message is received can be identified by connecting the Event to a Participant using a Message Flow …”

    COMMENTS:

    The description is devoted to both throw and catch Intermediate Message Events, but it is only described the Participant associated with the catch Event.

    SUGGESTION:

    It should say:
    “The actual Participant from which the Message is received or to which the Message is sent can be identified by connecting the Event to a Participant using a Message Flow …”

  • Reported: BPMN 2.0 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Participant multi-instance instead of Sub-Choreography multi-instance

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

    i) Chapter/Section 11.4.1. Page 337.It says:
    “The marker for a Choreography Task that is multi-instance MUST be a set of three vertical lines”

    ii) Chapter/Section 11.4.2. Page 342.It says:
    “The marker for a Sub-Choreography that is multi-instance MUST be a set of three vertical lines.”

    COMMENTS:

    describes the use of a multi-instance marker in the Participant Band for a multi-instance Participant (see Figure 11.15, p. 337). Multi-instance marker for the Choreography Task is described on page 336.

    (ii) describes the use of a multi-instance marker in the Participant Band for a multi-instance Participant (see Figure 11.23, p. 342). Multi-instance marker for the Sub-Choreography is described on page 341.

    SUGGESTION:

    In it should say:
    “The marker for a Participant (of a Choreography Task) that is multi-instance MUST be a set of three vertical lines.”

    In (ii) it should say:
    “The marker for a Participant (of a Sub-Choreography) that is multi-instance MUST be a set of three vertical lines.”

  • Reported: BPMN 2.0 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 345. Sub-Choreographies instead of Choreography Activities

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

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

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

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

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

  • Reported: BPMN 2.0 — Mon, 11 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 224. Typos

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

    a) Sub-section Send Task Mapping

    It says:
    “…there MUST be at most inputSet set and at most one Data Input on the Send Task.”

    It should say:
    “…there MUST be at most one inputSet set and at most one Data Input on the Send Task.”

    “at most inputSet” should be replaced by “at most one inputSet”

    b) Sub-section Recieve Task Mapping
    It says:
    “…there MUST be at most outputSet set and at most one Data Output on the Receive Task.”

    It should say:
    “…there MUST be at most one outputSet set and at most one Data Output on the Receive Task.”

    “at most outputSet” should be replaced by “at most one outputSet”

  • Reported: BPMN 2.0 — Mon, 11 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multiple Instances Description: Sequential instead of parallel, Typos

  • Key: BPMN21-214
  • Legacy Issue Number: 15667
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    I found a minor mistake on page 39 concerning multiple instances. The text describes 3 vertical and 3 horizontal lines and declares that both define sequential Multi-Instances. I think that 3 vertical lines should be parallel Multi-Instance (also displayed in the figures).

    In addition, there are three typos in this text: horizontal liness -> lines, vertical liness -> lines, sequentail -> sequential

    In addition, I think that at the following two positions, the numbers are not correct:
    Page 34: See next seven figures. Only five figures concerning Sequence Flow are listed.
    Page 35: See next five rows. Only four following lines contain corresponding figures.

  • Reported: BPMN 2.0 — Thu, 30 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Text mentiones keyword "MUST NOT" 2 times

  • Key: BPMN21-213
  • Legacy Issue Number: 15666
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    In the following text, MUST NOT is listed 2 times:

    The keywords “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “MUST NOT,” “SHOULD,” “SHOULD NOT,”
    “RECOMMENDED,” “MAY,” and “OPTIONAL” in this document are to be interpreted as described in RFC-2119.

  • Reported: BPMN 2.0 — Thu, 30 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 10.30 doesn't correspond with Text: Start Event as Marker

  • Key: BPMN21-216
  • Legacy Issue Number: 15682
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to page 182, a collapsed Event Sub-Process will show the start event as a marker: If the Event Sub-Process is collapsed, then its Start Event will be used as a marker in the upper left corner of
    the shape (see Figure 10.30).

    However, Figure 10.30 doesn't show the mentioned marker and, so, doesn't correspond with the text.

  • Reported: BPMN 2.0 — Mon, 4 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Text references DataObject Element although DataState is meant

  • Key: BPMN21-215
  • Legacy Issue Number: 15679
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    The following line is taken from page 213:

    The DataState element inherits the attributes and model associations of BaseElement (see Table 8.5). Table 10.54
    presents the additional attributes and model associations of the DataObject element:

    I think that "DataState" is meant instead of "DataObject".

  • Reported: BPMN 2.0 — Mon, 4 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Examples - DI - Lanes and Nested Lanes.bpmn example is not according to the specifications

  • Key: BPMN21-224
  • Legacy Issue Number: 15725
  • Status: open  
  • Source: USoft B.V. ( Cristina Constantin)
  • Summary:

    Examples - DI - Lanes and Nested Lanes.bpmn example is not according to the specifications.
    In xml:
    <bpmn:lane name="Lane 2 - 2" id="Lane_Lane2_2">
    <bpmn:flowNodeRef>Task_UserTask</bpmn:flowNodeRef>
    <bpmn:flowNodeRef>DataObject_Document</bpmn:flowNodeRef>
    </bpmn:lane>

    DataObject_Document is a dataObjectReference (and that derives directly from flowElement) and not a flowNode. The documentation clearly states that flowNodeRef should be a reference to a flowNode and not to a flowElement (this has even changed from beta1 to beta2).

  • Reported: BPMN 2.0 — Tue, 12 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 338. Wrong name, multiplicity and description of “messageFlowRefs”

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

    a)
    Table 11.2. Row “messageFlowRef”.

    It says:
    “messageFlowRef: Message Flow [1..*]

    It should say:
    “messageFlowRefs: Message Flow [1..2]

    See Figures 11.1 (p.326) and 11.6 (p.332), where the multiplicity [1..2] is clear.
    ----------------------------------------------------------------------------

    b)
    In Figures 11.1 (p.326) and 11.6 (p.332) the role name is “messageFlowRef”, but it should be “messageFlowRefs”, because there can be more than one links.
    --------------------------------------------------------------------------------------

    c)
    In Table 11.2. Row “messageFlowRef”, it says “Although not graphical represented, Choreography Task contain one (1) or more Message Flows that represent the interaction(s) between the Participants referenced by the Choreography Task.”

    But, on page 333, it says:
    “A Choreography Task is an atomic Activity in a Choreography Process. It represents an Interaction, which is one (1) or two (2) Message exchanges between two (2) Participants.” Furthermore, the multiplicity is [1..2].

    Then, in Table 11.2. Row “messageFlowRefs”, it should say:
    “Although not graphical represented, Choreography Task contain one (1) or two (2) Message Flows that represent the interaction(s) between the Participants referenced by the Choreography Task.”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 317. Ambiguous associations “partitionElement” and “partitionElementRef”

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

    Table 10.135.

    a)
    Model associations “partitionElement” and “partitionElementRef” have the same description:
    “A reference to a BaseElement which specifies the partition value and partition type. Using this partition element a BPMN compliant tool can determine the FlowElements which have to be partitioned in this Lane.”

    So, which is the difference between them?
    --------------------------------------------------------------------------

    b)
    Model association “flowNodeRefs” is described as “the list of FlowNodes partitioned into this Lane according to the partitionElement defined as part of the Lane element.”

    “partitionElement” is optional. What happen if “partitionElement” is not defined?

    Does “flowNodeRefs” depend of “partitionElementRef” also?

    Can both “partitionElement” and “partitionElementRef” be defined at the same time?

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 77. Incomplete sentence

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

    In Sub-Section Key-based Correlation.

    It says
    “The idea is to use a joint Conversation “token” which is used (passed to and received from) and outgoing and incoming Message.”

    The sentence is incomplete.
    Furthermore, the word “incoming” is underlined, but it is not clear the purpose of doing this.

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 440. Incorrect name of Parallel Event-Based Gateway 2

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

    It says:
    “If the instance was created through an instantiating Parallel Gateway, then all subsequent Events (of that Gateway) MUST have occurred.”

    Normal Parallel Gateways cannot be instantiating elements.

    Then, it should say:
    “If the instance was created through an instantiating Parallel Event-Based Gateway, then all subsequent Events (of that Gateway) MUST have occurred.”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 370. Wrong Parallel Gateway in Figure 11.47

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

    Figure 11.47.

    Participant B: The Parallel Gateway has a “decision”, and its outgoing Sequence Flows have “conditions”.

    It is a mistake. “A Parallel Gateway creates parallel paths without checking any conditions; each outgoing Sequence Flow receives a token upon execution of this Gateway.” (p. 302).

    Then, words “Decision?”, “Yes” and “No” should be removed.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 342. Wrong reference to Table 11.3

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

    It says:
    “Table 11.3 presents the additional model associations of the GlobalChoreographyTask element:”

    But in Table 11.3 Sub-Choreography element is described.

    Then, it should say:
    “Table 11.3 presents the additional model associations of the Sub-Choreography element:”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 341. Choreography Activity instead of Task

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

    It says:
    “The three (3) or more partitions in the Sub-Choreography shape provide the distinction between this type of Task and an Orchestration Sub-Process (in a traditional BPMN diagram).”

    A Sub-Choreography is not a “type of Task”, but it is a “type of Choreography Activity”.

    Then, it should say:
    “The three (3) or more partitions in the Sub-Choreography shape provide the distinction between this type of Choreography Activity and an Orchestration Sub-Process (in a traditional BPMN diagram).”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 441. “Task” instead of “Activity”

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

    It says:
    “Uncontrolled flow means that, for each token arriving on any incoming Sequence Flows into the Activity, the Task will be enabled independently of the arrival of tokens on other incoming Sequence Flows. The presence of multiple incoming Sequence Flows behaves as an exclusive gateway. If the flow of tokens into the Task needs to be ‘controlled,’ then Gateways (other than Exclusive) should be explicitly included in the Process flow prior to the Task to fully eliminate semantic ambiguities.”

    The description is intended for “Activities” in general, not for “Tasks” in particular.

    Then, it should say:
    “Uncontrolled flow means that, for each token arriving on any incoming Sequence Flows into the Activity, the Activity will be enabled independently of the arrival of tokens on other incoming Sequence Flows. The presence of multiple incoming Sequence Flows behaves as an exclusive gateway. If the flow of tokens into the Activity needs to be ‘controlled,’ then Gateways (other than Exclusive) should be explicitly included in the Process flow prior to the Activity to fully eliminate semantic ambiguities.”

    Three times “Task” should be replaced by “Activity”.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 57. Associations are incorrectly drawn Figure 8.6

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

    Figure 8.6.

    Generalization from “Documentation” to “BaseElement” is on top of aggregation from “BaseElement” to “Documentation”.

    Both relationships should be drawn separately. See Figure 8.5 (p.55), where they are correctly drawn.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 452. Incorrect name of Parallel Event-Based Gateway 3

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

    It says:
    “When used at the Process start as a Parallel Event Gateway, only message-based triggers are allowed.”

    It should say:
    “When used at the Process start as a Parallel Event-Based Gateway, only message-based triggers are allowed.”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pages 366-368. Wrong direction of Message Flow

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

    a) Figure 11.43 (p.366)

    Direction of M1 is wrong. It should be from Task in Participant B to Task in Participant A.
    ----------------------------------------------------------------------

    b) Figure 11.45 (p.368)
    Direction of M1 is wrong. It should be from Task in Participant B to Task in Participant A.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 359. Missing markers in Send and Receive Tasks

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

    Figure 11.37.

    Participant A:
    Two (of three) Send Tasks without message markers.

    Participant B:
    One (of two) Receive Task without message marker.
    One (of two) Receive Task without incoming Message Flow.

    Participant C:
    Receive Task without message marker.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 341. Choreography instead of Sub-Choreography

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

    It says:
    “The Choreography Activity shares the same shape as a Sub-Process or any other BPMN Activity, which is in this state.”

    This sentence is within section 11.4.2, where Sub-Choreographies are described.

    Then, it should say:
    “The Sub-Choreography shares the same shape as a Sub-Process or any other BPMN Activity, which is in this state.”

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 345. Wrong type of "calledChoreographyRef"

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

    Table 11.4.

    It says:
    “calledChoreographyRef: CallableElement [0..1]

    The model association is form “CallChoreography” to “Choreography”. See Figure 11.27, p. 344.

    Then, it should say:
    “calledChoreographyRef: Choreography [0..1]

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 117. Wrong name of model association “interfaceRefs”.

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

    Table 9.2. Row “interfaceRef”.

    The model association name should be “interfaceRefs”, because of its multiplicity ([0..*]), and because this is its name in Figure 9.7 (p.116).

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 115. Confusion over subtypes of Collaboration 1.

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

    It says
    “When Participants are defined they are contained within a Collaboration, which includes the sub-types of Choreography, GlobalConversation, or GlobalChoreographyTask.”

    This is not consistent with what is shown in Figure 9.1 (p.109): GlobalConversation and Choreography are sub-types of Collaboration; and GlobalChoreographyTask is sub-type of Choreography.

    Maybe it should say
    “When Participants are defined they are contained within a Collaboration, which includes the sub-types GlobalConversation, Choreography and GlobalChoreographyTask.”

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 111. Association “participants” not shown in Figure 9.1

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

    Table 9.1. Row “participants”. And Figure 9.1 (p.109).

    Model association “participants” (from “Collaboration” to “Participant”) is not shown in Figure 9.1 (p.109).

    Model association “participants” should be shown in Figure 9.1 because it is the location where all class “Collaboration” relationships must be displayed.

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 117 & 118. Confusion over subtypes of Collaboration 2

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

    Table 9.3 (p.117). Row “participantRef”.

    It says
    “Specifies how the PartnerEntity participates in Collaborations and Choreographies.”

    It should say
    “Specifies how the PartnerEntity participates in Collaborations.”
    ----------------------------------------------------

    Table 9.4 (p.118). Row “participantRef”.

    It says
    “Specifies how the PartnerRole participates in Collaborations and Choreographies.”

    It should say
    “Specifies how the PartnerRole participates in Collaborations.”
    --------------------------------------------------

    In Beta 2 GlobalConversation and Choreography are sub-types of Collaboration; and GlobalChoreographyTask is sub-type of Choreography.
    Then “Collaborations and Choreographies” is incomplete and ambiguous.

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 117 & 118. Wrong name of association “participantRefs

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

    Table 9.3 (p.117). Row “participantRef”.

    The model association name should be “participantRefs”, because of its multiplicity ([0..*]). Its name should be modified in Figure 9.7 (p.116) too.
    --------------------------------------

    Table 9.4 (p.118). Row “participantRef”.

    The model association name should be “participantRefs”, because of its multiplicity ([0..*]). Its name should be modified in Figure 9.7 (p.116) too.

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 185. Nonexistent attribute shown in Figure 10.29

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

    Table 10.21 and Figure 10.29 (p. 181)

    Attribute “protocol” was removed from class Transaction in Table 10.21 (p.185), but it remains in Figure 10.29 (p.181).

    Attribute “protocol” of class Transaction should be removed from Figure 10.29.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 182. Missing Start event triggers for Event Sub-Process

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

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

    Problem: “Timer” and “Parallel Multiple” are not mentioned, but they are valid Start Event triggers for Event Sub-Process (see Table 10.93, pp. 269 & 270). Then, it should say:

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

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 99. Wrong inheritance of FlowNode

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

    It says
    “Since Gateway, Activity, Choreography Activity, and Event have their own attributes, model associations, and inheritances; the FlowNode element does not inherit from any other BPMN element. Table 8.52 presents the additional model associations of the FlowNode element:”

    It should say
    “The FlowNode element inherits the attributes and model associations of FlowElement (see Table 8.44). Table 8.52 presents the additional model associations of the FlowNode element:”

    FlowNode is subclass of FlowElement. (See Figure 8.35, p. 98; and Figure 8.22, p.87.)

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 97. Wrong multiplicity of association in Table 8.50

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

    Table 8.50. Row “type”

    It says
    “type: ItemDefinition”

    It should say
    “type: ItemDefinition [0..1]

    In Figure 8.31 (p. 96) model association “type” (from ResourceParameter to ItemDefinition) is optional ([0..1])

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 96. ResourceParameter is not subclass of RootElement

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

    It says
    “The ResourceParameter element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to RootElement.”

    It should say
    “The ResourceParameter element inherits the attributes and model associations of BaseElement (see Table 8.5).”

    ResourceParameter it is not subclass of RootElement. It is direct subclass of BaseElement. (See Figure 8.31, p.96.)

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 84. Event is not direct subclass of FlowElement

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

    says
    “The Event element inherits the attributes and model associations of FlowElement (see Table 8.44), but adds no additional attributes or model associations:”

    It should say
    “The Event element inherits the attributes and model associations of FlowElement (see Table 8.44), through its relationship to FlowNode, but adds no additional attributes or model associations.”

    Event is direct subclass of FlowNode, which is direct subclass of FlowElement. (See Figure 8.20, p. 84.)

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 109. Wrong multiplicity in Figure 9.1

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

    Figure 9.1 and Table 9.1 (p.110).

    In Figure 9.1 multiplicity of “conversationAssociations” (from “Collaboration” to “ConversationAssociation”) is [1..1], but it should be [0..*], as it is shown in Table 9.1 (p.110).

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 104. Navigation (arrowhead) is needed if Figure 8.36

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

    Figure 8.36 and Table 8.65 (p.105)

    A navigation (arrowhead) is needed from “Interface” to “CallableElement” in Figure 8.36 in order to be consistent with the model association “callableElement” in Table 8.65 (p.105).

    The inclusion of “callableElements” in Table 8.65 means that “Interface knows about CallableElement”, which (in UML) is graphically represented with an arrowhead from “Interface” to “CallableElement”.

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 139. Ambiguous multiplicities of associations

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

    Table 9.14. Row “innerConversationNodeRef”.

    In table 9.14 the multiplicity of model association “innerConversationNodeRef” is [0..1], but in Figure 9.31 (p. 139) its multiplicity is [1..1].
    Its description in Table 9.14 (“This attribute defines the ConversationNodes of the referenced element...”) suggests that its multiplicity should be [0..*].

    The multiplicity of “innerConversationNodeRef” should be clearly defined ([0..1], or [1..1], or [0..*]). In case of [0..*] the model association name should be changed to “innerConversationNodeRefs”
    ---------------------------------------------

    Table 9.14. Row “outerConversationNodeRef”.

    In table 9.14 the multiplicity of model association “outerConversationNodeRef” is [0..*], but in Figure 9.31 (p. 139) its multiplicity is [1..1].
    Its description in Table 9.14 (“This attribute defines the ConversationNodes of the parent element...”) suggests that its multiplicity should be [0..*].

    The multiplicity of “outerConversationNodeRef” should be clearly defined ([1..1], or [0..*]). In case of [0..*] the model association name should be changed to “outerConversationNodeRefs”

    Table 9.14 and Figure 9.31 should be updated accordingly.

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 110. Wrong use of UML concept “aggregation”.

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

    In Table 9.1. Row “conversations”.

    It says
    “The conversations model aggregation relationship allows a Collaboration to contain …”

    It should say
    “The conversations model composition relationship allows a Collaboration to contain …”

    In Figure 9.1 (p. 109), the line “begins” with a filled mini-diamond, which represents a composition, not an aggregation.

  • Reported: BPMN 2.0 — Mon, 13 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 151. Wrong role name and multiplicity of association “artifacts”

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

    Figure 10.3.

    Name and multiplicity of role from “Process” to “Artifact” are:
    “artifact” and “0..1”

    but they should be:
    “artifacts” and “*” .

    See Table 10.1 (p. 152), row “artifacts”.

  • Reported: BPMN 2.0 — Fri, 17 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unclear and incorrect specification of Expressions and Formal Expressions

  • Key: BPMN21-99
  • Legacy Issue Number: 15422
  • Status: open  
  • Source: USoft ( Rene de Bruin)
  • Summary:

    The use of expression and formalexpression is unclear. The description of 'Expression' states: 'The Expression class is used to specify an Expression using natural-language text. These Expressions are not executable and are considered underspecified '. However, table 8.1 states about 'expressionLanguage': 'This attribute identifies the formal Expression language used in Expressions within the elements of this Definition'. I guess this should be ' This attribute identifies the formal Expression language used in Formal Expressions'.
    Then there are several places where an 'expression' can be entered and not a 'formal expression'. For example table 10.64: assignment attributes. The 'from' and 'to' both are an 'Expression'. Just above the table it says: "The default Expression language for all Expressions is specified in the Definitions element, using the expressionLanguage attribute. It can also be overridden on each individual Assignment using the same attribute". Since the 'from' and 'to' fields are 'Expressions' and not 'Formal Expressions', it is not possible to specify the expressionLanguage. The expression class cleary states it used to specify using "natural-language".
    There are more places where a FormalExpression might be a better choice. Like the conditionExpression of a sequence flow. Since it is an 'Expression' it can only containt the condition in natural language. Venders will need to add vendor specific extension elements to contain the formal expression.
    FormalExpressions are a subclass of Expressions. Maybe it is the intention that FormalExpressions can be used whereever expressions can be used. However, the xsd clearly forbids this (as noticed already by Mr Denis Gagne in issue 14433)
    Finally, the description of 'Expression' states: "The natural language text is captured using the documentation attribute, inherited from BaseElement". In example xml in the document, like in Table 10.19, expressions are just put in the body of the expression:
    <sequenceFlow sourceRef="OrderApprovedDecision" targetRef="OrderAndShipment">
    <conditionExpression>Was the Order Approved?</conditionExpression>
    /sequenceFlow>
    Is this then correct? The description of the Expression class states it should be in the document attribute (which is by the way also not correct since the xsd states 'document' is not an attribute but an element).

  • Reported: BPMN 2.0 — Thu, 19 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Cardinality of sources for Data Association

  • Key: BPMN21-98
  • Legacy Issue Number: 15415
  • Status: open  
  • Source: wu.ac.at ( abaumgra@wu.ac.at)
  • Summary:

    Throughout the text it is stated that a data association has one or more sources and one target (see page 228). First of all, if that is true the meta-model should be adjusted on page 229, figure 10.64. Taking "" as cardinality for sources of a data association would allow a data association to exist without any source. I suggest to change the cardinality to "1..".

    Second, in the description I couldn't find any example explaining for which cases more than one source in a data association makes sense. Is it allowed because a data object can be collection?

  • Reported: BPMN 2.0 — Fri, 13 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

How many source are allowed for data association?

  • Key: BPMN21-97
  • Legacy Issue Number: 15414
  • Status: open  
  • Source: wu.ac.at ( abaumgra@wu.ac.at)
  • Summary:

    In the text on page 228 it says "Data association elements have one or more sources and a target", but in the meta-model in figure 10.64 the association is marked as "*" meaning it is also possible to have 0 sources. As well as in table 10.63: "sourceRef:ItemAwareElement [0..*]".

    It is not clear how many sources of a data association are allowed now.

  • Reported: BPMN 2.0 — Thu, 12 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page153 Wrong reference to section 8.3.2

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

    Table 10.1. Row “correlationSubscriptions”.

    It says
    “correlationSubscriptions are a feature of context-based correlation (cf. section 8.3.3).”

    It should say
    “correlationSubscriptions are a feature of context-based correlation (cf. section 8.3.2).”

    “section 8.3.3” should be replaced by “section 8.3.2”

  • Reported: BPMN 2.0 — Mon, 6 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 96. Wrong reference to table 8.50

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

    It says
    “Table 8.51 presents the additional model associations for the ResourceParameter element:”

    It should say
    “Table 8.50 presents the additional attributes and model associations for the ResourceParameter element:”

    “model associations” should be replaced by “attributes and model associations”
    “Table 8.51” should be replaced by “Table 8.50”

  • Reported: BPMN 2.0 — Mon, 6 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

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

  • Key: BPMN21-96
  • Legacy Issue Number: 15408
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The first sentence of the subsection "Non-interrupting Event Handlers (Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)" starts out: "Interrupting Event Handlers are those..."
    The text should be: "Non-Interrupting Event Handlers are those..."

  • Reported: BPMN 2.0 — Fri, 6 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 10.98 needs Updating

  • Key: BPMN21-95
  • Legacy Issue Number: 15407
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Figure 10.98 shows an Event Gateway that initiates a process, but the Gateway marker is incorrect. The marker needs to be updated to that of a multiple Start Event rather than a multiple Intermediate Event.

  • Reported: BPMN 2.0 — Fri, 6 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 29 Wrong reference to page 240

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

    Table 7.1. Row “Event”

    It says
    “An Event is something that “happens” during the course of a Process (see page 245)”

    It should say
    “An Event is something that “happens” during the course of a Process (see page 240)”

  • Reported: BPMN 2.0 — Sat, 4 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Definition of Signal Missing

  • Key: BPMN21-103
  • Legacy Issue Number: 15441
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The Section on Common Elements (8.3) should have a subsection that defines Signal, the way that Message, Escalation, and Error are defined.

  • Reported: BPMN 2.0 — Wed, 1 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 96 Wrong reference to table 8.49

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

    It says
    “Table 8.51 presents the additional model associations for the Resource element:”

    It should say
    “Table 8.49 presents the additional attributes and model associations for the Resource element:”

    “model associations” should be replaced by “attributes and model associations”
    “Table 8.51” should be replaced by “Table 8.49”

  • Reported: BPMN 2.0 — Mon, 6 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Definition of Association is to strict

  • Key: BPMN21-101
  • Legacy Issue Number: 15428
  • Status: open  
  • Source: USoft ( Rene de Bruin)
  • Summary:

    Page 68 states:
    An Association is used to connect user-defined text (an Annotation) with a Flow Object (see Figure 8.12).
    This is to strict: an association can also be used to associate a compenstaion boundary event with a compenation activity.

  • Reported: BPMN 2.0 — Thu, 26 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Contradictory mandatoryness of category for category values

  • Key: BPMN21-100
  • Legacy Issue Number: 15423
  • Status: open  
  • Source: USoft ( Rene de Bruin)
  • Summary:

    The group class diagram (figure 8.15) states that a category values must reference exactly one category.
    The category values attributes table (table 8.23) however states that the category is not mandatory.

  • Reported: BPMN 2.0 — Fri, 20 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong metaclass name in attribute description

  • Key: BPMN21-102
  • Legacy Issue Number: 15431
  • Status: open  
  • Source: INRIA ( Juan Cadavid)
  • Summary:

    In table 10.58, description of the attribute outputSets mentions "...Every Data Interface must define..." when it should say "...Every InputOutputSpecification must define..."

  • Reported: BPMN 2.0 — Thu, 26 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multiple uncontrolled incoming Sequence Flows

  • Key: BPMN21-268
  • Legacy Issue Number: 15839
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to Section 13.2.1:
    The presence of multiple incoming Sequence Flows behaves as an exclusive gateway.

    However, I think this is only the case for alternative paths (only one token). Otherwise, several instances are created. See the specification from other sections:

    An Activity MAY be a target for Sequence Flows; it can have multiple incoming Sequence Flows. Incoming Sequence Flows MAY be from an alternative path and/or parallel paths.

    If the Activity has multiple incoming Sequence Flows, then this is considered uncontrolled flow. This means that when a token arrives from one of the Paths, the Activity will be instantiated. It will not wait for the arrival of tokens from the other paths. If another token arrives from the same path or another path, then a separate instance of the Activity will be created.

    If all the incoming flow is alternative, then a Gateway is not needed.

    I think that only multiple alternative incoming flows correspond to an exclusive gateway. I, therefore, suggest the following adaptation:

    The presence of multiple "alternative" incoming Sequence Flows behaves as an exclusive gateway.

    or

    The presence of multiple incoming Sequence Flows may instantiate an Activity several times.

  • Reported: BPMN 2.0 — Mon, 22 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Element Repository

  • Key: BPMN21-267
  • Legacy Issue Number: 15819
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    On page 329 it is stated that: As mentioned above, neither Data Objects nor Repositories are used in Choreographies. Both of these elements are used exclusively in Processes and require the concept of a central locus of control.

    Repository is refered to as being an element that can be used in Processes and it is also highlighted like other elements. However, an element with the name Repository is nowhere else mentioned.

  • Reported: BPMN 2.0 — Fri, 12 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Attributes of GlobalScriptTask

  • Key: BPMN21-266
  • Legacy Issue Number: 15818
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    There is no table with attributes and associations of GlobalScriptTask available.

    Basically the attributes should be similar to ScriptTask which has according to Table 10.12 on page 170 two attributes (scriptFormat: string [0..1], script: string [0..1]).

    According to the Global Task class diagram, however, GlobalScriptTask has script: string and striptLanguage: String. The XML schema on page 205 also mentions script [0..1] and scriptLanguage [1].

    The differences are therefore the attributes scriptFormat vs. scriptLanguage as well as their cardinality.

  • Reported: BPMN 2.0 — Fri, 12 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Connection Rules for Message Flow

  • Key: BPMN21-265
  • Legacy Issue Number: 15817
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to Table 7.4 on page 44, Message Flows can only connect to events of type message. According to page 257: The Result attribute of the End Event MUST be set to Message or Multiple if there are any outgoing Message Flows.

    Are events with Multiple Trigger allowed to have outgoing Message Flows? If yes, this should also be specified in Table 7.4.
    Is it further also possible to have a Start Event with Multiple Trigger having multiple incoming Message Flows?

    In addition, Table 7.4 is missing several arrows, e.g. first row (connecting from a Start Event) and last column (connecting to an End Event). Furthermore, the first column might also be possible (connections from a pool to another StartEvent).

  • Reported: BPMN 2.0 — Fri, 12 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Relationship type of CorrelationProperty

  • Key: BPMN21-272
  • Legacy Issue Number: 15893
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the Correlation Class Diagram (Figure 8.17) on page 76, CorrelationProperty has a relationship type with cardinality 0..1 to ItemDefinition.

    However, in Table 8.32 (CorrelationProperty model associations) on page 78, the relationship type has the datatype string.

    Suggestion: Correction of Table 8.32, change type from string to ItemDefinition

  • Reported: BPMN 2.0 — Mon, 13 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Attribute Description of Class Signal missing

  • Key: BPMN21-271
  • Legacy Issue Number: 15892
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    On page 281 Signal Events are described. The Class Diagram of SignalEventDefinition (Fig. 10.93) refers to a class called Signal with an attribute name and a relationship to ItemDefinition with the name structureRef. However, the attributes and model associations of this class are nowhere described in detail.

    Remark: attributes and model associations are also missing for some Global Tasks (GlobalBusinessRuleTask, GlobalScriptTask and GlobalUserTask), however, in this case similar attribute descriptions are available for the classes BusinessRuleTask, ScriptTask and UserTask and might be taken (only problem is the difference described in Issue 15818).

  • Reported: BPMN 2.0 — Mon, 13 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CompensateEventDefinition vs. CompensationEventDefinition

  • Key: BPMN21-260
  • Legacy Issue Number: 15811
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    The same element is sometimes called CompensateEventDefinition and sometimes CompensationEventDefinition.

    CompensateEventDefinition used:

    • Within the Class Diagram Figure 10.76
    • Table 10.106 ­ CompensateEventDefinition XML schema

    CompensationEventDefinition used:

    • in the labeling text of Figure 10.76
    • In the following text and description of the attributes and model associations.

    I would recommend to use CompensationEventDefinition.

  • Reported: BPMN 2.0 — Wed, 10 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Attributes and Model Associations of EndEvent

  • Key: BPMN21-259
  • Legacy Issue Number: 15810
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    Every specified Element has a sentence of the type "The RootElement element inherits the attributes and model associations of BaseElement (see Table 8.5), but does
    not have any further attributes or model associations." or the type "The Association element inherits the attributes and model associations of BaseElement (see Table 8.5). Table 8.20 presents the additional attributes and model associations for an Association" except EndEvent.

    It seems that EndEvent has no attributes, so the sentence "The EndEvent element inherits the attributes and model associations of ThrowEvent (see Table ..), but does
    not have any further attributes or model associations." could be inserted.

  • Reported: BPMN 2.0 — Wed, 10 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Model Associations of class Event

  • Key: BPMN21-273
  • Legacy Issue Number: 15894
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to page 84:
    The Event element inherits the attributes and model associations of FlowElement (see Table 8.44), but adds no additional attributes or model associations.

    However, according to the class diagram in Figure 8.20, Event has one model association to Property with the name 'properties' and the cardinality [0..n].

  • Reported: BPMN 2.0 — Mon, 13 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Attributes of StandardLoopCharacteristics

  • Key: BPMN21-264
  • Legacy Issue Number: 15816
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the LoopCharacteristics class diagram (Figure 10.45, page 196) StandardLoopCharacteristics only has one attribut (testBefore). However, Table 10.28 on page 198 shows two further attributes (loopMaximum and loopCondition).

  • Reported: BPMN 2.0 — Fri, 12 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Attributes of Transaction Element

  • Key: BPMN21-263
  • Legacy Issue Number: 15815
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the class diagram of Sub-Process (Figure 10.29, page 181), Transaction has two attributes (protocol and transaction). However, in Table 10.21 on page 185 only method is mentioned (transaction missing).

    In addition, the class diagram specifies that the data type of method is string. Table 10.21, however, defines that the data type is of TransactionMethod.

    Since an element TransactionMethod is not defined in any metamodel, I would suggest to use data type string. In addition, protocol could be inserted in Table 10.21 with a cardinality of [0..1] or [1].

  • Reported: BPMN 2.0 — Fri, 12 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Attributes of Element Resource Role

  • Key: BPMN21-270
  • Legacy Issue Number: 15891
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the class diagram of Resources on page 158, ResourceRole has an attribute "name" of type string.

    However, in Table 10.5 - Resource Role model associations on page 159, only three relationships are mentioned but no attribute "name".

  • Reported: BPMN 2.0 — Fri, 10 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Converging Gateway has multiple outgoing connections

  • Key: BPMN21-269
  • Legacy Issue Number: 15883
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the footnotes on page 7:
    a.Multiple outgoing connections are only allowed for converging Gateways.
    b.Multiple outgoing connections are only allowed for diverging Gateways.

    Footnote a should be correted to "multiple incoming connections". The right definition is also specified on page 298:

    A Gateway with a gatewayDirection of converging MUST have multiple incoming Sequence Flows, but MUST NOT have multiple outgoing Sequence Flows.

  • Reported: BPMN 2.0 — Thu, 9 Dec 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Cardinality of Relationship from CategoryValue to Category

  • Key: BPMN21-262
  • Legacy Issue Number: 15814
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    According to the Group class diagram (Figure 8.15 on page 70) CategoryValue has a relationship with cardinality 1 to Category. However, according to Table 8.23 on page 72, CategoryValue references category with a cardinality of [0..1].

    I would suggest to set the cardinality to 1.

  • Reported: BPMN 2.0 — Fri, 12 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Model Association participantMultiplicity(Ref) of element Participant

  • Key: BPMN21-261
  • Legacy Issue Number: 15812
  • Status: open  
  • Source: scch.at ( Christine Natschlär)
  • Summary:

    The model association participantMultiplicity(Ref) is twice named participantMultiplicity (in the class diagram and in Table 9.2 on the left side) and once participantMultiplicityRef (in Table 9.2 on the text of the right side). Maybe the text of Table 9.2 can be replaced as follows:

    participantMultiplicity: participant-
    Multiplicity [0..1]
    -->
    participantMultiplicityRef: Participant-
    Multiplicity [0..1]

  • Reported: BPMN 2.0 — Thu, 11 Nov 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Events that can be located after an Event-Based Gateway

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

    Chapter/Section 10.5.6. Page 306. It says:

    “Event-Based Gateways are configured by having outgoing Sequence Flows target an Intermediate Event or a Receive Task …”

    “If Message Intermediate Events are used in the configuration, then Receive Tasks MUST NOT …”

    “Only the following Intermediate Event triggers are valid: Message, Signal, Timer, Conditional, and Multiple (which can only include the previous triggers). Thus, the following Intermediate Event triggers are not valid: Error, Cancel, Compensation, and Link.”

    COMMENTS:

    According to Table 10.93 (p. 269) Intermediate catch Events in normal flow are: message, timer, conditional, link, signal, multiple and parallel multiple.

    The Events after an Event-Based Gateway can be only catch Intermediate Events in normal flow, but two of them (Link and parallel Multiple) are not allowed.

    SUGGESTIONS:

    Then, it should say:

    “Event-Based Gateways are configured by having outgoing Sequence Flows target an Intermediate catch Event or a Receive Task …”

    “If Message Intermediate catch Events are used in the configuration, then Receive Tasks MUST NOT …”

    “Only the following Intermediate catch Event triggers in normal flow are valid: Message, Signal, Timer, Conditional, and Multiple (which can only include the previous triggers). Thus, the following Intermediate catch Event triggers in normal flow are not valid: Link, and Parallel Multiple.”

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistencies concerning attribute “activationCount”

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

    i) Chapter/Section 10.5.5. Page 305. Table 10.126. Row “activationCount”. It says:
    “Refers at runtime to the number of tokens that are present on an incoming Sequence Flow of the Complex Gateway.”

    ii) Chapter/Section 13.3.5. Page 452-453. It says:
    “ Each incoming gate of the Complex Gateway has an attribute activationCount, which can be used in an Expression as an
    integer-valued variable. This variable represents the number of tokens that are currently on the respective incoming Sequence
    Flows. The Complex Gateway has an attribute activationExpression. An activationExpression is a boolean Expression that
    refers to data and to the activationCount of incoming gates. For example, an activationExpression could be x1+x2+…+xm >=
    3 stating that it needs 3 out of the m incoming gates to have a token in order to proceed. To prevent undesirable oscillation of
    activation of the Complex Gateway, ActivationCount variables should only be used in subexpressions of the form …”

    COMMENTS:

    In according to Table 10.126 (“Instance attributes related to the Complex Gateway”) for each instance of a certain Complex Gateway there is one “activationCount” attribute, which memorize the “number of tokens that are present on an incoming Sequence Flow”. But a Complex Gateway - by definition ­ has more than one incoming Sequence Flow.

    In (ii) it is described the presence and usage of more than one “activationCount” variable in a single instance of a Complex Gateway.

    In (ii) it is clearly stated that “Each incoming gate of the Complex Gateway has an attribute activationCount”. Then, the “activationCount” attribute should be located in each incoming “SequenceFlow instance”, but it is not what the meta-model says (see Figure 8.35, p. 98).

    “activationCount” cannot be an attribute of Sequence Flow Class , because a “normal” instance of Sequence Flow that reachs a Complex Gateway will be instantiate as many times as the Complex Gateway.

    In (ii) the attribute activationExpression is mentioned, but according to Figure 10.114 and Table 10.125 (p. 304) its real name is activationCondition.

    SUGGESTIONS:

    Somehow the meta-model must represent the fact that there will be many “activationCount” for each instance of a Complex Gateway. An option is to make “activationCount” attribute (of Complex Gateway instance) an array of integers (one for each incoming Sequence Flow).

    In (ii) replace “activationExpression” with “activationCondition”

    Typo: in (ii) “on the respective incoming Sequence Flows” should be replaced by “on the respective incoming Sequence Flow”

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

None Intermediate Event: “catch” or “throw”

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

    Description:

    ANTECEDENTS:
    i) Chapter/Section 10.4.4. Page 259. Table 10.89. Row “None”. It says:
    “The None Intermediate Event is only valid in normal flow, i.e., it MAY NOT be used on the boundary of an Activity. Although there is no specific trigger for this Event, it is defined as throw Event.”

    ii) Chapter/Section 10.4.5. Page 269. Table 10.93. Row “None”.
    None Intermediate Event is shown as a throw Event

    iii) Chapter/Section 10.4.5. Page 280. It says:
    “There are three (3) variations of None Events: a Start Event, a catch Intermediate Event, and …”

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

    COMMENTS:

    In and (ii) None Intermediate Event is defined as a throw Event, but in (iii) it is considered to be a catch Event

    SUGGESTIONS:

    It seems that it is not important which type (throw or catch) would be chosen, but it is necessary to define one and be consistent in its use.

    Note: see Issue 15687

  • Reported: BPMN 2.0 — Fri, 15 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistencies concerning Link Events

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

    i) Chapter/Section 10.4.4. Page 260. Table 10.89. Row “Link”. It says:
    “There can be multiple source Link Events, but there can only be one target Link Event.”

    ii) Chapter/Section 10.4.4. Page 268. It says:

    • If there is a source Link, there MUST be a matching target Link (they have the same name).
    • There MAY be multiple source Links for a single target Link.
    • There MUST NOT be multiple target Links for a single source Link.

    iii) Chapter/Section 10.4.5. Page 270. Figure 10.73.
    Role “target” (from LinkEventDefinition to LinkEventDefinition) has multiplicity [0..1]
    Role “source” (from LinkEventDefinition to LinkEventDefinition) has multiplicity [0..*]

    iv) Chapter/Section 10.4.5. Page 278. Table 10.98. Row “sources”. It says:
    “sources: LinkEventDefinition [1..*]
    “Used to reference the corresponding ‘catch’ or ‘target’ LinkEventDefinition, when this LinkEventDefinition represents a ‘throw’ or ‘source’ LinkEventDefinition.”

    v) Chapter/Section 10.4.5. Page 278. Table 10.98. Row “target”. It says:
    “target: LinkEventDefinition [1]
    “Used to reference the corresponding ‘throw’ or ‘source’ LinkEventDefinition, when this LinkEventDefinition represents a ‘catch’ or ‘target’ LinkEventDefinition.”

    COMMENTS:

    In (iii) the role name “source” is incorrect, because its multiplicity is “many” and it is not the name shown in (iv)

    In (iv) the multiplicity of “sources” is incorrect, it must be [0..*], because ­ by definition ­ a source (throw) Link doesn’t have any “sources”. Furthermore, in (iii) the multiplicity is [0..*].

    In (iv) the description in misplaced. Actually, it is the description of the role “target”.

    In (v) the multiplicity of “target” is incorrect, it must be [0..1], because ­ by definition ­ a target (catch) Link doesn’t have any “target”. Furthermore, in (iii) the multiplicity is [0..1].

    In (v) the description in misplaced. Actually, it is the description of the role “sources”.

    In (iv) and (v) it is not stated that “target” and “sources” are mutually exclusive.
    A source (throw) Link have one “target” and zero “sources”
    A target (catch) Link have one or more “sources” and no “target”.

    SUGGESTIONS:
    In (iii) change role name from “source” to “sources”.

    In (iv) change multiplicity form “[1..*]” to “[0..*]

    In (iv) replace description by:
    “Used to reference the corresponding ‘throw’ or ‘source’ LinkEventDefinitions (at least one), when this LinkEventDefinition represents a ‘catch’ or ‘target’ LinkEventDefinition. When the LinkEventDefinition represents a ‘throw’ or ‘source’ LinkEventDefinition this model association is not set.”

    In (v) change multiplicity form “[1..1]” to “[0..1]

    In (iv) replace description by:
    “Used to reference the corresponding ‘catch’ or ‘target’ LinkEventDefinition, when this LinkEventDefinition represents a ‘throw’ or ‘source’ LinkEventDefinition. When the LinkEventDefinition represents a ‘catch’ or ‘target’ LinkEventDefinition this model association is not set.”

  • Reported: BPMN 2.0 — Fri, 15 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message Flow Connections for Start, End and Intermediate Events

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

    i) Chapter/Section 10.4.2. Page 253. Message Flow Connections for Start Events
    It says:

    • A Start Event MAY be the target for a Message Flow; it can have zero (0) or more incoming Message Flows. Each Message Flow targeting a Start Event represents an instantiation mechanism (a trigger) for the Process. Only one of the triggers is REQUIRED to start a new Process.
    • A Start Event MUST NOT be a source for a Message Flow; it MUST NOT have outgoing Message Flows.

    ii) Chapter/Section 10.4.3. Page 257. Message Flow Connections for End Events
    It says:

    • An End Event MUST NOT be the target of a Message Flow; it can have no incoming Message Flows..
    • An End Event MAY be the source of a Message Flow; it can have zero (0) or more outgoing Message Flows. Each Message Flow leaving the End Event will have a Message sent when the Event is triggered.
    • The Result attribute of the End Event MUST be set to Message or Multiple if there are any outgoing Message Flows.
    • The Result attribute of the End Event MUST be set to Multiple if there is more than one (1) outgoing Message Flows

    iii) Chapter/Section 10.4.4. Page 268. Message Flow Connections for Intermediate Events
    It says:

    • A Message Intermediate Event MAY be the target for a Message Flow; it can have one (1) incoming Message Flow.
    • A Message Intermediate Event MAY be a source for a Message Flow; it can have one (1) outgoing Message Flow.
    • A Message Intermediate Event MAY have an incoming Message Flow or an outgoing Message Flow, but not both.

    COMMENTS:

    In it is not explained when the Start Event can have incoming Message Flows.
    The rules are:
    The Start Event MUST be associated with one (1) or more MessageEventDefinitions if there are any incoming Message Flows.
    The Start Event will be Message, Multiple or Parallel Multiple if there are any incoming Message Flows.
    The Start Event will be Multiple or Parallel Multiple if there is more than one (1) incoming Message Flows.

    In it is said “Only one of the triggers is REQUIRED to start a new Process”, this is true for a Multiple Start Event, but not for a Parallel Multiple Start Event.

    In (ii) the “Result” attribute is mentioned. It was an attribute of End Event in BPMN 1.2, but not in BPMN 2.0. (see Figure 10.69, p. 241).
    The rules are:
    The End Event MUST be associated with one (1) or more MessageEventDefinitions if there are any outgoing Message Flows.
    The End Event will be Message or Multiple if there are any outgoing Message Flows.
    The End Event will be Multiple if there is more than one (1) outgoing Message Flows.

    In (iii) it is described only the Message Intermediate Event, but Multiple and Parallel Multiple Intermediate Events can be the source or the target of Message Flows too.

    SUGGESTIONS:

    In add the rules that define when the Start Event can have incoming Message Flows, and consider the case when a a Parallel Multiple Start Event is used.

    In (ii) remove references to “Result” attribute and update the rules that define when the End Event can have outgoing Message Flows.

    In (iii) describe the rules concerning Message Flows for Multiple and Parallel Multiple Intermediate Events.

  • Reported: BPMN 2.0 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pages 285-287. Missing Events types

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

    i) Chapter/Section 10.4.2. Page 269. Table 10.93.
    Boundary Interrupting Events are: error, cancel, compensation, message, timer, escalation, conditional, signal, multiple and parallel multiple.

    Boundary Non-interrupting Events are: message, timer, escalation, conditional, signal, multiple and parallel multiple.

    Event Sub-Process Interrupting Events are: error, compensation, message, timer, escalation, conditional, signal, multiple and parallel multiple.

    Event Sub-Process Non-interrupting Events are: message, timer, escalation, conditional, signal, multiple and parallel multiple.

    ii) Chapter/Section 10.4.6. Page 285. Subsection “Handling Events attached to an Activity (Intermediate boundary Events and Event Sub-Processes)”. It says:

    “For boundary Events, handling consists of consuming the Event occurrence and either canceling the Activity the Event is
    attached to, followed by normal Sequence Flows leaving that Activity, or by running an Event Handler without canceling the
    Activity (only for Message, Signal, Timer and Conditional Events, not for Error Events).”

    iii) Chapter/Section 10.4.6. Page 287. It says:
    “For an interrupting Event (Error, Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple),
    only one Event Sub-Process for the same Event Declaration MUST be modeled.”

    COMMENTS:

    In (ii) Escalation, Multiple and Parallel Multiple are not mentioned as Boundary Non-Interrupting. Furthermore,
    Cancel and Compensations are not mentioned as Boundary Events that always interrupt.

    In (iii) Compensation is not mentioned as an interrupting Event for an Event Sub-Process.

    SUGGESTIONS:

    In (ii)
    “(only for Message, Signal, Timer and Conditional Events, not for Error Events)” should be replaced by “(only for Message,
    Signal, Timer, Conditional, Escalation, Multiple and Parallel Multiple Events, not for Error, Cancel and Compensation
    Events)”

    In (iii)
    “(Error, Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)” should be replaced by “Error, Escalation, Message, Signal, Timer, Conditional, Compensation, Multiple, and Parallel Multiple)”

  • Reported: BPMN 2.0 — Fri, 15 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 281. Typo in Table 10.100

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

    Table 10.100. Row “signalRef”.
    It says:
    “If the trigger is a Signal, then a Signal is provided.”

    “signalRef” is optional and it is similar to “errorRef” (see Table 10.96 p. 274) and “escalationRef” (see Table 10.97 p. 275).

    Then, it should say
    “If the trigger is a Signal, then a Signal payload MAY be provided.”

  • Reported: BPMN 2.0 — Fri, 15 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Number of internal markers for Choreography Activities

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

    i) Chapter/Section 11.4.1. Page 335. It says:
    “There are two types of internal markers (see Figure 11.12):”

    “A Choreography Task MAY have only one of the three (3) markers at one time.”

    ii) Chapter/Section 11.4.2. Page 341. It says:
    “There are two types of internal markers (see Figure 11.22):”

    “A Sub-Choreography MAY have only one of the three (3) markers at one time.”

    COMMENTS:

    In and (ii) it is clear that there are three markers, not two.

    SUGGESTIONS:

    In it should say:
    “There are three (3) types of internal markers (see Figure 11.12):”

    In (ii) it should say:
    “There are three (3) types of internal markers (see Figure 11.22):”

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong Public Process in Figure 10.127

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

    i) Chapter/Section 10.8. Page 318. It says:
    “For example Figure 10.127 shows a public Process at the top with a Send Task and Receive Task. A supporting private Process is shown at the bottom.”

    ii) Chapter/Section 10.8. Page 319. Figure 10.127.
    Public Process (at the top) consists of a Receive Task followed by a Send Task.

    iii) Issue 14652: Private process example correction (bpmn2-ftf). It says:
    “The private process in Figure 10-122 (One Process supporting to another)
    should have activity X and event B in parallel, because event B may
    arrive while X is executing, which would be lost in the current example.
    See webinar example on slide 51 in bmi/09-06-02.”

    COMMENTS:

    In it is stated that the A must be a Send Task, and B must be a Receive Task.

    In (ii) A is a Receive Task, and B is a Send Task. This contradicts .

    In (iii) it is stated that the problem with the example was the location of Activity X and Event B in the Private Process, nothing is said about Tasks A and B.

    SUGGESTIONS:

    Change the types of Tasks in Public Process:
    Task A should be a Send Task (filled envelope marker)
    Task B should be a Receive Task (unfilled envelope marker)

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 350. Typo

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

    Chapter/Section 11.5.1. Page 350. Table 11.6. Row “None”. It says:
    “Sub-Processes, however, we should look at. The Parent Process can be considered the trigger.”

    COMMENTS:

    This sentence (“we should look at”) seems to be a draft.

    Table 11.6 is devoted to Start Events in Choreography, so “Sub-Processes” and “Process” are not pertinent here.

    SUGGESTIONS:

    Remove it.

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sub-Choreography is not a compound Activity

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

    i) Chapter/Section 8.3.7. Page 87. Figure 8.22. According to classes and their relationships:
    Both Activity and Choreography Activity are sub-classes of Flow Node.

    ii) Chapter/Section 11.4.2. Page 338. It says:
    “A Sub-Choreography is a compound Activity in that it has detail that is defined as a flow of other Activities, in this case, a Choreography.”

    COMMENTS:

    According to Choreography Activity is not a type of Activity, because there is not generalization from Choreography Activity to Activity.

    Then, A Sub-Choreography cannot be a “compound Activity”, because a Sub-Choreography is not a type of Activity.

    SUGGESTIONS:

    In (ii) it should say:
    “A Sub-Choreography is a compound ChoreographyActivity in that it has detail that is defined as a flow of other ChoreographyActivities.”

    “Activity” should be replaced by “ChoreographyActivity”
    “Activities” should be replaced by “ChoreographyActivities

  • Reported: BPMN 2.0 — Mon, 18 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Event Sub-Processes use Multiple and Parallel Multiple Start Events

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

    i) Chapter/Section 10.4.2. Page 248. Table 10.84. Row “Multiple”. It says:
    “This means that there are multiple ways of triggering the Process”

    ii) Chapter/Section 10.4.2. Page 248. Table 10.84. Row “Parallel Multiple”. It says:
    “This means that there are multiple triggers REQUIRED before the Process can be instantiated”

    iii) Chapter/Section 10.4.2. Page 252. Table 10.86. Row “Multiple”. It says:
    “A Multiple Event indicates that that there are multiple ways of triggering the Event Sub-Process.”

    iv) Chapter/Section 10.4.2. Page 252. Table 10.86. Row “Parallel Multiple”. It says:
    “A Parallel Multiple Event indicates that that there are multiple ways of triggering the Event Sub-Process. All of them are REQUIRED to actually …”

    v) Chapter/Section 10.4.5. Page 279. It says:
    “If the trigger is Multiple, there are multiple ways of starting the Process. Only one of them is necessary to trigger the start of the Process. The EventDefinition subclasses will define which triggers apply”

    vi) Chapter/Section 10.4.5. Page 280. It says:
    “If the trigger is Multiple, there are multiple triggers REQUIRED to start the Process. All of them are necessary to trigger the start of the Process. The EventDefinition subclasses will define which triggers apply.”

    COMMENTS:

    and (ii) describe the use of Multiple and Parallel Multiple Start Events in Top-Level Processes.

    (iii) and (iv) describe the use of Multiple and Parallel Multiple Start Events in Event Sub- Processes

    In (v) and (vi) it is not mentioned the fact that Multiple and Parallel Multiple Start Events are used by Event Sub-Processes too.

    SUGGESTIONS:
    In (v) and (vi) “Process” should be replaced by “Process or Event Sub- Process” (4 times)

  • Reported: BPMN 2.0 — Fri, 15 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 270. Typo

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

    It says:
    “When one of the EventDefinition sub-types (e.g., TimerEventDefinition) is defined it is contained in Definitions, or a contained EventDefinition contained in a throw/catch Event.”

    According Figures 8.4 (p.52), 10.69 (p.241) and 10.73 (p.270), it should say:
    “When one of the EventDefinition sub-types (e.g., TimerEventDefinition) is defined it is contained in Definitions, or in a throw/catch Event.”

  • Reported: BPMN 2.0 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 247. “Parallel” instead of “Parallel Multiple”

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

    It says:
    “There are seven (7) types of Start Events for top-level Processes in BPMN (see Table 10.84): None, Message, Timer, Conditional, Signal, Multiple, and Parallel.”

    It should say:
    “There are seven (7) types of Start Events for top-level Processes in BPMN (see Table 10.84): None, Message, Timer, Conditional, Signal, Multiple, and Parallel Multiple.”

    “Parallel” should be replaced by “Parallel Multiple”.

  • Reported: BPMN 2.0 — Thu, 14 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Table 8.14: Example for BPMN's extension mechanism is not schema-valid

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

    The example for BPMN's extension mechanism in Table 8.14 on page 61 (PDF 91) is not valid with respect to the XML Schema.

    The example uses Extension Elements that are already defined in BPMN as part of ioSpecification, namely dataInput, dataOutput, inputSet, and outputSet. To be valid BPMN, those elements must be contained in an 'extensionElements' element and reside in an own XML namespace.

    I'd suggest to use different Extension Elements to avoid confusion with existing BPMN elements.

  • Reported: BPMN 2.0 — Fri, 15 Oct 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistencies and contradictions concerning Error element

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

    ANTECEDENTS:

    i) Chapter/Section 8.3.3. Page 82. Table 8.41. Row “name”. It says:
    “name : string”
    It means that “name” is mandatory.

    ii) Chapter/Section 8.3.3. Page 82. Table 8.41. Row “errorCode”. It says:
    “errorCode: string”
    It means that “errorCode” is mandatory.
    When describing this attribute three cases are identified:

    • End Event
    • Intermediate Event within normal flow
    • Intermediate Event attached to the boundary of an Activity

    iii) Chapter/Section 8.4.3. Page 105. It says:
    “An Operation defines Messages that are consumed and, optionally, produced when the Operation is called. It can also define zero or more errors that are returned when operation fails.” (see Figure 8.36, p.104, Table 8.66, p. 106).

    iv) Chapter/Section 10.4.1. Page 242. It says:
    “A trigger that is propagated is forwarded from the location where the Event has been thrown to the innermost enclosing scope instance (e.g., Process level) which has an attached Event being able to catch the trigger …. If no catching Event is found for an error or escalation trigger, this trigger is unresolved.”

    v) Chapter/Section 10.4.2. Page 250. Table 10.86. Row “Error”. It says:
    “The Error Start Event is only allowed for triggering an in-line Event Sub- Process. If there is only one (1) EventDefinition associated with the Start Event and that EventDefinition is of the subclass ErrorEventDefinition, then the Event is an Error Start Event and uses a lightning marker (see the figures to the right). Given the nature of Errors, an Event Sub-Process with an Error trigger will always interrupt its containing Process.”

    vi) Chapter/Section 10.4.3. Page 255. Table 10.88. Row “Error”. It says:
    “This type of End indicates that a named Error should be generated. All currently active threads in the particular Sub-Process are terminated as a result. The Error will be caught by a Catch Error Intermediate Event with the same errorCode or no errorCode which is on the boundary of the nearest enclosing parent Activity (hierarchically). The behavior of the Process is unspecified if no Activity in the hierarchy has such an Error Intermediate Event. The system executing the process can define additional Error handling in this case, a common one being termination of the Process instance.”

    vii) Chapter/Section 10.4.4. Page 263. Table 10.90. Row “Error”. It says:
    “A catch Intermediate Error Event can only be attached to the boundary of an Activity, i.e., it MAY NOT be used in normal flow. If used in this context, it reacts to (catches) a named Error, or to any Error if a name is not specified. Note that an Error Event always interrupts the Activity to which it is attached, i.e., there is not a non-interrupting version of this Event. The boundary of the Event thus always solid (see figure on the right).”

    viii) Chapter/Section 10.4.5. Page 269. Table 10.93. Row “Error”.
    Three Error Event Definitions are shown:
    Start Event Sub-Process (Interrupting)
    Intermediate Event attached to the boundary of an Activity (interrupting)
    End Event.

    ix) Chapter/Section 10.4.5. Page 274. Table 10.96. Row “error”. It says:
    “error: Error [0..1]
    It means that “error” is optional. (By the way, its name should be errorRef, see Figure 10.80, p.274).

    COMMENTS:

    In the name of an Error is mandatory, it means that the expression “named Error” carries no information, because every Error “is named”. Furthermore, the name of the Error is not used to identify it, the attribute errorCode is used instead.
    Then:

    • in (vi) the sentence “This type of End indicates that a named Error should be generated” is incorrect.
    • in (vii) the sentence “If used in this context, it reacts to (catches) a named Error, or to any Error if a name is not specified” is incorrect.

    In (ii) the attribute errorCode should be optional ([0..1]), because sometimes errorCode is not supplied (according to descriptions in Tables 8.41 and 10.88; it is mandatory only when the processType attribute of the Process is set to executable).

    In (ii) Intermediate Event within normal flow is identified, but it is incorrect, because it doesn’t exist as it is stated in (vii) and (viii). Furthermore, Start Event Sub-Process (Interrupting) is not identified in (ii), but it is in (viii).

    In (ii) when describing End Event, it is said “If the result is an Error, then the errorCode MUST be supplied (if the processType attribute of the Process is set to executable) This “throws” the Error.” It is confusing because the Error is actually thrown when an instance of Error (the “errorRef” of the ErrorEventDefinition) is thrown.

    In (iii) it is said that Operations use Errors too. Nevertheless, Errors are described as if they were associated only with Events.

    In (iv), according to meta-model a catching Error Event may not have an Error instance associated or can be associated to an Error instance without errorCode. In both cases “no catching Event is found”, but it is not clear whether both situations must be treated equally or not.

    In (v) nothing is said about the presence or absence of errorCode as in (vi).

    In (vi) the expression “named Error” is used, which (as stated above) is incorrect. It can be deduced that when an Error is thrown by the End Event it must contain an errorCode. But it not clear if an Error End Event must or must not throw an Error (which is optional, see ix). Besides, the Error can be catching by a Event Sub-Process, what it is not mentioned in (vi).

    In (vii) the expression “named Error” is used, which (as stated above) is incorrect. It seems that “name” is used instead of “errorCode”. It is not clear what happen when no Error is associated to de EventDefinition: Does it react as if an Error without errorCode where associated?

    In (ix) attribute errorRef is optional, but there are no rules concerning when and where an Error should be thrown. Nothing is said about processType attribute of the Process. So, it is possible that “processType attribute of the Process is set to executable” and no Error is provided, in consequence no errorCode could be supplied.

    Summary of problems:

    • The name of the Error cannot be used to match Errors, errorCode must be used instead.
    • According to some descriptions errorCode must be optional.
    • According to the meta-model errorRef is optional, but it is not clear when and where this attribute should be provided.
    • Error is described as if it were used by Events only, but it used by Operation too.

    SUGGESTIONS:

    • Remove all references to “named Errors” and the use of attribute “name” as a matching mechanism.
    • Define whether errorRef (in ErrorEventDefinition element) will be optional or not.
    • Define whether errorCode (in Error element) will be optional or not.
    • Describe all rules concerning errorRef and errorCode in Tables 10.86, 10.88 and 10.90 (where Error Start Event, Error End Event and Error Intermediate Event are described).
    • Describe rules concerning the use or Errors by Operations in section 8.4.3.
    • Remove from Tables 8.41 and 10.96 (where Error and ErrorEventDefinition are described) the rules concerning Events (remember that Errors are used by Operations too, and in the future more BPMN element could used Errors too).

    At least these issues should be clarified:

    a) If the processType attribute of the Process is set to executable, must errorRef or errorCode be supplied? or both?
    b) If errorRef (in ErrorEventDefinition element) is optional:

    • Is errorRef optional for a throwing Error End Event?
    • Is errorRef optional for a catching Error Start and Intermediate Events?
      If this is the case, what happens when an Error arrives?

    c) If errorCode (in Error element) is optional:

    • Is errorCode optional for a throwing Error End Event?
    • Is errorCode optional for a catching Error Start and Intermediate Events?

    d) Can two instances of Error share the same errorCode?

    • If the modeler want to match two Error Events (one throwing and one catching),
      must he/she provide the same Error to both ErrorEventDefinitions or two different Errors with the same errorCode? (According to the meta-model both alternatives are allowed, see Figure 10.80.)
  • Reported: BPMN 2.0 — Tue, 28 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 106. Wrong role name “errorRef” in Table 8.66

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

    Table 8.66. Row “errorRef”

    It says:
    “errorRef: Error [0..*]

    It should say:
    “errorRefs: Error [0..*]

    See Figure 8.36 (p.104).

  • Reported: BPMN 2.0 — Tue, 28 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistencies and contradictions concerning Escalation element

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

    ANTECEDENTS:

    i) Chapter/Section 8.3.4. Page 83. Table 8.42. Row “name”. It says:
    “name : string”
    It means that “name” is mandatory.

    ii) Chapter/Section 8.3.4. Page 83. Table 8.42. Row “escalationCode”.
    “escalationCode: string”
    It means that “escalationCode” is mandatory.
    When describing this attribute three cases are identified:

    • End Event
    • Intermediate Event within normal flow
    • Intermediate Event attached to the boundary of an Activity

    iii) Chapter/Section 10.4.1. Page 242. It says:
    “A trigger that is propagated is forwarded from the location where the Event has been thrown to the innermost enclosing scope instance (e.g., Process level) which has an attached Event being able to catch the trigger …. If no catching Event is found for an error or escalation trigger, this trigger is unresolved.”

    iv) Chapter/Section 10.4.2. Page 250. Table 10.86. Row “Escalation”. It says:
    “Escalation Event Sub-Processes implement measures to expedite the completion of a business Activity, should it not satisfy a constraint specified on its execution (such as a time-based deadline). The Escalation Start Event is only allowed for triggering an in-line Event Sub- Process. If there is only one (1) EventDefinition associated with the Start Event and that EventDefinition is of the subclass EscalationEventDefinition, then the Event is an Escalation Start Event and uses an arrowhead marker…”

    v) Chapter/Section 10.4.3. Page 255. Table 10.88. Row “Escalation”. It says:
    “This type of End indicates that an Escalation should be triggered. Other active threads are not affected by this and continue to be executed. The Escalation will be caught by a Catch Escalation Intermediate Event with the same escalationCode or no escalationCode which is on the boundary of the nearest enclosing parent Activity (hierarchically). The behavior of the Process is unspecified if no Activity in the hierarchy has such an Escalation Intermediate Event.”

    vi) Chapter/Section 10.4.4. Page 263. Table 10.90. Row “Escalation”. It says:
    “This type of Event is used for handling a named Escalation. If attached to the boundary of an Activity, the Intermediate Event catches an Escalation. In contrast to an Error, an Escalation by default is assumed to not abort the Activity to which the boundary Event is attached...”

    vii) Chapter/Section 10.4.5. Page 269. Table 10.93. Row “Escalation”.
    Six Escalation Event Definitions are shown:
    Start Event Sub-Process (Interrupting and non-interrupting)
    Intermediate Event attached to the boundary of an Activity (interrupting and non-interrupting)
    Intermediate Event within normal flow
    End Event

    viii) Chapter/Section 10.4.5. Page 275. Table 10.97. Row “escalationRef”. It says:
    “escalationRef: Escalation [0..1]
    It means that “escalationRef” is optional.

    COMMENTS:

    In the name of an Escalation is mandatory, it means that the expression “named Escalation” carries no information, because every Escalation “is named”. Furthermore, the name of the Escalation is not used to identify it, the attribute escalationCode is used instead.
    Then:

    • in (vi) the sentence “This type of Event is used for handling a named Escalation” is incorrect.

    In (ii) the attribute escalationCode should be optional ([0..1]), because sometimes escalationCode is not supplied (according to descriptions in Tables 8.42 and 10.88; it is mandatory only when the processType attribute of the Process is set to executable).

    In (ii) Start Event Sub-Process (Interrupting) is not identified in, but it is in (vii).

    In (ii) when describing End Event, it is said “If the Result is an Escalation, then the escalationCode MUST be supplied (if the processType attribute of the Process is set to executable). This “throws” the Escalation.” It is confusing because the Escalation is actually thrown when an instance of Escalation (the “escalationRef” of the EscalationEventDefinition) is thrown.

    In (iii), according to meta-model a catching Escalation Event may not have an Escalation instance associated or can be associated to an Escalation instance without escalationCode. In both cases “no catching Event is found”, but it is not clear whether both situations must be treated equally or not.

    In (iv) nothing is said about the presence or absence of escalationCode as in (v).

    In (v) it can be deduced that when an Escalation is thrown by the End Event it must contain an escalationCode. But it not clear if an Escalation End Event must or must not throw an Escalation (which is optional, see viii). Besides, the Escalation can be catching by a Event Sub-Process, what it is not mentioned in (v).

    In (vi) the expression “named Escalation” is used, which (as stated above) is incorrect. Furthermore, nothing is said about the presence or absence of escalationCode as in (v).

    In (viii) attribute escalationRef is optional, but there no rules concerning when and where an Escalation should be thrown. Nothing is said about processType attribute of the Process. So, it is possible that “processType attribute of the Process is set to executable” and no Escalation is provided, in consequence no escalationCode could be supplied.

    Summary of problems:

    • The name of the Escalation cannot be used to match Escalations, escalationCode must be used instead.
    • According to some descriptions escalationCode must be optional.
    • According to the meta-model escalationRef is optional, but it is not clear when and where this attribute should be provided.
    • Escalation is described as if it were used by Events only, but in the future it could used by others elements (as Error is used by Events and Operations).

    SUGGESTIONS:

    • Remove all references to “named Escalations” and the use of attribute “name” as a matching mechanism.
    • Define whether escalationRef (in EscalationEventDefinition element) will be optional or not.
    • Define whether escalationCode (in Escalation element) will be optional or not.
    • Describe all rules concerning escalationRef and escalationCode in Tables 10.86, 10.88 and 10.90 (where Escalation Start Event, Escalation End Event and Escalation Intermediate Event are described).
    • Remove from Tables 8.42 and 10.97 (where Escalation and EscalationEventDefinition are described) the rules concerning Events (remember that Escalations could be used by other elements too).

    At least these issues should be clarified:

    a) If the processType attribute of the Process is set to executable, must escalationRef or escalationCode be supplied? or both?
    b) If escalationRef (in EscalationrEventDefinition element) is optional:

    • Is escalationRef optional for a throwing Escalation End and Intermediate Events?
    • Is escalationRef optional for a catching Escalation Start and Intermediate Events?
      If this is the case, what happens when an Escalation arrives?

    c) If escalationCode (in Escalation element) is optional:

    • Is escalationCode optional for a throwing Escalation End and Intermediate Events?
    • Is escalationCode optional for a catching Escalation Start and Intermediate Events?

    d) Can two instances of Escalation share the same escalationCode?

    • If the modeler want to match two Escalations Events (one throwing and one catching),
      must he/she provide the same Escalation to both EscalationEventDefinitions or two different Escalations with the same escalationCode? (According to the meta-model both alternatives are allowed, see Figure 10.82)
  • Reported: BPMN 2.0 — Tue, 28 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Number of Participant bands and Messages in a Choreography Task

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

    i) Chapter/Section 7.2.2. Page 32 . Table 7.2. Row “Choreography Task”. It says:
    “A Choreography Task is an atomic Activity in a Choreography (see page 333). It represents a set of one (1) or more Message exchanges. Each Choreography Task involves two (2) Participants. The name of the Choreography Task and each of the Participants are all displayed in the different bands that make up the shape’s graphical notation. There are two (2) or more Participant Bands and one Task Name Band.”
    --------------------------------------------------------------------------

    ii) Chapter/Section 11.4. Page 332. Figure 11.6.
    Model association from “ChoreographyTask” to “MessageFlow” (role name “messageFlowRefs”) has multiplicity [1..2]
    --------------------------------------------------------------------------

    iii) Chapter/Section 11.4. Page 332. Table 11.1. Row “participantRefs”. It says:
    “participantRefs: Participant [2..*]
    --------------------------------------------------------------------------

    iv) Chapter/Section 11.4.1. Page 333. It says:
    “A Choreography Task is an atomic Activity in a Choreography Process. It represents an Interaction, which is one (1) or two (2) Message exchanges between two (2) Participants. Using a Collaboration diagram to view these elements (see page 109 for more information on Collaboration), we would see the two (2) Pools representing the two (2) Participants of the Interaction …”
    --------------------------------------------------------------------------

    v) Chapter/Section 11.4.1. Page 333. It says:
    “There are two (2) or more Participant Bands and one Task Name Band (see Figure 11.8).”
    --------------------------------------------------------------------------

    vi) Chapter/Section 11.4.1. Page 335. It says:
    “The three (3) bands in the Choreography Task shape provide the distinction between this type of Task and an Orchestration Task (in a traditional BPMN diagram).”
    --------------------------------------------------------------------------

    vii) Chapter/Section 11.4.1. Page 338. Table 11.2. Row “messageFlowRef”. It says:
    “messageFlowRef: Message Flow [1..*]
    “Although not graphical represented, Choreography Task contain one (1) or more Message Flows that represent the interaction(s) between the Participants referenced by the Choreography Task.”
    --------------------------------------------------------------------------

    COMMENTS:

    There are inconsistencies concerning the number of Messages, Participants and Participant Bands in a Choreography Task.

    In
    Messages: 1 or more.
    Participants: 2
    Participant bands: 2 or more

    In (ii)
    Messages: 1 or 2.

    In (iii)
    Participants: 2 or more.
    (Because “ChoreographyTask” inherits “participantRefs” from “ChoreographyActivity”.)

    In (iv)
    Messages: 1 or 2.
    Participants: 2

    In (v)
    Participant bands: 2 or more

    In (vi)
    Participant bands: 2.
    (There are 3 bands, one of them is de Task Name band.)

    In (vii)
    Messages: 1 or more.

    It seems that the correct numbers should be:
    Messages: 1 or 2
    Participants: 2
    Task name band: 1
    Participants bands: 2
    Total bands: 3 (= 1 + 2)

    SUGGESTIONS:

    In
    “one (1) or more Message exchanges” should be replaced by “one (1) or two (2) Message exchanges”
    “two (2) or more Participant Bands” should be replaced by “two (2) Participant Bands”

    In (ii) nothing

    In (iii)
    A new model association should be drawn in Figure 11.6 from “ChoreographyTask” to “Participant”, which actually would not be a new model association but a redefinition of “participantsRefs” form “ChoreographyActivity” to “Participant”.

    It should be annotated: [2..2] +participantRefs

    {redefines participantRefs}

    (See OMG Unified Modeling LanguageTM (OMG UML), Infrastructure. formal/2009-02-04. Pages 113, 150)

    In (iv) nothing

    In (v)
    “two (2) or more Participant Bands” should be replaced by “two (2) Participant Bands”

    In (vi) nothing

    In (vii)
    “messageFlowRef: Message Flow [1..*]” should be replaced by “messageFlowRefs: Message Flow [1..2]

    “one (1) or more Message Flows” should be replaced by “one (1) or two (2) Message Flows”

    A new row should be added to Table 11.2
    “participantRefs: Participant [2..2]
    “A Choreography Task has two (2) Participants (see page 115 for more information on Participants). This is a redefinition of participantRefs of ChoreographyActivity (see Table 11.1).”

  • Reported: BPMN 2.0 — Thu, 23 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Is “Association” a type of “Artifact” or not?

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

    ANTECEDENTS:

    i) Chapter/Section 7.2. Page 28, it says:

    “There are four (4) Connecting Objects:
    Sequence Flows
    Message Flows
    Associations
    Data Associations”

    and

    “The current set of Artifacts includes:
    Group
    Text Annotation”

    --------------------------------------------------------------------------

    ii) Chapter/Section 8.3.1. Figure 8.8. Page 66.

    In Figure 8.8 “Association” is a type of “Artifact”.
    --------------------------------------------------------------------------

    iii) Chapter/Section 11.3.2. Page 331.
    When describing Artifacts in Choreographies, it says: “Both Text Annotations and Groups can be used within Choreographies and all BPMN diagrams. There are no restrictions on their use.”

    --------------------------------------------------------------------------

    COMMENTS:

    In “Associations” are identified as connectors, and are not included among the “Artifacts”.

    In (ii) According to the Meta-model “Association” is an “Artifact”, and it is described inside Section “8.3.12 Artifacts” (p.67). but in other parts of the document this fact is ignored.

    In (iii) “Associations” are not mentioned as a type of “Artifact”.

    SUGGESTION:

    On pages 28 and 331, state that “Association” is a type of “Artifact” in order to be consistent with the meta-model.

  • Reported: BPMN 2.0 — Thu, 23 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 83. Wrong reference to Table 8.42

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

    It says:
    “The Escalation element inherits the attributes and model associations of BaseElement (see Table 8.5), through its relationship to RootElement. Table 8.41 presents the additional model associations of the Error element:”

    Table 8.41 is referenced, but it is 8.42 which should be mentioned.

    Then, it should say:
    “The Escalation element inherits the attributes and model associations of BaseElement (see Table 8.5), through its relationship to RootElement. Table 8.42 presents the additional attributes and model associations of the Escalation element:”

    “Table 8.41 presents the additional model associations of the Error element” should be replaced by “Table 8.42 presents the additional attributes and model associations of the Escalation element”

  • Reported: BPMN 2.0 — Mon, 27 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistencies related to Default Sequence Flow

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

    i) Chapter/Section 7.2.2. Page 34. Table 7.2. Row “Default flow”. It says:
    “For Data-Based Exclusive Gateways or Inclusive Gateways, one type of flow is the Default condition flow …”
    --------------------------------------------------------------------------

    ii) Chapter/Section 8.3.9. Page 90
    According to Figure 8.24 a Sequence Flow can be the “default flow” of many Gateways simultaneously (see multiplicity [0..*] of roles exclusiveGateway, inclusiveGateway and complexGateway).

    The same occurs in Figure 10.104 (p.297); Figure 10.107 (p. 299); Figure 10.109 (p.301); and Figure 10.114 (p.304).
    --------------------------------------------------------------------------

    iii) Chapter/Section 8.3.13. Page 98. Figure 8.35.
    Multiplicity of role “activity” (from “SequenceFlow” to “Activity”) is [1..1].

    The same occurs in Figure 10.6 (p.155).
    --------------------------------------------------------------------------

    iv) Chapter/Section 11.3.1. Page 330. It says:
    “Default Sequence Flows: For Exclusive Gateways, Inclusive Gateways, and Choreography Activities that have Conditional Sequence Flows, one of the outgoing Sequence Flows MAY be a Default Sequence Flow. Because the other outgoing Sequence Flows will have appropriately visible of data as described above, the Participants would know if all the other conditions would be false, thus the Default Sequence Flow would be selected and the Choreography would move down that Sequence Flow.”
    --------------------------------------------------------------------------

    v) Chapter/Section 11.4. Page 332. Figure 11.6.
    “ChoreographyActivity” is not associated with “SequenceFlow” for optional default.

    The same occurs in Figure 8.35, p. 98.
    ---------------------------------------------------------------------------

    COMMENTS:

    In : “Default flows” are used by Complex Gateways and Activities too, but they are not mentioned. Furthermore, in BPMN 2 the name is “Exclusive Gateway” not “Data-Based Exclusive Gateway” (see p. 33)

    In (ii): It is impossible for a Sequence Flow to be the “default flow” of more than one Gateway or Activity simultaneously, because a Sequence Flow has only one FlowNode as its sourceRef (Figure 8.35, p.98; see also Section 8.3.13).

    In (iii): Multiplicity [1..1] of role “activity” (from “SequenceFlow” to “Activity”) means that every Sequence Flow is the default of exactly one Activity, which is not possible.

    In (iv): Complex Gateways can have default in Orchestrations, but they are not mentioned for Choreographies (… For Exclusive Gateways, Inclusive Gateways, and Choreography Activities that have Conditional Sequence Flows …).

    In (v): Choreography Activities can have default, but the corresponding associations between “ChoreographyActivity” and “SequenceFlow” in Figures 8.35 and 11.6 are not shown

    SUGGESTIONS:

    In : It says:
    “For Data-Based Exclusive Gateways or Inclusive Gateways, one type of flow is the Default condition flow …”

    It should say:
    “For Exclusive, Inclusive or Complex Gateways, or Activities one type of flow is the Default condition flow …”

    In (ii): Multiplicity of roles exclusiveGateway, inclusiveGateway and complexGateway in Figures 8.24, 10.104, 10.107, 10.109 and 10.114 should be changed from [0..*] to [0..1].
    Furthermore, in Figures 8.24 and 10.104 a constrain

    {XOR }

    should be used in order to underline that a Sequence Flow cannot be a default flow of two or more Flow Nodes simultaneously (See OMG Unified Modeling LanguageTM (OMG UML), Infrastructure. formal/2009-02-04. Pages 41, 42, 43). This {XOR] must include the associations from “SequenceFlow” to “ExclusiveGateway”, “ EnclusiveGateway”, “ ComplexGateway”, “Activity” and “ ChoreographyActivity”.

    In (iii): Multiplicity of role “activity” (from “SequenceFlow” to “Activity”) in Figures 8.35 and 10.6 should be changed from [1..1] to [0..1].

    In (iv): If default are allowed in Choreographies for Complex Gateways, then “For Exclusive Gateways, Inclusive Gateways, and Choreography Activities that have Conditional Sequence Flows” should be replaced by “For Exclusive Gateways, Inclusive Gateways,, Complex Gateways, and Choreography Activities that have Conditional Sequence Flows”.

    In (v): The corresponding model associations (between “ChoreographyActivity” and “SequenceFlow” : +activity [0..1] --> +default [0..1]) should be added to Figures 8.35 and 11.6.
    Also, the corresponding row “default” should be added to Table 11.1 (p.332). (Similar to row “default” in Table 10.3, p. 156).

  • Reported: BPMN 2.0 — Thu, 23 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Some Tokens consumed by Complex Gateways don’t reach end nodes

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

    ANTECEDENTS:

    i) Chapter/Section 7.1.1. Page 27 (“Understanding the Behavior of Diagrams”), it says:
    “A Start Event generates a token that MUST eventually be consumed at an End Event. (which MAY be implicit if not graphically displayed).”.
    --------------------------------------------------------------------------

    ii) Chapter/Section 10.4.3. Page 254, it says:
    “All the tokens that were generated within the Process MUST be consumed by an End Event before the Process has been completed.”

    “For Processes without an End Event, a token entering a path-ending Flow Object will be consumed when the processing performed by the object is completed (i.e., when the path has completed), as if the token had then gone on to reach an End Event. When all tokens for a given instance of the Process are consumed, then the Process will reach a state of being completed.”
    --------------------------------------------------------------------------

    iii) Chapter/Section 10.4.3. Page 257, it says:
    “All tokens that are generated at the Start Event for that Process MUST eventually arrive at an End Event.”.
    --------------------------------------------------------------------------

    iv) Chapter/Section 13.1. Page 440, it says:
    “For a Process instance to become completed, all tokens in that instance MUST reach an end node, i.e., a node without outgoing Sequence Flows.”
    --------------------------------------------------------------------------

    COMMENTS:

    These statements are not entirely correct because Complex Gateways can consume tokens and do not generate an outgoing token. These token “are lost” before they could reach and end node, but the Process instance can become complete anyway.

    In the waiting-for-reset phase the Complex Gateway “consumes a token from each incoming Sequence Flow that has a token and from which it had not yet consumed a token in the first phase …the Gateway might not produce any tokens in this phase and no exception is thrown.” (Table 13.5, p.454).
    Then, the tokens are consumed by the Gateway and will never reach any end node. For example, this is the normal behavior of a 3-of-5 discriminator, where the last two tokens will be consumed by the Gateway and lost.

    SUGGESTION:

    State that in order to be completed all tokes in a Process instance MUS be consumed, which is usually (normally) achieved when the tokens reach end nodes.

  • Reported: BPMN 2.0 — Thu, 23 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Is a Choreography a type of Process?

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

    ANTECEDENTS:

    i) Chapter/Section 7.1.1. Page 23, it says:
    “There are three basic types of sub-models within an end-to-end BPMN model:
    Processes (Orchestration), including:
    Private non-executable (internal) Business Processes
    Private executable (internal) Business Processes
    Public Processes
    Choreographies
    Collaborations, which can include Processes and/or Choreographies
    A view of Conversations”
    -------------------------------------------------------------------

    ii) Chapter/Section 7.3. Page 41, it says:
    “The BPMN 2.0 aims to cover three basic models of Processes: private Processes (both executable and non-executable), public Processes, and Choreographies.”
    --------------------------------------------------------------------

    iii) Chapter/Section 9. Page 109, it says:
    “Collaborations … MAY include Processes within the Pools and/or Choreographies between the Pools”
    --------------------------------------------------------------------

    iv) Chapter/Section 11. Page 325, it says:
    “A Choreography is a type of process, but differs in purpose and behavior from a standard BPMN Process.”
    ----------------------------------------------------------------------

    v) Throughout the entire document.
    In several places it is used the expression “Choreography Process” instead of “Choreography”.

    ----------------------------------------------------------------------

    COMMENTS:

    a) Classifications on pages 23 and 41 are different. It is not clear the difference between “types of sub-models within an end-to-end BPMN model” and “basic models of Processes”. In the first case “Choreographies are not Processes”, but in the second “Choreographies are Processes”.

    b) According to UML models “Choreographies are not Processes”. See Figure 9.1 (p 109), Figure 10.2 (p. 150) and Figure 11.1 (p. 326).

    c) Maybe in a broad sense a “Choreography IS a Process”. But the formal definitions (UML models in BPMN 2.0 specification) make a clear distinction between both concepts. Which ­ of course ­are tightly interrelated.

    SUGGESTIONS:

    Modify the classification on page 41 in order to be consistent with the classification on page 23.

    Replace “Choreography Process” by “Choreography”.

    On page 325 replace “A Choreography is a type of process, …” by “A Choreography is like a process, ..”

  • Reported: BPMN 2.0 — Thu, 23 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 364. Number of Choreography Activities preceding an Inclusive Gateway

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

    It says:
    “For the split behavior to be enforced, the initiators of Choreography Activities immediately following the Gateway and the receiver of Choreography Activities immediately preceding the Gateway are the same Participant (i.e., A).”

    It is said “initiators of Choreography Activities”, meaning that there will be multiple Choreography Activities after the Gateway.

    But it is said “the receiver of Choreography Activities”, so it is not clear what the author wanted to communicate: One or multiple Choreography Activities before the Gateway. Both cases are possible (see page. 297).

    In the example (Figure 11.42, p.365) only one Choreography Task precedes the Gateways, but it is just one possible configuration.

    Then, it should say:
    1) “For the split behavior to be enforced, the initiators of Choreography Activities immediately following the Gateway and the receiver of Choreography Activity immediately preceding the Gateway are the same Participant (i.e., A).”

    or

    2) “For the split behavior to be enforced, the initiators of Choreography Activities immediately following the Gateway and the receivers of Choreography Activities immediately preceding the Gateway are the same Participant (i.e., A).”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 363. Wrong names of Choreography Tasks

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

    Figure 11.40.

    Choreography Task names are all the same: Choreography Task 1.

    They should be: Choreography Task 1, Choreography Task 2, and Choreography Task 3.

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 352. “escalation” instead of “non- interrupting

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

    Table 11.7. Row “Timer: Attached to Activity boundary”

    It says:
    “This includes both interrupting and escalation Events.”

    “Escalation” does not make sense here.

    Then, it should say:
    “This includes both interrupting and non- interrupting Events.”

    “escalation” should be replaced by “non- interrupting”

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 312. Wrong name of Figure 10.122

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

    It says
    “Figure 10.122 - Monitoring Class Diagram”

    Figure describes A Compensation Event Sub-Process (see last paragraph on page 311).

    Then, it should say
    “Figure 10.122 - Compensation Event Sub-Process”

    “Monitoring Class Diagram” should be replaced by “Compensation Event Sub-Process

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 274. Wrong role name “errorRef” in Table 10.96

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

    Table 10.96. Row “error”

    It says:
    “error: Error [0..1]

    It should say:
    “errorRef: Error [0..1]

    See Figure 10.80 (p.274).

  • Reported: BPMN 2.0 — Sun, 19 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 10.30 is incorrect

  • Key: BPMN21-202
  • Legacy Issue Number: 15601
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Figure 10.30 shows a collapsed Event Sub-Process. This figure is supposed to have an event marker in the upper left of the shape (as described in the bullet directly above it).

  • Reported: BPMN 2.0 — Sun, 19 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 352. “Cancel” instead of “Compensation

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

    a) Table 11.7. Row “Compensation: in Normal Flow”

    It says:
    “…there would be no indicator as to who is the source of the Cancel.”

    Compensation Event is described here.

    Then, it should say:
    “…there would be no indicator as to who is the source of the Compensation.”

    “Cancel” should be replaced by “Compensation”

    b) Table 11.7. Row “Compensation: Attached to Activity boundary”

    It says:
    “…on the Participant Band that is receiving the Cancel.”

    Compensation Event is described here.

    Then, it should say:
    “…on the Participant Band that is receiving the Compensation.”

    “Cancel” should be replaced by “Compensation

  • Reported: BPMN 2.0 — Sat, 18 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Adding child attributes and child elements in XSLT causes errors

  • Key: BPMN21-109
  • Legacy Issue Number: 15448
  • Status: open  
  • Source: wu.ac.at ( abaumgra@wu.ac.at)
  • Summary:

    The examples of Business Process Model and Notation (BPMN) Version 2.0 - Beta 2, (May 2010) are valid with the provided XML Schema: spec/BPMN/2.0/20100501/BPMN20.xsd. However, the spec/BPMN/2.0/20100501/BPMN20-ToXMI.xslt does not transform these models into a complete XMI file. For example UserTasks with an implementation and ioSpecification is defined in BPMN as follows:
    <semantic:userTask implementation="##unspecified" completionQuantity="1" isForCompensation="false" startQuantity="1" name="Review Issue List" id="_6-66">
    <semantic:incoming>_6-167</semantic:incoming>
    <semantic:outgoing>_6-169</semantic:outgoing>
    <semantic:ioSpecification>
    <semantic:dataInput id="Din1276277381462"/>
    <semantic:inputSet>
    <semantic:dataInputRefs>Din1276277381462</semantic:dataInputRefs>
    </semantic:inputSet>
    <semantic:outputSet/>
    </semantic:ioSpecification>
    <semantic:dataInputAssociation id="_6-151">
    <semantic:sourceRef>_6-139</semantic:sourceRef>
    <semantic:targetRef>Din1276277381462</semantic:targetRef>
    </semantic:dataInputAssociation>
    </semantic:userTask>

    After the transformation with "BPMN20-ToXMI.xslt" I get the following result (without the specified implementation):
    <flowElements xmi:type="bpmnxmi:UserTask" id="_6-66" name="Review Issue List" outgoing="_6-169 " incoming="_6-167 " isForCompensation="false" startQuantity="1" completionQuantity="1">
    <ioSpecification xmi:type="bpmnxmi:InputOutputSpecification">
    <inputSets xmi:type="bpmnxmi:InputSet" dataInputRefs="Din1276277381462 "/>
    <outputSets xmi:type="bpmnxmi:OutputSet"/>
    <dataInputs xmi:type="bpmnxmi:DataInput" id="Din1276277381462"/>
    </ioSpecification>
    <dataInputAssociations xmi:type="bpmnxmi:DataInputAssociation" id="_6-151" targetRef="Din1276277381462 " sourceRef="_6-139 "/>
    </flowElements>

    I took the "Email Voting 2.bpmn" example from the spec/BPMN/2.0/examples/ZIP. The transformation of "Email Voting 2.bpmn" produces the following error messages:
    /XSLT-Transformation/BPMN20-ToXMI.xslt; Line #8; Column #116; Cannot add attribute dataObjectRef after child nodes or before an element is produced. Attribute will be ignored.
    OR
    /XSLT-Transformation/BPMN20-ToXMI.xslt; Line #8; Column #116; Cannot add attribute implementation after child nodes or before an element is produced. Attribute will be ignored.
    (similar messages for cancelActivity, dataObjectRef, messageRef, attachedToRef, isCollection)

  • Reported: BPMN 2.0 — Mon, 6 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page154. Wrong reference to chapter 13

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

    It says
    “…Chapter 14 (see page 440).”

    It should say
    “…Chapter 13 (see page 440).”

    “Chapter 14” should be replaced by “Chapter 13"

  • Reported: BPMN 2.0 — Mon, 6 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page168. Wrong reference to figure 10.18

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

    It says
    “A Manual Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a hand figure marker that distinguishes the shape from other Task types (as shown in Figure 10.17).”

    It should say
    “A Manual Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a hand figure marker that distinguishes the shape from other Task types (as shown in Figure 10.18).”

    “Figure 10.17” should be replaced by “Figure 10.18”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page167. Wrong reference to page 171

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

    It says
    “See “User Task” on page 167 within the larger section of “Human Interactions” for the details of User Tasks.”

    It should say
    “See “User Task” on page 171 within the larger section of “Human Interactions” for the details of User Tasks.”

    “page 167” should be replaced by “page 171

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page170. Wrong references to figures 10.17 10.18

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

    It says
    “…the human involvement is REQUIRED to complete the Task (see Figure 10.15 and Figure 10.17, above).”

    It should say
    “…the human involvement is REQUIRED to complete the Task (see Figure 10.17 and Figure 10.18, above).”

    “Figure 10.15” should be replaced by “Figure 10.17”

    “Figure 10.17” should be replaced by “Figure 10.18”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 169. Wrong reference to figure 10.20

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

    It says
    “However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Script Task (see Figure 10.11).”

    It should say
    “However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Script Task (see Figure 10.20).”

    “Figure 10.11” should be replaced by “Figure 10.20”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 219. Wrong reference to table 10.58

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

    It says
    “Figure 10.54 presents the additional attributes and model associations of the InputOutputSpecification element:”

    It should say
    “Table 10.58 presents the additional attributes and model associations of the InputOutputSpecification element:”

    “Figure 10.54” should be replaced by “Table 10.58”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 217. Wrong reference to table 10.57

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

    It says
    “Table 10.54 presents the additional attributes of the Property element:”

    It should say
    “Table 10.57 presents the additional attributes of the Property element:”

    “Table 10.54” should be replaced by “Table 10.57”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 181. Wrong reference to figure 10.29

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

    It says
    “Figure 10.28 shows the class diagram related to Sub-Processes.”

    It should say
    “Figure 10.29 shows the class diagram related to Sub-Processes.”

    “Figure 10.28” should be replaced by “Figure 10.29”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 180. Wrong reference to figure 10.25

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

    It says
    “The (Collapsed) Sub-Process marker, seen in Figure 10.24, can be combined …”

    It should say
    “The (Collapsed) Sub-Process marker, seen in Figure 10.25, can be combined …”

    “Figure 10.24” should be replaced by “Figure 10.25”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 191. Wrong reference to figure 10.42

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

    It says
    “A Call Activity MUST fullfil the data requirements, as well as return the data produced by the CallableElement being invoked (see Figure 10.41).”

    It should say
    “A Call Activity MUST fullfil the data requirements, as well as return the data produced by the CallableElement being invoked (see Figure 10.42).”

    “Figure 10.41” should be replaced by “Figure 10.42”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 212. Wrong references to tables 10.51 10.52

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

    It says
    “…and ItemAwareElement (Table 10.52). Table 10.54 presents the additional attributes of the DataObject element:”

    It should say
    “…and ItemAwareElement (Table 10.51). Table 10.52 presents the additional attributes of the DataObject element:”

    “Table 10.52” should be replaced by “Table 10.51”
    “Table 10.54” should be replaced by “Table 10.52”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page168 . Wrong reference to figure 10.19

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

    It says
    “However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.11).”

    It should say
    “However, there is a graphical marker in the upper left corner of the shape that indicates that the Task is a Business Rule Task (see Figure 10.19).”

    “Figure 10.11” should be replaced by “Figure 10.19”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 172. Wrong reference to table 10.4

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

    It says
    “The User Task inherits the instance attributes of Activity (see Table 8.49).”

    It should say
    “The User Task inherits the instance attributes of Activity (see Table 10.4).”

    “Table 8.49” should be replaced by “Table 10.4”

  • Reported: BPMN 2.0 — Thu, 9 Sep 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Ambiguous statement about DataObjects and DataObjectReference

  • Key: BPMN21-91
  • Legacy Issue Number: 15388
  • Status: open  
  • Source: Rosch Consulting ( Cristina Conrad)
  • Summary:

    In section 10.3.1 there are some confusing statements about DataObjects and DataObjectReference. One statement reads "Data Object Reference cannot specify item definitions, and Data Objects cannot specify states." (page 215) and on the next page there is another statement that reads "Data Object elements can optionally reference a DataState element, which is the state of the data contained in the Data Object (see an example of DataStates used for Data Objects in Figure 7.8)." Can then DataObjects reference a state? Or is the "state" in the first sentence a different kind of state?

    Furthermore the schema (http://www.omg.org/spec/BPMN/2.0/20100501/Semantic.xsd) specifies that the DataOjectReference may have a reference to the item definition:
    <xsd:element name="dataObjectReference" type="tDataObjectReference" substitutionGroup="flowElement" />
    <xsd:complexType name="tDataObjectReference">
    <xsd:complexContent>
    <xsd:extension base="tFlowElement">
    <xsd:sequence>
    <xsd:element ref="dataState" minOccurs="0" maxOccurs="1" />
    </xsd:sequence>
    <xsd:attribute name="itemSubjectRef" type="xsd:QName" />
    <xsd:attribute name="dataObjectRef" type="xsd:IDREF" />
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>

    And that the DataObject may have a state:
    <xsd:element name="dataObject" type="tDataObject" substitutionGroup="flowElement" />
    <xsd:complexType name="tDataObject">
    <xsd:complexContent>
    <xsd:extension base="tFlowElement">
    <xsd:sequence>
    <xsd:element ref="dataState" minOccurs="0" maxOccurs="1" />
    </xsd:sequence>
    <xsd:attribute name="itemSubjectRef" type="xsd:QName" />
    <xsd:attribute name="isCollection" type="xsd:boolean" default="false" />
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>

  • Reported: BPMN 2.0 — Fri, 30 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Replace "process" attribute of a laneSet with "flowElementsContainer"?

  • Key: BPMN21-90
  • Legacy Issue Number: 15386
  • Status: open  
  • Source: USoft B.V. ( Cristina Constantin)
  • Summary:

    In BPMN2.0 beta1 LaneSet had a relationship with Process. This was changed in beta 2 and now LaneSet has a relationship with FlowElementsContainer, with the exception of Choreographies or Sub-Choreographies (see Figure 10.126 - The Lane class diagram ). In Table 10.134 ­ LaneSet attributes and model associations (of BETA2 document ) I see that there is a process attribute described as "the process owing the Lane set". Shouldn’t there be a "flowElementsContainer" attribute (as the LaneSet can be owned by a Sub-Process too) instead of the "process" attribute?

  • Reported: BPMN 2.0 — Thu, 29 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect reference in loopcharacteristics class diagram

  • Key: BPMN21-89
  • Legacy Issue Number: 15385
  • Status: open  
  • Source: USoft ( Rene de Bruin)
  • Summary:

    In the loopcharacteristics class diagram (figure 10.45) there are two references between StandardLoopCharacteristics and Expression. The one named 'loopMaximum' is not correct. LoopMaximum is an integer and is an attribute of StandardLoopCharacteristics (see table 10.28)

  • Reported: BPMN 2.0 — Wed, 28 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Define rules for placement of multiple activity markers

  • Key: BPMN21-84
  • Legacy Issue Number: 15255
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    A Task or Sub-Process may have multiple markers (e.g., looping, compensation, etc.). But the spec does not explicitly define how the markers should be ordered. The examples in the spec are not consistent in how they are presented.

  • Reported: BPMN 2.0b1 — Mon, 17 May 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Data associations need to be revisited and their use clarified.

  • Key: BPMN21-83
  • Legacy Issue Number: 15253
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Data associations need to be revisited and their use clarified.

    Data association should have there own visual depiction. Using the look of association is misleading as data associations have a different meaning than associations.

    A data association is an edge between flow elements (data objects(ref) and data stores(ref))as such they should not cross boundaries of pools or can they? This is not clear.
    It is also not clear if data objects(ref) and data stores (ref) can be drwan outside lanesets or pools.

  • Reported: BPMN 2.0b1 — Thu, 13 May 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistency between Boundary Event attribute names in Table 10.91 and Table 10.102

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

    The Boundary Event XML schema in Table 10.102 on page 292 (322) defines an attribute called 'attachedToRef', whereas Table 10.91 on page 268 (298) lists an attribute with the name 'attachedTo'.

    Proposal:
    Replace 'attachedTo' with 'attachedToRef' in Table 10.91.

  • Reported: BPMN 2.0 — Wed, 14 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarify Relationship between Collabration Message Flow and Choreography Tasks

  • Key: BPMN21-86
  • Legacy Issue Number: 15284
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    When a Choreography is included in a Collaboration, the spec says that Message Flow can be "wired up" to Choreography Tasks. This needs to be defined better. Are the objects connected or overlapping? What if the Choreography Task moves, etc.

  • Reported: BPMN 2.0 — Tue, 8 Jun 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Incorrect N-to-N relationships in participants class diagram

  • Key: BPMN21-94
  • Legacy Issue Number: 15396
  • Status: open  
  • Source: USoft ( Rene de Bruin)
  • Summary:

    The "Participant attributes and model associations" on page 119 state that a Participant can play 0 or 1 PartnerRole and/or 0 or 1 PartnerEntity. The class diagram on page 118 however displayes an N-to-N relationship between Participant and PartnerRole/PartnerEntity. This is not correct.

  • Reported: BPMN 2.0 — Wed, 4 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Activity as InteractionNode

  • Key: BPMN21-93
  • Legacy Issue Number: 15393
  • Status: open  
  • Source: wu.ac.at ( abaumgra@wu.ac.at)
  • Summary:

    Depicted in the table 7.4 on page 44 and documented on page 124 message flow is allowed from and to activities, but in the meta-model on page 123 only Tasks are InteractionNodes and not activities.

  • Reported: BPMN 2.0 — Tue, 3 Aug 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add Link Events to a sub-conformance level (Descriptive)

  • Key: BPMN21-82
  • Legacy Issue Number: 15217
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    There is a proposal to add conformance levels to BPMN 2.0. The proposal for a Descriptive level should include Link Events.

  • Reported: BPMN 2.0b1 — Wed, 21 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Messages and User Tasks

  • Key: BPMN21-81
  • Legacy Issue Number: 15171
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    It is possible that User Tasks may send and/or receive messages. Thus, the mechanisms built into Send, Receive, and Service Tasks should also apply to User Tasks.
    Also, Message Flow can connect to any Task. Thus, there should be some restrictions on this or messaging should be applied at the Task level instead of the individual sub-types

  • Reported: BPMN 2.0b1 — Fri, 9 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Rethink implementation attribute in Send/Receive/Service Tasks

  • Key: BPMN21-78
  • Legacy Issue Number: 15121
  • Status: open  
  • Source: Intalio, Inc. ( Tammo van Lessen)
  • Summary:

    Currently, send/receive/service/user/business rule tasks have an "implementation" attribute. Based on the information in the spec and from the process orchestration subgroup call, this attribute shall identify the technology to be used for interaction. This can be Web Service, WS-HT or any other protocol/coordination protocol.

    While this makes sense for human tasks and business rule tasks, there are a couple of inconsistencies with Send/Receive/Service tasks. Here is why:

    • Receive Task has an implementation attribute, a message event has not.
    • A Receive Task and a subsequent Send Task that deal with messages defined within the same operation may have different values for the implementation attribute. This is however probably not intended.

    My proposed resolution is to remove the implementation attributes for send/receive/service tasks. We should discuss whether this information is really needed or whether it could be inferred by the implementationRef of the interface/operation tuple. The information might be needed to determine in which technology an interface/operation is implemented. See also http://www.osoa.org/jira/browse/BPMNFTF-519#action_15739

    As an alternative, MessageEventDefinition would need such an attribute as well.

  • Reported: BPMN 2.0b1 — Mon, 8 Mar 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for expanded hexagons

  • Key: BPMN21-74
  • Legacy Issue Number: 15066
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Filed for soaML: When multiple hexagons (conversation/communication) are
    expanded, it isn't possible to tell which message flows go with which
    hexagons, because the hexagons disappear. Should have a grouping
    notation to show which message flow came from expanding which hexagons.

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

definitionalCollaborationRef should be 0..*

  • Key: BPMN21-73
  • Legacy Issue Number: 15065
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Table 10.1, definitionalCollaborationRef includes the phrase “For Processes that interact with other Participants,” which implies that Processes are Participants. In fact they are distinct elements in the metamodel.

    More significantly it states “The definitional Collaboration specifies the Participants the Process interacts with, and more specifically, which individual service, Send or Receive Task, or Message Event, is connected to which Participant through Message Flow.” However a Process could be linked to Participants in many Collaborations and so the multiplicity of [0..1] seems over-limiting.

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multi-language labels for diagram elements

  • Key: BPMN21-71
  • Legacy Issue Number: 15043
  • Status: open  
  • Source: Signavio GmbH ( Gero Decker [X] (Inactive))
  • Summary:

    Most diagram elements carry a text label. The current version of the spec only allows to specify one string that is used as label.

    Multi-national companies often document their business processes in multiple languages (English, German, Spanish..). BPMN should therefore allow to set multiple labels per element (+ default language for the diagram)

  • Reported: BPMN 2.0b1 — Tue, 9 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Ambiguous statements about Sequence Flow

  • Key: BPMN21-70
  • Legacy Issue Number: 15030
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    In section 10.4.1, Event Concepts, (page 211 -241 PDF) there are some confusing statements about Sequence Flow. For example, one statement reads: "The Data Association for a Throw Event is performed when the Sequence Flow arrives at the Throw Event."
    Sequence Flow do not "arrive" in this context. The statements should be revised to refer to Tokens arriving at the Events to make consistent with the rest of the specification

  • Reported: BPMN 2.0b1 — Wed, 3 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add Brief Description for Error and Escalation Event Definitions

  • Key: BPMN21-66
  • Legacy Issue Number: 14854
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The other Event Definitions have a brief description of what they are. The Error and Escalation do not have this description.

  • Reported: BPMN 2.0b1 — Thu, 10 Dec 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Redundancy in specifying data in processes

  • Key: BPMN21-72
  • Legacy Issue Number: 15054
  • Status: open  
  • Source: University of Stuttgart - ISW ( Frank Leymann)
  • Summary:

    There is an obvious redundancy in defining data in BPMN 2.0 (data objects, item definitions, messages, import of schema,...). The current spec does not say what is mandatory to be specified in which situation. At least the most common scenarios should clarified in the spec, e.g. what must be specified in case a WSDL doc is already available and the message described in this document should be used by a service task; or what must be specified in case in incoming message (by a start event) should be copied to a data object.

    I submitted a comprehensive document describing the situation to the issues@omg.org address, whithout any reaction since weeks. I am happy to send this document to the one assigned to this issue and discuss it.

  • Reported: BPMN 2.0b1 — Wed, 17 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Integrate temporal and token semantics

  • Key: BPMN21-77
  • Legacy Issue Number: 15101
  • Status: open  
  • Source: Agile Enterprise Design ( Mr. Fred A. Cummins)
  • Summary:

    BPMN uses temporal semantics currently in process abstraction, and token flow in process execution. It isn't currently clear which semantics should be used for what purposes, or if they are compatible. Temporal semantics should be highlighted as one of the semantics for sequence flow, especially in conjunction with definitional collaborations, and it should be related to the token semantics.

  • Reported: BPMN 2.0b1 — Mon, 1 Mar 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Enforcability rules not complete

  • Key: BPMN21-76
  • Legacy Issue Number: 15071
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Filed for Alistar: Enforcability rules not complete.

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Choreography activities sharing message flow

  • Key: BPMN21-80
  • Legacy Issue Number: 15159
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The spec allows multiple choreography activities to share the same
    message flow. Is that intended?

  • Reported: BPMN 2.0b1 — Mon, 5 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Lists of values

  • Key: BPMN21-79
  • Legacy Issue Number: 15158
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The word "list" is used a fair amount in describing attributes and model
    associations. I think these are intended to be sets in most cases,
    rather than lists (no ordering, no duplicates). In UML, the default is
    sets, you need to add "

    {ordered}

    " "

    {non-unique}

    " to get lists.

  • Reported: BPMN 2.0b1 — Mon, 5 Apr 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CorrelationSubscription Ownership - Sub Process

  • Key: BPMN21-85
  • Legacy Issue Number: 15256
  • Status: open  
  • Source: SAP SE ( Karsten Ploesser)
  • Summary:

    Currently only Processes can 'own' Correlation Subscriptions. However, also Sub Processes should be able to define and own Correlation Subscriptions.

    Use case: restrict the lifecycle of the correlation subscription to the sub process only (as opposed to activating the subscription for the entire lifecycle of the process. This is particularly required in the case of long running processes.

    Proposed resolution:
    Figure 10.29- The Sub-Process class diagram
    Table 10.20 - Sub-Process attributes
    Table 10.48 - SubProcess XML schema
    > ADD attribute correlationSubscriptions:CorrelationSubscription [0..*] to class Sub-Process

  • Reported: BPMN 2.0 — Mon, 17 May 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Event Sub-Process only in Sub-Processes?

  • Key: BPMN21-88
  • Legacy Issue Number: 15375
  • Status: open  
  • Source: Materna GmbH ( Christoph Eickelmann)
  • Summary:

    Chapter 12.2.5 defines on page 178 (208 pdf)
    'An Event Sub-Process is a specialized Sub-Process that is used within a Process (or Sub-Process)'

    Chapter 13.4.4 defines on Page 452 (482 pdf)
    'Event Sub-Processes allow to handle an Event within the context of a given Sub-Processes or Process.'

    The second paragraph of Chapter 13.4.4 specify the cancel/parallel execution of the enclosing Sub-Process. If the Parent Process is not a Sub-Process but a Process, there is no definition.

    Solution:
    Replace in the second paragraph 'enclosing Sub-Process' with 'Parent Process' (2x).

  • Reported: BPMN 2.0 — Thu, 15 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

How to represent Activities that might fit in more than one Lane?

  • Key: BPMN21-69
  • Legacy Issue Number: 15007
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Some activities (or other elements) may have properties that would allow them to be placed in more than one lane. For example, a Task could be assigned multiple resources. Is there a way to display the activity in multiple lanes? If not, how is would the most appropriate lane be chosen?

  • Reported: BPMN 2.0b1 — Thu, 28 Jan 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

XML Schema for dataObjectReference and dataStoreReference are missing

  • Key: BPMN21-92
  • Legacy Issue Number: 15389
  • Status: open  
  • Source: Rosch Consulting ( Cristina Conrad)
  • Summary:

    Schema for dataObjectReference and dataStoreReference is missing from chapter 10.3.4 XML Schema for Data

  • Reported: BPMN 2.0 — Fri, 30 Jul 2010 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for shared correlation properties

  • Key: BPMN21-75
  • Legacy Issue Number: 15070
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Filed for Alistar: Conversations / communications sharing correlation
    properties should be linked graphically.

  • Reported: BPMN 2.0b1 — Thu, 18 Feb 2010 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The spec should clearly state what visual features are available for extensions and which are restricted to core spec

  • Key: BPMN21-68
  • Legacy Issue Number: 14879
  • Status: open  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    Right now there is no clear separation on which graphical features (like line thickness, type of lines, color, etc) vendors are free to use as extensions, and which are restricted for the specification to use.

    We should define which features we want to use in the spec and which ones vendors are free to use. The reason for this is that if a vendor chooses line thickness for some visual extension and in a revision we choose to use the same feature, the vendor is forced to change to adapt (most importantly end-users).

    For example: it is clear that color is open for vendor extensions, and we should pick lines (thickness, dotted, etc) as restricted for our use.

  • Reported: BPMN 2.0b1 — Thu, 17 Dec 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML interface operations do not match BPMN interface operations

  • Key: BPMN21-67
  • Legacy Issue Number: 14876
  • Status: open  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    Currently interface operations in BPMN follow a "Document" model where all the arguments are wrapped in a single "Message" in and out of the operation.
    But in UML, interface operations follow the "RPC" model, where arguments are independent and each one has the "In, Out, InOut" classifier.
    This difference creates several problems when trying to relate/map BPMN and UML operations. Another side effect of the BPMN message model is that you cannot use simple data associations to fill the arguments of a service call. Since the operation is a single type, we have to use transformations to target the arguments (in my case we hide this complexity from the end user, and probably every vendor will do the same.

    So, if the FTF wants to have a reasonable integration with SoaML, we should fix this issue. The proposal is to adopt the UML model, with separate arguments instead of a single document in and out.
    We understand this is a major change, and a migration path from the Beta spec to the final one is a mandatory requirement.

  • Reported: BPMN 2.0b1 — Thu, 17 Dec 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.2.3: Task description needs revisiting

  • Key: BPMN21-60
  • Legacy Issue Number: 14796
  • Status: open  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    Description of issue: The description for Task needs revisiting

    • States that "A Task is used when the work in the Process cannot be broken down to a finer level of details". This doesn't reflect typical usage. It's not that it cannot be broken down, but rather many users simply choose to not break down further. Users model at the level of detail most appropriate for their needs and the needs of their audience.
    • States that "Generally, an end-user and/or applications are used to perform the Task when it is executed". What does this mean? A black-box Task is traditionally used for documentation processes, where what the task does is more important than how (whether by an end-user or by an application) it is done. If users know how it should be done then they would use a specialized task (i.e. User Task or Service Task) rather than Task

    Proposal: Reword to make it clear that Task has a purpose and usage in itself, beyond being a superclass for specialized tasks.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

More description for "Process as a callable element"

  • Key: BPMN21-59
  • Legacy Issue Number: 14794
  • Status: open  
  • Source: Oracle ( Vishal Saxena)
  • Summary:

    ##Source: Oracle (Vishal Saxena, vishal.saxena@oracle.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-118
    ##Original Info: (Severity: Minor - Nature: Revision)

    On page 122 (152 in PDF) under fig 10-2 we describe process as a callable element. I think its a good idea to give small introduction.

    Comments:
    From: wstephe created: Fri, 11 Sep 2009 17:12:58 -0500 (CDT)
    The page and section numbers were updated to match the Beta 1 spec

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Correlation across conversations

  • Key: BPMN21-54
  • Legacy Issue Number: 14777
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The metamodel seems to be missing relations between the correlation
    information in multiple conversations of the same collaboration /
    choreography. For example, in Figure 11.3 (Conversation diagram
    depicting several conversations between Participants in a related
    domain) how does the process internal to Consignee handling the
    Consignee-Retailer conversation map its correlation information to the
    correlation info in the Consignee-Supplier conversation? Without this
    the Consignee conversations with the Retailer and Supplier will be
    uncoordinated.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Throughout Spec [Specification]: Define explicit separation of "modeling" vs "implementation" attributes

  • Key: BPMN21-53
  • Legacy Issue Number: 14775
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    This is number 1 of 12 issues submitted by Bruce Silver:

    Define explicit separation of "modeling" vs "implementation" attributes. The current "core" vs "extended" is nowhere close to this, since modeling needs much of the extended set. Modeling is about orchestration of "abstract" activities, abstract meaning they have a name (label), task type, perhaps markers like loop/MI/adhoc, and unique id of course, but not implementation properties. Abstract sequence flow has name, source and target refs; if conditional, the label is sufficient - you don't require a conditionExpression. Message flow or message event does not require a message attribute, timer event does not require TimeDate or TimeCycle (please rename it to Duration) attribute, error event does not require an error code attribute, etc. Those are for implementation; in modeling it's the diagram that counts, i.e. the label.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Define "Pool"

  • Key: BPMN21-55
  • Legacy Issue Number: 14784
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

    The term "pool" is used extensively in the specification yet the definition seems inconsistent and not tied to the meta model. Sometimes a pool seems to be the role of a participant in a process context. In other cases it seems to be the essential container of a process. It seems to be a graphical element but shows up on ends of associations and in definitions of the semantics. The term "pool" does not seem to have any semantic relevance to process.
    Examples:
    • While a normal Process exists within a Pool, a Choreography exists between Pools (or Participants).
    • A Pool is the graphical representation of a Participant in a Collaboration (see page 235). It is also acts as a "swimlane" and a graphical container for partitioning a set of Activities from other Pools, usually in the context of B2B situations.
    • Nor can Sequence Flow cross a Pool boundary.
    • For message exchanges between pools, Conversations are used to group several Message Flow
    • A Participant is a specific business entity (e.g., a company) or a more general business role (e.g., a buyer, seller, or manufacturer) responsible for the execution of the Process enclosed in a Pool.

    The semantics behind of pool should be clarified and the spec should not use graphical elements to define semantics.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Annex A {Spec]: Add a section that documents the changes between V1.1 and V2.0

  • Key: BPMN21-57
  • Legacy Issue Number: 14788
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    We need to document the changes from V1.1. For example, we removed two attributes from User Task, because the same functionality is being handled elsewhere. We need to document such changes to make it easier for the implementers that need to migrate.

    Comments:
    From: mariano.benitez created: Wed, 8 Oct 2008 15:57:52 -0500 (CDT)
    We also dropped the concept of "streaming" data, so this should also be included in this section.
    Assignments elements are also removed, converted to DataAssociations.

    From: wstephe created: Sat, 12 Sep 2009 13:47:45 -0500 (CDT)
    Spec Draft version removed to prepare for BPMN 2.0 FTF

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Continue versus terminate in loop

  • Key: BPMN21-64
  • Legacy Issue Number: 14824
  • Status: open  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Introduction of end type break within a loop construct (continue construct is already there, implemented by the terminate end type which can be used inside a loop (multi instance activity) to end the loop).”

    This relates to what is e.g. said on page 407: “For a “terminate” End Event, the Sub-Process is abnormally terminated. In case of a multi-instance Activity, only the affected instance is terminated.”

    So, differentation is required between the two modes of getting out of the loop.

  • Reported: BPMN 2.0b1 — Wed, 25 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 8.3.3 [Data] Inconsistency between usage of expressions in Sequence Flows and in Data Associations

  • Key: BPMN21-58
  • Legacy Issue Number: 14790
  • Status: open  
  • Source: Object Management Group ( Mr. Mariano Benitez)
  • Summary:

    We have created some guards around the use of unavailable data in expressions of Data Associations.

    The issue I am raising is about the use case when a conditional sequence flow uses an expression, and the data objects used in that expression are unassigned.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.5 Text duplicated from 8.3.10

  • Key: BPMN21-61
  • Legacy Issue Number: 14800
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: The first three paragraphs in section 8.4 are duplicates of the same paragraphs in 8.3.10 where gateways are introduced.

    Proposal: Replace paragraphs in 10.5 by a short paragraph and a reference to 8.3.10's gateway section.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 - Section 14.3 [Execution Semantics]: Examples for the use of gateways are missing

  • Key: BPMN21-56
  • Legacy Issue Number: 14786
  • Status: open  
  • Source: International Business Machines ( Mr. Hagen Voelzer)
  • Summary:

    The use of some gateways should be described by example, e.g. complex gateway, inclusive gateway, multiple instances

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exclusive gateway Choreography rules too restrictive, only sender needed

  • Key: BPMN21-23
  • Legacy Issue Number: 14686
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Decisions are prevented from being used Choreographies if not all
    participants have access to the information on which the decision is
    made. But if the activities following the gateway are all sent by the
    same participant, only that participant needs to know how the decision
    is made. Using an event-based gateway in this case is confusing, since
    there is no waiting for events to proceed to the activities following
    it. Some sided email below about this.

    Steve,

    > The Gateway would most likely be Event based. The Buyer is
    > probably not going to be aware of the data that would be
    > used to make the decision, particularly a change order.
    > Thus, the Buyer is just going to be waiting for one of the
    > three responses.

    Makes sense for the buyer, but this isn't a model of the buyer (and the
    Seller is making a regular decision, why isn't that shown?).

    It's also odd to see an event-based gateway in a choreography since
    choreography can't don't wait for events, the participants do. The
    figure looks right according to the spec, but I think the spec is too
    restrictive on regular decisions in choreogrpahies.

    Conrad

    Steve,

    > The Seller is making a regular decision internally, but the
    > rationale (i.e., data) used to make the decision is private
    > for the Seller. A Choreography can only use Exclusive
    > Gateways if the data used for them is public.

    I understand that's the rule, but I'm not sure it make sense. In this
    case, the activities following the gateway are all initiated by the
    Seller. The rule should be that the seller has access to the decision
    data.

    > The Buyer does not know ahead of time, what the
    > results of the decision will be since the Buyer has not seen the
    > Seller's internal data.

    And that's fine, because it isn't the Buyer who initiates any of the
    activities after the gateway.

    > All private Exclusive Gateways show up as Event Gateways in a
    > Choreography.

    This is too hard to explain, for example, who receives the event? The
    choreography itself can't received an event, and there's no indication
    that it's the Buyer (other than they Buyer is receiving in the
    activities after the gateway).

    For FTF discussion.

    Conrad

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Parallel Gateway participants

  • Key: BPMN21-19
  • Legacy Issue Number: 14669
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Section 12.6.4 (Parallel Gateway) says "They create parallel paths of
    the Choreography that all Participants are aware of." Not all
    participants, only those involved after the gateway.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Event-based gateways in choreography should be exclusive

  • Key: BPMN21-18
  • Legacy Issue Number: 14668
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    An event-based gateway implies a message is being waited for, but
    choreographies can't receive messages, they have no central controller.
    One of the participants will have an event-based gateway internally, but
    the other will have a exclusive gateway. The choreography can use an
    exclusive gateway with no conditions, with the semantics is that exactly
    one of the following messages will be sent.

    Comments:
    From: conrad.bock created: Mon, 13 Jul 2009 15:53:49 -0500 (CDT)
    Email from Frank about conditions on exclusive gateways in choreographies:

    Hello Conrad,

    In my opinion there is no need to even have data as decision criteria.
    There may be a button, that a user presses (request xy..). Of course you
    can discuss, that the fact, that a button has been pressed is in itself
    data in the system. But it is a different kind of.

    So in the case of two senders there are two users and two buttons.
    Whoever presses first sends first.
    Whoever sends second is in a different branch of the choreography.
    That's how I understand it.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Section 15.1.2 Sub-Process Mappings: Table referenced is missing

  • Key: BPMN21-22
  • Legacy Issue Number: 14683
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Page 453. The first sentance of the section states:
    "The following table displays the mapping of an embedded Sub-Process with Adhoc="False" to a WS-BPEL scope. (This extends the mappings that are defined for all Activities--see page 450):"

    However, the table is not there.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.5.5 Complex Gateway: The general description of Complex Gateways needs improving

  • Key: BPMN21-21
  • Legacy Issue Number: 14674
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The general description of Complex Gateways needs improving. An example or two would be good.

    Comments:
    From: wstephe created: Sun, 13 Sep 2009 23:49:07 -0500 (CDT)
    The version number was removed from the summary so that it will apply to the Beta 1 spec

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Interactions supporting interactions

  • Key: BPMN21-15
  • Legacy Issue Number: 14663
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    When a business commits to an interaction with potential business
    partners, it might be that a particular partner needs only some of the
    interaction. This would be specified in another interaction diagram.
    The modeler needs to link these two interactions to say one supports the
    other, with the same semantics of the currently supports association,
    except applied to messaging rather than activities. The supports
    association should be generalized to cover interactions

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

PartnerRole underspecified and misnamed

  • Key: BPMN21-14
  • Legacy Issue Number: 14661
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    PartnerRole does not specify the context of the role (is it a role in an
    organization?). The examples given (a buyer, seller, or manufacturer)
    could just be Participants, rather than PartnerRoles. The term "role"
    also conflicts with Participants, which are effectively roles in
    Interactions.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 11-4 description

  • Key: BPMN21-20
  • Legacy Issue Number: 14673
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The first sentence of the paragraph under Figure 11-4 (Conversational
    view choreographies) refers to Figure 11-3, but is about Figure 11-4, as
    far as I can tell. How is the parent-child relation referred to at the
    beginning of the paragraph reflected in the notation or metamodel? It
    says the Planned Order Variations as being keyed on Order Id, but the
    figure shows it keyed on Variation ID also (compare to description of
    Retailer Order and Delivery Variations Ack). The paragraph refers to
    Conversations instead of Communication.

    The second paragraph under Figure 11-4 refers to Detailed Shipment
    Schedule and Delivery Monitor, which aren't in Figure 11-3 or 4. The
    paragraph refers to Conversations instead of Communication.

    The third paragraph under Figure 11-4 refers to Delivery Planning and
    Special Cover, which aren't in Figure 11-3 or 4. It mentions messages
    spawning conversations, which isn't described anywhere else. The
    paragraph refers to Conversations instead of Communication.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Gateways in Choreography missing split or merge

  • Key: BPMN21-12
  • Legacy Issue Number: 14656
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The section on gateways in choreography covers splits (diverging)
    gateways but not merges (converging) for parallel, exclusive. Only
    merges are covered for complex gateways.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message flow to/from events in Collaboration diagrams

  • Key: BPMN21-11
  • Legacy Issue Number: 14653
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Send/receive events and tasks have the same meaning, but the
    Collaboration section only shows message flow to/from tasks and other
    activities. Clarify that message flow can be attached to send/receive
    events in Collaboration.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CorrelationClassDiagram missing conversation association end name

  • Key: BPMN21-13
  • Legacy Issue Number: 14657
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 8-18 (The Correlation Class Diagram) is missing the association
    end name listed in Table 8-32 (CorrelationKey model associations).

    Comments:
    From: wstephe created: Fri, 24 Jul 2009 12:40:19 -0500 (CDT)
    I was going to add an issue that would request to remove the conversation model association row from Table 8-32. The model association is uni-directional, so correlationKeys should appear in the Conversation table (11-1), but conversation should not appear in the CorrelationKey table (8-32).

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multiple senders after event-based gateway in choreography

  • Key: BPMN21-17
  • Legacy Issue Number: 14667
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    About event-based gateways in choreography, the spec says:

    [Event-based] Gateways are used in Choreography when the data used to
    make the decision is only visible to the internal Processes of one
    Participant.

    On the right side of the Gateway [CB: I assume this means immediately
    after]: either the senders MUST be the same; or the receivers MUST be
    the same.

    If the decision criteria is private to one participant, how can there
    multiple senders after the gateway?

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Rules for exclusive gateway in choreography too strict

  • Key: BPMN21-16
  • Legacy Issue Number: 14666
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Exclusive gateways in choreography are required to use decision data
    accessible to all participants involved in the gatway. But if if the
    senders after gateway are the same, then receivers can use event
    gateways or event subprocess to wait for event that might never come.
    It isn't necessary for the receivers to have access to the decision
    data.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

A New Hook for Organizational Models?

  • Key: BPMN21-65
  • Legacy Issue Number: 14831
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The hook in BPMN for Resource Models is through the Resource class. Generally, Organization Models are considered separate from Resource Models, but there is not a separate hook for Organization Models in BPMN, the Resource class would have to be used for Organization models, which could be confusing.
    The Resource class could be renamed to make it more generic, or a new class for Organization could be added.

  • Reported: BPMN 2.0b1 — Wed, 2 Dec 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notation for alternaitve data input/output sets

  • Key: BPMN21-32
  • Legacy Issue Number: 14738
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Notation for data input/output sets is missing. I/O sets have a similar
    execution effect as decision and merge gateways, so it seems like they
    should be visible.

    Comments:
    From: wstephe created: Fri, 13 Mar 2009 13:50:54 -0500 (CDT)
    The decision on this for BPMN 1.X was that there would be no notation for this since it would probably be too complicated. There was a non-normative suggestion that inputs that belong in the same inputSet could be connected to the same point on the activity, but we didn't want to have anything like pins. I haven't seen any other suggestions. If we had something to look at, then we could consider.
    But, in general, in probably should be deferred for now.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exclusive Gateway Choreography Rule too Restrictive, starting new process

  • Key: BPMN21-31
  • Legacy Issue Number: 14737
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Filed for Dale Moberg. The rule illustrated by Figure 12-36 is that the
    choreography activities after an exclusive gateway must have the same
    receivers if the initiators are different. However, the receivers can
    be different if the activity starts a new process in the receiving
    participant, or if the receiving participant has access to the data in
    the decision from earlier in the flow. Steve says the discussions so
    far did not account for activites that start processes in the
    participants.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Multiple processes per participant

  • Key: BPMN21-27
  • Legacy Issue Number: 14709
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    From side discussion with Frank: A single public interaction
    (choreography, collaboration, or conversation) might be supported by
    multiple internal processes, but the current metamodel only allows one
    process per participant. The multiplicity should be widened to *.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

optional source and target refs for data association

  • Key: BPMN21-26
  • Legacy Issue Number: 14704
  • Status: open  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    dataOutputAssociation/@sourceRef should be optional, not required.
    dataInputAssociation/@targetRef should be optional, not required.
    This is to support non-executable models (<a href="http://www.osoa.org/jira/browse/BPMN-381" title="Abstract BPMN Profile"><strike>BPMN-381</strike></a>), since these elements are part of the data interface of the parent node, which is unspecified in non-executable models. The other end of the association, the dataObject, is still required.

    Comments:
    From: ssamoojh@ca.ibm.com created: Thu, 14 May 2009 11:04:19 -0500 (CDT)
    Counterproposal - Rather than making the source or target optional, instead 'lighten' the spec text. The spec currently states that the source or target must be an ItemAwareElement. In the case of non-executable models, the source or target may be the FlowElement itself. So my proposal is to tweak the spec text, so as to allow this.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 10.2.2 Human Interactions: The Parameter class should be described

  • Key: BPMN21-36
  • Legacy Issue Number: 14751
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The Parameter class is an association of ProcessRole. Parameter has its own attributes. Thus, there should be a short subsection that describes Parameter, including a table that describes the attributes.
    A general question: Parameter is a very generic name. Should this class be named something more specific?

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 14.2.2 Activity (semantics):

  • Key: BPMN21-35
  • Legacy Issue Number: 14745
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Beta 1: Section 14.2.2 Activity (semantics): The state of a Data Object should be considered as a Performance Constrainst for an Activity Changing from the Ready to Active state

    ##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-411
    ##Original Info: (Severity: Critical - Nature: Enhancement)

    The state of a Data Object should be considered as a Performance Constrainst for an Activity Changing from the Ready to Active state.

    If a Data Object is not in the state defined as an input (e.g., "Approved"), then the InputSet should not yet be considered "available."

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Initializing and updating properties is not straight-forward

  • Key: BPMN21-30
  • Legacy Issue Number: 14730
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    From examples meeting on 2009.03.26:

    When creating the looping example for <a href="http://www.osoa.org/jira/browse/BPMN-281" title="V0.5.6: Section 10.3 Data [Data]: Assignments not defined"><strike>BPMN-281</strike></a>, it is not obvious how to initialize properties. Also, updating a property via a dataInputAssociation or dataOutputAssociation is unnecessarily complicated because sourceRef and targetRef are currently mandatory elements, but not really applicable for properties.

    Proposal:
    (1) Introduce a new entity "initializationAssignment" (or better name) as a contained element for property (and data object for symmetry reasons), which has the same structure as assignment, but with an optional "to" element.
    (2) Make dataInputAssociation::sourceRef and ::targetRef optional, likewise dataOutputAssociation::sourceRef and ::targetRef.

    Comments:
    From: trickovic created: Tue, 7 Apr 2009 04:00:15 -0500 (CDT)
    As per 4/6 BPMN 2.0 meeting: Defer <a href="http://www.osoa.org/jira/browse/BPMN-471" title="Initializing and updating properties is not straight-forward">BPMN-471</a>.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 17 BPMN Example: Include full BPMN example for this section

  • Key: BPMN21-25
  • Legacy Issue Number: 14702
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Section 17 will be temporarily removed until the BPMN example is added.

    The section should have a full example with diagrams, XML, and supporting text.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Roles for Entities

  • Key: BPMN21-24
  • Legacy Issue Number: 14698
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    There is no association between PartnerEntities and PartnerRoles, even
    though entities will play roles. The only link currently is through
    participant, requiring modification of a C models to link a role or
    entity, see <a href="http://www.osoa.org/jira/browse/BPMN-520">http://www.osoa.org/jira/browse/BPMN-520</a>. An association
    between partner entities and roles would enable collections of C models
    to be grouped by roles, with roles reused by entities.

  • Reported: BPMN 2.0b1 — Thu, 19 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add an example of Mutlple Start Events on the Boundary of a Sub-Process

  • Key: BPMN21-29
  • Legacy Issue Number: 14729
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Add an example of Mutlple Start Events on the Boundary of a Sub-Process as shown in an example for Issue 145 and described in the execution semantics section.
    Section 10.2.5, Beta 1 spec

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Section 15.1.2 Mapping to BPEL Activities: Message Mapping snippet refers to StructureDefinition

  • Key: BPMN21-28
  • Legacy Issue Number: 14711
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The figure for the mapping of Message to BPEL shows a snippet that includes a StructureDefinition element. The actual attribute for Message is structureRef, which points to ItemDefinition.
    This figure should be updated.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 10.1.2: Use of BPMN Common Elements [Process] -- Return removed TBD sections and complete text

  • Key: BPMN21-37
  • Legacy Issue Number: 14755
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Some sections with TBDs were removed for the Nov OMG posting. These sections should be returned and filled with content.
    This section should match a parallel section in Chapter 11 (Choreography).

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 10.2.4 Performer: Relate Performer to Human Performer

  • Key: BPMN21-34
  • Legacy Issue Number: 14744
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Mainly Editorial:

    A HumanPerformer is a type of Performer, but there is no reference to this in the Performer section. There should be more description of how Performer can be used (e.g., through HumanPerformer).

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 9.1 Collaboration: Expand description of Collaboration in section

  • Key: BPMN21-33
  • Legacy Issue Number: 14741
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    The background text for the description of Collaboration is rather thin. Add more description and a figure or two.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Link Events - Constraints and Usage not clearly documented

  • Key: BPMN21-63
  • Legacy Issue Number: 14815
  • Status: open  
  • Source: International Business Machines ( Ms. Suzette Samoojh)
  • Summary:

    The Sequence Flow constraints around the usage of Link Events are not clearly expressed in the spec.

    Very simply, it should express that:

    • A Catch Link Event should have no incoming Sequence Flow.
    • A Throw Link Event should have no outgoing Sequence Flow.

    Instead the spec has several rather confusing statements (pgs 235-236) that make it hard to infer the simple behavior I described above.
    Statements like:

    • If the Intermediate Event is used within normal flow:
    • Intermediate Events MUST be the target of a Sequence Flow.
    • An Intermediate Event MUST be a source for Sequence Flow.
    • An exception to this: a source Link Intermediate Event (as defined below), it is not required to have an outgoing Sequence Flow.
    • A Link Intermediate Event MUST NOT be both a target and a source of a Sequence Flow.
    • A Link Intermediate Event MAY be the target (target Link) or a source (source Link) of a Sequence Flow, but MUST NOT be both a target and a source.

    Recommendation:

    • Tighten up and simplify the constraint descriptions for Link Events.
    • Refrain from introducing new terms "source" and "target", or if the new terms are needed, clearly relate them to the existing "catch" and "throw" terms.
  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 10.2 Clearer separation between conceptual and visual model needed

  • Key: BPMN21-62
  • Legacy Issue Number: 14802
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: This section mixes conceptual meta-model statements with visual representation statements. A clearer separation of those concepts is needed.
    – p 127 (157 in PDF) "... inclusion of re-usable tasks and processes in the diagram" should be "... invocation of re-usable tasks and other processes from the process"
    – p 127 (157 in PDF) "... a process is not a graphical object. Instead, it is a set of graphical objects." A process is neither, it is a container for activities and other entities, all of which have a graphical representation.
    – p. 133 (163 in PDF) ff "A task is a rounded corner rectangle" should be "A task is represented by a rounded corner rectangle". This occurs frequently for all task types, so globally change "is a rounded corner rectangle" to "is represented by a rounded corner rectangle"

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 9 Collaboration [Choreography; Specification, Metamodel]:

  • Key: BPMN21-52
  • Legacy Issue Number: 14774
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Section 9 Collaboration [Choreography; Specification, Metamodel]: Clarify that a pool represents a single BPMN process, not a "participant" meaning role or business entity

    ##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-299
    ##Original Info: (Severity: Significant - Nature: Enhancement)

    This is number 2 of 12 issues submitted by Bruce Silver

    Clarify that a pool represents a single BPMN process, not a "participant" meaning role or business entity. At least do this for a white box pool (aka private process); a black box pool (abstract process) is empty of activities, so its process is unknown and often labeled as role or business entity. Also remove the language that multiple pools in a BPD are about B2B. This is rarely the case. Multiple white box pools in a BPD are used when the processes involved have independent lifetimes and cardinality, and almost always when both pools represent the same business entity not B2B.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Spec: New Annex?: Enumerate the validation rules of BPMN

  • Key: BPMN21-51
  • Legacy Issue Number: 14773
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    This is number 3 of 12 issues submitted by Bruce Silver

    Enumerate the validation rules of BPMN. Back in the old days when the BPDM guys kept saying BPMN 1.0 had no explicit rules or metamodel, you said it did but it was buried in the narrative. Now you have an explicit metamodel but the rules are still buried in the narrative, and inconsistent from one part to the next. Judging from v1.x it will take years to clean up the narrative, so just enumerate the rules in one place and say this overrides contrary info elsewhere in the narrative.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Spec: Section 10.3 Data [Data]:

  • Key: BPMN21-50
  • Legacy Issue Number: 14771
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Beta 1 Spec: Section 10.3 Data [Data]: If start of an activity is guarded by availability of input data, there should be some visible indication of this in the diagram

    ##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-302
    ##Original Info: (Severity: Significant - Nature: Enhancement)

    This is number 5 of 12 issues submitted by Bruce Silver

    If start of an activity is guarded by availability of input data, there should be some visible indication of this in the diagram. ("Modeling" means you don't need to see the non-diagram attributes). It seems like BPMN 2.0 is trying to make data more a first class citizen, so this is needed.

    Comments:
    From: bruce created: Fri, 5 Dec 2008 17:29:56 -0600 (CST)
    In a user task, it is understood that time can elapse between task ready and active, whereas in service task there is no delay. So the temporal semantics are clear from the diagram. The issue is when service task is guarded by data "availability" - whatever that implies. If service task could incur delay between ready and active because of input data, this should be visible somehow in the diagram.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Spec: Section 14 BPEL Mapping: Better clarify the subset of BPMN diagrams that are BPEL-mappable (roundtrippable!

  • Key: BPMN21-49
  • Legacy Issue Number: 14770
  • Status: open  
  • Source: Bruce Silver Associates ( Mr. Bruce Silver)
  • Summary:

    Better clarify the subset of BPMN diagrams that are BPEL-mappable (roundtrippable!)

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide example: Basic process structure

  • Key: BPMN21-48
  • Legacy Issue Number: 14769
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: Missing example for process structure

    Proposal: Add an example showing process structure.

    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.

    Comments:
    From: mkloppmann created: Thu, 19 Feb 2009 12:30:43 -0600 (CST)
    Per the 2009.02.19 examples sub-team meeting:
    – Medium priority
    – The example should contain activities, events, gateways
    – Combine with <a href="http://www.osoa.org/jira/browse/BPMN-316" title="Provide example: Basic gateway examples">BPMN-316</a>

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide example: Inline Subprocess

  • Key: BPMN21-47
  • Legacy Issue Number: 14767
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: Missing example for Inline Subprocess

    Proposal: Add an example showing Inline Subprocess

    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.

    Comments:
    From: mkloppmann created: Thu, 19 Feb 2009 12:33:25 -0600 (CST)
    Per the 2009.02.19 examples sub-team meeting:
    – This item is related to <a href="http://www.osoa.org/jira/browse/BPMN-365" title="Notation for data flow in/out of a process">BPMN-365</a>

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide example: Basic gateway examples

  • Key: BPMN21-46
  • Legacy Issue Number: 14766
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: Missing examples for basic gateways.

    Proposal: Add three examples showing XOR, IOR and AND gateways.

    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.

    Comments:
    From: mkloppmann created: Thu, 19 Feb 2009 12:31:13 -0600 (CST)
    Per the 2009.02.19 examples sub-team meeting:
    – Medium priority
    – Combine with <a href="http://www.osoa.org/jira/browse/BPMN-310" title="Provide example: Basic process structure">BPMN-310</a>

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide example: Multi-instance activity

  • Key: BPMN21-45
  • Legacy Issue Number: 14765
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: Missing example for multi-instance activity.

    Proposal: Add an example showing a multi-instance activities, including data assignments from a set of values to the individual parallel instances, and from the results of the parallel instances to a result set. This will require collaboration with the Data team.

    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide example: Choreography

  • Key: BPMN21-42
  • Legacy Issue Number: 14762
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: Missing choreography example

    Proposal: Add an example showing a choreography with several choreography activities, based on the existing example.

    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 14.4 [BPEL mapping] Missing intermediate send event; mapping of participant ref

  • Key: BPMN21-41
  • Legacy Issue Number: 14761
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Type: Technical

    Description of issue:
    1. The spec misses the mapping for intermediate message send events
    2. The spec misses a mapping for send/receive events and tasks where the other party is specified not by a service-ref, but by a message flow to another participant.

    Proposal:
    1. Include that mapping into spec (see Visio)
    2. Introduce text describing how BPEL partnerLink is derived from either serviceRef or participantRef; use [serviceRef | participantRef] or similar notation as abbreviation.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1 Section 8.3.17 Sequence Flow and 14.2.1 Sequence Flow Considerations

  • Key: BPMN21-40
  • Legacy Issue Number: 14759
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Beta 1 Section 8.3.17 Sequence Flow and 14.2.1 Sequence Flow Considerations (Execution Semantics): Add Exclusive conditional behavior from activities

    ##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-349
    ##Original Info: (Severity: Significant - Nature: Enhancement)

    Suggested by Michael Rowley: Add Exclusive conditional behavior from activities.

    "Perhaps there should be a new variant of the minidiamond symbol to show that they are exclusive (filled in black, perhaps?). For human activities, it would then be clear that the different flows are different choices that can be made by the user. In B4P they would also be the "outcome" of the task."

    This was discussed on a BLOG (<a href="http://kswenson.wordpress.com/2008/01/01/human-process-trouble-ticket/#comment-8886">http://kswenson.wordpress.com/2008/01/01/human-process-trouble-ticket/#comment-8886</a>)

    Proposal TBD

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide example: Complex gateway

  • Key: BPMN21-44
  • Legacy Issue Number: 14764
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Description of issue: Missing example for complex gateway.

    Proposal: Add an example showing a complex gateway.

    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Provide example: Conversation View

  • Key: BPMN21-43
  • Legacy Issue Number: 14763
  • Status: open  
  • Source: International Business Machines ( Mr. Matthias Kloppmann)
  • Summary:

    Type: Example

    Description of issue: Missing example for Conversation View.

    Proposal: Add an example showing a conversation view.

    Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should

    also be provided using BPMN notation.

    Comments:
    From: wstephe created: Mon, 1 Dec 2008 21:45:34 -0600 (CST)
    An example has been started. It needs to be finished (including XML).

    Also, we should use this issue to track the full text requirements for Section 9.5 "Conversations" (V0.9.1)

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

[Chroeography] Complete section 11.4: Events

  • Key: BPMN21-39
  • Legacy Issue Number: 14757
  • Status: open  
  • Source: Oracle ( Martin Chapman)
  • Summary:

    Complete 11.4.1, 11.4.2, and 11.4.3 on choreogrpahy events.
    Each sub-section may require more text, review and some example and pictures.

    Comments:
    From: trickovic created: Fri, 12 Dec 2008 06:37:38 -0600 (CST)
    Issue assigned to Steve/the choreography team.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 11.2: Use of BPMN Common Elements [Choreography] -- Return removed TBD sections and complete text

  • Key: BPMN21-38
  • Legacy Issue Number: 14756
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Some sections with TBDs were removed for the Nov OMG posting. These sections should be returned and filled with content.
    This section should match a parallel section in Chapter 10 (Process).

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 251, Start Event on the boundary of a sub-process

  • Key: BPMN21-6
  • Legacy Issue Number: 14333
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    Is it still allowed to have Start and End Event on the boundary of an
    expended Sub-process?

    This was clearly stated and shown in BPMN 1.2. It is mentionned
    at page 251, but no example are provided.

    Is figure 7-8 page 69 valid?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 070, section 8 list of Core elements

  • Key: BPMN21-5
  • Legacy Issue Number: 14327
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 29, 2009

    The figure 8-1 indicates "Infrastructure, Common Elements, and Services".
    Three Core sub-packages are listed in page 71 "Foundation, Service, and
    Common".
    Figure 8-2 shows "Foundation, Common, and Service".
    Section 8.1 describes "Infrastructure", Section 8.2
    describes "Foundation", Section 8.3 describes "Common Elements" and
    Section 8.4 describes "Services".
    The list of BPMN core elements indicated in thre first bullet of section
    2.1.1
    is: "Infrastructure, Foundation, Common, and Service packages."

    Is there 3 or 4 sub-packages and should we use the same naming convention
    within this section of the document?

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Concept definition for Business Process

  • Key: BPMN21-2
  • Legacy Issue Number: 14242
  • Status: open  
  • Source: PNA University ( Jean-Paul Koster)
  • Summary:

    Since you still have the concept definition for "Business Process" listed as "TBD" in the Glossary, PNA would like to propose the following definition:

    Business Process:

    A Business Process is a cooperation between several people and/or systems each performing a particular role and possible other entities such as departments within a company or organization, in order to produce a product or to deliver a service to a customer. Within BPMN a Business Process is described using a BPD.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Allow a Process to be Ad Hoc (in addition to a Sub-Process)

  • Key: BPMN21-1
  • Legacy Issue Number: 14223
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Currently only Sub-Processes can be Ad Hoc. However, it would be useful for Processes to be Ad Hoc also. This would allow libraries of Ad Hoc Processes to be defined and re-used

  • Reported: BPMN 2.0b1 — Wed, 26 Aug 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 203, Table 10-26, The text describing the none and all behavior have been inverted

  • Key: BPMN21-9
  • Legacy Issue Number: 14538
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Page 203, Table 10-26, The text describing the none and all behavior of the behavior attribute have been inverted.

  • Reported: BPMN 2.0b1 — Thu, 8 Oct 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add a User Event

  • Key: BPMN21-8
  • Legacy Issue Number: 14422
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    There are many situations where a human involved in a process triggers an Event. The current set of Event types do not adequate reflect this situation. Thus, a new type of Event, a User Event, should be added to BPMN.

  • Reported: BPMN 2.0b1 — Mon, 14 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

This is a style suggestion to make diagrams clearer

  • Key: BPMN21-7
  • Legacy Issue Number: 14354
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    This is a style suggestion to make diagrams clearer. The XOR gateway allows two forms of diagram: empty diamond, and a diamond with an X in it. While redundancy is OK in general, the fact that different vendors make different choices. But an X and a cross look very similar. While the X should be allowed, the spec should indicate that it is preferred to use the blank option, with the eye to eventually eliminating the X.

  • Reported: BPMN 2.0b1 — Fri, 4 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Depiction of diagram fragments

  • Key: BPMN21-4
  • Legacy Issue Number: 14303
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 08, 2009

    The spec should prescribe how diagram fragments are presented. (e.g.
    three dots at end of continuing flows, ...)

    Given that BPMN has very specific structural requirements, most diagram
    fragments in the spec (and elsewhere) are not valid BPMN models.

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 046, Section 7.2, Message not listed as a BPMN element

  • Key: BPMN21-3
  • Legacy Issue Number: 14293
  • Status: open  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Reported by dga...@trisotech.com, Jul 06, 2009

    The Message element is not listed in any of the categories

    Comment 1 by dga...@trisotech.com, Jul 10, 2009

    The Message element is not listed in any of the BPMN element categories

  • Reported: BPMN 2.0b1 — Wed, 2 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Example of Lane, Laneset, and Partitions

  • Key: BPMN21-10
  • Legacy Issue Number: 14614
  • Status: open  
  • Source: BPM Advantage Consulting ( Dr. Stephen White)
  • Summary:

    Chapter 10.7 needs a more detailed example of how lanes can use process information/elements to partition flow objects

  • Reported: BPMN 2.0b1 — Fri, 6 Nov 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT