Business Process Model And Notation Avatar
  1. OMG Specification

Business Process Model And Notation — Closed Issues

  • Acronym: BPMN
  • Issues Count: 442
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
BPMN12-34 Section: 9.4, 9.4.1, 9.4.2 BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-33 Clarify association of artifacts to flows BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-32 BPMN does not have a symbol for a physical storage facility BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-31 BPMN does not explicitly identify a model element for "approval." BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-30 Page: Page 1 (PDF page 25) BPMN 1.1 BPMN 1.2 Resolved closed
BPMN2-301 Text User Task instead of Manual Task BPMN 2.0 BPMN 2.0.1 Resolved closed
BPMN2-300 Page 345. “Sub-Choreographies” instead of “Choreography Activities” BPMN 2.0 BPMN 2.0.1 Resolved closed
BPMN2-299 None Events not for catch Intermediate Event BPMN 2.0 BPMN 2.0.1 Resolved closed
BPMN2-298 Conditional Event instead of Error Event BPMN 2.0 BPMN 2.0.1 Resolved closed
BPMN2-297 Page 181. Wrong reference to table 10.20 BPMN 2.0 BPMN 2.0.1 Resolved closed
BPMN2-296 Conflicting content regarding choreographies. BPMN 2.0b1 BPMN 2.0 Closed; No Change closed
BPMN2-295 Page 203, Table 10-26, MultiInstance Activity: What is the intended use case if the catching boudnary event is interrupt BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN11-33 The list of supporting objects in B.11 is incomplete BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-32 Gate is a common feature of Gateways BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-22 Message/Property/Assignment relations are too complex BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-21 Message Flow ordering along Pool (abst process) is modeled only graphically BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-35 p. 282, Table 137 BPMN 1.0 BPMN 1.1 Resolved closed
BPMN11-34 The concept of "Trigger" in ambiguous in the BPMN specification BPMN 1.0 BPMN 1.1 Resolved closed
BPMN11-29 BPEL faults BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-28 BPMN spec doesn't include join condition BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-31 Specify persistent format BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-30 enhance BPMN to provide 'resource modeling'. BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-27 partner links are not modeled in BPMN explicitly. BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-26 correlation set BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-24 BPEL/WSDL specific properties BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-23 Reference Task does not define any way to pass parameters and values BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-25 BPEL->BPMN mapping problem BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-53 Events in subprocesses BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-52 BPMN: Interrupt Intermediate Event BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-58 Implicit State Machine for Activities BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-57 Multiple None Start Events inside of a sub-process BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-51 BPMN: Complex triggers BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-50 Multiple Triggers with 'and' semantics BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-49 BPMN: Attribute definitions BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-56 Inclusive Event-Based Decision BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-55 Extending activities with execution time (traversal time) attributes? BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-63 Where are tokens queued? BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-62 Clarify whether pools require their activites to be centrally coordinated BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-61 Do artifact flows affect execution BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-60 Defining "Main" Pool in diagram BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-59 Is it valid to have a pool nested within a Lane, BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-54 Provide ExpressionLanguage attribute for the element Expression BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-80 UML class diagram in the appendix BPMN 1.0 BPMN 1.1 Resolved closed
BPMN11-79 examples in section 10.2.1 Normal Flow (02) BPMN 1.0 BPMN 1.1 Resolved closed
BPMN11-87 Section: 9.3.4 Intermediate [Events] BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-86 BPMN Task Attribute "TaskType" Value-related Message Flow Restrictions BPMN 1.0 BPMN 1.1 Resolved closed
BPMN11-85 Add Project Management dependencies for activities (FF, FS, SF, SS) BPMN 1.0 BPMN 1.1 Resolved closed
BPMN11-81 Use of link events to synchronize behaviour BPMN 1.0 BPMN 1.1 Duplicate or Merged closed
BPMN11-83 question raised by Issue 9321 nor addresses by issue 9319 BPMN 1.0 BPMN 1.1 Resolved closed
BPMN11-82 Move Sequence Flow Conditions to Gates BPMN 1.0 BPMN 1.1 Resolved closed
BPMN11-78 examples in section 10.2.1 Normal Flow (01) BPMN 1.0 BPMN 1.1 Resolved closed
BPMN11-89 confusion regarding diagram 10.25 BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-88 Section: 10:2.1 Normal Flow BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-84 Should Exception Events be allowed to have no Outgoing Sequence Flow? BPMN 1.0 BPMN 1.1 Resolved closed
BPMN11-15 fundamental semantic model of token flows BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-14 differentiate a business message from a business signal BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-13 shared collaboration BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-12 Need consistent terminology for Categories, Core Elements BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-20 Some references are not explicit BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-19 Containment structure is unclear for non-graphical elements BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-11 Which is it, Core Elements, or Flow Objects?. BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-18 BPEL mapping definition is imprecise BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-17 how to model a process where more than one participant (pool) plays a part BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-16 Is BPMN just a notation? BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-74 Clarify the scope and usage of Compensation Events BPMN 1.0 BPMN 1.1 Resolved closed
BPMN11-73 Change the activity Marker for Multiple Instance activities BPMN 1.0 BPMN 1.1 Resolved closed
BPMN11-72 Culturally significant icons BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-71 no way to graphically differentiate an Embedded Subprocess BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-65 BPMN spec not clear on separation of data/display regarding pools and lanes BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-64 Page: 23 BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-77 References to Annex D and there is no Annex D in this specification BPMN 1.0 BPMN 1.1 Resolved closed
BPMN11-76 The direction arrow for association seems backwards BPMN 1.0 BPMN 1.1 Resolved closed
BPMN11-70 Section: 10.1.3 BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-75 Specify return type of ComplexMI_FlowCondition BPMN 1.0 BPMN 1.1 Resolved closed
BPMN11-69 Add a UML Profile to the BPMN specification BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-68 The Reference Task and Reference Subprocess should be removed BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-67 Section: 8.1, Table 8.1 BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-66 Section: 7.1.1/Note BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-38 Definition of "Rule" BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-37 Link does not have clear semantics BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-36 BPMN TaskType Attribute BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-46 MessageFlows to a subprocess boundary BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-45 DataObject attributes BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-42 Intermediate Events with outgoing Message Flow BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-41 Tasks with multiple outgoing message flows BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-44 "Quantity" attribute BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-43 "StartQuantity" attribute BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-40 Independent Subprocess BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-39 IORules attribute BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-47 Optional Start/End Events BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-48 "Exception" trigger BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN2-273 For DI: All graphical elements should have a Semantic Counterpart BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-272 Review the use of RFC2119 keywords BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-277 Rename "Call" Elements BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-276 XML Schema is not strict enough BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-282 Missing loopCharacteristics for Choreography stuff in MM BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-281 Figure 12-21, Sub-process marker missing BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-280 Mismatch in DataAssociation definition between spec and XSD BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-279 Receive Task is not mentioned as an instantiating element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-278 Merge Collaboration and Choreography in Metamodel BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-284 Missing in XML example BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-283 Missing label of a compensation activity BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-286 Missing marker in Compensation Activity BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-285 Process Model and Model Description are not consistent BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-274 Allow referencing scripts instead of enfocing inline specification BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-275 How to reference particular instances of Data Objects that are Collections BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-271 Choreography should be a Sub-Class of Collaboration BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-270 Additional participants in called/subconversation BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-261 Hexagons and message flow linked to activities BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-260 For Process within Collaboration, section 9.3 title is wrong and section 10.11 is empty BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-264 Data Objects should be defined with the same pattern a Data Stores and DataStoreRefs BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-263 Correlation on message flow and choreography activities BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-262 Label call conversation links BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-257 LaneSet should have an optional ‘name’ attribute BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-256 Simplify Use of Callable Elements BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-266 No way to identify the format of Documentation and TextAnnotation connect BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-265 Extending via inheritancy is problematic using the BPMN xsd format BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-259 How to represent Process Diagrams and Lanes? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-258 Figure 10.121 mis-described BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-254 CorrelationKey should be a concrete element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-253 Required definitions to invoke an existing function by means of a service task BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-268 Add Attribute Table for Global Task BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-267 Incorrect attribute name used for Start Event definition BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-269 Contradictory/redundant handing of data and subprocesses BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-255 DataInputs, DataOuputs, and DataStores should be FlowElements BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-291 Missing definition of the participant Buyer BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-290 Exporter Information Required for BPMN 2 files BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-289 Inclusive Gateway Semantics BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-288 Missing Message Flow BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-287 Choreography is not enforcable BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-294 The Two Multi-Instance Markers should be reversed BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-293 A Collaboration should be able to reference more than one Choreography BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-292 Conversation lanes BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-246 BPMN CMOF File problems BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-245 Mutiple depictions of a single semantic element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-244 Depictable element without a reference semantic element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-249 The example provided in Figure 10-22 and its serilization in Table 10-19 are incorrect or at least misleading BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-248 Add an attribute that can identify a rulebase/rule engine for Business Rule Task BPMN 2.0b1 BPMN 2.0 Closed; No Change closed
BPMN2-247 Confusing semantics for Terminate End Event BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-237 Ambiguity when multiple message flows associated with a choreography task BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-251 ResourceParameter::type attribute should be of type ItemDefinition, not Element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-250 Parallel Event Based Gateway capability is hidden away BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-239 Inconsistent/confusing statements around CallActivities and IOSpecifications BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-243 Table 10-4 page 162 List of possible states of an Activity instance BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-242 Clarify "Instance of this Conversation." BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-241 Change plural "flow" to "flows" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-240 Correlation key property values from process instances BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-252 Clarification of Temporal Sematics of Sequence Flow BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-238 Exclusive Gateway (missing sub-heading) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN-30 Reference Subprocess BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-29 Time intervals modeling is imprecise BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-35 SubProcessRef BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-5 Section 6 of the current specification should be moved as an appendix BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-4 BPMN comment BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-3 Sec. 6.16 BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-6 Mapping to BPEL should be moved to the appendix BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-1 Business Process Diagrams BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-2 BPMN comment: additional artifacts BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-24 restriction to be placed on the number of tokens BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-23 optional description attribute BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-22 BPMN Adopted Spec issue - Clarify behavior of Error intermediate event BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-21 Section: 4.6 BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-20 Is it really the Complete Set? BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-19 Are there 3 or are there 4 Standard Artifacts? BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-27 Section 12 of the specification should be moved as is to an appendix BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-26 Diagram with an "Invisible Pool" BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-28 Section 4.3.3 Reference to "missing" shape BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-25 Clarify why BPMN separates data and sequence BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-13 Ambiguous notations for Association BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-12 No means to define Categories BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-7 Unclear whether BPEL is part of Conformance BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN11-7 Attributes not explained with respect to Notation BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN-18 Which is it, (OR-Join) or (XOR) Gateway? BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-17 unclear what Figure 13 on p. 71 represents BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-16 complicated notation BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN11-10 Semantical difference between activity models and BPMN BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-6 Missing examples BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-9 Unclear what complete syntax is for an Attribute BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN11-8 Sequence Flow is not a Flow Object BPMN 1.0b1 BPMN 1.1 Resolved closed
BPMN-15 Ambiguous notations for OR BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-14 Unclear semantics of Group BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-11 BPEL mapping hard to follow BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-10 BPEL over-pervasive in document BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-9 compliance level to cover core elements/simple business modeling BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-8 Irrelevant conformance point BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-31 Definition of "Expression" BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-33 Role association to subprocesses BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-32 Performers BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN-34 Start Events with triggers on a subprocess BPMN 1.0b1 BPMN 1.0 Resolved closed
BPMN2-143 Need to revisit and test the process example in the spec (Figure 7-8) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-142 Service Package => Interface Package BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-147 Lanes and Sequence Flow BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-146 Grouping message flow in Collaboration BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-137 CorrelationSubscription Ownership BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-138 Semantic metamodel => Abstract syntax BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-144 Error class has no 'name' attribute BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-140 Conversation/Communication switch BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-141 Choreography Subprocess => Subchoreography BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-145 Typo in Terminate Event description BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-139 MessageFlowRefs missing from Conversation metamodel diagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-117 Beta 1 Section 11 Conversation: BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-116 Private process example correction BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-112 Multiple properties / keys clarification BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-115 isImmediate default BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-114 Subprocess / CallActivity switch BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-123 Processes supporting interactions BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-122 Private process type BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-118 Complex gateway merging rule in choreography too restrictive BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-121 Conversation/Process switch BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-113 Key-based Correlation => ? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-120 Correlation Class Diagram missing Process association BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-119 Promote correlationKeys association to ConversationContainer BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-220 Cardinality of the "sourceRef" association between DataAssociation and ItemAwareElement BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-219 Unclear/contradictory handling of visualized Data Inputs/Outputs BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-218 Data Inputs/Outputs on Subprocesses BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-213 Can a sub-process (embedded) have Lanes? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-212 Section 10.2.3 ScriptTask.scriptLanguage needs to specify format BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-215 Section 12.4.1 [Choreo] How many message flows per choreography task? Missing meta-model BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-214 Section 8.3.15 [Choreo] ParticipantMultiplicity must allow to specify 1..2, possibly also 0..1 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-211 Section 10.5.1/10.5.6 Need to clarify how initiating gateway is specifed: via sequence flow, attribute, or both BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-217 Formalizing the Source-Target relationships between Link Intermediate Event BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-216 Allow Choreographies within a Conversation Diagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-210 General [Metamodel] Double-check attributes that are enumerated types, and their extensibility needs BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-209 Section 9.2: Pool description needs revisiting BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-221 Data Inputs the target of multiple Data Associations BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-208 Default execution semantics for an activity with multiple incoming branches needs to be clarified BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-133 Are Conditional Start Events executable? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-132 Contradiction in constraint for Start Events in Event Subprocess BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-129 Error vs ErrorCode & Escalation vs EscalationCode BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-125 Choreography Complex Gateway example BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-124 Exclusive gateways in choreography cover splitting but not merging BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-128 Fix difference between MessageFlowNode definition in specification vs the semantic.xmi file BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-127 Meaning of + symbol on Communication undefined BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-131 Mention of "isInterrupting" attribute still in the spec BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-130 Incorrect description for the Transaction.protocol attribute BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-135 Section 11 Conversation: Fix Conversation figures for proper notation for Pools BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-136 Merge Conversation and Collaboration BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-134 Correlation Key & Correlation Properties are missing 'name' attributes BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-126 isClosed on Conversation BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-230 Property name mismatch between Spec and Schema for Item Definition BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-229 "isInterrupting" attribute of Start Events BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-224 Event marker quality is poor BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-223 Persistent versus transient event trigger BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-232 Reference ProcessRef missing in Figure 8.40 - The Participant Class Diagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-231 The Message element structureRef association should be renamed to itemRef BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-234 Execution semantics for Data Objects and Properties must be enhanced to properly describe concurrent modification situat BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-233 Does CallChoreography need a MessageFlowAssociation? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-226 Called conversations without keys of the caller BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-228 Allow Overlapping Matrix Construction of Lanes in a Diagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-227 Order of outgoing sequence flows from exclusive gateway BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-222 The description of operationRef is not accurate BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-235 Visibility and permissions for Data Objects and Properties must be described BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-225 Confusion about Performers and other roles that Resources play for Activities BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-203 Generalize message flow BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-202 Semantics for data flow without sequence flow BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-201 Enabling multiple events at the same time for the same message BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-197 Annex D Glossary [Specification]: Update Glossary BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-200 Section 10.3.1 [Data-MM]: Events can contain properties but the relationship is not shown in the MM diagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-199 Business Rule Task description doesn't describe purpose (section 10.2.3, Beta 1) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-198 Tasks vs Global Tasks BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-196 Section 8.1.5 [Infra] Import statement description is not clear enough BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-195 Section 2 Conformance [Specification]: Explicitly define BPMN compliance criteria, with focus on "model" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-205 Section 10.2.8 [Execution Semantics] Loops: Loop names misleading BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-204 Reuse of processes in orchestration and choreography BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-192 Pools multiplicity BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-191 [Meta-model] Exclusive gateway is missing specification of order of leaving sequence flows BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-190 Diagram Interchange should align with Diagram Type Definition BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-207 Section 10.2.5: Sub-Process: Figure 10.25; Add a minus sign to the bottom of an expanded Sub-Process? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-206 Section 8.2.1 [Service Model] How to model a request-reply use case? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-194 Data flow in/out of events BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-193 Beta 1: Section 10.3.1 Data Objects [Data]: Change Multiplicity of datastate attribute from 0..1 to 0..* BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-187 Beta 1: Is a Message a DataInput for an Activity; Is Message Flow a Data Association BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-186 Beta 1 [Section 12.1.2] - Use of the term "BPMN" in class names BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-185 Beta 1 [Section 12.1.2] - OrchestrationDiagram should be called ProcessDiagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-184 Relationship navigation (both in MM and XSD) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-183 Beta 1: Section 10.2 Activities: Reference Task and Sub-Process from BPMN 1.1 not in BPMN 2.0 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-176 Global Task should have performer, Call Activity should have capability to overwrite performer BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-182 Aliases for imported definitions BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-181 Beta 1: Section 10.2 Activities: Move User Task Instance Attributes to the higher level Activity element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-189 [Section 10.2.3] Editorial BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-188 [Section 10.6] Editorial: We need more explicit descriptions of Compensation behaviour regarding scopes BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-180 Add business-level presentation attributes to user task: subject and description BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-179 Data Association should be specialized from Association BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-175 Editorial: Rename FlowElement::categoryValue to ::categoryValueRef BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-174 Data Assignment 'from' and 'to' should be formal expressions BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-177 [XSD] Documentation and ScriptTask (and probably expressions) should be stored as CData elements and not String attribut BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-178 Lanes should be described in Process section BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-169 Beta 1: Section 10.4.5 Handling Events: When does the interrupting Event Sub-Process cancel its Parent? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-168 TimerEventDefinition: clarification of the expected result of the timeCycle and timeDate expressions BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-167 Correlation properties must have name and type (was dropped in 4/22 XSD and MM) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-166 tActivityResource::resourceRef should be optional BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-165 Section 10.3.1 Data Inputs and Outputs: Schema change: change minOccurs of inputSet for ioSpecification from 0 to 1 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-172 Beta 1: Set the name attribute of DataInputs and DataOutputs to optional BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-171 V0.9.9.1: Display of Messages and Associations in Choreography BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-164 XSD DataAssociation should own source and target refs and mistake in text spec BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-163 DataAssociations: How do we support literals? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-162 Metaelement missing for DI to show connection between ChoreographyActivity to Message BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-170 Beta 1: Section 10.4 Events: Statement "Signals are triggers generated in the Pool they are published" needs clarificati BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-173 XSD: Data Association sourceRef and targetRef should be of type QName BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-161 Beta 1 Section 13.2.4 ChoreographyActivityShape: Add Choreography Activity Bands to DI model BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-98 logic error in the PDF document BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-97 Target namespace mismatch between the XML Schemas in the spec (PDF) and the XML Schemas files (XSD) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-95 Clarification on relationship between MEP and Choreography Task in BPMN2 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-94 Initiating message flow for ChoreographyTask BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-92 Page 160, Figure 10-6 vs. Table 10-3. The "property" class is not depicted in the class diagram Figure 10-6 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-91 Page 161, Table 10-3, Error in attribute name. "resources" should be "activityResource" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-93 Page 161, Table 10-3, Issues regarding properties in the Activity attribute table BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-96 Allow Choreography Task to have more than 2 Participants BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-236 INCORRECT/IMCOMPLETE REFERENCES AND DEFINITIONS IN GLOSSARY BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-153 parallelMultiple attribute missing from CatchEvent table BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-152 CorrelationSubscription - Description & use-cases BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-154 The Category section has incorrect/inconsistent content BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-157 V0.9.7: Section 10 Process: Add ProcessResource Attribute to Process BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-156 Notation for supports association BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-151 XML-Schema type for 'from' and 'to' elements in Data Assignment must not be abstract BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-150 XSD: mixed="true" is redundant in tFormalExpression element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-149 Multiple PartnerEntities per Participant BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-160 Beta 1 Section 12.4 Choreography Activities: Fix redundancy in the definition of these elements BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-159 Beta 1 Section 2.2 Process Execution Conformance: Describe this conformance apart from Process Modeling Conformance BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-158 Use "item" terminology more uniformly BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-148 Service Task => Operation Task BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-155 Editorial: Incorrect containment statement for EventDefinitions BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-110 Misleading copy/paste para regarding Properties BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-102 URL referenced for WfMC Gloassary is incorrect BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-101 Definition of Participant Band Shadings not clear BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-108 Missing DataStore from the enumeration of item-awre elements at top of the page BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-107 Merge Conversation and Collaboration BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-111 Section 10.2.3 BPMN 1.2 BPMN 2.0 Resolved closed
BPMN2-100 Variable Id TO Variation Id BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-99 The schema for globalTasks of type Send ,Receive and Service are not there BPMN 1.1 BPMN 2.0 Resolved closed
BPMN2-106 Conversation Muddle BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-105 Correlation on Choregraphy BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-104 Typo in Section 7.2 paragraph 1 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-109 Missing details regarding the visualisation of a DataState for a DataObject BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-103 URL referenced for XPDL specification is incorrect BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-3 The case of some attribute name is not consistent. BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-2 Typos BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-1 Conformance Classes are overley Broad BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-6 Page 052, Table 7-2, Wrong figure of all event possibilities BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-5 Page 227 Table 10-56 the attributes optionalOutput and whileExecutingOuput are wrongly typed DataInput BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-4 Page 199 class model for the global tasks BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-8 Page 029, Section 2.1.3 Usage of normal bullets vs diamond shape to indicate structural specifications BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-7 Page 199, Figure 10-40 Types of Global Task (Text,Class Diagram and Schema do not match) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-9 Page 044, Figure 7-3, Pool names not separated from content by a single line BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-21 Page 044, Figure 7-4, The initiating party is wrongly identified in the figure BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-20 Page 395, Figure 12-51, Intermediate Event instead of End Event in Choreography diagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-19 Page 115, Section 8.3.13 Copy/paste BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-25 Page 351, Figure 12-7 Caption of the Figure Name BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-24 Page 348, Section 12.3.1, end of sentence confusing BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-23 Page 346, Section 12.1 Reference of Figure 12-4 instead of Figure 12-3? BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-22 Page 345, Section 12.1 Typo, the word "Events" should be "Activities" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-14 Page 372, Table 12-7 Blank sections BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-13 Page 338, section 11.7 Section name versus content BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-17 Page 064, Section 7.5.1, wrong reference to Table 8.4 (should be Table 7-3) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-16 Page 042, Section 7.1.1 Reference to Figure 10-5 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-12 Page 259, Table 10-82, Missing "Catch" label above depiction of Parallel Multiple Event BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-11 Page 130, section 8.3.17 Copy/Paste error BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-15 Page 028, Section 1, Missing Conversation diagram in list of diagrams defined in BPMN BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-18 Page 065, Section 7.5.2, Wrong reference to Table 8.5 (Should be Table 7-4) BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-10 Page 119, section 8.3.14 Copy/Paste error wrong term "Pool" vs "Message Flow" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-84 text attribute is missing from the Documentation element of the v 0.9.14 schema BPMN 1.1 BPMN 2.0 Resolved closed
BPMN2-83 BPMN 2 FTF issue on XSDs for DD / DI model transfer BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-88 Method of specifying a default SequenceFlow is awkward BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-87 Lane.partitionElementRef incorrectly defined BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-82 Page 24, Table 7.2 Gateway control types row - Redundant forms for XOR Gateway BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-81 Page 121, Figures 7.3 and 10-1 ­ Redundant ways to model receiving messages BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-90 Page 204, Table 10-26, MultiInstance Activity: Potential error and clarification regarding **BehaviorEventRef BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-89 businessRuleTask element in the BPMN 2.0 schema file is missing the implementation attribute BPMN 1.1 BPMN 2.0 Resolved closed
BPMN2-86 Semantic.xsd v0.9.14, sect. 8.2.1, p76-77 BPMN 1.1 BPMN 2.0 Resolved closed
BPMN2-85 Sematic.xsd vs. v0.9.14, sect. 8.3.7, pp106-107 BPMN 1.1 BPMN 2.0 Resolved closed
BPMN2-80 Page 26, Normal Flow row of Table 7.2 - Modeling Activities that are only ended by Events BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-79 Page 26, Normal Flow row of Table 7.2 - Modeling activities that do not complete before process completion BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-78 Page 22, Section 7.2.1 ­ Associating Data Objects with process as a whole BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-67 Page 331, Figure 11-4, Message Flows part of a Conversation diagram BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-77 Page 29, Section 7.2.2 ­ Fork and Join Differentiation BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-76 Page 121, Figure 10-1 - Redundant ways to model receiving messages BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-73 Page 22, Section 7.2.1 - Associating Data Objects with process as a whole BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-72 Page 190, sub-section "Transaction" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-74 Page 26, Normal Flow row of Table 7.2 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-69 Page 361, Figure 12-23, Sub-process marker missing BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-68 Page 337, section 11.5 Typo should be "Call Conversation" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-75 Page 26, Normal Flow row of Table 7.2 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-70 Page 032, section 2.4.1, Referencing wrong chapter BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-71 Page 076, Figure 8-5, Figure Caption incorrect BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-57 Page 244, section 10.4.2 Last two structural specifications for Start Event BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-56 Page 187, Do sub-process markers also apply for Call Activity and Event Subprocess BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-61 Page 253, section 10.4.3 End Event Sequence Flow Connections BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-60 Page 192, Table 10-21 Transaction types need explanation BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-65 Page 265, Sequence Flow Connections for Intermediate Events BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-64 Page 265, Activity Boundary Connections BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-62 Page 255, Message Flow connection for End Event BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-59 Page 251, Exceptions for Sequence Flow connections for Start Event BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-55 Page 159, Section 10.1.2 number of types of diagrams BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-58 Page 247 section Start Event for Event Sub-Processes BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-66 Page 328, Section 11, Communication Link or Conversation Link BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-63 Page 257, Intermediate Event Types in Normal flow BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-47 Page 223, Figure 10-57 Unclear usage of IsCollection attribute for DataOutput BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-46 Page 149, Figure 9-6 Multi-instance marker no depiction for white box pools BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-45 Page 149, Figure 9-6 Vertical pool markers placement depiction BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-50 Page 028, Section 1, Wrong term for BPMN : Business Process Modeling Notation BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-49 Page 115-120 Distinguishing Initiating and Non-Inititating Messages BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-54 Page 153, Figure10-1, Link Events not paired may lead to confusion BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-53 Page 056, Table 7-2, Compensation Association: Usage of term Compensate Event BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-43 Page 063, Section 7.4 Undefined term "Flow" BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-42 Page 050, 061 and 417 Group text implies that only activites can be within a Group BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-52 Page 054, Table 7-2, Gateway Control Types: Incomplete statement BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-51 Page 049, Table 7-1 Depiction of Lanes with single lines to separate Lane name to Lane content BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-41 Page 060, Table 7-2, Merging: No depiction of implicit merge BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-40 Page 058, Table 7-2, Fork: Questionable affirmation BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-44 Page 187, Figure 10-27 Inconsistent use of class hierarchy vs. attributes to define types of subprocess BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-48 Page 253 and 257, Table 10-81 and 10-82 EventDefintion used for Events BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-28 Page 357, Figure 12-17 and 12-18 Participant names not identical BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-27 Page 353, Figure 12-11, inapropriate caption BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-26 Page 352, Figure 12-9, inapropriate caption BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-34 Page 408, Section 13.2.5 Event Sub-process not included BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-33 Page 242-243 Tables 10-75 and 10-76 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-32 Page 243, Table 10-76 eventDefinitionRefs and eventDefinitions descriptions BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-31 Page 242, Table 10-75 eventDefintionsRefs and eventDefinitions descriptions are identical BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-30 Page 175, Table 10-11, Spelling of Business in Attribute Name BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-29 Page 370, Table 12-6, references to Event Sub-Process BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-37 Page 243 Table 10-76 the definition of EventDefinitionRefs and eventDefinitions is duplicated in ThrowEvent and CatchEve BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-36 Page 165, Table 10-7 Required attribute cardinality explicitly defined BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-39 Page 047, Section 7.2 Properties is presented as a Data element BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-38 The attribute name is duplicated across many, many, many classes BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-35 Page 331, Typo Figure references 11-3 but should be 11-4 BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN12-29 Figure 10.2 - A Conditional Sequence Flow BPMN 1.0b1 BPMN 1.2 Resolved closed
BPMN12-22 precisions about the Signal Event BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-21 Common Gateway Features BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-28 Figure 9.23 - An Inclusive Decision using Conditional Sequence Flow BPMN 1.0b1 BPMN 1.2 Resolved closed
BPMN12-27 Figure A.35 BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-25 Figure A.33 is missing an artefact BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-24 Figure A.31 is an invalid BPMN 1.1 model BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-19 Sequence Flow Connection BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-18 Glossary issue BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-20 Glossary (Adobe p321): under Trigger BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-26 Figure A.34 is missing an artefact BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-23 Figure A.30 is an invalid BPMN 1.1 model BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-16 Table A.10 editorial BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-15 Table A.10 BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-14 Table 9.13 BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-17 Glossary BPMN 1.1 BPMN 1.2 Resolved closed
BPMN12-13 Table 9.2 BPMN 1.1 BPMN 1.2 Resolved closed

