Comments on the Editor's Draft 2 April 2008

Hi all,

I just read through the latest Editor's Draft (2 April), and I have
found a couple of things that I would like to comment on.

*** Implicit error output ports

Section 2.1: "All steps have an implicit output port for reporting
errors that must not be declared."
Section 2.2: "Steps may also produce error, warning, and informative
messages. These messages appear on a special 'error output' port. Error
output ports are un-named, and only accessible via the automatic
connection made from them to the primary input of the p:catch
subpipeline of an immediately containing try/catch"

Since the error output ports are unnamed, does the statement in Section
2.1 make any sense? I mean, you can use any name when declaring an
output port and it will never clash with the 'error output'. Actually,
do we need to mention 'error output' ports at all? Isn't the way
(dynamic) errors are handled completely implementation-dependent? If I
read Section 4.6 (p:try) alone, it makes no reference to 'error output'
ports, but it is still perfectly understandable.

*** Usage of the word 'connected'

One thing that I have found quite confusing while trying to understand
XProc is the way the word 'connected' is used in the spec. After some
time, I came to the conclusion that it has the same meaning as 'bound',
but I am still not sure. I think the most confusing part for me was in
Section 2.2:

The declared outputs of a step may be connected to:
    * The input port of some other step.
    * One of the outputs declared on its container.

It actually took me some time to realize that I should read this "in the
opposite direction". That is, that some other step's input port may be
connected to the output port, or that an output port of the container
may be connected to the output port.

Related to this, I wonder whether the following requirement (also
Section 2.2): "The primary output port of a step must be connected." is
really necessary. Or does it apply only for compound steps? If I take it
literally, it would mean that:

    <p:input port="source">
      <p:document href="..."/>

is invalid because the primary output port if the first p:identity step
is not connected.

*** Implicit primary output port of a compound step

Section 2.3: "If a compound step has no declared outputs and the last
step in its subpipeline has an unbound primary output, then an implicit
primary output port will be added to the compound step."

Since the last step is defined as the last step in document order, I
wonder whether the implicit output port is added to the container in the
following example (I think so) - and what it is bound to:

  <p:identity name="identity1">
    <p:input port="source">
      <p:pipe step="identity2" port="result"/>
  <p:identity name="identity2"/>

In the example, the two p:identity steps will be executed in the
reversed order (identity2, identity1), so I would expect that the
primary output port on p:group would be bound to the primary output of
identity1. But identity1 is not the last step in the subpipeline...

*** Options/Variables

Section 2.8 (Options) contains the following sentence: "Unlike
variables, the value of an option can be changed by the caller." I think
a similar sentence should be in Section 2.7 (Variables). Otherwise
Section 2.8 is the first place where you learn about this "immutability"
of variables.

Actually, now I am not even sure what "the value of an option can be
changed by the caller" precisely means. Does it mean that you can
override the default value of an option?

*** Options and in-scope bindings

Section 2.5 does not say how options are evaluated and added to in-scope
bindings. Or is it stated somewhere else?

*** Typo in Section 3.8:

"If an XProc processor can determine statically that a dynamic error
will always occur, it may report that error statically provided that the
error does occur among the descendants of a p:try."

I think this sentence should read:

"If an XProc processor can determine statically that a dynamic error
will always occur, it may report that error statically provided that the
error DOES NOT occur among the descendants of a p:try."


Vojtech Toman
Principal Software Engineer
EMC Corporation

Aert van Nesstraat 45
3012 CA Rotterdam
The Netherlands

Received on Friday, 4 April 2008 15:25:39 UTC