Re: p:output and connections

Vasil Rangelov <boen.robot@gmail.com> writes:
> Latest editor's draft, 3 November 2009
>
> 1) 5.4 p:output says
>
> "It is a static error (err:XS0029) to specify a connection for a p:output
> inside a p:declare-step for an atomic step."
>
> How is a step supposed to produce an output then?

It doesn't say you can't declare an output, it says you can't declare
a connection for it.

This is OK:

<p:declare-step type="ex:mystep">
  <p:input name="source"/>
  <p:output name="result1"/>
  <p:output name="result2"/>
</p:declare-step>

This isn't:

<p:declare-step type="ex:mystep">
  <p:input name="source"/>
  <p:output name="result1">
    <p:inline>
      <doc/>
    </p:inline>
  </p:output>
  <p:output name="result2"/>
</p:declare-step>

> Especially one where the
> result comes from a non-primary port of a step, or where it comes from the
> primary output port of a step other than the latest one. Consider the very
> first example:
>
> <p:declare-step xmlns:p="http://www.w3.org/ns/xproc"
>                 name="xinclude-and-validate"
>                 version="1.0">
>   <p:input port="source" primary="true"/>
>   <p:input port="schemas" sequence="true"/>
>   <p:output port="result">
>     <p:pipe step="validated" port="result"/>
>   </p:output>
>
>   <p:xinclude name="included">
>     <p:input port="source">
>       <p:pipe step="xinclude-and-validate" port="source"/>
>     </p:input>
>   </p:xinclude>
>
>   <p:validate-with-xml-schema name="validated">
>     <p:input port="source">
>       <p:pipe step="included" port="result"/>
>     </p:input>
>     <p:input port="schema">
>       <p:pipe step="xinclude-and-validate" port="schemas"/>
>     </p:input>
>   </p:validate-with-xml-schema>
> </p:declare-step>
>
> Doesn't the above sentence mean this creates a static error? Or am I wrong
> in assuming that "connection" is equivalent to "binding"?

Connection is equivalent to binding, but that's not an atomic step.

> 2) What happens if a connection is provided upon a call to an atomic step?
> Is this a static error, and if not, does the connection get used if the
> returned output is empty (and/or simply not populated by the step), or does
> it completely abolish whatever the step may have produced on that port?

A connection is only allowed in a p:output on a compound step.

> In other words, what happens if I have, say:
>
> <p:pipeline xmlns:p="http://www.w3.org/ns/xproc" version="1.0"
> name="pipeline">
>   <p:xslt>
>     <p:input port="stylesheet">
>       <p:document href="stylesheet.xsl"/>
>     </p:input>
>     <p:with-option name="version" value="2.0"/>
>     <p:output port="secondary">
>       <p:pipe step="pipeline" port="source"/>
>     </p:output>
>   </p:xslt>
> </p:pipeline>

That's an error.

Section 3.11 defines err:XS0044 for "any element in the XProc
namespace ... [that] has element children other than those specified
by this specification".

Section 5.4 defines p:output as empty then further qualifies that
definition with the statement that on "compound steps, the declaration
may be accompanied by a connection for the output."

So I assert that err:XS0044 applies in the case of your example above.

> Personally, I think this should either be explicitly stated as a static
> error

Fair enough. I don't have any problem adding an explicit static error
for this case.

> OR be used as a *default* connection in case the step produces an
> empty sequence on that port.

No. Atomic steps produce what they produce. It would be wrong (IMHO)
to allow the declaration to override what the step produces.

> In the case of the above example, it could mean
> that the source document will be provided on the secondary port if the
> stylesheet didn't produced a second document, but if the stylesheet did
> produced one or more secondary documents, they'll be seen there.

*Way* to complicated.

> 3) Is p:empty the default connection for the non-primary outputs of steps?

For atomic steps, there is no default, the step produces what it produces.
It's a black box.

For compound steps, there is no default, but if you leave them
unconnected then they will produce an empty sequence.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | What is familiar is what we are used
http://nwalsh.com/            | to; and what we are used to is most
                              | difficult to 'Know'--that is, to see as
                              | a problem; that is, to see as strange,
                              | as distant, as 'outside us'.-- Nietzsche