Re: Cardinality of inputs & outputs

/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| Norman Walsh wrote:
|> / Jeni Tennison <jeni@jenitennison.com> was heard to say:
|> |> Do you have any use case in mind ?
|> |
|> | An optional pre/post-processing step. If the 'preprocess' step has a
|> | document on it, use it to transform the source prior to the other
|> | processing; if not, then just use the source as-is.
|>
|> How do you do that?
|
| Currently, I'd do:
|
| <p:pipeline>
|   <p:input port="source" />
|   <p:input port="preprocess" sequence="yes" />
|   <p:count name="nPreprocess">
|     <p:input port="source">
|       <p:pipe source="preprocess" />
|     </p:input>
|   </p:count>

Ok, that was the only way I could think of to do it too. I think this
is a compelling reason to keep the p:count step :-)

| I'm forced to specify the 'preprocess' port as a sequence despite the fact that
| I only want it to hold a maximum of one document.

I see the trade off this way:

With the status quo: sequence=yes means zero-or-more, no means 1. That
means that when you want to allow zero-or-one, you have to specify a
sequence even though that's not exactly what you mean.

If we add new options to support 0-or-1, 1, 0-or-more, 1-or-more then
you get finer control for the use cases where you want it. But it
also means that we have to explain this variety of options, introduce
markup for it, and implementations have to test for dynamic errors
against all these options.

On balance, I'm not sure the added complexity of supporting four options
is justified by the added functionality.

I don't feel strongly, but it's not obviously worth it to me.

|> | Another example is
|> | the 'source' input on the p:xslt2 step: not all transformations
|> | require source documents.
|>
|> I had expected the xslt2 step to require either exactly one source
|> document or an initial template name, or both. I would have expected a
|> source with no documents on it to be an error.
|>
|> I'm not sure that's justified, but it's what I would have expected.
|
| (In fact, the way p:xslt2 is specified is a lot better than either of our
| expectations, but let's pursue this...) It sounds like you agree that steps
| might have optional inputs. The problem is
|
| (a) there isn't a required attribute allowed on <p:input>
| (b) all inputs must be specified or the step no longer matches its signature
|
| As I said to Mohamed, I think that using the cardinality of an input is a lot
| less disruptive than introducing the concept of non-required inputs.

Indeed the binding issue is tricky. Our defaulting story for inputs
means that it's almost always the case that an input not explicitly
bound gets implicitly bound somewhere. So I think if you want an unbound
input we either have to provide new markup or you have to explicitly
bind it to an empty sequence:

  <p:input port="source"><p:inline/></p:input>

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | A toy car is a projection of a real
http://nwalsh.com/            | car, made small enough for a child's
                              | hand and imagination to grasp. A real
                              | car is a projection of a toy car, made
                              | large enough for an adult's hand and
                              | imagination to grasp.--Michael Frayn