15:58:43 RRSAgent has joined #xproc 15:58:43 logging to http://www.w3.org/2007/01/25-xproc-irc 15:58:46 Meeting: XML Processing Model WG 15:58:46 Date: 25 Jan 2007 15:58:46 Agenda: http://www.w3.org/XML/XProc/2007/01/25-agenda.html 15:58:46 Meeting: 52, T-minus 40 weeks 15:58:46 Chair: Norm 15:58:47 Scribe: Norm 15:58:49 ScribeNick: Norm 15:59:11 richard has joined #xproc 15:59:15 Zakim, what is the code? 15:59:15 the conference code is 97762 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), rlopes 15:59:18 zakim, please call ht-781 15:59:18 ok, ht; the call is being made 15:59:19 -Norm 15:59:21 +Norm 15:59:23 +Ht 15:59:29 +??P7 15:59:43 Zakim, ? is me 15:59:43 +rlopes; got it 15:59:50 +TomB 16:00:05 zakim, tomb is richard 16:00:05 +richard; got it 16:00:33 zakim, who's on the phone? 16:00:33 On the phone I see Norm, Ht, rlopes, richard 16:02:42 +Alex_Milowski 16:02:43 Regrets: Alessandro, Mohamed 16:03:03 alexmilowski has joined #xproc 16:03:05 AndrewF has joined #xproc 16:03:35 +??P11 16:03:41 zakim, ? is AndrewF 16:03:41 +AndrewF; got it 16:05:42 http://www.w3.org/XML/XProc/docs/alternate/ 16:06:33 Present: Norm, Henry, Rui, Richard, Alex, Andrew 16:06:34 Regrets: Alessandro, Mohamed, Paul 16:06:40 Topic: Accept this agenda? 16:06:40 -> http://www.w3.org/XML/XProc/2007/01/25-agenda.html 16:06:45 Accepted. 16:06:49 Topic: Accept minutes from the previous meeting? 16:06:49 -> http://www.w3.org/XML/XProc/2007/01/11-minutes.html 16:06:56 Accepted. 16:07:00 Topic: Next meeting: telcon 1 Feb 2007 16:07:15 No regrets given. 16:07:30 Topic: Choose/When syntax 16:09:02 Richard: Does the status quo allow you to override the context on each when? 16:09:11 Norm: Yes, by using an input named "source". 16:09:22 Henry: I prefer option 2, but I'm not sure I'm happy with the name xpath-context. 16:09:34 Henry: But I'm increasingly unhappy with any aspect of our design that uses builtin port names. 16:09:59 Norm: Tying this back to for-each and friends, the name "context" was proposed. 16:09:59 zakim, please call MSM-Office 16:09:59 ok, MSM; the call is being made 16:10:01 +MSM 16:11:22 Norm: I think the context element is oddly named in the for-each case, but I could get used to it. 16:11:42 Richard: What I find unpleasant is that the test is lexically outside the context binding element. 16:12:07 ...The context ought to be provided for things inside it or at the same level, not for things outside it. 16:12:20 Norm: I see your point, but I don't know what to do about it. 16:13:28 Michael: I have a question of comprehension: I thought that context was another name for a sole input. 16:13:54 Henry: That's not right: it's been an aspect of our choose/when design for a long time that the input to the branches is distinct from the input which is tested. 16:14:07 ...You can test one document and process on each of the branches different documents. 16:14:24 Michael: I think the draft should say that, I don't think it currently does. 16:18:11 Alex: This context has the feature that we don't have to name the port. 16:18:19 Alex: I would be really happy with a different name. 16:19:12 Norm repeats his earlier comments about the name "context" 16:19:28 Henry: I'm less sure that I want to treat this the same way that we treat for-each and viewport. 16:19:39 ...In those cases, the input there really is the input to the component. 16:20:10 ...I really do want to stay with some consistent notion of what "the input" is. 16:20:30 ...I'm not sure we should fold them together. 16:20:39 ...I like option 2 and I think calling it "context" is better than "xpath-context" 16:21:01 Michael: I was with you up to the last part about the name. 16:21:10 Alex: For-each and viewport are exactly like choose/when. 16:21:37 Alex: Viewport and for-each do something with the context. 16:22:55 Norm: Jeni made the point that having source in for-each and viewport is a little odd. 16:23:29 Richard: I'm wishing that I'd taken a completely different approach and using, for example, variables to refer to the documents in scope instead of all the complexity of tests. 16:23:46 +1 to HT's argument that the XPath context of a Choose/When is conceptually quite different from the single input of a viewport or for-each 16:24:14 Richard: It was suggested that XPaths be able to refer to inputs through variables. So the test could be "$source/something" or "$whatever/something". 16:24:23 Alex: We chould have an extension function to do this. 16:24:48 Norm muses "source(step,name)" 16:25:00 p:source(step,name) 16:25:18 p:pipe(step,name) 16:25:24 Alex: It has the consequence that it means you can't use an off-the-shelf XPath implementation. 16:25:53 Richard: The problem with an extension function is that it means you can dynamically construct the step and port names. 16:26:03 Henry: If that was the only thing in the way, we could just rule that. 16:26:15 s/rule that./rule that out./ 16:26:29 Richard: I disliked this before because it made it harder to see the flow of documents through the pipeline. 16:26:44 Richard: As long as you can figure out where the pipes go at compile time, I could live with it. 16:27:22 Henry: What I like about this is that it invites a natural default which is that the context of when defaults of context of choose which defaults to the primary input of choose. 16:28:02 s/defaults of context/defaults to context/ 16:28:55 Norm: With my chair's hat on, I have to question the size of this change? 16:29:39 Richard: I think that over the last few months, this nagging problem of the syntax and how to bind things for XPaths has been dragging us back. 16:29:49 ...Maybe it is a big enough problem that we really do need to reconsider it. 16:30:27 Henry: Opening XPaths in general to being able to attract input from any in-scope output port inside square brackets, etc. really does change the power of the language as it appears. 16:30:49 ...It effectively changes your ability to read off the data flow of a pipeline from its input port elements. 16:31:47 ...Extension functions have semantics that go way beyond the problem we were trying to solve. 16:32:13 ...I'm back to thinking we should go with option 2 and discuss the name of the element at another time. 16:33:17 Michael: My problem with option 2 is for the same information it requires a more complicated and elaborate XML structure. You're adding element structures that don't seem to be doing much. The term context is already taken in our spec. 16:33:32 ...We're going to have different names for these things. 16:35:22 Alex: Couldn't we just have an input without a port attribute? 16:35:29 Henry: That's just too complex for users. 16:36:20 Henry: Option 2 spells a special case with a special element name instead of spelling it "input port='source'" 16:36:52 Michael: Looking at the example more carefully, I think you're right. The second option isn't more complex. 16:36:56 ...I withdraw the argument. 16:37:50 Micheal: My dislike of adding a new GI was based on the misaprehension given by the note in the November draft that said that context was analogous with the input of for-each which I'm now learning is not what people intend. 16:37:57 ...I still stick at the term "context" 16:40:05 Henry, your argument does not support the use of the term "context" to mean something that the XPath spec calls by a different name 16:42:17 'context-node' works for me 16:42:52 Norm: I think that option 2, if we stick with something like the current syntax, is a consensus position. Does anyone disagree? 16:42:54 No one did. 16:43:06 Norm: So the question is then, what name? We can always revisit it later. 16:43:23 if we find a different name for what is now called 'context', we can revisit the name of this element. 16:44:39 Norm: The name is left to the editor's discretion, except that "context" is off the table. 16:45:55 Proposed: We will adopt option 2 as described above for the next draft. 16:46:05 Accepted. 16:46:21 Topic: Defaulting 16:46:48 http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0022.html 16:46:55 Henry: Yes. I had in mind going back to the threads that started in December. 16:46:59 http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0041.html 16:47:24 http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Dec/0056.html 16:47:47 Henry: I would like to say something like where we ended up in that discussion, editor please draft :-) 16:48:09 Norm: The editor might like somewhat more direction. 16:48:22 Alex: The real crux seems to be dealing with the preceding sibling case. 16:48:45 Henry: A crucial question is, is it names or is it arity? I started out thinking that I didn't care what a step's port was called if it only had one. 16:49:40 Norm: I think the draft will be easier to understand if we do it in terms of names. 16:50:15 Henry: I think it's easier to talk about the single input port, regardless of name. 16:50:34 Richard: We could certainly say that if the component only has one input, that's it's default. 16:51:08 Alex: Or we could say that a component declaration indicated its default port. 16:51:41 Richard: I like that. 16:52:33 Some discussion of input ports 16:52:45 Richard: I think you could just say that any unconnected input port is connected to the default. 16:53:38 Alex: In the case of building tools, I can imagine that having a declaration of which one is usually defaulted would be useful. 16:54:33 Richard: I can see Alex's point that this would be useful for a graphical tool 16:54:55 I'm now convinced that the only thing we need to do is provide a rule for which output provides the default input binding for its following sibling in the case where there is more than one output port 16:54:55 ...We could say that you designate one input as primary but that it's not used by the language. 16:55:56 +1 16:56:00 Norm: I think we're saying that, component declarations should be allowed to specify a single primary output, they should be allowed to specify a single primary input (but the language doesn't care) and that any unconnected input is automaticly connected to the default input. 16:56:17 ...Where the default input is the default output of the preceing sibling or the preceding sibling of the container. 16:56:28 ...Recursively. 16:57:30 Richard: I would say that each container component should specify what it's default input is and that's in the context. 16:58:11 Richard: I also think we should say explicitly that a component only has one output, that is it's default output regardless of what we say in the declaratoin. 16:58:15 s/toin/tion/ 17:00:21 Topic: Any other business 17:00:40 None 17:01:29 -MSM 17:01:55 -Norm 17:01:58 -richard 17:01:59 -AndrewF 17:02:01 -rlopes 17:02:03 -Alex_Milowski 17:02:18 rrsagent, set logs world visible 17:02:19 I'm logging. I don't understand 'set logs world visible', Norm. Try /msg RRSAgent help 17:02:25 rrsagent, set logs world-visible 17:02:30 rrsagent, draft minutes 17:02:30 I have made the request to generate http://www.w3.org/2007/01/25-xproc-minutes.html Norm 17:02:36 alexmilowski has left #xproc 17:07:06 disconnecting the lone participant, Ht, in XML_PMWG()11:00AM 17:07:11 XML_PMWG()11:00AM has ended 17:07:13 Attendees were +1.781.442.aaaa, Norm, Ht, rlopes, richard, Alex_Milowski, AndrewF, MSM 17:07:30 zakim, please excuse us 17:07:30 Zakim has left #xproc 19:15:19 Norm has joined #xproc 19:38:31 Norm has joined #xproc 20:04:50 rrsagent, pointer 20:04:50 See http://www.w3.org/2007/01/25-xproc-irc#T20-04-50 20:15:44 rrsagent, draft minutes 20:15:45 I have made the request to generate http://www.w3.org/2007/01/25-xproc-minutes.html Norm