Re: CR draft ready for review (Henry S. Thompson) writes:

> Toman_Vojtech writes:
>> I agree :) Personally I don't see any reason in forcing people to always
>> connect something to the primary (normal or parameter) input ports of
>> compound steps. They just hang there in the space, you don't have to use
>> them at all.
> Hold on.  What about the following [1]:
>   If no binding is provided for a primary input port, the input will
>   be bound to the default readable port. It is a static error
>   (err:XS0032) if no binding is provided and the default readable port
>   is undefined.
> I think this is as it should be.  I don't want to change it now.

Absolutely. That's not what's on the table. Consider this pipeline:

  <p:pipeline type="ex:mypipe">
      <p:input port="source">

The pipeline has a primary input port 'source' that's left dangling.
It's not used by p:identity so it just pours on the floor. That's what
we've been talking about.

The note about automatically binding p:sink to the parameter input
port is to avoid an error that doesn't exist: namely that it is an
error to leave input ports on a compound step unbound *inside the

The section you quoted above refers to this case:


It says that the input port on the ex:mypipe step will be bound to the
default readable port at the point of invocation. That is as it should

> I do
> note that we do something similar for p:variable, p:with-option and
> p:with-param, but p:for-each/p:iteration-source and
> p:viewport/viewport-source don't say what happens if there is no
> binding and no DRP, and the discussion of XPath context specifies an
> empty document or undefined in that case.  We should probably make
> this all a bit more consistent.

                                        Be seeing you,

Norman Walsh <> | Nothing will ever be attempted, if all            | possible objections must be first
                              | overcome.--Dr. Johnson

Received on Friday, 21 November 2008 17:35:19 UTC