Re: Parameters redux

/ Alessandro Vernet <avernet@orbeon.com> was heard to say:
| On 5/22/07, Norman Walsh <ndw@nwalsh.com> wrote:
|> I didn't add the concept of a default parameter port, but we do need the
|> concept of an implicit binding for parameter ports, I think. Otherwise,
|> the pipeline author has to explicitly allow parameters to be passed from
|> the pipeline to contained steps.
|
| Certainly, I wouldn't want to require parameters to be explicitly
| bound to a "for-each" or a "choose". Parameters visible outside of the
| "for-each" should be automatically visible inside of the "for-each".
| But I wouldn't expect parameters to be passed automatically to an XSLT
| step.

We could make the rules different for compound vs. atomic steps, but I
think the simplest thing to do is say that the parameters *are* passed
to the XSLT step. I think that is what users would expect, and what
should be most simple to write. Consider:

  <p:pipeline ...>
    ...
    <p:xinclude/>
    <p:validate-...>...</p:validate-...>
    <p:xslt>
      ...
    </p:xslt>
  </p:pipeline>

This is the pipeline I'm likely to write when I first start processing
my documents with XProc. Now if I decide that I want to pass a parameter
to the XSLT step, I think it's convenient and appropriate that if I pass
the parameter to the pipeline (on the command-line, for example) it will
get passed all the way down to the XSLT step.

In pipelines that are more complex, where there are multiple XSLT steps,
or other steps that accept parameters, the new functionality will give
the pipeline author the ability to control which parameters go where. So
that pipeline will naturally be more complicated, but I don't think the
proposal for that more complicated flexibility should change the status
quo in the simple case.

| We call all those steps, but attempting an analogy with other
| programming languages, XSLT or schema validations are more like
| functions, while "for-each" and "choose" are more like language
| constructs. A notion of scope is very natural for language constructs.
| But when dealing with things are more like functions, most languages
| avoid automatically exposing to the callee the parameters of the
| caller. Does this make sense?

It does, but it's not a distinction I want to make. For one thing, it
means that *every* XSLT step where I do want the pipeline parameters
to be passed to the step will need an additional binding:

  <p:input port="parameters">
    <p:port step="pipeline" port="parameters"/>
  </p:input>

Since I see that as the most common case, I'd like to default it.
Otherwise, I'm going to curse everytime I forget to do it and spend ten
minutes debugging a pipeline to figure out why my @%@$#! parameters
didn't work :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | If you settle for what they're giving
http://nwalsh.com/            | you, you deserve what you get.