Issues Descriptions

Section: 9.4, 9.4.1, 9.4.2

  • Key: BPMN12-34
  • Legacy Issue Number: 11634
  • Status: closed  
  • Source: TIBCO ( Justin Brunt)
  • Summary:

    We have been puzzling over the meaning of the MultiIinstance Paralllel Marker and believe that there’s a conflict in the description. We saw this in the 1.0 specification and then checked to see if the 1.1 specification had changed in any way but found it to be the same. We believe there needs to be clarification around the MultipleInstance loop MI_Ordering attribute with regards to the task marker symbol that should be used. Here’s the basic description (we’re giving table/figure references from v 1.1 draft of BPMN spec).… BPMN spec says that Standard loop will look like Figure 9.15 Image 1 And Multi Instance loop will look like Figure 9.15 Image 2 However in Table 9.20 Multi-Instance Loop Activity Attributes in the MI_Ordering attribute description it clearly states that… If set to Parallel, the Parallel marker SHALL replace the Loop Marker at the bottom center of the activity shape (see Figure 9.9 and Table 9.18). This suggests that a Multi-Instance Loop task that is set to sequential would actually have the Standard Loop Marker. The question is, which statement is correct, the first… “Standard Loop activities will have a marker that is a circle with an arrow and Multi-Instance Loop activities will have a marker that is two parallel vertical lines” Or the second… “A Parallel Multi-Instance activity will have a marker that is two parallel vertical bars. Standard loops and sequential multi-instance activities will have a marker that is a circle with an arrow on it”. These statements made in the BPMN spec seem to be contradictory. Now, to us, whether the task instances are performed in parallel or sequential is the most significant thing to display visually on the diagram. And therefore we actually think that the second statement should be true. However, whether the condition is evaluated once or on each loop iteration could also be significant enough to be visible in the diagram. We actually think that there are 3 significant pieces of information that BPMN is trying to convey with only 2 markers and associated attributes. § Separate Task instances are run in parallel. § Separate Task instances are run sequentially, and if so… o The loop exit condition is a Boolean expression and is re-evaluated on each loop iteration. o The condition is a Numeric expression that is evaluated only once before loop begins and specifies a maximum value for LoopCounter. We think that there are 2 possibilities to overcome this problem and clarify the meaning… 1) Add a new value to the Standard Loop TestTime attribute – OnceBefore – this states that the expression is numeric and specifies the number of loop iterations. Then remove the MI_Ordering attribute i.e. all Multi-Instance loops are parallel. It may be useful to introduce a new marker symbol to distinguish between OneBefore and Before/After (if it is deemed significant enough to been seen at diagram level). 2) Leave all the attributers as they are but introduce a new marker symbol for “The condition is a Numeric expression that is evaluated only once before loop begins and specifies a maximum value for LoopCounter” (i.e. a Multi-Instance Loop with MI_Ordering set to sequential. In either case, if all three pieces of information are deemed significant enough to been seen at diagram level, here are our suggestions… Multi-Instance + Parallel - use parallel bar symbol Standard Loop Before/After (Evaluated On every iteration) … You could, also distinguish between before and after by say, turning the symbol upside down for evaluate-before… Because the circle as a break in it then it suggests (maybe?) that the process engine stops to re-evaluate things each time round the loop. Multi-Instance + Sequential (or new Standard Loop + OnceBefore… Use circle with no break Because the circle has no break in it then it suggests (maybe?) that the process engine already knows how many times to go around.

  • Reported: BPMN 1.1 — Wed, 31 Oct 2007 04:00 GMT
  • Disposition: Resolved — BPMN 1.2
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Clarify association of artifacts to flows

  • Key: BPMN12-33
  • Legacy Issue Number: 11601
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    In clause 9.7.2 and 10.1.4, it is stated that a data object artifact can be associated with a (Sequence or Message) Flow.
    But the meaning of association with a Sequence Flow is not
    clearly stated.

    In Figure 9.40 there is an example of an association of a data object to a Sequence Flow between two Activities. Is such an association only permitted when the Flow is between two Activities? Is it permitted when the flow is between an Activity and a Gateway?

    For example, could Figure 9.40 have two activities on the right, with an exclusive data gateway (decision) routing the data object to one or the other under certain conditions?

    Is there a meaning to associating the data object with a Sequence Flow that terminates in an Event (throw or catch)?

    Proposed Resolution:

    When the flow originates from an Activity, the data object is an output of that Activity that is available at the time of the flow. When the flow terminates in an Activity, the data object is an input to that Activity that is available at the time the Activity starts. (This is the conclusion to be drawn from the current text. But these statements are independent of what is on the other end.)

    If the flow originates from a gateway or event, BPMN assigns no meaning to the association with respect to that end, but a conforming tool may.

    If the flow terminates in a gateway or event, the data object is an "input" artifact that is available when the Gateway decision is made, the Event is thrown, or the wait for the Event begins. The artifact, or the knowledge of its availability, may be used in making the Gateway decision or throwing or handling the Event.

    The preferred representation of a data object "flowing" past a gateway or event is to show two (or more) associations:
    output from the originating activity and input to the activity (or activities) that use the artifact. (And there should be an example of this.)

  • Reported: BPMN 1.1 — Tue, 9 Oct 2007 04:00 GMT
  • Disposition: Resolved — BPMN 1.2
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

  • Updated: Wed, 11 Mar 2015 01:53 GMT

BPMN does not have a symbol for a physical storage facility

  • Key: BPMN12-32
  • Legacy Issue Number: 11278
  • Status: closed  
  • Source: Agile Enterprise Design ( Fred Cummins)
  • Summary:

    BPMN does not have a symbol for a physical storage facility. This is important to highlight for management process diagrams since such facilities that may be a source of signifant costs and delays. (This comment is intended for consideration in BPMN 2.0)

  • Reported: BPMN 1.1 — Mon, 13 Aug 2007 04:00 GMT
  • Disposition: Resolved — BPMN 1.2
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

  • Updated: Wed, 11 Mar 2015 01:53 GMT

BPMN does not explicitly identify a model element for "approval."

  • Key: BPMN12-31
  • Legacy Issue Number: 11277
  • Status: closed  
  • Source: Agile Enterprise Design ( Fred Cummins)
  • Summary:

    BPMN does not explicitly identify a model element for "approval." This is important to highlight for control issues and regulatory compliance concerns. An approval symbol is apparently common in management consultant diagrams. A equlateral triangle with one edge at the base has been used for this. (this issue intended for BPMN 2.0).

  • Reported: BPMN 1.1 — Mon, 13 Aug 2007 04:00 GMT
  • Disposition: Resolved — BPMN 1.2
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Page: Page 1 (PDF page 25)

  • Key: BPMN12-30
  • Legacy Issue Number: 11150
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Page 1 (PDF page 25) Section 1 includes the text: "Note – This version does provide a non-normative mapping from BPMN to WSBPEL, but the BPMN specification itself is known to be incomplete with respect to capturing all the required information for WSBPEL. So the mapping is insufficient, in any case." This says one can't make a mapping from WSBPEL to BPMN. It doesn't prevent a mapping from BPMN to WSBPEL.

  • Reported: BPMN 1.1 — Wed, 11 Jul 2007 04:00 GMT
  • Disposition: Resolved — BPMN 1.2
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Text User Task instead of Manual Task

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

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

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

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

    No Data Available

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

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

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

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

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

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

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

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

None Events not for catch Intermediate Event

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

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

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

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

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

    resolved

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

Conditional Event instead of Error Event

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

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

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

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

    resolved

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

Page 181. Wrong reference to table 10.20

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

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

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

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

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

    resolved

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

Conflicting content regarding choreographies.

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

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

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

    withdrawn by submitter

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

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

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

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

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

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

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

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

The list of supporting objects in B.11 is incomplete

  • Key: BPMN11-33
  • Legacy Issue Number: 9717
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: dtc/06-02-01
    Date: February 2006
    Version: Final Adopted Specification
    Chapter: B.11
    Pages: 101
    Nature: Editorial
    Severity: minor

    Description:

    The list of supporting object types in B.11 does not include the following:
    Gate, which is actually documented under Gateway
    Input set, which is documented under Process
    Output set, which is documented under Process
    Trigger, which is documented under Event.

    Each of these supporting objects, together with its proper attributes (extracted from wherever it is documented), should be included in B.11.

    Recommendation:

    Add 4 subsections to B.11:

    Before B.11.4 (Message), add:

    B.11.a Gate, with the following attributes:

    "Outgoing SequenceFlow: SequenceFlow
    Each Gate SHALL have one associated Sequence Flow. The constraints on the SequenceFlow depend on the kind of Gateway.

    "Assignments (0..n): Assignment
    One or more assignment expressions MAY be made for each Gate. The
    Assignment SHALL be performed when the Gate is selected. The details of
    Assignment is defined in the Section B.11.1, "Assignment," on page 268."

    B.11.b Input(Set), with the following attributes:

    "Inputs (1-n) : Artifact
    One or More Inputs SHALL be defined for each InputSet. An Input is an Artifact, usually a Document Object."

    Before B.11.6 (Participant), add:

    B.11.c Output(Set), with the following attributes:

    "Outputs (1-n) : Artifact
    One or more Outputs MUST be defined for each OutputSet. An Output is an
    Artifact, usually a Document Object."

    Before B.11.11 (Webservice), add:

    B.11.d Trigger, with the following attributes:

    Trigger (None | Message | Timer | Rule | Link | Multiple) None : String
    Trigger defines the type of trigger, and determines what other attributes are permitted or required. The Trigger list MAY be extended to include new types.

    [Message Trigger only]
    Message : Message
    If the Trigger is a Message, then the Message SHALL be specified. (See B.11.4).

    [Message Trigger only]
    Implementation (Web Service | Other | Unspecified) Web Service : String
    This attribute specifies the technology that will be used to receive the message. A Web service is the default technology.

    [Timer Trigger only]
    TimeDate (0-1) : Date
    If the Trigger is a Timer, then a Date MAY be specified. The TimeDate specifies the point in time at which the Timer Event will occur. If a TimeDate is not specified, then a TimeCycle SHALL be specified (see the attribute below).

    [Timer Trigger only]
    TimeCycle (0-1) : String
    If the Trigger is a Timer, then a TimeCycle MAY be specified. The TimeCycle specifies the elapsed time between TimerEvents. If a TimeCycle is not
    specified, then a TimeDate MUST be specified (see the attribute above).

    [Rule Trigger only]
    RuleName : Rule
    If the Trigger is a Rule, then the triggering Rule SHALL be specified. (See B.11.9) The Rule specifies the observable state of affairs that triggers the RuleEvent.

    [Link Trigger only]
    LinkId : String
    If the Trigger is a Link, then the LinkId SHALL be specified. The LinkId specifies the name of the Link (signal) that triggers the LinkEvent when it is presented by the Process designated by the ProcessRef attribute (see below).

    [Link Trigger only]
    ProcessRef : Process
    If the Trigger is a Link, then the ProcessRef SHALL be specified. ProcessRef specifies the Process that is the source of the Link (signal) for which the Trigger is waiting. The identified Process MAY be the same Process as that of the Link Event.

  • Reported: BPMN 1.0b1 — Fri, 12 May 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Gate is a common feature of Gateways

  • Key: BPMN11-32
  • Legacy Issue Number: 9716
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Doc: ptc/06-02-01
    Date: February 2006
    Version: Final Adopted Specification
    Chapter: 9.5
    Pages:
    Nature: Editorial
    Severity: minor

    Description:

    In 9.5.1 Common Elements of Gateways, the object type Gate is not documented. But Gate appears, with the same two attributes (Outgoing flow, Assignments) in every subtype of Gateway in 9.5, and once for each role of Gate in that kind of Gateway. Moreover, the initial text for its attributes in each occurrence is the same. Some of the specific roles of Gate have special requirements as well, and this must be puzzled out from the current tables for the Gateways.

    The common concept Gate and the attributes of Gate with their common characteristics should be specified in 9.5.1, as a supporting object. Then in each of the subsections where the use of a Gate has special rules, only the special rules need to appear, and they should attach to the Gateway attribute that is the particular use/role of the Gate that imposes the constraint.

    Recommendation:

    In 9.5.1 add a subsection for Gate, e.g.

    "Gate

    "A Gate represents the point at which a Gateway is connected to an outgoing SequenceFlow. A given Gateway can have several Gates, one for each outgoing SequenceFlow. Each kind of Gateway imposes different constraints on the SequenceFlow, and some types of Gateway distinguish Gates with different kinds of constraints on the SequenceFlow.

    "Table 9.xx Gate Attributes

    "Outgoing SequenceFlow: SequenceFlow
    Each Gate SHALL have one associated Sequence Flow. The constraints on the SequenceFlow depend on the kind of Gateway.

    "Assignments (0..n): Assignment
    One or more assignment expressions MAY be made for each Gate. The
    Assignment SHALL be performed when the Gate is selected. The details of
    Assignment is defined in the Section B.11.1, "Assignment," on page 268."

    In table 9.27 (XOR Gateway attributes), delete the entries for Outgoing SequenceFlow and Assignments. Under the Gates attribute description, add a paragraph:
    "For each Gate, the Outgoing Sequence Flow (See Table 9.xx on page xxx) SHALL have its Condition attribute set to None (there is no evaluation of a condition expression).
    The attributes of a Sequence Flow can be found in Section 10.1.2,
    "Sequence Flow," on page 100."

    In table 9.28 (IOR Gateway attributes), delete both sets of entries for Outgoing SequenceFlow and Assignments.

    Under the Gates attribute description, add a paragraph:
    "For each Gate, except the DefaultGate, if any, the Outgoing Sequence Flow (See Table 9.xx on page xxx) SHALL have its Condition attribute set to Expression. The Outgoing Sequence Flow SHALL have a valid ConditionExpression, and the ConditionExpression SHALL be unique among all the Gates within the Gateway.
    The attributes of a Sequence Flow can be found in Section 10.1.2,
    "Sequence Flow," on page 100."

    Under the DefaultGate attribute description, add a paragraph:
    "For the Default Gate, the Outgoing SequenceFlow (See Table 9.xx on page xxx) SHALL have its Condition attribute set to Default. The SequenceThe
    The attributes of a Sequence Flow can be found in Section 10.1.2,
    "Sequence Flow," on page 100."

    In table 9.29 (Complex Gateway attributes), delete the entries for Outgoing SequenceFlow and Assignments. Under the Gates attribute description, add a paragraph:
    "For each Gate, the Outgoing Sequence Flow (See Table 9.xx on page xxx) SHALL have its Condition attribute set to None.
    The attributes of a Sequence Flow can be found in Section 10.1.2,
    "Sequence Flow," on page 100."

    In table 9.30 (Parallel Gateway attributes), delete the entries for Outgoing SequenceFlow and Assignments. Under the Gates attribute description, add a paragraph:
    "For each Gate, the Outgoing Sequence Flow (See Table 9.xx on page xxx) SHALL have its Condition attribute set to None.
    The attributes of a Sequence Flow can be found in Section 10.1.2,
    "Sequence Flow," on page 100."

  • Reported: BPMN 1.0b1 — Fri, 12 May 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Message/Property/Assignment relations are too complex

  • Key: BPMN11-22
  • Legacy Issue Number: 9563
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Message/Property/Assignment relations are too complex. It's not easy
    to model values sent along the message flow. Probably Message loaded
    with Assignments would help. Also. there is no easy way to model BPEL
    construct where full message is assigned to variable. It looks like
    there is duplication between Property set and Message. It's not clear
    whether it's possible to use Property Set or Message definition as
    Property type. Probably BPMN needs better type modeling.

  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.

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

Message Flow ordering along Pool (abst process) is modeled only graphically

  • Key: BPMN11-21
  • Legacy Issue Number: 9561
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Message Flow ordering along Pool (abstract process) is modeled only
    graphically. A specification of in/out indices to message flows is a
    solution. Otherwise it's impossible to tell from the model order of
    message receive/send for certain pool

  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

p. 282, Table 137

  • Key: BPMN11-35
  • Legacy Issue Number: 9722
  • Status: closed  
  • Source: CA Technologies ( Donna Burbank)
  • Summary:

    The attribute definitions for Property are unclear/inconsistent. The attribute names are "Type" and "Correlation". But in the Description for Correlation, the text refers to "ConditionType" and "Condition Expression": "If the ConditionType attribute is set to Expression, then the ConditionExpression attribute must be defined." It is unclear what this is referring to.

  • Reported: BPMN 1.0 — Mon, 15 May 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    No Data Available

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

The concept of "Trigger" in ambiguous in the BPMN specification

  • Key: BPMN11-34
  • Legacy Issue Number: 9719
  • Status: closed  
  • Source: CA Technologies ( Donna Burbank)
  • Summary:

    The concept of "Trigger" in ambiguous in the BPMN specification. Take, for example, a Timer Start Event. This appears to me as a start event as type timer. But the specification also seems to refer to a trigger as a separate entity--an start event with a trigger somehow 'attached'. This is confusing and should be better explained in the document.

  • Reported: BPMN 1.0 — Mon, 15 May 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

BPEL faults

  • Key: BPMN11-29
  • Legacy Issue Number: 9571
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    BPEL faults are more complex than simple error name and handler
    may be selected basing on fault name and type of the related data. BPMN
    supports only error handler selection by name. A way of specifying the
    faults at sufficient detail to enable generation of BPEL faults is
    needed, by means of some text annotation property perhaps.

  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

BPMN spec doesn't include join condition

  • Key: BPMN11-28
  • Legacy Issue Number: 9570
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    each action may contain join condition and have associated
    'suppressJoinFailure' flag. BPMN spec doesn't include join condition at
    all and puts suppressJoinFailure to the Process level only. Borland
    created complex structures to reflect behavior of related BPEL elements
    to enable generation.

  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

Specify persistent format

  • Key: BPMN11-31
  • Legacy Issue Number: 9573
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    A persistent format (XMI?) should be specified, to create possibility
    of vendor-independent models

  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Close, No Change: This issue is out of scope for the RTF and will be addressed by other OMG
    specifications, such as BPDM 1.0 and the response to the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

enhance BPMN to provide 'resource modeling'.

  • Key: BPMN11-30
  • Legacy Issue Number: 9572
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    It would be nice to enhance BPMN to provide 'resource modeling'. For
    example, a way to model working time available to the process, for
    participant. Maybe a clear way to define resources used by activities,
    number of available resource items, competition for resources.

  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

partner links are not modeled in BPMN explicitly.

  • Key: BPMN11-27
  • Legacy Issue Number: 9569
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    partner links are not modeled in BPMN explicitly. so some of
    related features are impossible to represent (e.g. dynamic partner
    links)

  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

correlation set

  • Key: BPMN11-26
  • Legacy Issue Number: 9568
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    BPEL model may use correlation set as a way to establish 'session'
    BPMN does not have similar construct. One could model a reference to
    correlation set in invoke as set of assignments. There should be a way
    to mark such set of assignments with a boolean "initiate" flag

  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

BPEL/WSDL specific properties

  • Key: BPMN11-24
  • Legacy Issue Number: 9566
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Borland found we had to add some BPEL/WSDL specific properties like
    'target namespace' and 'wsdl path' to Participant for BPEL generation

  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

Reference Task does not define any way to pass parameters and values

  • Key: BPMN11-23
  • Legacy Issue Number: 9565
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Reference Task does not define any way to pass parameters and values

  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

BPEL->BPMN mapping problem

  • Key: BPMN11-25
  • Legacy Issue Number: 9567
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    variables having 'message' type are imported as property sets,
    reference to message type is lost

    • it is hard to model variable as input and assign result of
      <invoke> to variable. If passing arguments can be modeled as sequence of
      assignments, receive part is impossible to model clearly--assignment is
      not symmetric, from is expected to be an expression and there is no way
      to define reference to service call result in expression as BPEL don't
      need it
  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

Events in subprocesses

  • Key: BPMN11-53
  • Legacy Issue Number: 9936
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The spec is unclear on when the events are enabled, ie, "listening" for
    the event.

    For example, suppose an independent process has a start event (either
    message, timer, or rule), and this process is used by another (as a
    subprocess, for example), as shown below.

    P1:

    A ---> P2 ----> B

    P2:

    Start
    Event ---> Other activities
    (Message,
    Timer,
    or Rule)

    What will happen if A is executing in P1, and the start event for P2
    occurs before A is finished?

    If P2 is intended to be called only by other processes (it isn't "top
    level"). Is there a way to prevent if from being triggered
    independently of its callers?

  • Reported: BPMN 1.0b1 — Thu, 8 Jun 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

BPMN: Interrupt Intermediate Event

  • Key: BPMN11-52
  • Legacy Issue Number: 9928
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    In many business processes, activities may be interrupted for business
    reasons. A new Interrupt Event would facilitate modeling of these
    processes. This type of Event would have try-catch semantics, similar to
    the Error Intermediate Event, but without the error semantics. To support
    this, we would need both an Interrupt Intermediate Event and an Interrupt
    End Event.

    Possible notation: a square, similar to the stop button on a tape player.

  • Reported: BPMN 1.0b1 — Thu, 20 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Implicit State Machine for Activities

  • Key: BPMN11-58
  • Legacy Issue Number: 10150
  • Status: closed  
  • Source: Axway Software ( Dale Moberg)
  • Summary:

    What are the states that an activity can transition to? Are these the values of the Status attribute of an Activity? (None, Ready, Active, Cancelled, Aborting, Aborted, Completing, Completed) What, if anything, causes a transition of an Activity from None to Ready? Can you transition from Completed to None? to Ready? And so forth.

    In what ways can these transitions occur? I think this is mainly a matter of what effects events have, but also involves the flows (and gateways, and tokens) [See the summary of start event types and their triggers (Table 9.5) and end events and process “endings” (Table 9.6) that has some info on effects on state, though some additional values appear to be mentioned.]

    If there are other states (“armed” “ready”, “listening”, “waiting” “dormant”, “inactive” and so on) list them along with basic ones such as
    “started” (“instantiated” “activated”) and completed. Are some states synonymous? Which ones? Is singly/multiply instantiated a state (so that an instantiated count could be tracked by numbers of copies active in the system?) How would the above states, if they exist, be related to the value in LoopType, StartQuantity, etc.

    Bonus: Link the state machine transistions to the token flow behaviors and when and how Activities after a Merge GW change state. How is a Start or Intermediate Event state with a None trigger different from a transfer of flow control by means of a token? There are connections between state transitions and “flow” as stated, for example, in the ConditionType Attribute where token flow is said to occur when the (source) Activity State goes to Completed. Are there rules relating the generation or consumption of tokens to the state transitions?

  • Reported: BPMN 1.0b1 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

Multiple None Start Events inside of a sub-process

  • Key: BPMN11-57
  • Legacy Issue Number: 10138
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    What would be the semantics of having multiple None Start Events inside of
    a sub-process? Should this be allowed.

    If the start events are on the sub-process border, then the semantics are
    clear. A sequence flow would target the start event and thus determine
    which start event would be triggered.
    But what happens when the start event is inside the sub-process? Will
    multiple instances of the sub-process be created? This doesn't work given
    that the sub-process instance is created when a token arrives via a
    sequence flow. If one instance is created then we have a conflict with
    the current spec semantics, in which each start event results in a new
    instance. And would tokens flow out of one start event or both?

  • Reported: BPMN 1.0b1 — Thu, 24 Aug 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

BPMN: Complex triggers

  • Key: BPMN11-51
  • Legacy Issue Number: 9925
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    It's common to have models with complex triggering conditions. For
    example, start this process upon arrival of Message A and Message B or
    arrival of Message A and Message C.

    A new trigger type, "Complex", would facilitate creation of such models.
    The trigger would be represented as an Expression in this case.

    A possible graphical notation would be to apply the same icon that is used
    in Complex Gateways.

  • Reported: BPMN 1.0b1 — Tue, 18 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

Multiple Triggers with 'and' semantics

  • Key: BPMN11-50
  • Legacy Issue Number: 9917
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    In BPMN 1.0, you can create an Event with Multiple triggers. But these
    triggers are treated as alternatives ... i.e., they have 'or' semantics.
    It is very common to require multiple triggers with 'and' semantics. That
    is, all of the triggers must be satisfied before the process will start.

    A possible graphical notation is to to use the '+' symbol inside of the
    event circle. This would then be consistent with the notation used to
    designate 'and' semantics in gateways.

  • Reported: BPMN 1.0b1 — Tue, 11 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

BPMN: Attribute definitions

  • Key: BPMN11-49
  • Legacy Issue Number: 9908
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    Some attribute descriptions and definitions require corrections:
    "Lanes" (Section B.4): Description mentions the "Id" of the lane,
    but it's the lane itself that is referenced by this attribute.
    "Inputs", "Outputs" (Section B.6.1): Description refers to
    "Document Object". Should be "Data Object".
    "OutgoingSequenceFlow" (Section B.7.2):

    • Should state that the sequence flow must be outgoing from this
      gateway. It's not actually stated, although the reader would
      probably assume that's the case.
    • Contradictory statements in the description. One sentence
      states that the Sequence Flow Condition must be Expression. And
      another sentence states that in certain cases the Sequence Flow
      Condition must be None.
      "DefaultGate" (Section B.7.2): The attributes under DefaultGate are
      not needed. The DefaultGate would reference an existing Gate, and
      thus there is no need to redefine the attributes of this Gate.
  • Reported: BPMN 1.0b1 — Wed, 12 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Inclusive Event-Based Decision

  • Key: BPMN11-56
  • Legacy Issue Number: 10096
  • Status: closed  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    We may need a way to model more general logic patterns for incoming events. For example, in response to an RFQ, a supplier may send either a decline, or a quote and (as a separate message) terms & conditions. The logic pattern for this use case is

    Decline XOR ( Quote AND Terms )

    If the Decline is accompanied by a memo giving reasons, then the logic becomes

    ( Decline AND Memo ) XOR ( Quote AND Terms )

    We want to open up three event receivers initially (four in the second case). Then, as a Quote arrives for example, we want to close the receives for Decline and Memo — since we don't expect those any longer — but keep the receive for Terms & Conditions open. When those have arrived as well, the inclusive event-based gateway is complete.

  • Reported: BPMN 1.0b1 — Mon, 7 Aug 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

Extending activities with execution time (traversal time) attributes?

  • Key: BPMN11-55
  • Legacy Issue Number: 10084
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Is there a plan for extending activities with execution time (traversal time) attribute???
    I mean is to put time on the activities which show how long they will take to finish. Maybe two attributes for the best and worst case (minimum and maximum traversal time).
    I can imagine a system, which allows displaying accumulated time for every sub process and task, for every separate flow path with minimum and maximum traversal time.
    It is more or less easy to find out estimated time for primitive tasks but it is really hard work to calculate possible execution time for whole process for synchronization purposes.
    So when you simulate the whole process at the end you will see how long the process will take in best and worst case.
    It is an excellent feature for process estimation. I realize the problems of implementing of such functionality because of merging of sequence flows but anyway it could be great feature.
    Unfortunately process execution time (traversal time) is still not supported by BPMN specification but you don’t need to be an oracle to predict that the idea will come through in the closest future.

  • Reported: BPMN 1.0b1 — Sat, 5 Aug 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

Where are tokens queued?

  • Key: BPMN11-63
  • Legacy Issue Number: 10341
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    In the following process, assume mulitple tokens are being fed to A
    from upstream (<X> = exclusive OR split, <+> = AND Join):

    ------

    ----> A – <X> <+> --> B

    ------

    I assume two executions of A are required for each execution of B (if
    not, correct the parts of the spec that imply this).

    Where are tokens queued up that don't have a matching one to get
    through the AND join? BPMN should indicate where the queuing happens,
    because it affects execution. If queuing is at the the exclusive-OR
    split, then conditions could change over time and the guard could
    direct the token to a different path after the token as been queued a
    while. Or token could queue at the join, and only be tested by the
    guards once.

  • Reported: BPMN 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

Clarify whether pools require their activites to be centrally coordinated

  • Key: BPMN11-62
  • Legacy Issue Number: 10340
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Clarify whether pools require their activites to be centrally coordinated. In particular, above Table 85, the specification says: "Note that Message Flow cannot connect to objects that are within the same Participant Lane boundary." (I think this should say "pool", rather than "lane".) Does this mean the entities represented by lanes must not coordinate their activities directly through messages to each other (ie, the coordination must be centralized)?

  • Reported: BPMN 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Do artifact flows affect execution

  • Key: BPMN11-61
  • Legacy Issue Number: 10339
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Do artifact flows affect execution? Table 8.2 (BPD Core Element) says: Data Objects are considered Artifacts because they do not have any direct effect on the Sequence Flow or Message Flow of the Process, but they do provide information about what activities require to be performed and/or what they produce. Not sure, but the above seems to imply that artifact flows do not affect execution (it does not affect sequencing or messaging). Compare Table 9.10 (Common Activity Attributes): [Input: for InputSets only] Inputs (1-n) : Artifact One or more Inputs MUST be defined for each InputSet. An Input is an Artifact, usually a Document Object. InputSets (0-n) : Input The InputSets attribute defines the data requirements for input to the activity. Zero or more InputSets MAY be defined. uEach InputSet is sufficient to allow the activity to be performed (if it has first been instantiated by the appropriate signal arriving from an incoming Sequence Flow). which seems to imply an execution semantics ("Each InputSet is sufficient to allow the activity to be performed").

  • Reported: BPMN 1.0b1 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Close, No Change: The answer to the question is that Data Objects can affect the performance of
    individual activities. However, they do not affect the operational semantics of a BPMN diagram—in terms of when and which activities will be performed. This is determined by the Sequence Flow and
    Gateways

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

Defining "Main" Pool in diagram

  • Key: BPMN11-60
  • Legacy Issue Number: 10282
  • Status: closed  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    Add an attribute to a Process that allows the modeler to define which Pool in a BPD is the "main" Pool. This Pool would be the focus of the diagram and the implementation of the Process in the Pool.

  • Reported: BPMN 1.0b1 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Is it valid to have a pool nested within a Lane,

  • Key: BPMN11-59
  • Legacy Issue Number: 10152
  • Status: closed  
  • Source: CA Technologies ( Donna Burbank)
  • Summary:

    Is it valid to have a pool nested within a Lane,

  • Reported: BPMN 1.0b1 — Fri, 1 Sep 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

Provide ExpressionLanguage attribute for the element Expression

  • Key: BPMN11-54
  • Legacy Issue Number: 9937
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Markus Klink)
  • Summary:

    BPMN expressions are defined as:

    "An Expression MUST be entered to provide a mathematical expression to be either tested as True or False or to be evaluated to update the value of Properties (e.g., assignment)."

    whereas the diagram has an ExpressionLanguage attribute which is defined as:

    "A Language MAY be provided so that the syntax of expressions used in the Diagram can be understood. "

    Expressions are used either in the boolean sense (e.g. as Conditions for Conditional flow) or in the imperative sense where expressions are evaulated to update values (e.g. as used in the element Assignment). Hence this can be conflicting with the default settings by the diagram, and is in conflict with the notion of BPMN as a human readable language it is suggested that each expression may contain an expressionlanguage field of type String. While BPMN will still mandate that certain expressions must deliver specific results, it will not standardize the expressionlanguages capable of achieving this goal.

  • Reported: BPMN 1.0b1 — Mon, 17 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

UML class diagram in the appendix

  • Key: BPMN11-80
  • Legacy Issue Number: 10503
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The UML class diagram in the appendix as revised after Ballot 4, is an object model, and it should not be an object model .

    More particularly, the new diagram in Appendix B looks like a metamodel for BPMN Element, In particular, it seems to show abstract classes (using italics for names),
    shows visibility public '+' for attributes, shows generalization relationships,
    and uses the notation for representing classes (or metaclasses), and attributes.

    This is misleading at best. It is understood within the FTF that the intent was to show the tables in a concise form,
    by using generalization to represent relationships among the tables in the appendix, but the diagram as it stands does not do that, since it includes concepts that are not appropriate to that purpose.isual representation of the tables and the rows of the tables.

  • Reported: BPMN 1.0 — Tue, 5 Dec 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

examples in section 10.2.1 Normal Flow (02)

  • Key: BPMN11-79
  • Legacy Issue Number: 10476
  • Status: closed  
  • Source: Computas ( Steinar Carlsen)
  • Summary:

    These issues refer to the examples in section 10.2.1 Normal Flow in the BPMN Adopted Specification as of february 2006; pages 125-128.

    The problem with the use of Link events for synchronizing behaviour is that there also is a need to explicitly state that two link events are the same object. This can be indicated through the use of (directed or undirected) associations, but that still is an indication only; not formalized. Next, use of such "equality associations" has problems with cases where the "same event" occurs both as an end event and a start event, as seen in figure 10.49. Here, the two "B Completed" link events are probably not exactly the same object (with the same id) since they are of different (sub)types.

    Such use of link events, which I do indeed consider very useful, should be improved in upcoming versions of BPMN.
    The situation in figure 10.49 is quite similar to "message exchange" - but within a pool. Just as there has been identified a need for distinguishing between sending and receving intermediate message events, there is a similar need to distinguish between "generating" and "reacting" intermediate link events. Generating intermediate link events could have the existing symbol; one can pragmatically think of them as "Go-to's". Reacting intermediate link events could have a new symbol with the internal fat arrow pointing right to left; these can be thought of as "Comes-from's". In the example then the topmost "B Completed" event could be changed into an generating intermediate link event. The bottom fragment could be changed into a normal start event, followed by a reacting intermediate "B Completed" link event followed by task D.

  • Reported: BPMN 1.0 — Thu, 25 Jan 2007 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    No Data Available

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

Section: 9.3.4 Intermediate [Events]

  • Key: BPMN11-87
  • Legacy Issue Number: 10932
  • Status: closed  
  • Source: Cleverlance ( Peter Sur.ák)
  • Summary:

    All the next five numbered points are BPMN Specification descriptions for Cancel Intermediate Event possible uses. TO SUMMARIZE EXECUTIVELY , text in the table 46 states that Cancel Intermediate MUST NOT be used when the Event is attached to the boundary of a Transaction WHILE text on pages 45, 47 and 60 and figure on page 60 indicate that Cancel Intermediate Event can be ONLY USED attached to the boundary of Sub-Process. I BELIEVE this is CRITICAL issue, because it establishes the completely opposite views and can possibly lead for example to rejection of valid BPMN diagram. 1) Text in chapter 9.3.4 Intermediate [Events] in table 9.9 on page 46 in the first row "Trigger" [attribute] in column Description states that "The Cancel Trigger MUST NOT be used when the Event is attached to the boundary of a Transaction or if the Event is not contained within a Process that is a Transaction." THE CORRECT SENTENCE should be "The Cancel Trigger MAY only be used when Event is attached to the boundary of a Sub-Process that is a Transaction." Read on... 2) At the same time, in chapter 9.4.3 Intermediate [Events] in Table 9.8 on page 45 is stated for Cancel Intermediate Event that "This type of Intermediate Event is used within a Transaction Sub-Process. This type of Event MUST be attached to the boundary of a Sub-Process. It SHALL be triggered if a Cancel End Event is reached within the Transaction Sub-Process. It also SHALL be triggered if a Transaction Protocol “Cancel” message has been received while the Transaction is being performed." 3) Text in the same chapter right below the table 9.9 in section "Activity Boundary Connections" on page 47 says, that "An Intermediate Event with a Cancel Trigger MAY be attached to a Sub-Process boundary only if the Transaction attribute of the Sub-Process is set to TRUE." 4) Except that, also in chapter 9.4.2 Sub-process in section "Sub-Process Behavior as a Transaction" on page 60 the indicates that "A Cancel Intermediate Event, attached to the boundary of the activity, will direct the flow after the Transaction has been rolled back and all compensation has been completed. The Cancel Intermediate Event can only be used when attached to the boundary of a Transaction activity. It cannot be used in any Normal Flow and cannot be attached to a non-Transaction activity." 5) Also the figure 9.11 on page 60 shows Cancel Intermediate Event attached to the boundary of Transaction Sub-Process.

  • Reported: BPMN 1.0b1 — Mon, 26 Mar 2007 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

