See also: IRC log
A-207-02: In progress.
Norm: None so far except for
cmsmcq's comments on the last editor's draft.
... We'll wait until next meeting after the comment period has closed.
Norm attempts to summarize, with kudos to Vojtech for an excellent XML Prague talk.
Norm: I think working on a concrete use cases/requirements document would help.
Cornelia: I think that's the right way to proceed.
Norm: Any volunteers to edit?
Alex: I did it last time, I could try.
Norm expresses concern about Alex's time commitments.
Alex: What about Murray?
Norm: If he showed up more often...
Vojtech: It'll be interactive, because we don't know what we want to focus on.
Alex: It's most just a matter of getting it setup.
Norm: Alex why don't you and I
try to get something started.
... Any issues to talk about today?
Alex: What about parameters?
Norm attempts to summarize.
<ht> I guess the hard questions are the use cases that Jeni raised which drove us to the complexity in the first place
Some discussion of using an option of type "parameters" that contains a map.
Alex: I think the question is how
to make this usable.
... I have a lot of pipelines where I have a set of options that come in that need to be turned into parameters.
... Using XQuery and XSLT steps, I have lots of parameters that are bound from pipeline options.
... There's the question of orchestrating this stuff such that the maps I'm using are connected correctly.
... What's the default map? In the context of a particular pipeline, if I've put parameters in a bag, I have to be able to access them.
Norm: Listening to your description, I wonder about order.
Alex: Aren't we talking about scoping here?
Norm: Yes, maybe.
Alex: You can think of it as
another set of inputs, but conceptually it's not a straight-up
port like we've talked about in the past.
... You can determine when things are dynamically computed.
... Or that should be the goal.
Norm: We clearly need a concrete proposal here.
Alex: A proposal should outline why we didn't like parameters as ports and how the proposal improves the situation.
<scribe> ACTION: Norm to write up an alternate parameters proposal in a little more detail [recorded in http://www.w3.org/2012/02/23-xproc-minutes.html#action01]
Vojtech: Alex often wants to change options into parameters, maybe it might be possible to pass parameter maps or options in scope to the step.
Norm: Very clever.
... Yes, being able to list either maps of parameters or options would be nice.
Vojtech: Moving options and parameters closer together would be good.
Alex: Dealing with mutable vs.
immutable values is also an issue. I often have a common set
that comes in from the outside that I then want to add a few
bits for just a step.
... Right now there's a bunch of with-params on the step right now and what we'd want to be able to say is that it's the global parameter set plus these additions.
... One approach is simplistic at the step: just pointing at different bags of parameters and outside of that there's some mechanism in the pipeline that determines what's in scope at that point. That pushes all the syntax out of the step and into the pipeline.
... The variables that are in scope can be declared outside of the expression.
... We could do something like that.
Norm: I think that's a hard question to answer in the abstract, but it's a use case we should keep in mind.
Alex: We should be working on use cases to demonstrate why the current situation is unwieldy and how an alternate proposal would be better.