RE: What are single, non-primary, output ports?

Thank you both for your answers.

> if, in a typical case, you don't need to read from 
> an output port, you don't want to p:sink it every time.

This is the key piece that I wasn't seeing/understanding.


Regards

Philip
________________________________________
From: xproc-dev-request@w3.org [xproc-dev-request@w3.org] On Behalf Of vojtech.toman@emc.com [vojtech.toman@emc.com]
Sent: 08 October 2010 08:54
To: xproc-dev@w3.org
Subject: RE: What are single, non-primary, output ports?

Personally, I see two mains reasons why some steps have a single,
non-primary output port:

1. In a typical case, the result of the step is not expected to
participate in the "default flow" of the pipeline, like the primary
output/input ports do. Often, the step produces a simple document that
indicates the result of some operation which is not a document
transformation. Another way of looking at this is that all standard
steps that produce documents in the xproc-step namespace (c:result,
c:param-set etc.) use a non-primary output port (with the possible
exception of p:http-requets, but only in a special case).

2. In contrast to primary output ports, non-primary output ports don't
have to be connected (in other words, there does not have to be another
step that reads from that port). This is sort of related to 1), because
if, in a typical case, you don't need to read from an output port, you
don't want to p:sink it every time.

Now, if you look at the four steps that you listed, the question is how
well do these two rules actually fit them... :)

- p:compare
This one is probably the most questionable one. If you are comparing two
documents, you typically want to know if they are equal or not, and the
only way to find out is to read the p:compare's output port. You can
make the comparison fail if the two documents are not equal, in which
case you don't need to read the output port, but still...

- p:parameters
Parameters... I think the main reason why p:parameters has a non-primary
output port (and a non-primary input port, too!) is to make it clear
that parameters are sort of different from normal documents flowing
through the pipeline, and as such they need extra care. You can view it
like this: if you really want to use p:parameters (and parameters in
general), you really want to be sure you know what you are doing, so
XProc forces you to connect everything explicitly :)

- p:store, p:xsl-formatter
I think the non-primary output port makes sense with these steps; they
just return the URI of the stored content. Typically, you don't care.

Regards,
Vojtech

--
Vojtech Toman
Consultant Software Engineer
EMC | Information Intelligence Group
vojtech.toman@emc.com
http://developer.emc.com/xmltech

Received on Friday, 8 October 2010 08:16:23 UTC