Re: why the output requirements on viewport?

In addition, p:for-each has the ability to dig recursively into the XML,
which might make it even more useful for that purpose.

Say you have this input XML:
<doc>
    <div id="A"/>
    <div id="B">
        <div id="C"/>
    </div>
</doc>

If you use p:viewport to match "div" elements, you wouldn't match the C
element since it's wrapped inside another div element. With a p:for-each
however, you would (unless you explicitly do something like
select="//div[not(ancestor::div)]").

Still, I agree that empty outputs should be allowed on p:viewport, which as
you say would behave like p:delete.

Regards
Jostein

2012/3/13 Leif Warner <abimelech@gmail.com>

> Would the p:for-each step be a good alternative where you're not going to
> connect the output to another port?
> -Leif
>
>
> On Mon, Mar 12, 2012 at 9:13 PM, Conal Tuohy <conal.tuohy@versi.edu.au>wrote:
>
>> **
>> Why does the XProc spec require viewports to have a primary output?
>> http://www.w3.org/TR/xproc/#err.S0006
>>
>> The p:viewport must contain a single, *primary output port<http://www.w3.org/TR/xproc/#dt-primary-output-port>
>> * declared explicitly or supplied by default<http://www.w3.org/TR/xproc/#primary-input-output>.
>> If that port has no *connection<http://www.w3.org/TR/xproc/#dt-connection>
>> *, then it is connected to the *primary output port<http://www.w3.org/TR/xproc/#dt-primary-output-port>
>> * of the *last step <http://www.w3.org/TR/xproc/#dt-last-step>* in the *
>> subpipeline <http://www.w3.org/TR/xproc/#dt-subpipeline>*. It is a *static
>> error <http://www.w3.org/TR/xproc/#dt-static-error>* (err:XS0006<http://www.w3.org/TR/xproc/#err.S0006>)
>> if the primary output port is unconnected and the *last step<http://www.w3.org/TR/xproc/#dt-last-step>
>> * in the subpipeline does not have a primary output port.
>>
>> http://www.w3.org/TR/xproc/#p.viewport
>>
>> I can see that it is generally useful to provide an output (when using
>> the viewport as a way of transforming a document by transforming chunks of
>> it) but equally it's sometimes unnecessary (when using the viewport merely
>> to break the document into chunks for independent processing in their own
>> right). It seems to me that in those cases where a viewport's sub-pipeline
>> merely consumes the sequence of documents without producing any output, the
>> viewport could simply remove the matched elements (i.e. it would behave
>> like p:delete, seen from the outside).
>> --
>>
>> Conal Tuohy
>> eResearch Business Analyst
>> Victorian eResearch Strategic Initiative+61-466324297
>>
>>
>