Re: Comments on the Editor's Draft 2 April 2008

/ Toman_Vojtech@emc.com was heard to say:
| 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

I tried to clean this up.

| *** 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:

I added a new sentence to the first paragraph of Section 2, does this
help:

[Definition: A pipeline is a set of connected steps, with outputs of
one step flowing into inputs of another.] A pipeline is itself a step
and must satisfy the constraints on steps. Connections between steps
occur where the input of one step is bound to the output of another.

| 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:pipeline>
|   <p:identity/>
|   <p:identity>
|     <p:input port="source">
|       <p:document href="..."/>
|     </p:input>
|   </p:identity>
| </p:pipeline>
|
| is invalid because the primary output port if the first p:identity step
| is not connected.

Indeed. The fact that the primary output of the first p:identity step
is not connected to any input is a static error.

I think the advantage of this requirement is that it catches errors.
The fact that you're letting a primary output flow onto the floor is
probably an error.

| *** 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:group>
|   <p:identity name="identity1">
|     <p:input port="source">
|       <p:pipe step="identity2" port="result"/>
|     </p:input>
|   </p:input>
|   <p:identity name="identity2"/>
| </p:group>
|
| 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...

That pipeline contains a static error. The step 'identity1' has an
unbound primary output port. Since it isn't the last step in document
order it is not (cannot) be implicitly bound to the output of the
p:group.

| *** 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?

Yes. And I've added some new text to the start of 5.7 which I hope
clarifies this.

| *** 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?

I think that's described later on, in the sections on variables and options.

| *** 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."

Definitely, thanks.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | If you run after wit you will succeed
http://nwalsh.com/            | in catching folly.-- Montesquieu