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

XProc Minutes 13 July 2006

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

W3C[1]

                                   - DRAFT -

                            XML Processing Model WG

Meeting 28, 13 Jul 2006

   Agenda[2]

   See also: IRC log[3]

Attendees

   Present
           Alessandro, Mohamed, Norman, Paul, Alex, Andrew

   Regrets
           Murray

   Chair
           Norm

   Scribe
           Norm

Contents

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

   Accepted.

  Accept minutes from the previous teleconference?

   No, since they were never published

  Next meeting: 20 July

   Any regrets?

   None given.

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

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

  Review of open action items

   A-27-01

   <scribe> Completed

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

   <scribe> Continued.

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

   <scribe> Continued.

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

   <scribe> Continued

   A-13-01: MSM to draft a complete table; ETA: 20 July 2006

   <scribe> Continued.

  XProc syntax

   Alex: I worked through some of my examples.

   ->
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jul/0002.html

   Alex: Maybe it's easier to look at the large document example

   ->
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jul/0016.html

   Norm: Is this the one you had in mind?

   Alex: Yes
   ... There's one tweak, the 'from' attribute is wrong in this one.
   ... The idea is that you are selecting an expression (@select) over an
   input document (@over)
   ... The thing you select has to be an element, so that it can be made into
   a document.
   ... That's provide as input labeled "iteration" (@to)
   ... The output of the for-each is the input that's been processed.

   <alexmilowski> <p:for-each select="section" over="large-doc"
   to="iteration" replacement="transformed">

   <alexmilowski> <!-- input isn't needed here because this "for-each" has

   <alexmilowski> to iterate over elements. The input is identified by

   <alexmilowski> the 'over' attribute and the binding for each result

   <alexmilowski> element is specified by the 'to' attribute. -->

   <alexmilowski> <p:output name="final" from="large-document"/>

   Alex: So in this example, the output is a little funny

   Some discussion which the scribe couldn't follow

   Norm attempts to summarize

   Alex: The way I've been using the output element is that there's a name
   for it and a from that refers to whatever you're labelling
   ... So what is the from?
   ... In the case of a normal step, it'd be something the component defined.

   Norm and Alex attempt to come to an understanding...

   Alex: The p:output can't be from 'transformed' because that's just the
   inner result. And it can't be 'large-doc' because it's not large-doc, it's
   large-doc after modification.

   <alexmilowski>
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jul/0028.html[7]

   Norm: This suggestion makes p:for-each something like a p:output in the
   sense that it defines a label for its output

   Alex: I think an issue we should raise for later is whether there's some
   grand unification of this and iterating over documents. We should make
   sure we come back to that.
   ... It would be unfortunate if we couldn't extend this to the concept of
   iterating over sequences of documents

   Norm: This example has multiple steps
   ... You've used the explicit naming of each input and output as opposed to
   the alternative which was naming though the step name.

   Alex: I said no defaults, no magic, no prefixing.

   Norm: Ok, so that was a significant part of your proposal.

   Alex: In the end, I think it might be very confusing to users.

   Norm: I'm inclined to agree.

   <MoZ> Alex, are steps systematicaly anonymous ?

   Norm: Anything else we should spend time discussing?

   ->
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jul/0017.html

   Alex: Most interesting bit is the p:url step

   <alexmilowski> http://www.smallx.com/tideinfo/[9]

   <alexmilowski> http://www.smallx.com/tideinfo-service/[10]

   Alex: The url step performs an http action and possibly massages the
   result (based on content-type) to produce a well-formed XML result
   ... The following steps cleanup and filter the result data.
   ... There's nothing earth shattering here except for the retrieval step.
   ... I could have done this through XSLT using document() calls, but that
   would require XSLT to be able to handle HTML documents

   Alessandro: the only thing I see are purely syntactic. What's the best
   name for these attributes, for example?

   Naming is hard.

   Alex: The naming issues and not having defaults haven't really been an
   issue for me. That makes me pretty comfortable with a first-round story
   that doesn't have any defaults.

   ->
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jul/0019.html

   Alex: The biggest thing to not here are the parameters.
   ... There's one input that contains two elements. I'm going to need those
   lots of times.
   ... So I grab them right at the beginning.
   ... There's a whole question of if you use parameters, where are they
   available. Is it implicit or explicit? Etc.
   ... This is a straight-through pipe. In fact it has to stream because the
   output of the last two steps can blow up to millions of elements.

   Norm: Are you making parameters copies or pointers to a document?

   Alex: I'm making copies.
   ... There are two interesting things: I have a bunch of custom steps, how
   do we deal with those, and I have a need to reuse the inputs to the
   pipeline at a later part, what's the right way to do that? With
   parameters? Or an input dependency? And how would that work?

  Any other business?

   None.

   Scribe apologizes for rather poor minutes this week.

Summary of Action Items

   [End of minutes]

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

   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2006/07/13-agenda.html
   [3] http://www.w3.org/2006/07/13-xproc-irc
   [7]
   http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jul/0028.html
   [9] http://www.smallx.com/tideinfo/
   [10] http://www.smallx.com/tideinfo-service/
   [12] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [13] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[12] version 1.127 (CVS
    log[13])
    $Date: 2006/07/18 16:39:27 $

Received on Tuesday, 18 July 2006 16:41:42 GMT

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