The text says:

The precise synchronization behavior of the Inclusive Gateway can be found on page 291.

The link on the text "page 291" goes to page 291, but since that is already the current page, the link text doesn't make sense. Also, the linked section does not describe the behavior precisely.

The text is:

Task, Sub-Process, and Call Activity

The word "Call" needs to be part of the term "Call Activity":

Task, Sub-Process, and Call Activity

The same issue occurs in section 10.3.6 on page 212/532 labeled 182:

The activation of a call Activity

Should be:

The activation of a Call Activity

Page 244/532 labeled 214:

one that is referenced by a Call Activity

Should be:

one that is referenced by a Call Activity

There is an incorrect sentence describing a parallel muliti-instance activity (check second sentence). The term "sequential" is repeated while the "parallel" should be used instead.
Incorrect:
A set of three horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see upper figure to the right).
A set of three vertical lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see lower figure to the right).
Correct:
A set of three horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see upper figure to the right).
A set of three vertical lines will be displayed at the bottom-center of the activity for parallel Multi-Instances (see lower figure to the right).

On page 13, clicking the link to:

"
Business Process Modeling
• Jean-Jacques Dubray, “A Novel Approach for Modeling Business Process Definitions,” 2002
http://www.ebpml.org/ebpml2.2.doc
"

Took me to this link:
https://av.zetsubou.org/2nd/av-2022/

Which 1) is not what I expected (“A Novel Approach for Modeling Business Process Definitions,”), 2) was in an asian language I could not understand and 3) had pictures with sexual content.

Regards,
Patur Vase

The sub-clauses listed in section 2.1 appear to be incorrect. References in the passage below to sub clause 2.1 should be referencing sub clause 2.2. The reference to sub clause 2.2 should be for sub clause 2.3. The reference to sub clause 2.3 should be for sub clause 2.4. Finally, the reference to subclause 2.4 should be for sub clause 2.5.

Original passage:
The implementation claiming conformance to the Process Modeling Conformance type SHALL comply with all of the
requirements set forth in sub clause 2.1. The implementation claiming conformance to the Process Execution
Conformance type SHALL comply with all of the requirements set forth in sub clause 2.2. The implementation claiming
conformance to the BPEL Process Execution Semantics Conformance type SHALL comply with all of the
requirements set forth in sub clause 2.3. The implementation claiming conformance to the Choreography Conformance
type SHALL comply with all of the requirements set forth in sub clause 2.4. The implementation is said to have BPMN
Complete Conformance if it complies with all of the requirements stated in sub clauses 2.1, 2.2, 2.3, and 2.4.

On the listed pages, the o in Model is incorrectly capitalized

There is a list of non-operational elements in the introduction to the section *13. BPMN Execution Semantics. The Ad-Hoc Process is in the list. However, in chapter **13.3.5 Ad-Hoc Sub-Process* its execution semantics is described in detail. So, I think the "details needed to execute them on an engine" are given. It seems, the Ad-Hoc Sub-Process is in fact operational and should be removed from the list.

PS: There is no "Ad-Hoc Process". The "Sub-" is missing.

In the "Multiple Instances" row in table 7.2 (page 39), the last sentence should read "A set of three vertical lines will be displayed at the bottom-center of the activity for parallel Multi-Instances (see lower figure to the right)." to match the diagram on the right.

I found a mistake in the BPMN 2.0.2 specification.

https://www.omg.org/spec/BPMN/2.0.2/PDF

On Page 37:

"The attributes of Tasks and Sub-Processes will determine if they are repeated or performed once (see page 190). A set of three horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see upper figure to the right).
A set of three vertical lines will be displayed at the bottom-center of the activity for SEQUENTIAL Multi-Instances (see lower figure to the right)."

The second "sequential" is wrong. The vertical lines are for PARALLEL Multi-Instances.

The corrected form is the following:

"The attributes of Tasks and Sub-Processes will determine if they are repeated or performed once (see page 190). A set of three horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see upper figure to the right).
A set of three vertical lines will be displayed at the bottom-center of the activity for PARALLEL Multi-Instances (see lower figure to the right)."

