Business Process Model And Notation Avatar
  1. OMG Specification

Business Process Model And Notation — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
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
BPMN11-94 Why in paragraph 7.1.1 Uses of BPMN, definition of Collaboration (Global) BPMN 1.1 open
BPMN11-93 Page 19 (PDF page 43) Table 8.2, definitionof "Pool". BPMN 1.1 open
BPMN11-92 Message flows in and out of independent sub-processes BPMN 1.0b1 open
BPMN11-91 BPMN Issue: Exclusive Gateway Merging BPMN 1.0b1 open
BPMN11-90 Update definition of merging behavior of Exclusive Data-Based Gateway BPMN 1.0b1 open
BPMN12-9 Figure 10.39 states that Arbitrary Cycle is known as Workflow Pattern #16. This is not correct BPMN 1.2 open
BPMN12-8 Figures 10.18 and 10.19 are presented as though they are logical equivalents in the description above 10.19. BPMN 1.2 open
BPMN12-12 external references in BPMN and DMN BPMN 1.2 open
BPMN12-11 The Description for LoopCondition does not seem to be correct BPMN 1.2 open
BPMN12-7 No MetaModel for BPMN BPMN 1.2 open
BPMN12-5 Section: 9.4.2 Sub-Process BPMN 1.2 open
BPMN12-10 Section: 9.4.2.3 BPMN 1.2 open
BPMN12-1 Timer Events BPMN 1.1 open
BPMN12-4 Fwd: BPMN Formal 1.1 - Reference Task issue - Section 9.4.3.8 BPMN 1.2 open
BPMN12-3 'Default' Gate' BPMN 1.2 open
BPMN12-2 Copyright BPMN 1.1 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

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

Why in paragraph 7.1.1 Uses of BPMN, definition of Collaboration (Global)

  • Key: BPMN11-94
  • Legacy Issue Number: 12243
  • Status: open  
  • Source: Banco de Chile ( Mario E. Cavieres)
  • Summary:

    I am beginner in BPM but in order to understand the BPMN standard, I send these questions: 1) Why in paragraph 7.1.1 Uses of BPMN, the definition of Collaboration (Global) Process (page 14) says: The collaboration process can be shown as two or more abstract process communicating with each other (see figure 7.3).... But the Figure 7.3 looks like as "two or more private (internal) business processes communicating with each other", comparing the Figure 7.1 and Figure 7.2 For more emphasis what I saying In the Figure 7.3 both process (patient and Receptionist/Doctor), all activities for both process are shown, this is not agree with definition of Abstract (public) process (page 13), that says: ....All other "internal" activities of the private business process are not shown in the abstract process.... 2) if the difference between Private (internal) business processes and Collaboration (Global) processes is the number of business entities, this mean that : Private (internal) business processes for only one business entity or specific organization. Collaboration (Global) processes for two or more business entities. What about Abstract (Public) processes, how many entities are or can be involved? 3) The Abstract (public) Processes are "abstract" because the activities of the another process or participant are not shown ?, using words of the definition of the Abstract (public) Processes.

  • Reported: BPMN 1.1 — Wed, 20 Feb 2008 05:00 GMT
  • Updated: Wed, 11 Mar 2015 01:55 GMT

Page 19 (PDF page 43) Table 8.2, definitionof "Pool".

  • Key: BPMN11-93
  • Legacy Issue Number: 11151
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Page 19 (PDF page 43) Table 8.2, definitionof "Pool". Should lanes within pools be referred to as "Lanes" or "Swimlane"? Both terms are used. It would be good to be consistent.

  • Reported: BPMN 1.1 — Wed, 11 Jul 2007 04:00 GMT
  • Updated: Wed, 11 Mar 2015 01:55 GMT

Message flows in and out of independent sub-processes

  • Key: BPMN11-92
  • Legacy Issue Number: 10139
  • Status: open  
  • Source: me.com ( Frank McCabe)
  • Summary:

    Where an activity represents an invocation of an independent
    subprocess, the spec does not state how to bin any incoming and
    outgoing message flows to the sub-process. It does state how to bind
    information (input and output sets) but not messages.

  • Reported: BPMN 1.0b1 — Thu, 24 Aug 2006 04:00 GMT
  • Updated: Wed, 11 Mar 2015 01:55 GMT

