XProc Minutes 7 June 2007

See http://www.w3.org/XML/XProc/2007/06/07-minutes

W3C[1]

                                   - DRAFT -

                            XML Processing Model WG

Meeting 70, 7 Jun 2007

   Agenda[2]

   See also: IRC log[3]

Attendees

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

   Regrets
           Paul, Michael, Rui

   Chair
           Norm

   Scribe
           Norm

Contents

     * 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
            sets?
         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

   Accepted

  Accept minutes from the previous meeting?

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

   Accepted

  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

   ->
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Jun/0092.html

   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
   for-each

   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

  Parameters

   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
   p:use-parameter-set)

   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?

   Nope

   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
   outputs.

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

   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
   counting.
   ... 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?

   None

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
    log[8])
    $Date: 2007/06/07 16:10:52 $