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

XProc Minutes for 8 Jun 2006

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Fri, 09 Jun 2006 15:26:47 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <878xo63zbc.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2006/06/08-minutes.html


                                   - DRAFT -

                            XML Processing Model WG

Meeting 24, 8 Jun 2006


   See also: IRC log[3]


           Rui, Norm, Mohamed, Alessandro, Paul, Andrew, Alex





     * Topics
         1. Accept this agenda?
         2. Accept minutes from the previous teleconference?
         3. Next meeting: 15 June telcon
         4. Face-to-face: 2-4 Aug 2006.
         5. Review of open action items
         6. XProc syntax
         7. Issue 3306: XPath over a sequence of documents
         8. Any other business?
     * Summary of Action Items


  Accept this agenda?

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


  Accept minutes from the previous teleconference?

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


  Next meeting: 15 June telcon

   Any regrets?

   Paul gives regrets for 15 and 22 June

   <scribe> ACTION: Norm to correct minutes for 01 June [recorded in

   Norm: I suspect Henry to give regrets for 15 June

   Norm gives regrets for 22 June

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

   Fill out the registration form; tell Murray where you're staying

  Review of open action items

   A-13-01: MSM to draft a complete table; ETA: 15 June 2006

   <scribe> Continued

   A-23-01: Henry to describe an alternate proposal in email

   <scribe> Completed

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

   <scribe> Continued

   Norm to write a syntax proposal

   <scribe> Continued

  XProc syntax

   Norm: Henry's proposal was quite simple and I thought it might be good
   jumping off point.
   ... Alex reports that simple pipes will handle most of our use cases

   Norm invites Alex to discuss his "flows" and "pipes" mail

   Alex: Far more than the majority are really simple uses cases.
   ... They're straight pipes with some sub-resources that you need.
   ... If we had a simple way of expressing the straight through cases, that
   would be good. Especially if we could extend that.
   ... We could envision "pipes" as reusable bits that are used in more
   complex flows
   ... I just sent an example to the list.
   ... The processing is actually driven by the parsing of the document
   itself that drives the pipeline.

   See Alex's mail:

   Alex: Pipes are simple, they just process a primary input

   Alex describes his example

   Norm: How might we address Jeni's questions about Henry's example in this
   ... How do you do conditionals based on documents other than the primary

   Alex: You'd have a construct in the flow, outside of the pipes.
   ... You'd be choosing which pipes to execute? I'm a little fuzzy on the
   concrete use case.
   ... The choices in our use cases document seem to be relative to a
   particular input which could be the primary input to a pipe.

   Norm: I was going to suggest that the use of multiple pipes would allow
   you to make the conditionals be on the primary input and the output of
   those pipes could be used later.

   Alex: Based on which documents occur in a collection, you might want to do
   one set of pipes or another. It might become combinatorial, but maybe
   there are better ways to orchestrate that.

   Norm: What about conditionality on the number of documents in the default
   ... It seems to me that if we expose the documents a set then a simple
   count() expression will do it. If we don't, then we can provide a
   component that will return the number, and then you can do simple tests on
   that number.

   Alex: I think collections can be handled at the flow level

   Norm: What about steps that are conditional on two inputs: Is the xml:base
   attribute on this element the same as the superDoc attribute on that other
   document's root element.
   ... I guess in this flow-and-pipe arrangement that we've been talking
   about, you'd have to combine those two elements into a single document
   somehow and then pass that to a pipe that could evaluate the condition.

   Alex: We also have the ability to put something into the flow-level that
   could evaluate it
   ... A natural consequence of this is that you still need to build a graph
   of inputs and outputs. You might have mutually exclusive pipes that you
   have to deal with in the graph. There's still some complexity here in the
   flow language.

   Norm: I'm not sure what you mean by "adding things to the flow language"

   <MoZ> +1 for expliciting flow level

   Alex: In the example I sent, the flow graph of where the inputs and
   outputs go is straightforward. If you had conditionals at the level of the
   flow, then you have this issue of whether or not some steps execute and
   produce outputs that are inputs to other things.

   Norm: I want to keep the conditionals tightly bound so that we don't get
   that complexity in the graph

   Richard: We all concluded that it was to complex if conditionals could
   spread. Everything related to the conditional, I think we agreed, belong
   inside the conditional.
   ... I'm not convinced that the distinction between flow and pipe is the
   right idea.
   ... I take the analogy of unix pipes; there aren't two syntaxes there but
   it still makes the simple case simple. I'm not immediately agreeing that
   this is a good idea. But I haven't looked at it closely yet.
   ... What I ideally want is a syntax that handles the complicated case but
   where it just falls out that the simple case looks simple.

   Norm: Perhaps we should turn our attention to something else and see if we
   get some more complete syntax proposals before next week.

  Issue 3306: XPath over a sequence of documents

   Norm: Anyone know what the right answer is?
   ... No, I guess not.

   Norm explores what it means to process an XPath expression over a sequence
   of documents.

   Richard: Jeni proposed that we could make the node set have a document
   order that corresponded to the sequence of documents.

   Alessandro: My understanding is that the concept of nodeset is fully
   baked. If we only allow the expression to be evaluated over a single
   document, then that would seem to be an arbitrary restriction.
   ... it seems natural to map sequence of documents to node sets of document

   Richard: I think that's the most reasonable thing to do. If we do that and
   provide a component that can aggregate nodes togther, then you could cover
   both cases (the case where order didn't matter and the case where it did)

   Norm: It sounds like we're approaching consensus.

   Proposal: if an XPath expression is evaluated over an input that is a
   sequence of documents, the expressions is in fact evaulated over a nodeset
   that consists of the document nodes of that input sequence. We accept the
   limitation that the relative order of the documents in the sequence is

   Mohamed: We must add that the relative order is lost, and we must also
   handle duplicates.

   Norm: I don't think that situation arises. In XPath duplication is about
   node identity.

   Richard: One consequence of making the context node be a set of documents:
   what would be the meaning of "/" in that situation?

   Norm: That's a good question.

   Richard: If the context nodeset is a set of document nodes, what is the
   context node?

   <scribe> ACTION: Norm to record the issue of "/" in an input sequence
   context [recorded in

   Norm repeats the proposal.


  Any other business?


Summary of Action Items

   [NEW] ACTION: Norm to correct minutes for 01 June [recorded in
   [NEW] ACTION: Norm to record the issue of "/" in an input sequence context
   [recorded in http://www.w3.org/2006/06/08-xproc-minutes.html#action02[10]]
   [End of minutes]


   [1] http://www.w3.org/
   [2] http://www.w3.org/XML/XProc/2006/06/08-agenda.html
   [3] http://www.w3.org/2006/06/08-xproc-irc
   [6] http://www.w3.org/2006/06/08-xproc-minutes.html#action01
   [7] http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jun/0020.html
   [8] http://www.w3.org/2006/06/08-xproc-minutes.html#action02
   [9] http://www.w3.org/2006/06/08-xproc-minutes.html#action01
   [10] http://www.w3.org/2006/06/08-xproc-minutes.html#action02
   [11] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
   [12] http://dev.w3.org/cvsweb/2002/scribe/

    Minutes formatted by David Booth's scribe.perl[11] version 1.127 (CVS
    $Date: 2006/06/09 19:25:26 $

Received on Friday, 9 June 2006 19:26:59 UTC

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