Business Process Model And Notation Avatar
  1. OMG Specification

Business Process Model And Notation — Closed Issues

  • Acronym: BPMN
  • Issues Count: 301
  • 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
BPMN2-301 Text User Task instead of Manual Task BPMN 2.0 BPMN 2.0.1 Resolved closed
BPMN2-300 Page 345. “Sub-Choreographies” instead of “Choreography Activities” BPMN 2.0 BPMN 2.0.1 Resolved closed
BPMN2-299 None Events not for catch Intermediate Event BPMN 2.0 BPMN 2.0.1 Resolved closed
BPMN2-298 Conditional Event instead of Error Event BPMN 2.0 BPMN 2.0.1 Resolved closed
BPMN2-297 Page 181. Wrong reference to table 10.20 BPMN 2.0 BPMN 2.0.1 Resolved closed
BPMN2-296 Conflicting content regarding choreographies. BPMN 2.0b1 BPMN 2.0 Closed; No Change closed
BPMN2-295 Page 203, Table 10-26, MultiInstance Activity: What is the intended use case if the catching boudnary event is interrupt BPMN 2.0b1 BPMN 2.0 Resolved closed
BPMN2-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
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

Issues Descriptions

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

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: 88solutions ( 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: 88solutions ( 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: 88solutions ( 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: 88solutions ( 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

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

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

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

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

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

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

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

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

    The example is provided to showcase human performers.

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

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

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

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

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

    This issue is addressed by 15163
    Disposition: Duplicate

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

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

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

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

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

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

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

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

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

Confusing semantics for Terminate End Event

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

    The spec has two confusing statements for Terminate End Event:

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

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

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

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

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

Ambiguity when multiple message flows associated with a choreography task

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

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

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

    There are a couple of possible solutions:

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

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

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

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

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

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

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

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

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

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

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

Parallel Event Based Gateway capability is hidden away

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

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

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

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

    In Table 7.2 (BPMN Extended Modeling Elements):

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

Inconsistent/confusing statements around CallActivities and IOSpecifications

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Clarify "Instance of this Conversation."

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

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

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

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

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

Change plural "flow" to "flows"

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

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

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

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

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

Correlation key property values from process instances

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

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

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

Clarification of Temporal Sematics of Sequence Flow

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

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

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

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

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

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

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

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

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

Exclusive Gateway (missing sub-heading)

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

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

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

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

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

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

Need to revisit and test the process example in the spec (Figure 7-8)

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

    Need to revisit and test the process example in the spec (Figure 7-8). I'm not convinced this example 'works'.

    Some immediate concerns:

    • Process Parts does not have any data output. So I'm not sure what the conditional sequence flow out of it would evaluate against.
    • The 'artifact extensions' appear to be used like data-aware elements, but they're not really.

    I'd suggest we validate the example further.

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

    Replace Figure 7.8 with the figure shown here:
    (Figure+7-8+Proposal+2010-04-01.png)
    To address the first concern, a data output has been introduced to the sub-process 'Procure Parts', which the conditional sequence flow can now evaluate against.
    The artifact extension 'Order Folder' and the associations connected to it have been substituted by two data associations from the data objects 'Assemblies (1..n)' and
    'Invoice' to the human task 'Send Assemblies & Invoice to Customer'.
    This usage of an artifact extension is possible, but miss-leading, because it suggests that the artifact is a data object connected via data associations. However, a data
    association can only connect a data object with an activity or event, but not data objects with each other. See also page 198 (230): 'The DataAssociation class is a
    BaseElement contained by an Activity or Event, [...]'
    All remaining artifact extensions have also been removed.
    Besides this, we made some minor layout improvements that did not change the semantics.
    Disposition: Resolved

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

Service Package => Interface Package

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

    Since the term "service" isn't used anymore in the interface and
    operation model, it would be better if the Service Package were renamed,
    perhaps to Interface Package.

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

    The proposal is to close the issue with no changes to the specification. Concepts "interface" and "operation" are used to model services. There is no need to rename
    "Service Package" as term "service" is a "superordinate" concept.
    Disposition: Closed, No Change

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

Lanes and Sequence Flow

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

    As per the current spec, a Lane references FlowElements. But FlowElements include SequenceFlow, which introduces issues given that SequenceFlow can span Lanes (e.g. the source is in one Lane while the target is in another).

    Recommendation: The spec text should indicate that SequenceFlow are not included in the list of FlowElements referenced by a Lane. Tools are then responsible for presenting and laying out the SequenceFlow appropriately, based on its source and targets.

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

    Lanes will reference FlowNodes, which exclude SequenceFlows (only activities, events and gateways are FlowNodes).
    We will change the semantic metamodel to reflect this change.
    a) in Figure 10.122 - The Lane class diagram , replace FlowElement with FlowNode
    b) below Figure 10.122, replace Flow Element with FlowNodes in these sentences:

    • "Each LaneSet and its Lanes can partition the Flow Elements in a different way."
    • "a tool can use to determine the list of Flow Elements to be partitioned into this Lane"
      c) in Table 10.128 - Lane attributes and model associations
      Replace flowElementRefs with flowNodeRefs, and FlowElement with FlowNode
      d) in Table 10.132 - Lane XML Schema
      Replace flowElementRef with flowNodeRef in this snippet
      <xsd:sequence>
      <xsd:element name="partitionElement" type="tBaseElement" minOccurs="0" maxOccurs="1"/>
      <xsd:element name="flowElementRef" type="xsd:IDREF" minOccurs="0" maxOccurs="
      unbounded"/>
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Grouping message flow in Collaboration

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

    Message flow can be grouped in Choreography and Conversation, and should
    be in Collaboration also. For example, a collaboration participant
    might have a process with a call activity that send/receives many
    messages. The modeler should be able to show these as a single line
    between the activity and the other participant, as in a conversation.
    otherwise, the modeler can only show the most detailed view of the
    interaction, with every lowest level message flow in the diagram.

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

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

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

CorrelationSubscription Ownership

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

    Figure 8-18 (The Correlation Class Diagram) shows only one-way
    references away from CorrelationSubscription. What owns
    CorrelationPropertyBindings? Table 8-35 (CorrelationSubscription model
    associations) says it's a BaseElement, and that it has a Process
    attribute. The subsection on Context-based Correlation in Section 8.3.3
    (Correlation) implies it is owned by Process.

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

    > Section 8.3.3 Correlation
    Figure 8.18 - The Correlation Class Diagram
    Change metamodel
    Original
    CorrelationSubscription is contained in Common package but is not contained by any concept
    Proposal (in accordance with Table 8.35 - CorrelationSubscription model associations)
    1 Process contains n CorrelationSubscriptions. Each CorrelationSubscription is contained by exactly 1 Process. Add association from Process to
    CorrelationSubscription.
    > Section 10 Process
    Figure 10.3 - Process Details class diagram
    Change metamodel
    Original
    Process class has no association to CorrelationSubscription class.
    Proposal
    Add containment Process CorrelationSubscription: 1 Process contains n CorrelationSubscriptions.
    Table 10.1 - Process Attributes & Model Associations
    Append row: subscriptions: CorrelationSubscription [0..*]
    Original
    N/A
    Proposal
    Attribute Name
    subscriptions: CorrelationSubscription [0..*]
    Description/Usage
    Correlation Subscriptions are a feature of context-based correlation (cf. section 8.3.3). Subscriptions are used to correlate incoming messages against data in the
    Process context. A Process may several subscriptions.
    Disposition: Resolved

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

Semantic metamodel => Abstract syntax

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

    The term "semantics" is used in execution to refer to how a model is
    translated to runtime (or business) behavior, which is the technical
    meaning of the word. Metamodels, on the other hand, are a kind of
    syntax that omits some details of the pictures appearing on the screen.
    Would be better to use the term "Abstract syntax" instead of "Semantic
    metamodel" when it's necessary to distinguish it from the diagram
    metamodel.

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

    Metamodels are an abstract form of syntax that omits some aspects of
    visual (concrete) syntax. Semantics is about how a business behaves
    given a model defined with the syntax.
    Above Figure 8.2 (Class diagram showing the core packages), first
    bullet, replace "semantic modeling" with "modeling".
    Section 8.2 (Foundation), first sentence, replace "semantic model"
    with "abstract syntax model".
    Section A.1 (Changes from BPMN, v1.2), third paragraph, second bullet,
    replace "semantic model" with "abstract syntax model".
    Section 8.1 (Infrastructure), first sentence, replace "semantic models"
    with "abstract syntax models".
    Disposition: Resolved

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

Error class has no 'name' attribute

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

    For it to be usable, it needs a 'name' attribute

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

    (a) Table 8.43: Add a new attribute called "name", with description "The descriptive name of the error".
    (b) Table 8.64 (schema snippet): Update XSD snippet to add the 'name' attribute.
    <xsd:element name="error" type="tError" substitutionGroup="rootElement"/>
    <xsd:complexType name="tError">
    <xsd:complexContent>
    <xsd:extension base="tRootElement">
    <xsd:attribute name="name" type="xsd:string"/>
    <xsd:attribute name="structureRef" type="xsd:QName"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>
    (c) Figure 8.20: Replace with
    (Error+Metamodel.jpg)
    Disposition: Resolved

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

Conversation/Communication switch

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

    A number of places in the text use the word "conversation" that should
    be "communication", for example Figure 11-1 and in Section 11 (eg, A
    Conversation is set of Message exchanges (Message Flow) that share the
    same correlation).

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

    This is addressed by the resolution of 14654.
    Disposition: Duplicate

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

Choreography Subprocess => Subchoreography

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

    To avoid confusion of Choreography with Process, and to be consistent
    with naming of analogous elements in Process, it seems like Choreography
    Subprocess should be renamed to Subchoreography.

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

    Change all occurrences of "Choreography Sub-Process" to "Sub-Choreography"
    Disposition: Resolved

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

Typo in Terminate Event description

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

    See pg. 270 of spec version 0.9.13.

    The section is for the Terminate Event, but it talks about the CancelEventDefinition rather than the TerminateEventDefinition.

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

    Change CancelEventDefinition with TerminateEventDefinition in the paragraph
    Disposition: Resolved

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

MessageFlowRefs missing from Conversation metamodel diagram

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

    MessageFlowRefs missing from Conversation metamodel diagram (compare to
    Conversation attributes table).

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

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

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

