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

XProc Minutes 7 June 2007

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 07 Jun 2007 12:11:55 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <878xavwxpw.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/06/07-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 70, 7 Jun 2007


   See also: IRC log[3]


           Norm, Alessandro, Alex, Richard, Henry, Andrew, Mohamed

           Paul, Michael, Rui




     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 14 June 2007
         4. Using context position to count iterations through a loop
         5. Parameters
         6. What's the default for steps that don't specify any parameter
         7. Cardinality of inputs
         8. p:head/p:tail and secondary outputs
         9. Any other business?
     * Summary of Action Items


  Accept this agenda?

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


  Accept minutes from the previous meeting?

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


  Next meeting: telcon 14 June 2007

   Norm will be calling from JFK, Henry to chair in his absence

  Using context position to count iterations through a loop

   Henry summarizes his mail


   Henry's message clearly raises a substantial issue; defer to email again.

   Richard reminds us why position() doesn't work for most of the cases of

   Richard: Consider the second step of the subpipeline inside a for-each;
   the position() in that step refers to the output from the first step, not
   the for-each


   Norm: Is anybody unhappy with the revised proposal that I sent for the
   next draft?

   Henry: I can go either way, but I have to say I like the nested approach
   better than the attributes case.

   Henry meant the p:use-parameter-set element instead of the attribute.

   Henry: That removes the need for an inherits attribute.

   Norm: Anyone feel strongly the other way?
   ... I'm happy to implement it that way instead.

   Norm asks the question again.

   Henry: It's not clear how this effects the vanilla case.

   Some discussion of elements vs attributes (@use-parameter-set vs

   Mohamed: I think it's totally equal to have elements or attributes.
   ... But I prefer to have elements.

   Alex: I prefer the attribute syntax, but I'm not going to stand in the way
   of progress.

   The proposal is accepted

  What's the default for steps that don't specify any parameter sets?

   Norm: I think its either none or the parameters from the pipeline

   Mohamed: Are we talking about parameters and options or just parameters?

   Norm: Just parameters.

   Straw poll: 2 for none, 2 for pipeline, 2 concur, and 1 abstain

   Norm: The editor will do something and mark the issue unresolved.

  Cardinality of inputs

   Norm attempts to explain the 0 or 1 case

   Some discussion of using p:count and choose to deal with the optional
   input anyway

   Henry: It feels like creeping featurism, but I want the 90% case to still
   not require any more work.
   ... I'm not happy if I have to specify two attributes to get 0 or more.

   Norm: Anyone opposed to this change?

   Henry: I don't prefer to make it, but I could live with it.
   ... Any advocates on the call?


   Let's leave it for a week and do a straight vote next week.

  p:head/p:tail and secondary outputs

   Henry: I'm opposed to secondary outputs by simply grabbing the input a
   second time and inverting the test.

   Norm: I'm sort of in the same camp, I fear the overhead of dealing with
   ignored secondary outputs.

   Henry: We've got a natural tension between some folks who think if a small
   number of components will do it, we're done, and others who think that if
   there are common assemblies, we should make components for them.

   Mohamed: When I proposed p:head/p:tail, I thought it would be like lisp
   where you could get both.
   ... Head and tail have the semantics of capturing both to me
   ... Since we can't make a recursive call, I think it would sometimes be a
   lot simpler to have two different answers.

   Henry: I think there's some value to that position. If the proposal is to
   replace p:head and p:tail with p:split-sequence, that's more attractive.

   The observation that split-sequence is matching-documents is made

   Richard: This starts to sound like a for-each with a choose in it.

   Henry: Split-sequence without a secondary output is just the same as
   matching documents.

   Richard: If it's equivalent to that, we should have a separate step, but
   maybe it should be made more general.
   ... A step that takes a sequence input and produces a set of sequence
   outputs with a set of tests to determine which documents go to which

   Henry: We don't have anything at the moment with arbitrary number of

   Some discussion...

   Henry: It would be like p:choose with branches that have guards.
   ... I think the 80/20 point is achieved by Mohamed's proposal.

   Alex: I just want to point out that head and tail have to do with
   ... There are a number of options that could be used to specify a range.

   <ht> head and tail really are just sub-cases of matching-documents

   Alex: One proposal would be to combine head and tail into one sort of
   "subrange" component.

   <ht> position()>5 and position()<10

   Alex: But you can't do what tail does.

   Norm: I agree

   Henry: You can if we take the hard decision about last()

   Richard: I think we're doing this in the wrong order.
   ... Whether we want these special steps on position depends on whether the
   general steps will do what we want.

   Henry: My current position is that, keeping Paul's advice firmly in mind,
   no p:head, no p:tail, no p:matching-documents, only p:split-sequence with
   two outputs.
   ... And allow last() to really be the real context size.

   Mohamed: Now if we have last(), we don't need to have p:count

   Some discussion of whether or not this is true; consensus that it isn't.

   We still need p:count.

   Henry: This gets us back to the the discussion at the beginning, what's
   the XPath context in the runtime.

   Norm: I don't think we'll get final consensus on this until we've settled
   position() so I'll let this hang for another week as well.

  Any other business?


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/06/07-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
    $Date: 2007/06/07 16:10:52 $

Received on Thursday, 7 June 2007 16:12:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:43 UTC