Issues for Mailing list of the Business process Model and Notation 2.0 (BPMN 2.0) Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 14240: Conformance Classes are overley Broad
Issue 14243: Typos
Issue 14244: The case of some attribute name is not consistent.
Issue 14245: Page 199 class model for the global tasks
Issue 14246: Page 227 Table 10-56 the attributes optionalOutput and whileExecutingOuput are wrongly typed DataInput
Issue 14247: Page 052, Table 7-2, Wrong figure of all event possibilities
Issue 14248: Page 199, Figure 10-40 Types of Global Task (Text,Class Diagram and Schema do not match)
Issue 14249: Page 029, Section 2.1.3 Usage of normal bullets vs diamond shape to indicate structural specifications
Issue 14250: Page 044, Figure 7-3, Pool names not separated from content by a single line
Issue 14251: Page 119, section 8.3.14 Copy/Paste error wrong term "Pool" vs "Message Flow"
Issue 14252: Page 130, section 8.3.17 Copy/Paste error
Issue 14253: Page 259, Table 10-82, Missing "Catch" label above depiction of Parallel Multiple Event
Issue 14254: Page 338, section 11.7 Section name versus content
Issue 14255: Page 372, Table 12-7 Blank sections
Issue 14256: Page 028, Section 1, Missing Conversation diagram in list of diagrams defined in BPMN
Issue 14257: Page 042, Section 7.1.1 Reference to Figure 10-5
Issue 14288: Page 064, Section 7.5.1, wrong reference to Table 8.4 (should be Table 7-3)
Issue 14289: Page 065, Section 7.5.2, Wrong reference to Table 8.5 (Should be Table 7-4)
Issue 14290: Page 115, Section 8.3.13 Copy/paste
Issue 14291: Page 395, Figure 12-51, Intermediate Event instead of End Event in Choreography diagram
Issue 14292: Page 044, Figure 7-4, The initiating party is wrongly identified in the figure
Issue 14294: Page 345, Section 12.1 Typo, the word "Events" should be "Activities"
Issue 14295: Page 346, Section 12.1 Reference of Figure 12-4 instead of Figure 12-3?
Issue 14296: Page 348, Section 12.3.1, end of sentence confusing
Issue 14297: Page 351, Figure 12-7 Caption of the Figure Name
Issue 14298: Page 352, Figure 12-9, inapropriate caption
Issue 14299: Page 353, Figure 12-11, inapropriate caption
Issue 14300: Page 357, Figure 12-17 and 12-18 Participant names not identical
Issue 14301: Page 370, Table 12-6, references to Event Sub-Process
Issue 14302: Page 175, Table 10-11, Spelling of Business in Attribute Name
Issue 14304: Page 242, Table 10-75 eventDefintionsRefs and eventDefinitions descriptions are identical
Issue 14305: Page 243, Table 10-76 eventDefinitionRefs and eventDefinitions descriptions
Issue 14306: Page 242-243 Tables 10-75 and 10-76
Issue 14307: Page 408, Section 13.2.5 Event Sub-process not included
Issue 14308: Page 331, Typo Figure references 11-3 but should be 11-4
Issue 14309: Page 165, Table 10-7 Required attribute cardinality explicitly defined
Issue 14310: Page 243 Table 10-76 the definition of EventDefinitionRefs and eventDefinitions is duplicated in ThrowEvent and CatchEve
Issue 14311: The attribute name is duplicated across many, many, many classes
Issue 14312: Page 047, Section 7.2 Properties is presented as a Data element
Issue 14313: Page 058, Table 7-2, Fork: Questionable affirmation
Issue 14314: Page 060, Table 7-2, Merging: No depiction of implicit merge
Issue 14315: Page 050, 061 and 417 Group text implies that only activites can be within a Group
Issue 14316: Page 063, Section 7.4 Undefined term "Flow"
Issue 14317: Page 187, Figure 10-27 Inconsistent use of class hierarchy vs. attributes to define types of subprocess
Issue 14318: Page 149, Figure 9-6 Vertical pool markers placement depiction
Issue 14319: Page 149, Figure 9-6 Multi-instance marker no depiction for white box pools
Issue 14320: Page 223, Figure 10-57 Unclear usage of IsCollection attribute for DataOutput
Issue 14321: Page 253 and 257, Table 10-81 and 10-82 EventDefintion used for Events
Issue 14322: Page 115-120 Distinguishing Initiating and Non-Inititating Messages
Issue 14323: Page 028, Section 1, Wrong term for BPMN : Business Process Modeling Notation
Issue 14324: Page 049, Table 7-1 Depiction of Lanes with single lines to separate Lane name to Lane content
Issue 14325: Page 054, Table 7-2, Gateway Control Types: Incomplete statement
Issue 14326: Page 056, Table 7-2, Compensation Association: Usage of term Compensate Event
Issue 14328: Page 153, Figure10-1, Link Events not paired may lead to confusion
Issue 14329: Page 159, Section 10.1.2 number of types of diagrams
Issue 14330: Page 187, Do sub-process markers also apply for Call Activity and Event Subprocess
Issue 14331: Page 244, section 10.4.2 Last two structural specifications for Start Event
Issue 14332: Page 247 section Start Event for Event Sub-Processes
Issue 14334: Page 251, Exceptions for Sequence Flow connections for Start Event
Issue 14335: Page 192, Table 10-21 Transaction types need explanation
Issue 14336: Page 253, section 10.4.3 End Event Sequence Flow Connections
Issue 14337: Page 255, Message Flow connection for End Event
Issue 14338: Page 257, Intermediate Event Types in Normal flow
Issue 14339: Page 265, Activity Boundary Connections
Issue 14340: Page 265, Sequence Flow Connections for Intermediate Events
Issue 14341: Page 328, Section 11, Communication Link or Conversation Link
Issue 14342: Page 331, Figure 11-4, Message Flows part of a Conversation diagram
Issue 14343: Page 337, section 11.5 Typo should be "Call Conversation"
Issue 14344: Page 361, Figure 12-23, Sub-process marker missing
Issue 14345: Page 032, section 2.4.1, Referencing wrong chapter
Issue 14346: Page 076, Figure 8-5, Figure Caption incorrect
Issue 14347: Page 190, sub-section "Transaction"
Issue 14349: Page 29, Section 7.2.2 - Fork and Join Differentiation
Issue 14350: Page 22, Section 7.2.1 - Associating Data Objects with process as a whole
Issue 14351: Page 26, Normal Flow row of Table 7.2
Issue 14352: Page 26, Normal Flow row of Table 7.2
Issue 14353: Page 121, Figure 10-1 - Redundant ways to model receiving messages
Issue 14358: Page 29, Section 7.2.2 ­ Fork and Join Differentiation
Issue 14359: Page 22, Section 7.2.1 ­ Associating Data Objects with process as a whole
Issue 14360: Page 26, Normal Flow row of Table 7.2 - Modeling activities that do not complete before process completion
Issue 14361: Page 26, Normal Flow row of Table 7.2 - Modeling Activities that are only ended by Events
Issue 14362: Page 121, Figures 7.3 and 10-1 ­ Redundant ways to model receiving messages
Issue 14363: Page 24, Table 7.2 Gateway control types row - Redundant forms for XOR Gateway
Issue 14423: BPMN 2 FTF issue on XSDs for DD / DI model transfer
Issue 14432: text attribute is missing from the Documentation element of the v 0.9.14 schema
Issue 14433: Sematic.xsd vs. v0.9.14, sect. 8.3.7, pp106-107
Issue 14441: Semantic.xsd v0.9.14, sect. 8.2.1, p76-77
Issue 14446: Lane.partitionElementRef incorrectly defined
Issue 14535: Method of specifying a default SequenceFlow is awkward
Issue 14537: businessRuleTask element in the BPMN 2.0 schema file is missing the implementation attribute
Issue 14540: Page 204, Table 10-26, MultiInstance Activity: Potential error and clarification regarding **BehaviorEventRef
Issue 14541: Page 161, Table 10-3, Error in attribute name. "resources" should be "activityResource"
Issue 14542: Page 160, Figure 10-6 vs. Table 10-3. The "property" class is not depicted in the class diagram Figure 10-6
Issue 14543: Page 161, Table 10-3, Issues regarding properties in the Activity attribute table
Issue 14546: Initiating message flow for ChoreographyTask
Issue 14548: Clarification on relationship between MEP and Choreography Task in BPMN2
Issue 14551: Allow Choreography Task to have more than 2 Participants
Issue 14559: Target namespace mismatch between the XML Schemas in the spec (PDF) and the XML Schemas files (XSD)
Issue 14564: logic error in the PDF document
Issue 14568: The schema for globalTasks of type Send ,Receive and Service are not there
Issue 14579: Variable Id TO Variation Id
Issue 14589: Definition of Participant Band Shadings not clear
Issue 14615: URL referenced for WfMC Gloassary is incorrect
Issue 14616: URL referenced for XPDL specification is incorrect
Issue 14617: Typo in Section 7.2 paragraph 1
Issue 14622: Correlation on Choregraphy
Issue 14623: Conversation Muddle
Issue 14641: Merge Conversation and Collaboration
Issue 14644: Missing DataStore from the enumeration of item-awre elements at top of the page
Issue 14645: Missing details regarding the visualisation of a DataState for a DataObject
Issue 14646: Misleading copy/paste para regarding Properties
Issue 14647: Section 10.2.3
Issue 14648: Multiple properties / keys clarification
Issue 14649: Key-based Correlation => ?
Issue 14650: Subprocess / CallActivity switch
Issue 14651: isImmediate default
Issue 14652: Private process example correction
Issue 14654: Beta 1 Section 11 Conversation:
Issue 14655: Complex gateway merging rule in choreography too restrictive
Issue 14658: Promote correlationKeys association to ConversationContainer
Issue 14659: Correlation Class Diagram missing Process association
Issue 14660: Conversation/Process switch
Issue 14662: Private process type
Issue 14664: Processes supporting interactions
Issue 14665: Exclusive gateways in choreography cover splitting but not merging
Issue 14670: Choreography Complex Gateway example
Issue 14671: isClosed on Conversation
Issue 14672: Meaning of + symbol on Communication undefined
Issue 14675: Fix difference between MessageFlowNode definition in specification vs the semantic.xmi file
Issue 14676: Error vs ErrorCode & Escalation vs EscalationCode
Issue 14677: Incorrect description for the Transaction.protocol attribute
Issue 14678: Mention of "isInterrupting" attribute still in the spec
Issue 14679: Contradiction in constraint for Start Events in Event Subprocess
Issue 14680: Are Conditional Start Events executable?
Issue 14681: Correlation Key & Correlation Properties are missing 'name' attributes
Issue 14682: Section 11 Conversation: Fix Conversation figures for proper notation for Pools
Issue 14684: Merge Conversation and Collaboration
Issue 14685: CorrelationSubscription Ownership
Issue 14687: Semantic metamodel => Abstract syntax
Issue 14688: MessageFlowRefs missing from Conversation metamodel diagram
Issue 14689: Conversation/Communication switch
Issue 14690: Choreography Subprocess => Subchoreography
Issue 14691: Service Package => Interface Package
Issue 14692: Need to revisit and test the process example in the spec (Figure 7-8)
Issue 14693: Error class has no 'name' attribute
Issue 14694: Typo in Terminate Event description
Issue 14695: Grouping message flow in Collaboration
Issue 14696: Lanes and Sequence Flow
Issue 14697: Service Task => Operation Task
Issue 14699: Multiple PartnerEntities per Participant
Issue 14700: XSD: mixed="true" is redundant in tFormalExpression element
Issue 14701: XML-Schema type for 'from' and 'to' elements in Data Assignment must not be abstract
Issue 14703: CorrelationSubscription - Description & use-cases
Issue 14705: parallelMultiple attribute missing from CatchEvent table
Issue 14706: The Category section has incorrect/inconsistent content
Issue 14707: Editorial: Incorrect containment statement for EventDefinitions
Issue 14708: Notation for supports association
Issue 14710: V0.9.7: Section 10 Process: Add ProcessResource Attribute to Process
Issue 14712: Use "item" terminology more uniformly
Issue 14713: Beta 1 Section 2.2 Process Execution Conformance: Describe this conformance apart from Process Modeling Conformance
Issue 14714: Beta 1 Section 12.4 Choreography Activities: Fix redundancy in the definition of these elements
Issue 14715: Beta 1 Section 13.2.4 ChoreographyActivityShape: Add Choreography Activity Bands to DI model
Issue 14716: Metaelement missing for DI to show connection between ChoreographyActivity to Message
Issue 14717: DataAssociations: How do we support literals?
Issue 14718: XSD DataAssociation should own source and target refs and mistake in text spec
Issue 14719: Section 10.3.1 Data Inputs and Outputs: Schema change: change minOccurs of inputSet for ioSpecification from 0 to 1
Issue 14720: tActivityResource::resourceRef should be optional
Issue 14721: Correlation properties must have name and type (was dropped in 4/22 XSD and MM)
Issue 14722: TimerEventDefinition: clarification of the expected result of the timeCycle and timeDate expressions
Issue 14723: Beta 1: Section 10.4.5 Handling Events: When does the interrupting Event Sub-Process cancel its Parent?
Issue 14724: Beta 1: Section 10.4 Events: Statement "Signals are triggers generated in the Pool they are published" needs clarificati
Issue 14725: V0.9.9.1: Display of Messages and Associations in Choreography
Issue 14726: Beta 1: Set the name attribute of DataInputs and DataOutputs to optional
Issue 14727: XSD: Data Association sourceRef and targetRef should be of type QName
Issue 14728: Data Assignment 'from' and 'to' should be formal expressions
Issue 14731: Editorial: Rename FlowElement::categoryValue to ::categoryValueRef
Issue 14732: Global Task should have performer, Call Activity should have capability to overwrite performer
Issue 14733: [XSD] Documentation and ScriptTask (and probably expressions) should be stored as CData elements and not String attribut
Issue 14734: Lanes should be described in Process section
Issue 14735: Data Association should be specialized from Association
Issue 14736: Add business-level presentation attributes to user task: subject and description
Issue 14739: Beta 1: Section 10.2 Activities: Move User Task Instance Attributes to the higher level Activity element
Issue 14740: Aliases for imported definitions
Issue 14742: Beta 1: Section 10.2 Activities: Reference Task and Sub-Process from BPMN 1.1 not in BPMN 2.0
Issue 14743: Relationship navigation (both in MM and XSD)
Issue 14746: Beta 1 [Section 12.1.2] - OrchestrationDiagram should be called ProcessDiagram
Issue 14747: Beta 1 [Section 12.1.2] - Use of the term "BPMN" in class names
Issue 14748: Beta 1: Is a Message a DataInput for an Activity; Is Message Flow a Data Association
Issue 14749: [Section 10.6] Editorial: We need more explicit descriptions of Compensation behaviour regarding scopes
Issue 14750: [Section 10.2.3] Editorial
Issue 14752: Diagram Interchange should align with Diagram Type Definition
Issue 14753: [Meta-model] Exclusive gateway is missing specification of order of leaving sequence flows
Issue 14754: Pools multiplicity
Issue 14758: Beta 1: Section 10.3.1 Data Objects [Data]: Change Multiplicity of datastate attribute from 0..1 to 0..*
Issue 14760: Data flow in/out of events
Issue 14772: Section 2 Conformance [Specification]: Explicitly define BPMN compliance criteria, with focus on "model"
Issue 14776: Section 8.1.5 [Infra] Import statement description is not clear enough
Issue 14778: Annex D Glossary [Specification]: Update Glossary
Issue 14779: Tasks vs Global Tasks
Issue 14780: Business Rule Task description doesn't describe purpose (section 10.2.3, Beta 1)
Issue 14781: Section 10.3.1 [Data-MM]: Events can contain properties but the relationship is not shown in the MM diagram
Issue 14782: Enabling multiple events at the same time for the same message
Issue 14783: Semantics for data flow without sequence flow
Issue 14785: Generalize message flow
Issue 14787: Reuse of processes in orchestration and choreography
Issue 14789: Section 10.2.8 [Execution Semantics] Loops: Loop names misleading
Issue 14791: Section 8.2.1 [Service Model] How to model a request-reply use case?
Issue 14793: Section 10.2.5: Sub-Process: Figure 10.25; Add a minus sign to the bottom of an expanded Sub-Process?
Issue 14795: Default execution semantics for an activity with multiple incoming branches needs to be clarified
Issue 14797: Section 9.2: Pool description needs revisiting
Issue 14798: General [Metamodel] Double-check attributes that are enumerated types, and their extensibility needs
Issue 14799: Section 10.5.1/10.5.6 Need to clarify how initiating gateway is specifed: via sequence flow, attribute, or both
Issue 14801: Section 10.2.3 ScriptTask.scriptLanguage needs to specify format
Issue 14803: Can a sub-process (embedded) have Lanes?
Issue 14804: Section 8.3.15 [Choreo] ParticipantMultiplicity must allow to specify 1..2, possibly also 0..1
Issue 14805: Section 12.4.1 [Choreo] How many message flows per choreography task? Missing meta-model
Issue 14809: Allow Choreographies within a Conversation Diagram
Issue 14816: Formalizing the Source-Target relationships between Link Intermediate Event
Issue 14817: Data Inputs/Outputs on Subprocesses
Issue 14818: Unclear/contradictory handling of visualized Data Inputs/Outputs
Issue 14819: Cardinality of the "sourceRef" association between DataAssociation and ItemAwareElement
Issue 14820: Data Inputs the target of multiple Data Associations
Issue 14822: The description of operationRef is not accurate
Issue 14823: Persistent versus transient event trigger
Issue 14826: Event marker quality is poor
Issue 14832: Confusion about Performers and other roles that Resources play for Activities
Issue 14833: Called conversations without keys of the caller
Issue 14834: Order of outgoing sequence flows from exclusive gateway
Issue 14848: Allow Overlapping Matrix Construction of Lanes in a Diagram
Issue 14858: "isInterrupting" attribute of Start Events
Issue 14859: Property name mismatch between Spec and Schema for Item Definition
Issue 14860: The Message element structureRef association should be renamed to itemRef
Issue 14863: Reference ProcessRef missing in Figure 8.40 - The Participant Class Diagram
Issue 14869: Does CallChoreography need a MessageFlowAssociation?
Issue 14877: Execution semantics for Data Objects and Properties must be enhanced to properly describe concurrent modification situat
Issue 14878: Visibility and permissions for Data Objects and Properties must be described
Issue 14880: INCORRECT/IMCOMPLETE REFERENCES AND DEFINITIONS IN GLOSSARY
Issue 14890: Ambiguity when multiple message flows associated with a choreography task
Issue 14919: Exclusive Gateway (missing sub-heading)
Issue 14921: Inconsistent/confusing statements around CallActivities and IOSpecifications
Issue 14932: Correlation key property values from process instances
Issue 14965: Change plural "flow" to "flows"
Issue 14966: Clarify "Instance of this Conversation."
Issue 15027: Table 10-4 page 162 List of possible states of an Activity instance
Issue 15028: Depictable element without a reference semantic element
Issue 15029: Mutiple depictions of a single semantic element
Issue 15031: BPMN CMOF File problems
Issue 15038: Confusing semantics for Terminate End Event
Issue 15040: Add an attribute that can identify a rulebase/rule engine for Business Rule Task
Issue 15042: The example provided in Figure 10-22 and its serilization in Table 10-19 are incorrect or at least misleading
Issue 15044: Parallel Event Based Gateway capability is hidden away
Issue 15045: ResourceParameter::type attribute should be of type ItemDefinition, not Element
Issue 15049: Clarification of Temporal Sematics of Sequence Flow
Issue 15055: Required definitions to invoke an existing function by means of a service task
Issue 15058: CorrelationKey should be a concrete element
Issue 15059: DataInputs, DataOuputs, and DataStores should be FlowElements
Issue 15060: Simplify Use of Callable Elements
Issue 15061: LaneSet should have an optional ‘name’ attribute
Issue 15062: Figure 10.121 mis-described
Issue 15063: How to represent Process Diagrams and Lanes?
Issue 15064: For Process within Collaboration, section 9.3 title is wrong and section 10.11 is empty
Issue 15067: Hexagons and message flow linked to activities
Issue 15068: Label call conversation links
Issue 15069: Correlation on message flow and choreography activities
Issue 15080: Data Objects should be defined with the same pattern a Data Stores and DataStoreRefs
Issue 15082: Extending via inheritancy is problematic using the BPMN xsd format
Issue 15083: No way to identify the format of Documentation and TextAnnotation connect
Issue 15085: Incorrect attribute name used for Start Event definition
Issue 15086: Add Attribute Table for Global Task
Issue 15087: Contradictory/redundant handing of data and subprocesses
Issue 15091: Additional participants in called/subconversation
Issue 15093: Choreography should be a Sub-Class of Collaboration
Issue 15095: Review the use of RFC2119 keywords
Issue 15102: For DI: All graphical elements should have a Semantic Counterpart
Issue 15103: Allow referencing scripts instead of enfocing inline specification
Issue 15104: How to reference particular instances of Data Objects that are Collections
Issue 15105: XML Schema is not strict enough
Issue 15115: Rename "Call" Elements
Issue 15119: Merge Collaboration and Choreography in Metamodel
Issue 15122: Receive Task is not mentioned as an instantiating element
Issue 15133: Mismatch in DataAssociation definition between spec and XSD
Issue 15137: Figure 12-21, Sub-process marker missing
Issue 15139: Missing loopCharacteristics for Choreography stuff in MM
Issue 15146: Missing label of a compensation activity
Issue 15147: Missing <sequenceFlow ... /> in XML example
Issue 15149: Process Model and Model Description are not consistent
Issue 15150: Missing marker in Compensation Activity
Issue 15152: Choreography is not enforcable
Issue 15154: Missing Message Flow
Issue 15155: Inclusive Gateway Semantics
Issue 15161: Exporter Information Required for BPMN 2 files
Issue 15163: Missing definition of the participant Buyer
Issue 15165: Conversation lanes
Issue 15168: A Collaboration should be able to reference more than one Choreography
Issue 15169: The Two Multi-Instance Markers should be reversed

