W3C

XML Processing Model WG

Meeting 71, 14 Jun 2007

Agenda

See also: IRC log

Attendees

Present
Rui, Alessandro, Paul, Alex, Norm, Henry, Andrew, Richard, Mohamed
Regrets
None
Chair
Norm
Scribe
Norm

Contents


Accept this agenda?

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

Accepted.

Accept minutes from the previous meeting?

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

Accepted.

Next meeting: telcon 21 June 2007

Alex gives regrets

Simplify parameters per Norm's observations

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

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

Using context position to count interations through a loop

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

Cardinality of inputs

Norm: Does anyone want to champion changes in this area?
... I don't hear anyone, so the status quo remains.

p:head/p:tail and secondary outputs

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.

@select on p:for-each

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

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/06/22 14:49:32 $