RE: Parameters

> 1. There is a new function, p:parameters. It takes a single string
>    argument and returns a map from QNames to XDM item values.
> 
>    p:parameters() as map:map(xs:Qname, item()*)
>    p:parameters($name as xs:string) as map:map(xs:QName, item()*)
> 
>    The function p:parameters() is a shortcut for p:parameters('')
> 
>    The map returned by the p:parameters function is
>    implementation-defined. An implementation can initialize the XProc
>    environment with any number of such named maps through APIs that
>    are out the scope of the XProc specification.
> 
>    An implementation that is invoked from the command line, for
>    example, might provide command line switches for setting values in
>    the parameter maps. For example:
> 
>        calabash -p foo=bar -p other:foo=baz -p struct=@foo.xml
> 
>    might create two maps. One, named '', containing two keys, 'foo'
>    and 'struct' initialized respectively to the values "bar" and the
>    XML document in foo.xml. The second, named 'other' containing a
>    single key mapping 'foo' to "baz".

So if I understand this correctly, the p:parameters() function would allow you to access different named parameter maps. Do their names correspond to parameter options of the owner pipeline, or is it something completely implementation-defined? (Or a mix of both?) If it is completely implementation-defined, how do I, as a pipeline writer, know which names to refer to in the pipeline - and how do I, as a pipeline user, know which names to use on the command-line without having to look at the pipeline code?

> 
> 2. Steps, like XSLT, that use parameters declare a parameters option
>    for this purpose:
> 
>    <p:declare-step type="p:xslt">
>      <p:option name="parameters" select="p:parameters()"
>                as="map:map(xs:QName, item()*)?"/>
> 
>    Because the default value of the parameters option is the
> p:parameters()
>    function, options specified to the pipeline will still, by defualt,
>    pass through to the step.
> 

Does that mean that the option name "parameters" would be reserved and would get special meaning? I am all for adopting a naming convention in the standard library so that all parameters-holding options are named "parameters", but giving that name a special meaning? Hm...

Btw, why is the 'auto connecting' of parameters from the owner pipeline to steps so important? If it weren't, we could simply drop the notion of parameters altogether and use only regular options. Since we want to adopt XSLT 3.0 maps, it would work just fine.

Regards,
Vojtech


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

Received on Thursday, 20 February 2014 15:45:26 UTC