W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > June 2007

XProc Minutes 14 June 2007

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:53 GMT