Issue 14240: Conformance Classes are overley Broad (bpmn2-ftf)

2.1.1 process modeling conformance:
what could a platform which supports all the diagrams except for conversation
diagrams claim conformance to? This might be important for migration from BPMN 1
implementations. Can it claim some form of "partial compliance?


Proposed Resolution: The FTF should define more granular conformance Classes, to ease migration
from BPMN 1.2 implementations.

BPMN 2 FTF typos

Issue 13: Page 79, Table 8-8 Typo extensionAttributeDefinitions is typed ExtensionDefinition 

Reported by dga...@trisotech.com, Jun 08, 2009 

On p.79, Table 8-8 the attribute extensionAttributeDefinitions is typed 
ExtensionDefinition, it should be typed ExtensionAttributeDefinition.

==========================================================================

Issue 30: Page 141, Table 8-81 Typo in type definition "s" added 

callableElements should be of type CallableElement and not CallableElements

==================================================================

Issue 32: Page 283, Figure 10-90 Typo "CancelEventDefinition" should be reploaced by "TerminateEventDefinition" 

Reported by hudoneric, Jun 25, 2009 

On p. 283 of the specification, we can read CancelEventDefinition element
inherits... 

Since a TerminateEventDefinition exists, I assume that this is what should
go there.

=========================================================================

Issue 62 : Page 307, section 10.5.6 Copy/paste Typo "Start Event" should be "Event Gateway" 

Comment 1 by dga...@trisotech.com, Jul 10, 2009 
In second structural specification Start Event should be replaced by Event 
Gateway.

=================================================================

Issue 63: Page 316, section 10.7 Copy/Paste Typo "Pool" should be replaced by "Lane" 

In second structural specificatio Pool should be replaced by Lane

=========================================================================

Issue 74: Page 049, Table 7-1, Typo word "is' extra 


For the element "Pool" the second sentence of the descriptive text is: "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."
The word "is" at the beginning of the sentence should be deleted.

=========================================================================

Issue 75: Page 052, Table 7-2, Typo missing "a" before Process 

Reported by asir...@trisotech.com, Jul 01, 2009 

For element "Activity" the first sentence is: "An Activity is a generic 
term for work that company performs (see page 159) in Process."

The word "a" shoud be added before the word "process".

===================================================================

Issue 76: Page 053, Table 7-2, Typo missing "or" in sentence 

Reported by asir...@trisotech.com, Jul 01, 2009 

For element "Choreography Task", the last sentence of the descption 
is:"There are two (2) more Participant Bands and one Task Name Band."

The word "or" shoud be added after the "two (2)".

Comment 1 by dga...@trisotech.com, Jul 06, 2009 
For element "Choreography Task", the last sentence of the descption 
is:"There are two (2) more Participant Bands and one Task Name Band."

The word "or" shoud be added after the "two (2)".


Summary: Page 053, Table 7-2, Typo missing "or" in sentence
Labels: Validated
Comment 2 by asir...@trisotech.com, Jul 07, 2009 
Same apply to last sentence of page 351.

Comment 3 by asir...@trisotech.com, Jul 07, 2009 
Also apply to Page 356, Section 12.4.2, last sentence of second paragraph.

====================================================================

Issue 80: Page 087, Typo "a" should be "are" 

Reported by asir...@trisotech.com, Jul 01, 2009 

In sub-section "Common Artifact Definitions", the sentence reads:"The 
following sections provide definitions that a common to all Artifacts."

"That a common" should be replaced by "that are common".

=====================================================================

Issue 82: Page 124, Section 8.3.15, Typo Missing "are" in frist sentence 

Reported by asir...@trisotech.com, Jul 01, 2009 

The first sentence of Section 8.3.15 is: "A Participant represents a 
specific PartnerEntity (e.g., a company) and/or a more general PartnerRole
(e.g., a buyer, seller, or manufacturer) that Participants in a  
collaboration."

The word "are" should be added to read " ..... that are Participants in a 
collaboration."

=====================================================================

Issue 83: Page 145, Section 9, Typo missing "in" 

Reported by asir...@trisotech.com, Jul 02, 2009 

Page 145, last paragraph, first sentence reads: "In some applications it 
is useful to allow more Messages to be sent between Participants when a
Collaboration is carried out than are contained the Collaboration model."

The word "in" should be added, for the sentence later part to read: " .... 
are contained in the Collaboration model."

======================================================================

Issue 84: Page 146, Section 9.1 Typo word "main" should be "may" 

Reported by asir...@trisotech.com, Jul 02, 2009 

Section 9.1, second paragraph, first sentence reads:"A Pool may be empty, 
a “black box,” or main show a Process within."

The word "main" should be replaced by "may".

======================================================================

Issue 87: Page 163, Section 10.2, Typo "An" should replace "A" 

Reported by asir...@trisotech.com, Jul 02, 2009 

In page 163, the second structural specification (just before section 
10.2.1) reads: "A Activity MAY be a source for Message Flow; it can have 
zero or more outgoing Message Flow." 

The first word of the sentence "A" should be replaced by the word "An".

======================================================================

Issue 88: Page 188, Section "Event Sub-Process", Typo missing "is" 

Reported by asir...@trisotech.com, Jul 02, 2009 

The frst sentence after the sub-section title "Event Sub-Process" 
reads: "An Event Sub-Process is a specialized Sub-Process that used within 
a Process (or Sub-Process)."

The word "is" should be added for the sentence to read: "An Event Sub-
Process is a specialized Sub-Process that is used within a Process (or Sub-
Process)."

====================================================================

Issue 89: Page 188, sub-section "Event Sub-Process" Typo 

Reported by asir...@trisotech.com, Jul 02, 2009 

The last structural specification of page 188 reads: "The use of text, 
color, size, and lines for a Sub-Process MUST follow the rules defined in
Section “Use of Text, Color, Size, and Lines in a Diagram” on page 63 with 
the exception that:"

The words " a Sub-Process MUST" should be replaced by "an Event Sub-
Process MUST".

====================================================================

Issue 91: Page 231, sub-section "DataInputAssociation", Typo "an" vs "a" 

