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.

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

There is an apparent conflict in the specification concerning the permissible Start Event types for an Event Sub-Process.

On Page 174, the specification states: "The Start Event of an Event Sub-Process MUST have a defined trigger. The Start Event trigger (EventDefinition) MUST be from the following types: Message, Error, Escalation, Compensation, Conditional, Signal, and Multiple." This enumeration excludes the Timer and Parallel event types.

This specification appears inconsistent with the restriction on Page 241, which additionally allows Timer and Parallel event types for the Start Event: "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."

It is consequently unclear whether Timer and Parallel events may be the Start Event in an Event Sub-Process.

In chapter 2, sub clause 2.1, page 1 it is written that "Process Modeling Conformance type SHALL comply with all of the requirements set forth in sub clause 2.1". However, the requirements are set forth in sub clause 2.2. Also, the sentences after that refer to sub clauses 2.2, 2.3 and 2.4 but these should refer to 2.3, 2.4 and 2.5.

In short: references to the requirements for the different conformance types should be to 2.2, 2.3, 2.4 and 2.5 and not 2.1, 2.2, 2.3 and 2.4.

In several occasions, the BPMN 2.0.1 specification uses the keywords "MAY NOT". This keywords, however, are not valid according to RFC 2119.

Probably "MUST NOT" would be correct. (Please note: the opposite of "MAY" is not "MAY NOT"!)

Version 2.0.1 is still referring to the sub clauses 2.1-2.4 (as in Version 2.0) even though they have changed to 2.2-2.5

In Table 10.52 the description of DataObject.IsCollection reads "If an itemDefinition is referenced, then this attribute MUST have the same value as the IsCollection attribute of the referenced itemDefinition".

This description prevents BPMN from defining a collection of DataObjects on a single Item Aware Element referred to by an Item Definition. Therefore, if I wish to model an individual item X and a collection of item X they need to reference different item definitions - surely this is not the intent.

I propose rewording this sentence to read "If a referenced itemDefinitions isCollection attribute is set to true, then this attribute MUST also be set to true".

I don't know if there is a flow-on effect to other areas of the documentation.