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

Musings on parameters

From: Norman Walsh <ndw@nwalsh.com>
Date: Tue, 01 Oct 2013 15:57:28 +0100
To: public-xml-processing-model-wg@w3.org
Message-ID: <m238olrqcn.fsf@nwalsh.com>
Random thoughts from a few long drives.

If we remove parameter input ports, then we've lost the mechanism by
which steps which accept parameters are identified. Suppose instead of
adding one back in, we simply say that all steps accept parameters,
but most steps just ignore them.

It's nice and uniform and easy to explain.

And about setting them...this is kind of clunky:

  <ex:some-step opt1="5" opt2="{concat('test', $foo)}">
    <p:with-param name="param1" select="5"/>
    <p:with-param name="param2" select="/a/b/c"/>
  </ex:some-step>

It's a shame you can't use AVTs for the parameters. How about a new
element:

  <ex:some-step opt1="5" opt2="{concat('test', $foo)}">
    <p:parameters param1="5" param2="{/a/b/c}"/>
  </ex:some-step>

Then if we really, really going to stretch things, we could say that
'step' on p:parameters can name an ancestor step with the semantic
that any parameters passed to that ancestor are also passed to this
step.

  <p:declare-step name="main">
    <p:xslt>
      <p:parameters step="main"/>
      <p:with-param name="step" select="3+5"/>
    </p:xslt>
    ...

Any of these ideas any good?

                                        Be seeing you,
                                          norm

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

Received on Tuesday, 1 October 2013 14:57:58 UTC

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