XProc Meeting Minutes 24 May 2007

See http://www.w3.org/XML/XProc/2007/05/24-minutes

W3C[1]

                                   - DRAFT -

                            XML Processing Model WG

24 May 2007

   Agenda[2]

   See also: IRC log[3]

Attendees

   Present
           Norm, Alessandro, Henry, Paul, Mohamed, Richard, Rui, Alex, Andrew

   Regrets
           None

   Chair
           Norm

   Scribe
           Norm

Contents

     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 31 May 2007
         4. Open action items
         5. Parameter proposals
         6. p:position() vs position()
         7. Any other business
     * Summary of Action Items

     ----------------------------------------------------------------------

  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/05/24-agenda.html

   Accepted.

  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/05/17-minutes.html

   Accepted.

  Next meeting: telcon 31 May 2007

   Norm, Henry give regrets

   Alex to chair

  Open action items

   Henry completed his action on p:wrap

   Alex completed his actions wrt to steps in the latest draft

  Parameter proposals

   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.

  p:position() vs position()

   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.

   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.

   ... for the next doc, change the first two to 'second document' and '2'

   ... I missed 'context size' -- it's 1, 2, 3, . . .

   Mohamed: that approach to context size is why I don't like this proposal

   ... It means 'last()' is wrong

   Norm: But you have to give _something_ , so it will be wrong one way or
   another

   ... the only alternative is to say you can't stream

   Alex: You can't have a set of documents in XPath 1.0

   Norm, Richard: Yes you can -- a node set of document nodes, e.g.
   <xsl:for-each select="document(a)|document(b)">....

   Alex 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?

   Henry: Straw poll: Can live with using context position: Richard, Alex,
   Alessandro, Henry

   <ht> Rui, Norm can live with

   <ht> Paul and Andrew pass

   <ht> Mohamed against

   Richard: The point is to ensure that position() never equals last()

   Back to email, I guess.

  Any other business

   None

   Adjourned

Summary of Action Items

   [End of minutes]

     ----------------------------------------------------------------------

   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/05/24-agenda.html
   [3] http://www.w3.org/2007/05/24-xproc-irc
   [6] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [7] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[6] version 1.128 (CVS
    log[7])
    $Date: 2007/05/24 16:47:03 $