Reported by asir...@trisotech.com, Jul 02, 2009 

The first sentence of page 231 reads: "The DataInputAssociation can be 
used to associate a item-aware element with a DataInput contained in
an Activity."

The word "a" before "item-aware" should be replaced by the word "an".

===================================================================

Issue 94: Page 308, Section 10.5.6, Typo Replace "follow" by "following" 

Reported by asir...@trisotech.com, Jul 02, 2009 

The fifth structural specification in page 308, reads: "Only the following 
Intermediate Event triggers are valid: Message, Signal, Timer, 
Conditional, and Multiple (which can only include the previous triggers). 
Thus, the follow Intermediate Event triggers are not valid: Error, Cancel, 
Compensation, and Link."

The word "follow" in the second sentence of the specification should be 
replaced by "following".

=================================================================

Issue 95: Page 320, Section 10.8, Typo missing word "in" 

Reported by asir...@trisotech.com, Jul 02, 2009 

Section 10.8, second paragraph, first sentence reads: "In some 
applications it is useful to allow more Activities and Events to occur 
when a Process is executed or performed than are contained the Process 
model."

The word "in" should be added for the end of the sentence to read " .... 
than are contained in the Process model."

================================================================

Issue 100: Page 343, Section 12, Typo Two verbs used instead of one 

Reported by asir...@trisotech.com, Jul 07, 2009 

The sentence above Figure 12-2 reads: "Figure 12-1 shows displays the 
metamodel ...".

One of the two verbs, "shows" or "displays" should be deleted.

===============================================================

Issue 109: Page 367, Section 12.4.6, Typo, word "will" to be deleted 

Reported by asir...@trisotech.com, Jul 07, 2009 

The second sentence of page 367 reads: "The Choreography Task that has two 
Messages will is reflected by three Process Tasks."

The word "will" should be deleted. 

==============================================================

Issue 112: Page 164, Table 10-5, Typo "s" added to Type 

Reported by dga...@trisotech.com, Jul 08, 2009 

There is also a typo on p. 164. resourceParameterBindings should be of 
type 
ResourceParameterBinding and not ResourceParameterBindings.

==============================================================

Issue 121: Page 361 Section 12.4.3 Typo "collpased" instead of "collapsed" 

Reported by hudoneric, Jul 27, 2009 

On page Page 361 Section 12.4.3 "collpased" should be read "collapsed". The
text is located on the third bullet of the section 12.4.3.

=============================================================

Issue 124: Page 044, Figure 7-4, Page 345 Figure 12-2 and Page 394 Figure 12-50 Typo in the figure 

Reported by dga...@trisotech.com, Jul 29, 2009 

The last Choreography activity in Figure 7-4, Figure 12-2 and  Figure 12-
50 should be labeled "Handle Medecine".

====================================================================

Issue 134: Page 264 Table 10-85 Typo in table caption "cancel Activity" should be "cancelActivity" 

Reported by dga...@trisotech.com, Jul 29, 2009 

Page 264 Table 10-85 Typo in table caption "cancel Activity" should 
be "cancelActivity"

========================================================================

 Reported by dga...@trisotech.com, Jun 08, 2009

It seems that lower case is the standard, but some attributes like 
ReceiveTask.Instanciate, UserTask.Imlementation for example, but there are 
other attributes as well.

The same comment applies to type name string vs String, Boolean vs 
Boolean, etc…




Comment 1 by hudoneric, Jun 09, 2009

The case of the gatewayDirection on p.111 is lower case. The values of other 
enumerations in the document are capitalized.

Comment 2 by hudoneric, Jun 10, 2009

Same thing for multi-instance behavior on p.203.

Comment 3 by hudoneric, Jun 10, 2009

The case of the enumeration UserTaskImplementation is not the same in the
specification (p. 179) and the schema (p. 181).

Comment 4 by hudoneric, Jun 10, 2009

The case of the methodon p.192is lower case. The values of other 
enumerations in the document are capitalized.

On p.199, there is a class model for the global tasks, but there no table 
that explains the attributes that are displayed on the diagram like the 
other classes in the document.

 Reported by dga...@trisotech.com, Jun 08, 2009

On p. 227 the attributes optionalOutput and whileExecutingOuput are typed 
DataInput, they should be typed DataOutput.

 Reported by dga...@trisotech.com, Jun 08, 2009

The old list from BPMN 1.2 is presented there

 Reported by hudoneric, Jun 25, 2009

On p. 199 of the specification The figure 10-40 Defines 4 types of global
tasks: User, Manual, Script, BusinessRule.

The paragraph "Types of Global Task" on p. 199 says that the list of task
types is the same for globals task and standard tasks. 

When I look at the xml schema (Semantic.xsd) only  User, Manual, Script,
BusinessRule are defined. 

I wonder which one is true, the text or the schema? Also I wonder why the
global task redefines the same attributes as standard tasks instead of
referencing them.

 Reported by asir...@trisotech.com, Jun 26, 2009

Should the list presented use the diamond shape to indicate structural 
specifications? 

 Reported by asir...@trisotech.com, Jun 26, 2009

Should the Pool names be separated by a single line as stated in the 
structural specification in Section 9.2, page 146.

 Reported by asir...@trisotech.com, Jun 26, 2009

The third strtural specification refers to Pool, should it be replaced by 
Message Flow?

 Reported by asir...@trisotech.com, Jun 26, 2009

Second structural specification, should Task be replaced by Sequence Flow?

 Reported by asir...@trisotech.com, Jun 29, 2009

The Parallel Multiple Event in Table 10-82 is the only Event without 
the "Catch"  indicated above its diagram object. 

 Reported by asir...@trisotech.com, Jun 29, 2009

Is the tiltle "Communication Link" or "Conversation Link"? Second term 
used in the text and Figure of this section.

 Reported by asir...@trisotech.com, Jun 29, 2009

Why are Table sections for Escalation used in normal flow and Escalation 
attached to activity boundary left blank?

 Reported by asir...@trisotech.com, Jul 01, 2009

Section 1, third paragraph, first sentence says: "This specification 
represents the amalgamation of best practices within the business modeling 
community to define the notation and semantics of Collaboration diagrams, 
Process diagrams, and Choreography diagrams."

Should "Conversation diagrams", described in section 13, be added to this 
list?

 Reported by asir...@trisotech.com, Jul 01, 2009

The last paragraph, first sentence of page 42 is: "A public Process 
represents the interactions between a private Business Process and another 
Process or Participant (see Figure 10-5)."

Should the reference to Figure 10-5, be replaced by Figure 7-2 presented 
at page 43?

 Reported by asir...@trisotech.com, Jul 01, 2009

Should the first two words of section 7.5.1 "Table 8.4" be replaced 
by "Table 7-3" ?

 Reported by asir...@trisotech.com, Jul 01, 2009

Should the first two words of section 7.5.2 "Table 8.5" be replaced 
by "Table 7-4"?

 Reported by asir...@trisotech.com, Jul 01, 2009

The second structural specification of section 8.3.13 should refer 
to "Message" and not "Task".

 Reported by asir...@trisotech.com, Jul 02, 2009

The Choreography diagram shown in Figure 12-51 end with an Intermediate 
Event. It should be an End Event.

 Reported by dga...@trisotech.com, Jul 06, 2009

The initial messages and Participant bands are greyed in error, (Reverse 
logic Initiating vs Return)

 Reported by asir...@trisotech.com, Jul 07, 2009

The fourth sentence of the last paragraph of page 345, reads: "For 
example, a Planned Order Variations Message is sent by the Supplier to the 
Retailer; the corresponding send and receive have been modeled using 
regular BPMN messaging Events."

This text refers to the content of Figure 12-3 (mentionned before). No 
Events are shown in this Figure. The word "Events" should be replaced 
by "Activities".

 Reported by asir...@trisotech.com, Jul 07, 2009

In the first and second paragraphs of page 346 a reference is made to 
Figure 12-4. Should it be to Figure 12-3 instead?

 Reported by asir...@trisotech.com, Jul 07, 2009

Page 348, last paragraph, first sentence reads: "In some applications it 
is useful to allow more Messages to be sent between Participants when a
Choreography is carried out than are contained the Choreography model."

The end of the sentence "... is carried out than are contained in the 
Choreography model." is confusing.

Figure 12-7 caption is "A Collaboration view of Choreography Task 
elements" is not representative of the figure.

According to the text above the figure and the diagram, the caption should 
be: "A Collaboration view of the Participants of the Interaction".

 Reported by asir...@trisotech.com, Jul 07, 2009

Figure 12-9 caption is "Choreography Task". It should be "A Collaboration 
view of Choreography Task elements".

The sentence below this figure makes reference to Figure 12-7. The 
reference should be to Figure 12-9.

 Reported by asir...@trisotech.com, Jul 07, 2009

The caption of Figure 12-11 is "Choreography Task". It should be "A 
Collaboration view of a two-way Choreography Task element".

 Reported by asir...@trisotech.com, Jul 07, 2009

Figure 12-18 is stated to be a different representation of Figure 12-17.

However, the Participant names are different, Participant 1 and 2 in 
Figure 12-17 and Participant A and B in Figure 12-18.

They should be the same.

 Reported by asir...@trisotech.com, Jul 07, 2009

In Table 12-6, many references are made to the use of different types of 
Start Events for Event Sub-Processes.

Are Event Sub-Processes part of a Choreography diagram or are Event Sub-
Processes represented by Choreography Sub-Processes in a Choreography 
diagram, like other Sub-processes involved in Message exchange between 
Participants?

If Event Sub-Processes are not pat of a Choreography diagram why all these 
references to Event Sub-Processes in the Choreography section?

Comment 1 by dga...@trisotech.com, Jul 13, 2009


If Event Sub-Processes are not part of a Choreography diagram why all these 
references to Event Sub-Processes in Table 12-6

 Reported by dga...@trisotech.com, Jul 08, 2009

On p. 175 BusinesRuleTaskImplementation should be 
BusinessRuleTaskImplementation and
BuisnessRuleWebService should be BusinessRuleWebService.

Spelling of Business

 Reported by dga...@trisotech.com, Jul 08, 2009

Seems to be a copy/paste error

 Reported by dga...@trisotech.com, Jul 08, 2009

The two texts need to be reviewed

eported by dga...@trisotech.com, Jul 08, 2009

Cardinality of eventDefinitions is not same that in schema of page 290 and 
294

 Reported by asir...@trisotech.com, Jul 09, 2009

The Event Sub-process is not presented in the list of BPMN shapes, even if 
it has a distinctive aspect.

Comment 1 by dga...@trisotech.com, Jul 10, 2009

All shapes are presented in this section, but the Event Sub-process is not presented 
in the list of BPMN shapes, even if it has a distinctive "shape".

 Reported by dga...@trisotech.com, Jul 13, 2009

The first sentence under figure 11-4 says: In figure 11-3...
should be figure 11-4

 Reported by dga...@trisotech.com, Jul 13, 2009

The cardinality of parameterRef is specified as [1]. 
In other cases when attributes are required the cardinality is not 
specified

 Reported by dga...@trisotech.com, Jul 29, 2009

On p.243, the definition of EventDefinitionRefs and eventDefinitions is 
duplicated in ThrowEvent Table 10-76 and CatchEvent Table 10-75. 

All events either inherit from 
ThrowEvent or CatchEvent, so why not define these attributes in the Event 
class instead, in order to avoid duplication?

 Reported by dga...@trisotech.com, Jul 29, 2009

The attribute "name" is duplicated across many, many, many classes. 

Why not have a new "NamebleElement" class that specify the name or putting 
it in 
BaseElement instead of having it duplicated in many places?

 Reported by dga...@trisotech.com, Jul 29, 2009

Page 047, Section 7.2 Properties is presented as a Data element
Not sure we understand that one yet.

 Reported by dga...@trisotech.com, Jul 29, 2009

Under the title Fork: it is stated that "uncontrolled" flow is the 
preferred method 
for most situations is a questionable affirmation.

 Reported by dga...@trisotech.com, Jul 29, 2009

Under the title Merging : The text talks of the possibility of an 
alternative 
representation of a merge  (i.e two sequence flows entering an activity)
but does not 
depict it or specifies it as an implicit merge

 Reported by dga...@trisotech.com, Jul 29, 2009

These texts of those pages specifies that a Group is a grouping of 
Actiovities that are within the same category. In fact a Group is tied to 
the Category  supporting element (which is an attribute of all BPMN 
elements) (page 089).  Thus the texts are somewhat misleading.

 Reported by dga...@trisotech.com, Jul 29, 2009

The first structural specification bullet of section 7.4 refers to "Flow"
Where is "Flow" defined?

 Reported by dga...@trisotech.com, Jul 29, 2009

Both Adhoc and Transaction arepresented as specialized class of 
SubProcess, why not the same for Event SubProcess

On page 187, Figure 10-27, the attribute triggeredByEvent
defines if the sub-process is an event sub-process. But on page on p. 188
it is stated that an event is a specialized sub-process. If I take a look
at the model is says that an ad hoc and transaction can also be
event-sub-proceses.

Leads to confusion regarding possible Event based transactions or Event 
Based Adhoc

 Reported by dga...@trisotech.com, Jul 29, 2009

It would be good to have a depiction of the Multi-instance marker in the 
Vertical Pool layout

 Reported by dga...@trisotech.com, Jul 29, 2009

The example on p. 149 shows the multi-instance marker for a black box pool.
But there is no depiction of it for white box pools.

 Reported by dga...@trisotech.com, Jul 29, 2009

In Figure 10-57, we can see that the DataOutput has a isCollection 
attribute as well as in Table 10-54 on page 224. The DataOutput also has 
itemSubjectRef attribute that is inherited from ItemAwareElement. This 
attribute is of type ItemDefinition and specifies the isCollection 
attribute.

When we read the description on table 10-54 on page 224 for the 
isCollection attribute the following: "Defines if the DataOutput 
represents a collection of elements. This is a projection of the same 
attribute of the referenced ItemDefinition."

I wonder why we need to have it defined both in DataOutput and 
ItemDefinition if the attribute in DataOutput is the "same".

