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

XProc Minutes 3 January 2008

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 03 Jan 2008 12:07:35 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2k5mqu9bc.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2008/01/03-minutes


                                   - DRAFT -

                            XML Processing Model WG

3 Jan 2008


   See also: IRC log[3]


           Norm, Michael, Henry, Richard, Alex, Mohamed, Rui, Andrew

           Alessandro, Paul, Murray




     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 10 January 2008?
         4. Last call comments
         5. 81. A proposal to restructure our top-level syntax
         6. 89. Questions and comments
         7. Future plans
         8. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2008/01/03-agenda


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/12/20-minutes


  Next meeting: telcon 10 January 2008?

   No regrets given.

  Last call comments

   -> http://www.w3.org/XML/XProc/2007/09/lastcall/comments.html

  81. A proposal to restructure our top-level syntax

   Norm wonders if Alex has any thoughts.

   Alex: I generally like it.

   Alex wonders if there are any controversial parts in the minds of others


   Norm: Is there anyone on the call that thinks we shouldn't do this?

   Michael: The fundamental idea seems good. Some of the special cases for
   defaulting are problematic.

   Alex: When you have a p:pipeline, any inputs and outputs are additive, is
   that right?

   Richard: Yes, as I framed it, p:pipeline is just syntactic sugar for a
   declaration with a p:input and a p:output.
   ... The advantage it gives is that there's a fully explicit syntax for
   ... If you want an abbreviated syntax, then p:pipeline is it, and the
   abbreviation seems to me to be very straightforward.

   Alex: Can you point to a p:pipeline to import it.

   Richard: I don't see why not.

   In fact, you can point to all three, a p:pipeline, a p:declare-step, or a

   Some discussion of the fact that this means you can point to a
   declare-step implemented by other means as well.

   Let's consider the options in Richard's proposal:

   1. How to refer to pipeline input ports within a subpipeline.

   Norm: I have a preference for using the local name of the type.

   Richard: That has an impact on option 3, since it will make some inputs
   totally unavaiable.

   Alex: Why not make the type required.

   Henry: You could do that, you could take 1 and 3 as a package solution.

   Henry expresses a preference for requiring the type if we don't go with
   the absent step attribute shortcut.

   Henry: The advantage of requiring all pipelines to be typed is that it
   means you can always import them.

   Richard: And conversely, having untyped pipelines allows authors to
   prevent them from being reused without copying.

   Mohamed: I prefer to use the local name as well. Omitting the name is just
   too complicated to understand.

   So, for option 1, we'll use the local name of the step type.

   2. Should the defaulted input and output on p:pipeline have referenceable

   Richard: I think that if they don't have referencable names, how can you
   call the pipeline? That's compelling to me.

   Norm: I feel a little odd because we've made the other choice elsewhere.

   Richard: Yes, but no where else is it exposed externally.

   Anyone disagree?

   Mohamed points out that you could still call them, as long as the call
   used the primary input port.

   Richard: I think the point of the simplification is that it simplifies
   things for the author, it shouldn't constrain the user.

   Ok, for 2, we'll use the names "source" and "result"

   3. The type attribute is optional on p:pipeline.

   Norm: I think at the moment I favor making it optional, the point of the
   default syntax is to make things simple and requiring a type you never use
   doesn't seem simple.

   Henry: I think we should try that and see if we get pushback.

   So, for 3, we leave it optional.

   Norm summarizes the consequences of the choices.

   Richard: I left the 'primary' off of my equivalence summary in email.

   Mohamed: I'm wondering about the mandatory nature of input and output in
   the p:pipeline case.

   Norm: I think pipelines that have no input or no output are going to be
   much less common.

   <richard> It's not "do something extra if you want to reuse", it's "don't
   use this abbrevation if you want to reuse"

   <scribe> ACTION: Norm to craft an editor's draft implementing these
   decisions [recorded in

  89. Questions and comments

   Norm: On closer inspection, I decided that these were editorial or

  Future plans

   Norm: Seems like we're done.

   Henry: Time for a last call.

   Richard: Do we want to introduce this renaming in a last call.

   Norm muses about that.

   Norm: I guess it's time to get an editor's draft out that includes all of
   the decisions we've made.
   ... Anyone know of anything else that's outstanding?

   Mohamed: At some point we talked about splitting the spec.

   Richard: Having the step library separate, you mean?

   Mohamed: yes.

   Norm: I'll put that on the agenda for next week.

  Any other business?



Summary of Action Items

   [NEW] ACTION: Norm to craft an editor's draft implementing these decisions
   [recorded in http://www.w3.org/2008/01/03-xproc-minutes.html#action01[8]]
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2008/01/03-agenda
   [3] http://www.w3.org/2008/01/03-xproc-irc
   [7] http://www.w3.org/2008/01/03-xproc-minutes.html#action01
   [8] http://www.w3.org/2008/01/03-xproc-minutes.html#action01
   [9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [10] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[9] version 1.128 (CVS
    $Date: 2008/01/03 16:58:54 $

Received on Thursday, 3 January 2008 17:04:01 UTC

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