14:51:50 <RRSAgent> RRSAgent has joined #xproc
14:51:50 <RRSAgent> logging to http://www.w3.org/2006/06/08-xproc-irc
14:51:53 <Norm> zakim, this will be xproc
14:51:53 <Zakim> ok, Norm; I see XML_PMWG()11:00AM scheduled to start in 9 minutes
14:52:28 <Norm> Norm has changed the topic to: XProc WG: 8 June 2006: http://www.w3.org/XML/XProc/2006/06/08-agenda.html
14:52:43 <Norm> Meeting: XML Processing Model WG
14:52:43 <Norm> Scribe: Norm
14:52:43 <Norm> ScribeNick: Norm
14:52:43 <Norm> Date: 8 Jun 2006
14:52:43 <Norm> Chair: Norm
14:52:44 <Norm> Agenda: http://www.w3.org/XML/XProc/2006/06/08-agenda.html
14:53:07 <rlopes> rlopes has joined #xproc
14:55:18 <Zakim> XML_PMWG()11:00AM has now started
14:55:25 <Zakim> +??P27
14:59:50 <Zakim> +Norm
14:59:53 <Zakim> -??P27
14:59:54 <Zakim> +??P27
15:00:08 <Norm> zakim, ??p27 is rlopes 
15:00:08 <Zakim> +rlopes; got it
15:00:23 <Norm> zakim, who's on the phone?
15:00:24 <Zakim> On the phone I see rlopes, Norm
15:01:04 <Zakim> +[ArborText]
15:01:11 <PGrosso> PGrosso has joined #xproc
15:01:18 <Norm> zakim, ArborText is PGrosso 
15:01:18 <Zakim> +PGrosso; got it
15:01:34 <Zakim> +[IPcaller]
15:01:41 <avernet> Zakim, [IP is Alessandro
15:01:41 <Zakim> +Alessandro; got it
15:02:14 <MoZ> Zakim, what is the code?
15:02:14 <Zakim> the conference code is 97762 (tel:+1.617.761.6200), MoZ
15:02:43 <AndrewF> AndrewF has joined #xproc
15:03:09 <Zakim> +moz
15:03:15 <Zakim> +Alex_Milowski
15:03:29 <alexmilowski> alexmilowski has joined #xproc
15:03:35 <Zakim> +??P42
15:03:37 <AndrewF> zakim, ? is AndrewF
15:03:39 <Zakim> +AndrewF; got it
15:03:40 <Norm> zakim, who's on the phone?
15:03:41 <Zakim> On the phone I see rlopes, Norm, PGrosso, Alessandro, moz, Alex_Milowski, AndrewF
15:06:07 <Norm> Topic: Accept this agenda?
15:06:07 <Norm> -> http://www.w3.org/XML/XProc/2006/06/08-agenda.html
15:06:29 <Norm> Present: Rui, Norm, Mohamed, Alessandro, Paul, Andrew, Alex
15:06:42 <Norm> Regrets: Micheal
15:06:54 <Norm> Accepted.
15:06:59 <MoZ> s/Micheal/Michael/
15:07:00 <Norm> Topic: Accept minutes from the previous teleconference?
15:07:00 <Norm> -> http://www.w3.org/XML/XProc/2006/06/01-minutes.html
15:07:08 <Norm> Accepted.
15:07:14 <Norm> Topic: Next meeting: 15 June telcon
15:07:14 <Norm> Any regrets?
15:07:38 <Norm> Paul gives regrets for 15 and 22 June
15:08:07 <Norm> ACTION: Norm to correct minutes for 01 June
15:08:33 <Norm> Norm: I suspect Henry to give regrets for 15 June
15:08:51 <Norm> Norm gives regrets for 22 June
15:09:05 <Norm> Topic: Face-to-face: 2-4 Aug 2006.
15:09:54 <Norm> Fill out the registration form; tell Murray where you're staying
15:09:57 <Norm> Topic: Review of open action items
15:10:02 <Norm> A-13-01: MSM to draft a complete table; ETA: 15 June 2006
15:10:04 <Norm> Continued
15:10:12 <Norm> A-23-01: Henry to describe an alternate proposal in email
15:10:30 <Norm> Completed
15:10:39 <Norm> A-23-02: Richard to write a syntax proposal
15:10:40 <Norm> Continued
15:10:45 <Norm> Norm to write a syntax proposal
15:10:48 <Norm> Continued
15:10:58 <Norm> Topic: XProc syntax
15:11:37 <Norm> Norm: Henry's proposal was quite simple and I thought it might be good jumping off point.
15:12:10 <Norm> Norm: Alex reports that simple pipes will handle most of our use cases
15:12:44 <Norm> Norm invites Alex to discuss his "flows" and "pipes" mail
15:12:57 <Norm> Alex: Far more than the majority are really simple uses cases.
15:13:15 <Norm> Alex: They're straight pipes with some sub-resources that you need.
15:14:03 <Norm> Alex: If we had a simple way of expressing the straight through cases, that would be good. Especially if we could extend that.
15:14:19 <Norm> Alex: We could envision "pipes" as reusable bits that are used in more complex flows
15:14:30 <Norm> Alex: I just sent an example to the list.
15:15:07 <Norm> Alex: The processing is actually driven by the parsing of the document itself that drives the pipeline.
15:16:10 <alexmilowski> <pipe> 
15:16:10 <alexmilowski>    <input name="in.document" primary="true"/>
15:16:10 <alexmilowski>    <input name="in.schema"/>
15:16:10 <alexmilowski>    <input name="in.stylesheet"/>
15:16:10 <alexmilowski>    <step name="validate">
15:16:11 <alexmilowski>       <input name="schema" ref="in.document"/>
15:16:13 <alexmilowski>    </step>
15:16:15 <alexmilowski>    <step name="xslt">
15:16:17 <richard> richard has joined #xproc
15:16:17 <alexmilowski>       <input name="stylesheet" ref="in.stylesheet"/>
15:16:19 <alexmilowski>    </step>
15:16:21 <alexmilowski> </pipe>
15:16:43 <PGrosso> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jun/0020.html
15:16:46 <Norm> Alex: Pipes are simple, they just process a primary input
15:16:47 <Zakim> +??P5
15:16:49 <richard> zakim, ? is richard
15:16:49 <Zakim> +richard; got it
15:16:54 <PGrosso> [is alex's email in the archive]
15:16:58 <PGrosso> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Jun/0020.html
15:17:20 <Norm> Alex describes his example
15:22:01 <Norm> Norm: How might we address Jeni's questions about Henry's example in this framework?
15:22:31 <Norm> Norm: How do you do conditionals based on documents other than the primary input
15:23:07 <Norm> Alex: You'd have a construct in the flow, outside of the pipes.
15:23:33 <Norm> Alex: You'd be choosing which pipes to execute? I'm a little fuzzy on the concrete use case.
15:23:55 <Norm> Alex: The choices in our use cases document seem to be relative to a particular input which could be the primary input to a pipe.
15:24:26 <Norm> 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. 
15:25:37 <Norm> 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.
15:26:47 <Norm> Norm: What about conditionality on the number of documents in the default input?
15:27:32 <Norm> Norm: 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.
15:28:20 <Norm> Alex: I think collections can be handled at the flow level
15:28:49 <Norm> Norm: What about steps that are conditional on two inputs: Is the xml:base attribute on this document the same as the superDoc attribute on that other document's root element.
15:29:06 <Norm> s/on this document/on this element/
15:30:07 <Norm> Norm: 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.
15:30:29 <Norm> Alex: We also have the ability to put something into the flow-level that could evaluate it
15:31:24 <Norm> Alex: 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.
15:31:53 <Norm> Norm: I'm not sure what you mean by "adding things to the flow language"
15:32:02 <MoZ> +1 for expliciting flow level 
15:32:56 <Norm> 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.
15:34:23 <Norm> Norm: I want to keep the conditionals tightly bound so that we don't get that complexity in the graph
15:35:00 <Norm> 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.
15:36:05 <Norm> Richard: I'm not convinced that the distinction between flow and pipe is the right idea. 
15:36:39 <Norm> Richard: 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.
15:37:06 <Norm> Richard: What I ideally want is a syntax that handles the complicated case but where it just falls out that the simple case looks simple.
15:37:58 <ht> zakim, please call ht-781
15:38:00 <Zakim> ok, ht; the call is being made
15:38:02 <Zakim> +Ht
15:40:12 <Norm> Norm: Perhaps we should turn our attention to something else and see if we get some more complete syntax proposals before next week.
15:40:49 <Norm> Topic: Isue 3306: XPath over a sequence of documents
15:40:54 <Norm> s/Isue/Issue/
15:41:16 <Norm> Norm: Anyone know what the right answer is?
15:41:21 <Norm> Norm: No, I guess not.
15:42:53 <avernet> q+
15:43:27 <Norm> Norm explores what it means to process an XPath expression over a sequence of documents.
15:44:29 <Norm> Richard: Jeni proposed that we could make the node set have a document order that corresponded to the sequence of documents.
15:46:46 <Norm> ack avernet 
15:47:57 <Norm> 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.
15:48:17 <Norm> Alessandro: it seems natural to map sequence of documents to node sets of document nodes
15:48:47 <Norm> 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)
15:49:05 <Norm> Norm: It sounds like we're approaching consensus.
15:50:43 <Norm> 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 lost.
15:50:44 <MoZ> q+
15:51:09 <Norm> ack MoZ 
15:51:26 <Norm> Mohamed: We must add that the relative order is lost, and we must also handle duplicates.
15:54:10 <Norm> Norm: I don't think that situation arises. In XPath duplication is about node identity.
15:57:50 <Norm> Richard: One consequence of making the context node be a set of documents: what would be the meaning of "/" in that situation?
15:57:56 <Norm> Norm: That's a good question.
15:58:41 <Norm> Richard: If the context nodeset is a set of document nodes, what is the context node?
15:59:24 <Norm> ACTION: Norm to record the issue of "/" in an input sequence context
16:00:29 <Norm> Norm repeates the proposal.
16:00:38 <Norm> s/repeates/repeats/
16:00:43 <Norm> Accepted.
16:00:52 <Norm> Topic: Any other business?
16:00:53 <Norm> None
16:01:11 <Zakim> -richard
16:01:13 <Zakim> -Norm
16:01:14 <Zakim> -Alessandro
16:01:15 <Zakim> -moz
16:01:16 <Zakim> -Alex_Milowski
16:01:17 <Zakim> -PGrosso
16:01:19 <Zakim> -rlopes
16:01:20 <Zakim> -AndrewF
16:01:24 <PGrosso> PGrosso has left #xproc
16:03:47 <Norm> rrsagent, make logs world-visible
16:03:52 <Norm> rrsagent, draft minutes
16:03:52 <RRSAgent> I have made the request to generate http://www.w3.org/2006/06/08-xproc-minutes.html Norm
16:06:18 <Zakim> disconnecting the lone participant, Ht, in XML_PMWG()11:00AM
16:06:24 <Zakim> XML_PMWG()11:00AM has ended
16:06:25 <Zakim> Attendees were Norm, rlopes, PGrosso, [IPcaller], Alessandro, moz, Alex_Milowski, AndrewF, richard, Ht
16:21:26 <Norm> Norm has joined #xproc
16:24:01 <alexmilowski> alexmilowski has left #xproc
18:02:22 <Zakim> Zakim has left #xproc
18:41:22 <Norm> rrsagent, bye
18:41:22 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2006/06/08-xproc-actions.rdf :
18:41:22 <RRSAgent> ACTION: Norm to correct minutes for 01 June [1]
18:41:22 <RRSAgent>   recorded in http://www.w3.org/2006/06/08-xproc-irc#T15-08-07
18:41:22 <RRSAgent> ACTION: Norm to record the issue of "/" in an input sequence context [2]
18:41:22 <RRSAgent>   recorded in http://www.w3.org/2006/06/08-xproc-irc#T15-59-24