I believe I have found one small mistake in the BPMN specification 2.0, but it has two occurrences.

The mistake is where the sentence states two times "business process runtime", that perhaps should be altered to "business process engine"?

It is here:

10.2.4 Human Interactions
10.2.4.1 Tasks with Human involvement
In many business workflows, human involvement is needed to complete certain Tasks specified in the workflow model.
BPMN specifies two different types of Tasks with human involvement, the Manual Task and the User Task.
A User Task is executed by and managed by a business process runtime. Attributes concerning the human involvement, like people assignments and UI rendering can be specified in great detail. A Manual Task is neither executed by nor managed by a business process runtime.

Also on page 163.

There is a wrong page referencelink, because it links to itself on page 163, where it should link to "10.2.4.1 Tasks with Human involvement" instead.

"See “User Task” on page 163 within the larger section of “Human Interactions” for the details of User Tasks"

I have just started going through the 'Business Process Model and Notation, v2.0' document and come across some fairly basic errors in some of your example flows. On the one hand BPMN is very prescriptive, yet in the execution of the examples it is extremely lax and erroneous. I have not got very far into the document yet as it very heavy going, but 2 cases in point where your examples are poor: figure 7.1, 'Approve or Reject Policy' should be two mutually exclusive processes, one to reject and the other to approve, which should have 2 separate outcomes. If you are wishing just to show a high level articulation of this dependency, then the process should be phrased as 'Make Policy Application [Request] Decison'. The other process that jumps out as logically unsound is figure 7.3, example of collaboration process. There are 2 swimlanes, one for patient and one for doctor surgery. 'receive medicine request' is a 'pharmacy' function so should be in a '!
pharmacy' pool. The way this process flows, there is no point in issuing a prescription request to the patient whose only duty is to present it back to the same surgery. Prescriptions requests have to go to a pharmacy, not the doctor. If the notation is being so prescriptive and requiring accurate conformance, the the examples need to be sensible, clear and error-free or there can be no confidence in the notation.

On the referred chapter/section/table/page, the description cell for the item "Multiple Instances" must describe and differentiate sequential multiple instances and parallel multiple instances. The text in this table´s cell says the same for both sequential and parallel multiple instances, as shown (i enclosed the error within double brackets):
" The attributes of Tasks and Sub-Processes will determine if they are repeated or performed once (see page 190).
A set of three horizontal lines will be displayed at the bottom-center of the activity for sequential Multi-Instances (see upper figure to the right).
A set of three vertical lines will be displayed at the bottom-center of the activity for [[sequential]] Multi-Instances (see lower figure to the right).".
The description for the round box with vertical lines should read "parallel" instead of "sequential".

Thanks in advance.
Carlos Biscione - Oracle Colombia.

The returning message flow to the "Ask Developer" manual task from the "Provide feedback for 2nd level support" manual task should be go to the "Document 2nd level result" manual task in the same pool?

Dear Team

On the provider www.bpmn.io I can create a flow that is exportable to a .BPMN/XML file. In order to check this XML validation the library links to:

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" id="Definitions_13r4fun" targetNamespace="http://bpmn.io/schema/bpmn" exporter="bpmn-js (https://demo.bpmn.io)" exporterVersion="8.8.0">

The URLS to Omg.org are giving a page 404.

Question:
Is it possible to support me the correct Omg URLs for the XML header? so the XML can be validated

Kind regards

Dieter Proost

I always took for granted, that error and escalation events can only be catched in the same process instance at the same or a higher level as the throw event. A recent discussion in the OCEB group revealed, that the specification doesn't really support that view, without some reading between the lines.

The semantics of these important events should not be open to debate. I suggest to add a clarification.

The attributes of Tasks and Sub-Processes
will determine if they are repeated or
performed once (see page 190). A set of three
horizontal lines will be displayed at the
bottom-center of the activity for sequential
Multi-Instances (see upper figure to the right).
A set of three vertical lines will be displayed at
the bottom-center of the activity for sequential
Multi-Instances (see lower figure to the right).

Above the description of the multi instances from the document.
In the last sentence the parallel multi instance ist described. But instead of using the word parallel its sequential.

