Re: Parameters

On Wed, Mar 5, 2014 at 8:57 AM, Henry S. Thompson <> wrote:

> But, either I'm missing something, we've lost the un-named parameters?
> That is, from the command-line, I'm guessing you're assuming something
> along the lines of Norm's example for specifying parameters in _named_
> groups, but that's it.  Otherwise there's no way to know where to put
> parameter bindings which come from the command line, is there?
> That means we have no way to reconstruct the current simple command
> line for a pipeline with an xslt step, right?


The use case that we discussed at some length at the meeting in
Edinburgh was the "docbook stylesheet" example where you have this

    <p:input port="stylesheet"> ...</p:input>

and you want the parameters to be able to be controlled from the
outside.  Having that as magic is compelling but is it enough to have
this whole mechanism?  That's what we need to decide.

Here's the alternative via Vojtech's proposal:

  <p:input port="source"/>
  <p:output port="result"/>
  <p:option name="parameters" as="map:map(xs:QName, item()*)?" select="map{}"/>

  <p:xslt parameters="$parameters">
    <p:input port="stylesheet"> ...</p:input>



1. You probably can't use p:pipeline unless we say it always has a
'parameters' option now.
2. A user would need to know the name of the option used to pass
parameters when they specify parameter values from the outside.

If we added a 'parameters' option to p:pipeline, we'd be back to:

  <p:xslt parameters="$parameters">
    <p:input port="stylesheet"> ...</p:input>

I'm not sure how I feel about the above.

--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language

Bertrand Russell in a footnote of Principles of Mathematics

Received on Wednesday, 5 March 2014 22:53:43 UTC