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

XProc Minutes 29 June 2006

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Tue, 18 Jul 2006 12:40:58 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87lkqqx3vp.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/06/29-minutes.html


                                   - DRAFT -

                            XML Processing Model WG

Meeting 27, 29 Jun 2006


   See also: IRC log[3]


           Norm, Rui, Paul, Alessandro, Henry, Richard, Andrew, Alex,

           Michael, Murray




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


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2006/06/29-agenda.html


  Accept minutes from the previous teleconference?

   -> http://www.w3.org/2006/06/22-xproc-minutes.html

   Norm thanks Henry for chairing


  Next meeting

   6 July telcon or 13 July?

   <scribe> Cancelled: 6 July

   Next meeting is 13 July

   Any regrets? Richard

  Face-to-face: 2-4 Aug 2006.

   Henry gives regrets for 13 and 20 July

   Get your plans to Murray!

  Review of open action items

   A-13-01: Continues

   A-23-02: Continues

   A-23-03: Continues

  XProc syntax

   Norm wonders if we were moving towards consensus at the last meeting.

   Norm: In particular, about the conditional proposal Richard made

   Richard: We didn't really come to agreement, but it wasn't rejected out of

   Alex: should we start with my and Murray's alternatives?
   ... Mine was just to compare the two approaches

   Norm: What about the otherwise?

   Alex: If it's a pipe, then if the when doesn't fire, I'd expect it to just
   do identity.

   Richard: But if the conditional had multiple inputs or outputs, it's not
   clear what the identity is.

   Norm: Couldn't we just make it an error not to include the otherwise

   Richard: In the simple case, there might be lots of cases where people
   would prefer not to write it.

   Alex: My example does need an otherwise.

   Henry: I can't see that the difference is doing any work.


   Alex: The concept of a primary input and output was rejected in general. I
   think the pipe brings it back.

   Richard: We've meant different things at different times about primary
   inputs and outputs.
   ... Sometimes it has an effect on the control, but in the examples I've
   been posting, I've been assuming there'd be an idea of a primary input and
   output purely for abbreviation purposes.
   ... I certainly haven't meant primary input and output to have any other

   Henry: Other things being equal, I'd prefer a syntax that makes heavy use
   of defaulting to get to the 80/20 point, rather than saying that you have
   to make a discontinuous change in the markup to move beyond that.
   ... If there are things you can't do, that's a problem, but I don't see
   that in the cases we've looked at so far.
   ... The other difference between the two examples is that Alex's includes
   a choose with a contained pipe and that appears to be doing no work. I'd
   like it to the be case that we don't need it.

   Alex: that's only because it's a single step.

   Henry: What's wrong with saying that the content model of p:when is

   Alex: I'm not convinced there's a simple story of defaulting that gets to
   a simple straight-through pipe.
   ... XSLT can be conceptualized as a resource with an input and an output.
   There's a story that you can tell for things that are straight thorugh

   Richard: There's something about an XSLT component that says that it's
   source parameter is the one that can be an input when it's placed in a
   ... In your example, the source is something that comes from a pipe?

   Alex: No, I think this makes the story for components more complicated,
   but for users less.

   Henry: Components need declarations and those declarations tell you what
   the primary inputs and outputs are

   Richard: Given that you need to do that for the components anyway, why do
   you need the pipe/flow

   Alex: Because an aggregation component might not have a primary input and
   ... I think it'll be much more confusing if there's a whole hidden layer
   you have to understand to move beyond simple pipes.

   Richard: If you've got a sequence of unix commands that are piped
   together, then you can use a bunch of "|" symbols. If you have multiple
   inputs and outputs then you have to put redirects to files in. But you
   don't need to wrap the sequence of commands in anything special to
   distinguish these two cases.

   Alex: Yes, but the ones that go beyond simple chains are too complicated
   for most people to understand.
   ... There's a slippery slope where you have to chase these named
   references back and forth.
   ... If there's a simple syntax for the simple case and a different syntax
   for the more complicated cases, then you know when you're jumping to the
   next level of complexity.

   Norm: I'm going to agree with Henry here. We want to make incremental
   improvement simple.

   <ht> HST thinks the XSLT example cuts the wrong way for AM's argument --
   no-one uses the 'simple' stylesheet-is-template mechanism, precisely
   because evolving it is discontinuous

   Norm: We seem to be struggling with this the idea of getting the defaults
   right. I'd like to get the verbose syntax right first.

   Alex: I think we should consider defaults along the way.

   <Alessandro> Norm, I agree with this approach

   <rlopes> +1 for Norm's approach

   Alex: Maybe one way out is to divide and conquer our use cases. Assign
   some number of them to individuals with proposals for how you'd write it
   ... 20 to 30 of the use cases are straight through pipes
   ... We need to make some progress on those use cases. So let's do that.

   Richard: I agree with Alex that it would be a good idea to write out some
   of the use cases in a proposed syntax.

   Alex: There was the issue of naming inputs and outputs

   Richard: In the examples I've done so far, I don't think it makes much
   ... I don't think we need to worry about this too much now, but maybe
   doing this will turn up a case where it does matter.

   <scribe> ACTION: Alex to write up some straw syntaxes for some of the use
   cases. [recorded in

   <scribe> ACTION: Norm to write up some straw syntaxes for some of the use
   cases. [recorded in

   <Zakim> ht, you wanted to accept NW's suggestion

   Henry: This is past it's window, but for the record, I'm happy with Norm's
   desire to focus on a fully articulated syntax in the first instance. I'll
   privately try to find forms of the fully articulated syntax that will
   admit to graceful defaulting.
   ... I don't object to the overall strategy you suggested.

   Norm: I think working on syntax proposals and examples for use cases might
   help us move forward.

   Alex: Do we want to go through the dot proposal stuff again? And Murray's
   using QNames for step names.

   Norm: I think that the naming conventions (either the step/input-output
   name or the explicitly named input or output) and the use of step
   type="xslt" or p:xslt for hte step name are largely irrelevant.
   ... They have little impact on the technical solutions, only on the
   surface syntax.

   Alex: Use of a QName for a step name allows us to have a directed syntax.
   Being able to specify shorthand just like extension elements in XSLT is a
   good thing.

   Richard: You're thinking of some sort of macro-like facility?

   Alex: Yes. Becuase that's what I do in smallx.
   ... There's a big usability win, but it does obfuscate inputs and outputs
   if you're just looking at a step.
   ... But since we need the component definition anyway, maybe that's ok.

   Richard: I agree that some sort of facility like that would be nice, but I
   need to understand everything else better.
   ... So to remind us where we are: we've talked a lot about
   straight-through pipes and we've talked about the conditinal construct
   without any conclusion. The other control construct we've thought of is
   the iteration or viewport construct.
   ... We haven't really addressed that at all yet, but we should make sure
   we consider it.
   ... It would be a good thing for someone to come up for a concrete syntax.

   Alex: There's iteration over elements and over documents.

   Norm: Right. I don't know if they can be unified but I hope so.
   ... Does it make sense to end early and come back in two weeks with our
   examples in hand?

  Any other business?



Summary of Action Items

   [NEW] ACTION: Alex to write up some straw syntaxes for some of the use
   cases. [recorded in
   [NEW] ACTION: Norm to write up some straw syntaxes for some of the use
   cases. [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2006/06/29-agenda.html
   [3] http://www.w3.org/2006/06/29-xproc-irc
   [6] http://www.w3.org/2006/06/29-xproc-minutes.html#action01
   [7] http://www.w3.org/2006/06/29-xproc-minutes.html#action02
   [8] http://www.w3.org/2006/06/29-xproc-minutes.html#action01
   [9] http://www.w3.org/2006/06/29-xproc-minutes.html#action02
   [10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [11] http://dev.w3.org/cvsweb/2002/scribe/

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

Received on Tuesday, 18 July 2006 16:41:09 UTC

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