Beta 1 Section 11 Conversation:

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

    Beta 1 Section 11 Conversation: The concepts of Conversation, Conversation Diagram, and Communication are too confusing. The distinctions between Conversation and Communication are not clear. It appears as though the Conversation is used for multiple concepts, including a diagram. This should be clarified.

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

    The proposal is to merge the Collaboration and Conversation diagrams.
    While the proposal is complicated it will:

    • Significantly simplify implementation by reducing the number of metamodel elements, metamodel complexity, and required text restriction
    • Provides a better alignment with another standard: SoaML
    • There would be no loss of current end-user functionality
      The Proposal includes:
      (a) Delete Chapter 11. It's contents will be moved to Chapter 9 as detailed below
      Modifications to Section 8
      (b) Section 8, page 39 (69 pdf), last paragraph: change "Choreography, Collaboration, and Conversation" to "Choreography, and Collaboration"
      (c) Figure 8.3, replace figure with new organization of Core elements (see Specification Convenience Document)
      (d) Section 8.3, page 55 (85 pdf), first sentence: change "Collaboration, Conversation, and Choreography" to "Collaboration, and Choreography"
      (f) Figure 8.8, replace figure with new organization of Artifact elements (see Specification Convenience Document)
      (g) Section 8.3.2, page 63 (93 pdf), replace first sentence with: "CallableElement is the abstract super class of all elements that have been defined outside of a Process,
      but which can be called (or reused), by a Call Activity, from within a Process."
      (h) Section 8.3.2, page 63 (93 pdf), add at the end of the first paragraph: "The BPMN elements that can be called by Call Activities (i.e., are Callable Elements) are:
      Process and GlobalTask (see Figure 8.17)."
      Figure 8.17, replace figure with new organization of Callable elements (see Specification Convenience Document)
      (j) Move Section 8.3.2 to a subsection of Section 10.2.6
      (k) Section 8.3.3, page 65 (95 pdf), change first sentence to: "The concept of Correlation facilitates the association of a Message to a Send Task or Receive Task,
      often in the context of a Conversation, which is also known as instance routing."
      (l) Section 8.3.3, page 65 (95 pdf), second sentence: change "Conversation, Choreography" to "Collaboration (Conversation), Choreography"
      (m) Figure 8.18, replace figure with new organization of Correlation elements (see Specification Convenience Document)
      Table 8.32, CorrelationKey: delete the row for the conversation attribute
      (o) Section 8.3.4, page 71 (101 pdf), replace first paragraph with "These elements are used to do mapping between two elements that both contain Conversation
      Nodes. The ConverstaqionAssociation provides the mechanism to match up the Conversation Nodes."
      (p) Section 8.3.4, page 71 (101 pdf), second paragraph, delete second sentence
      (q) Section 8.3.4, page 71 (101 pdf), replace first bullet on page with: "A Collaboration references a Choreography for inclusion between the Collaboration's Pools
      (Participants). The Conversation Nodes of the Choreography (the inner diagram) need to be mapped to the Conversation Nodes of the Collaboration (the outer
      diagram)."
      (r) Section 8.3.4, page 71 (101 pdf), delete second bullet on page
      (s) Figure 8.18, replace figure with new organization of Conversation elements (see Specification Convenience Document)
      (t) Table 8.42, page 72 (102 pdf), delete first row of table
      (u) Table 8.42, page 72 (102 pdf), replace first column of second row with: "innerConversationNodeRef: ConversationNode"
      (v) Table 8.42, page 72 (102 pdf), replace second column of second row with: "This attribute defines the Conversation Nodes of the referenced element (e.g., a
      Choreography to be used in a Collaboration) that will be mapped to the parent element (e.g., the Collaboration)."
      (w) Table 8.42, page 72 (102 pdf), replace first column of third row with: "outerConversationNodeRef: ConversationNode"
      Table 8.42, page 72 (102 pdf), replace second column of third row with: "This attribute defines the Conversation Nodes of the parent element (e.g., a
      Collaboration references a Choreography) that will be mapped to the referenced element (e.g., the Choreography)."
      Move Section 8.3.4 to Section 11 after Section 11.7. The Contents of Section 11 will be moved to Section 9 as described below.
      (z) Figure 8.24, replace figure with new organization of Flow Element Container elements (see Specification Convenience Document)
      (a2) Table 8.46: delete second row (artifacts attribute)
      (b2) Delete section 8.3.11, Interaction Specification. All Interaction Specification characters have been moved to Collaboration (Section 9 and detailed below)
      (c2) Section 8.3.14, page 87 (117 pdf), first paragraph (non-bullet): delete "(the view showing the Choreography Process Combined with Orchestration Processes)"
      from first sentence.
      (d2) Section 8.3.14, page 88 (118 pdf), first paragraph : Change "Choreography Task" to "Choreography"
      (e2) Figure 8.24, replace figure with new organization of Flow Element Container elements (see Specification Convenience Document)
      (f2) Section 8.3.14, Sub-Section Message Flow Association, page 90 (120 pdf), second paragraph: Delete second sentence
      (g2) Section 8.3.14, Sub-Section Message Flow Association, page 90 (120 pdf): Delete the second and third bullet on the page.
      (h2) Figure 8.39, replace figure with new organization of Message Flow Association elements (see Specification Convenience Document)
      (i2) Move Section 8.3.14 to Section 9 and make it Section 9.3
      (j2) Section 8.3.15, page 91 (121 pdf), second paragraph, second sentence: Change "InteractionSpecification" to "Collaboration"
      (k2) Section 8.3.15, page 91 (121 pdf), second paragraph, second sentence: Change "Collaboration, a Choreography, a Conversation, a Global Communication, or a
      GlobalChoreographyTask" to "Choreography, GlobalConversation, or GlobalChoreographyTask"
      (l2) Figure 8.40, replace figure with new organization of Participant elements (see Specification Convenience Document)
      (m2) Section 8.3.15, Sub-Section Participant Multiplicity, second paragraph: Change "Choreography" to "Collaboration"
      (n2) Section 8.3.15, Sub-Section Participant Association, second paragraph: Change "three (3)" to "four (4)"
      (o2) Section 8.3.15, Sub-Section Participant Association: replace the second bullet with the following: "A CallConversation references a Collaboration or
      GlobalConversation. Thus, the Participants of the Collaboration or GlobalConversation (the inner diagram) need to be mapped to the Participants referenced by the
      CallConversation (the outer element). Each CallConversation contains its own set of ParticipantAssociations."
      (p2) Section 8.3.15, Sub-Section Participant Association: replace the third bullet with the following: "A CallChoreography references a Choreography or
      GlobalChoreographyTask. Thus, the Participants of the Choreography or GlobalChoreographyTask (the inner diagram) need to be mapped to the Participants
      referenced by the CallChoreography (the outer element). Each CallChoreography contains its own set of ParticipantAssociations."
      (q2) Section 8.3.15, Sub-Section Participant Association: add a forth bullet with the following: "A CallActivity within a Process that has a definitional Collaboration
      references another Process that also has a definitional Collaboration. The Participants of the definitional Collaboration of the called Process (the inner diagram) need to
      be mapped to the Participants of the definitional Collaboration of the calling Process (the outer diagram)."
      (r2) Figure 8.43, replace figure with new organization of Participant Association elements (see Specification Convenience Document)
      (s2) Move Section 8.3.15 to Section 9 and make it Section 9.2.1
      (t2) Move Table 8.62 to Section 10.2.9
      (u2) Table 8.63, replace the "extension" section of the table with the following:
      "<xsd:extension base="tBaseElement">
      <xsd:sequence>
      <xsd:element name="innerConversationNodeRef" type="xsd:QName"/>
      <xsd:element name="outerConversationNodeRef" type="xsd:QName"/>
      </xsd:sequence>
      </xsd:extension>"
      (v2) Move Tables 8.63, 8.72, 8.73, 8.74, 8.75, 8.76, and 8.77 to Section 9.5 Collaboration Package XML Schemas
      Modifications to Section 7
      (w2) Section 7.1.1, Sub-Section Conversations, first paragraph, first sentence: change "The Conversation diagram is similar to a Collaboration diagram" to "The
      Conversation diagram is a particular usage of and an informal description of a Collaboration diagram"
      (x2) Section 7.1.1, Sub-Section Conversations, first paragraph, second sentence: change "Pools of a Conversation are not allowed to contain a Process and a
      Choreography is not allowed to be placed in between the Pools" to "Pools of a Conversation are usually do not contain a Process and a Choreography is usually not
      placed in between the Pools"
      (y2) Section 7.1.1, Sub-Section Conversations, second paragraph: change "Communication" to "Conversation"
      Modifications to Section 9
      (z2) Section 9, second paragraph: after the first sentence add the following sentence: "A Choreography is an extended type of Collaboration."
      (a3) Figure 9.1, replace figure with new organization of Collaboration elements (see Specification Convenience Document)
      (b3) Section 9, paragraph before Table 9.1: delete ", and InteractionSpecification (see Table 8.48)"
      (c3) Table 9.1: add row to top of table with "name: string [0..1]" in the first column and "The descriptive name of the Collaboration." in the second column.
      (d3) Table 9.1, choreographyRef attribute row: replace the second column with the following:
      "The choreographyRef model association defines a Choreography that is shown between the Pools of the Collaboration. A Choreography specifies a business contract
      (or the order in which messages will be exchanged) between interacting Participants. See page 327 for more details on Choreography.
      The participantAssociations (see below) are used to map the Participants of the Choreography to the Participants of the Collaboration.
      The MessageFlowAssociations (see below) are used to map the Message Flows of the Choreography to the Message Flows of the Collaboration.
      The ConversationAssociations (see below) are used to map the Conversations of the Choreography to the Conversations of the Collaboration.
      Note that this attribute is not applicable for Choreography or GlobalConversation which are a subtypes of Collaboration. Thus, a Choreography cannot reference
      another Choreography."
      (e3) Table 9.1: add row after ChoreographyRef attribute row with "correlationKey: CorrelationKey [0..*]" in the first column and "This association specifies
      correlationKeys used to associate Messages to a particular Collaboration." in the second column.
      (f3) Table 9.1, conversationAssociations attribute row: replace the second column with the following:
      "This attribute provides a list of mappings from the Conversations of a referenced Collaboration to the Conversations of another Collaboration. It is used when:
      • When a Choreography is referenced by a Collaboration."
      (g3) Table 9.1, conversations attribute row: replace "Conversation" with "ConversationNode"
      (h3) Table 9.1, conversations attribute row: replace the second column with the following:
      "The conversations model aggregation relationship allows a Collaboration to contain Conversation elements, in order to group Message Flow of the Collaboration and
      associate correlation information, as is required for the definitional Collaboration of a Process model. The Conversation elements will be visualized if the Collaboration
      is a Collaboration, but not for a Choreography."
      (i3) Table 9.1: add row after artifacts attribute row with "participants: Participant [0..*]" in the first column and "This provides the list of Participants that are used in the
      Collaboration. Participants are visualized as Pools in Collaboration and as Participant Bands in Choreography Activities for Choreography." in the second column.
      (j3) Table 9.1, participantAssociations attribute row: replace the second column with the following:
      "This attribute provides a list of mappings from the Participants of a referenced Collaboration to the Participants of another Collaboration. It is used in the following
      situations:
      • When a Choreography is referenced by a Collaboration.
      • When a definitional Collaboration for a Process is referenced through a CallActivity (and mapped to definitional Collaboration of the calling Process)."
      (l3) Table 9.1: add row after participantAssociations attribute row with "messageFlow: Message Flow [0..*]" in the first column and "This provides the list of Message
      Flow that are used in the Collaboration. Message Flow are visualized in Collaboration (as dashed line) and hidden in Choreography." in the second column.
      (m3) Table 9.1, messageFlowAssociations attribute row: replace the second column with the following:
      "This attribute provides a list of mappings for the Message Flow of the Collaboration to Message Flow of a referenced model. It is used in the following situations:
      • When a Choreography is referenced by a Collaboration. This allows the "wiring up" of the Collaboration Message Flow to the appropriate Choreography Activities."
      (n3) Section 9, after Table 9.1: split first paragraph into two paragraphs after the first sentence
      (o3) Section 9, after Table 9.1: replace the first sentence of the newly created paragraph (the second paragraph) with the following: "Correlations are the mechanism
      that is used to assign the Messages to the proper Process instance, and can be defined for the Message Flow that belong to a Conversation."
      (p3) Move the text from the newly created paragraph until the end of the section (stopping at Section 9.1) to a new section (to be created) and label that section "9.4.8
      Correlations"
      (q3) Section 9.2, first paragraph, first sentence: delete "or a Choreography"
      (r3) Section 9.3: Change title of section to "Process within Collaboration"
      (s3) Figure 9.8, replace figure with new organization of Choreography and Collaboration elements (see Specification Convenience Document)
      (t3) Table 9.2, Collaboration XML Schema: Change "<xsd:element ref="conversation"" to "<xsd:element ref="conversationNode""
      (u3) Table 9.2, Collaboration XML Schema: add the following to the <xsd:sequence> section:
      "<xsd:element ref="correlationKey" minOccurs="0" maxOccurs="unbounded"/>"
      Modifications to Section 10
      (v3) Figure 10.2, replace figure with new organization of Process detail elements (see Specification Convenience Document)
      (w3) Table 10.3: add row after laneSets attribute row with "artifacts: Artifact [0..*]" in the first column and "This attribute provides the list of Artifacts that are
      contained within the Process." in the second column.
      (x3) Figure 10.28, replace figure with new organization of Sub-Process elements (see Specification Convenience Document)
      (y3) Table 10.3: add row after triggeredByEvent attribute row with "artifacts: Artifact [0..*]" in the first column and "This attribute provides the list of Artifacts that are
      contained within the Sub-Process." in the second column.
      Modifications to Section 11
      (z3) Section 11: Replace "Communication" with "Conversation" throughout section
      (a4) Section 11: Replace "GlobalCommunication" with "GlobalConversation" throughout section
      (b4) Section 11: Replace "CommunicationLink" with "ConversationLink" throughout section
      (c4) Section 11: replace first paragraph with the following: "The Conversation diagram is a particular usage of and an informal description of a Collaboration diagram.
      In general, it is a simplified version of Collaboration, but Conversation diagrams do maintain all the features of a Collaboration."
      (d4)Section 11: replace first bullet in section with the following: "Conversation Node elements (Conversation, Sub-Conversation, and Call Conversation)"
      (e4) Section 11, first sentence after second bullet: replace sentence with the following: "A Conversation is a logical grouping of Message exchanges (Message Flow)
      that can share a Correlation."
      (f4) Section 11, first paragraph after Figure 11.1: add the following to the end of the paragraph: "Note that the diagram looks the same as a simple Collaboration
      diagram (as in Figure 9.3, above)."
      (g4) Section 11, second paragraph after Figure 11.2: add the following to the end of the sentence: ", but the Conversations are not visualized in a Choreography"
      (h4) Section 11, third paragraph after Figure 11.2, first sentence: replace "Choreography" with "Collaboration"
      (i4) Section 11: delete Figure 11.5 and the paragraph above it.
      (j4) Section 11: delete Table 11.1, the paragraph above it and the paragraph below it.
      (k4) Delete Section 11.1
      (l4) Section 11.2, first paragraph: replace "all elements that can appear in a Conversation diagram" with "all elements that comprise the Conversation elements of a
      Collaboration diagram"
      (m4) Section 11.2: add figure after first paragraph with the title: "Metamodel of ConversationNode Related Elements" (see Specification Convenience Document)
      (n4) Table 11.3: add row with "messageFlowRefs: MessageFlow [0..*]" in the first column and "A reference to all Message Flows (and consequently Messages)
      grouped by a Conversation element." in the second column.
      (o4) Table 11.3 : add row with "correlationKeys: CorrelationKey [0..*]" in the first column and "This is a list of the ConversationNode's correlationKeys, which are
      used to group Message Flows for the ConversationNode." in the second column.
      (p4) Section 11.3, first sentence: change "Conversation diagram" to "Conversation (Collaboration) diagram"
      (q4) Section 11.3. second sentence: replace "single" with "concept and/or a"
      (r4) Section 11.3, first paragraph before Table 11.4: Delete second sentence and add the following to the end of the first sentence: "but does not contain any additional
      attributes or model associations"
      (s4) Delete Table 11.4
      (t4) Section 11.4, first paragraph, first sentence: replace "parent Conversation" with "parent Collaboration"
      (u4) Section 11.4, first paragraph, second sentence: replace "within a Conversation" with "within a Collaboration"
      (v4) Table 11.5: replace the first column of the first row with the following: "conversationNodes: ConversationNode [0..*]"
      (w4) Table 11.5: replace the second column of the first row with the following: "The ConversationNodes model aggregation relationship allows a Sub-Conversation to
      contain other ConversationNodes, in order to group Message Flow of the Sub-Conversation and associate correlation information."
      (x4) Section 11.5, first sentence: change "in the Conversation" to " in the Conversation (Collaboration)"
      (y4) Section 11.5, second bullet: change "calls a Conversation" to "calls a Collaboration"
      (z4) Table 11.6, first row, first column: change "calledElementRef" to "calledCollaborationRef" and change "CallableElement" to "Collaboration"
      (a5) Table 11.6, first row: replace second column with the following:
      "The element to be called, which MAY be either a Collaboration or a GlobalConversation.
      The called element MUST NOT be a Choreography or a GlobalChoreographyTask (which are subtypes of Collaboration)"
      (b5) Section 11.5: add the following after Table 11.6: "Note - The ConversationNode attribute messageFlowRef doesn't apply to Call Conversations."
      (c5) Section 11.6, first sentence: Change "within any Conversation" to "within any Collaboration"
      (d5) Section 11.6: Replace the second paragraph with the following:
      "The GlobalConversation element inherits the attributes and model associations of Collaboration (see Table 8.48), but does not have any additional attributes or model
      associations.
      A GlobalConversation is a restricted type of Collaboration, it is an "empty Collaboration."
      [diamond bullet] A GlobalConversation MUST NOT contain any ConversationNodes.
      Since a GlobalConversation does not have any Flow Elements, it does not require MessageFlowAssociations, ParticipantFlowAssociations, or
      ConversationFlowAssociations or Artifacts. It is basically a set of Participants, Message Flows , and correlationKeys intended for reuse. Also, the Collaboration
      attribute choreographyRef is not applicable to GlobalConversation."
      (e5) Delete Table 11.7
      (f5) Move all tables in Section 11.8 (XML Schemas) to Section 9.5
      (g5) Move all remaining contents of Section 11 to Section 9.4 and name that section "Conversations"
      Modifications to Section 12
      (h5) Replace "Choreography Sub-Process" with "Sub-Choreography" throughout section
      (i5) Figure 12.1, replace figure with new organization of Choreography elements (see Specification Convenience Document)
      (j5) Section 12.1, first paragraph after Figure 12.1: replace "CallableElement" with "Collaboration"
      (k5) Section 12.1, first paragraph after Figure 12.1: Delete the second sentence and add the following to the end of the first sentence: ", but does not have any
      additional attributes or model associations.
      (l5) Delete Table 12.1
      (m5) Add the following paragraph to the end of the section (before Section 12.1): "Note - The Collaboration attribute choreographyRef is not applicable to
      Choreography."
      (n5) Section 12.3.1, page 313 (343 pdf), last bullet on page, first sentence: replace "the isClosed attribute of a Choreography" with "the isClosed attribute (from
      Collaboration)"
      (o5) Figure 12.6: replace figure with new organization of Choreography Activity elements (see Specification Convenience Document)
      (p5) Section 12.4.2, last paragraph in section (before Section 12.4.3): replace the second sentence with the following: "Table 12.X presents the additional model
      associations of the Sub-Choreography element"
      (q5) Section 12.4.2, after last paragraph in section: Add a table entitled "Sub-Choreography Model Associations" with one row, with "artifacts: Artifact [0..*]" in the
      first column and "This attribute provides the list of Artifacts that are contained within the Sub-Choreography." in the second column
      (r5) Replace "Call Choreography Activity" with "Call Choreography" throughout section
      (s5) Figure 12.27, replace figure with new organization of Call Choreography elements (see Specification Convenience Document)
      (t5) Table 12.4, first row, first column: change "calledElementRef" to "calledChoreographyRef" and change "CallableElement" to "Choreography"
      (u5) Table 12.4, first row, second column: delete second sentence of column
      (v5) Table 12.4, second row, second column: change "containing" to "referenced by"
      (w5) Section 12.4.4, second paragraph, first sentence: Change "CallableElement" to "Collaboration" and add the following to the end of the sentence: "through its
      relationship to Choreography"
      (x5) Section 12.4.4: add the following after Table 12.5:
      "A GlobalChoreographyTask is a restricted type of Choreography, it is an "empty Choreography."
      [diamond bullet] A GlobalChoreographyTask MUST NOT contain any Flow Elements.
      Since a GlobalChoreographyTask does not have any Flow Elements, it does not require MessageFlowAssociations, ParticipantFlowAssociations, or
      ConversationFlowAssociations or Artifacts. It is basically a set of Participants and Message Flows intended for reuse."
      (y5) Table 12.9: change "substitutionGroup="rootelement"" to "substitutionGroup="collaboration""
      (z5) Table 12.9: change "base="tCallableElement"" to "base="tCollaboration""
      (a6) Table 12.9: delete the following:
      "<xsd:element ref="artifact" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element ref="messageFlow" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element ref="participant" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element ref="conversation" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element name="conversationAssociation" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element ref="messageFlowAssociation" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element ref="participantAssociation" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:attribute name="isClosed" type="xsd:boolean" default="false"/>"
      (b6) Table 12.10: change "substitutionGroup="rootelement"" to "substitutionGroup="choreography""
      (c6) Table 12.10: change "base="tCallableElement"" to "base="tChoreography""
      (d6) Table 12.10: delete the following:
      "<xsd:sequence>
      <xsd:element ref="participant" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element ref="messageFlow" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>"
      (e6) Table 12.13: change "calledElement" to "calledChoreographyRef"
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Private process example correction

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

    The private process in Figure 10-122 (One Process supporting to another)
    should have activity X and event B in parallel, because event B may
    arrive while X is executing, which would be lost in the current example.
    See webinar example on slide 51 in bmi/09-06-02.

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

    (a) Replace Figure 10.123 (One Process supporting to another) with the one given in the attachment
    BPMNFTF-341-private-process-example.pdf.
    (b) In paragraph above Figure 10.123, next to last sentence (the one beginning "It also introduces"), replace "Activity" with "Activities".
    Disposition: Resolved

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

