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

XProc Minutes 31 Aug 2006

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Thu, 31 Aug 2006 16:14:18 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <87veo8k6hx.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/08/31-minutes.html

W3C[1]

                                   - DRAFT -

                            XML Processing Model WG

Meeting 33, 31 Aug 2006

   Agenda[2]

   See also: IRC log[3]

Attendees

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

   Regrets
           Alessandro, Erik

   Chair
           Norm

   Scribe
           Norm

Contents

     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous meeting?
         3. Next meeting: telcon 7 Sep 2006
         4. Comments on the draft
         5. The select attribute on p:param
     * Summary of Action Items

     ----------------------------------------------------------------------

  Accept this agenda?

   -> http://www.w3.org/XML/XProc/2006/08/31-agenda.html

   Accepted.

  Accept minutes from the previous meeting?

   -> http://www.w3.org/XML/XProc/2006/08/17-agenda.html

   Accepted.

  Next meeting: telcon 7 Sep 2006

   No regrets given.

  Comments on the draft

   Four things: add a description for p:declare-parameter

   scribe: Document select on p:param (we need to determine the context)
   ... Remove the special case in 4.1.1 for a source w/o step
   ... Add text about extension attributes and elements
   ... Do we allow p:declare-input on for-each, choose, etc.

   Henry: We've talked about components and steps as quite different things
   ... in the draft, you've moved the other way. Now there are just classes
   of components.
   ... I think that's a good idea, but I don't think we decided it.

   <alexmilowski> I've always thought of it that way too...

   Henry: In that case, we need to speak of allowing users to create classes
   of components

   Richard: I think the draft is confusing, it speaks of a graph of
   components, but choose and for-each aren't described as components.

   <ht> HST likes 'construct' for the language constructs

   <ht> and 'component' for XSLT and user-defined stuff

   <ht> and 'step' for the union of the two

   Norm describes how in fact he thinks "for-each" is now in fact a component

   Micheal: I'm a little concerned about losing the distinction between steps
   and components.
   ... Personally, I believe that people have a tendency to get confused
   about class/instance distinctions.

   Norm describes pipelines as a graph of components and steps as a mechanism
   for instantiating those components.

   Michael: I've got a pipeline with three XSLT stylesheets applied in
   sequence. I think I have three XML constructs in the XML description of
   the pipeline. I think I have three steps/stages in an abstract description
   of the pipeline.
   ... and three control blocks in memory, but perhaps only one copy of the
   processor if it's renetrant. But I have one of something, what is that?
   ... I had thought that that was a component.

   Richard: A shell script may run a sequence of two or three programs and
   two of them may be the same.
   ... The fact that in the first case I meant programs and in the second I
   meant executable file doesn't seem confusing.

   Michael: In some contexts, I can certainly imagine getting confused if we
   didn't have conventions for distinction between those things.

   Richard: One reason I don't want to elaborate a whole set of names is
   because there is in fact at least a third case for each one. Suppose you
   run a pipeline twice. Now, not only are there are the layers we already
   had, there's also the instances of them running.

   Henry: And this is entirely parallel to any description of an OO system.

   Richard: There's also the fact that we have constructs that run a
   component repeatedly within the same pipeline.

   Alex: Do we have to dig that deep?

   Richard: Let's look at it from the other end.
   ... We seem generally happy with the term "step" for the things that
   aren't built into the language.
   ... We need something for both language constructs and things not built
   into the language.

   Michael: You'd rather say we plug the output ports of the X component into
   the input ports of the Y component. Why not step?

   <MSM> one syllable vs three syllables

   Richard: The only reason I don't want to use step there is because we have
   a step element in the language.

   <ht>
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Aug/0095.html[6]

   Norm describes his situation where components are synthesised sometimes

   <ht> See above for the diagram Richard just referred to

   Richard: I also want to be able to be able to have steps in the document
   correspond to single components in the semantics

   Henry: The only thing worth noting right now about the diagram is that it
   goes backwards wrt the current discussion. It uses step for the union.

   Michael: I continue to be a little concerned about the absence of a term
   for the abstraction who's most obvious instantiation is a software module
   that a user might add to an available library
   ... what I'm hearing people say is that they want to use "component" for
   one of the constiuent parts of the pipeline
   ... I don't have a particular desire to use component in a slightly
   different way. I just don't think of invocations as instances of programs.

   Richard: Defining a component, writing a component, is like defining a
   function. So XSLT would be a function that you called.
   ... A line of the program that called that function would be a "function
   call"
   ... And there would be other constructs that weren't function calls like
   conditionals and loops.
   ... In our language, "steps" are like function calls because we don't call
   the conditional things steps.

   Henry: The problem with "step" for "statement" is that we have have an
   element named "step" which is the equivalent of "function call"

   Norm proposes to try to use step and component consistently in the
   document and see if that helps

   Michael: When CMS pipelines were introduced, the authors thought hard
   about the terminology.
   ... They used the term "stage" for the things that go between the pipeline
   characters.
   ... and for the processes that get connected up.
   ... I think in the abstract that step would be nicer, but stage does not
   have the collision with the usage of step as something which invokes
   something like XSLT

  The select attribute on p:param

   Norm summarizes the current state of the document

   Norm: I think we need to allow source/href/here on p:param

   Alex: I thought we agreed to do that, even though it gives me heartburn.
   ... I was surprised not to see that in the document.
   ... I think we should be clear that if you create a param that uses an
   input that isn't otherwise an input to the step, you're creating a new
   input dependency.

   Richard: It's easy to statically determine what the dependencies are.

   Norm will update the document to allow p:param elements to specify a
   context for the select attribute.

   Henry: I expect in due course that we'll have a shortcut for this.

   Norm asks about allowing declare-input on p:choose, p:for-each, etc.

   Richard: What about a declare-input that you don't use?

   Norm: Uhm

   Richard: It doesn't seem to usefully document anything if you can't
   prevent dangling inputs.

   Norm: Does anyone else want to be able to declare those inputs?

   Murray: I don't see any reason not to

   Richard: But unless we have rules that say that if you declare one, you
   must declare them all.

   <ht> MSM, see
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Aug/0096.html[7]
   for an attempt to follow up your suggestion wrt 'Stage'

   Richard: The effect of declare input is simply to alias an existing name.
   So how come you're only allowed to use it in these particular places.
   ... My inclination is not to allow it unless we work out what's allowed.

   Norm: My middle ground is to say that a declare-input that you don't use
   is an error.

   Henry: I feel that you should minimize the amount of work on the draft in
   this area.

   Norm: Ok, we'll leave it alone, but not record that as a decision.

   Norm proposes revising the draft before next week in an effort to get FPWD
   out

Summary of Action Items

   [End of minutes]

     ----------------------------------------------------------------------

   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2006/08/31-agenda.html
   [3] http://www.w3.org/2006/08/31-xproc-irc
   [6] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Aug/0095.html
   [7] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Aug/0096.html
   [8] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [9] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[8] version 1.127 (CVS
    log[9])
    $Date: 2006/08/31 20:12:57 $

Received on Thursday, 31 August 2006 20:14:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:48 GMT