BPMN Task Attribute "TaskType" Value-related Message Flow Restrictions

  • Key: BPMN11-86
  • Legacy Issue Number: 10657
  • Status: closed  
  • Source: Escape Velocity ( Bob Daniel)
  • Summary:

    . If a task has the TaskType value set to “None”, the task is not allowed to have incoming or outgoing message flows. This restriction should be removed. “None” would logically be interpreted as “not defined”, so the message flow restriction would be overly constraining—one might be early in an analysis and the type of task not yet defined, though a message flow in/out specified. (Note that the ProcessType attribute on Process also has the legal value “None”, and in that case the definition parenthetically states that “None” means “not defined”. Further, no restriction is placed on message flow.)

    2. The message flow connect rules in Table 8.5 do not reflect the TaskType value message flow restrictions otherwise defined in Table B.64. An annotation (footnote) should be made to the table to note the restrictions.

  • Reported: BPMN 1.0 — Thu, 8 Feb 2007 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Add Project Management dependencies for activities (FF, FS, SF, SS)

  • Key: BPMN11-85
  • Legacy Issue Number: 10527
  • Status: closed  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    Project management models define the start/finish relationships between activities. This is handled in four ways: Finish-Finish; Finish-Start; Start-Finish; and Start-Start. Current BPMN Flow handles two of the four. A sequential flow of activities is a Finish-Start; a parallel set of activities is a Start-Start. But the other two combinations are not definable. The solution may not require graphical canges to BPMN, but there should be some behavioral support for these situations.

  • Reported: BPMN 1.0 — Fri, 15 Dec 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

