XML Processing Model WG

Meeting 66, 3 May 2007


See also: IRC log


Norm, Mohamed, Alessandro, Paul, Henry, Andrew, Michael, Alex
Richard, Rui


Accept this agenda?

-> http://www.w3.org/XML/XProc/2007/05/03-agenda.html


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2007/04/04/26-minutes.html


Next meeting: telcon 10 May 2007

We have regrets from Rui, Alessandro, Michael

Open action items

Henry to propose a debugging alternative to p:tee

<scribe> Completed.

Alex to craft a proposal on serialization

<scribe> Continued.

Options vs parameters

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0023.html

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.

Alessandro: Why?

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

<alexmilowski> http://www.w3.org/XML/XProc/docs/langspec.html#dt-in-scope-parameters

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 programming languages.
... 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 place.
... 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 change.
... 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.

Norm: good.

p:tee proposal or alternate debugging proposal

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0138.html

-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007May/0060.html

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

No one.

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?

<MoZ> $p:position

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?

<ht> href="'foo.xml'"

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

<ht> href="concat('foo',$p:position,'.xml')"

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 for-eaches.
... 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'/>

<ht> </p:input>

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]

Any other business

Henry: Are we meeting in November?

Norm: I think we said yes, but I'll double check.


Summary of Action Items

[NEW] ACTION: Henry to write up all the variables/functions he wants. [recorded in http://www.w3.org/2007/05/03-xproc-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/05/21 12:42:41 $