BPMN Issue: Exclusive Gateway Merging

  • Key: BPMN11-91
  • Legacy Issue Number: 9615
  • Status: open  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    The BPMN 1.0 version of the Exclusive Gateway merging (either data or event Gateways) acts as a "pass through" for any Tokens that arrive. This means that there is no "exclusiveness" to the merging as the name of the Gateway would imply. A "discriminator" merging that allows the first Token through and stops any further (parallel) Tokens is a business pattern that cannot be currently modeled. This functionality should either replace the current merging behavior or be added to the behavior.

  • Reported: BPMN 1.0b1 — Fri, 28 Apr 2006 04:00 GMT
  • Updated: Wed, 11 Mar 2015 01:55 GMT

Update definition of merging behavior of Exclusive Data-Based Gateway

  • Key: BPMN11-90
  • Legacy Issue Number: 9410
  • Status: open  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    Update the definition of the merging behavior of the Exclusive Data-Based Gateway. Currently, the Gateway just passes all Tokens through. The behavior should be changed to be exclusive in that it will allow the first Token to arrive through the Gateway, but ignore/consume all other Tokens from the same Token family.

  • Reported: BPMN 1.0b1 — Thu, 2 Mar 2006 05:00 GMT
  • Updated: Wed, 11 Mar 2015 01:55 GMT

Figure 10.39 states that Arbitrary Cycle is known as Workflow Pattern #16. This is not correct

  • Key: BPMN12-9
  • Legacy Issue Number: 13923
  • Status: open  
  • Source: SunGard ( Roy Massie)
  • Summary:

    Figure 10.39 states that Arbitrary Cycle is known as Workflow Pattern #16. This is not correct. Arbitrary cycle is Workflow Control Pattern # 10 in Van Der Aalst's documents. Recommend the 16 in the Figure description be changed to a 10.

  • Reported: BPMN 1.2 — Thu, 7 May 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figures 10.18 and 10.19 are presented as though they are logical equivalents in the description above 10.19.

  • Key: BPMN12-8
  • Legacy Issue Number: 13922
  • Status: open  
  • Source: SunGard ( Roy Massie)
  • Summary:

    Figures 10.18 and 10.19 are presented as though they are logical equivalents in the description above 10.19. However, In Figure 10.19 it is possible both Condition 1 and 2 could be true causing all three transitions to be traversed. This is not possible in 10.18 because of the exclusive gate. To make the two diagrams behave the same, the default slash should be added to the Condition 1 transition coming from the Inclusive gate on diagram 10.19. This will insure either Condition 1 XOR Condition 2 is traversed, but not both inclusively as is possible in the current spec. If the diagrams are not to be taken as logical equivalents, the text just under Figure 10.18 should be changed to make this clearer and the Activity names should be made different so equivalence is not implied.

  • Reported: BPMN 1.2 — Thu, 7 May 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

external references in BPMN and DMN

  • Key: BPMN12-12
  • Legacy Issue Number: 19716
  • Status: open  
  • Source: Bruce Silver Associates ( Bruce Silver)
  • Summary:

    I don?t know if this has come up in the BPMN RTF already? apologies if old news. TThe DMN beta followed BPMN?s external reference scheme of a prefixed ID value, but in the FTF version they changed to it to something like href=?[DMN filepath]#[ID]?. They say that the BPMN way is ?flawed? because it could lead to accidental ID collisions.?? I don?t understand why referencing a physical storage location in lieu of a proper namespace is less ???flawed? but my question is whether BPMN is moving to do it the DMN way.?? Seeing as DMN has specific pointers to BPMN elements, and I would expect some future BPMN to have specific pointers to DMN elements, I don???t see how the two standards could have totally different methods of external reference.

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

