RE: Parameters

> There's only _one_ point at which parameter maps get created and bound
> to names, and that's at the entry to the whole XProc engine, i.e. on
> the command line as per Norm's 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".
> 
> or via some mechanism in a XProc example's API.

So given the above example, how does the pipeline user know that he has to use the name "struct"? Is that declared in any way in the pipeline? I guess I still don't see that bit.

> >>
> >> 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...
> 
> No, not at all.  The documentation of the xslt step has to say that the
> option named 'parameters' is used to initialise XSLT parameters, just
> as today it says "Any parameters passed on the parameters port are used
> to define top-level stylesheet parameters"

I see, p:parameters() is the default value, I missed that somehow.

> 
> > 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.
> 
> They are very similar, but without a little magic, of the sort provided
> by function calls and not by variable/option reference, you can't get
> all the way from the _default_ expression in a step signature to the
> top-level pipeline invocation (e.g. in
>   >>    <p:declare-step type="p:xslt">
>   >>      <p:option name="parameters" select="p:parameters()"
> you can't replace p:parameters() with $p:parameters and have anything
> useful happen.)
> 
> Hope this helps,

Thanks Henry, it indeed does.

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 16:25:49 UTC