Use of link events to synchronize behaviour

  • Key: BPMN11-81
  • Legacy Issue Number: 10516
  • Status: closed  
  • Source: Computas ( Steinar Carlsen)
  • Summary:

    These issues refer to the examples in section 10.2.1 Normal Flow in the BPMN Adopted Specification as of february 2006; pages 125-128.

    A problem with the use of Link events for synchronizing behaviour is that there also is a need to explicitly state that two link events are the same object. This can be indicated through the use of (directed or undirected) associations, but that still is an indication only; not formalized. Next, use of such "equality associations" has problems with cases where the "same event" occurs both as an end event and a start event, as seen in figure 10.49. Here, the two "B Completed" link events are probably not exactly the same object (with the same id) since they are of different (sub)types.
    Such use of link events, which I do indeed consider very useful, should be improved in upcoming versions of BPMN.

    Two possible solutions for this could be:

    1) Introduce a way of specifying that two flow objects within/across diagrams are "equal"; possibly also allowing equality across start and end events. Could be a particular kind of associons with strong semantics.

    2) The situation in figure 10.49 is quite similar to "message exchange" - but within a pool. Just as there has been identified a need for distinguishing between sending and receving intermediate message events, there is a similar need to distinguish between "generating" and "reacting" intermediate link events. Generating intermediate link events could have the existing symbol; one can pragmatically think of them as "Go-to's". Reacting intermediate link events could have a new symbol with the internal fat arrow pointing right to left; these can be thought of as "Comes-from's". In the example then the topmost "B Completed" event could be changed into an generating intermediate link event. The bottom fragment could be changed into a normal start event, followed by a reacting intermediate "B Completed" link event followed by task D. There also must be some way of "pairing" the related generating and reacting events; this could be done by adding an attribute to the receiving event which holds the id of the matching generating event.

  • Reported: BPMN 1.0 — Thu, 14 Dec 2006 05:00 GMT
  • Disposition: Duplicate or Merged — BPMN 1.1
  • Disposition Summary:

    No Data Available

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