Is this denormalisation for the purpose of drawing a collection that has 
not be concretized by a ItemDefinition?

 Reported by dga...@trisotech.com, Jul 29, 2009

On p.246 of the specification, The EventDefinition used for each start
event type are explicitly listed. 

But in table 10-81 and 10-82 it is provided only for the None and 
Multiple.  For consistency it should probably listed in all of them here 
too.

 Reported by dga...@trisotech.com, Jul 29, 2009

Page 115 Structural Specifcation says that Any Message that is after the 
first on the list of Messages for a Choreography Task or Choreography 
Subproces.....

What about Collaboration Diagrams that do not include Choreography 
tasks...how do we determine Initiating and Non-Initiating

 Reported by dga...@trisotech.com, Jul 29, 2009

BPMN 2.0, term is Business Process Model and Notation

Same issue at page 40, section 7, 3rd paragraph.

 Reported by dga...@trisotech.com, Jul 29, 2009

The Lane depiction included in the table shows Lanes with single lines to 
seperate Lane name to Lane content.

According to structural specification of page 316, Section 10.7, these 
lines should not be there. Should the figure presented excludes these 
lines as shown in Figure 10-119 at page 317?

 Reported by dga...@trisotech.com, Jul 29, 2009

The sentence " Both Exclusive (see page 298) and Event-Based (see page 
307). " is incomplete and leads to confusion while reading the text.

 Reported by dga...@trisotech.com, Jul 29, 2009

At row "Compensation Association" the text indicates " .... or a throw 
Compensate Event". Throughout the document the term "Compensation Event" 
is used, should this text also use the term "Compensation Event" instead?

 Reported by dga...@trisotech.com, Jul 29, 2009

In figure 10-1 the throwing Link Intermediate Event and the catching Link 
Intermediate Event may lead to confusion to the reader, i.e. someone could 
think that they should be paired where probably this is a diagram fragment 
and they should not be paired.

The diagram presented is not a complete process but a fragment of a 
process due to the presence of Intermediate Link Events not paired and 
the "Discussion Cycle" Sub-process without not directing to a proper "End".

Should the diagram be replaced or an identification provided that it shows 
an incomplete fragment of a larger process? 

 Reported by dga...@trisotech.com, Jul 29, 2009

Section 10.1.2, first sentence reads: "Some BPMN elements are common to 
both Process and Choreography, as well as Collaboration; they are used in 
both types of diagrams."

Is the last part of the sentence, which reads: "they are used in both 
types of diagrams." applies to only two of them, which one are they? 

If not, the term "both" should be replaced by "all" or eliminated, or this 
statement reworked.

 Reported by dga...@trisotech.com, Jul 29, 2009

Sub-process markers are presented at pages 186-187. Does these markers 
(Compensation, Ad Hoc, Loop and MI) also apply to Call Activity and Event 
Sub-process? Is it none, some or all of them?

According to the Class diagrams a Call Activity could not be Adhoc, but 
since a Call Activity extends from Activity it could be Loop or 
Compensation or Multi-instance?

According to the same logic, an Event Subprocess could also have the same 
behavior plus Ad hoc.

We feel these explicit lists should be presented in the spec instead of 
inferred from the class diagrams.

 Reported by dga...@trisotech.com, Jul 29, 2009

In the last two structural specifications of page 244:
Should Event Sub-process be added to the exceptions that any other 
elements must not have incoming Sequence Flow when a Start Event is used?

 Reported by dga...@trisotech.com, Jul 29, 2009

The first sentence says:" A Start Event can also initiate an inline Event 
Sub-Process (see page 188). In that case, the same Event types as for 
boundary Events are allowed (see Table 10-79), namnely: Message, timer, 
Escalation, Error, Cancel, Compensation, Conditional, Signal, Multiple, 
and Parallel."

Cancel should be removed from the list.

 Reported by dga...@trisotech.com, Jul 29, 2009

In the structural specification on Sequence Flow Connections (page 251)it 
is written:"When a Start Event is not used, then all Flow Objects that do 
not have an incoming Sequence Flow SHALL be the start of a separate 
parallel path. 

Event Sub-process and Catching Intermediate Event Link are also exceptions 
to that?

 Reported by dga...@trisotech.com, Jul 29, 2009

At p. 192 of the specification, the TransactionMethod can be of type 
Compensate, Store,Image.

A small text describing these variants would be useful, since only stating 
terms can lead to various interpretation.

The same issue apply for the BPMN 1.2 specification at (p.281) B.11.19.

 Reported by dga...@trisotech.com, Jul 29, 2009

The third structural specifications for an End Event in page 253 reads:"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." 

Is a "Throwing Link Intermediate Event" an exception to this statement? 
And, should it be indicated?

 Reported by dga...@trisotech.com, Jul 29, 2009

The last two structural speficication at bottom of page 255 have errors. 
The first one has an extra sentence starting with If the Intermediate 
Event...

The second structural specification should not be there.

(BTW bullet should be diamonds here and many other places)

 Reported by dga...@trisotech.com, Jul 29, 2009

The sentence above Table 10-82 says: "Nine(9) of the eleven (11) 
Intermediate Event ...."
Table 10-82 shows 10 Events and not 9 and page 256 indicates and lists 
twelve (12) Intermediate Events.

 Reported by dga...@trisotech.com, Jul 29, 2009

In the structural specifications under "Activity Boundary Connections" the 
list of Intermediate Events that can be attached is provided (second 
structural spec.).
In the structural specifications under "Sequence Flow Connections" the 
same list is provided (first sttructural spec.).
Is it required to duplicate the list? 

The content of the list is different, Escalation is not included in the 
second list.

 Reported by dga...@trisotech.com, Jul 29, 2009

A structual specification says:"The Intermediate Events with the following 
Triggers MAY be used in normal flow: None, Message, Timer, Compensation, 
Conditional, Link, and Signal. Thus, the following MUST NOT: Canvel, 
Error, Multiple and Parallel Multiple."

However, Table 10-82 (page 259) says for both (Multiple and Parallel 
Multiple Events) "If used within normal flow, the event can catch ...".

Are Multiple and Paralle Multiple Events allowed on the normal flow?

Also Escalation is missing from the list of MAY be used in normal flow

 Reported by dga...@trisotech.com, Jul 29, 2009

At beginnig of section 11 it says: "The view includes two(2) additional 
graphical elements that do not exist in other BPMN views: A Communication, 
A CommunicationLink."

The title of section 11.7 at page 338 is "Communicaion Link", however the 
descriptive text anf Figure refer to "Conversation Link".

The graphical element a "Communication Link" should be  "Conversation 
Link"?

 Reported by dga...@trisotech.com, Jul 29, 2009

Figure 11-4 presents a list of Message Flows associated to the "Delivery 
Negotiations Conversation".

Are the message flows listed the correct depiction for the explosion of 
the Conversation?

If so shouldn't the conversation object have a [+]?
Are Message Flows graphical elements to be used in a Conversation diagram 
or was it presented exclusively to show the relation between two views?

 Reported by dga...@trisotech.com, Jul 29, 2009

Second structural specification should be "Call Conversation" instead of 
"Call Activity"

 Reported by dga...@trisotech.com, Jul 29, 2009

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

In addition the caption of the figure should be "Choreography Sub-Process 
with multi-instance Participants".

 Reported by dga...@trisotech.com, Jul 29, 2009

Second bullet of section 2.4.1 is: "Choreography diagrams, which includes 
the elements defined in the Choreography, and Choreography packages (see 
Chapter 10)."

The reference should be to Chapter 12.

Third bullet of section 2.4.1 See Chapter 143 should read Chapter 9

 Reported by dga...@trisotech.com, Jul 29, 2009

Figure 8-5 is named "Classes in the Infrastructure package".

This figure is presented in the section "8.2 Foundation".

Is the caption incorrect?

 Reported by dga...@trisotech.com, Jul 29, 2009

Can a Transaction Sub-Process be presented collapsed?
i.e with a + marker at the bottom center.

NB It is clear in the case of Event Subprocess

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

We agree to leave this issue in the wish list for the RTF
Disposition: Deferred

Many workflow systems are designed around the concept that there is a process context that holds variables shared by all activities within that context.  Since the swimming pool represents the process instance as a whole, there should be a way to associated process variables with the pool itself, which would be accessible by all activities within the pool.

The spec should clarify how a model can associate data objects with the process as a whole.

Page 26, Normal Flow row of Table 7.2 - Modeling activities that do not complete before process completion.

There are activities that are never ended - that is they have no natural completion, but are terminated only when the process itself is terminated.  Monitoring activities are like that.  If an activity is started, and there is never a conclusion of that activity, then this should be indicated by having no outbound arrow from the activity.  This activity is concluded only by the termination of the process as a whole.   For example, and process may have a main thread, but also split early and start a "monitoring" activity.  This monitoring activity is designed to stay active until the process is concluded for some other reason.  There is no way for the assignee of the activity to say "I am done monitoring this process" without the process itself being terminated. Since there is no "natural" end of the activity, there should be no arrow coming out of the activity node.  I am not sure if this is a requirement of the spec, but there is a common perception that it is a requirement, that all activities have an outbound arrow coming out of it.  

This request is that the spec include a statement that it is explicitly OK to not have an arrow out of an activity that has no natural end to its execution.  

If this is not agreed, the spec needs to explain how to model such activities.

Modeling Activities that are only ended by Events

There are activities that are only ended by events, thus the activity may have one or more events located on the border of the activity, but no "normal" non event exit of the activity.  

The request is that the spec include an explicit statement that the activity might have events on the border, but no other "natural" ending of the activity.

If this is not agreed, the spec needs to explain how to model such activities.

This is a style suggestion that will make diagrams clearer by removing redundant notations.  There is a "receive event" to receive any kind of communication.  For example, and event to receive a message.  Or an event to receive a signal.  Events are circles on the diagram.  Additionally, BPMN allows a "receive type" activity, that is a rounded rectangle that receives messages.  Receiving of a message seems more naturally to be an "event" and not an "activity" because an event is something that happens.  An activity is something you do, and receiving something is really just waiting and not doing anything.  So picturing receive an activity seems unnatural.  The redundancy to two ways to draw this causes confusion.  

The spec could encourage the use of a "receive event", and to deprecate the "receive activity".  Receive activity would still be allowed, but "deprecation" would put the standard on a path to eventually remove it, and would send a message to not use it or expect it to be there in the future.  

The figure 10-1 should be re-drawn to have receive message events instead of "receive activities".

The doctor/patient example in figure 7-3 should be redrawn to use receive events instead of the receive activities.

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

Many workflow systems are designed around the concept that there is a process context
that holds variables shared by all activities within that context. Since the swimming pool
represents the process instance as a whole, there should be a way to associated process
variables with the pool itself, which would be accessible by all activities within the pool.


The spec should clarify how a model can associate data objects with the process as a
whole.

There are activities that are never ended - that is they have no natural completion, but are
terminated only when the process itself is terminated. Monitoring activities are like that.
If an activity is started, and there is never a conclusion of that activity, then this should be
indicated by having no outbound arrow from the activity. This activity is concluded only
by the termination of the process as a whole. For example, and process may have a main
thread, but also split early and start a "monitoring" activity. This monitoring activity is
designed to stay active until the process is concluded for some other reason. There is no
way for the assignee of the activity to say "I am done monitoring this process" without
the process itself being terminated. Since there is no "natural" end of the activity, there
should be no arrow coming out of the activity node. I am not sure if this is a requirement
of the spec, but there is a common perception that it is a requirement, that all activities
have an outbound arrow coming out of it.


This request is that the spec include a statement that it is explicitly OK to not have an
arrow out of an activity that has no natural end to its execution.


If this is not agreed, the spec needs to explain how to model such activities

There are activities that are only ended by events, thus the activity may have one or more
events located on the border of the activity, but no "normal" non event exit of the activity.


The request is that the spec include an explicit statement that the activity might have
events on the border, but no other "natural" ending of the activity.


If this is not agreed, the spec needs to explain how to model such activities.

This is a style suggestion that will make diagrams clearer by removing redundant
notations. There is a "receive event" to receive any kind of communication. For
example, and event to receive a message. Or an event to receive a signal. Events are
circles on the diagram. Additionally, BPMN allows a "receive type" activity, that is a
rounded rectangle that receives messages. Receiving of a message seems more naturally
to be an "event" and not an "activity" because an event is something that happens. An
activity is something you do, and receiving something is really just waiting and not doing
anything. So picturing receive an activity seems unnatural. The redundancy to two ways
to draw this causes confusion.


The spec could encourage the use of a "receive event", and to deprecate the "receive
activity". Receive activity would still be allowed, but "deprecation" would put the
standard on a path to eventually remove it, and would send a message to not use it or
expect it to be there in the future.


The figure 10-1 should be re-drawn to have receive message events instead of "receive
activities".


The doctor/patient example in figure 7-3 should be redrawn to use receive events instead
of the receive activities.

This is a style suggestion to make diagrams clearer. The XOR gateway allows two forms
of diagram: empty diamond, and a diamond with an X in it. While redundancy is OK in
general, the fact that different vendors make different choices. But an X and a cross look
very similar.


While the X should be allowed, the spec should indicate that it is preferred to use the
blank option, with the eye to eventually eliminating the X.

XSD Schemas for transfer of Model instances of DI and DD Metamodels


Source: Tom Rutt (Fujitsu)


Location: BPMN 2.0 Beta 1 ­ Annex B


Summary of Issue:


In the current BPMN 2 spec, Model instances of the BPMN2 Metamodel have two
alternate forms for transfer:
- XMI derived directly from the BPMN 2 Metamodel
- Instances of the BPMN XSD schemas defined in BPMN 2 spec.


The current Annex B of the Beta 1 BPMN 2 spec defines metamodels for Diagram
Interchange (DI) and Diagram Definition (DD). However there are no BPMN XSD
schemas defined for the DI and DD metamodels. Thus, it seems that XMI derived
from these DI and DD metamodels currently the only normative way defined to
transfer Model instances of these metamodels?


The current plan is that this Annex B will be replaced with a reference to the
adopted DI spec.