Multiple properties / keys clarification

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

    http://www.osoa.org/jira/browse/BPMN-585
    Does the first message in an Conversation need to have values for all
    the properties of a correlation key, or can some values appear in later
    messages?

    When a conversation has multiple correlation keys, do all the properties
    of all the keys need to match in each message, or just the properties
    for one of the keys?

    Can a message later in a conversation send values for only some of the
    properties in a key?

    Comments:
    From: conrad.bock created: Tue, 4 Aug 2009 14:15:01 -0500 (CDT)
    Conrad,

    I doubt the spec is precise enough on that yet - so here is my
    personal take on what we want it to say:

    • All properties constituting a correlation key MUST (SHOULD?) be set
      by a single message in a conversation (Rationale: We don't want a
      partially set key.)
    • Not all correlation keys of a given conversation need to be set at
      any given time. (Rationale: Conversation keys could be added over
      the lifetime of a conversation, no reason to prevent this.)
    • When associating an (inbound) message with a conversation, all
      properties of all correlation keys contained in that message must
      match those already set for the conversation (instance). (Rationale:
      We could relax that, having it strict simplifies the rules and
      increases usability; I don't see why a message would ever contain
      multiple correlation keys some of which do not match, but could be
      convinced otherwise through scenarios. Of course a message does not
      have to contain properties for all correlation keys that may be used
      for a conversation, but those that it uses must match.)

    With that the answers to your questions would be:

    • Not all must be contained, some could be delivered later - for
      those correlation happens based on the keys that were already set
      by the first message.
    • Yes, all must match - see rationale above, we could relax that if
      we see a good reason.

    Hopefully that makes sense - and hopefully I got the terminology
    right, admittedly I didn't check back with the spec but answered from
    memory.

    Viele Grüße/Kind regards,
    -Matthias

    From: conrad.bock created: Wed, 5 Aug 2009 08:40:28 -0500 (CDT)
    These clarification affects the second paragraph of the Key-based
    Correlation subsection of Section 8.3.3 (Correlation):

    At runtime the first Send Task or Receive Task in a Conversation
    populates the CorrelationKey instance by extracting the values of the
    CorrelationProperties according to the
    CorrelationPropertyRetrievalExpression from the initially sent or
    received Message. Later in the Conversation, this CorrelationKey
    instance is used for the described matching procedure where from
    incoming Messages a composite key is extracted and used to identify
    the associated Conversation.

    New keys might appear during the converstion. For example, the initial
    message from a customer placing an order might not include the order
    number. This is assigned by a new process instance and used to
    correlate messages later in the conversation.

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

    under Section 8.3.3, replace the text of the first bullet with this text:
    In plain, key-based correlation, Messages that are exchanged within a Conversation are logically correlated by means of one or more common CorrelationKeys. That
    is, any Message that is sent or received within this Conversation needs to carry the value of at least one of these CorrelationKey instances within its payload. A
    CorrelationKey basically defines a (composite) key. The first Message that is initially sent or received initializes one or more CorrelationKey instances associated with
    the Conversation, i.e., assigns values to its CorrelationProperty instances which are the fields (partial keys) of the Correlation-Key. A CorrelationKey is only
    considered valid for use, if the Message has resulted in all CorrelationProperty fields within the key being populated with a value. If a follow-up Message derives a
    CorrelationKey instance, where that CorrelationKey had previously been initialized within the Conversation, then the CorrelationKey value in the Message and
    Conversation MUST match. If the follow-up Message derives a CorrelationKey instance associated with the Conversation, that had not previously been initialized, then
    the CorrelationKey value will become associated with the Conversation. As a Conversation may comprise different Messages that may be differently structured, each
    CorrelationProperty comes with as many extraction rules (CorrelationPropertyRetrievalExpression) for the respective partial key as there are different Messages.
    under section 8.3.3 Correlation, the under the title "Key-based Correlation", replace the second paragraph with this text:
    At runtime the first Send Task or Receive Task in a Conversation MUST populate atleast one of the CorrelationKey instances by extracting the values of the
    CorrelationProperties according to the CorrelationPropertyRetrievalExpression from the initially sent or received Message. Later in the Conversation, the populated
    CorrelationKey instances are used for the described matching procedure where from incoming Messages a composite key is extracted and used to identify the
    associated Conversation. Where these non-initiating Messages derive values for CorrelationKeys, associated with the Conversation but not yet populated, then the
    derived value will be associated with the Conversation instance.
    Disposition: Resolved

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

isImmediate default

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

    isImmediate on SequenceFlow currently defaults to true for all private
    processes. It should default to false for non-executable processes,
    because these are not intended to be completely specified.

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

    In Table 8.60 (SequenceFlow attributes and model associations), isImmediate row:
    (a) Second bullet: Replace "a public Processes" with "non-executable Processes (public Processes and non-executable private Processes)"
    (b) Third bullet: Replace "an executable and non-executable (internal)" with "executable".
    In Section 10.8 (Process Instances, Unmodeled Activities, and Public Processes):
    Second bullet, replace the
    (c) Two occurrences of "processType" with "isExecutable".
    (d) First occurrence of "public" with "non-executable".
    (e) Second occurrence of "public" with "false, or defaults to false".
    (f) "private" with "executable".
    (g) "executable or non-executable" with "true, or defaults to true"
    (h) In XMI/XSD, change isImmediate attribute on SequenceFlow to be optional.
    Disposition: Resolved

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

Subprocess / CallActivity switch

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

    Section 10.4.2 (Start Event) uses the BPMN 1.x term "subprocess" to
    include called processes. In BPMN 2 "subprocess" means embedded. See
    Table 10-78 (Sub-Process Start Event Types) and under the heading "Start
    Event Triggers". Might be in other places also.

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

    (a) Section 13.2.5, Sub-Section CalledSubProcessShape, Page 383 (412 pdf): Replace the first paragraph with the following: "A Call Activity is used for invoking a
    global Process. It has the same symbol as the subprocess (embedded). Expanding the Call Activity should display the called Process."
    (b) Table 13.13 - CalledSubProcessShape , first row, second column: replace contents of column with the following: "A reference to another BPMN diagram defining
    the details of the called Global Process. "
    (c) Table 13.13 - CalledSubProcessShape styles: , first row, second column: replace contents of column with the following: "Indicates whether the Call Activity is
    expanded or collapsed."
    Section 10.4.2 Start Event
    (d) First bullet below Figure 10.67 Start Event, page 214 (244 pdf): Replace "or an expanded Sub-Process" with ", a Sub-Process (embedded), or a Global Process
    (called Process)"
    (e) First paragraph after first bullet below Figure 10.67 Start Event, page 214 (244 pdf): Replace the first sentence of the paragraph with the following: "Note - A
    Process may have more than one Process level (i.e., it can include Expanded Sub-Processes or Call Activities that call other Processes)."
    (f) Page 215 (245 pdf), First paragraph after the bullets: Replace the paragraph with the following: "If the Process is used as a Global Process (callable Process that
    can be invoke from Call Activities of other Processes) and there are multiple None Start Events, then when flow is transferred from the parent Process to the Global
    Process (child Process), only one of the Global Process's Start Events will be triggered. The TargetRef attribute of the Sequence Flow incoming to the Global Process
    object can be extended to identify the appropriate Start Event."
    Sub-Section Start Event Triggers, page 215 (245 pdf)
    (g) Second bullet: delete " and called (reusable)"
    (h) Add new bullet after second bullet with the following: "Global Processes (called)
    Sub-Section Start Events for Top-level Processes: add new paragraph after the first paragraph with the following: "A top-level that has at least one (1) None Start
    Event MAY be called by a Call Activity in another Process. The None Start Event is used for invoking the Process from the Call Activity. All other types of Start
    Events are only applicable when the Process is used as a top-level Process."
    Section 10.4.3 End Event
    (j) Page 222 (252 pdf), second bullet on page: delete "top-level" from first sentence.
    (k) Page 222 (252 pdf), first paragraph after bullets: replace first sentence of the paragraph with the following: "Note - A Process may have more than one Process
    level (i.e., it can include Expanded Sub-Processes or a Call Activities that call other Processes)."
    Disposition: Resolved

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

Processes supporting interactions

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

    When a private process supports an interaction, this currently can only
    be captured by defining a public process for the private one to support,
    and including the public process in a collaboration, with further links
    to choreographies or conversations, if those were the interaction model
    being supportted. Private processes should be able to support any of
    the interaction models directly

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

    No Data Available

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

Private process type

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

    Modelers should be able to declare a process private without committing
    to whether it is executable or non-executable. Add private as a value
    for the type attribute.

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

    (a) In Figure 10.2, 10.3, and other metamodel figures where Process appears with its attributes, insert a new attribute beneath processType: "isExecutable : Boolean".
    In Table 10.1 (Process Attributes & Model Associations), processType row, change as follows:
    left column
    (b) replace "executable | non-executable" with "private".
    right column
    (c) replace the second through fourth paragraphs (from "The BPMN 1.2 processType" through "not included in a
    non-executable Process.") with "A private process is one that is internal to a specific organization."
    insert new row below processType:
    left column
    isExecutable : Boolean [0..1]
    right column
    (d) First paragraph: "An optional Boolean value specifying whether the process is executable".
    (e) Move the current third and fourth paragraphs from the processType row to this row after the first paragraph (starting from "An
    executable Process" through "included in a non-executable Process.")
    (f) Add paragraph at end:
    "For public processes, no value has the same semantics as if the value were false. The value may not be true for public processes."
    In the following tables and rows, in the right column, replace all occurrences of "processType" with "isExecutable" and and all occurrences
    of "executable" with "true".
    (g) Table 10.3 (Activity attributes and model associations), loopCharacteristics row.
    (h) Table 10.88 (ConditionalEventDefinition model associations), condition row.
    Table 10.89 (ErrorEventDefinition attributes and model associations), errorCode row.
    (j) Table 10.90 (EscalationEventDefinition attributes and model associations), escalationCode and timeCycle rows.
    (k) Table 10.92 (MessageEventDefinition model associations), messageRef.
    (l) In Section 10.8 (Process Instances, Unmodeled Activities, and Public Processes), second bullet, next to last sentence, replace "executable or non-executable" with
    "private".
    In Table 10.129 (Process XML schema):
    (m) In tProcessType element, replace enumeration values "executable" and "non-executable" with a single value "private ".
    Add element after processType for isExecutable boolean attribute, no default: <xsd:attribute name="isExecutable" type="xsd:boolean"/>
    Disposition: Resolved

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

Complex gateway merging rule in choreography too restrictive

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

    The rule fo merging complex gateway in choreography is

    "In order to enforce the synchronizing merge of the Gateway, the
    senders or receivers Choreography Activities preceding the Gateway
    need to be the same Participant. This ensures that the merge can be
    enforced."

    but if the sender of the activity after the gateway participates in the
    activties before the gateway, and has access to the complex decision
    data, then it has everything needed to perform the synchronization.

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

    The quote in the issue is from the inclusive gateway, rather than the
    complex merge.
    In the Choreography chapter, in section Gateways, subsection Inclusive
    Gateway, under the third paragraph, first bullet, second subbullet (the
    one beginning "Merge:"), in the sentence immediately after the colon
    (the one beginning "In order to enforce"), replace the portion of the
    sentence after the comma with:
    the sender of the Choreography Activity after the Gateway must
    participate in the Choreography Activities immediately preceding the
    gateway.
    In the Choreography chapter, in section Gateways, subsection Inclusive
    Gateway, in the paragraph just above the first figure, third sentence,
    replace the portion of the sentence after the comma with:
    the initiator of Choreography Activities immediately following the
    Gateway participates in the Choreography Activities immediately
    preceding the Gateway.
    Disposition: Resolved

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

Conversation/Process switch

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

    Section 8.3.3 (Correlation), first bullet says "dispatched to this
    particular Conversation". This should describe dispatching to a process
    instance, there are no conversation instances. Another example is in
    the CorrelationKey paragraph under Figure 8-18 (The Correlation Class
    Diagram). Might be other places in the spec refering to conversations as
    if they were executed.

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

    Section 8.3.3
    > Subsection "CorrelationKey", first paragraph
    Original
    For each Message that is received within a particular Conversation, the CorrelationProperties need to provide a CorrelationPropertyRetrievalExpression which
    references a FormalExpression to the Message payload.
    Proposal
    For each Message that is exchanged as part of a particular Conversation, the CorrelationProperties need to provide a CorrelationPropertyRetrievalExpression which
    references a FormalExpression to the Message payload.
    > Subsection "Key-based Correlation", first paragraph
    Original
    Messages will be routed to the Conversation whose extracted composite key matches the respective CorrelationKey instance.
    Proposal
    Messages are associated to a particular Conversation if the composite key extracted from their payload matches the CorrelationKey initialized for this Conversation.
    Disposition: Resolved

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

Key-based Correlation => ?

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

    Key-based correlation could have a better name, because context-based
    correlation (subscription) also uses keys, it just enables values for
    process keys to change over time. Perhaps the term could be "static
    correlation", meaning the values of process properties do not change
    over time (though values and keys can be added). BTW, "context-based"
    for subscription is equally vague. How about static vs dynamic
    correlation?

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

    The terms "key-based" and "context-based" are common in the area of
    correlation, it's best to leave them as they are.
    Disposition: Closed, No Change

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

Correlation Class Diagram missing Process association

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

    Figure 8-18 (The Correlation Class Diagram) is missing the association
    between CorrelationSubscription and Process that appears in Table 8-35
    (CorrelationSubscription model associations).

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

    The resolution of this issue is covered by 14685 OMG-14685
    Disposition: Duplicate

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

Promote correlationKeys association to ConversationContainer

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

    correlationKeys is on Conversation and Subconversation in Figure 8-18
    (The Correlation Class Diagram). Promote it to ConversationContainer

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

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

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

Cardinality of the "sourceRef" association between DataAssociation and ItemAwareElement

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

    See figure 10.61. The "sourceRef" assocation.

    The cardinality on the DataAssociation end is 1. This tells me that any given DataAwareElement must be the source of exactly one DataAssociation.

    This doesn't work:

    • DataAwareElement are not required to participate in data associations.
    • Data Objects can be the source of multiple data associations.

    So the cardinality should be 0..n

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Replace Figure 10.61. See here in particular, the corrected cardinality (circled in red):
    (10583_MM_DataAssociation.jpg)
    Disposition: Resolved

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

Unclear/contradictory handling of visualized Data Inputs/Outputs

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

    The spec does not provide much clarification on how the Data Inputs/Outputs notation is used.

    As an example, consider a process that is calling another process. The called process has Data Inputs and Data Outputs.

    If I create a data association from the calling process to the Call Activity, clearly the target of that data association would be a data input of the called process.
    And yet the spec states that:

    • DataInputs MUST NOT have incoming DataAssociations.
      So, there's a contradiction here. DataAssociations do and should target DataInputs.

    Or, is that statement intended to describe visualization of the DataAssociation (i.e. the DataAssociation visually stops at the CallActivity boundary and does not visually connect to the Data Input, even if it is actually connected in the semantic model)?

    If the latter, why not allow the Data Association to connect to the Data Inputs? Doing so would result in a more explicit visualization of the underlying semantics. If I had multiple Data Inputs, I would be able to tell at a glance which Data Input is being targetted by which Data Association.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    1. Pdf pg 221, section titled "Data Inputs". Replace entire second paragraph (including sub-bullets) with the following:
    [See word doc for formatted version: 10_process-data_updatedFor317.doc]
    The Data Input is an item-aware element. Data Inputs may be visualized in a Process diagram to show the inputs to the top-level Process or to show the inputs of a
    called Process (i.e. one that is referenced by a Call Activity, where the Call Activity has been expanded to show the called Process within the context of a calling
    Process).

    • Visualized DataInputs have the same notation as DataObjects, except MUST contain a small, unfilled block arrow (see Figure 10.55).
    • DataInputs MAY have incoming DataAssociations.
    • If the Data Input is directly contained by the top-level Process, it MUST NOT be the target of Data Associations within the underlying model. Only Data
      Inputs that are contained by Activities or Events may be the target of Data Associations in the model.
    • If the Process is being called from a Call Activity, the Data Associations that target the data inputs of the Call Activity in the underlying model may be
      visualized such that they connect to the corresponding data inputs of the called Process, visually crossing the Call Activity boundary. But note that this is visualization
      only. In the underlying model, the Data Associations target the data inputs of the Call Activity and not the data inputs of the called Process.
      2. Pdf pg 223, section titled "Data Outputs". Replace entire second paragraph (including sub-bullets) with the following:
      [See word doc for formatted version: 10_process-data_updatedFor317.doc]
      The DataOutput is an item-aware element. DataOutput elements may be visualized in a Process diagram to show the outputs of the top-level Process, or to show the
      outputs of a called Process (i.e. one that is referenced by a Call Activity, where the Call Activity has been expanded to show the called Process within the context of a
      calling Process)..
    • Visualized DataOutputs have the same notation as DataObjects, except MUST contain a small, filled block arrow (see Figure 10.57).
    • DataOutputs MAY have outgoing DataAssociations.
    • If the Data Output is directly contained by the top-level Process, it MUST NOT be the source of Data Associations within the underlying model. Only Data
      Outputs that are contained by Activities or Events may be the source of Data Associations in the model.
    • If the Process is being called from a Call Activity, the Data Associations that originate from the data outputs of the Call Activity in the underlying model may
      be visualized such that they connect from the corresponding data outputs of the called Process, visually crossing the Call Activity boundary. But note that this is
      visualization only. In the underlying model, the Data Associations originate from the data outputs of the Call Activity and not the data outputs of the called Process
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Data Inputs/Outputs on Subprocesses

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

    The spec isn't clear on the relationship between visual Data Inputs/Outputs and embedded subprocesses.

    Pg 191 states that "DataInput elements may appear in a Process diagram to show the inputs the Process as a whole ...". There's a similar statement on pg. 193 for Data Outputs.

    The phrase "the Process as a whole" almost reads like visualized Data Inputs/Outputs are only applicable to Processes (and not to embedded subprocesses).

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Modify/include the following text to chapter 10.3 - "Data Input and Output", directly before Figure 10.8:
    Not every Activity type defines inputs and outputs, only Tasks, CallableElements (Global Tasks and Processes) MAY define their data requirements. Embedded
    MUST NOT define Data Inputs and Data Outputs directly, however they MAY define them indirectly via Multi Instance Loop Characteristics.
    Modify/include the following text to chapter 10.2.8 - "Multi-Instance Characteristics":
    Table 10.3 - MultiInstanceLoopCharacteristics attributes and model associations
    loopDataInputRef: ItemAwareElement [0..1]
    This ItemAwareElement is used to determine the number of Activity instances, one Activity instance per item in the collection of data stored in that ItemAwareElement
    element.
    For Tasks it is a reference to a DataInput which is part of the Activity's InputOutputSpecification.
    For Sub Processes it is a reference to a collection-valued DataObject in the context that is visible to the Sub Process.
    In order to initialize a valid multi-instance, either the loopCardinality Expression or the loopDataInput MUST be specified.
    loopDataOutputRef: ItemAwareElement [0..1]
    This ItemAwareElement specifies the collection of data, which will be produced by the multi-instance.
    For Tasks it is a reference to a DataOutput which is part of the Activity's InputOutputSpecification.
    For Sub Processes it is a reference to a collection-valued DataObject in the context that is visible to the Sub Process.
    inputDataItem: DataInput [0..1]
    A DataInput, representing for every Activity instance the single item of the collection stored in the loopDataInput. This DataInput can be the source of
    DataInputAssociation to a data input of the Activity's InputOutputSpecification. The type of this DataInput MUST the scalar of the type defined for the loopDataInput.
    outputDataItem: DataOutput [0..1]
    A DataOutput, representing for every Activity instance the single item of the collection stored in the loopDataOutput. This DataOutput can be the target of
    DataOutputAssociation to a data output of the Activity's InputOutputSpecification. The type of this DataOutput MUST the scalar of the type defined for the
    loopDataOutput.
    Table 10.37 - MultiInstanceLoopCharacteristics XML schema
    (change loopDataInput to loopDataInputRef with new type QName; change loopDataOutput to loopDataOutputRef with new type QName; change of inputDataItem
    to type tDataInput; change of outputDataItem to type tDataOutput)
    <xsd:complexType name="tMultiInstanceLoopCharacteristics">
    <xsd:complexContent>
    <xsd:extension base="tLoopCharacteristics">
    <xsd:sequence>
    <xsd:element name="loopCardinality" type="tExpression" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="loopDataInputRef" type="xsd:QName" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="loopDataOutputRef" type="xsd:QName" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="inputDataItem" type="tDataInput" minOccurs="0" maxOccurs="1"/>
    <xsd:element name="outputDataItem" type="tDataOutput" minOccurs="0" maxOccurs="1"/>
    <xsd:element ref="complexBehaviorDefinition" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element name="completionCondition" type="tExpression" minOccurs="0" maxOccurs="1"/>
    </xsd:sequence>
    <xsd:attribute name="isSequential" type="xsd:boolean" default="false"/>
    <xsd:attribute name="behavior" type="tMultiInstanceFlowCondition" default="all"/>
    <xsd:attribute name="oneBehaviorEventRef" type="xsd:QName" use="optional"/>
    <xsd:attribute name="noneBehaviorEventRef" type="xsd:QName" use="optional"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>
    Note: The attached diff from Tammo is not complete, so better use the schema above.
    Disposition: Resolved

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

Can a sub-process (embedded) have Lanes?

  • Key: BPMN2-213
  • Legacy Issue Number: 14803
  • Status: closed  
  • Source: Oracle ( Meera Srinivasan)
  • Summary:

    ##Source: Oracle (Meera Srinivasan, meera.srinivasan@oracle.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-59
    ##Original Info: (Severity: Significant - Nature: Enhancement)

    Section 10.2.5, Page 152 (page 182 in PDF)

    Can a sub-process (embedded) have Lanes? My understanding is no. Can the specification clarify this clearly?

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Move the laneSets attribute from Process to FlowElementContainer:
    (a) Table 10.1, page 124 (154 pdf): remove 4th row from table (laneSets)
    (b) Table 8.46, page 78 (108 pdf): add the following row to the table:
    laneSets: LaneSet [0..*] || This attribute defines the list of LaneSets used in the Flow Element Container (e.g., Process, Sub-Process). LaneSets are not used for
    Choreographies or Sub-Choreographies."
    (c) Section 9.2.1, page 117 (147 pdf): replace the first sentence in section with the following: "A Lane is a sub-partition within a Process (often within a Pool) or Sub-
    Process and will extend the entire length of the Process level, either vertically or horizontally."
    (d) Section 10.7, page 282 (312 pdf): replace the first sentence in section with the following: "A Lane is a sub-partition within a Process (often within a Pool) or Sub-
    Process and will extend the entire length of the Process level, either vertically (see figure XX) or horizontally (see figure XX)."
    (e) Section 10.7, page 282 (312 pdf): remove second sentence in section.
    (f) Figure 10.122, page 285 (315 pdf): replace figure to show the change in the laneSet attribute
    (g) Table 10.43, page 181 (211 pdf): add the "laneSet" element to the Sub-Process schema snippet. Also add this element to the BPMN XSD.
    Disposition: Resolved

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

Section 10.2.3 ScriptTask.scriptLanguage needs to specify format

  • Key: BPMN2-212
  • Legacy Issue Number: 14801
  • Status: closed  
  • Source: International Business Machines ( Matthias Kloppmann)
  • Summary:

    Description of issue: The scriptLanguage is currently specified to be a String, this risks clashes across different implementations. It should either be required to be an URI, or an example should suggest this to be an URI.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    1. expressionLanguage, typeLanguage
    a. Spec tables 8.1 (Definitions), 8.44 (FormalExpression)
    Add the following to the descriptions for the expressionLanguage and typeLanguage attributes: "The language must be specified in a URI format."
    There are no changes to the XSD or UML metamodel.
    2. scriptLanguage
    a. Change the name of the attribute to "scriptFormat". Applies to the XSD, UML metamodel, and spec (table 10.10).
    b. The type of the attribute will consistently be "string". Impacts the XSD only. The UML metamodel and spec currently use "string".
    c. Replace the description of the attribute in table 10.10 with: Defines the format of the script. This attribute value must be specified with a mime-type format. And it
    must be specified if a script is provided.
    d. Replace figure 10.10
    e. Update the XSD snippet in table 10.35
    Disposition: Resolved

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

Section 12.4.1 [Choreo] How many message flows per choreography task? Missing meta-model

  • Key: BPMN2-215
  • Legacy Issue Number: 14805
  • Status: closed  
  • Source: International Business Machines ( Matthias Kloppmann)
  • Summary:

    Description of issue: The text reads "A choreography task ... represents a coherent set of Message exchanges." Neither "coherent" nor "set" is further detailed, nor is a schema shown that clarifies the relationship between Choreography Task and Message Flow.

    Proposal: Provide further explanation of "coherent set", and provide meta-model for Choreography Task.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

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

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

Section 8.3.15 [Choreo] ParticipantMultiplicity must allow to specify 1..2, possibly also 0..1

  • Key: BPMN2-214
  • Legacy Issue Number: 14804
  • Status: closed  
  • Source: International Business Machines ( Matthias Kloppmann)
  • Summary:

    Description of issue: The attributes minimum and maximum are mandated to have a min value of 2. Why would multiplicities such as 1..2 be excluded? Couldn't there even be optional participants?

    Proposal: At the very least, the minimum attribute should allowed to have a minimum of 1. Possibly, minimum should be allowed to start at 0, and maximum at 1.

    Comments:
    From: wstephe created: Fri, 11 Sep 2009 13:19:42 -0500 (CDT)
    The section, table, and page numbers were updated to match the Beta 1 Spec.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    8.3.15 Participants
    p94
    "When the minimum attribute of the ParticipantMultiplicty element has been set by the modeler, then the multiinstance
    marker will be displayed in bottom center of the Pool (Participant - see Figure 8-41) or the Participant Band
    of a Choreography Activity (see page 356)."
    change to:
    "The multi-instance marker will be displayed in bottom center of the Pool (Participant - see Figure 8-41), or the Participant Band of a Choreography Activity (see page
    356), when the ParticipantMultiplicity is associated with the Participant, and the maximum attribute is either not set, or has a value of two (2) or more."
    Table 8.56 ParticipantMultiplicity attributes
    Change from "minimum: integer [0..1] = 2" to "minimum: integer = 0" - mandatory with default value of 0
    with suitable update to schema.
    "The minimum attribute defines minimum number of Participants that
    MUST be involved in the Collaboration. The value of minimum MUST be
    two (2) or greater."
    change to:
    "The minimum attribute defines minimum number of Participants that
    MUST be involved in the Collaboration. If a value is specified in the
    maximum attribute, it MUST be greater or equal to this minimum value."
    Change from "maximum: integer [0..1] = 2" to "maximum: integer [0..1] = 1" - optional with default value of 1.
    "The maximum attribute defines maximum number of Participants that
    MAY be involved in the Collaboration. The value of maximum MUST be
    two (2) or greater."
    change to:
    "The maximum attribute defines maximum number of Participants that
    MAY be involved in the Collaboration. The value of maximum MUST be
    one (1) or greater, AND must be equal or greater than the minimum value."
    Disposition: Resolved

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

Section 10.5.1/10.5.6 Need to clarify how initiating gateway is specifed: via sequence flow, attribute, or both

  • Key: BPMN2-211
  • Legacy Issue Number: 14799
  • Status: closed  
  • Source: International Business Machines ( Matthias Kloppmann)
  • Summary:

    Description of issue: Section 8.4.1 states that a gateway's behavior is performed at instantiation time of the process if there is a gateway with no incoming sequence flow (top of p. 126). However, section 8.4.6 introduces an "instantiate" flag for Event-base Gateways, which seems to have the exact same purpose (table 8-85 on p. 128). These two ways of tying process instantiation and gateway execution together need to be reconciled.

    Proposal: Preferably, get rid of the instantiate flag and allow the behavior described in 8.4.1 for all gateways, including the event-based gateway. Alternatively, introduce an instantiate flag for all gateways (or for those where it makes sense), and describe the relationship between no incoming sequence flow and the flag.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Section 10.2.3, Sub-Section Receive Tasks, page 139 (169 pdf):
    (a) delete the three bullets on page.
    (b) Third paragraph: replace the second sentence of the paragraph with the following: "In order for the Task to instantiate the Process its instantiate attribute must be set
    to true and it must not have any incoming Sequence Flow."
    (c) Last paragraph on page: add the following to the paragraph: "If the instantiate attribute is set to true, the envelope marker looks like a Message Start Event (as
    shown in Figure 10.X)."
    (d) Add new figure after Figure 10.15 that shows the instantiate version of the Receive Task (see
    (10698_New+Icon+for+Instantiating+Receive+Task.jpg)
    ), which is a Task with a marker that looks like a small Message Start Event.
    (e) The new Figure will have the following caption: "A Receive Task Object that instantiates a Process"
    (f) Table 10.10, second row, second column: delete "after the Start Event or a starting Task if there is no Start Event"
    Section 10.5.6:
    (g) Delete the first three bullets after Figure 10.114
    (h) First paragraph after Figure 10.114: replace "meet one of the following conditions:' with "not have any incoming Sequence Flow."
    Section 14.1, Second paragraph, First sentence:
    Replace "Event-Based Gateway" with "Event-Based Gateway or a Receive Task"
    (j) Replace "Instantiate flag is true" with "instantiate flag set to true"
    (k) Section 14.2.3, Bullet for Receive Task: Add the following to the bullet: "If the Receive Task's instantiate attribute is set to true, the Receive Task itself can start a
    new Process instance."
    Disposition: Resolved

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