question raised by Issue 9321 nor addresses by issue 9319

  • Key: BPMN11-83
  • Legacy Issue Number: 10519
  • Status: closed  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    Issue 9321 was resolved as being addressed by Issue 9319. However, the resolution of Issue 9319 did not adequate address the question raised by Issue 9321. Thus, this question still needs to be addressed. The Issue is:
    The start of section 8 has the following which suggests 2 levels of compliance; however this opportunity has been missed in the conformance section: "First, there is the list of core elements that will support the requirement of a simple notation. These are the elements that define the basic look-and-feel of BPMN. Most business processes will be modeled adequately with these elements. Second, there is the entire list of elements, including the core elements, which will help support requirement of a powerful notation to handle more advanced modeling situations."

  • Reported: BPMN 1.0 — Fri, 8 Dec 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Move Sequence Flow Conditions to Gates

  • Key: BPMN11-82
  • Legacy Issue Number: 10518
  • Status: closed  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    Right now flow conditionality is maintained in the Sequence Flow. This should be moved to the Gates and then the Sequence Flow become purely a mechanism to advance the flow (Token).

  • Reported: BPMN 1.0 — Thu, 7 Dec 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

examples in section 10.2.1 Normal Flow (01)

  • Key: BPMN11-78
  • Legacy Issue Number: 10475
  • Status: closed  
  • Source: Computas ( Steinar Carlsen)
  • Summary:

    The problem with the use of Link events for synchronizing behaviour is that there also is a need to explicitly state that two link events are the same object. This can be indicated through the use of (directed or undirected) associations, but that still is an indication only; not formalized. Next, use of such "equality associations" has problems with cases where the "same event" occurs both as an end event and a start event, as seen in figure 10.49. Here, the two "B Completed" link events are probably not exactly the same object (with the same id) since they are of different (sub)types.

    Such use of link events, which I do indeed consider very useful, should be improved in upcoming versions of BPMN.
    Two possible solutions for this could be:
    1) Introduce a way of specifying that two flow objects within/across diagrams are "equal"; possibly also allowing equality across start and end events. Could be a particular kind of associons with strong semantics.

  • Reported: BPMN 1.0 — Thu, 16 Nov 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

