Re: "Fixing parameters"

Norman Walsh writes:

> Here's a proposal for "fixing parameters".

Some things I don't understand, but +1!

> 1. Adopt the XSLT 3.0 extensions to the data model and functions and
>    operators to support maps

Yup.

> 2. Instead of specifying input ports, steps declare that they accept
>    parameters in a manner analogous to options:
>
>    <p:declare-step type="p:xslt" xml:id="xslt">
>       . . .
>       <p:parameters name="parameters"/> <!-- *** -->

So the value of 'name' is the name of a pseudo-option?

>    </p:declare-step>

> 3. Steps accept parameters just like options:
>
>    <p:xslt parameters="{$parameters}"> ...

             ^^^^^^^^^^
That has to match the name declared with p:parameters, right?

What about

     <[some step]>
      <p:with-option name="parameters" select="...."/>

or do we not need that given {}?
or do we add
      <p:with-parameters name="..." select="...."/>

That has the advantage of allowing several. . .

>    or
>
>    <p:xslt parameters="{map:put(map:new(), 'output-format', 'xhtml')}"> ...
>
>    I think maps basically have to be in variables, so we don't need
>    to support a <p:with-parameters> instruction.

Well, see above for a possible counter-reason.

> 4. If a step has no bindings for any of its parameters, and its enclosing
>    pipeline has a parameters with the same name, then those parameters
>    are passed in automatically. You can explicitly disable this with
>    parameters="{()}".

'Enclosing' runtime, or lexically?  Need an example.

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

Received on Thursday, 13 September 2012 17:20:31 UTC