Re: "Fixing parameters"

"Toman, Vojtech" <vojtech.toman@emc.com> writes:
> 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?

We could say that, but I don't think we have to. That's a decision we
can make independently. (Though perhaps for consistency, we will
decide to allow it.)

At this point, unfortunately, I start to want to be able to declare
the types of options. What is an p:xslt step supposed to do if a map()
appears as the value of the initial-mode option, for example?

Ah, the slippery slope of every change...

> 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:
[...]
> 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...

And that's exactly why I didn't go that way. I still think that it
must be possible to pass parameters to the XSLT step in this pipeline:

  <p:pipeline>
    <p:xslt>
      <p:input port="stylesheet">
        <p:document href="style.xsl"/>
      </p:input>
    </p:xslt>
  </p:pipeline>

And I don't see how to do that without the automagic inheritance.

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

I hadn't thought of that, but yes, I think so.

> 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.

Good point. Perhaps we still want to keep p:with-param as a way of
setting individual parameter values as the result of evaluating an
XPath expression.

I don't think p:with-param is anywhere near as awkward and awful as
the parameter input port design.

> 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?

That was the heart of my statement that "we probably need a new
function that takes an XML serialization of parameters and returns a
map."

  <p:xslt parameters="{p:parameter-map('some-parameter-step-name', 'result')}"/>

I think that's got all sorts of implications that I haven't thought
through carefully :-)

                                        Be seeing you,
                                          norm

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