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

XProc Minutes 13 Dec 2007

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 13 Dec 2007 12:01:40 -0500
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2ve72lea3.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/12/13-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 94, 13 Dec 2007


   See also: IRC log[3]


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





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 20 December 2007
         4. Last call comments
         5. Comment #81, a proposal to restructure our top-level syntax
         6. Comment 79: sequence-consistency of choose/try branches
         7. Comment 80, properties of an implicit output port
         8. Comment 83, viewport
         9. Comment 74, minor p:http-request issues
        10. Comment 76, p:import dynamic errors: should be static
        11. Any other business?
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/12/13-agenda


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/11/29-minutes


  Next meeting: telcon 20 December 2007

   No regrets given.

  Last call comments

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

  Comment #81, a proposal to restructure our top-level syntax

   Henry: I think the motivation is the crucial thing.
   ... It felt like we still hadn't found the sweet-spot in the relationship
   between pipelines, steps, and pipeline-libraries
   ... The crucial observation was that it suddenly made sense to allow
   declare-step to contain a subpipeline
   ... That's precisely what we're doing when we put <px:somename> in a
   pipeline as a call to the pipeline with the type px:somename
   ... It made sense to use *declare-step* to do that.
   ... When I worked that all through, it seemed to me to have a number of
   positive consequences.
   ... The single residual notion as the sort-of entry level way of wrapping
   a subpipeline to run it, it didn't have to have a name.
   ... Giving it a name is only necessary if you want to be able to refer to
   its ports.
   ... There are two seperable parts: 1. Put a subpipeline in declare-step
   and 2. let's make reference to the enclosing top-level artifact easy by
   defaulting on p:pipe.
   ... I think that works very neatly, but its seperable from the other

   Norm: My big concern was the fact the you couldn't import two simple
   pipelines anymore, because there'd be a name clash.

   Henry: We could (1) add an optional name to p:pipeline, but that still
   doesn't help if you don't own the pipeline.
   ... Or (2) alow a type attribute on p:import that is the type of a naked
   imported pipeline.
   ... or an error if the imported library doesn't include it.

   Norm: If we went with type, I think I'd want it to be an error if you
   don't import a naked pipeline.

   Henry: Or you can workaround it with a really tedious set of nested

   Some discussion

   Norm: The other concern I have is much harder to quantify: are we making
   the language more like a static compile/run language and less dynamic and
   is it going to piss off our audience.

   Richard: there isn't a pipeline and a declare-step for the pipeline, it's
   one or the other.

   Henry observes that the type/p:import trick would bungle an attempt to
   import a recursive pipeline.

   Alex: I don't see why requiring the p:declare-step in the recursive case
   is such a big deal.

   Norm: I'm not *sure* it is, it just changes the way the language feels.

   Richard: I thought we were going to get rid of p:pipeline altogether, just
   putting them all in p:declare-steps.
   ... Then we put pipeline back in as an abbreviation for a common case of a
   declare-stpe with a subpipeline in it.
   ... We can then fiddle with what the abbreviation means to make the common
   cases we care about easy.
   ... If you do it in those two stages, it seems more plausible to me.

   Norm: There's no point in repeating myself: there's a sense in which this
   makes the language feel more like java and less like a scrypting language
   and that worries me.

   Henry: A question of how much a discontinuity arises when you want to
   write a recursive pipeline is an open question.

   Alex: What if a pipeline is allowed to have a type declared. And you have
   to do that to use recursion.

   Richard: If we made pipeline just be an abbreviation in that way, the only
   thing we've really changed is that you write pipelines with p:declare-step
   when you put them in libraries.

   Henry: I get confused about what the state of play is wrt what attributes
   are allowed on p:pipeline at the moment.

   Alex: It also fixes the defaulting problem for inputs and outputs of

   Henry: The other consequence is that we could get rid of the situation
   where p:pipeline has both an optional name and an optional type.
   ... Our users are never going to be anything other than confused by that.

   Norm: The way that was rectified was by allowing p:pipe to have no step
   and that means the enclosing pipeline.

   Some discussion of the proposal that Norm had made earlier

   Alex: I'd have to think about the defaulting story a bit more.

   Richard: The thing that Henry's proposing isn't really defaulting, it's
   like giving the name of the pipeline the name "" and just letting you not
   say that.

   Alessandro: I think it would help if someone could consolidate the
   proposal and post it with some examples. My reluctance now is coming more
   from lack of understanding that something being wrong with it.

   Henry: I'll do that over the next 24 hours.

  Comment 79: sequence-consistency of choose/try branches

   Norm: I think so.

   Richard: The reason why it came up was that one branch had an XSLT and the
   other had Identity, so that doesn't work.

   Norm: Yes, I see how that might be tedious.

   Richard: Because you're allowed to hook sequences to non-sequences, it
   doesn't really matter to the implementor.
   ... We could say that if any branch produces a sequence, then the p:choose

   Norm: I can live with that.

   Proposal: We accept Richard's suggestion above, an output of a choose or
   try is a sequence if any of the branches produces a sequence on that port.


  Comment 80, properties of an implicit output port

   Richard: I think Norm's right, it inherits the properties of the output on
   the last step.


   Richard: The only effect that declaring something sequence=false has is
   that it prevents a sequence from slipping through.

  Comment 83, viewport

   Richard: We really did mean that the pipeline can inside the viewport can
   only have one output.

   Norm: Yes, we meant that.

   This is a significant editorial issue, but not a technical one.

   The subpipeline must have one output and the result can be a sequence.

   Richard: I think there may be similar editorial problems with p:for-each

  Comment 74, minor p:http-request issues

   The version was absent by mistake and yes, the XML decl should be present

  Comment 76, p:import dynamic errors: should be static

   Norm: Yes, they should be static.


  Any other business?


Summary of Action Items

   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/12/13-agenda
   [3] http://www.w3.org/2007/12/13-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/12/13 17:00:48 $

Received on Thursday, 13 December 2007 17:01:53 UTC

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