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.

I am beginner in BPM but in order to understand the BPMN standard, I send these questions: 1) Why in paragraph 7.1.1 Uses of BPMN, the definition of Collaboration (Global) Process (page 14) says: The collaboration process can be shown as two or more abstract process communicating with each other (see figure 7.3).... But the Figure 7.3 looks like as "two or more private (internal) business processes communicating with each other", comparing the Figure 7.1 and Figure 7.2 For more emphasis what I saying In the Figure 7.3 both process (patient and Receptionist/Doctor), all activities for both process are shown, this is not agree with definition of Abstract (public) process (page 13), that says: ....All other "internal" activities of the private business process are not shown in the abstract process.... 2) if the difference between Private (internal) business processes and Collaboration (Global) processes is the number of business entities, this mean that : Private (internal) business processes for only one business entity or specific organization. Collaboration (Global) processes for two or more business entities. What about Abstract (Public) processes, how many entities are or can be involved? 3) The Abstract (public) Processes are "abstract" because the activities of the another process or participant are not shown ?, using words of the definition of the Abstract (public) Processes.

Page 19 (PDF page 43) Table 8.2, definitionof "Pool". Should lanes within pools be referred to as "Lanes" or "Swimlane"? Both terms are used. It would be good to be consistent.

Where an activity represents an invocation of an independent
subprocess, the spec does not state how to bin any incoming and
outgoing message flows to the sub-process. It does state how to bind
information (input and output sets) but not messages.

The BPMN 1.0 version of the Exclusive Gateway merging (either data or event Gateways) acts as a "pass through" for any Tokens that arrive. This means that there is no "exclusiveness" to the merging as the name of the Gateway would imply. A "discriminator" merging that allows the first Token through and stops any further (parallel) Tokens is a business pattern that cannot be currently modeled. This functionality should either replace the current merging behavior or be added to the behavior.

Update the definition of the merging behavior of the Exclusive Data-Based Gateway. Currently, the Gateway just passes all Tokens through. The behavior should be changed to be exclusive in that it will allow the first Token to arrive through the Gateway, but ignore/consume all other Tokens from the same Token family.