The Description for LoopCondition does not seem to be correct

  • Key: BPMN12-11
  • Legacy Issue Number: 14054
  • Status: open  
  • Source: Thales Australia ( Benjamin Yau)
  • Summary:

    The Description for LoopCondition does not seem to be correct in "..., plus the timing when the expression SHALL be evaluated". The timing seems to be determined by the TestTime attribtue. If that is true, the "...plus ..."phrase should be taken out.

  • Reported: BPMN 1.2 — Thu, 2 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No MetaModel for BPMN

  • Key: BPMN12-7
  • Legacy Issue Number: 13866
  • Status: open  
  • Source: University of Luxembourg ( Alfredo Capozucca)
  • Summary:

    For the moment there is not MetaModel for BPMN. For MetaModel I mean a class diagram that shows the elements of the language and their relationships. In the paper Birgit Korherr, Beate List: Extending the EPC and the BPMN with Business Process Goals and Performance Measures. ICEIS (3) 2007: 287-294 authors give one proposal. It is very important to provide an OFFICIAL MM for BPMN, since it will bring clarity to the language.

  • Reported: BPMN 1.2 — Wed, 15 Apr 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 9.4.2 Sub-Process

  • Key: BPMN12-5
  • Legacy Issue Number: 13446
  • Status: open  
  • Source: ( Gabor Faludi)
  • Summary:

    Hello, after reading throuh the named chapter about Sub-processes, I could not find a clear statement on the allowed number of "None Start Events" and "None End Events". Out of the spec one might have the feeling that a Sub-process always have a dedicated entry point from the "outside", which entry point is represented by a "None Start Event", and the sam epplies to End events/exit points. I could not find a statement regarding this, nor any overall principle out of which it could be concluded. It would maybe make sense to enrich the specification with this information.

  • Reported: BPMN 1.2 — Thu, 5 Feb 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section: 9.4.2.3

  • Key: BPMN12-10
  • Legacy Issue Number: 13990
  • Status: open  
  • Source: Dresden University of Technology ( Frank Toeppel)
  • Summary:

    the issue I'm reporting is a typo only: Chapter 9.4.2.3 contains information regarding reusable sub processes. The initial sentence introducing this chapter is as follows: <sentence> A Reusable Sub-Process object is an activity within a Process that “calls” to another Process that exists within a BDP (see Figure 9.10). </sentence> >From my point of view the listed abbreviation BDP is misspelled, I would expect BDP for Business Process Diagram. It's really a minor issue, but anyway I would like to point to

  • Reported: BPMN 1.2 — Mon, 15 Jun 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Timer Events

  • Key: BPMN12-1
  • Legacy Issue Number: 12201
  • Status: open  
  • Source: TIBCO ( Justin Brunt)
  • Summary:

    With regard to Timer Events, Expression in B.11.8 doesn’t provide a solution to the example given in the specification such as in Table 9.8 for Timer Events which use TimeDateExpression B.11.18 which in turn use Expression.

    BPEL has three constructs For, Until and RepeatEvery. RepeatEvery can optionally be applied to the other two. The XSD excerpt is as follows:
    <xsd:element name="for" type="tDuration-expr" />
    <xsd:element name="until" type="tDeadline-expr" />
    <xsd:element name="repeatEvery" type="tDuration-expr" />

    Both the types of expressions extend tExpression which is defined as this:
    <xsd:complexType name="tExpression" mixed="true">
    <xsd:sequence>
    <xsd:any processContents="lax"
    minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
    <xsd:attribute name="expressionLanguage"
    type="xsd-derived:anyURI" />
    <xsd:attribute name="opaque"
    type="xsd-derived:tOpaqueBoolean" />
    <xsd:anyAttribute namespace="##other" processContents="lax" />
    </xsd:complexType>
    And are further qualified in section 8.3 as:
    .Deadline expressions should return valid values of xsd:date and xsd:dateTime
    .Duration expressions should return valid values of xsd:duration

    We feel the BPMN spec is imprecise in this area in defining both in Table A.9 by their mapping to BPEL (TimeDate = until, TimeCycle = for). RepeatEvery makes no appearance in the BPMN spec.

    Therefore, we think the best solution would be for BPMN to add RepeatEvery. Is it possible that the BPMN spec may have believed TimeCycle actually fulfils the BPEL repeatEvery, the name would seem to bear that out? However it explicitly says that TimeCycle should be interpreted as BPEL 'for'. Therefore a second, larger, change to BPMN would be to re-map TimeCycle to repeatEvery and add instead WaitFor or some such mechanism.

  • Reported: BPMN 1.1 — Mon, 28 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Fwd: BPMN Formal 1.1 - Reference Task issue - Section 9.4.3.8

  • Key: BPMN12-4
  • Legacy Issue Number: 12941
  • Status: open  
  • Source: Object Management Group ( Jon Siegel)
  • Summary:

    In BPMN Formal/08-01-17, Section 9.4.3.8, Reference Task, the first paragraph refers to Activity, while the second paragraph and the associated Table 9.31 refer to Task. For clarity and correctness, the first paragraph should also refer to Task.

    To fix: Change the word "activity" to "Task" in the first sentence. Change the word "activities" to "Tasks" in the second sentence.

  • Reported: BPMN 1.2 — Wed, 8 Oct 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