Formalizing the Source-Target relationships between Link Intermediate Event

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

    Currently, there is no formalized way to relate Throw Link Events with their corresponding Catch Link Event(s). The spec briefly mentions that their names must be the same, but names are unreliable.

    • There is no constraint on names, so I could create multiple Catch Link Events with the same name, thus breaking the model.
    • Names are not used, in general throughout the spec, for formalizing relationships. Instead IDs are.
    • Users do sometimes assign different names to the Throw and Catch (for example "A" for the throw and "from A" for the catch).

    Recommendation: Add an explicit assocation from the Throw Link Event to the Catch Link Event

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Add a new bidirectional association to the LinkEventDefinition.
    (Updated+Link+Event+Metamodel.jpg)
    If the LinkEventDefinition represents a 'throw' or 'source' link event, it will reference 1 LinkEventDefinitions representing the corresponding 'catch' or 'target' link event.
    If the LinkEventDefinition represents a 'catch' or 'target' link event, it will reference 1 or more LinkEventDefinitions representing the corresponding 'throw' or 'source'
    link events.
    Spec updates:
    (a) - Update Figure 10.70 to add new bidirectional association to the LinkEventDefinition class:
    (Updated+Link+Event+Metamodel.jpg)

    • Add two new associations to Table 10.91:
      (b) sources: Used to reference the corresponding 'catch' or 'target' LinkEventDefinitions, when this LinkEventDefinition represents a 'throw' or 'source'
      LinkEventDefinition.
      (c) target: Used to reference the corresponding 'throw' or 'source' LinkEventDefinition, when this LinkEventDefinition represents a 'catch' or 'target'
      LinkEventDefinition.
      Corresponding additions will be made to the BPMN XSD.
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Allow Choreographies within a Conversation Diagram

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

    Currently, Choreographies are not allowed between the Pools of a Conversation diagram. However, this capability would be very useful for some modeling problems, such as the linking of BPMN diagrams to SoaML

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

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

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

General [Metamodel] Double-check attributes that are enumerated types, and their extensibility needs

  • Key: BPMN2-210
  • Legacy Issue Number: 14798
  • Status: closed  
  • Source: International Business Machines ( Matthias Kloppmann)
  • Summary:

    Description of issue: The meta-model contains attributes that are conceptually enumerated types. Sometimes their set of values needs to be extensible, sometimes their set of values is closed within the scope of the spec. The spec needs a consistent approach for both types of enums.

    Proposal: Presumably, enums with a closed list should be defined as enums in the metamodel, while enums that are extensible should be defined as string. Better ways to render this may exist. The outcome of the decision must be applied consistently throughout the spec

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The FTF has reviewed the list of attributes through the resolution of multiple issues. No further work is required on this topic.
    Disposition: Closed, No Change

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

Section 9.2: Pool description needs revisiting

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

    Description of issue: Page 114 (144 in PDF) states that a "Pool acts as the container for a Process". This is not true. Pools simply reference Processes.

    Proposal: Rewording to something like: A Pool may have internal details, in the form of the Process that will be executed. Or a Pool may have no internal details, i.e., it can be a "black box".

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    1) in Page 22 Table 7.1 BPMN Modeling Elements
    Original Text
    A Pool is the graphical representation of a Participant in a Collaboration (see page 146). It is also acts as a "swimlane" and a graphical container for partitioning a set of
    Activities from other Pools, usually in the context of B2B situations.
    Append the following to the original text
    A Pool may have internal details, in the form of the Process that will be executed. Or a Pool may have no internal details, i.e., it can be a "black box".
    (2) in Page 144 Section 9.2 - Pool and Participant
    Replace the following text:
    Graphically, a Pool is a container for partitioning a Process from other Pools
    with this:
    A Pool may or may not reference a Process.
    Disposition: Resolved

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

Data Inputs the target of multiple Data Associations

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

    Can a single Data Input be the target of multiple Data Associations? The spec does not explicitly disallow this.

    What would be the outcome of executing this model - would the last data association defined always overwrite the results of executing prior ones?

    Is there a use-case or scenario where this produces meaning results, or should this pattern be disallowed?

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Add the following paragraph after the last paragraph in Section 10.3.2 Execution Semantics for Data
    Once an InputSet becomes "available", all DataAssociations whose target is any of the DataInputs of the InputSet are executed. These executions fill the Activity
    DataInputs and the execution of the Activity can begin.
    When an Activity finishes execution, all DataAssociations whose sources are any of the DataOutputs of the OutputSet are executed. These executions copy the values
    from the DataOutputs back to the container's context (DataObjects, Properties, etc).
    Execution Semantics for DataAssociation
    The execution of any DataAssociation must follow these semantics:
    a) If the DataAssociation specifies a "transformation" Expression, this expression is evaluated and the result is copied to the targetRef. This operation replaces
    completely the previous value of the targetRef element.
    b) For each "assignment" element specified:
    ) Evaluate the Assignment's "from" expression and obtain the *source value
    ) Evaluate the Assignment's "to" expression and obtain the *target element. The target element can be any element in the context or a sub-element of it (e.g. a
    DataObject or a sub-element of it).
    ) Copy the *source value to the target element.
    c) If no "transformation" Expression nor any "assignment" elements are defined in the DataAssociation:
    *) copy the DataAssociation "sourceRef" value into the "targetRef". Only one sourceRef element is allowed in this case.

    Add the following sentence in Section 14.2.2 Activity, at the end of the bullet that starts with "When some data InputSet becomes available,"
    Please refer to section 10.3.2 for a description of the execution semantics for DataAssociations.
    "
    Disposition: Resolved

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

Default execution semantics for an activity with multiple incoming branches needs to be clarified

  • Key: BPMN2-208
  • Legacy Issue Number: 14795
  • Status: closed  
  • Source: Oracle ( Vishal Saxena)
  • Summary:

    The current execution semantics apparently implies that the said activity with two incoming connections will be executed twice. Instead it should be a merge semantics that is the activity is executed once when token arrives on both branches.

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The proposal in the issue description is in conflict with start events on the boundary of a sub-process as explained above and also conflicts compatibility with BPMN
    1.1. Thus, we propose to close with no change.
    Disposition: Closed, No Change

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

Are Conditional Start Events executable?

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

    Are ConditionalStartEvents executable? What data are they able to access?

    Note that the spec states that executable ConditionalStartEvents must have a FormalExpression. So the spec implies they are executable. But it doesn't provide guidance on what data context would be provided for that FormalExpression.

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

    Section 10.4.2 Start Event
    Table 10.3 - Top-Level Process Start Event Types
    Change row: Conditional
    Original (Description column)
    This type of event is triggered when a Condition such as "S&P 500 changes by more than 10% since opening", or "Temperature above 300C" become true. The
    Condition Expression for the Event must become false and then true before the Event can be triggered again.
    If there is only one (1) EventDefinition associated with the Start Event and that EventDefinition is of the subclass ConditionalEventDefinition, then the Event is a
    Conditional Start Event and MUST be displayed with a lined paper marker (see the figure to the right).
    Proposal (Description column)
    This type of event is triggered when a Condition such as "S&P 500 changes by more than 10% since opening", or "Temperature above 300C" become true. The
    Condition Expression for the Event must become false and then true before the Event can be triggered again.
    The Condition Expression of a Conditional Start Event MUST NOT refer to the data context or instance attribute of the process (as the Process instance has not yet
    been created). Instead, it may refer to static process attributes and states of entities in the environment. The specification of mechanisms to access such states is out of
    scope of the standard.
    If there is only one (1) EventDefinition associated with the Start Event and that EventDefinition is of the subclass ConditionalEventDefinition, then the Event is a
    Conditional Start Event and MUST be displayed with a lined paper marker (see the figure to the right).
    Disposition: Resolved

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

