

XProc Minutes 27 July 2006

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Thu, 27 Jul 2006 12:02:56 -0400
Message-ID: <878xmft4r3.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/07/27-minutes.html


                                   - DRAFT -

                            XML Processing Model WG

Meeting 30, 27 Jul 2006


   See also: IRC log[3]


           Alex, Alessandro, Andrew, Mohamed, Norman, Richard, Rui





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous teleconference?
         3. Next meeting: Face-to-face: 2-4 Aug 2006
         4. Review of open action items
         5. Agenda for the f2f
         6. XProc syntax
         7. Any other business?
     * Summary of Action Items


  Accept this agenda?



  Accept minutes from the previous teleconference?

   -> http://www.w3.org/XML/XProc/2006/07/20-minutes.html



   Make sure your arrangements are in order.

  Review of open action items

   A-23-02: Richard to write a syntax proposal

   <scribe> Withdrawn.

   A-13-01: MSM to draft a complete table; ETA: 20 July 2006

   <scribe> Continued.

  Agenda for the f2f


   1. Finish the syntax wrangling

   2. Define the core language constructs

   3. Make a first pass at identifying a list of required components

   4. Make a list of standard but optional components (if any)

   5. Review our open issues

   Norm will try to draft an agenda this week

  XProc syntax

   Lots of good discussion on the list, any burning issues?

   None suggested.

   Alessandro's proposal:

   <Alessandro> http://avernet.googlepages.com/xproc-syntax[6]

   Alex suggests looking at for-each

   Alessandro: On the for-each it looks like we want to reference a sequence
   of documents that we want to iterate on, we want the option of providing
   an XPath expression.
   ... In the for-each we need to be able name the outputs

   Norm did something alternate:


   Alex: If you're iterating over a document and using an XPath expression,
   you have to specify a replacement
   ... When you're iterating over a sequence of documents, that's not
   necessarily true.
   ... There are way more options when you're iterating over a collection of

   Some discussion of whether we're talking about for-each or peephole

   Norm tries to outline how for-each and peephole differ. For-each just
   returns the sequence of things generated, peephole wraps the original
   document around the replaced matches.

   Richard: I think there should be something that does a body for each
   document in a sequence and something else that does each matched part in a
   single document.

   Norm: We could have for-each and for-each-document, I just didn't think it
   was necessary.

   Richard: The output is a sequence of documents. The peephole mechanism can
   be build out of that, I think.
   ... A component that takes the original and an XPath and a sequence of
   documents, the sequence could be plugged in where the matches occurred.

   Alex: It could be done that way, but I'm not sure I want to do it that

   Norm wonders if there's a practical use for a component that works that

   Richard proposes that there are some uses, whether they're practical or

   Some more discussion of how for-each and peephole are similar.

   Richard: Do they between them cover all the looping functionality we need?

   Alex: Can we add a peephole/viewport element?
   ... I don't much like "peephole".

   Norm: Anyone like peephole better than viewport?

   Murray: I don't like either.


   Norm asks about for-each-output and observes he tried to show how
   declare-output could be used in each case.

   Norm: On the subject of name, I assume we're still sort of evenly divided
   about how we want to do the naming.

   Yeah, pretty much.

   Richard: On for-each, the name attribute is used for the binding. Does
   that make it a variable?

   Alessandro: Yes.

   Norm: Huh?

   Alessandro: No, actually, it's just used when you want to ref= to the

   Murray: I don't understand why we have ref= and href=

   Norm: I think we might be able to combine them.

   Some discussion of the direction things flow

   Alessandro: In my example, the direction is the same

   -> http://avernet.googlepages.com/xproc-syntax-parse-import

   Norm: I see, the name is repeated. This really only works in the case
   where you name individual outputs.
   ... If you were using the compound naming system, then each when would
   have to have a *step* with the same name and that step would have to have
   an output port with the same name, in order to make this work.
   ... So if we go with #name/port it's much harder to always point from the
   output to the input in the conditional case
   ... (Where "much harder" means "impossible", I think)

   Richard: When I was thinking about conditionals, I was going to have each
   of the when's declare their outputs.
   ... Then the choose referred to those names.

   Norm: Yes, that would work as well, but it's pretty verbose to have to
   declare all the outputs on every branch.

   Scribe apologizes for failure to capture several minutes of minutes...

   Murray: Can't the p:when's output bubble up?

   Norm: Not when there's more than one output from the p:choose

   Richard: But when there is only one, we might be able to abbreviate it

   Norm: Yes, and it's the idea of abbreviations in the future that makes me
   have a slight preference for the compound naming choice.

  Any other business?



Summary of Action Items

   [End of minutes]


   [1] http://www.w3.org/
   [3] http://www.w3.org/2006/07/27-xproc-irc
   [6] http://avernet.googlepages.com/xproc-syntax
   [11] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[10] version 1.127 (CVS
    $Date: 2006/07/27 16:01:04 $

Received on Thursday, 27 July 2006 16:03:23 GMT
