output (Z.100)

Concrete graphical grammar

<output area> ::=
<output symbol> contains <output body>

<output symbol> ::=
<plain output symbol>
| <internal output symbol>

<plain output symbol> ::=

<output body> ::=
<signal identifier>
[<actual parameters>]{, <signal identifier>
[<actual parameters>]}*
[to <destination>] [ via [all] <via path> ]

<destination> ::=
<PId expression> | <process identifier> | this

<via path> ::=
<via path element> {, <via path element>}*

<via path element> ::=
<signal route identifier>
| <channel identifier>
| <gate identifier>

There is a syntactic ambiguity between <PId expression> and <process identifier> in <destination>. If <destination> can be interpreted as a <PId expression> without violating any static conditions, it is interpreted as <PId expression> otherwise as <process identifier>. <process identifier> must denote a process, which is reachable from the originating process.

The <via path> is considered a list of <via path element>s.

via all may only be specified when there is no <destination>. via all represents multicast as explained in Model.

this may only be specified in a <process type definition> and in scopes enclosed by a <process type definition>.


Stating a <process identifier> in <destination> indicates the destination as any existing instance of the set of process instances indicated by <process identifier>. If there exist no instances, the signal is discarded.

If no signal route identifier is specified and no destination is specified, any process, for which there exists a communication path, may receive the signal.

The values conveyed by the signal instance are the values of the actual parameters of the output. If an <expression> in <actual parameters> is omitted, no value is conveyed with the corresponding place of the signal instance, i.e. the corresponding place is "undefined".

The PId value of the originating process is also conveyed by the signal instance.

If a syntype is specified in the signal definition and an expression is specified in the output, then the range check defined in § is applied to the expression.

The signal instance is then delivered to a communication path able to convey it. The set of communication paths able to convey the signal instance can be restricted by the via clause to the set of paths mentioned in the via clause.

If <destination> is <expression>, the signal instance is delivered to the process instance denoted by <expression>. If this instance does not exist or is not reachable from the originating process, the signal instance is discarded.

If <destination> is <process identifier>, the signal instance is delivered to an arbitrary instance of the process instance set denoted by <process identifier>. If no such instance exists, the signal instance is discarded.

For example, if <destination> is specified as Null in an output, the signal instance will be discarded, when the output is interpreted.

If no <destination> is specified, the receiver is selected in two steps. First, the signal is sent to a process instance set, which can be reached by the communication paths able to convey the signal instance. This process instance set is arbitrarily chosen. Second, when the signal instance arrives at the end of the communication path, it is delivered to an arbitrary instance of the process instance set. The instance is arbitrarily selected. If no instance can be selected, the signal instance is discarded.

Note that specifying the same <channel identifier> or <signal route identifier> in the via clause of two outputs does not automatically mean that the signals are queued in the input port in the same order as the outputs are interpreted. However, order is preserved if the two signals are conveyed by identical delaying channels, or only conveyed by channels with no delay, or if the originating process or service and the destination process or service are defined within the same block.


If several pairs of (<signal identifier> <actual parameters>) are specified in an <output body> it is derived syntax for specifying a sequence of <output>s or <output area>s in the same order specified in the original <output body> each containing a single pair of (<signal identifier> <actual parameters>). The to clause and the via clause are repeated in each of the <output>s or <output area>s.

Stating via all is derived syntax for multicasting the signal via the communication paths mentioned in <via path>, so that signals are sent in the same order as <via path element>s appear in <via path>, one via each <via path element>. Multicast denotes a sequence of outputs of the same signal. The values conveyed with each of the resulting signal instances are only evaluated once before interpreting the first output, implicit variables are then used to store the values for use in each output. If same <via path element> appears several times in a <via path>, one signal is sent for each appearance.

Stating this is derived syntax for denoting as <process identifier>, the implicit <process identifier> for the set of instances of which the process executing the output is a member.