Contradiction in constraint for Start Events in Event Subprocess

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

    Apparent contradiction, assuming I'm reading the constraint right.

    The spec states that "An Event Sub-Process MUST have a single Start Event". I interpret this to mean exactly one.
    And yet the spec allows a Start Event with a Multiple or Parallel Multiple event definition. These are short-hand for multiple Start Events, each with a single event definition. Hence a contradiction in functionality and intent.

    Recommend updating the spec constraint to state "An Event Sub-Process MUST have at least one Start Event".

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

    This is not a problem with the specification, so we close with no change
    Disposition: Closed, No Change

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

Error vs ErrorCode & Escalation vs EscalationCode

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

    The ErrorEventDefinition contains an errorCode and references an Error class. Wouldn't it make sense for errorCode to be moved into the Error class. I'd expect that all usages of that Error class would specify the same errorCode.

    Same pattern is there for Escalation.

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

    (a) Insert new subsection, under 8.3, for Escalation.
    An Escalation identifies a business situation that a process may need to react to.
    Insert Figure
    (Escalation_MM.jpg)
    The Escalation element inherits the attributes and model associations of Base Element through its relationship to RootElement.
    New table, with attributes
    name: The descriptive name of the escalation
    structureRef: An ItemDefinition that defines the payload of the escalation
    (b) Move the "errorCode" attribute from Table 10.89 to Table 8.43
    (c) Move the "escalationCode" attribute from Table 10.90 to new table for Escalation
    (d) Replace Figure 8.20 with
    (Error_MM.jpg)
    (e) Replace Figure 10.70 with
    (EventDefinitions_MM.jpg)
    (f) Replace Figure 10.75 with
    (ErrorEventDefinition_MM.jpg)
    (g) Replace Figure 10.77 with
    (EscalationEventDefinition_MM.jpg)
    (h) Table 8.64 (schema snippet): Updated XSD snippet to add the errorCode attribute to tError
    <xsd:element name="error" type="tError" substitutionGroup="rootElement"/>
    <xsd:complexType name="tError">
    <xsd:complexContent>
    <xsd:extension base="tRootElement">
    <xsd:attribute name="name" type="xsd:string"/>
    <xsd:attribute name="structureRef" type="xsd:QName"/>
    <xsd:attribute name="errorCode" type="xsd:string"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>
    New table under 8.3.18, for the Escalation schema snippet
    <xsd:element name="escalation" type="tEscalation" substitutionGroup="rootElement"/>
    <xsd:complexType name="tEscalation">
    <xsd:complexContent>
    <xsd:extension base="tRootElement">
    <xsd:attribute name="name" type="xsd:string"/>
    <xsd:attribute name="structureRef" type="xsd:QName"/>
    <xsd:attribute name="escalationCode" type="xsd:string"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>
    (j) Table 10.101: Updated XSD snippet to remove the errorCode attribute from tErrorEventDefinition
    <xsd:element name="errorEventDefinition" type="tErrorEventDefinition" substitutionGroup="eventDefinition"/>
    <xsd:complexType name="tErrorEventDefinition">
    <xsd:complexContent>
    <xsd:extension base="tEventDefinition">
    <xsd:attribute name="errorRef" type="xsd:QName"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>
    (k) New table under 10.4.8, for the EscalationEventDefinition schema snippet
    <xsd:element name="escalationEventDefinition" type="tEscalationEventDefinition" substitutionGroup="eventDefinition"/>
    <xsd:complexType name="tEscalationEventDefinition">
    <xsd:complexContent>
    <xsd:extension base="tEventDefinition">
    <xsd:attribute name="escalationRef" type="xsd:QName"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>
    Disposition: Resolved

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

Choreography Complex Gateway example

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

    Section 12.6.5 (Complex Gateway) has a figure that doesn't match the
    text example

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

    (a) Exchange Figure 12.48 with the diagram depicted here:
    (Compex+Gateway+in+Choreography+%28Choreography%29+Proposal+2010-04-20.png)
    (b) Exchange Figure 12.49 with the diagram depicted here:
    (Compex+Gateway+in+Choreography+%28Collaboration%29+Proposal+2010-04-20.png)
    (c) Section 12.7.5: Exchange the second paragraph:
    "Consider an e-tender which sends a request for quote to service providers (e.g., warehouse storage) in a marketplace. The e-tender Process sends out each request
    and anticipates a response through two Choreography Activities with a sequential flow between these. The request-response branches merge at a Complex Gateway to
    model the requirement that when 60% responses have arrived, an assessment of the tender can proceed. The assessment occurs after the Complex Gateway. If the
    assessment reports that the reserve amount indicated by the customer cannot be met, a new iteration of the tender is made. All up a maximum of 3 tenders is run. A key
    issue is to ensure that the responses should not be mixed across tender iterations."
    with the following text:
    "Consider an e-tender which sends a request for quote to multiple service providers (e.g., warehouse storage) in a marketplace. The e-tender Process sends out
    requests to each service provider and anticipates their response through three Choreography Activities. The response branches merge at a Complex Gateway to model
    the requirement that when 66% responses have arrived, an assessment of the tender can proceed. The assessment occurs after the Complex Gateway. If the
    assessment reports that the reserve amount indicated by the customer cannot be met, a new iteration of the tender is made. A key issue is to ensure that the responses
    should not be mixed across tender iterations. A Terminate End Event ensures that all activities are terminated, when a tender has been successful."
    Disposition: Resolved

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

Exclusive gateways in choreography cover splitting but not merging

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

    The section on exclusive gateways in choreography covers splitting but not merging gateways

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

    The resolution of this issue is covered by 14656 OMG-14656
    Disposition: Duplicate

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

Fix difference between MessageFlowNode definition in specification vs the semantic.xmi file

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

    From Mohamed Keshk (via email):

    In "Semantic.xmi" file, the only sub-classes of "MessageFlowNode" are: Task, Event, and Participant.

    While in pdf specs, page 122, first section entitled with "MessageFlowNode", first paragraph, the following is written:
    "Only the Pool/Participant, Activity, and Event elements can connect to Message Flow and thus, these elements are the only ones that are sub-classes of MessageFlowNode".

    Am I missing something here, or some changes should be made?

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

    The elements listed in the schema are correct. If a Task or Event is contained within a Sub-Process that is collapsed, then the tool will be able to derived that the
    connection should be redirected to the boundary of the Sub-Process.
    Am I missing something here, or some changes should be made?
    Disposition: Closed, No Change

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

Meaning of + symbol on Communication undefined

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

    Sections 11.4 and 11.5 don't defined the meaning of + symbol on
    Communication. I thought it meant the expansion included at least one
    communication. If this is the definition, then Figure 11-3 has a nested
    communication symbol for Delivery Negotiations, but Figure 11-4 expands
    it without a communication.

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

    The definition given by the filer appears under Figure 11.4, but it is incorrect. The plus sign only indicates the presence of a SubConversation, or CallConversation to a
    Collaboraton, as described in those sections.
    In the paragraph under Figure 11.4 (Conversational view choreographies), next to last sentence, starting with "to alert", replace the rest of the sentence with ", indicating
    a Sub-Conversation or a CallConversation calling a Collaboration."
    Disposition: Resolved

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

Mention of "isInterrupting" attribute still in the spec

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

    Spec v0.9.14.

    Section 14.4.4 (Execution Semantics) mentions the "isInterrupting" attribute. This attribute was renamed to "cancelActivity".

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

    This issue was based on an earlier draft of the specification and is no longer valid. Thus, we will close.
    Disposition: Closed, No Change

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

Incorrect description for the Transaction.protocol attribute

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

    Spec v0.9.14. Table 10-21 contains an incorrect description for the Transaction.protocol attribute.

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

    This issue is a duplicate of issue OMG 14750 (14750)
    Disposition: Duplicate

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

Section 11 Conversation: Fix Conversation figures for proper notation for Pools

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

    The figures of the Conversation show the Pools without the proper notation (as defined in <a href="http://www.osoa.org/jira/browse/BPMN-305" title="V0.5.6: Section 9 Collaboration [Choreography; Specification, Metamodel]: Pool and lane. Provide distinct shapes since their semantics are so different">BPMN-305</a>). These should be fixed. There are also two figures in the Collaboration chapter that also need fixing.

    Comments:
    From: wstephe created: Sun, 13 Sep 2009 23:14:29 -0500 (CDT)
    Version number removed from summary so that it will apply to the Beta 1 spec

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

    Close this issue as a duplicate of 14250.
    Disposition: Duplicate

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

Merge Conversation and Collaboration

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

    Conversation and Collaboration currently differ because Conversation
    messages can grouped, and Conversation can be reused. Since these
    capabilities are useful on collaboration, it would be simpler for users
    and implementers to merge these diagrams. Then there would be two
    interactions diagrams, one highlighting communication between
    participants (collaboration/conversation) and one highlighting the
    sequence of message flow (Choreography). This would be easier to
    explain and reduce the terminology complexity of the "three C models".

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

    Close this issue as a duplicate.
    The resolution of issue 14641 will resolve this issue
    Disposition: Duplicate

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

Correlation Key & Correlation Properties are missing 'name' attributes

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

    I'd think that CorrelationKey at a minimum needs a name.
    I'm not too sure that CorrelationProperty does, but give it is a RootElement, a name might be prudent.

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

    Duplicate. This issue will be resolved through the disposition of Issue 14721 (JIRA 14721).
    Disposition: Duplicate

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

isClosed on Conversation

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

    isClosed is on Collabration and Choreography, but not Conversation. It
    should be promoted to Interaction

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

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

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

Property name mismatch between Spec and Schema for Item Definition

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

    The MM and spec shows ItemDefinition with a property named "structure." The schema names this property "structureRef." These two should be synchronized. Mostly likely, the spec and MM should be changed.

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

    (a) Update the UML metamodel, renaming ItemDefinition.structure to structureRef
    Replace Figures 8.20, 8.22, 8.27, 8.34, 10.47, 10.48, 10.52, 10.53, 10.56, 10.58, 10.61, 10.70, 10.75, 10.77, 10.84, 10.89
    (b) Update Table 8.49 (pg 113)
    Rename structure to structureRef
    Disposition: Resolved

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

"isInterrupting" attribute of Start Events

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

    The "isInterrupting" attribute is introduced in the start events to deal with the possible non interrupting nature of start events in the context of Event Sub-processes. It is to be ignored for other Start Events.

    A few issues:
    In Table 10-112 on page 294. The schema snippet is missing the "isInterrupting" attribute.

    In Table 10-80 on page 251 the isInterrupting attribute has no default value whereas the semantic.xsd file does set it by default to "false"

    Should we remove the default value from the schema or should we set the "isInterrupting" attribute to "true" by default so that if that attribute is pushed in the context of a normal start event the proper depiction will be rendered. (Eventhough it should have been ignored..)

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

    (a) Table 10.80, first row, first column: add " = true"
    (b) Table 10.122, replace "<xsd:extension base="tCatchEvent"/>" with the following:
    "<xsd:extension base="tCatchEvent">
    <xsd:attribute name="isInterrupting" type="xsd:boolean" default="true"/>
    </xsd:extension>"
    (c) change the default of the isInterrupting attribute to true in the schema and metamodel
    Disposition: Resolved

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

Event marker quality is poor

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

    The markers that appear in the Beta spec are of really poor quality (they look almost hand-drawn). They have a negative impact on the overall quality of the spec.
    See table 10.86 for examples, but really is prevalent in a lot of the markers throughout the document.

    Note that the same markers in prior versions (e.g. the v0.9.14) were of much greater quality. Somehow the marker quality degraded, probably an accidental side-effect of some sort of document conversion

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

    ALL images were updated with replacements of adequate resolution, we are not including specific diagrams because most of the were updated based on the
    resolutions of other issues.
    Disposition: Resolved

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

Persistent versus transient event trigger

  • Key: BPMN2-223
  • Legacy Issue Number: 14823
  • Status: closed  
  • Source: VDMbee ( Henk de Man)
  • Summary:

    Define for intermediate messages (intermediate event trigger) if the message should be persisted in the process scope when the intermediate message is not yet active.

    (See also workflow patterns from van der Aalst; e.g. http://www.workflowpatterns.com/evaluations/standard/index.php and
    http://www.workflowpatterns.com/patterns/control/new/wcp24.php
    ).

    It relates to e.g. the following on page 226 in the BPMN 2.0 Beta 1 specification:

    “If the Event is used to “catch” the Event Trigger, then the token will remain at the Event until the Trigger occurs (e.g., the Message is received).”

    Differentiation is required between whether one wants to persist (or "defer") the trigger, or whether one wants to "lose" the trigger when the process is not yet in state to react.

  • Reported: BPMN 2.0b1 — Wed, 25 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue cannot be fixed in this FTF.
    Disposition: Closed, Out Of Scope

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

Reference ProcessRef missing in Figure 8.40 - The Participant Class Diagram

  • Key: BPMN2-232
  • Legacy Issue Number: 14863
  • Status: closed  
  • Source: SAP SE ( Rouven Day)
  • Summary:

    In the class diagram for Participant (Figure 8.40 - The Participant Class Diagram) the reference to a Process is missing.
    In the list of attributes it is available but not in the diagram.
    Since this is a very prominent reference, it should also be visible in the class diagram.

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

    Beta 1, August 2009 (pdf version)
    Make the following change in the specification: Update figure "The Participant Class Diagram" (figure 8.40 in Beta 1, draft 1) to include class "Process" and association
    (s) between the Participant and Process classes.
    This is important as table "Participant attributes and model associations" (table 8.53, in Beta 1, draft 1) defines attribute processRef, but it is not shown in figure 8.40.
    No MM and XSD updates are necessary.
    Disposition: Resolved

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

The Message element structureRef association should be renamed to itemRef

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

    The Message element has an association named "structureRef," which points to the ItemDefinition element. It should be renamed "itemRef."

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

    (a) Replace Figure 8.34 (pg 116)
    Update the UML metamodel, renaming Message.structureRef to itemRef
    (b) Update Table 8.50 (pg 116)
    Rename structureRef to itemRef
    (c) Update Table 8.71 (pg 134) - XSD snippet
    Rename structureRef to itemRef
    Disposition: Resolved

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

Execution semantics for Data Objects and Properties must be enhanced to properly describe concurrent modification situat

  • Key: BPMN2-234
  • Legacy Issue Number: 14877
  • Status: closed  
  • Source: Object Management Group ( Mariano Benitez)
  • Summary:

    Does it make sense to describe the runtime behaviour of updating DataObjects and/or Properties by different executions?

    Should we leave this up to interpretations by implementers? Should we describe the expected behaviour or multiple executions updating the same DataObject/Property. This is specially important for multi-instance activities

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

    This is considered to be an enhancement.
    Disposition: Closed, Out Of Scope

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

Does CallChoreography need a MessageFlowAssociation?

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

    Choreographies contain Message Flow. The CallChoreographyActivity will call another Choreography or a GlobalChoreographyTask, both of which have there own Message Flow. There are similar relationships to Participant. A CallChoreographyActivity has a ParticipantAssociation, so it should also have a MessageFlowAssociation or should not have the ParticipantAssociation.

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

    The Message Flow within the called Choreography will not be used or interact within the calling Choreography, so no mapping is required. Thus, there is no change
    required to the specification.
    Disposition: Closed, No Change

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

Called conversations without keys of the caller

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

    Called conversations might have messages that don't have the correlation keys of the caller. Clarify whether this is allowed or not.

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

    Called collaborations can have messages that don't have the correlation
    keys of the caller. The internal structure of messages is not specified
    in BPMN, but correlation keys applying to message flow establish
    property requirements on the contents of the message. The correlation
    keys applying to a message flow are all the keys of the containers of
    the message flow, including containers transitively through calls of
    collaborations or choreographies.
    Above Figure 8.18 (The Correlation Class Diagram) insert a new
    paragraph:
    Correlation can be applied to message flows in Collaboration and
    Choreography, as described in Chapters XXXCollaboration and
    XXXChoreography. The keys applying to a message flow are the keys of
    containers or groupings of the message flow, such as Collaborations,
    Choreographies, and Conversation Nodes, and Choreography Activities.
    This might result in multiple correlation keys applying to the same
    message flow, perhaps due to multiple layers of containment. In
    particular, calls of Collaborations and Choreographies are special
    kinds of Conversation Nodes and Choreography Activities, respectively,
    and are considered a kind of containment for the purposes of
    correlation. The correlation keys specified in the caller apply to
    message flow in a called collaboration or choreography.
    Disposition: Resolved

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

Allow Overlapping Matrix Construction of Lanes in a Diagram

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

    The spec has always described the ability to create matrix types of Lanes in diagrams. The current DI MM does not allow this.

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

    This issue is outdated given the rewrite of Chapter 13 (Diagram Interchange) under issue 14423
    Disposition: Closed, No Change

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

Order of outgoing sequence flows from exclusive gateway

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

    Metamodel does not capture order of outgoing message flows from exclusive gateway, which is needed to evaluate the conditions in order,
    per Table 14.2.

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

    Close this issue as a duplicate.
    The resolution of issue 14753 will resolve this issue
    Disposition: Duplicate

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