'Default' Gate'

  • Key: BPMN12-3
  • Legacy Issue Number: 12372
  • Status: open  
  • Source: Axway Software ( Sylvain Astier)
  • Summary:

    In the specs, it is stated that a gate can be designated as the 'Default' Gate' for Excusive Data-based gateway and Inclusive Gateway. It is stated in the specs for Gates that
    "For DefaultGates: The Sequence Flow MUST have its Condition attribute set to Otherwise"
    However, The Condition Type attribute for a Sequnce Flow can only be
    Expression
    None
    Default

    Should the specs state that "For DefaultGates: The Sequence Flow MUST have its Condition attribute set to Default"
    Please confirm.

  • Reported: BPMN 1.2 — Mon, 7 Apr 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Copyright

  • Key: BPMN12-2
  • Legacy Issue Number: 12265
  • Status: open  
  • Source: International Business Machines ( Dave Ings)
  • Summary:

    In the preface in the "Licenses" section it states "The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free,paid up, worldwide license to copy and distribute this document". However other than the OMG itself no companies are listed above or in fact below in the preface. Surely this is bug - failing to list the copyrights of the companies that submitted the intellectual property. Note section 6.3 has a list of contributors. This is the URL I downloaded the PDF from: http://www.omg.org/spec/BPMN/1.1/ and the file was http://www.omg.org/docs/formal/08-01-17.pdf all linked from http://www.omg.org/technology/documents/br_pm_spec_catalog.htm

  • Reported: BPMN 1.1 — Fri, 7 Mar 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 29, Section 7.2.2 - Fork and Join Differentiation

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

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

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

Typo: Data Object spelled Objec

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

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

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

word catalogue in the Figure 5.3: Order Fulfillment

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

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

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

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

Missing event marker in Figure 10.30

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

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

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

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

figure 13.1

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

    I may be wrong but I assume figure 13.1 is wrong

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

Bug p385

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

    ??

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

    ??

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

Section 10.3.4 Human Performer is not peorperly defined for implementation interpretation

  • Key: BPMN21-366
  • Legacy Issue Number: 19461
  • Status: open  
  • Source: Trisotech ( 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 ( 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: agnos.ai UK Ltd ( 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 ( 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 ( 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 ( 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 ( Jon Siegel)
  • Summary:

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

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

    the first sentence reads, correctly –

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

    In the next section, under the heading

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

    the first sentence reads, incorrectly –

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

    Clearly the authors meant to start this sentence with

    Non-interrupting Event Handlers are ...

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

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

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 ( 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 ( Jon Siegel)
  • Summary:

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

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

    comes the cryptic phrase

    (REF for SIP)

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

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

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

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 ( 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 ( 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 ( Jon Siegel)
  • Summary:

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

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

Can Event Sub-Processes Loop?

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

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

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

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