See also: IRC log
-> http://www.w3.org/XML/XProc/2007/06/14-agenda.html
Accepted.
-> http://www.w3.org/XML/XProc/2007/06/07-minutes.html
Accepted.
Alex gives regrets
Norm attempts to explain his proposal
Alex: I'm confused.
Norm points out that pipes inside parameter sets could be just like ports in steps.
Alex: Why not abandon parameters altogether?
Henry: I think it's a good
balance. I think it's important to preserve the simplicity of
simply setting p:parameter on a step.
... Especially when what you're setting it to is the value of
an option.
... If we made parameters only documents, you'd have to go way
around the house to do that.
... It has the property that I like which is that you can just
about ignore them if you don't use them.
... There are issues about defaulting, but I'm prepared to
leave them on the side for now.
... Two questions remain: if we acknowledge that the flow of
parameters is subsidiary to the flow of documents, what's the
declaration for the input?
... 1. It's basically an input, declare it and use it. We'll
steal a port name for this.
... 2. Avoid trespassing on the port namespace, make them
choose parameters everytime and there'll be some attribute on
input that lets you say that this is the parameter input
port.
... 3. Just use a distinguished element,
p:parameter-input
... I could live with any one of these.
Norm: I could live with any one
of them as well
... We don't seem to have strong consensus, I'd be inclined to
pick one with the understanding that we could change our minds
after living with it for a bit
Some discussion of a sequence of c:parameter documents or a c:parameters document with a set of parameter inside it.
Alex: I guess I'm fine with this.
Norm: Anyone not want to go there?
No one speaks up
<ht> port='parameter
<ht> 1) <p:input port='parameter'/>
<ht> 2) <p:input port='...' parameters='yes'/>
<ht> 3) <p:parameter-input port='...'/>
Straw poll: 1:1, 2:2, 3:5, abstain:1
Proposal: Norm will write up the proposal in a draft using p:parameter-input
Henry: I'm not convinced by
Jeni's arguments, I'd really rather not.
... It means that you have to can't use position for position
in the current sequence
... I think we should stick with the straightfoward definition
of position() in a sequence in an atomic step
... and have something else for the iteration count.
... There are some unaswered questions, but I think we can
answer them.
<MoZ> +1 for Henry's proposal
Henry: One case where we will
have to think about it is in a select of a p:input
... p:input select="position() mod 2 = 0" should return every
other document, but I'm prepared to leave that for another
day.
... We need to look very carefully at every place in the syntax
where the pipeline processor will evaluate expressions and
determine what the answer is.
... There are two places, one is p:input; the other is, if we
keep it there, the select on for-each itself.
Norm: Anyone in favor of position()?
None heard.
Proposal: the next draft add a
p:index() function which performs iteration counting.
... We'll still use position() for sequence counting in atomic
steps.
Accepted
Norm: Does anyone want to
champion changes in this area?
... I don't hear anyone, so the status quo remains.
Norm: We delayed this until position() was settled
Henry: Right. Now we have, I
think we can go ahead with p:split-sequence
... last() means what it should mean when evaluated by a
component in the context of a sequence and component
implementors have to get it right.
... users will have to understand that they lose streaming if
they do so.
Alex: There are lots of XPath expressions that don't stream.
Henry: Yes, but it's worth noting that this is the next level up. This makes you buffer the entire document sequence.
Norm: Anyone opposed to Henry's proposal?
Accepted.
Norm: Let's start with the straight-up question, does anyone think we can't simply delete it?
<MoZ> Me !!
Henry: If you don't have it, then it forces you to write a p:input on p:for-each even though defaulting does the right thing in all other places
Norm: It's already on iteration-source, I want to delete it from for-each
AM: In that case, I'm for deleting it
Mohamed: Main argument for keeping it is to keep the parallelism with viewport
... We do have to tweak the semantics of select on p:input (and friends) . . .
Norm: Should we talk about that?
Mohamed: Yes
Norm: Implementation uncovered for me that selecting on an input (or for-each) you don't recurse
... I think that's nuts
... If you have four divs with 7 divs nested inside, you should get 11 documents
... comments/disagreements?
Mohamed: I think this will be difficult to implement for p:input, and therefore for p:for-each if we remove select from p:for-each
Norm: I think it's easy to do this, using existing libraries
Henry: It's easy to do the current semantics with a streaming implementation, and hard to do the proposed semantics
Norm: I will lie down in the road if we keep the current semantics and still call it 'select'
Henry: Agreed that it's change the name or change the semantics, status quo is not good
Henry: What about the following argument: we do have match semantics for viewport, where the coherence of the operation requires it.
...But for for-each, it's not as much like viewport as we might think. It's there so that you can demultiplex a sequence to use steps that require single documents.
...If we haven't had a select on for-each at all, I'm not sure that I would have complained.
...That's the point
that I've arrived at. Another observation: it will always be
possible to write xh:div[not(ancestor::xh:div)]
to get the top-level divs.
Henry: If we move to pure select semantics on input.
...I've talked myself into saying that there's no special semantics required for an attribute on for-each. It's like any other component that takes a sequence.
...On p:input, I don't have a problem with saying that 'select' should have ordinary "select" semantics.
Henry: so is iteration-source shared by for-each and viewport ?
Norm: No, viewport has viewport-source , which doesn't allow select
Norm: Does anyone object to changing the semantics of 'select' on input to be full selection semantics (i.e. no partial match semantics)
Norm: RESOLUTION: Change the semantics of 'select' on input to be full selection semantics (i.e. no partial match semantics)
Norm: Any objections to removing 'select' from p:for-each?
Norm: RESOLUTION: Remove 'select' from p:for-each