See also: IRC log
We have regrets from Rui, Alessandro, Michael
Henry to propose a debugging alternative to p:tee
Alex to craft a proposal on serialization
Henry: I think Richard and I are
alike in being sympathetic to Jeni's use cases, we're getting
things out of proportion here.
... XSLT is the only step that uses parameters at all.
... The simplest possible mechanism which allows them to work is therefore the best solution.
... I propose: http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0061.html
... Amended with the ability to unbind parameters.
Henry: p:parameter is the only
thing there is to do with parameters.
... All you can do is give them a value or ungive them a value. No namespace changing; no importing, no declaring. Nothing.
... The analogy Richard draws is with the environment and shell scripts.
... They're a single, global space and you can give them values and take them away and that's it.
... All the proposals about options are correct, I'm only arguing for a radically simpler parameter story.
Alex: We have three steps that
use parameters: XQuery and both XSLT's.
... I've been thinking about serialization parameters; we could use parameters for that.
... I think there are a lot of things where parameters are going to be useful.
... Including step types that we aren't defining.
Henry: I agree with the position
that Norm and Jeni agreed with is that the crucial thing about
them is that you don't know much about them
... The difference between what we have today and my proposal is get rid of import-parameter and parameter declarations.
Alessandro: So import-parameters is done automatically?
Henry: Yes, all the in-scope parameters are always availble.
Henry: Because all of the examples we've seen so far have import-parameters = "*"
Alex: And your implementation always has all the parameters available.
Norm: And how does undeclare work?
Henry: Making sure a parameter doesn't have a value seems like a marginal case, but I'd read <p:parameter name="foo"/> as an unbinding.
Alex: That's a little weird.
Henry: But value="" is perfectly sensible.
Norm: My concern is that one of the things I think XProc is going to be used for quite a bit is chaining together multiple XSLT steps. And most stylesheet authors put all their parameters in no namespace. So the proposal you're making, Henry, begs for collisions.
Alex: Looking at your example, the select="$per-page" will still be legal.
Henry: I think packaging up lots
of XSLT steps is something we're going to do a lot, but I
almost never use parameters from the command line for any of my
... Doing so is a dodgy business. If you're writing a carefully constructed pipeline to do a task, you'll know what the parameters are.
Alex: You can solve the random parameters from the command line use case with options or by massaging the stylesheet as part of the pipeline.
Norm: I'm in favor of simple, and I'm willing to float Henry's proposal to the public and see what they say.
Henry: What I think this will also really help our users. The way we were headed, with all this duplication, looked parallel but wasn't. Users were going to be baffled by the question of when do I use which.
Norm: I'm convinced that this proposal is sufficiently simple that we should try it.
Alex: Me too.
Alessandro: Me too, but I'm
concerned about this automatic import of parameters.
... Why not just make users list all the parameters explicitly?
Henry: What could possibly go
wrong from passing all the parameters?
... The only case that we're worried about is the case where you know that there's a collision between two stylesheets in the same pipeline.
... Alex pointed out that you can protect them if you know that's the case.
Alex: You already have a set of
parameters in the environment. Then there's a derivation done
to compute the actual parameters for each step.
... The actual parameters are the same as the in-scope parameters and you're done.
... The worst case is that you have to bind a bunch of extra parameters.
Alessandro: I guess I'm not
worried about implementation, I'm just thinking about
... Generally when you call a function, you enumerate the parameters that you're passing.
Henry: Exactly, that's what options are for.
Alessandro: You don't usually have all the parameters. It could be a security issue, there are lots of reasons.
Henry: You have to declare the options that you accept, you have to pass them explicitly, etc. Parameters are this funny business that we only have because of XSLT and its friends.
<Zakim> MoZ, you wanted to remind why we split options and parameters
Mohamed: I think we missed the
point about why we split options and parameters in the first
... We were thinking about collisions between parameters that were for steps and options that were for the pipeline processor.
Henry: Options are in a separate space; we've solved that problem.
Mohamed: I'm speaking options declared in the spec.
Henry: But they're in a separate
space from the names of parameters; that's not going to
... If there's a stylesheet that takes a parameter named "filename", no option can collide with that.
Mohamed: Consider this example: I have a pipeline with two XSLT steps. I want to make a parameter that called "filename" for the two steps.
Henry: Then you write in each step:
<ht> <p:parameter name='filename' value='$o1'/>
<ht> <p:parameter name='filename' value='$o2'/>
Henry: where o1 and o2 are *options* that you pass to your pipeline.
<ht> and say runipipe o1=x.xml o2=y.xml
Mohamed: The second point was that one day in import parameter we might have an "except" attribute.
<alexmilowski> The only feature we don't have is the one that Norm mentioned: Pass all options in namespace A as parameters to XSLT A and all options in namespace B as parameters to XSLT B.
<alexmilowski> ...which is OK by me.
<ht> <p:unbind-parameter name='foo'/>
Henry: if you really, really want
to make sure that no parameter named foo gets into a particular
step, then you write something like p:unbind-parameter.
... I'd be happier if a I saw a use case.
Norm: I'd be happier to write it up without that feature and see if the world demands it.
Henry: It's clear how we could add it.
Norm summarizes the proposal.
Alex: And sibling options cannot refer to each other.
Norm: I understood that we have
no forward references.
... Let's make that a separate issue.
... Anyone not understand our current proposal wrt options/parameters?
Norm: I propose to skip item 2; Alex has an open action to propose something about serialization; I think we should just put all these things in that proposal.
Alex: I think we've accepted the names unescape-markup and escape-markup, so I think we can drop that issue.
<ht> HST suggests that the right strategy wrt the 'sibling options' question is to a) be sure that wherever we allow an XPath expression in the spec., we specify the XPath context and b) the answer wrt options is "the options in the inherited environment"
Henry: I raised the question of
whether a component was the right way to do this.
... Or to think of it more as an annotation.
... I offered two proposals.
... The question is, at which end do you want to do the logging/journaling.
... One answer is: you do it at the place where the document comes from.
... So you could add <p:journal port="result" href="someURI"/>
... That doesn't require any changes, you just add that.
... The alternative is to go to the other end; on the input binding you could add a journal attribute.
<p:pipe step="s1" port="result" journal="someURI"/>
Henry: The disadvantage is that
it requires you to put in a p:input with explicit names and
things because it can't all be defaulted.
... On balance, I think I favor the first over the second.
... So there are three proposals: a new component, p:tee or something; p:journal element in a step; or the journal attribute which you can add to pipes.
Norm: Anyone else have an opinion?
Alex: The advantage of the builtin solution is that makes solving the sequence problem easier.
Henry: The thing that swung me to option 1 is that you have to add two elements and maybe a name to use a journal attribute in a fully defaulted pipeline.
Norm: Does anyone favor Henry's option 2 over his option 1?
Straw poll: Which do you prefer, the builtin journaling solution or a letting a component do it?
Journaling: 6; Step: 1; 1 Abstain (2 concur)
Norm: Anyone who can't live with the journaling element?
Norm: And sequences?
Henry: I think we should provide options that are always bound in an iteration and use attribute value templates to let the user specify how to deal with it.
Norm: We don't have AVTs. Do you really want to add them for this?
Henry: I'd be perfectly happy to say that the value of the href is an XPath expression, but then the 90% case is "'xxx'".
Norm: I have another: implementation defined.
Henry: I can live with that, but I think that having iteration and sequence number variables in the environment is going to turn out to be hugely useful.
Norm: This is Mohamed's p:position everywhere right?
Henry: Yes, but I think we're
also going to need named index iterations for nested
... we need both.
<ht> for iteration step name='foo', then an option p:foo_i is bound
Norm: I'm starting to feel like functions are a better way to do this than automatic variable bindings.
Mohamed: We have to figure out what it means to evaluate an XPath expression on a sequence.
<ht> <p:input select="foo">
<ht> <p:pipe step='s' port='p'/>
Mohamed: If we say that it's the same as evaluating the expression over each document in the sequence, then functions and variables are the same.
Norm: I'm still not sure I understand.
Henry: At the end of the day, what I want is a third variable or function which is unique per pipeline evaluation episode.
<scribe> ACTION: Henry to write up all the variables/functions he wants. [recorded in http://www.w3.org/2007/05/03-xproc-minutes.html#action01]
Henry: Are we meeting in November?
Norm: I think we said yes, but I'll double check.