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

XProc Minutes 20 July 2006

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Thu, 20 Jul 2006 15:09:38 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <877j28nle5.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/07/20-minutes.html


                                   - DRAFT -

                            XML Processing Model WG

Meeting 29, 20 Jul 2006


   See also: IRC log[3]


           Rui, Paul, Alex, Richard, Alessandro, Norm, Murray

           Mohamed, Henry, Andrew




     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous teleconference?
         3. Next meeting: 27 July
         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/07/20-agenda.html


  Accept minutes from the previous teleconference?

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


   -> http://www.w3.org/XML/XProc/2006/07/13-minutes.html


  Next meeting: 27 July

   Any regrets?

   Paul is at risk.

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

   Registration is closed. Make sure your arrangements are in order.

   Murray: Temperatures for the f2f are likely to be warm. It's been in the

  Review of open action items

   A-27-01: Alex to write up some straw syntaxes for some of the use cases

   <scribe> Closed.

   A-27-02: Norm to write up some straw syntaxes for some of the use cases

   <scribe> Closed.

   A-23-02: Richard to write a syntax proposal

   <scribe> Continued.

   A-23-03: Norm to write a syntax proposal

   <scribe> Closed.

   A-13-01: MSM to draft a complete table

   <Scribe> Continued. New ETA 27 July 2006.

  XProc syntax

   Norm: Norm attempts to summarize.


   Norm: We can talk about input/output bindings today and name/label/from as
   those seem to be issues we might be able to resolve.

   Murray: I'm happy to discuss these things, however, my thought is that the
   input/output bindings and the naming and cross referencing are two of the
   trickier things.
   ... We may need the white board.
   ... Is there something more fruitful to discuss?
   ... And whether or when are we going to get the strawman document to a
   stage where we can begin using it for discussion.

   Norm: For the latter question, I'd like to get to that point by next week.

   Murray: I'd be ok with saying at the end of the face-to-face. What I want
   to start discussing soon is changes to a document.

   Norm: With respect to the former point, those were the best issues I could
   come up with, but I'm open to suggestions.

   Alex describes message 66. See URI above.

   Richard: I agree with the approach, but I don't think you've factored out
   the naming issue.
   ... What I would have said is an input binding is a pair of the name of an
   input declared by the component and a docment flowing through a pipe in a
   ... And an output binding is a pair of a name of an output declared by the
   component and a document flowing out of the pipe.
   ... What you've actually said implies that names are the mechanism that
   will be used. The other possibilities are that you name the pipes, or that
   there are no names on the outputs, you just refer to them by component and
   output name.

   Alex: I was hoping to come to some agreement before we begin naming.
   ... Can you grab one of these things in an abstract sense and be able to
   look at it with some perspective of a syntaxless thing.
   ... There are aspects of dangling pointers (wrt includes) that may need to
   be resolved.

   Richard: Ok, so there's an asymetry between inputs and outputs. Inputs
   can't be "here documents" and probably can't be URLs.

   Alex describes a case where maybe he did put a URL on an output.

   <alexmilowski> The example I was talking about:

   Norm describes how input is sometimes a declaration and sometimes it's a

   Richard: I don't think there's any ambiguity that using input/with-input
   ... That case (use-case-5-6) where one is called url-request and one is
   reference-to-output, is final-doc-reference.xml the name used in
   result-document in XSLT?

   Alex: Yes

   Richard: I find it very confusing that these output elements have from

   Alex: I always use name to name the thing that you're providing and from
   always points to something with a name.

   Norm: I agree with Richard, I think it's hugely confusing.

   Alex: I don't think we have inputs/outputs nailed down at the conceptual
   level yet.

   Murray: We haven't agreed on the model and we seem to be going all over
   the place.

   Norm: Conceptual differences? I thought we understood them pretty well

   Alex: Maybe output is the real hard case.

   Richard: One way of looking at it is, that you bind inputs to outputs. You
   don't bind both of them to something.
   ... It's only inputs that you need to bind to things.

   Alex: What about two XSLT steps?

   Richard: Dot syntax

   Murray: I have a different answer.
   ... If I have a for-each or a choose, each area within that may or may not
   have an output.
   ... Let's say I've got five of them: a, b, c, d, e.
   ... I can name them each and then try to resolve them in later steps, or I
   can use Richard's dotted syntax.
   ... My answer would have been to give an output at a top level.

   <alexmilowski> +1 to this...

   Some discussion of the the naming case in the context of a choose with

   Norm observes that in a choose, you can say that the output of the choose
   is some label, but if the first when contains three steps, you have to
   bind the output from one of those steps to the output of the choose.

   Discussion of syntax defaulting.

   Norm: Let's not worry about the defaulting case until later.
   ... Do we agree conceptually about inputs and outputs?

   Alex: I don't think we're all on the same page about outputs.

   Richard: I don't think there's any real disagreement conceptually because
   I think we all agree that it's conceptually equivalent to a model where
   you have explicitly named pipes and what inputs nad outputs do is
   equivalent to attaching things to the end of pipes.
   ... Setting aside cases where you read it directly from an href or
   something like that.
   ... Then the question becomes, do we attach things by giving names to all
   the ends, or do we have a scheme in which pipes are implicitly named by
   using some dot syntax as I suggested.
   ... Or do we have some other syntax where pipes point to components or
   components point to explicit pipe objects.

   Alex: I have to say I was worried about having to name things a lot and
   while the syntax is up in the air, having to map those names to things I"m
   going to use in the pipeline isn't a big deal.

   Norm: I've convinced myself that the two styles are isomorphic.
   ... It's going to come down to what syntax is easier.

   Richard: I'm worried about what Alex said, I thought that if you referred
   to another pipeline you never got to see what was inside.

   Norm: Indeed.

   Alex: It depends on whether you can do textual sorts of inclusoin.

   Richard: There's no question that we're going to have to provide names for
   the things that are parameters to the *pipeline*
   ... Looking at your example, you've been forced to name things document-2,
   document-3, etc. Those aren't meaningful names.

   Alex: The use cases I wrote have better names.

   Murray: It's possible that we can make this taste-good and be less-filling
   at the same time. If I don't name things, they're named for me, and if I
   name them, I can use those names.

   Richard: I completely agree.

   Norm: We could do both, but the world will think better of us in five
   years if we muster the courage to pick only one.

   Richard: You could stay that steps can be named, and outputs can be named,
   and you can refer to either one.

   Norm: Yes.

   Richard: Then we might be able to come up with a uniform syntax for naming
   everything. Things could all be optionally named, you just have to name
   enough things to be able to refer to the things you want to refer to.

   Norm: Yes, we could do that. And maybe it wouldn't be the most evil thing
   I've done this week.

   Richard: This might also help debuggers.

   Alex: I'd like feedback on some specific use cases.
   ... The XInlude one, 5.2[9].
   ... Can we "interfere" with the nested XIncludes?
   ... Also, 5.4.1[10] and 5.4.2[11], the aggregation use cases.

   Alex: This one has to do with collections.
   ...Also: 5.6[12], where XSLT produces two things.

  Any other business?



Summary of Action Items

   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2006/07/20-agenda.html
   [3] http://www.w3.org/2006/07/20-xproc-irc
   [8] http://www.w3.org/XML/XProc/docs/use-cases/web/use-case-5-6.xml
   [9] http://www.w3.org/XML/XProc/docs/use-cases/web/use-case-5-2.xml
   [10] http://www.w3.org/XML/XProc/docs/use-cases/web/use-case-5-4-1.xml
   [11] http://www.w3.org/XML/XProc/docs/use-cases/web/use-case-5-4-2.xml
   [12] http://www.w3.org/XML/XProc/docs/use-cases/web/use-case-5-6.xml
   [13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [14] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[13] version 1.127 (CVS
    $Date: 2006/07/20 19:07:04 $

Received on Thursday, 20 July 2006 19:09:44 UTC

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