Issue 14223: Allow a Process to be Ad Hoc (in addition to a Sub-Process)
Issue 14240: Conformance Classes are overley Broad
Issue 14242: Concept definition for Business Process
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 14293: Page 046, Section 7.2, Message not listed as a BPMN element
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 14303: Depiction of diagram fragments
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 14327: Page 070, section 8 list of Core elements
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 14333: Page 251, Start Event on the boundary of a sub-process
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 14354: This is a style suggestion to make diagrams clearer
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 14422: Add a User Event
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 14538: Page 203, Table 10-26, The text describing the none and all behavior have been inverted
Issue 14539: Page 203, Table 10-26, MultiInstance Activity: What is the intended use case if the catching boudnary event is interrupt
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 14614: Example of Lane, Laneset, and Partitions
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 14653: Message flow to/from events in Collaboration diagrams
Issue 14654: Beta 1 Section 11 Conversation:
Issue 14655: Complex gateway merging rule in choreography too restrictive
Issue 14656: Gateways in Choreography missing split or merge
Issue 14657: CorrelationClassDiagram missing conversation association end name
Issue 14658: Promote correlationKeys association to ConversationContainer
Issue 14659: Correlation Class Diagram missing Process association
Issue 14660: Conversation/Process switch
Issue 14661: PartnerRole underspecified and misnamed
Issue 14662: Private process type
Issue 14663: Interactions supporting interactions
Issue 14664: Processes supporting interactions
Issue 14665: Exclusive gateways in choreography cover splitting but not merging
Issue 14666: Rules for exclusive gateway in choreography too strict
Issue 14667: Multiple senders after event-based gateway in choreography
Issue 14668: Event-based gateways in choreography should be exclusive
Issue 14669: Parallel Gateway participants
Issue 14670: Choreography Complex Gateway example
Issue 14671: isClosed on Conversation
Issue 14672: Meaning of + symbol on Communication undefined
Issue 14673: Figure 11-4 description
Issue 14674: Section 10.5.5 Complex Gateway: The general description of Complex Gateways needs improving
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 14683: Beta 1 Section 15.1.2 Sub-Process Mappings: Table referenced is missing
Issue 14684: Merge Conversation and Collaboration
Issue 14685: CorrelationSubscription Ownership
Issue 14686: Exclusive gateway Choreography rules too restrictive, only sender needed
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 14698: Roles for Entities
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 14702: Beta 1: Section 17 BPMN Example: Include full BPMN example for this section
Issue 14703: CorrelationSubscription - Description & use-cases
Issue 14704: optional source and target refs for data association
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 14709: Multiple processes per participant
Issue 14710: V0.9.7: Section 10 Process: Add ProcessResource Attribute to Process
Issue 14711: Beta 1 Section 15.1.2 Mapping to BPEL Activities: Message Mapping snippet refers to StructureDefinition
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 14729: Add an example of Mutlple Start Events on the Boundary of a Sub-Process
Issue 14730: Initializing and updating properties is not straight-forward
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 14738: Notation for alternaitve data input/output sets
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 14741: Beta 1: Section 9.1 Collaboration: Expand description of Collaboration in section
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 14744: Beta 1: Section 10.2.4 Performer: Relate Performer to Human Performer
Issue 14745: Section 14.2.2 Activity (semantics):
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 14751: Beta 1: Section 10.2.2 Human Interactions: The Parameter class should be described
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 14755: Beta 1: Section 10.1.2: Use of BPMN Common Elements [Process] -- Return removed TBD sections and complete text
Issue 14756: Beta 1: Section 11.2: Use of BPMN Common Elements [Choreography] -- Return removed TBD sections and complete text
Issue 14757: [Chroeography] Complete section 11.4: Events
Issue 14758: Beta 1: Section 10.3.1 Data Objects [Data]: Change Multiplicity of datastate attribute from 0..1 to 0..*
Issue 14759: Beta 1 Section 8.3.17 Sequence Flow and 14.2.1 Sequence Flow Considerations
Issue 14760: Data flow in/out of events
Issue 14761: Section 14.4 [BPEL mapping] Missing intermediate send event; mapping of participant ref
Issue 14762: Provide example: Choreography
Issue 14763: Provide example: Conversation View
Issue 14764: Provide example: Complex gateway
Issue 14765: Provide example: Multi-instance activity
Issue 14766: Provide example: Basic gateway examples
Issue 14767: Provide example: Inline Subprocess
Issue 14769: Provide example: Basic process structure
Issue 14770: Beta 1 Spec: Section 14 BPEL Mapping: Better clarify the subset of BPMN diagrams that are BPEL-mappable (roundtrippable!
Issue 14771: Beta 1 Spec: Section 10.3 Data [Data]:
Issue 14772: Section 2 Conformance [Specification]: Explicitly define BPMN compliance criteria, with focus on "model"
Issue 14773: Beta 1 Spec: New Annex?: Enumerate the validation rules of BPMN
Issue 14774: Section 9 Collaboration [Choreography; Specification, Metamodel]:
Issue 14775: Throughout Spec [Specification]: Define explicit separation of "modeling" vs "implementation" attributes
Issue 14776: Section 8.1.5 [Infra] Import statement description is not clear enough
Issue 14777: Correlation across conversations
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 14784: Define "Pool"
Issue 14785: Generalize message flow
Issue 14786: Beta 1 - Section 14.3 [Execution Semantics]: Examples for the use of gateways are missing
Issue 14787: Reuse of processes in orchestration and choreography
Issue 14788: Annex A {Spec]: Add a section that documents the changes between V1.1 and V2.0
Issue 14789: Section 10.2.8 [Execution Semantics] Loops: Loop names misleading
Issue 14790: Section 8.3.3 [Data] Inconsistency between usage of expressions in Sequence Flows and in Data Associations
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 14794: More description for "Process as a callable element"
Issue 14795: Default execution semantics for an activity with multiple incoming branches needs to be clarified
Issue 14796: Section 10.2.3: Task description needs revisiting
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 14800: Section 10.5 Text duplicated from 8.3.10
Issue 14801: Section 10.2.3 ScriptTask.scriptLanguage needs to specify format
Issue 14802: Section 10.2 Clearer separation between conceptual and visual model needed
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 14815: Link Events - Constraints and Usage not clearly documented
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 14824: Continue versus terminate in loop
Issue 14826: Event marker quality is poor
Issue 14831: A New Hook for Organizational Models?
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 14854: Add Brief Description for Error and Escalation Event Definitions
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 14876: UML interface operations do not match BPMN interface operations
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 14879: The spec should clearly state what visual features are available for extensions and which are restricted to core spec
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 15007: How to represent Activities that might fit in more than one Lane?
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 15030: Ambiguous statements about Sequence Flow
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 15043: Multi-language labels for diagram elements
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 15054: Redundancy in specifying data in processes
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 15065: definitionalCollaborationRef should be 0..*
Issue 15066: Notation for expanded hexagons
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 15070: Notation for shared correlation properties
Issue 15071: Enforcability rules not complete
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 15101: Integrate temporal and token semantics
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 15121: Rethink implementation attribute in Send/Receive/Service Tasks
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 15158: Lists of values
Issue 15159: Choreography activities sharing message flow
Issue 15161: Exporter Information Required for BPMN 2 files
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 15171: Messages and User Tasks
Issue 15217: Add Link Events to a sub-conformance level (Descriptive)
Issue 15253: Data associations need to be revisited and their use clarified.
Issue 15255: Define rules for placement of multiple activity markers
Issue 15256: CorrelationSubscription Ownership - Sub Process
Issue 15284: Clarify Relationship between Collabration Message Flow and Choreography Tasks
Issue 14223: Allow a Process to be Ad Hoc (in addition to a Sub-Process) (bpmn2-ftf)
Click here for this issue's archive.
Source: International Business Machines (Dr. Stephen White, wstephe(at)us.ibm.com)
Nature: Enhancement
Severity: Significant
Summary:
Currently only Sub-Processes can be Ad Hoc. However, it would be useful for Processes to be Ad Hoc also. This would allow libraries of Ad Hoc Processes to be defined and re-used
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.
Since you still have the concept definition for "Business Process" listed as "TBD" in the Glossary, PNA would like to propose the following definition: Business Process: A Business Process is a cooperation between several people and/or systems each performing a particular role and possible other entities such as departments within a company or organization, in order to produce a product or to deliver a service to a customer. Within BPMN a Business Process is described using a BPD.
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 dga...@trisotech.com, Jul 06, 2009 The Message element is not listed in any of the categories Comment 1 by dga...@trisotech.com, Jul 10, 2009 The Message element is not listed in any of the BPMN element categories
Reported 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 The spec should prescribe how diagram fragments are presented. (e.g. three dots at end of continuing flows, ...) Given that BPMN has very specific structural requirements, most diagram fragments in the spec (and elsewhere) are not valid BPMN models.
Reported 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 The figure 8-1 indicates "Infrastructure, Common Elements, and Services". Three Core sub-packages are listed in page 71 "Foundation, Service, and Common". Figure 8-2 shows "Foundation, Common, and Service". Section 8.1 describes "Infrastructure", Section 8.2 describes "Foundation", Section 8.3 describes "Common Elements" and Section 8.4 describes "Services". The list of BPMN core elements indicated in thre first bullet of section 2.1.1 is: "Infrastructure, Foundation, Common, and Service packages." Is there 3 or 4 sub-packages and should we use the same naming convention within this section of the document?
Reported 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 Is it still allowed to have Start and End Event on the boundary of an expended Sub-process? This was clearly stated and shown in BPMN 1.2. It is mentionned at page 251, but no example are provided. Is figure 7-8 page 69 valid?
Reported 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.
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.
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.
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.
There are many situations where a human involved in a process triggers an Event. The current set of Event types do not adequate reflect this situation. Thus, a new type of Event, a User Event, should be added to BPMN.
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 203, Table 10-26, The text describing the none and all behavior of the behavior attribute have been inverted.
Page 203, Table 10-26, multiInstanceLoopCharacteristics: I believe that the motivation behind having events thrown in coordination with the completion of instances of multiInatnce activity is to have non-interrupting boundary events to carry out some desired ackownledgements (or other defined activites), but if the catching boudnary event is interrupting, the alternate flow will be followed potentially resulting in un-expected or suspected behavior. What is the intended use case if the catching boudnary event is interrupting?
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.
Chapter 10.7 needs a more detailed example of how lanes can use process information/elements to partition flow objects
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.
Send/receive events and tasks have the same meaning, but the Collaboration section only shows message flow to/from tasks and other activities. Clarify that message flow can be attached to send/receive events in Collaboration.
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.
The section on gateways in choreography covers splits (diverging) gateways but not merges (converging) for parallel, exclusive. Only merges are covered for complex gateways.
Figure 8-18 (The Correlation Class Diagram) is missing the association end name listed in Table 8-32 (CorrelationKey model associations). Comments: From: wstephe created: Fri, 24 Jul 2009 12:40:19 -0500 (CDT) I was going to add an issue that would request to remove the conversation model association row from Table 8-32. The model association is uni-directional, so correlationKeys should appear in the Conversation table (11-1), but conversation should not appear in the CorrelationKey table (8-32).
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.
PartnerRole does not specify the context of the role (is it a role in an organization?). The examples given (a buyer, seller, or manufacturer) could just be Participants, rather than PartnerRoles. The term "role" also conflicts with Participants, which are effectively roles in Interactions.
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 business commits to an interaction with potential business partners, it might be that a particular partner needs only some of the interaction. This would be specified in another interaction diagram. The modeler needs to link these two interactions to say one supports the other, with the same semantics of the currently supports association, except applied to messaging rather than activities. The supports association should be generalized to cover interactions
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
The section on exclusive gateways in choreography covers splitting but not merging gateways
Exclusive gateways in choreography are required to use decision data accessible to all participants involved in the gatway. But if if the senders after gateway are the same, then receivers can use event gateways or event subprocess to wait for event that might never come. It isn't necessary for the receivers to have access to the decision data.
About event-based gateways in choreography, the spec says: [Event-based] Gateways are used in Choreography when the data used to make the decision is only visible to the internal Processes of one Participant. On the right side of the Gateway [CB: I assume this means immediately after]: either the senders MUST be the same; or the receivers MUST be the same. If the decision criteria is private to one participant, how can there multiple senders after the gateway?
An event-based gateway implies a message is being waited for, but choreographies can't receive messages, they have no central controller. One of the participants will have an event-based gateway internally, but the other will have a exclusive gateway. The choreography can use an exclusive gateway with no conditions, with the semantics is that exactly one of the following messages will be sent. Comments: From: conrad.bock created: Mon, 13 Jul 2009 15:53:49 -0500 (CDT) Email from Frank about conditions on exclusive gateways in choreographies: Hello Conrad, In my opinion there is no need to even have data as decision criteria. There may be a button, that a user presses (request xy..). Of course you can discuss, that the fact, that a button has been pressed is in itself data in the system. But it is a different kind of. So in the case of two senders there are two users and two buttons. Whoever presses first sends first. Whoever sends second is in a different branch of the choreography. That's how I understand it.
Section 12.6.4 (Parallel Gateway) says "They create parallel paths of the Choreography that all Participants are aware of." Not all participants, only those involved after the gateway.
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.
The first sentence of the paragraph under Figure 11-4 (Conversational view choreographies) refers to Figure 11-3, but is about Figure 11-4, as far as I can tell. How is the parent-child relation referred to at the beginning of the paragraph reflected in the notation or metamodel? It says the Planned Order Variations as being keyed on Order Id, but the figure shows it keyed on Variation ID also (compare to description of Retailer Order and Delivery Variations Ack). The paragraph refers to Conversations instead of Communication. The second paragraph under Figure 11-4 refers to Detailed Shipment Schedule and Delivery Monitor, which aren't in Figure 11-3 or 4. The paragraph refers to Conversations instead of Communication. The third paragraph under Figure 11-4 refers to Delivery Planning and Special Cover, which aren't in Figure 11-3 or 4. It mentions messages spawning conversations, which isn't described anywhere else. The paragraph refers to Conversations instead of Communication.
The general description of Complex Gateways needs improving. An example or two would be good. Comments: From: wstephe created: Sun, 13 Sep 2009 23:49:07 -0500 (CDT) The version number was removed from the summary so that it will apply to the Beta 1 spec
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
Page 453. The first sentance of the section states: "The following table displays the mapping of an embedded Sub-Process with Adhoc="False" to a WS-BPEL scope. (This extends the mappings that are defined for all Activities--see page 450):" However, the table is not there.
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.
Decisions are prevented from being used Choreographies if not all participants have access to the information on which the decision is made. But if the activities following the gateway are all sent by the same participant, only that participant needs to know how the decision is made. Using an event-based gateway in this case is confusing, since there is no waiting for events to proceed to the activities following it. Some sided email below about this. Steve, > The Gateway would most likely be Event based. The Buyer is > probably not going to be aware of the data that would be > used to make the decision, particularly a change order. > Thus, the Buyer is just going to be waiting for one of the > three responses. Makes sense for the buyer, but this isn't a model of the buyer (and the Seller is making a regular decision, why isn't that shown?). It's also odd to see an event-based gateway in a choreography since choreography can't don't wait for events, the participants do. The figure looks right according to the spec, but I think the spec is too restrictive on regular decisions in choreogrpahies. Conrad Steve, > The Seller is making a regular decision internally, but the > rationale (i.e., data) used to make the decision is private > for the Seller. A Choreography can only use Exclusive > Gateways if the data used for them is public. I understand that's the rule, but I'm not sure it make sense. In this case, the activities following the gateway are all initiated by the Seller. The rule should be that the seller has access to the decision data. > The Buyer does not know ahead of time, what the > results of the decision will be since the Buyer has not seen the > Seller's internal data. And that's fine, because it isn't the Buyer who initiates any of the activities after the gateway. > All private Exclusive Gateways show up as Event Gateways in a > Choreography. This is too hard to explain, for example, who receives the event? The choreography itself can't received an event, and there's no indication that it's the Buyer (other than they Buyer is receiving in the activities after the gateway). For FTF discussion. :) Conrad
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).
There is no association between PartnerEntities and PartnerRoles, even though entities will play roles. The only link currently is through participant, requiring modification of a C models to link a role or entity, see <a href="http://www.osoa.org/jira/browse/BPMN-520">http://www.osoa.org/jira/browse/BPMN-520</a>. An association between partner entities and roles would enable collections of C models to be grouped by roles, with roles reused by entities.
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>
Section 17 will be temporarily removed until the BPMN example is added. The section should have a full example with diagrams, XML, and supporting text.
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.
dataOutputAssociation/@sourceRef should be optional, not required. dataInputAssociation/@targetRef should be optional, not required. This is to support non-executable models (<a href="http://www.osoa.org/jira/browse/BPMN-381" title="Abstract BPMN Profile"><strike>BPMN-381</strike></a>), since these elements are part of the data interface of the parent node, which is unspecified in non-executable models. The other end of the association, the dataObject, is still required. Comments: From: ssamoojh@ca.ibm.com created: Thu, 14 May 2009 11:04:19 -0500 (CDT) Counterproposal - Rather than making the source or target optional, instead 'lighten' the spec text. The spec currently states that the source or target must be an ItemAwareElement. In the case of non-executable models, the source or target may be the FlowElement itself. So my proposal is to tweak the spec text, so as to allow this.
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
From side discussion with Frank: A single public interaction (choreography, collaboration, or conversation) might be supported by multiple internal processes, but the current metamodel only allows one process per participant. The multiplicity should be widened to *.
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
The figure for the mapping of Message to BPEL shows a snippet that includes a StructureDefinition element. The actual attribute for Message is structureRef, which points to ItemDefinition. This figure should be updated.
> 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
Add an example of Mutlple Start Events on the Boundary of a Sub-Process as shown in an example for Issue 145 and described in the execution semantics section. Section 10.2.5, Beta 1 spec
From examples meeting on 2009.03.26: When creating the looping example for <a href="http://www.osoa.org/jira/browse/BPMN-281" title="V0.5.6: Section 10.3 Data [Data]: Assignments not defined"><strike>BPMN-281</strike></a>, it is not obvious how to initialize properties. Also, updating a property via a dataInputAssociation or dataOutputAssociation is unnecessarily complicated because sourceRef and targetRef are currently mandatory elements, but not really applicable for properties. Proposal: (1) Introduce a new entity "initializationAssignment" (or better name) as a contained element for property (and data object for symmetry reasons), which has the same structure as assignment, but with an optional "to" element. (2) Make dataInputAssociation::sourceRef and ::targetRef optional, likewise dataOutputAssociation::sourceRef and ::targetRef. Comments: From: trickovic created: Tue, 7 Apr 2009 04:00:15 -0500 (CDT) As per 4/6 BPMN 2.0 meeting: Defer <a href="http://www.osoa.org/jira/browse/BPMN-471" title="Initializing and updating properties is not straight-forward">BPMN-471</a>.
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.
Notation for data input/output sets is missing. I/O sets have a similar execution effect as decision and merge gateways, so it seems like they should be visible. Comments: From: wstephe created: Fri, 13 Mar 2009 13:50:54 -0500 (CDT) The decision on this for BPMN 1.X was that there would be no notation for this since it would probably be too complicated. There was a non-normative suggestion that inputs that belong in the same inputSet could be connected to the same point on the activity, but we didn't want to have anything like pins. I haven't seen any other suggestions. If we had something to look at, then we could consider. But, in general, in probably should be deferred for now.
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
The background text for the description of Collaboration is rather thin. Add more description and a figure or two.
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->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
Mainly Editorial: A HumanPerformer is a type of Performer, but there is no reference to this in the Performer section. There should be more description of how Performer can be used (e.g., through HumanPerformer).
Beta 1: Section 14.2.2 Activity (semantics): The state of a Data Object should be considered as a Performance Constrainst for an Activity Changing from the Ready to Active state ##Source: IBM (Stephen A. White, wstephe@us.ibm.com) ##Original Issue: http://www.osoa.org/jira/browse/BPMN-411 ##Original Info: (Severity: Critical - Nature: Enhancement) The state of a Data Object should be considered as a Performance Constrainst for an Activity Changing from the Ready to Active state. If a Data Object is not in the state defined as an input (e.g., "Approved"), then the InputSet should not yet be considered "available."
Comments: From: ings_osoa created: Tue, 10 Mar 2009 10:35:26 -0500 (CDT) SAP believes that modeling of Data Object states is out of scope of BPMN 2.0. This is required if we want to introduce the state of Data Objects as a performance constraint. Steve still thinks this is an interesting issue but he agrees to defer it as it will not be resolvable in the available time. From: conrad.bock created: Tue, 10 Mar 2009 10:40:43 -0500 (CDT) The spec already supports Data Object state, see Figure 10-46 (DataObject class diagram) in 0.9.7. From: conrad.bock created: Tue, 10 Mar 2009 10:43:31 -0500 (CDT) P.S. Since the specfalready supports Data Object state, it would be good to include it in the execution semantics. The execution semantics description is very incomplete anyway and is critical to complete, see <a href="http://www.osoa.org/jira/browse/BPMN-415">http://www.osoa.org/jira/browse/BPMN-415</a>. I added a link. From: hvo created: Mon, 16 Mar 2009 09:54:09 -0500 (CDT) My state of knowledge is also that data object state is out of scope. It can be specified but it does not affect semantics. Data object state was never considered a "performance constraint" in in sense of Sect 13 so far. From: hvo created: Wed, 18 Mar 2009 11:49:42 -0500 (CDT) Steve, Conrad and me suggest to defer this issue.
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.
The Parameter class is an association of ProcessRole. Parameter has its own attributes. Thus, there should be a short subsection that describes Parameter, including a table that describes the attributes. A general question: Parameter is a very generic name. Should this class be named something more specific?
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.
Some sections with TBDs were removed for the Nov OMG posting. These sections should be returned and filled with content. This section should match a parallel section in Chapter 11 (Choreography).
Some sections with TBDs were removed for the Nov OMG posting. These sections should be returned and filled with content. This section should match a parallel section in Chapter 10 (Process).
Complete 11.4.1, 11.4.2, and 11.4.3 on choreogrpahy events. Each sub-section may require more text, review and some example and pictures. Comments: From: trickovic created: Fri, 12 Dec 2008 06:37:38 -0600 (CST) Issue assigned to Steve/the choreography team.
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...
Beta 1 Section 8.3.17 Sequence Flow and 14.2.1 Sequence Flow Considerations (Execution Semantics): Add Exclusive conditional behavior from activities ##Source: IBM (Stephen A. White, wstephe@us.ibm.com) ##Original Issue: http://www.osoa.org/jira/browse/BPMN-349 ##Original Info: (Severity: Significant - Nature: Enhancement) Suggested by Michael Rowley: Add Exclusive conditional behavior from activities. "Perhaps there should be a new variant of the minidiamond symbol to show that they are exclusive (filled in black, perhaps?). For human activities, it would then be clear that the different flows are different choices that can be made by the user. In B4P they would also be the "outcome" of the task." This was discussed on a BLOG (<a href="http://kswenson.wordpress.com/2008/01/01/human-process-trouble-ticket/#comment-8886">http://kswenson.wordpress.com/2008/01/01/human-process-trouble-ticket/#comment-8886</a>) Proposal TBD
Comments: From: wstephe created: Fri, 21 Nov 2008 17:43:58 -0600 (CST) Assigned to Hagen for now since there are execution semantics consequences of this feature. From: hvo created: Thu, 22 Jan 2009 09:11:32 -0600 (CST) Seems to be related to 145, at least for subprocesses, more precisely related to the discussion there whether we want to encapsulate alternative behavior in a subprocess and how we want to show that at the interface. From: bruce created: Sat, 24 Jan 2009 18:00:25 -0600 (CST) I don't think this is same as 145. This one uses normal semantics of subprocess completion. It is purely notational, and works the same regardless of the visual representation of the activity (unlike 145). Conditional sequence flow with the open diamond "implies" independent conditions (like OR gateway) but it "could" be used with exclusive conditions (like XOR gateway). This makes a clear distinction between the two forms of conditional sequence flow out of an activity. The downside is yet another graphic element. From: david_marston created: Sun, 25 Jan 2009 11:53:25 -0600 (CST) Maybe you just need to say that at a certain level of formality, explicit gateways are necessary. I think we don't want a mix of exclusive and inclusive minidiamonds, which would be the next requested feature once two kinds are allowed. If you are drawing the process for human consumption, be informal and show all exit conditions as inclusive (and use an annotation to state that formal rules exist, if that would ease your guilt). If you want a model that will compile into checkboxes and/or radio buttons, draw the necessary gateways. From: mariano.benitez created: Tue, 27 Jan 2009 12:37:28 -0600 (CST) I would really like to be able to define exclusive implicit gateways in the activity, this has been the behaviour of our product for the past 8 years and we never had a complain abou it. (This is just to express how much I like the idea, it is not an argument.) :) Now, I agree NOT to mix exclusive and inclusive minidiamonds. What I think is that the inclusive/exclusive behaviour is an attribute of the activity. The default SF out of the activity is actually an attribute of the activity itself, so we might well add another attribute "gateway behaviour" that would be inclusive or inclusive. Actually diamonds has nothing to do with the type of gateway they are flowing out from. I prefer an activity attribute that would rule for all conditional SF out of the activity. From: hvo created: Wed, 28 Jan 2009 02:30:27 -0600 (CST) Is there any reason why we would like to have this feature only on the output side but not on the input side? From: wstephe created: Wed, 28 Jan 2009 17:17:34 -0600 (CST) I understand Mariano's point of view on this issue. A few tool vendors involved in V1.0 had similar features and so the mini diamond was added. I would have preferred that ALL Sequence Flow control be handled by Gateways. Having both Gateways and mini diamonds is too much notation, in my opinion. BPMN is already dinged by people who say that it is too complex. I would not suggest that we remove the mini-diamonds, since they are legacy, but I would prefer that we don't add any more notation to V2.0 than we have to. I would recommend that we defer this issue. From: mariano.benitez created: Fri, 30 Jan 2009 08:21:32 -0600 (CST) I think multiple sequence flows in/out of activities is a reasonable shortcut that most of our customers use, it makes the visual diagram cleaner. Actually, in the case of multiple incoming sequence flows, it behaves like an exclusive gateway, different from the outgoing side. (see section 13.2.1) There is no reason why people would not want inclusive gateway semantics on the incoming side too. I don't think it is too much of a change to add 2 attributes that describe the incoming and outgoing behaviour, and it would make the semantics more consistent and flexible for users. So, I would recommend we open this issue with the proposal I just made. From: wstephe created: Fri, 25 Sep 2009 15:10:08 -0500 (CDT) Summary updated to match Beta 1 spec sections
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.
Type: Technical Description of issue: 1. The spec misses the mapping for intermediate message send events 2. The spec misses a mapping for send/receive events and tasks where the other party is specified not by a service-ref, but by a message flow to another participant. Proposal: 1. Include that mapping into spec (see Visio) 2. Introduce text describing how BPEL partnerLink is derived from either serviceRef or participantRef; use [serviceRef | participantRef] or similar notation as abbreviation.
Description of issue: Missing choreography example Proposal: Add an example showing a choreography with several choreography activities, based on the existing example. Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.
Type: Example Description of issue: Missing example for Conversation View. Proposal: Add an example showing a conversation view. Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation. Comments: From: wstephe created: Mon, 1 Dec 2008 21:45:34 -0600 (CST) An example has been started. It needs to be finished (including XML). Also, we should use this issue to track the full text requirements for Section 9.5 "Conversations" (V0.9.1)
Description of issue: Missing example for complex gateway. Proposal: Add an example showing a complex gateway. Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.
Description of issue: Missing example for multi-instance activity. Proposal: Add an example showing a multi-instance activities, including data assignments from a set of values to the individual parallel instances, and from the results of the parallel instances to a result set. This will require collaboration with the Data team. Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation.
Description of issue: Missing examples for basic gateways. Proposal: Add three examples showing XOR, IOR and AND gateways. Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation. Comments: From: mkloppmann created: Thu, 19 Feb 2009 12:31:13 -0600 (CST) Per the 2009.02.19 examples sub-team meeting: -- Medium priority -- Combine with <a href="http://www.osoa.org/jira/browse/BPMN-310" title="Provide example: Basic process structure">BPMN-310</a>
Description of issue: Missing example for Inline Subprocess Proposal: Add an example showing Inline Subprocess Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation. Comments: From: mkloppmann created: Thu, 19 Feb 2009 12:33:25 -0600 (CST) Per the 2009.02.19 examples sub-team meeting: -- This item is related to <a href="http://www.osoa.org/jira/browse/BPMN-365" title="Notation for data flow in/out of a process">BPMN-365</a>
Description of issue: Missing example for process structure Proposal: Add an example showing process structure. Examples must be provided in XML, inline with the BPMN 2.0 XSD. If necessary, the example should also be provided using BPMN notation. Comments: From: mkloppmann created: Thu, 19 Feb 2009 12:30:43 -0600 (CST) Per the 2009.02.19 examples sub-team meeting: -- Medium priority -- The example should contain activities, events, gateways -- Combine with <a href="http://www.osoa.org/jira/browse/BPMN-316" title="Provide example: Basic gateway examples">BPMN-316</a>
Better clarify the subset of BPMN diagrams that are BPEL-mappable (roundtrippable!)
Beta 1 Spec: Section 10.3 Data [Data]: If start of an activity is guarded by availability of input data, there should be some visible indication of this in the diagram
##Source: IBM (Stephen A. White, wstephe@us.ibm.com)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-302
##Original Info: (Severity: Significant - Nature: Enhancement)
This is number 5 of 12 issues submitted by Bruce Silver
If start of an activity is guarded by availability of input data, there should be some visible indication of this in the diagram. ("Modeling" means you don't need to see the non-diagram attributes). It seems like BPMN 2.0 is trying to make data more a first class citizen, so this is needed.
Comments:
From: bruce created: Fri, 5 Dec 2008 17:29:56 -0600 (CST)
In a user task, it is understood that time can elapse between task ready and active, whereas in service task there is no delay. So the temporal semantics are clear from the diagram. The issue is when service task is guarded by data "availability" - whatever that implies. If service task could incur delay between ready and active because of input data, this should be visible somehow in the diagram.
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.
This is number 3 of 12 issues submitted by Bruce Silver Enumerate the validation rules of BPMN. Back in the old days when the BPDM guys kept saying BPMN 1.0 had no explicit rules or metamodel, you said it did but it was buried in the narrative. Now you have an explicit metamodel but the rules are still buried in the narrative, and inconsistent from one part to the next. Judging from v1.x it will take years to clean up the narrative, so just enumerate the rules in one place and say this overrides contrary info elsewhere in the narrative.
Section 9 Collaboration [Choreography; Specification, Metamodel]: Clarify that a pool represents a single BPMN process, not a "participant" meaning role or business entity ##Source: IBM (Stephen A. White, wstephe@us.ibm.com) ##Original Issue: http://www.osoa.org/jira/browse/BPMN-299 ##Original Info: (Severity: Significant - Nature: Enhancement) This is number 2 of 12 issues submitted by Bruce Silver Clarify that a pool represents a single BPMN process, not a "participant" meaning role or business entity. At least do this for a white box pool (aka private process); a black box pool (abstract process) is empty of activities, so its process is unknown and often labeled as role or business entity. Also remove the language that multiple pools in a BPD are about B2B. This is rarely the case. Multiple white box pools in a BPD are used when the processes involved have independent lifetimes and cardinality, and almost always when both pools represent the same business entity not B2B.
Comments: From: bruce created: Fri, 5 Dec 2008 17:51:52 -0600 (CST) I suspect I will not carry the day on this one. I see there was language to this effect in early November and then deleted later. Can we at least say that a pool may contain at most one process? From: wstephe created: Tue, 15 Sep 2009 14:28:08 -0500 (CDT) The section number was removed from the Summary to allow this to apply to the Beta 1 spec
This is number 1 of 12 issues submitted by Bruce Silver: Define explicit separation of "modeling" vs "implementation" attributes. The current "core" vs "extended" is nowhere close to this, since modeling needs much of the extended set. Modeling is about orchestration of "abstract" activities, abstract meaning they have a name (label), task type, perhaps markers like loop/MI/adhoc, and unique id of course, but not implementation properties. Abstract sequence flow has name, source and target refs; if conditional, the label is sufficient - you don't require a conditionExpression. Message flow or message event does not require a message attribute, timer event does not require TimeDate or TimeCycle (please rename it to Duration) attribute, error event does not require an error code attribute, etc. Those are for implementation; in modeling it's the diagram that counts, i.e. the label.
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 metamodel seems to be missing relations between the correlation information in multiple conversations of the same collaboration / choreography. For example, in Figure 11.3 (Conversation diagram depicting several conversations between Participants in a related domain) how does the process internal to Consignee handling the Consignee-Retailer conversation map its correlation information to the correlation info in the Consignee-Supplier conversation? Without this the Consignee conversations with the Retailer and Supplier will be uncoordinated.
Comments: From: conrad.bock created: Mon, 27 Oct 2008 14:07:22 -0500 (CDT) Ivana said she will check with Alistar before opening this. From: conrad.bock created: Tue, 16 Dec 2008 10:58:54 -0600 (CST) Ivana said: Please check v0.9.2 and in particular the cardinality condition on conversation and correlation set. From: conrad.bock created: Tue, 16 Dec 2008 14:36:33 -0600 (CST) I see that conversations can have multiple correlation sets, but where is the mapping specified between them? For example, in Figure 9.13 of v0.9.2 (A Conversation Diagram example), the correlation information specified between Retailer and Consignee might need to be transformed to the correlation information between Consignee and Supplier. Where is that mapping specified? From: ings_osoa created: Wed, 14 Jan 2009 16:47:16 -0600 (CST) 288 open assign to Alistair, probably work in progress and/or already done, Alistair can determine which is the case From: alistair.barros created: Mon, 2 Feb 2009 23:36:44 -0600 (CST) Spec updates sent to Steve provide preliminary text to address this issue. technical discussions are currently taking place and final proposal will be produced as a result. From: conrad.bock created: Wed, 11 Feb 2009 09:18:29 -0600 (CST) Alistar, I couldn't find this addressed in the update posted on <a href="http://www.osoa.org/jira/browse/BPMN-253,">http://www.osoa.org/jira/browse/BPMN-253,</a> maybe I missed it. Since a conversation provides a multi-participant view, the message flows between two of the participants might contain information used for correlation with other participants. For example, in the conversation in Section 1.7 of your update, a message flow from Retailer and Consignee might have data to be used as correlation information between the Consignee and Supplier and back to the Retailer from the Supplier. This enables the Retailer to tell the message flows from the Supplier are apart of the overall interaction involving the Consignee. How are these relationships between the conversations captured in the metamodel? From: ings_osoa created: Fri, 6 Mar 2009 14:33:13 -0600 (CST) Deferring as per 3/5 choreo status call minutes.
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 term "pool" is used extensively in the specification yet the definition seems inconsistent and not tied to the meta model. Sometimes a pool seems to be the role of a participant in a process context. In other cases it seems to be the essential container of a process. It seems to be a graphical element but shows up on ends of associations and in definitions of the semantics. The term "pool" does not seem to have any semantic relevance to process. Examples: • While a normal Process exists within a Pool, a Choreography exists between Pools (or Participants). • A Pool is the graphical representation of a Participant in a Collaboration (see page 235). It is also acts as a "swimlane" and a graphical container for partitioning a set of Activities from other Pools, usually in the context of B2B situations. • Nor can Sequence Flow cross a Pool boundary. • For message exchanges between pools, Conversations are used to group several Message Flow • A Participant is a specific business entity (e.g., a company) or a more general business role (e.g., a buyer, seller, or manufacturer) responsible for the execution of the Process enclosed in a Pool. The semantics behind of pool should be clarified and the spec should not use graphical elements to define semantics.
Comments: From: bruce created: Fri, 5 Dec 2008 18:49:53 -0600 (CST) I agree w/Cory. Pool has fundamental semantics, unlike Lane which is purely notational. Sequence flow from start to end constrained within a pool. Message flow must connect two pools. A pool can contain at most one process (not counting subprocess activities within that process). Etc. For some reason BPMN refuses to say a pool is a container for a process. Instead it says a pool is a visual expression of a "participant" - role or entity - even though behind-the-firewall collaborations between pools representing the exact same role or entity are not uncommon. They are separate pools not because they represent different participants but because of their independent lifetime and cardinality. From: mariano.benitez created: Mon, 29 Dec 2008 13:29:47 -0600 (CST) Also in the XSD schema the conversation element has a unbounded reference to a "pool" element. The MM do not mention Pool, but it is defined in the XSD. From: bruce created: Tue, 27 Jan 2009 18:28:26 -0600 (CST) The MM element for pool should be process. A BPD (sorry, "collaboration diagram") with two collaborating processes representing the exact same role or business entity contains two pools interacting via message flows. Pool is a visual element, process is the MM element. The pool always exists but sometimes is invisible. So it is a Zen visual element. From: wstephe created: Tue, 27 Jan 2009 18:47:25 -0600 (CST) I don' think that a Process is the same as a Pool. For one, a Process can appear in more than one Pool. For example, WalMart could play two Roles in a Collaboration, occupying two Pools. Those two Pools could have different Processes, but those two Pools could actually use the same Process (if the Modeler chooses). The Pool, which we have been equating to Participant lately, may or may not reference (contain) a Process. From: mariano.benitez created: Fri, 30 Jan 2009 07:53:06 -0600 (CST) Steve, In your example: Could you describe how the MM would look like in both cases (same process in both pools and different processes)? Probably I don't fully understand Collaboration, but how does a sequence flow whose target is a pool woud relate to the real process? From: bruce created: Fri, 30 Jan 2009 12:04:01 -0600 (CST) Steve's example is enlightening, because it shows the problem is lack of clarity on what is a "process." To me, his example describes two processes, not one. A BPMN process is an orchestration, a continuous flow of control from start to end events via sequence flow. A "business process" may indeed have more than one BPMN process, perhaps even performed by the same participant (WalMart), acting in same role (or different roles) in multiple pools. The reason they are separate processes/pools is that 1) they have independent lifetimes; 2) they may have independent cardinality. In BPEL no one has trouble with this distinction. A business process is very often composed of multiple BPEL processes. Why is this not a single BPEL process? For many of the same reasons as in BPMN. The BPMN spec explicitly says a process is not a "thing" but a collection of things. I don't think this is consistent with BPMN 2.0 MM. If we can agree that a BPMN process is a thing, then I think the pool question will be simpler to resolve.
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).
The use of some gateways should be described by example, e.g. complex gateway, inclusive gateway, multiple instances
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: > [Paul Harmon] We worry that teaching the distinction between a solid > 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.
We need to document the changes from V1.1. For example, we removed two attributes from User Task, because the same functionality is being handled elsewhere. We need to document such changes to make it easier for the implementers that need to migrate. Comments: From: mariano.benitez created: Wed, 8 Oct 2008 15:57:52 -0500 (CDT) We also dropped the concept of "streaming" data, so this should also be included in this section. Assignments elements are also removed, converted to DataAssociations. From: wstephe created: Sat, 12 Sep 2009 13:47:45 -0500 (CDT) Spec Draft version removed to prepare for BPMN 2.0 FTF
The names "Standard Loop" and "Multi Instance Loop" are misleading. Actually both allow for creation of a desired number of Activity instances, not just Multi Instance Loops as the spec text states it. So the multiple instance characteristics is true for all loops, also Standard Loops. Thus the naming of the loop types is very misleading. Proposal: Go for the well known names (<a href="http://en.wikipedia.org/wiki/Control_flow#Loops">http://en.wikipedia.org/wiki/Control_flow#Loops</a>). Rename Standard Loop to Condition-controlled Loop (or Conditional Loop or Condition-based Loop). Also find a better name for Multi Instance Loop. I´ll try to post some name proposals soon. Comments: From: wstephe created: Fri, 20 Mar 2009 19:15:16 -0500 (CDT) The results of Issue 193 will also resolve this issue. From: wstephe created: Sat, 12 Sep 2009 13:45:16 -0500 (CDT) The section number was updated to match the Beta 1 spec.
We have created some guards around the use of unavailable data in expressions of Data Associations. The issue I am raising is about the use case when a conditional sequence flow uses an expression, and the data objects used in that expression are unassigned.
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
##Source: Oracle (Vishal Saxena, vishal.saxena@oracle.com) ##Original Issue: http://www.osoa.org/jira/browse/BPMN-118 ##Original Info: (Severity: Minor - Nature: Revision) On page 122 (152 in PDF) under fig 10-2 we describe process as a callable element. I think its a good idea to give small introduction. Comments: From: wstephe created: Fri, 11 Sep 2009 17:12:58 -0500 (CDT) The page and section numbers were updated to match the Beta 1 spec
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: The description for Task needs revisiting - States that "A Task is used when the work in the Process cannot be broken down to a finer level of details". This doesn't reflect typical usage. It's not that it cannot be broken down, but rather many users simply choose to not break down further. Users model at the level of detail most appropriate for their needs and the needs of their audience. - States that "Generally, an end-user and/or applications are used to perform the Task when it is executed". What does this mean? A black-box Task is traditionally used for documentation processes, where what the task does is more important than how (whether by an end-user or by an application) it is done. If users know how it should be done then they would use a specialized task (i.e. User Task or Service Task) rather than Task Proposal: Reword to make it clear that Task has a purpose and usage in itself, beyond being a superclass for specialized tasks.
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 first three paragraphs in section 8.4 are duplicates of the same paragraphs in 8.3.10 where gateways are introduced. Proposal: Replace paragraphs in 10.5 by a short paragraph and a reference to 8.3.10's gateway section.
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.
Description of issue: This section mixes conceptual meta-model statements with visual representation statements. A clearer separation of those concepts is needed. -- p 127 (157 in PDF) "... inclusion of re-usable tasks and processes in the diagram" should be "... invocation of re-usable tasks and other processes from the process" -- p 127 (157 in PDF) "... a process is not a graphical object. Instead, it is a set of graphical objects." A process is neither, it is a container for activities and other entities, all of which have a graphical representation. -- p. 133 (163 in PDF) ff "A task is a rounded corner rectangle" should be "A task is represented by a rounded corner rectangle". This occurs frequently for all task types, so globally change "is a rounded corner rectangle" to "is represented by a rounded corner rectangle"
##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
The Sequence Flow constraints around the usage of Link Events are not clearly expressed in the spec. Very simply, it should express that: - A Catch Link Event should have no incoming Sequence Flow. - A Throw Link Event should have no outgoing Sequence Flow. Instead the spec has several rather confusing statements (pgs 235-236) that make it hard to infer the simple behavior I described above. Statements like: - If the Intermediate Event is used within normal flow: - Intermediate Events MUST be the target of a Sequence Flow. - An Intermediate Event MUST be a source for Sequence Flow. - An exception to this: a source Link Intermediate Event (as defined below), it is not required to have an outgoing Sequence Flow. - A Link Intermediate Event MUST NOT be both a target and a source of a Sequence Flow. - A Link Intermediate Event MAY be the target (target Link) or a source (source Link) of a Sequence Flow, but MUST NOT be both a target and a source. Recommendation: - Tighten up and simplify the constraint descriptions for Link Events. - Refrain from introducing new terms "source" and "target", or if the new terms are needed, clearly relate them to the existing "catch" and "throw" terms.
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.
Introduction of end type break within a loop construct (continue construct is already there, implemented by the terminate end type which can be used inside a loop (multi instance activity) to end the loop).” This relates to what is e.g. said on page 407: “For a “terminate” End Event, the Sub-Process is abnormally terminated. In case of a multi-instance Activity, only the affected instance is terminated.” So, differentation is required between the two modes of getting out of the loop.
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
The hook in BPMN for Resource Models is through the Resource class. Generally, Organization Models are considered separate from Resource Models, but there is not a separate hook for Organization Models in BPMN, the Resource class would have to be used for Organization models, which could be confusing. The Resource class could be renamed to make it more generic, or a new class for Organization could be added.
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 other Event Definitions have a brief description of what they are. The Error and Escalation do not have this description.
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.
Currently interface operations in BPMN follow a "Document" model where all the arguments are wrapped in a single "Message" in and out of the operation. But in UML, interface operations follow the "RPC" model, where arguments are independent and each one has the "In, Out, InOut" classifier. This difference creates several problems when trying to relate/map BPMN and UML operations. Another side effect of the BPMN message model is that you cannot use simple data associations to fill the arguments of a service call. Since the operation is a single type, we have to use transformations to target the arguments (in my case we hide this complexity from the end user, and probably every vendor will do the same. So, if the FTF wants to have a reasonable integration with SoaML, we should fix this issue. The proposal is to adopt the UML model, with separate arguments instead of a single document in and out. We understand this is a major change, and a migration path from the Beta spec to the final one is a mandatory requirement.
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.
Right now there is no clear separation on which graphical features (like line thickness, type of lines, color, etc) vendors are free to use as extensions, and which are restricted for the specification to use. We should define which features we want to use in the spec and which ones vendors are free to use. The reason for this is that if a vendor chooses line thickness for some visual extension and in a revision we choose to use the same feature, the vendor is forced to change to adapt (most importantly end-users). For example: it is clear that color is open for vendor extensions, and we should pick lines (thickness, dotted, etc) as restricted for our use.
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.
Some activities (or other elements) may have properties that would allow them to be placed in more than one lane. For example, a Task could be assigned multiple resources. Is there a way to display the activity in multiple lanes? If not, how is would the most appropriate lane be chosen?
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
In section 10.4.1, Event Concepts, (page 211 -241 PDF) there are some confusing statements about Sequence Flow. For example, one statement reads: "The Data Association for a Throw Event is performed when the Sequence Flow arrives at the Throw Event." Sequence Flow do not "arrive" in this context. The statements should be revised to refer to Tokens arriving at the Events to make consistent with the rest of the specification
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.
Most diagram elements carry a text label. The current version of the spec only allows to specify one string that is used as label. Multi-national companies often document their business processes in multiple languages (English, German, Spanish..). BPMN should therefore allow to set multiple labels per element (+ default language for the diagram)
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.
There is an obvious redundancy in defining data in BPMN 2.0 (data objects, item definitions, messages, import of schema,...). The current spec does not say what is mandatory to be specified in which situation. At least the most common scenarios should clarified in the spec, e.g. what must be specified in case a WSDL doc is already available and the message described in this document should be used by a service task; or what must be specified in case in incoming message (by a start event) should be copied to a data object. I submitted a comprehensive document describing the situation to the issues@omg.org address, whithout any reaction since weeks. I am happy to send this document to the one assigned to this issue and discuss it.
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.
Table 10.1, definitionalCollaborationRef includes the phrase “For Processes that interact with other Participants,” which implies that Processes *are* Participants. In fact they are distinct elements in the metamodel. More significantly it states “The definitional Collaboration specifies the Participants the Process interacts with, and more specifically, which individual service, Send or Receive Task, or Message Event, is connected to which Participant through Message Flow.” However a Process could be linked to Participants in many Collaborations and so the multiplicity of [0..1] seems over-limiting.
Filed for soaML: When multiple hexagons (conversation/communication) are expanded, it isn't possible to tell which message flows go with which hexagons, because the hexagons disappear. Should have a grouping notation to show which message flow came from expanding which hexagons.
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.
Filed for Alistar: Conversations / communications sharing correlation properties should be linked graphically.
Filed for Alistar: Enforcability rules not complete.
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”).
BPMN uses temporal semantics currently in process abstraction, and token flow in process execution. It isn't currently clear which semantics should be used for what purposes, or if they are compatible. Temporal semantics should be highlighted as one of the semantics for sequence flow, especially in conjunction with definitional collaborations, and it should be related to the token semantics.
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.
Currently, send/receive/service/user/business rule tasks have an "implementation" attribute. Based on the information in the spec and from the process orchestration subgroup call, this attribute shall identify the technology to be used for interaction. This can be Web Service, WS-HT or any other protocol/coordination protocol. While this makes sense for human tasks and business rule tasks, there are a couple of inconsistencies with Send/Receive/Service tasks. Here is why: - Receive Task has an implementation attribute, a message event has not. - A Receive Task and a subsequent Send Task that deal with messages defined within the same operation may have different values for the implementation attribute. This is however probably not intended. My proposed resolution is to remove the implementation attributes for send/receive/service tasks. We should discuss whether this information is really needed or whether it could be inferred by the implementationRef of the interface/operation tuple. The information might be needed to determine in which technology an interface/operation is implemented. See also http://www.osoa.org/jira/browse/BPMNFTF-519#action_15739 As an alternative, MessageEventDefinition would need such an attribute as well.
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.
The word "list" is used a fair amount in describing attributes and model
associations. I think these are intended to be sets in most cases,
rather than lists (no ordering, no duplicates). In UML, the default is
sets, you need to add "{ordered}" "{non-unique}" to get lists.The spec allows multiple choreography activities to share the same message flow. Is that intended?
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).
Lanes representing conversations should require activities in those lanes to send or receive message flows in the conversation.
To support SoaML modeling a Collaboration will need to be able to reference more than one Choreographies. These Choreographies would then be associated with the Conversations of the Collaboration.
The two versions of the Multi-Instance loop marker should be reversed. The three horizontal lines looks more like parallism and the three vertical lines look more like sequentialism.
It is possible that User Tasks may send and/or receive messages. Thus, the mechanisms built into Send, Receive, and Service Tasks should also apply to User Tasks. Also, Message Flow can connect to any Task. Thus, there should be some restrictions on this or messaging should be applied at the Task level instead of the individual sub-types
There is a proposal to add conformance levels to BPMN 2.0. The proposal for a Descriptive level should include Link Events.
Data associations need to be revisited and their use clarified. Data association should have there own visual depiction. Using the look of association is misleading as data associations have a different meaning than associations. A data association is an edge between flow elements (data objects(ref) and data stores(ref))as such they should not cross boundaries of pools or can they? This is not clear. It is also not clear if data objects(ref) and data stores (ref) can be drwan outside lanesets or pools.
A Task or Sub-Process may have multiple markers (e.g., looping, compensation, etc.). But the spec does not explicitly define how the markers should be ordered. The examples in the spec are not consistent in how they are presented.
Currently only Processes can 'own' Correlation Subscriptions. However, also Sub Processes should be able to define and own Correlation Subscriptions. Use case: restrict the lifecycle of the correlation subscription to the sub process only (as opposed to activating the subscription for the entire lifecycle of the process. This is particularly required in the case of long running processes. Proposed resolution: Figure 10.29- The Sub-Process class diagram Table 10.20 - Sub-Process attributes Table 10.48 - SubProcess XML schema > ADD attribute correlationSubscriptions:CorrelationSubscription [0..*] to class Sub-Process
When a Choreography is included in a Collaboration, the spec says that Message Flow can be "wired up" to Choreography Tasks. This needs to be defined better. Are the objects connected or overlapping? What if the Choreography Task moves, etc.