confusion regarding diagram 10.25

  • Key: BPMN11-89
  • Legacy Issue Number: 11241
  • Status: closed  
  • Source: Value Momentum Software Services Pvt Ld ( Chandrakant Manglani)
  • Summary:

    There is a confusion regarding diagram 10.25. The word Condition means that the condition has to be met before the Activity/Process is initiated. However, the word ‘Default Condition’ conveys a wrong meaning. It is the word ‘Condition’ in the ‘Default Condition’ that is causing the confusion. Instead of saying ‘Default Condition’ can rather call it ‘Default’ or ‘Mandatory’. OR, if it mandatory then it should not branch out of a decision box and rather branch out of the Original Process.

  • Reported: BPMN 1.0b1 — Wed, 1 Aug 2007 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    The following minor text modifications will be made to the BPMN 1.1 Specification

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

Section: 10:2.1 Normal Flow

  • Key: BPMN11-88
  • Legacy Issue Number: 10933
  • Status: closed  
  • Source: Cleverlance ( Peter Sur.ák)
  • Summary:

    Section - Forking Flow, page 111 - there is a typo: "Even when not required as a “best practice,” there are situations were the Parallel Gateway provides a useful indicator of the behavior of the Process." ... The sentence should state: "... are situations WHERE [capitalization added] the ..."

  • Reported: BPMN 1.0b1 — Mon, 26 Mar 2007 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    The following minor text modification will be made to the BPMN 1.1 Specification

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

Should Exception Events be allowed to have no Outgoing Sequence Flow?

  • Key: BPMN11-84
  • Legacy Issue Number: 10520
  • Status: closed  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    Exception Events (i.e., attached to an activity) are required to have an outgoing Sequence Flow. However, if the model being created is simple and does not use Start and End Events (see figure below), and the exception is extended to end the process, should we allow the modeler to forgo the use of Start and End Events (which would be currently required)?

  • Reported: BPMN 1.0 — Fri, 8 Dec 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

fundamental semantic model of token flows

  • Key: BPMN11-15
  • Legacy Issue Number: 9376
  • Status: closed  
  • Source: me.com ( Frank McCabe)
  • Summary:

    Currently there is no description of the fundamental semantic model of token flows in the spec. Clearly it is based on a variety of petri net; however a description of the particular semantics assumed in BPMN could be very useful in reading the spec. Such a description should be formal in the sense that it should be mathematically clear what the procedural semantics of BPMN is

  • Reported: BPMN 1.0b1 — Thu, 23 Feb 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

differentiate a business message from a business signal

  • Key: BPMN11-14
  • Legacy Issue Number: 9364
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Comment to BPMN FTF:

    • Currently there is no standard way to differentiate a business
      message from a business signal, which have fundamental different
      characteristics.

    ========
    During the ebBP-BPMN discussions last week, I was asked to summarize what business signals are and how they function. There has been some initial discussion on the bpmn@omg.org list re: signals in general. I'd like to make a necessary distinction about the similarities and differences.

    • What is a business signal? [1]
      o "Business signals have a specific business purpose and are
      separate from lower protocol and transport signals. One or
      more Business Signals can be exchanged as part of a Business
      Transaction to ensure state alignment between both parties.
      Evaluation of business signals enable the state of a
      Business Collaboration to be explicitly calculated at run
      time. The ebBP technical specification provides both the
      structure and choreography of Business Signals, including
      allowing for user defined signals....

    A Business Signal is computable. This provides the
    collaborating parties with a mutual understanding of the
    business activity. This function allows the parties to know
    if their expectations in a Business Transaction are
    realized. This is state alignment, and is important in order
    for the ebBP specification to have commercial viability. The
    ebBP specification provides the ability to conduct intended
    transactions if that is the intent of the collaborating
    parties."

    • Where does the business signal fit in eBusiness and business
      messaging? [2]
      o State alignment: (almost quoting from our specification for
      specifics) The process of exchanging signals and state
      changes of a Business Transaction enables state alignment
      between the parties involved. If the standard signals are
      used, the structures of ebXML Business Signals are
      ‘universal’ and do not vary from transaction to transaction.
      Business signal schema can be found at:
      http://www.oasis-open.org/committees/document.php?document_id=16460&wg_abbrev=ebxml-bp
      (detailed schema documentation also exists on this public
      page). The ebBP technical specification provides both the
      structure and choreography of Business Signals. The ebXML
      Message Service Specification (and other evolving
      technologies) provides a reliable messaging infrastructure.
      This is the basis upon which the ebBP technical
      specification builds its protocol for business state
      alignment using Business Signals. The Business Signal
      payload structures are optional and normative and are
      intended to provide business semantics to the Business Signals.
      o Part of process definition: Defined in the BT pattern and
      bounded by partner expectations. Map back to business
      transaction activity. Map back to service and action context
      for agreement (such as CPP/A).
      o Transition and determination of several types of successes
      and failures: Condition guards exist on transition in
      process steps and activities. Business signals are integral
      here. In ebBP and in business collaboration, there is
      protocol and business success whereby one supports the
      other. Reference:
      http://www.oasis-open.org/committees/document.php?document_id=16457&wg_abbrev=ebxml-bp
      (See Section 3.6.3)
    • What happens if you don't model these signals?
      o In configuration: Business and messaging signals are
      explicitly modeled in configuration.
      o In understanding the partner agreement: The partners may
      mutually expect these be used and therefore set criteria
      associated with the progress and outcomes of the business
      process (and its activities).
      o In managing state transitions: See previous comment.
      o In seeking to generate computable artifacts: Without the
      definition of such signals, the artifacts either have to be
      defined out of band or in a potentially proprietary way. We
      allow user-defined signals, although they are still related,
      included and part of the business process.
    • Links to the business process [3]
      o Standard signals: Defined structure and semantics related to
      the pattern, activity and transitions
      o User defined signals: Allowed pointers to user-defined structure
      o BT patterns
      + Template: See patterns matrices in the specification
      (sections 3.4.9 and 3.4.9.1) that specify how these
      signals infer content validation, succesful syntactic
      validation and also allow the business process to
      proceed (or not).
      + Profile: Partners identify their expectations using
      the patterns and the selectable criteria to support
      not only the business messages received but the
      business signals that support them.
      o Relevance to model
      + Business Transactions and the Business Service View
      [4. See Chapter 9].
      + Business significance
    1. Involves timing parameters, implication to
      business partner expectations, etc. Several
      important criteria are defined around the use of
      the business signals. [4. See Chapter 8. State
      notations and their relevance to partner
      expectations are found in Chapter 9.]

    You can see how signals are used in the process definitions found on our public web site at: (ePV, Netherlands example) http://www.oasis-open.org/committees/document.php?document_id=16436&wg_abbrev=ebxml-bp

    Facts

    • Properties such as line width or color could be used but can't be
      seen if printed on black and white.
    • Properties such as message and (add) signal could be used. The
      latter would have to be added. There would also possibly need to
      be a way to differentiate whether or not business signals were
      used as the implementation and runtime results may differ given
      that assumption (different semantics).
    • In order to maintain the focus of generation of software
      artifacts, business signals should be considered for modeling in a
      standard way (preferred to a tool specific option).

    Additional note: We have seen tools that actually use the properties of messages to delineate a signal (such as a stereotype).

    • Business signals differ from underlying messaging infrastructure
      acknowledgements. Several communities including UK Bristol
      government and ePV have indicated the value of the use of business
      signals. Supports monitoring framework as well.

    Business example
    Two partners agree to engage in a Commercial Transaction pattern and use the BT from the pattern. A BTA is developed in a Business Collaboration to support these expectations. The partners will use reliable messaging and they use the business signals. An intelligibility (syntactic) check is made on the business message before the Receipt Acknowledgement business signal is sent, and successful business processing is required on the business document before an Acceptance Acknowledgement business signal is generated. Both carry timing expectations with them (in support of the BTA). For example, an Order Management system would validate a business document meets the partner expectations before initiating a sales order and sending a Response from a Purchase Order Request. Prior to the Response being sent these signals are used. They also allow the partners to optimize where required. The Buyer (Requesting Role) can understand that the Request was received and then whether or not it was successfully business processed (i.e. alleviating the potential need to query another Seller). Let's assume the Purchase Order doesn't muster in validation processing, then a Negative Acceptance Acknowledgement is sent. The Buyer (Requesting Role) may have an early indication and then can send a Cancel Transaction. Both parties are able to react more quickly to current conditions. In addition the business signals give clear indication of state alignment (the parties have a shared understanding of their condition and state of the business expectations).

    Example business signals found at: http://www.oasis-open.org/committees/download.php/16652/ebxmlbp-v2.0.2-cd-ExampleSignals.txt

    [1] From our FAQ found at: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/16540/ebBPv2.FAQ.html
    [2] Not transport level or HTTP acknowledgements.
    [3] Business signals defined in Section 3.4.9.3 at: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/ (in technical specification)
    [4] This reference was provided on the public bpmn@omg list late last week - N090 UNCEFACT Modeling Methodolgy R10 [1]. The business signals occur in the Business Service View (which is different than a transport level component), see: http://www.ifs.univie.ac.at/untmg/ (UMM_N090R10_2001-11_01.zip) - See chapters 8-9.

  • Reported: BPMN 1.0b1 — Tue, 14 Feb 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

