XML Processing Model WG

Meeting 70, 7 Jun 2007


See also: IRC log


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


Accept this agenda?

-> http://www.w3.org/XML/XProc/2007/06/07-agenda.html


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2007/05/24-minutes.html


Next meeting: telcon 14 June 2007

Norm will be calling from JFK, Henry to chair in his absence

Using context position to count iterations through a loop

Henry summarizes his mail

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

Henry's message clearly raises a substantial issue; defer to email again.

Richard reminds us why position() doesn't work for most of the cases of for-each

Richard: Consider the second step of the subpipeline inside a for-each; the position() in that step refers to the output from the first step, not the for-each


Norm: Is anybody unhappy with the revised proposal that I sent for the next draft?

Henry: I can go either way, but I have to say I like the nested approach better than the attributes case.

Henry meant the p:use-parameter-set element instead of the attribute.

Henry: That removes the need for an inherits attribute.

Norm: Anyone feel strongly the other way?
... I'm happy to implement it that way instead.

Norm asks the question again.

Henry: It's not clear how this effects the vanilla case.

Some discussion of elements vs attributes (@use-parameter-set vs p:use-parameter-set)

Mohamed: I think it's totally equal to have elements or attributes.
... But I prefer to have elements.

Alex: I prefer the attribute syntax, but I'm not going to stand in the way of progress.

The proposal is accepted

What's the default for steps that don't specify any parameter sets?

Norm: I think its either none or the parameters from the pipeline

Mohamed: Are we talking about parameters and options or just parameters?

Norm: Just parameters.

Straw poll: 2 for none, 2 for pipeline, 2 concur, and 1 abstain

Norm: The editor will do something and mark the issue unresolved.

Cardinality of inputs

Norm attempts to explain the 0 or 1 case

Some discussion of using p:count and choose to deal with the optional input anyway

Henry: It feels like creeping featurism, but I want the 90% case to still not require any more work.
... I'm not happy if I have to specify two attributes to get 0 or more.

Norm: Anyone opposed to this change?

Henry: I don't prefer to make it, but I could live with it.
... Any advocates on the call?


Let's leave it for a week and do a straight vote next week.

p:head/p:tail and secondary outputs

Henry: I'm opposed to secondary outputs by simply grabbing the input a second time and inverting the test.

Norm: I'm sort of in the same camp, I fear the overhead of dealing with ignored secondary outputs.

Henry: We've got a natural tension between some folks who think if a small number of components will do it, we're done, and others who think that if there are common assemblies, we should make components for them.

Mohamed: When I proposed p:head/p:tail, I thought it would be like lisp where you could get both.
... Head and tail have the semantics of capturing both to me
... Since we can't make a recursive call, I think it would sometimes be a lot simpler to have two different answers.

Henry: I think there's some value to that position. If the proposal is to replace p:head and p:tail with p:split-sequence, that's more attractive.

The observation that split-sequence is matching-documents is made

Richard: This starts to sound like a for-each with a choose in it.

Henry: Split-sequence without a secondary output is just the same as matching documents.

Richard: If it's equivalent to that, we should have a separate step, but maybe it should be made more general.
... A step that takes a sequence input and produces a set of sequence outputs with a set of tests to determine which documents go to which outputs.

Henry: We don't have anything at the moment with arbitrary number of outputs.

Some discussion...

Henry: It would be like p:choose with branches that have guards.
... I think the 80/20 point is achieved by Mohamed's proposal.

Alex: I just want to point out that head and tail have to do with counting.
... There are a number of options that could be used to specify a range.

<ht> head and tail really are just sub-cases of matching-documents

Alex: One proposal would be to combine head and tail into one sort of "subrange" component.

<ht> position()>5 and position()<10

Alex: But you can't do what tail does.

Norm: I agree

Henry: You can if we take the hard decision about last()

Richard: I think we're doing this in the wrong order.
... Whether we want these special steps on position depends on whether the general steps will do what we want.

Henry: My current position is that, keeping Paul's advice firmly in mind, no p:head, no p:tail, no p:matching-documents, only p:split-sequence with two outputs.
... And allow last() to really be the real context size.

Mohamed: Now if we have last(), we don't need to have p:count

Some discussion of whether or not this is true; consensus that it isn't.

We still need p:count.

Henry: This gets us back to the the discussion at the beginning, what's the XPath context in the runtime.

Norm: I don't think we'll get final consensus on this until we've settled position() so I'll let this hang for another week as well.

Any other business?


Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/06/20 11:40:34 $