The description of operationRef is not accurate

  • Key: BPMN2-222
  • Legacy Issue Number: 14822
  • Status: closed  
  • Source: IBM ( Yu)
  • Summary:

    in this page, for Send Task, in Table 10.9 ­ Send Task model associations. the description of operationRef is:

    This attribute specifies the operation that is invoked by the Service Task.

    But this description is not accurate because Send task is not a Service Task. the better description may be:

    This attribute specifies the operation that the Send Task will inovke to.

    This issue also happens on the Receive Task's operationRef's description because for Receive Task, the operationRef should describe what operation the Receive task will listen on.

  • Reported: BPMN 2.0b1 — Wed, 25 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Table 10.9, page 169 (199 pdf), second row, second column: change "Service Task" to "Send Task"
    (b) Table 10.10, page 170 (200 pdf), third row, second column: change "operation that is invoked by the Receive Task" to "operation through which the Receive Task
    receives the message"
    Disposition: Resolved

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

Visibility and permissions for Data Objects and Properties must be described

  • Key: BPMN2-235
  • Legacy Issue Number: 14878
  • Status: closed  
  • Source: Object Management Group ( Mariano Benitez)
  • Summary:

    We should be clear in the spec the places/actions that can read and write on a DataObject or Property.

    For example: is it valid to update an activity property in another activity? We should be extensive in this, otherwise it will be left to vendor interpretation and this can create confusion.

    This was discussed in the BPMN 2.0 FTF in December 2009.

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

    Under section 10.3.1 Data Modeling, paragraphs name "Lifecycle and Visibility" clearly defines the visibility and permissions for Data Object and Properties.
    Hence, this issue is already answered in the specification, and no change is required.
    Disposition: Closed, No Change

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

Confusion about Performers and other roles that Resources play for Activities

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

    Should Performers be reusable--at least within a Process? How do tools add additional types of Resource/Activity Roles (e.g., overseer, manager, etc.)? Are the current extension mechanisms sufficient?
    Should Performer be a sub-class of ActivityResource or referenced by it?

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

    The ActivityResource/Performer are not reusable, the Resource element referenced by them is. This schema allows most of reuse use cases.
    So the FTF conclusion is to close with no change, since there is no change needed.
    Disposition: Closed, No Change

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

Generalize message flow

  • Key: BPMN2-203
  • Legacy Issue Number: 14785
  • Status: closed  
  • Source: Model Driven Solutions ( Cory Casanave)
  • Summary:

    The specification contains this constraint: Note that Message Flow cannot connect to objects that are within the same Pool.

    There is no reason to have this constraint and it artificially constrains the model. Many process modeling paradigms (including UML) provide for flows between activities within a process. It is common to refactor processes in which case the interactions don't change - but they may move to another pool. From a business perspective we may well have a message between activities, even if we have not delineated all the participants. The constraint should be removed. This could be acheaved by a more general treatment of interactions.

    Comments:
    From: conrad.bock created: Wed, 15 Oct 2008 09:48:03 -0500 (CDT)
    Related to <a href="http://www.osoa.org/jira/browse/BPMN-229">http://www.osoa.org/jira/browse/BPMN-229</a> (Mariano is working on it).

    From: bruce created: Fri, 5 Dec 2008 18:52:24 -0600 (CST)
    This would fundamentally change one of BPMN's core concepts, message, which currently is any type of signal exchanged between processes (pools).

    From: mariano.benitez created: Wed, 10 Jun 2009 13:36:58 -0500 (CDT)
    One way or another, we need a resolution for this problem with pools and processes.

    I personally think we should allow message flows between activities of the same process, or even between processes, but without a collaboration diagram. Collaboration diagrams seems like an overkill for me in the case of simple inter-process synchronization (private processes that add up to the big business process).

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This proposal would change basic design principles in BPMN. Hence, we do not want to fix this.
    Disposition: Closed, No Change

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

Semantics for data flow without sequence flow

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

    An activity with data flow input and no incoming sequence flows
    should be given an executable semantics. Then the modeler can focus
    on what data activities accept and provide, without the
    complications of sequencing activities. The semantics could apply
    when input data is taken only at the beginning of activity
    execution, and only from output data that is provided at the end of
    execution of a previous activity in the flow. This isn't the same
    as sequence flow with associated data, because each incoming token
    on a sequence flow "enables the activity independently" (see
    13.1.1. Sequence Flow Considerations). An inclusive merge semantics
    for multiple incoming sequence flows (as in
    <a href="http://www.osoa.org/jira/browse/BPMN-117),">http://www.osoa.org/jira/browse/BPMN-117),</a> helps, but doesn't work
    with mult-token activities or subgraphs in common cases (see
    <a href="http://www.osoa.org/jira/browse/BPMN-254)">http://www.osoa.org/jira/browse/BPMN-254)</a>.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    We propose to relax the sequence flow (SF) connection rules for activities. Any activity may or may not have incoming or outgoing SF, irrespective of the presence of
    start and end events. The semantics we propose for activities without incoming/outgoing SF is as follows:

    • each activity that does not have any incoming SF is triggered (ie receives an implicit token) upon instantiation of the containing (sub-) process
    • each activity that does not have any outgoing SF is treated as if it would be connected to an implicit undecorated end event.
      This requires the following changes to the spec document (referring to dtc/2009-08-14 ):
      in Sect. 10.2 Paragraph "Sequence Flow Connections"
    • in the sentence "If the Activity does not have an incoming Sequence Flow, and there is no Start Event for the Process, then the Activity MUST be instantiated when
      the Process is instantiated.", delete "and there is no Start Event for the Process,"
    • in the sentence "If the Activity does not have an outgoing Sequence Flow, and there is no End Event for the Process, then the Activity marks the end of one or more
      paths in the Process", delete "and there is no End Event for the Process"
      in Sect. 10.4.2 "Start event",
    • delete this:
      "If the Start Event is used, then there MUST NOT be other flow elements that do not have incoming Sequence Flow—all other Flow Objects MUST be a target of at
      least one Sequence Flow. u Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation Marker). Compensation
      Activities MUST NOT have any incoming Sequence Flow, even if there is a Start Event in the Process level. See page 314 for more information on Compensation
      Activities. u An exception to this is the Intermediate Event, which MAY be without an incoming Sequence Flow (when attached to an Activity boundary). "
      Change this:
      "If the Start Event is not used, then all Flow Objects that do not have an incoming Sequence Flow (i.e., are not a target of a Sequence Flow) SHALL be instantiated
      when the Process is instantiated. There is an assumption that there is only one implicit Start Event, meaning that all the starting Flow Objects will start at the same time.
      u Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation marker). Compensation Activities are not considered a
      part of the normal flow and MUST NOT be instantiated when the Process is instantiated. See page 314 for more information on Compensation Activities. "
      into this:
      "All Flow Objects that do not have an incoming Sequence Flow (i.e., are not a target of a Sequence Flow) SHALL be instantiated when the Process is instantiated.
      u Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation marker). Compensation Activities are not considered a
      part of the normal flow and MUST NOT be instantiated when the Process is instantiated. See page 314 for more information on Compensation Activities.
      in Sect. 10.4.3 "End event":
      Delete this:
      "If an End Event is used, then there MUST NOT be other flow elements that do not have any outgoing Sequence Flow—all other Flow Objects MUST be a source of
      at least one Sequence Flow.
      • Exceptions to this are Activities that are defined as being Compensation Activities (have the Compensation marker). Compensation Activities MUST NOT have any
      outgoing Sequence Flow, even if there is an End Event in the Process level. See page 314 for more information on Compensation Activities. "
      In this:
      "If the End Event is not used, then all Flow Objects that do not have any outgoing Sequence Flow (i.e., are not a source of a Sequence Flow) mark the end of a path in
      the Process. However, the Process MUST NOT end until all parallel paths have completed."
      delete "If the End Event is not used, then "
      in Sect. 14.2.1. "Sequence Flow Considerations"
      change this:
      "If an Activity has no incoming Sequence Flow, and there are no Start Events in the containing Process or Sub- Process, the Activity will be instantiated when the
      containing Process or Sub-Process is instantiated. Exceptions to this are Event Sub-Processes and Activities marked as Compensation Activities, as they have
      specialized instantiation behavior. "
      into this:
      "If an Activity has no incoming Sequence Flow, the Activity will be instantiated when the containing Process or Sub-Process is instantiated. Exceptions to this are
      Compensation Activities, as they have specialized instantiation behavior. "
      change this:
      "If the Activity has no outgoing Sequence Flow and there are no End Events in the containing Process or Sub- Process, the Activity will terminate and termination
      semantics for the container applied. "
      into this:
      "If the Activity has no outgoing Sequence Flow, the Activity will terminate without producing any tokens and termination semantics for the container is then applied. "
      Disposition: Resolved
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Enabling multiple events at the same time for the same message

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

    When multiple message events for the same message (payload type) are
    enabled at the same time ("executed" at the same time), can they
    receive the same transmitted message? For example, suppose a process
    has parallel gateways resulting in two message events for an Order
    message being executed at the same time. If an order message is sent
    at execution time, can it be received by both message events?

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Change text in section "14.2.3 Task":
    Current:
    Receive Task: Upon instantiation, the Receive Task begins waiting for the associated Message. When the Message arrives, the Receive Task completes.
    New:
    Receive Task: Upon instantiation, the Receive Task begins waiting for the associated Message. When a message with the right correlation information for that process
    instance arrives, the Receive Task completes. For key-based correlation, only a single receive for a given correlation key can be active, and thus the message matches
    at most one process instance. For predicate-based correlation, the message can be passed to multiple receive tasks.
    Change text in section "14.4.2 Intermediate Events"
    Current:
    For Intermediate Events, the handling consists of waiting for the Event to occur. Waiting starts when the Intermediate Event is reached. Once the Event occurs, it is
    consumed. Sequence flow leaving the Event is followed as usual.
    New:
    For Intermediate Events, the handling consists of waiting for the Event to occur. Waiting starts when the Intermediate Event is reached. Once the Event occurs, it is
    consumed. Sequence flow leaving the Event is followed as usual.
    For intermediate message catch events, the message correlation behavior is the same as for receive tasks – see section "14.2.3 Task".
    Change text in section "14.4.3 Intermediate Boundary Events"
    Current:
    For boundary Events, handling first consists of consuming the Event occurrence. If the cancelActivity attribute is set, the Activity the Event is attached to is then
    cancelled (in case of a multi-instance, all its instances are cancelled); if the attribute is not set, the Activity continues execution (only possible for Message, Signal, Timer,
    and Conditional Events, not for Error Events). Execution then follows the Sequence Flow connected to the boundary Event.
    New:
    For boundary Events, handling first consists of consuming the Event occurrence. If the cancelActivity attribute is set, the Activity the Event is attached to is then
    cancelled (in case of a multi-instance, all its instances are cancelled); if the attribute is not set, the Activity continues execution (only possible for Message, Signal, Timer,
    and Conditional Events, not for Error Events). Execution then follows the Sequence Flow connected to the boundary Event.
    For intermediate boundary message events, the message correlation behavior is the same as for receive tasks – see section "14.2.3 Task".
    Change text in section "14.4.4 Event Sub-Processes"
    Current:
    A non-interrupting Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The non-interrupting Event
    Handler may only be initiated after the parent Activity is Running. More than one non-interrupting Event Handler may be initiated and they may be initiated at different
    times. There might be multiple instances of the non-interrupting Event Handler at a time.
    New:
    A non-interrupting Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The non-interrupting Event
    Handler may only be initiated after the parent Activity is Running. More than one non-interrupting Event Handler may be initiated and they may be initiated at different
    times. There might be multiple instances of the non-interrupting Event Handler at a time.
    For Event Sub-Processes triggered via message start events, the message correlation behavior is the same as for receive tasks – see section "14.2.3 Task".
    Disposition: Resolved

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

Annex D Glossary [Specification]: Update Glossary

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

    The Glossary has been taken from V1.1 and needs to be updated.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Changes to Annex C: Glossary
    (a) Reformat the descriptions of the definitions so that the definition is not repeated in the description. For example, change the beginning of the Activity definition from:
    "An activity is a generic term for work that a company or organization performs via business processes"
    To:
    "Work that a company or organization performs using business processes."
    (b) Remove WfMC definitions from Glossary (some of these definitions will be merged with BPMN terms (see below)
    (c) Remove Workflow Pattern definitions from Glossary
    (d) "Abstract Process" Definition: change definition to "A process that represents the interactions between a private business process and another process or
    participant."
    (e) "AND-Join" Definition: Delete this topic and merge the definition with "Join" (see below)
    (f) "Join" Definition: Replace definition with the following: "A point in the Process where two or more parallel Sequence Flow paths are combined into one Sequence
    Flow path. BPMN uses a Parallel Gateway to perform a Join. Also known as "AND-Join.""
    (g) "AND-Split" Definition: Delete this topic and merge the definition with "Fork"
    (h) "Fork" Definition: Replace definition with the following: "A point in the Process where one Sequence Flow path is split into two or more paths that are run in parallel
    within the Process, allowing multiple activities to run simultaneously rather than sequentially. BPMN uses multiple outgoing Sequence Flows from Activities or Events or
    a Parallel Gateway to perform a Fork. Also known as "AND-Split."
    "Artifact" Definition: remove last two sentences.
    (j) "Association" Definition: replace definition with the following: "A connecting object that is used to link information and Artifacts with Flow Objects. An association is
    represented as a dotted graphical line with an arrowhead to represent the direction of flow."
    (k) "Business Analyst" Definition: replace the definition with "A specialist who analyzes business needs and problems, consults with users and stakeholders to identify
    opportunities for improving business return through information technology, and defines, manages, and monitors the requirements into business processes."
    (l) "Business Process" definition: replace definition with the following: "A defined set of business activities that represent the steps required to achieve a business
    objective. It includes the flow and use of information and resources."
    (m) Remove the "Business Process Definition" item.
    "Business Process Management" definition: replace definition with the following: "management (for example, process analysis, definition, processing, monitoring and
    administration), including support for human and application-level interaction. BPM tools can eliminate manual processes and automate the routing of requests between
    departments and applications."
    (o) "Choreography" definition: replace definition with the following: "An ordered sequence of message exchanges between two or more Participants. In a Choreography
    there is no central controller, responsible entity, or observer of the Process."
    (p) "Collaboration" definition: replace definition with the following: "of message exchanges between two or more Participants."
    (q) "Compensation Flow" definition: replace definition with the following: "Flow that defines the set of activities that are performed while the transaction is being rolled
    back to compensate for activities that were performed during the Normal Flow of the Process. A Compensation Flow can also be called from a Compensate End or
    Intermediate Event."
    (r) Remove the "Controlled Flow" item.
    (s) "Decision" definition: replace definition with the following: "A gateway within a business process where the Sequence Flow can take one of several alternative paths.
    Also known as "Or-Split.""
    (t) "End Event" definition: replace first sentence with: "An event that indicates where a path in the process will end."
    (u) "Event Context" definition: replace definition with the following: "An activity or group of activities in an expanded Subprocess that can be interrupted by an exception
    (such as an Error Intermediate Event)."
    (v) "Exception" definition: replace definition with the following: "An event that occurs during the performance of the Process that causes a diversion from the Normal
    Flow of the Process. Exceptions can be generated by Intermediate Events, such as time, error, or message."
    (w) "Exception Flow" definition: replace definition with the following: "A Sequence Flow path that originates from an Intermediate Event attached to the boundary of an
    activity. The Process does not traverse this path unless the Activity is interrupted by the triggering of a boundary Intermediate Event (an Exception - see above)."
    "Expanded Sub-Process" definition: replace definition with the following: "A Sub-Process that exposes its flow detail within the context of its Parent Process. An
    Expanded Sub-Process is displayed as a rounded rectangle that is enlarged to display the Flow Objects within."
    "Flow" definition: replace definition with the following: "A directional connector between elements in a Process, Collaboration, or Choreography. A Sequence Flows
    represents the sequence of Flow Objects in a Process or Choreography. A Message Flow represents the transmission of a Message between Collaboration
    Participants.The term Flow is often used to represent the overall progression of how a Process or Process segment would be performed."
    (z) "Flow Object" definition: replace definition with the following: "A graphical object that can be connected to or from a Sequence Flow. In a Process, Flow Objects
    are Events, Activities, and Gateways. In a Choreography, Flow Objects are Events, Choreography Activities, and Gateways."
    (a2) "Intermediate Event" definition: replace the definition with: "An event that occurs after a Process has been started. An Intermediate Event affects the flow of the
    process by showing where messages and delays are expected, distributing the Normal Flow through exception handling, or showing the extra flow required for
    compensation. However, an Intermediate Event does not start or directly terminate a process. An Intermediate Event is displayed as a circle, drawn with a thin double
    line."
    (b2) "Lane" definition: replace the definition with: "A partition that is used to organize and categorize activities within a Pool. A Lane extends the entire length of the Pool
    either vertically or horizontally. Lanes are often used for such things as internal roles (e.g., Manager, Associate), systems (e.g., an enterprise application), or an internal
    department (e.g., shipping, finance),"
    (c2) "Merge" definition: replace the definition with: "A point in the Process where two or more alternative Sequence Flow paths are combined into one Sequence Flow
    path. No synchronization is required because no parallel activity runs at the join point. BPMN uses multiple incoming Sequence Flows for an Activity or an Exclusive
    Gateway to perform a Merge. Also know as "OR-Join.""
    (d2) Remove "OR-Join" and merge it's definition with the "Merge" item.
    (e2) "Message" definition: replace the definition with: "An Object that depicts the contents of a communication between two Participants. A message is transmitted
    through a Message Flow and has an identity that can be used for alternative branching of a Process through the Event-Based Exclusive Gateway."
    (f2) "Message Flow" definition: replace the definition with: "A Connecting Object that shows the flow of messages between two Participants. A Message Flow is
    represented by a dashed lined."
    (g2) "Normal Flow" definition: replace the definition with: "A flow that originates from a Start Event and continues through activities on alternative and parallel paths until
    reaching an End Event."
    (h2) Remove OR-Split and merge definition with Decision
    (i2) Remove Parallel Split item
    (j2) "Participant" definition: replace last sentence in definition with: "In a Collaboration, Participants are informally known as "Pools."
    (k2) "Pool" definition: replace the definition with: "A Pool represents a Participant in a Collaboration. Graphically, a Pool is a container for partitioning a Process from
    other Pools/Participants. A Pool is not required to contain a Process, i.e., it can be a "black box." "
    (l2) "Private Business Process" definition: replace the definition with: "A process that is internal to a specific organization, generally called a workflow or BPM process."
    (m2) "Process" definition: replace the definition with: "A sequence or flow of Activities in an organization with the objective of carrying out work. In BPMN, a Process
    is depicted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and Sequence Flow that adhere to a finite execution semantics."
    (n2) "Result" definition: replace the definition with: "The consequence of reaching an End Event. Types of Results include Message, Error, Compensation, Signal, Link,
    and Multiple."
    (o2) "Start Event" definition: replace the definition with: "An Event that indicates where a particular Process starts. The Start Event starts the flow of the Process and
    does not have any incoming Sequence Flow, but can have a Trigger. The Start Event is displayed as a circle, drawn with a single thin line."
    (p2) "Sequence Flow" definition: replace the definition with: "A connecting object that shows the order in which activities are performed in a Process and is represented
    with a solid graphical line. Each Flow has only one source and only one target. A Sequence Flow can cross the boundaries between Lanes of a Pool but cannot cross
    the boundaries of a Pool."
    (r2) "Task" definition: Replace third sentence of the definition with the following: "Generally, an end-user, an application, or both will perform the Task."
    (s2) "Token" definition: replace the definition with: "A theoretical concept that is used as an aid to define the behavior of a Process that is being performed. The
    behavior of Process elements can be defined by describing how they interact with a token as it "traverses" the structure of the Process. For example, a token will pass
    through an Exclusive Gateway, but continue down only one of the Gateway's outgoing Sequence Flow."
    (t2) "Transaction" definition: in first sentence, replace "A Transaction is" with "A Sub-Process that represents"
    (u2) "Trigger" definition: replace first sentence with "A mechanism that detects an occurrence and can cause additional processing in response, such as the start of a
    business Process."
    (v2) "Uncontrolled Flow" definition: replace the definition with: "Flow that proceeds without dependencies or conditional expressions. Typically, an Uncontrolled Flow
    is a Sequence Flow between two Activities that do not have a conditional indicator (mini-diamond) or an intervening Gateway."
    Disposition: Resolved

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