shared collaboration

  • Key: BPMN11-13
  • Legacy Issue Number: 9363
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This was submitted to BPMN members in addition to the OASIS ebBP list 13-14 February 2006. This is sent in an abbreviated fashion to FTF for comment inclusion.

    Diagram examples: http://www.oasis-open.org/committees/download.php/16684/ebxmlbp-v2.0.2-Document-pr-BPMN-r02-en.zip

    As a subsequent followup between BPMN and ebBP (discussions 7 and 9 February 2006), our team has begun to delve deeper into using (future) joint activity, associate the operation activities to business transaction activities, show the use of business signals and business signal exceptions (such as Negative Receipt Acknowledgement) and understand what questions remain.

    Initial thoughts of potential needs (current or future) for BPMN that may be relevant for shared collaboration [1]:

    1. Visibility of the BT pattern and its constraints and guidelines
    2. Business QoS aspects (guidance that may translate to technical
    mechanisms in the messaging infrastructure)
    3. More detailed modeling of the business document (this may be part
    of properties). This may be too granular for BPMN however.
    4. Need for end timers

    • Timers are not just for exceptions but may be for receipt of
      a business signal (Receipt or Acceptance Ack), and for the
      overall collaboration, activity, etc.
      5. Need to be able to model simply multiple internal processes to
      support different operations, or the same operation using
      different mechanisms.
      6. How to effectively show how a business partner may assume many
      roles in a pool.
    • For example, a Supplier (exposed in Business Collaboration)
      may assume the roles of Buyer, Distributor or Seller. These
      roles may be specific to the activities within a joint
      activity or be associated with the activities defined
      elsewhere but visible in a Complex Business Transaction
      Activity. Visibility and participation in this activity are different but may be associated.
      7. Last year we spoke to some of your team members about the use of inclusive OR gateway, and intermediate or end
      messages for representing that a response could be several different types of responses (cancel, change, accept for
      example). The current BPMN semantics preclude use of message flows into / out of a gateway. In addition, we couldn't
      determine how to indicate that multiple types of business messages (specifically) may occur. We originally used
      exclusive rather than an inclusive OR gateway notation object (per BPMN suggestion in September). With inclusive
      OR, parallelism could result. For example, in a decision, it is modeled that one path is taken. In order to represent the sequence flow into a gateway, and several possible paths out (termed end messages in BPMN), I opted
      to use the inclusive OR gateway as suggested. In ebBP, forks can be non-deterministic intentionally. Forks can
      resemble a non-deterministic OR or parallel ANDs or exclusive OR (like a Decision). This question arose outside of
      the option to use a future joint activity.

    What gateway control type is appropriate when you actually could
    have n potential paths on a fork or join,
    and either only one is actually performed or many could be
    performed, and business messages are sent? This is actually a conceptual difference in current BPMN v1.0 and
    collaboration whereby not all paths may be rendered executable or be used in execution (monitorable in ebBP context).

  • Reported: BPMN 1.0b1 — Tue, 14 Feb 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

Need consistent terminology for Categories, Core Elements

  • Key: BPMN11-12
  • Legacy Issue Number: 9357
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Issue summary: Need consistent terminology for Categories, Core Elements
    aka Graphical Objects

    Details:
    Note: This issue is related to the one above ???3 under the summary:
    Which is it, Core Elements, or Flow Objects?.

    The text presentation on page 15 of 06-01-01 (section 8.1) introduces
    four "basic categories" of Core Modeling Elements.
    compare that with Section 9.1, the text preceding Table 9.1, which reads
    in part
    >>>> "BPMN graphical objects (Flow Objects, Swimlanes, Artifacts and
    Connecting Objects)"
    These same four were earlier said to be the basic Categories aka the
    Core Modeling Elements. Now they are said to be the four "graphical
    objects".
    It seems likely that authors of different parts of the text were agreed
    that this list of four was speciallly important, but that they did not
    use the same terminology for them. They should consistently be termed
    "categories", "core elements" or "the BPMN Graphical Objects", but not a
    mix of all 3 terminologies.

    Since these four categories turn up in so many contexts, they invite
    close study, and their seemng importance – at least in the view of the
    authors of the spec – suggests that the metamodel of the BPMN domain
    should recognize them as important metaclasses. If this implication is
    not intended, then the text should get rid of these "categories".

  • Reported: BPMN 1.0b1 — Fri, 3 Feb 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

Some references are not explicit

  • Key: BPMN11-20
  • Legacy Issue Number: 9560
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Some references are not explicit. Borland, for example, added
    reference between matching link events into our metamodel. Apparently,
    there may be a reference between error events (one causing error and
    another one providing connection to error handler) and possibly for
    compensation event

  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Containment structure is unclear for non-graphical elements

  • Key: BPMN11-19
  • Legacy Issue Number: 9559
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:
    • Containment structure is unclear for non-graphical elements like
      WebService, Message, Rule etc. Borland made deliberate decisions to put
      some of them into Diagram, some to Participant.
  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    No Data Available

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

Which is it, Core Elements, or Flow Objects?.

  • Key: BPMN11-11
  • Legacy Issue Number: 9355
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Note: This issue is vaguely related to 9321
    See section 8.1 "BPD Core Element Set" starting on page 15 of 06-01-01
    The text presentation is organized according to four "basic categories" and gives the impresion that some semantic or syntactic commonality underlies each of the four categories. The category Flow Objects are listed on page 15 as bullet items.
    .
    but the table 8.1 repeats the same list, but now calling them "Core Modelng Elements", and the category "Flow Objects" has been forgotten. This is confusing.
    It is additionally confusing to have separate lists of "Core Modeling Elements", "Core

  • Reported: BPMN 1.0b1 — Thu, 2 Feb 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None

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

BPEL mapping definition is imprecise

  • Key: BPMN11-18
  • Legacy Issue Number: 9558
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    BPEL mapping section suggests mapping of flow graph to structural BPEL
    construct which calls for the complex flow analysis (e.g. to define
    bounds of the switch construct). With this complexity, BPEL mapping
    definition is imprecise. Some constructs, like exception handling, don't
    map to BPEL constructs suggested by the spec due to the difference in
    behavior. I would suggest to redefine mapping using approach described
    in article "An Example of Using BPMN to Model a BPEL Process"
    http://www.bpmn.org/Documents/Mapping%20BPMN%20to%20BPEL%20Example.pdf

  • Reported: BPMN 1.0b1 — Thu, 13 Apr 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

how to model a process where more than one participant (pool) plays a part

  • Key: BPMN11-17
  • Legacy Issue Number: 9465
  • Status: closed  
  • Source: Borders Group ( Doug Howell)
  • Summary:

    Reading over the BPMN spec, my main question is how to model a process where more than one participant (pool) plays a part in it. We have many Visio diagrams where a process is drawn across several swimlanes to denote that several people/groups take part in one process. This seems to be very intuitive for people. Is there any way to model a process across pools, or does BPMN require the modeling of multiple processes (with similar names)? names?

  • Reported: BPMN 1.0b1 — Tue, 21 Mar 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Is BPMN just a notation?

  • Key: BPMN11-16
  • Legacy Issue Number: 9461
  • Status: closed  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    We should clarify the nature of BPMN. If BPMN is just a notation, then Section 2 (BPMN Overview) should be specifically state this and also contrast a notation from other types of process specifications. If BPMN is not just a notation, then this should likewise be stated and its scope and purpose should be made clear.

  • Reported: BPMN 1.0b1 — Fri, 17 Mar 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Clarify the scope and usage of Compensation Events

  • Key: BPMN11-74
  • Legacy Issue Number: 10429
  • Status: closed  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    The usage and scope for non-transactional compensation events, both throwing and catching, is not clear in the spec.

  • Reported: BPMN 1.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Change the activity Marker for Multiple Instance activities

  • Key: BPMN11-73
  • Legacy Issue Number: 10428
  • Status: closed  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    The maker for Multiple Instances (two vertical parallel lines) is a bit confusing. It looks like a "pause" symbol on a tape player. This should be changed. The new marker should indicate multiple instances in both the parallel and serial forms of the activity.

  • Reported: BPMN 1.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Culturally significant icons

  • Key: BPMN11-72
  • Legacy Issue Number: 10409
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    BPMN uses a six-pointed star for events with multiple triggers and for
    event-based gateways. This symbol has cultural and religious significance,
    and apparently its use will block adoption in certain regions and
    countries.

    Recommend replacing it with a 5-pointed star.

  • Reported: BPMN 1.0b1 — Thu, 12 Oct 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above pages 53 through 55 for figures (dtc/2007-06-01)

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

no way to graphically differentiate an Embedded Subprocess

  • Key: BPMN11-71
  • Legacy Issue Number: 10384
  • Status: closed  
  • Source: CA Technologies ( Donna Burbank)
  • Summary:

    There is currently no way to graphically differentiate an Embedded Subprocess vs. an Independent Subprocesses. Suggested resolution is to use the "go to" arrow instead of a "+" (plus sign) for the Independent Subproces, similar to the off-page connector. This would indicate that the Independent Subprocess "goes to" another diagram.

  • Reported: BPMN 1.0b1 — Fri, 6 Oct 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

BPMN spec not clear on separation of data/display regarding pools and lanes

  • Key: BPMN11-65
  • Legacy Issue Number: 10350
  • Status: closed  
  • Source: CA Technologies ( Donna Burbank)
  • Summary:

    The BPMN specification is not clear on the separation of data and display regarding pools and lanes. In some cases, pools and lanes seem to only be visual containers that are portrayed on diagrams. In other cases (e.g. in property definitions), pools and lanes seem to a part of the actual BPMN data/metadata.

    Consider the following use case:

    I create a new business process diagram
    Within this diagram, I create a pool with two lanes
    Within the lanes, I create a sequence of flow objects which collectively create a BP Process (that could be executed).

    In the case above, the diagram will reference the pool. The pool will both define the process and reference the lanes within the pool.

    The following questions emerge:

    1. Can the BP process itself be referenced (i.e. displayed) in more than one business process diagram, either as a new unique pool or an independent sub-process inside another process? Or does a BP process have only one diagram (or set of diagrams if using off-page connectors) associated with it.

    2. Consider the case of storing BPMN metadata without diagram representation. In data, is a pool and/or lane considered to be the owner to the BP process inside the pool / lane, or is just a visual attribute of the process? It seems if you have a BP Process (that contains flow objects), you would be able to portray this same process in two BPMD diagrams 1) a pool/lane showing the flow objects in the process 2) an independent sub-process showing flow objects in the process.

    3. Is there ever a case where BP process is considered to be the owner of the pool? That is, a process contains more than one pool. From the spec, it appears that a pool can define only one process, and a process cannot own one or more pools.

  • Reported: BPMN 1.0b1 — Mon, 18 Sep 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Page: 23

  • Key: BPMN11-64
  • Legacy Issue Number: 10348
  • Status: closed  
  • Source: Real IRM Solutions ( Sonja Stafford-Northcote)
  • Summary:

    On page 23 of the BPMN specification, it is stated that Tasks of type Receive can be used after the XOR Event Based Decision. So, such a Receive Task will have an incoming Sequence Flow from an XOR Event Based Decision. But, on page 64 it is stated that no other incoming Sequence Flow (other than from a Start Event)are allowed for the Receive Task." I find these 2 statements contradicting each other. Can you please advise.

  • Reported: BPMN 1.0b1 — Mon, 18 Sep 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    No Data Available

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

References to Annex D and there is no Annex D in this specification

  • Key: BPMN11-77
  • Legacy Issue Number: 10467
  • Status: closed  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    Specification: BPMN Final Adopted Specification: dtc/06-02-01
    Contact: Stephen White, IBM
    Problem: References to Annex D and there is no Annex D in this specification

    Exact places to remove Annex D reference:
    Section 9.3.2 Start, page 37 (first paragraph on the page)
    Page 61 (first Note on the page)
    Table 11-5 "End Event Mapping to BPEL4WS" page 141, Cancel (End Event column)
    Table 11-11 "Cancel Intermediate Mapping to BPEL4WS" page 145, Trigger = Cancel (Intermediate Event column)
    Table 11-26 "Sub-Process Mappings to BPEL4WS" page 167, IsATransaction (Sub-Process column)
    Table 11-43 "Exception Flow Mappings to BPEL4WS" page 180, Quantity 1: Integer (Sequence Flow column)

  • Reported: BPMN 1.0 — Mon, 20 Nov 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

The direction arrow for association seems backwards

  • Key: BPMN11-76
  • Legacy Issue Number: 10449
  • Status: closed  
  • Source: CA Technologies ( Donna Burbank)
  • Summary:

    The direction arrow for association seems backwards. For a “To” association, I would expect the arrowhead to be at the target object. This is how most modeling tools work.

    A à B would indicate the “flow” goes from A TO B, and would be considered a “To” association. Currently, the BPMN would show this as A ß B (arrowhead at the source), which is not intuitive

  • Reported: BPMN 1.0 — Mon, 13 Nov 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Section: 10.1.3

  • Key: BPMN11-70
  • Legacy Issue Number: 10375
  • Status: closed  
  • Source: Vanderlande Industries ( Shobha Radhakrishnan)
  • Summary:

    After reading the following on BPMN - BPMN OMG Final Adopted Specification of March 6 2006, - Introduction to BPMN by Stephen A.WHite, IBM Corporation. In the latter paper are the following statements: "Pools are used to represent Participants in the process" "Message flow is defined as the mechansism to show the communication between two participants" "Lanes are often used to separate the activities associated with a company function or role" With the above three statements, I am having difficulty understanding the rationale for the below statement about BPMN "Sequence Flow may cross the boundaries of Lanes within a Pool, but Message Flow may not be used between FLow objects in Lanes of the same Pool". To model the process of how a Customer project is executed by a company, I want to model Organisation Units (e.g. Sales, Development) as Pools and roles inside those Units as Lanes (e.g. Project Manager, Team Leader, Architect, Developer etc), Message Flows can be used to represent the interactions between Sales and Development Units. But I am not allowed to use Message Flows to represent the interactions between an Architect and the Developer. WHy? Am I using the pools and lanes in a manner that is against the philosophy of BPMN? I tried to get an answer from BPMN OMG Final Adopted Specification of March 6 2006, but the rationale was not very clear. Please could I have a clarification for the rationale between not allowing message flows between lanes in the same pool.

  • Reported: BPMN 1.0b1 — Wed, 27 Sep 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