Resolving issue involves the FTF answering two questions:


1) Is there a need to define “custom” XSD schemas, not based on XMI, as an
alternative for transfer of DI and DD model instances.
2) If the answer to question 1 is yes, will these “custom” XSD schemas be
defined by the BPMN 2 FTF, or the DI submitters?

The text attribute is missing from the Documentation element of the v 0.9.14 Semantic.xsd schema. Thus no text description of a BPMN element can be captured by the provided schema

In the schema, the substitutionGroup relation is place between the expression element and the formalExpression element, not the types. Thus elements of type expression do not benefit from the substitutionGroup. (e.g. activationCondition in the complexGateway is of type tExpression and thus cannot accept a formalExpresion).

In the Semantic.xsd schema, the baseElement has its Id attribute as optional. This has the effect by inheritance that all elements have optional Ids.

Although Figure 8-5 and Table 8-5 does not speficy this attribute as required, I believe it should be???

Consider swim lanes representing performers.


- The spec states that the Lane.partitionElementRef would reference a Performer. This won't work since Performers are owned by Activities. Hence would result in a different Lane for every Activity.
Instead the Lane.partitionElementRef should instead reference a Resource, which multiple Performers may reference.

- The XSD defines Lane.partitionElementRef as an IDREF. It should instead be a QName, to allow references to a Resource in a different Definitions file.

I have looked at a few sample BPMN2.0 xml instances, such as those in the draft spec, those in the book 'BPMN Method and Style', and others found on the web.


In all cases, SequenceFlow elements are shown with a sourceRef and a targetRef, but no id. This seems reasonable.


However, I have now discovered that, to specify a 'default' SequenceFlow for an Inclusive or Exclusive Gateway, you must populate the 'default' attribute of the Gateway with a reference to the SequenceFlow. As I understand it, this reference must refer to the id of the SequenceFlow.


This seems unnecessarily complicated. To me, the obvious way of specifying a default SequenceFlow is to have a boolean attribute on the SequenceFlow itself, defaulting to false.

If there is a good reason to specify it as a reference on the Gateway, I would have thought it would be good practice to always assign an id to a SequenceFlow. Otherwise, to make one of them a default, you have to, first, assign an id to it, and then use the id as a reference on the Gateway. This seems awkward.

businessRuleTask  Element (Semantic.xsd vs. v0.9.14, sect. 10.2.3, Table 10-11, p175) 
The businessRuleTask element in the BPMN 2.0 schema file Semantic.xsd is missing the implementation attribute of type BusinessRuleTaskImplementation as per the specification documentation.

Page 204, Table 10-26, There seems to be an error in providing an attribute called noneBehaviorEventRef, it should be allBehaviorEventRef....? Futhermore a complexBehaviorEventRef attribute would be missing....?

But why do we need multiple ***BehaviorEventRef attributes? Couldn't we just have a BehaviorEventRef attribute that is used for either one, all or complexe?

Page 161, Table 10-3, Error in attribute name.  "resources" should be "activityResource"

Page 160, Figure 10-6 vs. Table 10-3. The "property" class is not depicted in the class diagram (Figure 10-6) but listed in the attribute (Table10-3).

Page 161, Table 10-3, Issues regrading properties: 1)The text describes properties as being "local" to the activity, yet contibues to mentione a deliation with the activity name as a prefix.  If it is local why would we need the activity name as a prefix?
2) Although I uderstand using the name of the peorperty for presentation in a tool interface, we do not have a guarantee that the name will be unique.

In BPMN Core Structure, Common Elements,
Message, second figure, text underneath
refers to a list of messages for a
choreography task, but the association
between ChoreographyTask and MessageFlow
is not ordered.  Or the initial message
flow of a Choreography Task could be
identified by a new association if it is not 
intended to order all the messages.

PDF page 337, page 307:
"A single MEP is defined as a BPMN Choreography Task (see page 350). Thus, a Choreography defines the order
in which Choreography Tasks occur. Choreography Sub-Processes allow the composition/decomposition of
Choreographies."


If the MEP has a request, response and multiple faults how will the choreography identify which subsequent path based on a decision relates to each response.


Would propose changing wording to "A single MEP can be defined ..." - allowing an MEP to be defined across separate Choreography Tasks, enabling the decision point and relevant paths based on each response type to be explicitly defined in the choreography. However this may require some additional mechanism to correlate the separate choreography tasks as belonging to the same MEP.

A Choreography Task now can have only two Participants. But there are situations where one Participant may send the same message to more than one other Participant. Multiple Choreography Tasks would be needed to do this, where it could be done with one if this change was made

There is currently a mismatch between the target namespace of the XML Schemas in the spec (PDF) and the XML Schemas files (XSD) themselves. This applies to Beta 1.

 

In the PDF specification that are several instances where the target namespace for the XML Schemas is defined as “http://www.omg.org/bpmn20”:

-          Table 8.2 (page 44)

-          Table 8.16 (page 53)

-          Table 10.19 (page 150)

 

However the latest available XML Schemas (bmi/09-05-05) have the target namespace set to “http://schema.omg.org/spec/BPMN/2.0”.

 

If the XML Schemas are correct then the specification should reflect the same target namespace.

maybe I’m wrong, but it seems there’s a logic error in the PDF document mentioned above:

 

-       Figure 12.36 shows a Choreography starting with communication from A (initiator) to B. Depending on message content based decision next message will be sent from A to B (decision YES) or from A to C (decision NO).

-       Comparing that to the corresponding Collaboration in Figure 12.37 I detected a mismatch, within Pool A the gateway acts inverse: If decision YES message M3 will be sent from A to C, and if decision NO message will be sent from A to B

-       Looks like content of pool A should be adapted (decision YES should result in message from A to B)

 

Furthermore there seems to be an offset to Figure indices listed in some chapters vs. the real Figure numbers:

 

-       Check chapter 10.2.8 (Loop Characteristics in Process Diagrams)

-       Scroll to page 169 (PDF document page 199), chapter Standard Loop Characteristics

-       You will find a link to Figure 10.42 and 10.43 (see Figure 10.42 and Figure 10.43)

-       Corresponding figures instead are 10.43 and 10.44

-       This offset stuff starts somewhere before in the document, maybe an additional picture has been added

 

In the semantic.xsd and in the spec document chapter 10.2.7 vs chapter 10.2.9.  The schemas for the globalSendTask, globalReceiveTask and globalSendTask are missing.  This is related to another reported issue that the class diagram Figure 10-40 on page 199 is also missing these corresponding classes

Page 326 of pdf: para below Figure 11.4 refers to "(keyed on Variable Id and Order Id)", however the figure 11.4 uses Variation ID and Order ID.


Proposal: change "Variable Id" in paragraph to "Variation Id".

The participant bands of Choreography Activities have different shadings, but chapter 12 does not define the shadings or the reasons. The differences are shown in a figure, but not defined in the text.

The URL given for the WfMC Gloassary in section 3.2 is incorrectly shown as 
http://www.wfmc.org/standards/docs.htm

I would suggest that either http://wfmc.org/wfmc-standards-framework.html or just http://www.wfmc.org is used.

The URL used to reference the XPDL specification is incorrectly given as http://www.wfmc.org/standards/docs.htm

Instead I would suggest either http://wfmc.org/wfmc-standards-framework.html or http://www.wfmc.org

The second sentence of the first paragraph in section 7.2 states: "The goal of
the specification is to enable portability of Process definitions, so that users can take Process definitions created in
one vendor’s environment and use them is another vendor’s environment."


The final part of the sentence should read "and use them in another vendor’s environment."

i.e. "is" should become "in"

It should be possible to add correlation to
choreography, without creating a conversation.
Sometimes interactions are only described with
choreograpies, and they might need correlation

The concept of conversation is muddled in the idea of a logical grouping of message flow and a diagram that contains a set of these groupings. Conversations should be a light-weight element defined to be used in any diagram that has message flow.

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

The first para at the top of page 212 lists the possible item-aware elements but is missing the DataSore as per the class diagram below it Figure 10-46

The section discussing States of DataObject at the bottom of page 213 refers to Figure 7-8 to examplify the visualization of a DataState attribute of a DataObject but fails to specify the details of this visualizaton (i.e. in this particular case using square brackets surrounding the DataState value).

Or is the visualization left to the vendor tool?

In the Lifecycle and Visibility section of Properties, the second para is misleading.  The Para starts with "The visibility of a Property"  this may lead to the misconception that Properties have depictions, which they don't.  The para also refers to Process as flow elements and the scope example below does not really present the concept very well.

Section(s) of Spec: 10.2.3
  
Sub-Team responsible: 

Type: Editorial

Description of issue: 
Section 10.2.3 says "A User Task is a typical "workflow" Task where a human performer performs the Task with the assistance of a
software application and is scheduled through a task list manager of some sort."
The second part of this sentence is not correct. It could not be that every User Task has to be scheduled through a task list manager. E.g. there are User Tasks where the user has to go to a system, open a transaction and enters some data. On complete and event is fired that tells the process engine that the task is completed.
I consider this kind of task as a User Task as well, even though it is not scheduled through a task list manager.

Proposal: Can we relax or remove the second part of the sentence?

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.

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?

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.

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.

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.

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.

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.

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

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

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.

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.

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

Close, no change. The spec already allows putting private process in collaborations.
Disposition: Closed, No Change

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

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

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

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.

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? 

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.

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

Spec v0.9.14.

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

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

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.

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.

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

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

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.

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.

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

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

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.

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.

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.

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

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.

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.

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.

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

Comments:
From: ssamoojh@ca.ibm.com created: Thu, 28 May 2009 17:57:44 -0500 (CDT)
Actually I was just about to open an issue, suggesting we rename "Interface" to "Service Interface", given that "Interface" is generally an overloaded term.

From: conrad.bock created: Fri, 29 May 2009 08:15:35 -0500 (CDT)
True, although I think it's less overloaded than "service", which has a
very different business meaning than in software.  I thought "operation"
was more neutral, and it's what is actually invoked by a Service Task
(see the operationRef attribute on ServiceTask).

Collaborations and other C models might be in reusable libraries, but
currently their participants cannot be linked to multiple entities, and
cannot be linked with modifying the C model.  For example, a
collaboration might describe a contract that many entities can enter
into.  This contract might be in a library and not be modifiable.
Entities should still be able to refer to participants in it to indicate
they commit to the contract.  This commitment is made jointly by
multiple entities, each linked to their own participants.

Since it inherits from a base element with mixed content, it does not need to define itself as mixed.

Comments:
From: ssamoojh@ca.ibm.com created: Tue, 19 May 2009 11:47:40 -0500 (CDT)
The 'mixed' setting does not need to be redeclared. It is transitively inherited.  tExpression inherits it from tBaseElementWithMixedContent.  tFormalExpression also (and thus it does not need to be redeclared there).

So there's a minor consistency issue (with tFormalExpression), but no technical issue to my knowledge.

[Reducing the severity based on this information.]

From: mariano.benitez created: Tue, 19 May 2009 12:23:01 -0500 (CDT)
suggest to defer but agree the resolution (remove mixed=True from tFormalExpression)

From: mariano.benitez created: Thu, 6 Aug 2009 09:20:03 -0500 (CDT)
Testing notification scheme

The XML-Schema type for elements "from" and "to" in complex type "tAssignment" is 
"tBaseElementWithMixedContent". However this type is declared abstract and forces to specify 
a xsi:type attribute for elements "from" and "to".
The proposal is to use a non-abstract XML-schema type for "from" and "to" elements. A good
candidate would be "tExpression" which is a non-abstract extension of "tBaseElementWithMixedContent":
	<xsd:complexType name="tAssignment">
		<xsd:complexContent>
			<xsd:extension base="tBaseElement">
				<xsd:sequence>
					<xsd:element name="from" type="tExpression" minOccurs="1" maxOccurs="1"/>
					<xsd:element name="to" type="tExpression" minOccurs="1" maxOccurs="1"/>
				</xsd:sequence>
				<xsd:attribute name="language" type="xsd:anyURI"/>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>	

The Correlation Subscription concepts in the spec are difficult to follow and understand.

We need improved explanations in the spec, with descriptions of when and how someone would use this, and the motivations behind it.

Comments:
From: wstephe created: Fri, 24 Jul 2009 13:05:02 -0500 (CDT)
Yes, Section 8.3.3 (V0.9.14) needs a complete overhaul.

The CatchEvent has a "parallelMultiple" attribute, but it's not listed in the table in the spec. Table 10.75 on page 212 (242 pdf).

Comments:
From: wstephe created: Wed, 23 Sep 2009 16:52:11 -0500 (CDT)
The Section and page numbers were added to match the Beta 1 spec.

It states that the name of the Category provides the label for the Group.  And yet Category does not have a name attribute.  So where is the name coming from.

Also, given that Group references CategoryValue (and not Category), shoudn't the Group label be the CategoryValue.value, rather than the Category name?  In Figure 8-14, what is "Handle Medicine" ... is it a Category name or a CategoryValue.value?

Beta 1 spec page 238 (268 pdf) states that:
"When one of the EventDefinition sub-types (e.g., TimerEventDefinition) is defined it is contained in Definitions."

This is of course incorrect, since an EventDefinition can be contained by either the Definitions or the Catch/ThrowEvent.

Comments:
From: wstephe created: Wed, 23 Sep 2009 17:03:15 -0500 (CDT)
The page number was updated to match the Beta 1 spec

Filed for Frank: The supports association between processes should have
a notation

The Process does not have a way to have a resource, e.g., a supervisor, assigned. Thus, a ProcessResouce, similar to the ActivityResource, should be added.

Comments:
From: wstephe created: Wed, 23 Sep 2009 17:04:05 -0500 (CDT)
This is suitable for the FTF