Best regards, Jan

Text:

The Start Event trigger (EventDefinition) MUST be from the following types: Message, Error,
Escalation, Compensation, Conditional, Signal, and Multiple (see page 259 for more details)

Table on Page 259:

Lists the above start events but also includes the Timer, and Parallel Multiple events.

Section 10.5.2 on page 238 states:

If the Process is used as a global Process (a callable Process that can be invoked from Call Activities of other Processes) and there are multiple None Start Events, then when flow is transferred from the parent Process to the global Process, only one of the global Process’s Start Events will be triggered. The targetRef attribute of a Sequence Flow incoming to the Call Activity object can be extended to identify the appropriate Start Event.

1. Bug: the text only mentions "Global" processes and not "Top-level" processes, which is another but similar category of processes (p. 239). I find no semantic definition about multiple None Start Events in Top-level processes. I think, it should be the same semantic as for Global processes.

2. Bug:

As already mentioned in Bug report BPMN21-413 (https://issues.omg.org/issues/BPMN21-413) there is a semantic inconsistency with the definition of the process instantiation (also Section 10.5.2 on page 238):

All Flow Objects that do not have an incoming Sequence Flow (i.e., are not a target of a Sequence Flow) SHALL be instantiated when the Process is instantiated.

To bring both text passages together, I assume the term "Flow Objects" refers more likely to "Activities", because multiple start events are usually handled in an exclusive manner (defined at multiple places in the specification).
*But, in my mind there is no semantic difference between an Activity A with no incoming sequence flow and Activity A connected to a None Start Event.* (This just seems to be a modelling preference.)
So, the question is, how to handle multiple None Start Events in a Global and Top-level process? Exclusive (like the other typed start events) or Inclusive (like Activities without an incoming sequence flow) semantics?

Solution:

To stay consistent (no semantic difference between an Activity with or without a None Start Event), I plead for the inclusive semantic, i.e. to put a token into every None Start Event if the process was instantiated via a None Start Event.
If the process is instantiated via a typed start event, the exclusive semantic should remain.

Additionally, this is more user-friendly from a modeling perspective than the alternative: if Start Events have to be used (maybe because of a modeling guideline), the parallel semantic would require to have one None Start Event connected to a Parallel Gateway connected to all parallel-executable Activities. This could look very messy compared to one None Start Event at each Activity.

The disadvantage is the difficulty to model/implement the exclusive start if it is needed. In my experience I have rarely seen it and the inclusive start is way more often required for multiple None Start Events.
But let's look into that: For a Global (callable) process you can still use the existing targetRef attribute on the incoming sequence flow to refer to/instantiate just one None Start Event.
None Start Events are also typically used for a manual process start in a process automation engine. If it is really intended to just put a token into one specific None Start Event, you could alternatively 1. use a Message Start Event or 2. the process engine can offer a way to just start a specific None Start Event.

3. Related Improvement:

If the semantic will be defined as suggested in Bug 2 for multiple None Start Events, it is also possible and useful to allow multiple None Start Events in embedded Sub-Processes. The entry into the Sub-Process would put a token into every existing None Start Event.

We recently had a dispute with a customer, who wanted to use a different BPMN tool for downstream processing of certain process models exported from our tool.
While analysing their claim, I found confusing definitions for the LinkEventDefinition:

The textual specification for the LinkEventDefinition (and especially the table 10.98) defines three additional fields (compared to the EventDefinition): name, sources and target. All three are listed in the table 10.98 as "attributes":

However, the following XSD definition actually specifies only the name to be an XML attribute while target and sources are defined as XML child elements - see table 10.115.

As far as I could tell from a quick scan, all other "attributes" listed in tables with such a name are actually also XML attributes.
So I can see how there could an interpretation, that the target of a link event should be an XML attribute and not a child element.
Am I correct in assuming that the XSD is binding and thus "target" should really not be an attribute of the linkEventDefinition element, but rather a child element?
If so, then this section should be defined in a less ambiguous way.

On page 292, the spec reads, "The precise synchronization behavior of the Inclusive Gateway can be found on page 292."

It should refer to Section 13.3.3, page 435.

(It would be helpful if other gateways in section 10.5 also referred to their respective execution semantics in section 13.3.)

Hello,

My startup company has developed extension to BPMN2.0 to include blockchain. I have built a Javascript library for the same at this link on BitBucket: https://bitbucket.org/solyd/solyd-moddle/src
Can I please request to make necessary amendments in BPMN specs to include the same?
Please advice.

In Table 8.52 the specification says:

outgoing: Sequence Flow [0..*]: This attribute identifies the outgoing Sequence Flow of the FlowNode. This is an ordered collection.

In the xmi-file the property outgoing doesn't have ordered=true, as it should.

It says "The DataStore element inherits the attributes and model associations of FlowElement (see Table 8.44) through its relationship to RootElement, and ItemAwareElement (see Table 10.51). [...]" while the diagram depict DataStore as being a direct descendant of FlowElement.

Software vendors seem to implement it as a mandatory step to close every XOR Gateway with a XOR Join.
It seems that even the majority of users which can be found in the internet, assume or state that the XOR Join element has to used everytime a XOR Gateway is opened.
Just a few sources state that the usage of the XOR Join gateway is optional.

Since i don't see a definitie logical reason, to use the XOR Join gateway at all, i was researching the OMG BPNPs specifications, which seem not to clrarly state how to handle XOR Joins either.
Therefore i open up this issue. Could you please state:

1. is there really an imgainable situation, in which the XOR Join makes sense? Is this element really needed?
2. What is your recommendation in usage?

Thank you very much for any clarification

Please excuse that i ask this question by opening this bug report. SInce i wasn't able to find a definite answer to the given question in the specification, it may more be a bug in terms of an missing clarification, which seem to lead to the situation, that certain software providers handle the use of a XOR Join Gateway in a way, that seem to be redundant, from a strictly logical perspective, by stating the use of a XOR Gateway without the following mandatory use of a XOR Join Gateway as an error.

There seem to be two different understandings of the handling of the XOR Join gateway. The Majority seems to state, that using this in general would be the best practise, whereas I think, that the logical aspect should be paramount. (Form follows function). That is why I was starting to research for an official explanation.

So, could the OMG point out:
A: Which possible Situation could logically justify the existance of this element?
B: What a desired best practice in the use of this element would be?

Thank you very much for your help
sincerly yours

On p. 241 is written:

A Start Event can also initiate an inline Event Sub-Process (see page 174). In that case, the same Event types as for
boundary Events are allowed (see Table 10.86), namely: Message, Timer, Escalation, Error, Compensation,
Conditional, Signal, Multiple, and Parallel.

and on p. 174:

The Start Event trigger (EventDefinition) MUST be from the following types: Message, Error,
Escalation, Compensation, Conditional, Signal, and Multiple (see page 259 for more details).

It seems that Timer and Parallel are missing the list on p. 174.

“Call activity” in the table looks like “None” (not market in bold).

Example about figure 6.52 shows not about driver`s story

The example in section 15.3.1 Document Structure on page 475 (PDF 505) uses invalid Diagram Interchange (DI) attributes and fails XML schema validation. The example seems to use an older DI version than the one published with BPMN 2.0. This is also visible in the different namespace URLs used.

diagram1.bpmn:7: element BPMNDiagram: Schemas validity error : Element '{http://www.omg.org/spec/BPMN/20100524/DI}BPMNDiagram', attribute 'scale': The attribute 'scale' is not allowed.
diagram1.bpmn:7: element BPMNDiagram: Schemas validity error : Element '{http://www.omg.org/spec/BPMN/20100524/DI}BPMNDiagram', attribute 'unit': The attribute 'unit' is not allowed.diagram1.bpmn:8: element BPMNPlane: Schemas validity error : Element '{http://www.omg.org/spec/BPMN/20100524/DI}BPMNPlane', attribute 'element': The attribute 'element' is not allowed.
diagram1.bpmn fails to validate

A fixed version that passes XML schema validation is available at:
https://github.com/bpmn-miwg/bpmn-miwg-demos/tree/master/2020-06-omg-technical-meeting-boston/discussion/BPMN%202.0.2%20Section%2015.3.1%20Document%20Structure%20Example

On page 312, it says:
“It is possible to specify that a Sub-Process can be compensated without having to define the compensation handler. The Sub-Process attribute compensable, when set, specifies that default compensation is implicitly defined, which recursively compensates all successfully completed Activities within that Sub-Process.”

On page 457 (section 13.4.4), it says:
“It is possible to specify that a Sub-Process can be compensated without having to define the compensation handler. The Sub-Process attribute compensable, when set, specifies that default compensation is implicitly defined, which recursively compensates all successfully completed Activities within that Sub-Process, invoking them in reverse order of their forward execution.”

The mentioned attribute “compensable” doesn’t appear in any Class Diagram or Table. In particular, Figure 10.29 and Table 10.20 (p.181), where the Sub-Process element is described.

These paragraphs should be removed; or the attribute “compensable” should be added in Table 10.20 and Figure 10.29.

Page 213 states the following restriction about process data input and incoming data association:

• Data Inputs MAY have incoming Data Associations:
  • If the Data Input is directly contained by the top-level Process, it MUST not be the target of Data Associations within the underlying model. Only Data Inputs that are contained by Activities or Events MAY be the target of Data Associations in the model.

Page 215 states the following restriction about process data output and outgoing data association:

• Data Outputs MAY have outgoing DataAssociations.
  • If the Data Output is directly contained by the top-level Process, it MUST not be the source of Data Associations within the underlying model. Only Data Outputs that are contained by Activities or Events MAY be the target of Data Associations in the model.

So according to those, a Process Data Input MUST NOT have incoming data association and a process Data Output MUST NOT have outgoing data association.

But on page 225, the following is stated:

In the case of a Start Event, the Data Inputs of the enclosing process are available as targets to the DataOutputAssociations of the Event. This way the Process Data Inputs can be filled using the elements that triggered the Start Event.

In the case of an End Event, the Data Outputs of the enclosing process are available as sources to the DataInputAssociations of the Event. This way the resulting elements of the End Event can use the Process Data Outputs as sources.

So according to those paragraphs, a process data input might have incoming data association if the source is a start event and a process data output might have outgoing data association if the target is an end event.

Those exceptions should be written on page 213 and 215 to avoid confusion.

On page 292 of the document, it says in the last line:

[The] precise synchronization behavior of the Inclusive Gateway can be found on page 292.

Obviously, we are on page 292 already.

I assume the cross-reference should be to page 435.

That said, the synchronization behavior of the Inclusive Gateway is not described on pages 435-436 - or not in enough detail to be useful.

"A set of three vertical lines will be displayed at the bottom-center of the activity for sequential parallel Multi-Instances "

Table 2.3, Footnote 'a'
It should probably be,
"Multiple incoming connections are only allowed for converging Gateways"

The specification says in the (non normative) glossary:

Flow Object - A graphical object that can be connected to or from a Sequence Flow. In a Process, Flow Objects are Events, Activities, and Gateways. In a Choreography, Flow Objects are Events, Choreography Activities, and Gateways.

In the metamodel, the common superclass of Event, Activity, Choreography Activity, and Gateway is FlowNode. Does that mean, Flow Object and Flow Node are synonyms? Or is Flow Object the graphical object and Flow Node the model element? Both words are used throughout the specification, e.g.

Table 7.3 displays the BPMN Flow Objects and shows how these objects can connect to one another through Sequence Flows.

Of the types of Flow Node, only Activities, Gateways, and Events can be the target [of a Sequence Flow].

Does it serve any purpose to have different names for the two? I find it confusing.

Suggestion
Replace all occurrences of "Flow Object" with "Flow Node".

Section 12.1.1 includes the text "miss-interpretations"

The correct spelling is "misinterpretations"

Section 6.1.1 includes this bullet point on conventions:

• The cardinality of any content part is specified using the following operators:
• <none> — exactly once

I don't know whether this should be:
• <1> — exactly once
or
• <one> — exactly once

I could not find any examples of this syntax in the standard.

Diagram 8.1 looks amateurish: the non-horizontal text labels are not aligned linearly, nor are the letters spaced evenly. The circular rings look like they were cut out of construction paper. This diagram doesn't have the quality one would expect to see in a formal international standard published by the OMG.

The third paragraph of section 2.1 says:

"The implementation claiming conformance to the Process Modeling Conformance type SHALL comply with all of the requirements set forth in sub clause 2.1. The implementation claiming conformance to the Process Execution Conformance type SHALL comply with all of the requirements set forth in sub clause 2.2. The implementation claiming conformance to the BPEL Process Execution Semantics Conformance type SHALL comply with all of the 2 Business Process Model and Notation (BPMN), v2.0.2 requirements set forth in sub clause 2.3. The implementation claiming conformance to the Choreography Conformance type SHALL comply with all of the requirements set forth in sub clause 2.4. The implementation is said to have BPMN Complete Conformance if it complies with all of the requirements stated in sub clauses 2.1, 2.2, 2.3, and 2.4."

Each of the sub-section numbers referenced is off by 1. The correct paragraph text should be:

"The implementation claiming conformance to the Process Modeling Conformance type SHALL comply with all of the requirements set forth in sub clause 2.2. The implementation claiming conformance to the Process Execution Conformance type SHALL comply with all of the requirements set forth in sub clause 2.3. The implementation claiming conformance to the BPEL Process Execution Semantics Conformance type SHALL comply with all of the 2 Business Process Model and Notation (BPMN), v2.0.2 requirements set forth in sub clause 2.4. The implementation claiming conformance to the Choreography Conformance type SHALL comply with all of the requirements set forth in sub clause 2.5. The implementation is said to have BPMN Complete Conformance if it complies with all of the requirements stated in sub clauses 2.2, 2.3, 2.4, and 2.5."

The definitions Element in the XSD should have an extensionElements like in the CMOF Definitions.

<xsd:element name="definitions" type="tDefinitions"/>
<xsd:complexType name="tDefinitions">
<xsd:sequence>
<xsd:element ref="import" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="extension" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="rootElement" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="bpmndi:BPMNDiagram" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="relationship" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="extensionElements" minOccurs="0" maxOccurs="1" />
</xsd:sequence>

Collapsed activities have "None or isExpanded is false" as BPMNShape Attributes, while their corresponding Expanded form have "None or isExpanded is true".
"None" should not appear in both forms as it creates confusion.
This issue is present in the tables of Ad Hoc Sub-Process, Transaction, and Call Activity, but not in those of Sub-Process, Event Sub-Process, and Call Choreography Activity.
Hence, the former group of tables should be corrected based on the later.

(1) On page 204, the last sentence reads:
The DataObject element inherits the attributes and model associations of FlowElement (see Table 8.44) and ItemAwareElement (Table 10.52). Table 10.54 presents the additional attributes of the DataObject element.

However, the first Table reference should be to Table 10.51 (not 10.52), and the second should be to 10.52 (not 10.54).

(2) On page 205, the first full sentence (not in a table) reads:
The Data Object Reference element inherits the attributes and model associations of ItemAwareElement (Table 10.52) and FlowElement (see Table 8.44). Table 10.53 presents the additional attributes of the Data Object Reference element.

However, the first Table reference should be to Table 10.51 (not 10.52). The reference to Table 10.53 is correct.

The specification says:

10.5.2 Start Event All Flow Objects that do not have an incoming Sequence Flow SHALL be instantiated when the Process is instantiated.

There are some exceptions to this rule, but they don't touch the following discussion. Since Events are Flow Objects, this applies also to Start Events: When the process with multiple Start Events is instantiated, all Start Events of this instance are instantiated (i.e. they get a token).

Further down it says however:

There MAY be multiple Start Events for a given Process level. Each Start Event is an independent Event. That is, a Process instance SHALL be generated when the Start Event is triggered.

That means on instantiating a process, each Start Event gets instantiated, which in turn instantiates a new process. I don't think this was intended.

In the same section the semantics for calling global processes is defined differently (without mentioning it as an exception to the above rule):

If the Process is used as a global Process and there are multiple None Start Events, then when flow is transferred from the parent Process to the global Process, only one of the global Process’s Start Events will be triggered.

So called global Processes are treated differently from Subprocesses (I know, somewhere else it is stated, that a Subprocess can only have a unique Start Event - a rule that is contradicted in the immediately following sentence). I think this is confusing.

Suggestion
Change the above sentence

All Flow Objects that could have but do not have an incoming Sequence Flow SHALL be instantiated when the Process is instantiated.

This way, multiple Start Events are always alternative. This would be in line with many other sections of the specification:

13.2 Process Instantiation and Termination A Process is instantiated when one of its Start Events occurs. Each occurrence of a Start Event creates a new Process Instance [...] Note that two Start Events are alternative [...]

and

13.3.4 Sub-Process/Call Activity If the Sub-Process does not have incoming Sequence Flows but Start Events that are target of Sequence Flows from outside the Sub-Process, the Sub-Process is instantiated when one of these Start Events is reached by a token. Multiple such Start Events are alternative. [...]

The text today reads:

An ItemAwareElement MAY be underspecified, meaning that the structure attribute of its ItemDefinition is optional if the modeler does
not wish to define the structure of the associated data.

I believe it should be:

An ItemAwareElement MAY be underspecified, meaning that the structureRef attribute of its ItemDefinition is optional if the modeler does
not wish to define the structure of the associated data.

The ItemDefininition doesn't have an attribute called "structure".

The specification says about External Relationships:

These extensions’ intention is to extend the semantics of a given BPMN Artifact.

The following text then refers consistently to BPMN Artifacts.

The metamodel however specifies that a Relationship links all kinds of CMOF::Elements, not just BPMN::Artifacts.

My guess is, that "BPMN Artifacts" was meant to read "BPMN elements", e.g.

typed relationships that enable BPMN and non-BPMN Artifacts to be related

should probably read

typed relationships that enable BPMN and non-BPMN Artifacts elements to be related

The specification says about Extension:

It provides a set of extension elements, which allows BPMN adopters to attach additional attributes and elements to standard and existing BPMN elements.

In other words, extension can only add something to existing elements, but not create new element types.
However about Artifacts it says:

A modeler or modeling tool MAY extend a BPMN diagram and add new types of Artifacts to a Diagram.

Given the extension mechanism, it is unclear, how new types of Artifacts can be added. And since the Metaclass Artifact is abstract, it is not possible to use the generic Artifact and extend it to create something resembling a new type. A modeler would always need to specify the concrete subclass, such as Group or TextAnnotation and thus inherit attributes and semantics he probably doesn't need.
So either the sentence is wrong, or there is another extension mechanism, that needs some explanation here.

The specification says:

categorizedFlowElements:FlowElement [0..*] - The FlowElements attribute identifies all of the elements (e.g., Events, Activities, Gateways, and Artifacts) that are within the boundaries of the Group.

This attribute is derived and the elements are found by looking at the diagram and determining, which elements are within the boundaries of the dashed box representing the Group. As far as I know, this is the only place in the specification, where the location of an element in the diagram is relevant for the semantics. I think there should be a more formal way.
Further down the specification says:

Groups are one way in which Categories of objects can be visually displayed on the diagram.

If the only way to define a group is to show it in the diagram (as the first sentence implies), this sentence is wrong.

On page 71 of the spec, in the Category chapter, in the Table 8.23, the attribute categorizedFlowElements of the CategroyValue element is descibed as follow :

categorizedFlowElements: FlowElement [0..*]
The FlowElements attribute identifies all of the elements (e.g.,Events, Activities, Gateways, and Artifacts) that are within the boundaries of the Group.
But Artifact is not a FlowElement, so it must not appear as an example of the latter

Table 8.23. Row “categorizedFlowElements”

It says
“The FlowElements attribute identifies all of the elements (e.g., Events, Activities, Gateways, and Artifacts) that are within the boundaries of the Group.”

The name of the model association is “categorizedFlowElements”, not “FlowElements”.

Model Association “categorizedFlowElements” is of type “FlowElement”, but “Artifact” is not a “FlowElement” (see Figure 8.8, page 66; and Figure 8.22, page 87). So “Artifacts” cannot be examples of elements identified by “categorizedFlowElements”.

Then, it should say
“The categorizedFlowElements model association identifies all of the Flow Elements (e.g., Events, Activities, and Gateways) that are within the boundaries of the Group.”

The description in the bpmnElement column of the table for the Sequence Flow, Conditional Sequence Flow, and Default Sequence Flow elements is incorrect. default neither is an attribute of the listed elements, nor it is of type boolean. It belongs to the element referenced by the sourceRef attribute, and can either reference an element or be undefined (it cannot be false).

In the table in pg 411, the rightmost column header is named BPMNShape Attributes. However this should be a table concerning BPMNEdge, and thus the header should be named BPMNEdge Attributes.

Introduce start and intermediate events of type “User”. Events of type User can be used to identify user initiated actions for example pressing a door-bell or selecting a menu item on a computer. At the moment the BPMN specification only allows these events to be modelled as conditional events or alternatively through the BPMN extension mechanism. Unfortunately the majority of vendors do not support the extension mechanism, they only support the main specification. Adding this to the main specification would greatly improve the BPMN's applicability and usability.

Allow event-based gateways to have outgoing conditional flows. Section 10.6.6 of the BPMN specification v2.0.2 states that “The outgoing sequence flows of the event gateway must not have a conditional expression”. I suggest that this clause be changed because an initiating event-based gateway is an excellent way to model, for example, a menu, where not all items on a menu are available all the time (as they might depend upon user roles or the application’s state). With outgoing conditional flows from the event-based gateway this situation can be modelled easily. Of course modelling a menu is only one such scenario, and I appreciate that the conditions to be applied to the conditional flows could instead be applied to the events following the event-based gateway, but the use of conditional flows is simply a cleaner implementation.

In table 10.88 "End Event Types", the table row with header "Compensation" contains this statement:
"To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process."
The same applies to Table 10.89 "Intermediate Event Types in Normal Flow" on page 251.

On page 234, however, there is this statement: "The compensation handler is either user defined or implicit."

The two statements, taken together, would mean that an implicit compensation handler cannot be called by a Throwing Compensation Event.

This probably is not intended.

Either the concept of implicit compensation should be removed alltogether (which is not my preference), or alternatively the sentence
"To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process."
should be changed like this:
"To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process, or the Activity must be a Sub-Process or a Call Activity calling a Process."
because sub-processes and called processes always are implicitly compensable (unless the compensable attribute is set to false).

Chapter "10.5.1 Concepts" contains the following statement on page 234:
"Cancellation will terminate all running Activities and compensate all successfully completed Activities in the Sub-
Process it is applied to. If the Sub-Process is a Transaction, the Transaction is rolled back."

The standard, however, is a little bit vague about what actually triggers cancellation.
Here are just a few examples of scenarios in whose descriptions the standard applies the term "cancel":

• Throwing Cancel Event
• 'cancelRemainingInstances' attribute of Ad-Hoc Sub-Processes
• 'completionCondition' attribute of Multi-Instance Activities
• 'condition' attribute of ComplexBehaviorDefinitions
• 'isInterrupting' attribute of Start Events in Event Sub-Processes
• 'cancelActivity' attribute of boundary events

Do all these scenarios trigger a cancellation in the sense of the above mentioned statement?
This should be explained more precisely in the standard.

Furthermore, on page 301, there is this statement:
"Cancellation in turn can result in compensation of already successfully completed
portions of an active Activity, in case of a Sub-Process."

Why does the statement use "can result" instead of e.g. "always results"?
The standard should describe precisely under which circumstances cancellation results in compensation, and the circumstances under which cancellation does not result in compensation.

In chapter 10.5.4 "Intermediate Event", on page 258, there is the following sentence:
"An exception to this: an Intermediate Event with a Compensation trigger MUST NOT have an outgoing Sequence Flow (it MAY have an outgoing Association)."

This statement seems to be wrong. For example, figure 10.32 on page 176 shows several throwing Intermediate Events with outgoing sequence flows.