IRC log of xproc on 2007-01-25

Timestamps are in UTC.

15:58:43 [RRSAgent]
RRSAgent has joined #xproc
15:58:43 [RRSAgent]
logging to
15:58:46 [Norm]
Meeting: XML Processing Model WG
15:58:46 [Norm]
Date: 25 Jan 2007
15:58:46 [Norm]
15:58:46 [Norm]
Meeting: 52, T-minus 40 weeks
15:58:46 [Norm]
Chair: Norm
15:58:47 [Norm]
Scribe: Norm
15:58:49 [Norm]
ScribeNick: Norm
15:59:11 [richard]
richard has joined #xproc
15:59:15 [rlopes]
Zakim, what is the code?
15:59:15 [Zakim]
the conference code is 97762 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), rlopes
15:59:18 [ht]
zakim, please call ht-781
15:59:18 [Zakim]
ok, ht; the call is being made
15:59:19 [Zakim]
15:59:21 [Zakim]
15:59:23 [Zakim]
15:59:29 [Zakim]
15:59:43 [rlopes]
Zakim, ? is me
15:59:43 [Zakim]
+rlopes; got it
15:59:50 [Zakim]
16:00:05 [richard]
zakim, tomb is richard
16:00:05 [Zakim]
+richard; got it
16:00:33 [Norm]
zakim, who's on the phone?
16:00:33 [Zakim]
On the phone I see Norm, Ht, rlopes, richard
16:02:42 [Zakim]
16:02:43 [Norm]
Regrets: Alessandro, Mohamed
16:03:03 [alexmilowski]
alexmilowski has joined #xproc
16:03:05 [AndrewF]
AndrewF has joined #xproc
16:03:35 [Zakim]
16:03:41 [AndrewF]
zakim, ? is AndrewF
16:03:41 [Zakim]
+AndrewF; got it
16:05:42 [Norm]
16:06:33 [Norm]
Present: Norm, Henry, Rui, Richard, Alex, Andrew
16:06:34 [Norm]
Regrets: Alessandro, Mohamed, Paul
16:06:40 [Norm]
Topic: Accept this agenda?
16:06:40 [Norm]
16:06:45 [Norm]
16:06:49 [Norm]
Topic: Accept minutes from the previous meeting?
16:06:49 [Norm]
16:06:56 [Norm]
16:07:00 [Norm]
Topic: Next meeting: telcon 1 Feb 2007
16:07:15 [Norm]
No regrets given.
16:07:30 [Norm]
Topic: Choose/When syntax
16:09:02 [Norm]
Richard: Does the status quo allow you to override the context on each when?
16:09:11 [Norm]
Norm: Yes, by using an input named "source".
16:09:22 [Norm]
Henry: I prefer option 2, but I'm not sure I'm happy with the name xpath-context.
16:09:34 [Norm]
Henry: But I'm increasingly unhappy with any aspect of our design that uses builtin port names.
16:09:59 [Norm]
Norm: Tying this back to for-each and friends, the name "context" was proposed.
16:09:59 [MSM]
zakim, please call MSM-Office
16:09:59 [Zakim]
ok, MSM; the call is being made
16:10:01 [Zakim]
16:11:22 [Norm]
Norm: I think the context element is oddly named in the for-each case, but I could get used to it.
16:11:42 [Norm]
Richard: What I find unpleasant is that the test is lexically outside the context binding element.
16:12:07 [Norm]
...The context ought to be provided for things inside it or at the same level, not for things outside it.
16:12:20 [Norm]
Norm: I see your point, but I don't know what to do about it.
16:13:28 [Norm]
Michael: I have a question of comprehension: I thought that context was another name for a sole input.
16:13:54 [Norm]
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 [Norm]
...You can test one document and process on each of the branches different documents.
16:14:24 [Norm]
Michael: I think the draft should say that, I don't think it currently does.
16:18:11 [Norm]
Alex: This context has the feature that we don't have to name the port.
16:18:19 [Norm]
Alex: I would be really happy with a different name.
16:19:12 [Norm]
Norm repeats his earlier comments about the name "context"
16:19:28 [Norm]
Henry: I'm less sure that I want to treat this the same way that we treat for-each and viewport.
16:19:39 [Norm]
...In those cases, the input there really is the input to the component.
16:20:10 [Norm]
...I really do want to stay with some consistent notion of what "the input" is.
16:20:30 [Norm]
...I'm not sure we should fold them together.
16:20:39 [Norm]
...I like option 2 and I think calling it "context" is better than "xpath-context"
16:21:01 [Norm]
Michael: I was with you up to the last part about the name.
16:21:10 [Norm]
Alex: For-each and viewport are exactly like choose/when.
16:21:37 [Norm]
Alex: Viewport and for-each do something with the context.
16:22:55 [Norm]
Norm: Jeni made the point that having source in for-each and viewport is a little odd.
16:23:29 [Norm]
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 [MSM]
+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 [Norm]
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 [Norm]
Alex: We chould have an extension function to do this.
16:24:48 [Norm]
Norm muses "source(step,name)"
16:25:00 [ht]
16:25:18 [ht]
16:25:24 [Norm]
Alex: It has the consequence that it means you can't use an off-the-shelf XPath implementation.
16:25:53 [Norm]
Richard: The problem with an extension function is that it means you can dynamically construct the step and port names.
16:26:03 [Norm]
Henry: If that was the only thing in the way, we could just rule that.
16:26:15 [ht]
s/rule that./rule that out./
16:26:29 [Norm]
Richard: I disliked this before because it made it harder to see the flow of documents through the pipeline.
16:26:44 [Norm]
Richard: As long as you can figure out where the pipes go at compile time, I could live with it.
16:27:22 [Norm]
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 [ht]
s/defaults of context/defaults to context/
16:28:55 [Norm]
Norm: With my chair's hat on, I have to question the size of this change?
16:29:39 [Norm]
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 [Norm]
...Maybe it is a big enough problem that we really do need to reconsider it.
16:30:27 [Norm]
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 [Norm]
...It effectively changes your ability to read off the data flow of a pipeline from its input port elements.
16:31:47 [Norm]
...Extension functions have semantics that go way beyond the problem we were trying to solve.
16:32:13 [Norm]
...I'm back to thinking we should go with option 2 and discuss the name of the element at another time.
16:33:17 [Norm]
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 [Norm]
...We're going to have different names for these things.
16:35:22 [Norm]
Alex: Couldn't we just have an input without a port attribute?
16:35:29 [Norm]
Henry: That's just too complex for users.
16:36:20 [Norm]
Henry: Option 2 spells a special case with a special element name instead of spelling it "input port='source'"
16:36:52 [Norm]
Michael: Looking at the example more carefully, I think you're right. The second option isn't more complex.
16:36:56 [Norm]
...I withdraw the argument.
16:37:50 [Norm]
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 [Norm]
...I still stick at the term "context"
16:40:05 [MSM]
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 [ht]
'context-node' works for me
16:42:52 [Norm]
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 [Norm]
No one did.
16:43:06 [Norm]
Norm: So the question is then, what name? We can always revisit it later.
16:43:23 [MSM]
if we find a different name for what is now called 'context', we can revisit the name of this element.
16:44:39 [Norm]
Norm: The name is left to the editor's discretion, except that "context" is off the table.
16:45:55 [Norm]
Proposed: We will adopt option 2 as described above for the next draft.
16:46:05 [Norm]
16:46:21 [Norm]
Topic: Defaulting
16:46:42 [Norm]
Norm: Henry, you proposed this for the 18th, can you set the stage?
16:46:48 [ht]
16:46:55 [Norm]
Henry: Yes. I had in mind going back to the threads that started in December.
16:46:59 [ht]
16:47:24 [ht]
16:47:47 [Norm]
Henry: I would like to say something like where we ended up in that discussion, editor please draft :-)
16:48:09 [Norm]
Norm: The editor might like somewhat more direction.
16:48:22 [Norm]
Alex: The real crux seems to be dealing with the preceding sibling case.
16:48:45 [Norm]
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]
Norm: I think the draft will be easier to understand if we do it in terms of names.
16:50:15 [Norm]
Henry: I think it's easier to talk about the single input port, regardless of name.
16:50:34 [Norm]
Richard: We could certainly say that if the component only has one input, that's it's default.
16:51:08 [Norm]
Alex: Or we could say that a component declaration indicated its default port.
16:51:41 [Norm]
Richard: I like that.
16:52:33 [Norm]
Some discussion of input ports
16:52:45 [Norm]
Richard: I think you could just say that any unconnected input port is connected to the default.
16:53:38 [Norm]
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 [Norm]
Richard: I can see Alex's point that this would be useful for a graphical tool
16:54:55 [ht]
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 [Norm]
...We could say that you designate one input as primary but that it's not used by the language.
16:55:56 [alexmilowski]
16:56:00 [Norm]
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 [Norm]
...Where the default input is the default output of the preceing sibling or the preceding sibling of the container.
16:56:28 [Norm]
16:57:30 [Norm]
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 [Norm]
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 [Norm]
17:00:21 [Norm]
Topic: Any other business
17:00:40 [Norm]
17:01:29 [Zakim]
17:01:55 [Zakim]
17:01:58 [Zakim]
17:01:59 [Zakim]
17:02:01 [Zakim]
17:02:03 [Zakim]
17:02:18 [Norm]
rrsagent, set logs world visible
17:02:19 [RRSAgent]
I'm logging. I don't understand 'set logs world visible', Norm. Try /msg RRSAgent help
17:02:25 [Norm]
rrsagent, set logs world-visible
17:02:30 [Norm]
rrsagent, draft minutes
17:02:30 [RRSAgent]
I have made the request to generate Norm
17:02:36 [alexmilowski]
alexmilowski has left #xproc
17:07:06 [Zakim]
disconnecting the lone participant, Ht, in XML_PMWG()11:00AM
17:07:11 [Zakim]
XML_PMWG()11:00AM has ended
17:07:13 [Zakim]
Attendees were +1.781.442.aaaa, Norm, Ht, rlopes, richard, Alex_Milowski, AndrewF, MSM
17:07:30 [MSM]
zakim, please excuse us
17:07:30 [Zakim]
Zakim has left #xproc
19:15:19 [Norm]
Norm has joined #xproc
19:38:31 [Norm]
Norm has joined #xproc
20:04:50 [Norm]
rrsagent, pointer
20:04:50 [RRSAgent]
20:15:44 [Norm]
rrsagent, draft minutes
20:15:45 [RRSAgent]
I have made the request to generate Norm