>  Terminology is perhaps the hardest part of standards such 
 >  as BPMN. There is no way to pick terms that will be 
 >  acceptable to all potential users of BPMN. Different groups 
 >  will come into BPMN with different expectations. Some of 
 >  the terms will fit those expectations and other will not.
 > [From <a href="http://www.omg.org/archives/bpmn2-eval/msg00048.html">http://www.omg.org/archives/bpmn2-eval/msg00048.html</a>]

In this particular case, the submission has one already ("item", as in
ItemDefinition, ItemAwareElement, and ItemKind), introduced to
accomodate informational and physical flows.  I think it would be good
to have uniform terminology covering both information and physical
things, for example:

  Message Flow => Item Flow
    (Message appears redundant with ItemDefinition, or Message could be
     a subclass of ItemDefinition for those items that happen 
     to be used in Item Flows)
  Data Object => Item Object
  DataInput => ItemInput
  DataOutput => ItemOutput
  DataState => ItemState
  DataAssociations => ItemAssociations

So much of BPMN's market is modeling businesses in general rather than
business software specifically, that I think it's important for adoption
to have the appropriate terminology.

Add a description of how a tool might conform to Process Execution independent of Process Modeling Conformance.

There is some redundancy in the definition of Choreography Activities. For example, Participants are listed as well as MF, which have source and targer Participants. Also, for one-way Tasks, the initiating Participant can be derived from the MF.

The current DI model doesn't specify the Participant Bands of the shape and should be added. These bands can vary in shading and Association connections to the shape (of a Message) are dependent on the sender of the Message (i.e., the Participant of the appropriate Band).

Comments:
From: trickovic created: Wed, 6 May 2009 03:41:57 -0500 (CDT)
As per 5/4 BPMN team meeting - the issue to be deferred. 

The metamodel does not have a element for DI to use for connecting
ChoreographyActivity and Message (derivable from ChoreographyActivity to
Message Flow to Message).  Associations should not be used for links
that are derivable from the semantic metamodel.

Comments:
From: trickovic created: Wed, 6 May 2009 03:38:35 -0500 (CDT)
As per 5/4 BPMN team meeting - the issue to be deferred.

DataAssociations  and Assigments correctly allow mapping between data elements.

Now, there is no way to do a simple mapping of a literal to a data input.

An assignment could be used to solve the problem, but then you are forced to include a dummy sourceRef to fullfil the requirement of at least one source ref.

A simple solution would be to allow 0 zero source refs, and keeping the restriction of the scope of the assignment to the souce refs.

Comments:
From: trickovic created: Wed, 6 May 2009 04:28:07 -0500 (CDT)
As per 5/4 BPMN team meeting - the issue is valid but to be deferred. 

From: mariano.benitez created: Wed, 2 Sep 2009 15:19:27 -0500 (CDT)
testing comments... sorry

[OMG 14718] XSD DataAssociation should own source and target refs and mistake in text spec

##Source: Oracle (Mariano Benitez, mariano.benitez@oracle.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-501
##Original Info: (Severity: Significant - Nature: Revision)

According to the spec text, DataInputAssociation and DataOutputAssociation do not define any attribute.

In the XSD they both own define sourceRef and TargetRef. 

These elements should be part of the parent class. (there is no problem in moving them up since both definitions are similar (cardinality and types).

Also:

In page 202 of Beta 1 it says:
"The DataInputAssociation element inherits the attributes and model associations of *FlowElement* (see Table 10-62), but does not contain any additional attributes or model associations."

But it should say DataAssociation.



Comments:
From: mariano.benitez created: Tue, 5 May 2009 09:05:19 -0500 (CDT)
Proposal for text fix, just replace flowelement with dataassociation.

From: mariano.benitez created: Tue, 5 May 2009 09:06:35 -0500 (CDT)
Steve, I just attached the fix for the text issue, can you apply it?

Regarding the MM (XSD) change, it's not that critical to add it, but it could help.

From: trickovic created: Wed, 6 May 2009 04:27:47 -0500 (CDT)
As per 5/4 BPMN team meeting - the issue is valid but to be deferred. 

The spec says that there must be one InputSet for an ioSpecification. The schema has the minOcurrs at 0. The schema should be changed so that minOccurs is 1.

##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-494
##Original Info: (Severity: Significant - Nature: Revision)

tActivityResource::resourceRef is a required attribute, but should be optional - in case the resource is resolved via a ResourceAssigmnentExpression there won't be any statically assigned resourceRef (except for a dummy, which is how I resolved the problem in the example).

         <performer resourceRef="dummy">
           <!--Issue: If specified via an expression, a resourceRef is not needed, i.e., the attribute must not be required.-->
           <resourceAssignmentExpression>
              <formalExpression>getInputData()/resource</formalExpression>
           </resourceAssignmentExpression>
        </performer>

##Source: IBM (Matthias Kloppmann, matthias-kloppmann@de.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-493
##Original Info: (Severity: Significant - Nature: Revision)

Correlation properties are specified by means of name and type, e.g., orderID of type integer, or customerName of type string. The properties may typically be specified by means of their name and type only, while retrievalExpressions are added only later, and modified independently. The latest version of the spec dropped name and type.

Resolution proposal: Re-add correlationProperty::name and ::itemRef.

These attributes of the TimerEventDefinition are expressions, there is no mention of the result type. Also it would be useful to describe how this values are used (timeDate defines the next moment the time will trigger, while timeCycle defines an interval that is added to "now" to define the next moment).

Another thing that is not described is the moment when theses expressions are evaluated. Intuitively I think it is in the moment after the trigger is executed, and for the first time, the moment it is activated.

Following the BPEL mapping, the timeDate expression should return an XSD DateTime element and the timeCycle an XSD Interval (Period). 

I think it is necessary to clarify this in the execution semantics so people understand what type of behaviour is expected from this event.

I can make the changes if necessary.

In this section there is the following text: "They execute synchronously and after their completion, the hosting Activity is immediately canceled."

This means that the parent process will continue work while the Event SP is active, which could be a long time. If the triggering Event is an error, this doesn't make much sense. Note that the Execution Semantics section doesn't specify when the parent activity is terminated.

------------------------------ Proposal ---------------- 2009-04-15 -------------------------------------

Modify text so that it states that the activity of the parent Process is terminated when the interrupting Event SP is triggered

OMG 14724] Beta 1: Section 10.4 Events: Statement "Signals are triggers generated in the Pool they are published" needs clarification

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

in the Concepts sub-section there is the following statement: "Signals are triggers generated in the Pool they are published."
This is not clear. It implies that Signals are limited to being sent and received in the same Process, which is not true.

This was generated from the example for <a href="http://www.osoa.org/jira/browse/BPMN-329" title="Provide example: Process within Collaboration">BPMN-329</a>.
The current examples of Choreography show Messages connected to ChoreographyTasks through Associations. However, there are additional semantics to these connections. The semantics could be derived from the ChoreographyTask definiition, but we should investigate whether the display of the Message on the diagram requires any additional MM changes or whether this is purely a diagram display issue.
Section 12, Beta 1 Spec

Names are  not require for all DataInputs and DataOutputs. Names would be used mainly for the ones that are shown graphically on the diagram. 

Consider a Call Activity that invokes another Process:
    <callActivity id="CallActivity"
                  calledElement="tns:CalledProcessNotServiceEnabled"> 
      <dataInputAssociation>
        <sourceRef>MyOrder</sourceRef>
        <targetRef>Order</targetRef> 
      </dataInputAssociation>
      <dataOutputAssociation>
        <sourceRef>Result</sourceRef>
        <targetRef>MyResult</targetRef>
      </dataOutputAssociation>
    </callActivity>
In above sample, the targetRef of the data input association refers to a DataInput object of process 'CalledProcessNotServiceEnabled'
and the sourceRef of the data output association refers to a DataOutput object of the called process.

The proposal is to modify the XML-Schema type of sourceRef and targetRef from xsd:IDREF to xsd:QName to allow references to 
processes and global tasks data input/output that appear in potentially separate BPMN definitions.

In Data Assignment, the 'from' and 'to' attributes are Object. The Assignment class should be modified as following
1. Remove 'language' attribute
2. Data Type of 'from' and 'to' is FormalExpression

Apart from that, the attribute 'evaluatesToTypeRef' in FormalExpression class should be optional

As per discussion in examples working session on 2009.03.26

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>

Documentation and the scripts are formatted text, we should keep the format (spaces, tabs) that the user defined.

Storing formatted text as string attributes makes it impossible to do so, since it turns the attributes quite big and looses the format.

It would be better if we store any formatted text as a CDATA element, so we can easily keep the format.

Proposal: change the XSD for documentation, script task and formal expressions to use a CDATA element instead of a string attribute.

Lanes are pat of process modeling and should be described in the Process section.  They
are currently documented in the Collaboration chapter, which happens to use process models.

Comments:
From: wstephe created: Tue, 14 Apr 2009 10:30:41 -0500 (CDT)
The resolution to this issue was applied in V0.9.9.5

Association has a source and target of BaseElement which should inherit
to DataAssociation, instead of being defined again on Data Association.

From the human interactions example:
Need to add business-level presentation attributes known from BPEL4People, namely subject and description. This should include the ability to specify presentation parameters - needs discussion. Without these, the user task capability is not rich enough for serious direct execution, but will always require mapping to and enrichment in BPEL4People.

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 activities this capability. 

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

Comments:
From: wstephe created: Wed, 11 Feb 2009 23:49:01 -0600 (CST)
For example, a Process/Collaboration defines a Participant/Role named "Seller." This Process/Collaboration is called into another Process/Collaboration that has a Participant/Role named "Retailer." In the context of the parent, "Retailer" and "Seller" mean the same thing. This means that "Seller" needs have an alias to align it with "Relailer."

From: conrad.bock created: Thu, 12 Feb 2009 10:11:03 -0600 (CST)
I thought the use case for aliases was a role or entity in a defintions
file that imports another role or entity that happens to have a
different name, but arethe same thing.  For example, maybe an entity is
"IBM" and the imported entity is "International Business Machines".  The
alias for the import could be "IBM".  But this would cause a namespace
conflict, if definitions are namespaces.  Maybe it would be better to
have some way of linking the entities to say they are the same thing,
rather than depending on the name, not sure.

From: conrad.bock created: Tue, 17 Feb 2009 15:47:27 -0600 (CST)
Steve suggests this should be available within the same definition file.

From: ings_osoa created: Tue, 10 Mar 2009 11:06:49 -0500 (CDT)
Steve suggested that it be assigned to Suzette and Suzette agreed. Suzette will consult with Steve on the use cases.

From: ssamoojh@ca.ibm.com created: Sun, 15 Mar 2009 18:49:41 -0500 (CDT)
The use-cases I'm aware of appear to have simple solutions.  But it's possible I don't understand the full scope or all use-cases.  For now, let me cover the ones that I know of, and their possible (seemingly simple) solutions.

Use-case 1:  A Participant that references a Role/Entity, but which requires a contextual alias.
Possible solution:  Use the Participant.name attribute.  If specified, it serves as the alias. If unspecified, the name is derived from the name of the Role or Entity.

Use-case 2:  A CallActivity that references CallableElement, and which requires a contextual alias.
Possible solution:  Use the inherited FlowElement.name attribute.  If specified, it serves as the alias.  If unspecified, the name is derived from the name of the CallableElement.

From: ssamoojh@ca.ibm.com created: Wed, 18 Mar 2009 15:51:22 -0500 (CDT)
Attaching "Credit Check Example V5.ppt" for reference.  But I don't believe this is a candidate for "aliasing" since, as stated on slide 12, the scenario covers two different Roles.

From: conrad.bock created: Thu, 19 Mar 2009 11:11:00 -0500 (CDT)
Suzette,

The alias refers to the entities, roles, and processes/global tasks,
rather than the participants and call activities.  These might have
different names in separately developed definition files, even thought
they're the same thing in reality.  I hink the suggestion is to support
aliases on import (ie, the import itself will give a new name to the
imported element in the receiving definition file).

Conrad

From: ssamoojh@ca.ibm.com created: Fri, 27 Mar 2009 16:35:13 -0500 (CDT)
Reducing priority, since it looks like the new ParticipantAssociation class may address this requirement.
I won't close the issue just yet, in case we find that there is still need for more, beyond what the ParticipantAssociation covers.

From: conrad.bock created: Mon, 30 Mar 2009 09:27:36 -0500 (CDT)
Suzette,

Lower priority is fine for me, although ParticipantAssociation does not
address this really.  ParticipantAssociation is for equating
participants in certain situations, like calling choreographies, whereas
the issue is about equating any elements in all situations.  I expect
the issue will be deferred.

Conrad

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

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?

Comments:
From: mkloppmann created: Thu, 29 Jan 2009 15:11:47 -0600 (CST)
IMO, the meta-model defines the data entities and their relationships, as the base for the "BPMN 2.0 language" the spec defines, in two dialects, XMI and XML. Instances of this language are used as a means to transport the semantic information between vendors' tools (and runtimes).

How those language instances are used beyond transporting them between tools and runtimes is beyond the scope of the specification; in particular how a particular vendor's implementation accesses them, which access paths are used etc. As such, the meta-model shouldn't mandate whether links are navigable or not, just express relationships. The same holds for the XSD representation.

Pragmatically, IMO this means that any 1 to n relationship should be navigable only from the "n side" to the "1 side", with the additional benefit that this results in the "expected" XSD mapping.

(This occurs indeed several times -- another example is the relationship between activities and sequence flows. While it's natural that a sequence flow identifies its single source and target, there is no need to also instantiate the redundant information per activity which incoming and outgoing sequence flows it has -- which the current XSD requires.)

From: ssamoojh@ca.ibm.com created: Thu, 29 Jan 2009 16:43:41 -0600 (CST)
I agree with Matthias on the first two paragraphs.

I tend to agree with the third (and fourth) paragraphs, but would prefer to do a sweep through the MM, see if there are any exceptions, before we apply this as a global design principle.


From: trickovic created: Fri, 30 Jan 2009 04:35:04 -0600 (CST)
As per 1/29 BPMN Examples meeting: The issues moved to "open" and assigned to Suzette. 

From: david_marston created: Sun, 1 Feb 2009 21:25:22 -0600 (CST)
I tend to disagree with Matthias' fourth paragraph. If he is saying "there is no need" in the sense that the other direction can be calculated before any structural interpretation that is node-centric, then I would concede that point with some qualifiers. In the type of pragmatic transformation I do, I generally take a node-centric approach. I "need" the references from the node-centric point of view. See <a href="http://www.osoa.org/jira/browse/BPMN-410" title="The case for Flow Objects owning references to flows in or out">BPMN-410</a> for a longer treatise on the relation between gateways and sequence flows.

From: rmueller created: Sun, 1 Feb 2009 21:45:59 -0600 (CST)
I agree with Matthias here but would love to see more examples and one round through the MM before we modify the XSD's, maybe on a case-by-case basis.

From: ssamoojh@ca.ibm.com created: Tue, 3 Feb 2009 14:02:06 -0600 (CST)
In the Feb 2nd meeting, the group agreed to the following:
  -  The ServiceReference-&gt;Interface should be removed from the XSD.  In the MM, it would be marked as 'derived'.
  -  This approach could likely be applied to other similar cases.
  -  To Do [for Suzette]:  Do an initial pass over the MM and identify similar cases.  Work with the subteams to determine if the 'derived' solution applies to their individual cases.


From: trickovic created: Tue, 7 Apr 2009 04:01:07 -0500 (CDT)
As per 4/6 BPMN 2.0 meeting: Defer <a href="http://www.osoa.org/jira/browse/BPMN-413" title="Relationship navigation (both in MM and XSD)">BPMN-413</a>.

From: wstephe created: Fri, 25 Sep 2009 16:04:59 -0500 (CDT)
Updated section to match Beta 1 spec

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"

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.

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.

I believe we need to be more clear/explicit when describing several aspects of compensations. I base this on 0.9.2

- We should made clear on each case what context is used in compensation. This is a refinement of the snapshot concept, but it needs clarification in this cases:
-- Boundary event handlers: it only mention "black-box" compensation, when it should clearly state that the current state is used.
-- inline event sub-processes: they mention the snapshot when the process is completed, but there is no mention to the case when the compensation is triggered while the subprocess is still running. Also it should be described that the parent scope used in the compensation is the current one, even when the compensated subprocess uses the snapshot context.

[OMG 14750] [Section 10.2.3] Editorial: protocol attribute on the transaction subprocess class seems to have a wrong description - TransactionMethod values not explained
This is the description Transaction->protocol attribute in 0.9.2 (page 156):

The elements that make up the internal Sub-Process flow.
This association is only applicable when the XSD Interchange is used. In the case
of the XMI interchange, this association is inherited from the
FlowElementsContainer class.

Also, the TransactionMethod values are not fully explained. I can infer compensate, but I don't understand Store or Image.

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.

Comments:
From: conrad.bock created: Fri, 19 Dec 2008 11:08:32 -0600 (CST)
The first figure attached is Maged's showing the option taken for
expediency in the IOS submission (option "1").  The second is Maged's
showing his team's submission to ADTF Diagram Type Definition.  The
presentation files are attached covering the two options and the IBM
submission to ADTF.

From: bruce created: Fri, 19 Dec 2008 17:03:34 -0600 (CST)
I have a feeling this could take many months to resolve.  Currently DI specifies 2 kinds of information: 1) graphics info about elements in the semantic model, i.e. position and size of shapes, connector bendpoints, etc.; and 2) ALL info about elements not in the semantic model, e.g. lanes, annotations, and proposed pages (<a href="http://www.osoa.org/jira/browse/BPMN-390" title="Add 'page' root element in DI"><strike>BPMN-390</strike></a>).  Standardizing exchange of graphics is not as important as the ability to include core information that has always been in BPMN BPDs.  If DI is delayed for resolution of this issue, I would like to see lanes, annotations, pages, and other info currently in DI moved to the semantic model so they can be included in BPMN 2.0 from the beginning.

