W3C home > Mailing lists > Public > xproc-dev@w3.org > June 2009

RE: Implicit output ports and p:declare-step

From: <Toman_Vojtech@emc.com>
Date: Thu, 25 Jun 2009 02:54:09 -0400
Message-ID: <6E216CCE0679B5489A61125D0EFEC7871001F85E@CORPUSMX10A.corp.emc.com>
To: <xproc-dev@w3.org>
> I can see several options:
> 1. We say that the implicitly created port is named "result".

Definitely better than having an anonymous port. It would also make it
possible to address the results of other compound steps (not just
p:declare-step) that have no explicit output ports:

<p:group name="foo">

  <p:input port="source">
    <p:pipe step="foo" port="result"/>

But still not sure we should go that route (creating implicit primary
output ports).

> 2. We say that it's your bug, you fix it. Either by making
>    the port name explicit or by adding an identity step.
>     <px:fred name="myproc"/>
>     <p:identity name="myproc-identity"/>
>     <p:store href="fred-output.xml"/>
>     <p:identity>
>       <p:input port="source">
>         <p:pipe step="myproc-identity" port="result"/>
>       </p:input>
>     </p:identity>

Would that be declaring victory, or admitting defeat? I am still trying
to understand whether the implicit primary output port in p:declare-step
is a feature, or a bug. If we don't change anything, we probably should
make it more explicit to the users that they should be aware of yet
another (weird?|great?) feature when writing pipelines.

> 3. We say that the rules about defaulting output ports don't apply to
>    p:declare-step.

That was my initial opinion, but that might be too strict, or too big a
change at this moment.
Now I lean more towards option 1 - if we are going to change anything,
this one seems to be simple enough, and it would actually add something
to the language (you can always address the output of compound steps
with no explicit output ports)

> Choice 2 is the only one that requires no changes to the spec.
> But now consider how implementations interface with pipelines. Mostly,
> I think, implementors (and APIs) are going to want to use port names.
> XML Calabash, for example, has -i/port/ and -o/port/ options for
> binding inputs and outputs. As long as port names are uniformly
> available, we can have a clean port-name based interface.

That is how I discovered the problem. I ran a pipeline with no output
ports using our command-line interface, and to my surprise, I saw output
on stdout. But if you want to, let's say, redirect the primary output
port, you can't because it has no name.

In our API, it is less of an issue. When you run a pipeline in Calumet,
you get a PipelineOutput object that provides you with access to all
output ports of the pipeline, also indicating which one is primary. So
in the case of a pipeline with no explicit output ports, you will still
be able to address the implicit port.

Received on Thursday, 25 June 2009 06:55:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:05 UTC