Parameters middle ground

Been thinking about parameters again. Our requirements document says
we're going to drop them, but we know that's not ideal.

Using AVTs is going to make options much nicer:

  <p:xslt initial-mode="{$mode}" output-base-uri="{$base}">
    ...
  </p:xslt>

But for parameters you'd still have to say:

  <p:xslt initial-mode="{$mode}" output-base-uri="{$base}">
    <p:with-param name="param1" select="'value1'"/>
    <p:with-param name="param2" select="$value2"/>
    ...
  </p:xslt>

which is kind of ugly.

Suppose we add a p:parameters element that you can use with AVTs:

  <p:xslt initial-mode="{$mode}" output-base-uri="{$base}">
    <p:parameters param1="value1" param2="{$value2}"/>
    ...
  </p:xslt>

(We could add a p:options element too, for parity, but I'm not sure
how I feel about that. Let's set it aside.)

Then we could say that the "step" attribute on p:parameters is the
name of (an ancestor compound) step. The semantics of using the step
attribute would be that all the parameters provided to the identified
step would also be provided to the step on which the reference occurs.

Multiple p:parameter elements could be used. Here's a pipeline that
copies all externally bound parameters to the XSLT step.

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc"
                version="2.0" name="main">
  <p:input port="source"/>
  <p:output port="result"/>
  <p:serialization port="result" indent="true"/>

  <p:xslt>
    <p:parameters step="main"/>
    ...
  </p:xslt>
</p:declare-step>

This doesn't address the use case where the pipeline utterly fails to
mention any parameters. But I think we can leave that problem on the
floor.

Thoughts?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 512 761 6676
www.marklogic.com