See also: IRC log
Date: 24 May 2007
Meeting number: 69, T-minus 23 weeks
<scribe> Scribe: Norm
<scribe> ScribeNick: Norm
<MoZ> Norm, is this better ?
Yes
-> http://www.w3.org/XML/XProc/2007/05/24-agenda.html
Accepted.
-> http://www.w3.org/XML/XProc/2007/05/17-minutes.html
Accepted.
Norm, Henry give regrets
Alex to chair
Henry completed his action on p:wrap
Alex completed his actions wrt to steps in the latest draft
Norm: Henry and I discussed it this morning
Henry: In response to your mail,
Norm where you asked how to feed a parameter to only one XSLT
step.
... Wouldn't you have to change the pipeline?
Norm: Yes
Some discussion of how to make it work for arbitrary parameters
Richard: I think you could do it from the command line, but it might be messy
Norm attempts to summarize the differences between Henry's proposal and the alternate draft.
Henry: The reason I made another
proposal is that there appears to be a lot more mechanism and
new rules than appeared to be necessary in the 90% use case of
the new mechanism.
... If we wanted grouped parameters to send to separate steps,
then let's do just that.
Alex: One of the things you can do with Norm's proposal is avoid shadowing so, for examples, you can avoid having *all* parameters go to http-request as headers
Norm: Right.
Henry: That's true, there's no
way to do that.
... There are two levels: first, that it would be reasonable to
spec http-request to say that it could read parameters as
headers by explicitly naming them.
... But we still use QNames, right?
... That's what namespaces are for. If you need to avoid name
collisions.
Alex: We could augment Henry's proposal with some sort of exclude parameter.
Some discussion of how bindings would also work with namespaces and multiple steps of the same type
Henry: If, after suitable experience, we feel that we need some way of throwing away inherited parameters, we could add that.
Alex: I think if you want to
write a rock-solid pipeline, you're going to wind up trying to
deal with parameters by moving them all up to top-level
optoins
... I'm worried that our current flexibility might allow
user-specified parameters to cause XProc to go off the
rails.
Henry: I'm somewhat sympathetic.
The fact that we have as yet not said anything about parameters
on the command line means we should give it careful
thought.
... Even if it's implementation defined if they can be set on
the command line.
... With respect to options, the situation seems a bit more
clear. But for parameters it seems less clear.
... We're working on parameters against a background of
assumptions that I think it was right for Alex to point
out.
Norm: I don't think we can try to
reach closure on this today, given how recently new proposals
have surfaced.
... But I also don't think we can push out a new draft until we
have resolved it, so that'll just have to wait a week or
two.
... Anything else on parameters this week?
Nope; let's take it back to email.
Norm attempts to summarize the current state of play, conceding that he's been convinced by Jeni
Henry: I convinced myself that it
has to be a function, but I don't think it's the XPath
position() function.
... It has to be a function because in the case where you have
a step that accepts a sequence, the pipeline processor is only
going to invoke the step once.
... It follows that there can't be a variable that has the
binding because there's only one invocation so there's only one
option to pass in the binding.
... Inside a step, the way an expression can tell you your
position must be a function.
<Zakim> MoZ, you wanted to add some argument *againt* position()
Mohamed: The use of position() requires that we define a context and I don't want to have to define a context.
Norm: I don't think that makes sense, the XPath 1.0 spec says the context exists and has five things in it.
<alexmilowski> function vs variable really doesn't matter for establishing the XPath context... you'll still have to be clever if you want a clean API for your step implementors.... but I'm not going to argue against functions.
Henry: All we can do when mandating what components do when they evaluate XPaths is tell them what we make available in the context.
Richard: I'm now confused about
how this whole thing is supposed to work. Henry is assuming
that the step gets to go off and evaluate XPaths. I wasn't
aware that that was how it was supposed to work.
... There's no way my steps can evaluate anything in the
context of XProc.
Henry: There are certain options
to certain of our steps who's static value is an XPath
expression.
... these are expressions that the step must evaluate.
Richard: I was expecting the
delete step to get run once for each of the matches
... Why does it matter if its a variable or a function?
... If you have a step that has a bunch of documents coming
into it then in order to know inside the step what the position
is implies that the implementation must be exactly synchronized
with the input to the pipeline
... I agree that we're getting on dangerous ground, but I think
we have to.
Some discussion of p:matching-documents
Richard: The case were it seems to be difficult is where you expect independent step writers to be able to determine which position in the sequence a document is.
<Zakim> Norm, you wanted to point out how p:position() doesn't work any better than position()
Norm: The p:position() function is essentially the same as the context position.
<ht> Norm: For a step like matching-documents -- for the first doc. in the sequence the context will be a context node: the document; a context position: 1; a set of variable bindings, function bindings, etc.
<ht> ... for the next doc, change the first two to 'second document' and '2'
<ht> ... I missed 'context size' -- it's 1, 2, 3, . . .
<ht> MZ: that approach to context size is why I don't like this proposal
<ht> ... It means 'last()' is wrong
<ht> NW: But you have to give _something_ , so it will be wrong one way or another
<ht> ... the only alternative is to say you can't stream
<ht> AM: You can't have a set of documents in XPath 1.0
<ht> NW, RT: Yes you can -- a node set of document nodes, e.g. <xsl:for-each select="document(a)|document(b)">....
<alexmilowski> Err... I didn't say you can't have a set of documents in XPath 1.0
Henry: we're going to say that
conformant step implementations of steps which take document
sequences as input must use this context.
... We're not saying that they're evaluating against a
set.
... When a step implementation of a step which takes sequence
input evaluates an XPath against a context node which is one of
the nodes in that sequence, then the rest of the context must
look like this.
<ht> ... where 'this' is what Norm said above
Richard: Am I right in thinking that although you have this context you can't get out to other documents.
<richard> context size should be NaN
<alexmilowski> "Uncle!" +1 for context position and the postion() funciton.
Henry: Given the choice between saying you can't stream or saying last() will be wrong, I much prefer the latter
Alex: Is there anything bad that can happen by using position()?
Norm: I don't think so.
Alex: I'm fine with it then.
Mohamed: I still think that
defining the context is a bad idea. Too many things will go
against what people will find obvious.
... Node-set is very different from sequence.
<alexmilowski> straw poll ?
Mohamed: I think it's bad
information to give to users to say that we use position() and
the last() will be wrong.
... Ok, I think I'm beginning to understand.
Richard: What did we agree to for determining if you're the last document?
Norm: We didn't.
Richard: So we could set the context size to the largest possible integer.
<ht> ... or 1+plus the context position()
<richard> or +inf - who can tell whether it's an integer?
<ht> Straw poll: Can live with using context position: RT, AM, AV, HT
I can live with it.
<ht> RL, NW can live with
<ht> PG and Andrew pass
<ht> MZ against
<ht> RT: The point is to ensure that position() never equals last()
None
Adjourned
This is scribe.perl Revision: 1.128 of Date: 2007/02/23 21:38:13 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/mine/the alternate draft/ Succeeded: s/Henry/Richard/ Succeeded: s/htis/this/ Found Scribe: Norm Inferring ScribeNick: Norm Found ScribeNick: Norm Default Present: Norm, [IPcaller], Ht, avernet, PGrosso, MoZ, richard, rlopes, Alex_Milowski, Andrew Present: Norm Alessandro Henry Paul Mohamed Richard Rui Alex Andrew Agenda: http://www.w3.org/XML/XProc/2007/05/24-agenda.html Found Date: 24 May 2007 Guessing minutes URL: http://www.w3.org/2007/05/24-xproc-minutes.html People with action items:[End of scribe.perl diagnostic output]