Section 10.3.1 [Data-MM]: Events can contain properties but the relationship is not shown in the MM diagram

  • Key: BPMN2-200
  • Legacy Issue Number: 14781
  • Status: closed  
  • Source: Object Management Group ( Mariano Benitez)
  • Summary:

    Figure 10-53 describes the class diagram for properties, they have a containment relation with Activity and Process, but not with Events. In the spec text reads:

    • "Certain flow elements may contain properties, in particular only Processes, Activities and Events may contain Properties"

    We already agreed that events activities (throw or catch) can contain properties, so we need to add this to the MM and update the diagram

    Proposal: add relation between Properties and Events in the MM and update the diagram 10-53

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Add relation between Properties and Events in the MM and update the diagram 10-53
    Disposition: Resolved

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

Business Rule Task description doesn't describe purpose (section 10.2.3, Beta 1)

  • Key: BPMN2-199
  • Legacy Issue Number: 14780
  • Status: closed  
  • Source: International Business Machines ( Matthias Kloppmann)
  • Summary:

    Description of issue:The description of the business rule task just describes its shape, but doesn't state its purpose.

    Proposal: Add a single sentence such as "A business rule task calls a business rule and returns its result into the process."

    Comments:
    From: mkloppmann created: Tue, 14 Oct 2008 10:27:45 -0500 (CDT)
    <a href="http://www.osoa.org/jira/browse/BPMN-143" title="0.5.1. Section 10.1 [Execution semantics]: Clarify completion of tasks">BPMN-143</a> assumes the proposed resolution for <a href="http://www.osoa.org/jira/browse/BPMN-268" title="Business Rule Task description doesn't describe purpose (section 10.2.3, Beta 1)">BPMN-268</a>.

    From: bruce created: Fri, 5 Dec 2008 18:21:24 -0600 (CST)
    I propose the following tweak as more informative and more consistent w/language of business rule people:

    "A business rule task is a specific type of service task that calls a decision or ruleset on a business rule engine and returns its result to the process."

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue has been fixed before the Beta. There is a description for the BR Task in section 10.2.3 (page 141/pdf 171) and in execution semantics, section 14.2.3
    (page 393/pdf 424)
    Disposition: Closed, No Change

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

Tasks vs Global Tasks

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

    The various kinds of tasks could also be global tasks. Section
    10.2.7. Global Task says:

    There are different types of Tasks identified within BPMN to
    separate the types of inherent behavior that Tasks might
    represent. This is true for both Global Tasks and standard Tasks,
    where the list of task types is the same for both. For the sake of
    efficiency in this specification, the list task types is presented
    once on page 167.

    "Globalness" should be an attribute of Task, so the taxonomy of
    tasks does not need to be repeated.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    We do not consider making all tasks global something necessary. Besides simplicity and simetry, there is no added value to business users, since the refactoring would
    be done by tooling anyway, so they would not see a difference if the metamodel changes in one way or the other.
    We consider this issue to be part of this FTF, maybe a new RFP can handle it.
    Disposition: Closed, Out Of Scope

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

Section 8.1.5 [Infra] Import statement description is not clear enough

  • Key: BPMN2-196
  • Legacy Issue Number: 14776
  • Status: closed  
  • Source: Object Management Group ( Mariano Benitez)
  • Summary:

    The intention of the import statement is to include an ENTIRE file as a namespace, so I can reference elements defined inside that file.

    The current text says:
    "The Import class is used when referencing external element, either BPMN elements contained in other BPMN Definitions or non-BPMN elements. Imports must be explicitly defined."

    It is not clear that you are importing the entire file (ala BPEL). Also, it is not clear what is the meaning of "Imports must be explicitly defined"

    – Proposal by Mariano Benitez 23/Oct —
    Change the wording to:

    The import class is used to import elements defined externally and make them available for use by elements defined within the scope of the import element.
    The importType attribute defines the style of associated with the element. Both BPMN and non-BPMN imports are allowed.
    For example: This allows importing an XML Schema that will be used inside StructureDefinition elements, or invoking a global task defined in another file.
    Import elements can be defined globally as part of the definitions, so it is available to all elements defined in that definitions, or it can be defined inside a StructureDefinition, which restricts the scope to that element only.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Change in Table 8.2 Import Attributes, the description of the importType attribute to:
    "Identifies the type of document being imported by providing an absolute URI that identifies the encoding language used in the document.The value of the importType
    attribute MUST be set to http://www.w3.org/2001/XMLSchema when importing XML Schema 1.0 documents, to http://www.w3.org/TR/wsdl20/ when importing
    WSDL 2.0 documents, and http://schema.omg.org/spec/BPMN/2.0 when importing BPMN 2.0 documents. Other types of documents MAY be supported.
    Importing Xml Schema 1.0, WSDL 2.0 and BPMN 2.0 types MUST be supported."
    Note on 2010-04-26:
    The FTF acknowldges the proposed namespace does not follow OMG guidelines for namespace conventions. The final namespaces will be:

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

Section 2 Conformance [Specification]: Explicitly define BPMN compliance criteria, with focus on "model"

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

    Beta 1: Section 2 Conformance [Specification]: Explicitly define BPMN compliance criteria, with focus on "model" (as defined above) portability between tools.

    ##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
    ##Original Issue: http://www.osoa.org/jira/browse/BPMN-301
    ##Original Info: (Severity: Significant - Nature: Enhancement)

    This is number 4 of 12 issues submitted by Bruce Silver

    Explicitly define BPMN compliance criteria, with focus on "model" (as defined above) portability between tools. What elements and attributes MUST be supported. There can and should be multiple levels here. You don't have to certify it if you are explicit enough and connect it with #3 above. There will be no shortage of available tools that can check compliance.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close this issue as a duplicate.
    The resolution of issue 14240 will resolve this issue
    Disposition: Duplicate

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

Section 10.2.8 [Execution Semantics] Loops: Loop names misleading

  • Key: BPMN2-205
  • Legacy Issue Number: 14789
  • Status: closed  
  • Source: SAP SE ( Rouven Day)
  • Summary:

    The names "Standard Loop" and "Multi Instance Loop" are misleading. Actually both allow for creation of a desired number of Activity instances, not just Multi Instance Loops as the spec text states it. So the multiple instance characteristics is true for all loops, also Standard Loops. Thus the naming of the loop types is very misleading.

    Proposal: Go for the well known names (<a href="http://en.wikipedia.org/wiki/Control_flow#Loops">http://en.wikipedia.org/wiki/Control_flow#Loops</a>). Rename Standard Loop to Condition-controlled Loop (or Conditional Loop or Condition-based Loop). Also find a better name for Multi Instance Loop. I´ll try to post some name proposals soon.

    Comments:
    From: wstephe created: Fri, 20 Mar 2009 19:15:16 -0500 (CDT)
    The results of Issue 193 will also resolve this issue.

    From: wstephe created: Sat, 12 Sep 2009 13:45:16 -0500 (CDT)
    The section number was updated to match the Beta 1 spec.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This is not an implementation issue so the proposal is to close the issue with no changes to the specification.
    Disposition: Closed, No Change

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

Reuse of processes in orchestration and choreography

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

    Modelers should be able to define processes independently of whether
    they will be reused in processes or choreographies. Currently the
    information coming in or out of a process is either through data flow or
    through messages, I understand it. The modeler must commit to one of
    these in advance, or define two copies of the process, one with
    messages, the other with data flow. Suzette brought this up separately
    and says a solution was agreed that Mariano will write up. Didn't see
    any issue from her on this, sorry if this is a duplicate.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In section 10.3.2 Executions Semantics for Data, add the following text at the end of the section:

    In the case of Throw and Catch Events, given their nature, the execution semantics for data is different.
    When a ThrowEvent is activated, all DataInputAssociations of the event are executed, filling the DataInputs of the Event. Finally DataInputs are then copied to the
    elements thrown by the event (Messages, Signal, etc). Since there are no InputSets defined for Events, the execution will never wait.
    When a CatchEvent is activated, DataOutputs of the event are filled with the element that triggered the event. Then all DataOutputAssociations of the event are
    executed. There are no OutputSets defined for Events.
    To allow invoking a Process from both a CallActivity and via MessageFlow, the StartEvent and EndEvent support an additional case.
    In the case of a StartEvent, the DataInputs of the enclosing process are available as targets to the DataOutputAssociations of the Event. This way the Process
    DataInputs can be filled using the elements that triggered the StartEvent.
    In the case of a EndEvent, the DataOutputs of the enclosing process are available as sources to the DataInputAssociations of the Event. This way the resulting elements
    of the EndEvent can use the Process DataOutputs as sources.
    Disposition: Resolved

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

Pools multiplicity

  • Key: BPMN2-192
  • Legacy Issue Number: 14754
  • Status: closed  
  • Source: Bruce Silver Associates ( Bruce Silver)
  • Summary:

    Table 9-1 says a diagram containing pools, i.e. Collaboration, must contain 2 or more. Then is says "Note that the multiplicity of the pools model association is an open issue and may be changed in a later revision of the specification," but it is unclear whether this means the minimum of 2 pools in a diagram or relates to the MI marker on pools. If the former, I think the minimum should be 1 and it should not wait until a later revision of the sepcification. The reasons are
    1) backward compatibility with BPMN 1.1, in which all BPDs were assumed to have at least one pool, whether boundary visible or not; and
    2) ability for modelers to create diagrams with just one pool, labeled with name of the process... and be able to create schema-valid xml from it.

    Also... following fig 9-4 it says " ...the Activities that represent the work performed from the point of view of the modeler or the modeler's organization may be considered "internal" Activities and are not required to be surrounded by the boundary of their Pool...". This is only true if all the activities are part of a single process (orchestration). I think better to say, "...a single process that represents the work performed from the point of view of the modeler or the modeler's organization may be considered "internal" and is not required to be surrounded by the boundary of its Pool...".

    Comments:
    From: trickovic created: Wed, 21 Jan 2009 07:01:18 -0600 (CST)
    Bruce's comment: Second part is editorial issue. First part is MM issue.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The metamodel allows for Collaborations to have zero (0) or more Pools. Thus, it is possible to create a Collaboration with just one Pool. The statement that a
    Collaboration contains two (2) Pools is inaccurate and will be fixed.
    The statement about multiplicity of Pools being an open issue was removed from the specification prior to the completion of the Beta version.
    Section 9.2, page 116 (146 pdf), first paragraph below Figure 9.4:
    (a) Change first sentence to:
    "A Collaboration can contain at two (2) or more Pools (i.e., Participants)."
    (b) Change second sentence to:
    "However, a Process that represents the work performed from the point of view of the modeler or the modeler's organization may be considered "internal" and is not
    required to be surrounded by the boundary of the Pool, while the other Pools in the Diagram MUST have their boundary."
    Disposition: Resolved

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

[Meta-model] Exclusive gateway is missing specification of order of leaving sequence flows

  • Key: BPMN2-191
  • Legacy Issue Number: 14753
  • Status: closed  
  • Source: International Business Machines ( Matthias Kloppmann)
  • Summary:

    Type: Technical

    Description of issue: The execution semantics for exclusive gateways correctly states that "the conditions [of the outgoing sequence flows] are evaluated in order". However, the meta-model for an exclusive gateway does not allows for the specification of that order.

    Proposal: Using the "appropriate means" (prototype statement?), ensure the relationship from a FlowNode to its outgoing sequence flows is an ordered collection, rather than a set. This provides ordering not only for an exclusive gateway, but for all FlowNodes, but that doesn't seem to harm.
    In the XSD, where the sequence flows reference their source node rather than vice versa, an additional attribute or element to render the order may be needed, or the representation of sequence flow in the XSD may need to be revised.

    (Assigning to Suzette as representative of MM team who also is concerned with the XSD)

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Update Table 8.61 (pg 131)
    Append the following to the description for the 'outgoing' association: This is an ordered collection.
    The UML Metamodel used as base for XSD and XMI will be updated to reflect this change
    Disposition: Resolved

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

Diagram Interchange should align with Diagram Type Definition

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

    This summarizes a conversation with Maged, we agreed an issue should be
    filed. He said there were two approaches to diagram interchange (which
    he can explain more about). The one in the IOS submission was chosen
    for expediency and IBM will not be submitting it to the OMG's Diagram
    Type Definition RFP (DTD). The differences between the approaches is
    too much to resolve in an FTF. The IOS submission should use the same
    diagram interchange as IOS members (IBM at least) are submitting for
    DTD. Then any remaining differences between IOS and the later DTD
    adoption can be resolved in FTF.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close this issue as a duplicate.
    The resolution of issue 14423 will resolve this issue
    Disposition: Duplicate

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

Section 10.2.5: Sub-Process: Figure 10.25; Add a minus sign to the bottom of an expanded Sub-Process?

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

    The collapsed Sub-Process has a "plus" sign marker. Should the expanded Sub-Process have a "minus" sign marker. Many tools already do this.

    Comments:
    From: wstephe created: Thu, 5 Mar 2009 19:41:21 -0600 (CST)
    Given the current schedule, this issue will not be addressed in the RFP process. This issue can be reopened by the BPMN 2.0 FTF.

    From: wstephe created: Sat, 12 Sep 2009 13:35:55 -0500 (CDT)
    The Section and Figure numbers were updated to match the Beta 1 spec

  • Reported: BPMN 2.0b1 — Tue, 24 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Close; no change
    The FTF decided that the issue report does not identify a problem with this specification
    Disposition: Closed, No Change

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

Section 8.2.1 [Service Model] How to model a request-reply use case?

  • Key: BPMN2-206
  • Legacy Issue Number: 14791
  • Status: closed  
  • Source: Object Management Group ( Mariano Benitez)
  • Summary:

    In BPMN 1.1 there is no way to model a request-reply model based on a single interface operation.

    Right now we don't have a way to relate a Receive Task and Service/Reply Task that generates the response to the message received.

  • Reported: BPMN 2.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

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

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

Data flow in/out of events

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

    Data flow should work with events, rather than just send and receive
    tasks and activities. Modelers sh9uldn't need to change the model so
    much just to add data flow.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This is not a problem with the specification, so we close with no change
    Disposition: Closed, No Change

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

Beta 1: Section 10.3.1 Data Objects [Data]: Change Multiplicity of datastate attribute from 0..1 to 0..*

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

    A Data Object can have multiple states at the same time. Change Multiplicity of datastate attribute from 0..1 to 0..*

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The FTF decided this change is not required, since it implementing another way extending state multiplicity for data objects (DataObjectRefs). See 15080.
    Disposition: Closed, No Change

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

