See also: IRC log
-> http://www.w3.org/XML/XProc/2007/06/07-agenda.html
Accepted
-> http://www.w3.org/XML/XProc/2007/05/24-minutes.html
Accepted
Norm will be calling from JFK, Henry to chair in his absence
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
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.
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?
Nope
Let's leave it for a week and do a straight vote next week.
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.
None