Re: <input> for <pipeline> (action A-87-01)

In the minutes of the 25 Oct 2007 telcon, the editor is instructed to
adopt the following resolution for top-level p:pipelines only, leaving
p:pipelines in libraries and p:declare-step open:

| |> I propose that we add the following, probably in 5.1, but perhaps in both
| |> 5.1.1 and 5.1.2, whatever seems best editorially.
| |>
| |>   An input declaration may include a default binding. If no binding is
| |>   provided for an input port which has a default binding, then the
| |>   input is treated as if the default binding appeared.
| |>
| |>   It is a static error to provide a default binding for a primary input
| |>   port.

The editor is concerned that this creates extra work that may need to
be undone in the future and extra complexity in the spec. He'd prefer
to resolve all of the cases at once. To that end, the following
proposal is offered:

In 5.1, add:

  An input declaration may include a default binding. If no binding is
  provided for an input port which has a default binding, then the
  input is treated as if the default binding appeared.

  A default binding does not satisfy the requirement that a primary
  input port is automatically connected by the processor, nor is it
  used when no default readable port is defined. Consequently, it is
  pointless to provide a default binding for any primary input port
  except on a p:pipeline that is invoked directly by the processor.

  It is a static error for a p:pipe to appear in a default binding.

Mohamed, I think, pushed back on making the use of p:pipe a static
error becase he envisioned using a p:input inside a p:option to
provide a default binding for option select attributes. But that
doesn't work anyway because a p:input inside a p:option is not a
declaration, it's a binding. So you can't do that. It seems to me that
forbidding p:pipe simplifies things significantly.

I think the consequences of this proposal are:

1. A top-level p:pipeline can provide defaults for all of its inputs,
be they primary or not.

2. A p:declare-step or a p:pipeline in a library can define defaults
for all of its inputs, be they primary or not, but defining a default
for a primary input is a no-op. It's never used since the the step,
when it's called, will always bind the primary input port to the
default readable port (or cause a static error).

3. You can't establish default bindings for p:option or p:parameters
because p:input in those cases isn't a declaration.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.