Beta 1: Is a Message a DataInput for an Activity; Is Message Flow a Data Association

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

    Is Message Flow another type of Data Association? This would mean that Messages can be mapped to the Data Inputs of Activities.
    Is there another way to use Message as an Activity Input?

    Comments:
    From: conrad.bock created: Thu, 5 Feb 2009 08:54:23 -0600 (CST)
    This would be a subtopic of <a href="http://www.osoa.org/jira/browse/BPMN-229" title="Reuse of processes in orchestration and choreography">BPMN-229</a>.

    From: ings_osoa created: Tue, 10 Mar 2009 10:32:59 -0500 (CDT)
    Steve notes that this issue may arise during our samples work and if so we can resolve it in that context. Otherwise he agrees it should be deferred.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    Formatted versions are available here:
    10_process-activities_updatedFor359_v2.doc
    10_process-data_updatedFor359_v2.doc
    10_process-events_updatedFor359_v3.doc
    14_execsem_updatedFor359_v2.doc
    (a) Replace the first paragraph after Figure 10.11 with the following:
    "The Service Task inherits the attributes and model associations of Activity (see Table 103). In addition the following constraints are introduced when the Service Task
    references an Operation: The Service Task has exactly one InputSet and at most one OutputSet. It has a single data input with an ItemDefinition equivalent to the one
    defined by the Message referenced by the inMessageRef attribute of the associated operation. If the operation defines output Messages, the Service Task has a single
    data output that has an ItemDefinition equivalent to the one defined by the Message referenced by the outMessageRef attribute of the associated operation."
    (b) Add a new paragraph immediately after Figure 10.14 with the following:
    "The Send Task inherits the attributes and model associations of Activity (see Table 10.1 ). In addition the following constraints apply when the Send Task references a
    Message: The Send Task has at most one input set and one data input. If the data input is present, it must have an ItemDefinition equivalent to the one defined by the
    associated Message. At execution time, when the Send Task is executed, the data automatically moves from the data input on the Send Task into the Message to be
    sent. If the data input is not present, the Message will not be populated with data from the process."
    (c) Add a new paragraph immediately after Figure 10.15 with the following:
    "The Receive Task inherits the attributes and model associations of Activity (see Table 10.1 ). In addition the following constraints apply when the Receive Task
    references a Message: The Receive Task must have at most one output set and at most one data output on the Receive Task. If the data output is present, it must have
    an ItemDefinition equivalent to the one defined by the associated Message. At execution time, when the Receive Task is executed, the data automatically moves from
    the Message to the data output on the Receive Task. If the data output is not present, the payload within the Message will not flow out of the task and into the
    process."
    (d) Section 10.3.1, last paragraph on page 182 (212 pdf): delete ", Messages" from the last sentence.
    (e) Table 10.52, attributes "dataInputs" and "dataOutputs": add "This is an ordered set" to their descriptions.
    (f) First paragraph after Table 10.54, change "outputs to the specific Activity implementations" to "outputs to specific Activity and Event implementations"
    (g) Section 10.3.1, Sub-Section Service Task Mapping: replace the two (2) paragraphs of the section with the following:
    "If the Service Task is associated with an Operation there must be a single data input on the Service Task and it must have an ItemDefinition equivalent to the one
    defined by the Message referred to by the inMessageRef attribute of the operation. If the operation defines output Messages, there must be a single data output and it
    must have an ItemDefinition equivalent to the one defined by Message referred to by the outMessageRef attribute of the operation."
    (h) Add a new Sub-Section after Sub-Section Service Task Mapping, with a title of "Send Task Mapping" and contents of the following:
    "If the Send Task is associated with a Message, there must be at most one input set and at most one data input on the Send Task. If the data input is present, it must
    have an ItemDefinition equivalent to the one defined by the associated Message. If the data input is not present, the Message will not be populated with data at
    execution time."
    Add a new Sub-Section after Sub-Section Service Task Mapping, with a title of "Receive Task Mapping" and contents of the following:
    "If the Receive Task is associated with a Message, there must be at most one output set and at most one data output on the Receive Task. If the data output is present,
    it must have an ItemDefinition equivalent to the one defined by the associated Message. If the data output is not present, the payload within the Message will not flow
    out of the Event and into the process."
    (j) Add a new Sub-Section after Sub-Section Script Task Mapping, with a title of "Events" and contents of the following:
    If any of the EventDefinitions for the Event is associated with an element that has an Item Definition (such as a Message, Escalation, Error, Signal), the following
    constraints apply:
    [bullet] If the Event is associated with multiple Event Definitions, there must be one data input (in the case of Throw Events) or one data output (in the case of Catch
    Events) for each Event Definition. The order of the Event Definitions and the order of the data inputs/outputs determine which input/output corresponds with which
    Event Definition.
    [bullet] For each Evant Definition and input/output pair, if the input/output is present, it must have an ItemDefinition equivalent to the one defined by the Message,
    Signal, Error or Signal on the associated Event Definition. In the case of a ThrowEvent, if the data input is not present, the Message, Escalation, Error, or Signal will not
    be populated with data. In the case of a CatchEvent, if the data output is not present, the payload within the Message, Escalation, Error, or Signal will not flow out of
    the event and into the process.
    (k) Replace Figure 10.66: ThrowEvent.dataInputs and CatchEvent.dataOutputs to have multiplicity of 0..n
    (l) Section 10.4.1, Sub-Section Data Modeling and Events: Replace the 2nd sentence of the 1st paragraph with the following:
    "For such Events, the following constraints apply:
    [bullet]If the Event is associated with multiple Event Definitions, there must be one data input (in the case of Throw Events) or one data output (in the case of Catch
    Events) for each Event Definition. The order of the Event Definitions and the order of the data inputs/outputs determine which input/output corresponds with which
    Event Definition.
    [bullet]For each Evant Definition and input/output pair, if the input/output is present, it must have an ItemDefinition equivalent to the one defined by the Message,
    Signal, Error or Signal on the associated Event Definition. In the case of a ThrowEvent, if the data input is not present, the Message, Escalation, Error, or Signal will not
    be populated with data. In the case of a CatchEvent, if the data output is not present, the payload within the Message, Escalation, Error, or Signal will not flow out of
    the event and into the process.
    The execution behavior is then as follows:
    [bullet]For Throw Events: When the event is activated, the data in the data input is automatically assigned to the Message, Signal, Escalation or Error referenced by the
    corresponding EventDefinition.
    [bullet]For Catch Events: When the trigger of the event occurs (for example, the Message is received), the data is automatically assigned to the data output that
    corresponds to the EventDefinition that described that trigger."
    (m) Section 10.4.1: Delete Sub-Section "Catch Event Data Association" and delete Sub-Section "Throw Event Data Association"
    Table 10.75, attributes "eventDefinitionRefs", "eventDefinitions", and "dataOutputs": add "This is an ordered set" to their descriptions.
    (o) Table 10.76, attributes "eventDefinitionRefs", "eventDefinitions", and "dataInputs": add "This is an ordered set" to their descriptions.
    (p) Section 14.2.3: Replace the description of the bullet for Service Task with the following: "Upon activation, the data in the inMessage of the Operation is assigned
    from the data in the data input of the Service Task, and the Operation is invoked. On completion of the service, the data in the data output of the Service Task is
    assigned from the data in the outMessage of the Operation, and the Service Task completes. If the invoked service returns a fault, that fault is treated as interrupting
    error, and the Activity fails."
    (q) Section 14.2.3: Replace the description of the bullet for Send Task with the following:
    "Upon activation, the data in the associated Message is assigned from the data in the data input of the Send Task. The Message is sent and the Send Task completes."
    (r) Section 14.2.3: Replace the description of the bullet for Receive Task with the following:
    "Upon activation, the Receive Task begins waiting for the associated Message. When the Message arrives, the data in the data output of the Receive Task is assigned
    from the data in the Message, and Receive Task completes."
    (s) Section 14.2.3, Bullet for User Task: Replace "instantiation" with "activation"
    (t) Section 14.2.3, Bullet for Manual Task: Replace "instantiation" with "activation"
    (u) Section 14.2.3, Bullet for Business Rule Task: Replace "instantiation" with "activation"
    (v) Section 14.2.3, Bullet for Script Task: Replace "instantiation" with "activation"
    (w) Section 14.2.3, Bullet for Abstract Task: Replace "instantiation" with "activation"
    Disposition: Resolved

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

Beta 1 [Section 12.1.2] - Use of the term "BPMN" in class names

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

    Many classes in the visual model start with BPMN. For example, BPMNDiagram, BPMNShape, etc.

    Given that this metamodel is part of the BPMN spec, including BPMN in class names seem extraneous. Certainly we don't do so in the semantic metamodel, so there is an inconsistency in style. Also, this style of naming generally isn't considered a recommended practice. What if BPMN is renamed in the next version?

    Is there a real need for this pattern?

    Comments:
    From: oliver.kieselbach created: Thu, 15 Jan 2009 06:29:07 -0600 (CST)
    I personally don't have a strong opinion about the general naming. Two motivations were driving us here: 1) we wanted to have names which clearly differentiate between a visual MM element from the corresponding semantic element to avoid confusion when talking/discussing/describing elements. 2) when Maged has shown us the Diagram Definition concept and the examples for the UML intrumentation of this DD MM, he also used names like "UMLClassDiagram", "UMLConnector" etc.

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    We need the prefix for Domain Specific refinement of the generic DD specification to differentiate it from the referenced element. This pattern was also done with
    UML.
    Disposition: Closed, No Change

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

Beta 1 [Section 12.1.2] - OrchestrationDiagram should be called ProcessDiagram

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

    In the visual metamodel, a Choreography is visualized in a ChoreographyDiagram, a Collaboration is visualized in a CollaborationDiagram, and yet a Process is not visualized with a ProcessDiagram as I would expect but rather an OrchestrationDiagram.

    For consistency and clarity in terminology, the OrchestrationDiagram should be called ProcessDiagram. Was there a reason it couldn't be?

    Comments:
    From: oliver.kieselbach created: Thu, 15 Jan 2009 06:30:52 -0600 (CST)
    I don't think there was a special reason behind the decision to use "OrchestrationDiagram". So, it would be fine with me to rename it to "ProcessDiagram"

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    The BPMN DI does not contain diagram type as this is not needed for Diagram interchange.
    Disposition: Closed, No Change

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

Relationship navigation (both in MM and XSD)

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

    Beta 1, Section 8.4

    Currently the MM contains a bidirectional relationship between Interface and ServiceRef. This is also represented in the XSD, where the Interface complexType has an element that references a ServiceReference, and the ServiceReference complexType has an element that references an Interface.

    In the Samples meeting, it was raised that the Interface->ServiceReference relationship was not needed in the XSD. This discussion resulted in several outstanding questions:

    • If it doesn't belong in the XSD, should it be in the MM?
    • Tool vendors would find this convenient to have. But is that an implementation issue?
    • This likely isn't the only case. Need to have a broader discussion.
    • What is the purpose of the MM? How are we positioning it?
    • If the MM is for portability, then should the arguments used against the XSD also apply to the MM?
  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:
    • This issue has been carried over from the BPMN 2.0 submission team
    • Ongoing implementation projects do not indicate this is an issue. Close with no changes to the specification (as it is not a problem)
      Disposition: Closed, No Change
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Beta 1: Section 10.2 Activities: Reference Task and Sub-Process from BPMN 1.1 not in BPMN 2.0

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

    In BPMN 1.1, there were Reference Tasks and Sub-Processes, which provided a type of within Diagram reusability--as opoposed to Global Tasks reused across diagrams. Any feature that is in 1.1, but not 2.0 should have some documentation as to why it is not there. This issue could be used to re-introduce the elements or to document why they were excluded in this version.

    Comments:
    From: wstephe created: Tue, 3 Feb 2009 17:39:41 -0600 (CST)
    This could be potential resolved by modifying the Call Activity so that it can also call activities within the same diagram (which was what the Reference Task and Reference Sub-Process did).

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    In Changes annex (Annex A) add:
    "Reference Tasks are removed. These provided reusability within a single diagram, as compared to GlobalTasks, which are resuable across multiple diagrams.
    GlobalTasks can be used instead of Reference Tasks, to simplify the language and implementations."
    Disposition: Resolved

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

Global Task should have performer, Call Activity should have capability to overwrite performer

  • Key: BPMN2-176
  • Legacy Issue Number: 14732
  • Status: closed  
  • Source: Oracle ( Ralf Mueller)
  • Summary:

    A Global Task should have a (default) performer. Right now that is missing in the meta model.
    A Call Activity then should have the capability to overwrite the performer of the global task it is calling.

    Example: (Global User Task)

    <globalUserTask id="approveOrder" name="Approve Order" implementation="humanTaskWebService">
    <documentation>
    Given an order and customer data, approve or reject the order.
    </documentation>
    <ioSpecification>
    <dataInput id="approveOrder-input1" structureDefinitionRef="tns:customerStructure" optional="false"/>
    <dataInput id="approveOrder-input2" structureDefinitionRef="tns:orderStructure" optional="false"/>
    <dataOutput id="approveOrder-output" structureDefinitionRef="tns:resultStructure"/>
    <inputSet id="approveOrder-is">
    <dataInputRefs>aproveOrder-input1</dataInputRefs>
    <dataInputRefs>aproveOrder-input2</dataInputRefs>
    <outputSetRefs>approveOrder-os</outputSetRefs>
    </inputSet>
    <outputSet id="approveOrder-os">
    <dataOutputRefs>aproveOrder-output</dataOutputRefs>
    <inputSetRefs>approveOrder-is</inputSetRefs>
    </outputSet>
    </ioSpecification>
    <performer name="Regional Manager" id="regionalManager"/>
    <potentialOwner>
    <peopleAssignmentPeopleGroup definition="regionalManagers">
    <parameter parameter="city">
    <formalExpression>getDataInput('approveOrder-input1')/address/city</formalExpression>
    </parameter>
    <parameter parameter="country">
    <formalExpression>getDataInput('approveOrder-input1')/address/country</formalExpression>
    </parameter>
    </peopleAssignmentPeopleGroup>
    </potentialOwner>
    <rendering>
    <documentation>HTML Rendering</documentation>
    <html xmlns="<a href="http://w3c.org/html">http://w3c.org/html</a>">
    <h1>Approve Order</h1>
    </html>
    </rendering>
    </globalUserTask>

    Comments:
    From: trickovic created: Tue, 7 Apr 2009 04:03:59 -0500 (CDT)
    As per 4/6 BPMN 2.0 meeting: Defer <a href="http://www.osoa.org/jira/browse/BPMN-467" title="Global Task should have performer, Call Activity should have capability to overwrite performer">BPMN-467</a>

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    (a) Change the MM relationship in GlobalTask from Performer to ResourceRole (ex ActivityResource, see issue 408) and rename the relationship from "performers" to
    "resources".
    1. Change Figure 10.42 to reflect this change
    2. Change the sentence below Figure 10.42 to the following content: "The Global Task inherits the attributes and model associations of Callable Element (see Table
    8.30). Table 10.XX presents the additional model associations of the GlobalTask:"
    3. Create a new table:
    resources: ResourceRole [0..*] => Defines the resource that will perform or will be responsible for the GlobalTask. In the case where the CallableElement that
    references this GlobalTask defines its own resources, they will override the ones defined here.
    (b) Add the following sentence to section 10.2.6 CallAcivity: "When the CallActivity defines one or more ResourceRole elements, the elements defined by the
    CallableElement are ignored and the elements defined in the CallActivity are used instead."
    (c) Change Table 10.131 - GlobalTask XML schema: replace "performer" with "resource".
    Disposition: Resolved

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

Aliases for imported definitions

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

    Filed for Martin and Steve, based on choreograph discussions. When importing definitions, names of imported elements might not be suitable for the application of the importing definitions. The importing definitions should be able to assign aliases to the imported elements for use within the importing definitions.

    -------------------------------------------------------------------------------------------------------------------
    Proposal to review: [Suzette Samoojh - March 18, 2009]
    -------------------------------------------------------------------------------------------------------------------

    Assumption: "Aliasing" is required when you need to use an existing element, but wish to label it differently based on a usage context.
    Two known use-cases:

    • A Participant references a Role (or Entity) and wishes to apply a name that is different from the Role (or Entity) name.
    • A CallActivity references a CallableElement and wishes to show a name that is different from the name of the CallableElement.

    Proposal: Use existing 'name' attributes to achieve this.

    • Participant.name: If specified, serves as the 'alias' for the referenced Role or Entity. If unspecified, the original name of the Role or Entity is used.
    • CallActivity.name [inherited from FlowElement]: Ditto
      No MM changes needed. Just spec text.

    If anyone has an example that the above does not satisfy, please post it.
    [Note that a concrete example then means we will tackle this issue in a samples-driven manner].

  • Reported: BPMN 2.0b1 — Fri, 20 Nov 2009 05:00 GMT
  • Disposition: Resolved — BPMN 2.0
  • Disposition Summary:

    This issue cannot be fixed in this FTF.
    Disposition: Closed, Out Of Scope

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

Beta 1: Section 10.2 Activities: Move User Task Instance Attributes to the higher level Activity element

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

    Since all activities have performers and priorities. it makes sense to be able to use the actual performer or priority of any activity in the definition of any other activity. E.g., the performer of this activity cannot be the same as that activity. Performers can do the work as in User Tasks, or just be stakeholders or authorizers, etc. for any activity (including sub-processes). Right now only User Activities have these instance attributes. Moving the attributes to the Activity level would allow other activitie