Specify return type of ComplexMI_FlowCondition

  • Key: BPMN11-75
  • Legacy Issue Number: 10448
  • Status: closed  
  • Source: International Business Machines ( Petko Chobantonov)
  • Summary:

    Summary: Specify the return type of ComplexMI_FlowCondition defined in Multi-Instance Loop attributes table

    The specification does not specify the expected return type of ComplexMI_FlowCondition expression attribute.

  • Reported: BPMN 1.0 — Thu, 9 Nov 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Add a UML Profile to the BPMN specification

  • Key: BPMN11-69
  • Legacy Issue Number: 10373
  • Status: closed  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    Add a UML Profile to the BPMN specification

  • Reported: BPMN 1.0b1 — Wed, 27 Sep 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

The Reference Task and Reference Subprocess should be removed

  • Key: BPMN11-68
  • Legacy Issue Number: 10372
  • Status: closed  
  • Source: CA Technologies ( Donna Burbank)
  • Summary:

    “The Reference Task and Reference Subprocess should be removed. With the resolution of issue 9559, containment issues no longer restrict the vendor from making any BPMN object reusable/referenced.”

  • Reported: BPMN 1.0b1 — Tue, 26 Sep 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    Suggested Resolution:
    Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
    the BPMN 2.0 RFP.
    Revised Text: None
    Disposition: Closed, deferred

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

Section: 8.1, Table 8.1

  • Key: BPMN11-67
  • Legacy Issue Number: 10355
  • Status: closed  
  • Source: InfoPro ( Jim Godfrey)
  • Summary:

    The last sentance in the "Activity" "Description" paragraph in Table 8.1 should read "Processes are either unbounded or ARE [capitalization added] contained ... ." The sentance currently, and incorrectly, reads "Processes are either unbounded or A contained ... ."

  • Reported: BPMN 1.0b1 — Tue, 19 Sep 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Section: 7.1.1/Note

  • Key: BPMN11-66
  • Legacy Issue Number: 10352
  • Status: closed  
  • Source: InfoPro ( Jim Godfrey)
  • Summary:

    The second sentance under "Note" in section 7.1.1 should start with the word "See." The word is missing.

  • Reported: BPMN 1.0b1 — Tue, 19 Sep 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Definition of "Rule"

  • Key: BPMN11-38
  • Legacy Issue Number: 9892
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    The definition of "Rule", as given in section B.11.9, is ambiguous. More
    clarification is needed in the spec.

  • Reported: BPMN 1.0b1 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Link does not have clear semantics

  • Key: BPMN11-37
  • Legacy Issue Number: 9883
  • Status: closed  
  • Source: Agile Enterprise Design ( Fred Cummins)
  • Summary:

    Issue: Link does not have clear semantics. Not clear if it is graphical only (for connecting off page or cross page lines, or has execution semantics. Also, it is not clear what types of elements can be linked. Need to clarify semantics for BPDM. Proposed solution (FTF discussion) Link is a graphical convenience for connecting two points on a graphical representation of a process. The points must be within a single pool and the name/identifier must be unique within the pool. It is only valid where a line without the link(s) would be valid.

  • Reported: BPMN 1.0b1 — Wed, 5 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

BPMN TaskType Attribute

  • Key: BPMN11-36
  • Legacy Issue Number: 9801
  • Status: closed  
  • Source: Axway Software ( Sylvain Astier)
  • Summary:

    Page 64 (Adobe 88) of the BPMN Spec (06-02-01) the first row of table 9.17 reads:

    "TaskType (Service | Receive | Send | User | Script | Manual | Reference | None) None : String"

    This would mean the default type for the TaskType attribute would be "None". However, the description says « TaskType is an attribute that has a default of Service », which makes more sense to me.

  • Reported: BPMN 1.0b1 — Thu, 1 Jun 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

MessageFlows to a subprocess boundary

  • Key: BPMN11-46
  • Legacy Issue Number: 9903
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    Page 103 states that
    If the Message Flow is connected to the boundary of the Expanded
    Sub-Process, then this is equivalent to connecting to the Start Event
    for incoming Message Flow or the End Event for outgoing Message Flow
    (see Figure 10.7).

    Does this make sense, considering that the Sub-Process may contain
    Send/Receive Tasks and Message Intermediate Events? If we remove this
    sentence, then we should also remove Figure 10.7.

  • Reported: BPMN 1.0b1 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

DataObject attributes

  • Key: BPMN11-45
  • Legacy Issue Number: 9902
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    The DataObject contains two attributes "RequiredToStart" and
    "ProducedAtCompletion". These probably should be on the Activity rather
    than the DataObject, since a single DataObject can be associated with
    multiple Activities. Also, we may want to relate them in some way to the
    Activity Input/Output Sets.

  • Reported: BPMN 1.0b1 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Intermediate Events with outgoing Message Flow

  • Key: BPMN11-42
  • Legacy Issue Number: 9899
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    Page 48 states that an Intermediate Event cannot have outgoing Message
    Flow. This restriction should be removed.

  • Reported: BPMN 1.0b1 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Tasks with multiple outgoing message flows

  • Key: BPMN11-41
  • Legacy Issue Number: 9898
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    Page 92 states that a Task may have zero or more outgoing Message Flows.
    But the tasks that support outgoing message flows (e.g. SendTask,
    ServiceTask, etc) can have at most one outgoing Message. This implies that
    all Message Flows leaving a single Task must all be associated with the
    same Message. This should be clarified in the spec.

  • Reported: BPMN 1.0b1 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

"Quantity" attribute

  • Key: BPMN11-44
  • Legacy Issue Number: 9901
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    Currently, there is a Quantity attribute on Sequence Flows. Does it belong
    there or should it instead be on the Activity?

  • Reported: BPMN 1.0b1 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

"StartQuantity" attribute

  • Key: BPMN11-43
  • Legacy Issue Number: 9900
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    The "StartQuantity" attribute, as it's currently defined on page 50, needs
    revisiting. What happens if an Activity has multiple incoming sequence
    flows? Should the StartQuantity instead consist of a list of numbers, each
    of which is correlated in some way with a particular sequence flow?

  • Reported: BPMN 1.0b1 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Independent Subprocess

  • Key: BPMN11-40
  • Legacy Issue Number: 9895
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    The term "Independent Subprocess" doesn't fully convey the intent of this
    construct. Suggest it be renamed to "Reusable Subprocess".

  • Reported: BPMN 1.0b1 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

IORules attribute

  • Key: BPMN11-39
  • Legacy Issue Number: 9894
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    The IORules attribute on Activity is of type Expression. Shouldn't it be a
    Rule?

  • Reported: BPMN 1.0b1 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

Optional Start/End Events

  • Key: BPMN11-47
  • Legacy Issue Number: 9904
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    A Start or End Event should only be optional if it has no Trigger or
    Result

  • Reported: BPMN 1.0b1 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

"Exception" trigger

  • Key: BPMN11-48
  • Legacy Issue Number: 9906
  • Status: closed  
  • Source: International Business Machines ( Suzette Samoojh)
  • Summary:

    Page 47 refers to an "Exception" trigger. Should be renamed to "Error".

  • Reported: BPMN 1.0b1 — Thu, 6 Jul 2006 04:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    see above

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

For DI: All graphical elements should have a Semantic Counterpart

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

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

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

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

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

Review the use of RFC2119 keywords

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

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

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

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

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

Rename "Call" Elements

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

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

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

    Reason:

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

XML Schema is not strict enough

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

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

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

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

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

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

Missing loopCharacteristics for Choreography stuff in MM

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

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

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

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

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

Figure 12-21, Sub-process marker missing

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

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

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

    Add the + marker to Figure 12.21
    Disposition: Resolved

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

Mismatch in DataAssociation definition between spec and XSD

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

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

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

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

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

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

Receive Task is not mentioned as an instantiating element

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

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

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

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

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

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

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

Merge Collaboration and Choreography in Metamodel

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

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

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

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

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

Missing in XML example

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

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

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

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

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

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

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

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

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

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

Missing label of a compensation activity

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

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

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

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

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

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

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

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

Missing marker in Compensation Activity

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

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

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

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

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

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

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

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

Process Model and Model Description are not consistent

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

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

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

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

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

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

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

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

Allow referencing scripts instead of enfocing inline specification

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

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

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

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

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

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

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

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

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

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

How to reference particular instances of Data Objects that are Collections

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

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

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

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

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

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

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

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

Choreography should be a Sub-Class of Collaboration

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

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

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

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

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

Additional participants in called/subconversation

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

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

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

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

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

Hexagons and message flow linked to activities

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

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

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

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

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

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

  • Key: BPMN2-260
  • Legacy Issue Number: 15064
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

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

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

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

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

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

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

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

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

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

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

Correlation on message flow and choreography activities

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

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

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

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

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

Label call conversation links

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

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

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

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

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

LaneSet should have an optional ‘name’ attribute

  • Key: BPMN2-257
  • Legacy Issue Number: 15061
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

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

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

    So for example Figure 10.121 would have Supplier: By Department

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

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

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

Simplify Use of Callable Elements

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

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

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

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

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

No way to identify the format of Documentation and TextAnnotation connect

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

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

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

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

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

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

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

Extending via inheritancy is problematic using the BPMN xsd format

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

    Extending via inheritancy is problematic using the BPMN xsd format.

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

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

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

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

How to represent Process Diagrams and Lanes?

  • Key: BPMN2-259
  • Legacy Issue Number: 15063
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

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

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

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

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

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

Figure 10.121 mis-described

  • Key: BPMN2-258
  • Legacy Issue Number: 15062
  • Status: closed  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

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

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

    In beta version 09-08-14,

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

CorrelationKey should be a concrete element

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

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

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

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

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

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

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

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

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

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

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

Add Attribute Table for Global Task

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

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

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

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

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

Incorrect attribute name used for Start Event definition

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

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

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

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

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

Contradictory/redundant handing of data and subprocesses

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

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

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

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

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

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

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

DataInputs, DataOuputs, and DataStores should be FlowElements

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

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

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

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

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

Missing definition of the participant Buyer

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

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

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

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

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

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

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

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

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

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

    <startEvent id="StartProcess"/>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Exporter Information Required for BPMN 2 files

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

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

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

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

    More specifically there is the following in the XMI spec :

    <xsd:complexType name="Documentation">

    …

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

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

    For example:

    <xmi:XMI>

    <documentation xmi:type=xmi:Documentation>

    <exporter>MagicDraw UML</exporter>

    <exporterVersion>16.8 Beta</exporterVersion>

    </documentation>

    …

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

    Proposal:

    Add to the tDefinitions xsd complexType:

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

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

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

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

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

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

Inclusive Gateway Semantics

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

    In the current semantics description of the inclusive gateway:

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

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

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

    I suggest to reword the entire sentence.

    The same applies to the semantics of the complex gateway.

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

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

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

Missing Message Flow

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

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

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

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

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

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

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

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

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

Choreography is not enforcable

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

    Figure 12.4; The Choreography model is not locally enforcable.

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

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

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

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

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

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

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

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

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

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

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

The Two Multi-Instance Markers should be reversed

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

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

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

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

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

A Collaboration should be able to reference more than one Choreography

  • Key: BPMN2-293
  • Legacy Issue Number: 15168
  • Status: closed  
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    To support SoaML modeling a Collaboration will need to be able to reference more than one Choreographies. These Choreographies would then be associated with the Conversations of the Collaboration.

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

    Section 9, Collaboration
    Change the multiplicity of Collaboration's choreographyRef model association from 0..1 to 0..*
    (a) Update Figure 9.1 to reflect this change
    Table 9.1, second row:
    (b) First column: Change "[0..1]" to "[0..*]"
    (c) Second column: change the first sentence to "The choreographyRef model association defines the Choreographies that can be shown between the Pools of the
    Collaboration."
    (d) Table 9.2, Collaboration XML Schema: change:
    "<xsd:attribute name="choreographyRef" type="xsd:QName" use="optional"/>"
    To
    "<xsd:element ref="choreographyRef " minOccurs="0" maxOccurs="unbounded"/>"
    Disposition: Resolved

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

Conversation lanes

  • Key: BPMN2-292
  • Legacy Issue Number: 15165
  • Status: closed  
  • Source: International Business Machines ( Jim Amsden)
  • Summary:

    Lanes representing conversations should require activities in those
    lanes to send or receive message flows in the conversation.

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

    The resolution assumes the resolution of 14654.
    In the Collaborations chapter, Conversations section, at the end of the
    Conversation Link subsection, add the paragraph
    When a lane represents a conversation, the flow elements in the lane
    (or elements nested or called in them) that send or receive messages
    must do so as part of the conversation represented by the lane.
    Disposition: Resolved

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

BPMN CMOF File problems

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

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

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

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

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

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

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

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

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

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

Mutiple depictions of a single semantic element

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

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

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

    Maybe the same could be explored for DataObjects

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

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

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

Depictable element without a reference semantic element