RE: "Fixing parameters"

Hi Norm, 

It looks simple and interesting. Some immediate questions:

1. After adopting the XSLT 3.0 extensions to the data model, I assume a value of an option can be a map, too - correct? If that is the case, do we need the distinction between options and parameters at all? Suppose we drop the notion of parameters altogether and keep only options, then we could do this:

<p:declare-step type="p: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 port="parameters"/>      <!-- map -->
  <p:option name="initial-mode"/>    <!-- QName -->
  <p:option name="template-name"/>   <!-- QName -->
  <p:option name="output-base-uri"/> <!-- anyURI -->
  <p:option name="version"/>         <!-- string -->
</p:declare-step>

And in the specification of the p:xslt step say:

"
If present, the value of the parameters option must be a map.
...
The XSLT stylesheet provided on the stylesheet port is applied to the document on the source port. Any parameters passed through the *parameters option* are used to define top-level stylesheet parameters.
"

This would things much simpler (maybe too simple?), almost a documentation issue. On the other hand, it would probably mean that we would have to drop the inheritance of parameters from the owner pipeline and other things...

2. The names of parameter maps are in the same scope as options, so that you can refer to both in XPath expressions, right?

3. One advantage of the current p:with-param syntax is that you can use different bindings for each p:with-param expression. How would we support that? There are at least two options: Keep p:with-param (or something similar) in XProc 2.0, or force the users to put the parameters in variables first and then refer to these. The latter has some disadvantages: unless we loosen the rules, p:variable must come before all steps in the sub-pipeline, and it also "spoils" the scope with unnecessary cruft.

4. A common use case is to have steps that produce parameters as a c:param-set/c:param documents. If we decided to drop p:with-param, how would you - without forcing the users to go to the bottom of the XProc hell and back - feed that output into some other step's parameters?


Regards,
Vojtech

--
Vojtech Toman
Consultant Software Engineer
EMC | Information Intelligence Group
vojtech.toman@emc.com
http://developer.emc.com/xmltech


> -----Original Message-----
> From: Norman Walsh [mailto:ndw@nwalsh.com]
> Sent: Thursday, September 13, 2012 4:54 PM
> To: public-xml-processing-model-wg@w3.org
> Subject: "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

Received on Friday, 14 September 2012 09:30:51 UTC