- From: Norman Walsh <ndw@nwalsh.com>
- Date: Wed, 20 Jun 2007 07:42:27 -0400
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <871wg63l98.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/06/14-minutes
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 71, 14 Jun 2007
Agenda[2]
See also: IRC log[3]
Attendees
Present
Rui, Alessandro, Paul, Alex, Norm, Henry, Andrew, Richard, Mohamed
Regrets
None
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 21 June 2007
4. Simplify parameters per Norm's observations
5. Using context position to count interations through a loop
6. Cardinality of inputs
7. p:head/p:tail and secondary outputs
8. @select on p:for-each
* Summary of Action Items
----------------------------------------------------------------------
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]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2007/06/14-agenda.html
[3] http://www.w3.org/2007/06/14-xproc-irc
[7] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[8] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[7] version 1.128 (CVS
log[8])
$Date: 2007/06/20 11:40:34 $
Received on Wednesday, 20 June 2007 11:42:54 UTC