From: conrad.bock created: Fri, 19 Dec 2008 18:15:36 -0600 (CST)
Assuming DI is finished in the current spec, the alignment with DTD
wouldn't be hard, as I understand it from Maged.  If it's not done in
the current spec, then there's alot of work to do anyway.  OMG won't
accept two ways of exchanging diagrams.

I don't agree about diagram interchange not being important.  Losing
diagrammatic interchange for a graphical language means there really is
no interchange, except for analysis.

Lanes should be in the metamodel in any case, see
<a href="http://www.osoa.org/jira/browse/BPMN-264">http://www.osoa.org/jira/browse/BPMN-264</a>.


From: conrad.bock created: Tue, 6 Jan 2009 14:53:01 -0600 (CST)
Oliver (I think) said at the January 5 meeting that Maged mentioned the
above to him and would be drawing up a sketch for a proposed solution.

From: ings_osoa created: Wed, 14 Jan 2009 16:28:44 -0600 (CST)
384 open issue assign to Oliver note that goal is architectural alignment to facilitate future migration but *not* detailed class mapping

From: trickovic created: Mon, 2 Feb 2009 04:41:02 -0600 (CST)
"BPMN-DI-DD.ppt" slide deck provides additional information.

From: oliver.kieselbach created: Mon, 2 Mar 2009 11:00:48 -0600 (CST)
The new Architecture has been applied to spec version 0.95 section 12

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)

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.

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

Comments:
From: ssamoojh@ca.ibm.com created: Tue, 9 Dec 2008 17:20:35 -0600 (CST)
Steve, what exactly do you mean by "multiple states at the same time"?  I can see value in modeling possible states (i.e. the Order is in either PENDING or APPROVED state), which would require changing the multiplicity.  But is that what you mean?

From: wstephe created: Wed, 10 Dec 2008 01:00:50 -0600 (CST)
A Data Object could be a JIRA issue, for example. The issue could have states across muliple dimensions. One dimension could be its status, which could be New, Open, Resolved, etc. Another dimension could be whether or not it has been assigned. These could all be defined states (meaning the multiplicity of State would be 0..*).
Instead of requiring the modeler to make complex states, such as "Open Unassigned" for a single state. it would be better to have the modeler create two different states for the Data Object, one that could be for the status and one for th Assignment. So the Data Object could go from "Open, Unassigned" to"Open, Assigned" by changing one of those states, leaving the other the same.
It would be easier to track those states this way also.

From: mariano.benitez created: Wed, 10 Dec 2008 04:54:08 -0600 (CST)
Steve, what you are describing are data object attributes for sure. I don't think people would like to model those things as states (which are separated form the data object itself). And people would also want to access this states from expressions and assignments, so states would not be a perfect fit.
What I would find useful is to "externalize" as state some attribute and keep the state and attribute in sync, but I don't think it is relevant to the spec.

Nevertheless, if the state is an opaque object, people could use any structure and manipulate it as they need, so I don't think multiple states are needed.

From: wstephe created: Fri, 12 Dec 2008 20:53:27 -0600 (CST)
Mariano, that's a good point. I'm not sure how to differentiate Data Object state(s) with the attributes. The states are generally displayed with the Issue name and help the users track what is going on.

I posted a model of the JIRA Issue Workflow (<a href="https://www-1.ibm.com/QuickPlace/bpmnnext/Main.nsf/h_Library/4A8A326614E7CF0E8525751E0008AE67/?OpenDocument">https://www-1.ibm.com/QuickPlace/bpmnnext/Main.nsf/h_Library/4A8A326614E7CF0E8525751E0008AE67/?OpenDocument</a>). Here you can see that the Data Objects (the Issues) are updated throughout the process and their states change in multiple ways. This is what spawned this issue. Take a look and see if this helps you see the issue or what could be done.

From: mariano.benitez created: Mon, 15 Dec 2008 07:57:08 -0600 (CST)
Steve,

The JIRA example you are using is borderline between executable and non-executable processes, which creates some confusion on the intention.

I have a couple comments regarding your use case (JIRA Issue Workflow.jpg):

1) we agreed that there is only one state object associated with a data object, without any notion of location in the process. 
This means that you can only represent a single state in the metamodel. This in itself is an issue we should address if we want to support your use case. Unless the state moves completely to the visual model, and each representation of the data object can have its own state/s.

2) I assume your process is not designed for execution. But in the case we would like to make it executable, we would need to transform/create all those state changes into assignments manually. This creates a gap between non-executable and executable processes.

So as a conclusion of my evaluation:
- People can do anything they like with states, so I don't see harm in allowing multiple states, all we should do is ensure that states are shown in the right order.
- Diagram notation makes no mention to states, but it should since the different states are associated with the DataObjectShape class.

From: ssamoojh@ca.ibm.com created: Tue, 16 Dec 2008 11:49:29 -0600 (CST)
Mariano, I don't agree with #1 in your comment above.
The State represents the state of the data in the Data Object (and not the state of the Data Object).  I could easily have multiple Data Objects in the semantic model that hold the same data at different points in its lifecycle .... Data Object 1 holds "Order" when it's in state New and Data Object 2 holds "Order" when it's in state "Pending".

From: mariano.benitez created: Tue, 16 Dec 2008 12:42:09 -0600 (CST)
Suzette,
The fact that there are other use cases (like your example) does not invalidate my interpretation (or my use case, or the JIRA use case, where the issue data object is the same across the process). 

Do you have other proposal or suggestion? I do propose to change it, but I also would like to move the state to the visual model. This proposal do not invalidate your use case, nor mine.



From: ssamoojh@ca.ibm.com created: Tue, 16 Dec 2008 15:52:28 -0600 (CST)
My comment was not related to my use-case.  I was simply responding to your comment #1, where the lack of a "notion of location" is raised as an issue.  I don't see that location is a problem here, and I gave an example of how the current metamodel allows me to represent different states at different locations in the process flow.  But maybe I'm misunderstanding what you are describing in #1.

In any case, state is not just visual-only information.  Hence it needs to be in the semantic model.

To address Steve's use-case of multiple States on a single DataObject at a single point in the process flow:  I'd recommend we don't do anything.  There are several use-cases that we could come up with, and I'm not confident we understand them all well enough to accommodate in BPMN.  Hence I'd propose we leave the model as-is.  Tool vendors will have to extend the DataObjectState irregardless in order to use it.  So they could just as easily extend it to accommodate multiple states.

The NET of all of the above is:  I don't see a need for any changes.

From: mariano.benitez created: Wed, 17 Dec 2008 12:58:33 -0600 (CST)
While I agree with your "action" for this issue, I would still be concerned about how to visualize the state in a diagram, we do not propose any way of displaying it. Steve's example is not compliant in this aspect.

So to expand Suzette's proposal, I would say: no need for any change in the MM, but we would need to describe how to show a state, of where...

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.

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.

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.

Comments:
From: mariano.benitez created: Thu, 23 Oct 2008 08:50:34 -0500 (CDT)
open issue: should we allow BPMN 1.1 or less to be imported? Is there a minimal list of supported import types ? XML Schema and BPMN 2.0, anything else? WSDL? BPEL?

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

Comments:
From: wstephe created: Sun, 13 Sep 2009 23:15:56 -0500 (CDT)
The version number was removed from the summary so that it will apply to the Beta 1 spec

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.

Comments:
From: rouven.day created: Thu, 16 Oct 2008 08:52:49 -0500 (CDT)
Hi Conrad, I see several problems with your proposals of defining globalness as an atribute of Task. 
1) There is a clear distinction between embedded and referenced elements in BPMN (see embedded and referenced Sub-Processes). Same can apply to Tasks. Tasks can be embedded (normal Task). Then it is contained in a FlowElementContainer (e.g. Process) and by design not construced for reuse. 
2) If you want to make something reusable you must be able to define a signature and the usages. Both would require additional associations from the usage to the reusable task. E.g. one association to determine which Task to call and one association which Operation to call. 

From: bruce created: Fri, 5 Dec 2008 18:12:07 -0600 (CST)
If a global task means referenceable, what is the scope of a non-global task?  Is it a top-level process?  The nearest enclosing subprocess?  Or is it available for reference by any caller under the same root element?

From: wstephe created: Fri, 9 Jan 2009 19:33:54 -0600 (CST)
I think that this issue should be raised to critical.

The Global Task taxonomy is not included in the spec and only partly in the MM. Only GlobalTask, GlobalBusinessRuleTask, and GlobalScriptTask exist. 

I also agree that we should not duplicate the taxonomy. However, Global Tasks are Calleable Elements and not Activities. I'm not sure how we can resolve this.

From: wstephe created: Fri, 9 Jan 2009 19:34:37 -0600 (CST)
I raised this to critical since it is a big gap in the spec and MM

From: ings_osoa created: Wed, 14 Jan 2009 17:18:05 -0600 (CST)
271 open, assign to Steve, will require spec text as well as metamodel adds may also need metamodel refactoring (which would be hard to do at this stage)

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

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

Comments:
From: ssamoojh@ca.ibm.com created: Thu, 9 Oct 2008 11:45:10 -0500 (CDT)
This is not just a metamodel change, nor is it the data metamodel.  Reassigning to the events team.

Events team, please:
1. Ensure you agree with the proposal.
2. Validate that the execution semantics still work for events and that nothing is missing.
3. Make the required text changes to the spec (attributes table and such).
4. Let me know when you're ready and I will include in the consolidated metamodel.


From: mariano.benitez created: Tue, 5 May 2009 08:34:25 -0500 (CDT)
in version 0.9.11 the figure is Figure 10-51 - Property class diagram. Page 204.

in the XSD events do not have properties either.

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?

Comments:
From: conrad.bock created: Mon, 15 Dec 2008 08:37:25 -0600 (CST)
Open and assigned to Hagen, per status review meeting.

From: mkloppmann created: Mon, 9 Feb 2009 07:13:04 -0600 (CST)
This depends on the kind of event, and most importantly, which kind of correlation applies to it.

We distinguish between key-based and predicate-based correlation.

For key-based correlation, a particular received message will always match a single receive. Actually, issuing the second receive with the same correlation key should already trigger a (runtime) fault -- this may currently not be specified at this level of detail in the spec though. This is the behavior we know from existing runtimes, and scenarios.

For predicate-based correlation, we allow for weaker matching criteria, and consequently, the ability for a single received message to match more than a single receive -- regardless of those receive events residing within a single process instance, or within multiple process instances. Karsten may want to comment further on predicate-based correlation.


From: hvo created: Mon, 13 Jul 2009 08:55:25 -0500 (CDT)
My understanding is that the above distinction is made by the current spec, but the distinction could be better reflected by the execution semantics section. Hence I propose to move this forward to FTF as an editorial issue.

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

