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

XProc Minutes 21 June 2007

From: Norman Walsh <ndw@nwalsh.com>
Date: Fri, 22 Jun 2007 10:56:43 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <871wg4ox5g.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2007/06/21-minutes


                                   - DRAFT -

                            XML Processing Model WG

Meeting 72, 21 Jun 2007


   See also: IRC log[3]


           Norm, Paul, Andrew, Henry, Alessandro, Richard

           Rui, Michael, Alex




     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 28 June 2007
         4. Review comments on 20 June 2007 editor's draft?
         5. Renaming p:doc, p:document, and p:journal
         6. Base URIs
         7. Pipeline defaults
         8. What's between here and Last Call?
         9. Any other business
     * Summary of Action Items


  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2007/06/21-agenda


  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2007/06/14-minutes


  Next meeting: telcon 28 June 2007

   No regrets given for 28 June

  Review comments on 20 June 2007 editor's draft?

   -> http://www.w3.org/XML/XProc/docs/langspec.html

   Henry commented on some content models and on App D being broken.

   Norm reports that those things are fixed.

   Mohamed made some comments in email; Norm will address these.

  Renaming p:doc, p:document, and p:journal

   Norm describes the background following Jeni's mail

   Henry: I'm happy to change p:journal to p:log
   ... And I agree we should change p:doc to p:documentation.
   ... I don't feel strongly about p:document, I'm happy to leave it.
   ... I don't think there's any real stress between document and

   Norm: I dislike the alternatives that have been proposed and I don't find
   document/documentation confusing.
   ... Anyone want to pursue p:document renaming?

   No one speaks up.

   Proposed: Rename p:doc to p:documentation and p:journal to p:log. Leave
   p:document unchanged.

   Any objections?


  Base URIs

   Norm outlines his concerns.

   But not very well articulated.

   We should probably say what happens to the base URI as a document passes
   through each step.

   Norm: I guess the clearest thing I can say is that we have no way of
   accessing the base URI from XPath.
   ... So you can't make a p:choose that branches on the base URI, you can't
   pass it as an option or parameter.

   Let's move this to email.

  Pipeline defaults

   Norm points out that parameter defaults are a little tricky.

   Henry: On the question of pipeline parameters, I sort of convinced myself
   that it was going to come out ok.
   ... That is, the fact that we can put parameter port declarations on
   p:pipeline means that you can connect to them.
   ... There is some way, maybe the only way, of declaring an input port in
   p:pipeline as a parameter port. Reading from this gets you whatever was
   passed in from the outside.

   Norm: The question is, if you don't have a parameter input port on a
   p:pipeline, what happens to parameters?

   Henry: I want a pipeline with one input and one output not to have to have
   any declarations.

   Norm: That's not on the table!

   Henry: Yes it is. I wrote email about it...I can find that mail

   Norm: So if a pipeline has no inputs and no outputs, you want it to have a
   default input of source and a default output of result?

   Henry: I don't care about the name, I just want the default input port to
   be available.

   <ht> My goal all along has been to make it so that
   <p:pipeline><p:identity/></p:pipeline> works

   Alessandro: With a system like this, how do we declare that a pipeline has
   no inputs or outputs?

   Henry proposes p:empty, but we agree quickly that this doesn't work.

   Henry/Richard recall that we had previously discussed making nothing mean
   one input

   Henry: No inputs or outputs is a small percentage case, so maybe we can
   have attributes on p:pipeline that identify the number of inputs and

   Norm: Yes, that would work. It's not pretty to me...

   Norm agrees that it's syntactically simpler but worries that it's
   conceptually confusing.

   Henry: Maybe we push it too far, but think of the stdin/stdout analogy:
   you don't have to declare those.

   <ht> The input to the first step is, other things being equal, the in put
   to the pipeline

   Norm: I could live with it, but it's not immediately comfortable.

   Alessandro: In my mind, pipelines are more similar to the way you would
   use functions in other programming languages. In those languages, default
   declarations are uncommon.
   ... And in my experience, having 1 input and 1 output is not the
   overwhelmingly common case.
   ... Having that be the default doesn't resonate with me.

   <Zakim> ht, you wanted to note the exception to Perl

   Henry: I wanted to observe that Alessandro is right in general, but Perl
   is a counter example.
   ... In Perl the default input and default output are always there by
   default, $_

   <ht> That is $_

   Henry: I can live without this, but it seems the logical conclusion of the
   rest of our defaulting story.

   Richard: One can imagine the input case working as a kind of error
   recovery. If a pipeline with no inputs finds its first step relies on the
   default input, it could infer one. But that doesn't work for outputs.

   <scribe> ACTION: Henry to get this discussion started in email [recorded
   in http://www.w3.org/2007/06/21-xproc-minutes.html#action01[7]]

  What's between here and Last Call?

   Norm: I want everyone to think about what stands between us and last call.

   Henry: Is the error story complete?

   Norm: I think it's complete, but I wouldn't swear to it.

   Henry: Can we say nothing about implementations and APIs?

   Norm: Good point.

   Henry: The fact that every implementor will have to answer certain
   questions doesn't obligate us to answer them.

   Norm: I'm not sure I follow.

   Henry: There's been an assumption that whatever the API is, it's going to
   get at most one document at a time. But it's also got to know when it's
   gotten the last one.

   Norm: I don't think we could answer that in any sort o fimplementation
   independent matter.

   Henry: Do we need or want to make the point that implementations have to
   buffer whole sequences at places.

   Norm: Not normatively, in my mind, but informally I think we should
   mention it.

   Try/Catch, some uses of last(), and possibly p:count

  Any other business

   Mohamed: What about the step vocabulary, will that be updated for the next
   ... Some name changes.

   Norm: Let's check with Alex and see what the status is/.


Summary of Action Items

   [NEW] ACTION: Henry to get this discussion started in email [recorded in
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2007/06/21-agenda.html
   [3] http://www.w3.org/2007/06/21-xproc-irc
   [7] http://www.w3.org/2007/06/21-xproc-minutes.html#action01
   [8] http://www.w3.org/2007/06/21-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: 2007/06/22 14:49:17 $

Received on Friday, 22 June 2007 14:56:48 UTC

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