W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > October 2013

Re: Parameters middle ground

From: Alex Milowski <alex@milowski.com>
Date: Tue, 29 Oct 2013 19:59:43 -0700
Message-ID: <CABp3FNKA7PZ04S_PxEtkudG4+u1zerkX0J_+5HYvd9-xWqVeMw@mail.gmail.com>
To: XProc WG <public-xml-processing-model-wg@w3.org>
On Tue, Oct 29, 2013 at 1:34 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> 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.)

Good up to this point.

> 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>

I don't like how this intrudes on the parameter names.  This means you
couldn't ever have a parameter named 'step'.

Couldn't we just add either:

   * an option to every step with parameters called 'parameters' that
takes a whitespace separated list of ancestor step names (same
semantics as you propose)
   * a p:use attribute that could be used on the p:parameters
attribute to do the what 'step' does.

I'm not a big fan of namespaced attributes.

I'd prefer a syntax outside of p:parameters as "inheriting" parameters
is a more complex use case and so a more complex (but not onerously
so) syntax is justified.

Another option is:

   <p:parameters param1="value1" param2="{$value2}">
      <p:use step="main"/>
      <p:use step="other"/>

which would have the effect of merging "main" and "other" and then
overriding/setting param1/param2.

--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language

Bertrand Russell in a footnote of Principles of Mathematics
Received on Wednesday, 30 October 2013 03:00:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:52 UTC