Comments:
From: oliver.kieselbach created: Tue, 25 Nov 2008 08:10:43 -0600 (CST)
I would like to see some examples and use cases which highlights the benefits of that approach compared to what has to be done with the current available concepts. This would help me understand what could be done already based on the meta model and concepts we have, where some refinements are necessary or at which points there would be bigger impact.
E.g. is it possible to solve the use case you have in mind with "visual shortcuts" like we already defined the data flow modeling (see figure 10-45 in spec 0.9.0). If not what impact would such a concept have for the activity lifecycle (e.g. if we define that the input pulls the data..we probably have to define how the output of the prev. activity is still available and when runtimes can destroy the context of activities).


From: conrad.bock created: Tue, 25 Nov 2008 15:56:06 -0600 (CST)
My understanding is an activity with multiple incoming sequence flows
annotated with data (the visual short cut you mentioned) results in
multiple executions of the activity, each waiting for data inputs
necessary to start.  A typical data flow without sequence flow executes
the activity once when all the data is available.  This is very natural
for many applications.  Requiring sequence flow forces the modeler to
introduce parallel merges, which is redundant from the modeler's
perspective.

The impact on the lifecycle is to make is to do the same data polling it
needs to do now to wait for data, as I understand it, except it does
this at the start of a process for all activities that have no incoming
control flow.


From: mariano.benitez created: Mon, 15 Dec 2008 13:27:52 -0600 (CST)
Conrad,

incoming sequence flows with annotated data is a shortcut for a couple of data associations, one coming out of the source of the SF, and another one coming into the target SF.

Even if it is not modeled graphically, the behaviour it is like you described, wait for all the data to become available, regardless of the sequence flow. 

If a modeler chooses the visual shortcut, and there are multiple incoming SF, he would need to do some further editing to define it properly. Also, you need to remember that "InputSets" define the set of required inputs.

Hope it clarifies.
MAriano

From: hvo created: Thu, 8 Jan 2009 03:37:29 -0600 (CST)
I think that drawing a data flow dependency between two activities without control flow is supported implicitly by the spec as of today, at least
for the usual acylic cases without multiple instances.

From: ings_osoa created: Wed, 14 Jan 2009 17:19:03 -0600 (CST)
255 leave as new, Conrad to create a motivational use case (or decide that this issue should be closed)

From: conrad.bock created: Tue, 10 Feb 2009 14:54:54 -0600 (CST)
I think a simpler way to handle input sets is to allow activities
without sequence flow to start when they have all their required data.
Then an activity that needs data from one of the input sets can start
when the data is available, see
  <a href="http://www.osoa.org/jira/browse/BPMN-255">http://www.osoa.org/jira/browse/BPMN-255</a>
  <a href="http://www.osoa.org/jira/browse/BPMN-365">http://www.osoa.org/jira/browse/BPMN-365</a>

From: conrad.bock created: Tue, 10 Feb 2009 14:57:01 -0600 (CST)
Sorry, the above comment was meant for
<a href="http://www.osoa.org/jira/browse/BPMN-145">http://www.osoa.org/jira/browse/BPMN-145</a>.

From: ings_osoa created: Tue, 10 Mar 2009 15:52:28 -0500 (CDT)
Deferred with Conrad's agreement.

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

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.

Comments:
From: wstephe created: Fri, 3 Oct 2008 17:22:55 -0500 (CDT)
Not sure I agree with this. Processes and Choreographies are quite different. There are some common elements, such as Events, Gateways, etc. and these are packaged in the Core::Common packaged. Messages are one of these common elements are can be used in both. 
I don't see any re-use across Process and Choreo. Processes are restricted within Pools and Choreos are only between Pools, Also the activities of Choreo and Process are quite different, with different attributes. Data can be used in Processes but not Choreos.
Furthermore, the end users of Process and Choreo are quite different (at least for now), and there shouldn't be any confusion as to what those end users are modeling.
For Process modelers, if they create Process(es) within a Collaboartion (with Pools), then a Choreography could be derived, at least in part. 

From: conrad.bock created: Sat, 4 Oct 2008 11:36:42 -0500 (CDT)
The business modeler will mostly see similarities.  Information comes
into the process and goes out.  It might be from/to someone in the same
department or a different one, from the same company or a different one,
depending on the usage.  The modeler doesn't want or need to commit to
where the information is going to or coming from when they define the
process (or maintain two versions of the process, as Suzette pointed
out).  This was brought up independently by the information architects
at NASA and other places.  These domain experts aren't wedded to a
particular metamodel or arbitrary rules of particular notations.  My
understanding is Mariano has a solution based on using Message Events in
both cases.

From: wstephe created: Mon, 6 Oct 2008 14:07:37 -0500 (CDT)
I think that the issue really has to do with Process vs Collaboration, not Choreography -- in BPMN terms. 

I can see how high level models may not care about who is doing what activity. Thus, the distinction betwen Lanes and Pools in not imporant. When Pools are introduced (which brings us to a Collaboration), then there is an concern about data vs. message and there might be some reuse there. However, I don't think that there is an "automatic" way to introduce Pools and create a Collaboration from a set of Lanes. There is most likely human involvement in the conversion. Some MM structuring could help with whatever conversion can be automated, though.

Choreography is a different animal. 

From: conrad.bock created: Mon, 6 Oct 2008 14:30:13 -0500 (CDT)
Sorry, I must not have been clear. There is no introduction of lanes and
pools in the use case I'm referring to.  The modeler is just defining a
reusable process.  They don't know if it will be reused later (by some
other modelers) as a subprocess of another process, or as a process
"realizing" a participant in a choreography.  The modeler is forced to
define the process with tasks sending and receiving messages for
providing and receiving information from/to the process, or with
dataflow for providing and receiving information.  This limits how the
process can be reused, because message tasks won't work if the process
is reused as a subprocess, and dataflow won't work if the process is
reused by realizing a participant.  The model currently "early binds"
the decision about how the process will be used.

From: ssamoojh@ca.ibm.com created: Wed, 8 Oct 2008 15:48:18 -0500 (CDT)
Just noticed this issue, so figured I would provide my 2 cents.  I've asked Mariano for a pointer to the JIRA issue he's using for his write-up (I couldn't find it either).  In the meantime, here are my thoughts/opinions.

1. I agree with Conrad.  I as a user simply want to state that my process requires X as input.  I don't know whether X will come in as a Message (when I'm participating in a Collaboration) or whether X will come in as pure data (when my process is simply being called from another process).  I should be able to define a single process that could be used in either situations.  [This is very very common amongst tool users ... they want to define a single library of models that could be reused in different situations].

2. We discussed this in the data modeling breakout during the F2F.  Mariano volunteered to write-up the proposal.  But the net is that a MessageStartEvent would be able to either receive a Message (the Collaboration scenario), or its data requirements can be fulfilled through an associated DataInput (the Reuse scenario).  But we should wait for Mariano's write-up to get the full details.


From: ssamoojh@ca.ibm.com created: Wed, 8 Oct 2008 16:03:10 -0500 (CDT)
There is existing JIRA issue for this topic, so we'll use this one.  Assigning to Mariano (assuming he is still volunteering).

From: mariano.benitez created: Wed, 8 Oct 2008 16:28:50 -0500 (CDT)
Yep, we agreed to allow (somehow) processes to use the same definition whether they are invoked via a direct call or a message. I am still catching up with JIRA, I just came back from a 3 weeks road show... Thanks for reminding.. :)

If my memory still keeps some data, the proposal we arrived is that a MessageStartEvent is implicitly defined as a DataInput for the process. Since a process is a callable element, we assume they have data inputs and input sets, but we still need to clarify how those things are mapped to the inner elements (the message start event, or anything else?)

From: mariano.benitez created: Wed, 8 Oct 2008 16:29:07 -0500 (CDT)
and yes, I will work on a proposal for this. :)


From: wstephe created: Wed, 8 Oct 2008 20:41:32 -0500 (CDT)
I just want to clarify the terminology. A process that applies to a participant would never be realized in a Choreography. It can be realized in a Collaboration, through a Pool. That process may or may not conform to a choreography, which is a different type of model. There can be no re-use between Processes and Choreographies. 

So the issue is about the use of a Process (or parts of a Process) within or between Participants in a Collaboration. In that case, the differences between data flow and message flow becomes important.

From: conrad.bock created: Thu, 9 Oct 2008 09:44:20 -0500 (CDT)
The modeler needs to declare which processes "realize" participants in
which choreographies (in part to record how it satisfies a legal
commitment to other companies).  It seems like creating a collaboration
is alot for such a simple thing, and the collaboration model exposes the
internals of the process, which might not be desirable on interchange.

From: wstephe created: Tue, 14 Oct 2008 13:24:05 -0500 (CDT)
We are not providing any formal mechanisms that would enable a modeler to declare that a process actually "realizes" a choreography. Using a Choreo within a Collaboratiion is way that a modeler can visualize the relationship between the internal Process and the Choroegraphy, but it does not guarantee conformance. 
Such a conformance validation would be useful, but is not a part of our spec. It will have to be done sepaately.
For the Processes shown in the Collaboration (within Pools), they do not have to show any internal behavior. They could be Abstract Processes, showing only the touch points. Whether they show internals or not is up to the modeler.

From: conrad.bock created: Tue, 14 Oct 2008 13:45:47 -0500 (CDT)
There must be a connection between process and choreographies the
modeler is expecting the processes to support.  This doesn't mean
automatically checking that they do support the choreographies, only
that the modeler can say what their intention is.  Building a
collaboration that indirectly points to a choreography is too heavy for
such a simple and common end-user need .  Will file a separate issue on
it.

From: conrad.bock created: Tue, 14 Oct 2008 14:15:51 -0500 (CDT)
See <a href="http://www.osoa.org/jira/browse/BPMN-269">http://www.osoa.org/jira/browse/BPMN-269</a>.

From: ings_osoa created: Wed, 15 Oct 2008 16:44:49 -0500 (CDT)
As per 10/15 "BPMN Issue Review" meeting: leave as new pending explanatory use cases to be developed by Conrad



From: conrad.bock created: Thu, 16 Oct 2008 13:20:59 -0500 (CDT)
See attached slides.

From: conrad.bock created: Tue, 3 Mar 2009 12:47:45 -0600 (CST)
Another example related to Steve's is at
<a href="http://www.osoa.org/jira/browse/BPMN-390,">http://www.osoa.org/jira/browse/BPMN-390,</a> with expanded and collaposed
interactive subprocesses:
  <a href="http://www.osoa.org/jira/secure/attachment/10204/Proposal+for+DI+issue+on+Pages.doc">http://www.osoa.org/jira/secure/attachment/10204/Proposal+for+DI+issue+on+Pages.doc</a>
  <a href="http://www.osoa.org/jira/secure/attachment/10315/10315_BPMN-390-example-1%262.JPG">http://www.osoa.org/jira/secure/attachment/10315/10315_BPMN-390-example-1%262.JPG</a>

From: ings_osoa created: Fri, 6 Mar 2009 14:26:07 -0600 (CST)
Deferring as per 3/5 choreo status call minutes.

From: conrad.bock created: Thu, 2 Apr 2009 08:59:10 -0500 (CDT)
Here's some user support for addressing this issue:

 &gt;  [Paul Harmon] We worry that teaching the distinction between a solid
 &gt;  and a dotted arrow is too confusing and might better be omitted.

From user input to OMG/BMI, see
<a href="http://www.omg.org/archives/bmi/msg01227.html">http://www.omg.org/archives/bmi/msg01227.html</a>.  Typical modelers draw
solid lines (item/data flow) across pools to indicate messaging.  It isn't
necessary to have a separate notation for it.

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&#xB4;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.

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.

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

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.

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

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

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.

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.

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

Comments:
From: wstephe created: Tue, 9 Sep 2008 18:56:37 -0500 (CDT)
The answer is no. We will make this clear in the spec.

From: wstephe created: Wed, 11 Mar 2009 13:33:10 -0500 (CDT)
The answer to this is now less clear. Lanes are now contained in a Process, rather than a Pool as was in BPMN 1.X. Thus, it might be possible to have lanes in sub-processes. We are investigating the semantic and visual model consequences.

From: mariano.benitez created: Wed, 10 Jun 2009 13:45:44 -0500 (CDT)
if you are calling another process (via call activity), then the other process can have lanes, and they should be visually represented.

Right now (v0.9.14), a sub-process can only contain flow elements and artifacts, not lanesets. I think we should allow lanesets in subprocess.



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

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.

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.

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

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

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

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.

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

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?

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.

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.

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

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?

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

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.

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

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

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.

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

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.

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.

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

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.

Glossary in Annex C contains a number of definitions of, and references to, workflow patterns that were incorrect in version 1.0 of the spec and are still incorrect in version 2.0.


For example, see the following definitions:
Deferred Choice references workflow pattern #17 ­ actually Deferred Choice is pattern #16;
Discriminator references workflow pattern #8 ­ actually Discriminator is pattern #9;
Implicit Termination references workflow pattern #12 ­ actually Implicit Termination is pattern #11


Also the URL for these workflow patterns has changed (All pages from 'tmitwww.tm.tue.nl' have moved to the server 'is.ieis.tue.nl' - although the latest patterns can actually be found at http://www.workflowpatterns.com/).

May I suggest that the entire contents of the Glossary are reviewed against the latest set of workpatterns (http://www.workflowpatterns.com/documentation/documents/BPM-06-22.pdf) and ensure that the correct pattern numbers are used.  I would also like the glossary to be extended to cover the extra workflow patterns that have been defined beyond van der Aalst's original 20 (or 21 if you include pattern #9a)and that can can be implemented using BPMN notation - (www.workflowpatterns.com/documentation/documents/BPM-06-17.pdf might give useful guidance for this (even though it relates to BPMN v1)).

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.

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.

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?

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.

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.

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

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

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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

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

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

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.

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.

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

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

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

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)

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.

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.

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

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.

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.

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

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

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.

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

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.

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.

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

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.

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?

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.

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

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.

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)

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)

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

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

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

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)

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.

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