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

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

No Data Available

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

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

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

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

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

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

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

resolved

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

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

resolved

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

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

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

resolved

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

withdrawn by submitter

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?

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

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.

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

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

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

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

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

Reason:

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

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.

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

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.

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

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

Add the + marker to Figure 12.21
Disposition: Resolved

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.

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

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?

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

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.

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

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)

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

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)

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

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

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

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

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

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

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

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.

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

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

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

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.

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

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.

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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)

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

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

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

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

In beta version 09-08-14,

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

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

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

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.

• To "Table 8.80 - Interface attributes and model associations", add the following row:
  implementationRef: Element[0..1] This attribute allows to reference a concrete artifact in the underlying implementation technology representing that interface, such as
  a WSDL porttype.
• To "Table 8.81 - Operation attributes and model associations", add the following row:
  implementationRef: Element[0..1] This attribute allows to reference a concrete artifact in the underlying implementation technology representing that operation, such as
  a WSDL operation.
• Update the UML meta-model and XSD schema accordingly.
  Disposition: Resolved

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

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

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.

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

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.

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

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.

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

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

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

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

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

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

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

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

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

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

<startEvent id="StartProcess"/>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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)

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

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

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

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.

Reason: Changing the icon for multi-instance activities now will cause a lot of confusions. It will be difficult to ensure that the whole document stays in a consistent state.
There are also already publications out on the market that use the current notation.
Even for BPMN 1.x there are examples that use the current "vertical" notation for parallel, e.g. see Steves
http://www.bpmn.org/Documents/Notations_and_Workflow_Patterns.pdf , Figure 30. So, there would be some kind of incompatibility introduced.
Which orientation is better to understand for parallel and sequential depends mainly on taste on which axis one assumes time. If you model vertically top to bottom, the
current notation is good. This is similar like writing a text, or also similar to UML activity and sequence diagrams. Only for the case that you model left-to-right the other
proposal might make little more sense.
Conclusion: Changing the meaning now has much higher risk than advantages.
Disposition: Closed, No Change

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.

Section 9, Collaboration
Change the multiplicity of Collaboration's choreographyRef model association from 0..1 to 0..*
(a) Update Figure 9.1 to reflect this change
Table 9.1, second row:
(b) First column: Change "[0..1]" to "[0..*]"
(c) Second column: change the first sentence to "The choreographyRef model association defines the Choreographies that can be shown between the Pools of the
Collaboration."
(d) Table 9.2, Collaboration XML Schema: change:
"<xsd:attribute name="choreographyRef" type="xsd:QName" use="optional"/>"
To
"<xsd:element ref="choreographyRef " minOccurs="0" maxOccurs="unbounded"/>"
Disposition: Resolved

Lanes representing conversations should require activities in those
lanes to send or receive message flows in the conversation.

The resolution assumes the resolution of 14654.
In the Collaborations chapter, Conversations section, at the end of the
Conversation Link subsection, add the paragraph
When a lane represents a conversation, the flow elements in the lane
(or elements nested or called in them) that send or receive messages
must do so as part of the conversation represented by the lane.
Disposition: Resolved

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.

All machine-readable files are included in document DTC/2010-05-04, including CMOF files.
The zip file with these files is attached: 2010-05-04.zip
There are several sections under chapter 16 (chapter 15 of the final draft) that indicate the location of machine-readable files.
Introduce a new section before Section 16.2 XSD

• Section 15.2 Machine readable files
  BPMN 2.0 machine readable files, including XSD, XMI and XSLT files can be found in OMG Document DTC/2010-05-04, which is a zip file containing all the files.
  XSD files are found under the XSD folder of the zip file, and the main file is XSD/BPMN20.xsd.
  XMI files are found under the XMI folder of the zip file, and the main file is XSD/BPMN20.cmof.
  XSLT files are found under the XSLT folder of the zip file.
• Section 16.2 XSD
  Remove the first two paragraphs (starting "The BPMN 2.0 XSD").
• Section 16.3 XMI
  Remove the first paragraph (starting "The BPMN 2.0 XMI").
• Section 16.4 XSLT Transformation between XSD and XMI
  Replace the paragraph with the following text:
• The XSLT transformation from XSD to XMI is in the file XSLT/BPMN20-ToXMI.xslt
• The XSLT transformation from XMI to XSD is in the file XSLT/BPMN20-FromXMI.xslt
  Disposition: Resolved

When a single semantic element has multiple depictions (e.g. DataObjects), this forces the requirement for the target and source information to be duplicated in the DI schema in oder to know where to draw the association (i.e to which instance).

In the case of DatStore, the solution was to have only one semantic element dataStore and have dataSoreRefs as depictable duplicate elements.

Maybe the same could be explored for DataObjects

The resolution of issue 15080 will also resolve this issue
Disposition: Duplicate

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.

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

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.

This issue is addressed by 15163
Disposition: Duplicate

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.

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

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.

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

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.

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

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

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

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.

In Table 7.2 (BPMN Extended Modeling Elements):

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

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?

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

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

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

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

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

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