"Fixing parameters"

Hi folks,

Here's a proposal for "fixing parameters".

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

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:input port="source" sequence="true" primary="true"/>
      <p:input port="stylesheet"/>
      <p:output port="result" primary="true"/>
      <p:output port="secondary" sequence="true"/>
      <p:option name="initial-mode"/>
      <p:option name="template-name"/>
      <p:option name="output-base-uri"/>
      <p:option name="version"/>
      <p:parameters name="parameters"/> <!-- *** -->
   </p:declare-step>

3. Steps accept parameters just like options:

   <p:xslt parameters="{$parameters}"> ...

   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.

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="{()}".

   We could simplify our lives a lot by removing this magic copying,
   but I think we probably still need it.

   It is not an error if the enclosing pipeline has no parameters with
   the same name, the set of input parameters is simply an empty map.

6. The XML serialization of parameters is still useful, so we keep that.

7. We probably need a new function that takes an XML serialization of
   parameters and returns a map.

Maps have to be immutable, so we'll need to work through some of the
details with care.

                                        Be seeing you,
                                          norm

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