IRC log of xproc on 2006-06-15

Timestamps are in UTC.

15:01:58 [RRSAgent]
RRSAgent has joined #xproc
15:01:58 [RRSAgent]
logging to
15:02:04 [richard]
richard has joined #xproc
15:02:07 [Norm]
Meeting: XML Processing Model WG
15:02:07 [Norm]
Scribe: Norm
15:02:07 [Norm]
ScribeNick: Norm
15:02:07 [Norm]
Date: 15 Jun 2006
15:02:07 [Norm]
Chair: Norm
15:02:08 [Norm]
15:02:08 [Zakim]
15:02:15 [ht]
zakim, [MIT is ht
15:02:15 [Zakim]
+ht; got it
15:02:21 [rlopes]
Zakim, [IP is Rui
15:02:21 [Zakim]
+Rui; got it
15:02:25 [MoZ]
Zakim, what is the code?
15:02:25 [Zakim]
the conference code is 97762 (tel:+1.617.761.6200), MoZ
15:02:27 [Zakim]
15:02:28 [richard]
zakim, ? is richard
15:02:28 [Zakim]
+richard; got it
15:02:54 [Norm]
Norm has changed the topic to: XProc
15:03:13 [Zakim]
+ +
15:03:25 [MoZ]
zakim, aaaa is MoZ
15:03:29 [Zakim]
+MoZ; got it
15:03:30 [Zakim]
15:03:34 [AndrewF]
zakim, ? is AndrewF
15:03:34 [Zakim]
+AndrewF; got it
15:03:54 [Norm]
zakim, who's on the phone?
15:03:54 [Zakim]
On the phone I see Michael, Alessandro, Alex_Milowski, Rui, Norm, ht, richard, MoZ, AndrewF
15:06:26 [Norm]
Present: Michael, Alessandro, Alex, Rui, Norm, Henry, Richard, Mohamed, Andrew
15:06:26 [Norm]
Regrets: Paul
15:06:51 [Norm]
Topic: Accept this agenda?
15:06:51 [Norm]
15:06:58 [Norm]
15:07:12 [Norm]
Topic: Accept minutes from the previous teleconference?
15:07:12 [Norm]
15:07:22 [Norm]
15:07:29 [Norm]
Topic: Accept minutes from the previous teleconference?
15:07:29 [Norm]
15:07:39 [Norm]
15:07:41 [Norm]
Topic: Next meeting: 22 June telcon
15:07:41 [Norm]
Any regrets?
15:07:49 [MoZ]
me too
15:08:23 [Norm]
Norm, Michael, Mohamed, Andrew
15:09:03 [Norm]
Henry to chair
15:09:12 [Norm]
Topic: Face-to-face: 2-4 Aug 2006.
15:09:18 [Norm]
Register and report your plans to Murray
15:09:31 [Norm]
Topic: Review of open action items
15:09:47 [Norm]
A-13-01: MSM to draft a complete table; ETA: 15 June 2006
15:10:14 [Norm]
15:10:38 [Norm]
ETA: 20 July 2006
15:10:42 [Norm]
A-23-02: Richard to write a syntax proposal
15:10:45 [Norm]
15:10:52 [Norm]
A-23-03: Norm to write a syntax proposal
15:10:54 [Norm]
15:11:05 [Norm]
A-23-02 Continues
15:11:52 [Norm]
Topic: XProc syntax
15:12:49 [Norm]
Richards email: ->
15:12:56 [Norm]
15:13:20 [Norm]
Richard summarizes his message.
15:14:31 [Norm]
Richard: The end of that message shows a description of components that a processor could use to check that the pipeline was connected together correctly.
15:15:24 [Norm]
Richard: Rather than making up names for each output of each step, I use the name of the step and the name of input or output from that component.
15:16:33 [Norm]
Richard: There's a single param named xslt-params that would use a small syntax that we'd have to make up.
15:16:48 [MSM]
Richard, are you particularly attached to using '.' as the separator?
15:17:00 [Norm]
Norm: Taking some of these ideas in reverse order, I hope we can do better with the parameters to for example XSLT
15:17:50 [Norm]
Richard: I agree it's not very nice, we can certainly do it better. However, we'll need something like this in general for other components, even if we do something special for XSLT.
15:18:23 [Norm]
Henry: I thought we had an emerging consensus that we'd have some parameter that could take a bag of name/value pairs.
15:18:57 [ht]
Not what I said, Norm
15:19:15 [Norm]
Richard: The fact that there are things in XSLT that are called parameters and that they coincide with pipeline parameters is something of a coincidence.
15:19:23 [ht]
<with-param name="foo" value="baz"/>
15:19:35 [Norm]
Henry: Not what I said. I thought there would never be a constraint on how many of these you'd include in a step.
15:19:43 [alexmilowski]
I've been thinking the same way too...
15:20:17 [Norm]
Henry: Any component that had a notion of parameters could use that
15:20:55 [Norm]
Richard: It's possible that there would be program parameters and stylesheet parameters that could have name collisions.
15:21:21 [MoZ]
where do we put, for example java parameters (-Xmx) ?
15:21:28 [Norm]
Richard: Some XSLT processors have an "input" parameter for the input document. What if the stylesheet also has a parameter named "input"?
15:22:25 [Norm]
Henry: It seems to me that the 80/20 point is to say that a parameter that has a signature in the component definition, then that's what it is. But if you find another parameter, then that's passed to the application.
15:22:31 [MSM]
Richard, in your example that seems to be handled / handleable by passing the *pipeline* input (pipeline stdin, so to speak) using 'with-input' rather than 'with-parameter' -- so I'm not sure I grok the problem
15:22:48 [Norm]
Richard: I'm not sure I'm happy with having those two things completely undistinguished. If you mistype a name, the compiler can't tell.
15:22:57 [Norm]
Henry: It sounds like maybe we should have two element names.
15:23:12 [Norm]
Richard: Yes, we should try to devise a more user-friendly syntax.
15:24:05 [Norm]
Alex: A general rule of saying that there's an arbitrary number of parameters works for XSLT. The same is likely to be true for the pipeline itself. It's a good general mechanism.
15:24:14 [Norm]
Alex: I don't see the harm in having extra parameters.
15:25:25 [Norm]
Norm observes that we might easily be able to do better.
15:25:43 [ht]
HST: I think we do indeed need to use the signature to specify required/expected parameters
15:26:13 [Norm]
Norm: Richard's example also gives us an easy starting point for a discussion of how inputs and outputs are named.
15:26:27 [ht]
... And we could put in the signature whether or not a component supports arbitrary name/value parameters, as e.g. XSLT
15:26:32 [Norm]
Richard: It's a notable feature that you don't list anything about the outputs of a component. Which is a bit asymetrical.
15:26:50 [MSM]
[msm likes both the flexibility of passing unexpected parameters without an error and the cleanliness of getting a warning if you do so by accident, likes a --pedantic flag for that reason]
15:27:06 [Norm]
Richard: but it probably has to be asymetrical.
15:27:45 [Norm]
Richard: Henry wants to be able to not specify any inputs or outputs in a simple pipe. We can do that by having a component definition mark one input and one output as the primary inputs and outputs.
15:28:08 [Norm]
Michael: Richard, are you saying that the reason it looks asymetric is the example?
15:28:43 [Norm]
Richard: No. The mention of the inputs is to connect them to the outputs. There's no point connecting the outputs to the inputs if you've already connected the inputs to the outputs.
15:28:58 [Norm]
Michael: Yes. An arc can be specified from either end and you don't need to do both.
15:29:12 [MSM]
(of course, some people wear a belt with their suspenders)
15:29:46 [Norm]
Norm: The only part of this that bothers me a little bit is that you can't tell what the pipeline is doing if you don't also have in hand the component vocabulary.
15:30:00 [Norm]
Richard: That's sort of true.
15:30:09 [MSM]
can you expound? not sure what 'having the component vocabulary in hand' means
15:30:54 [Norm]
Norm tries
15:31:13 [MoZ]
+1 for beeing explicit
15:31:35 [Norm]
Norm: There's a fairly straightforward choice to be made here. We can name the inputs and outputs individually in each step or we can use an approach like Richard has outlined.
15:32:10 [Norm]
Norm: Does anyone feel strongly about what is the right answer?
15:32:23 [Norm]
HT: "Strong" might be too strong, but I'm inclined to do it Richard's way.
15:33:32 [Norm]
HT: There's probably not much support for a real two-level proposal with two syntaxes. The alternative, which is a medium level language with lots of defaulting, is probably more likely. Richard's approach is well suited to that story.
15:34:17 [Norm]
Richard: Imagine taking my syntax and adding with-output to it.
15:34:47 [Norm]
Richard: Then imagine that this with-output is optional, and a default name is generated for you but you can specify a different one i fyou'd like.
15:35:02 [ht]
HST would like to perform s/with-// on Richard's example
15:35:23 [Norm]
Norm: I think it would make two different variants and we should avoid that if we can.
15:35:40 [Norm]
Richard: I'm inclined to agree with HST that we should remove "with-"
15:36:05 [Norm]
Richard: In the components, you just say what the inputs and outputs are.
15:36:18 [MoZ]
we must have distinction between calling of step and definition of step
15:36:44 [Norm]
Richard: But consider the pipeline program itself. Where it says <output name="result"> it's both defining that it has such an output and declaring what it's connected to. This will happen also in conditional and switch expressions.
15:37:17 [Norm]
Richard: Given that, the distinction between input and with-input is slightly less meaningful because of that. Unless you make people specify both, which would be unnaturally verbose.
15:37:42 [Norm]
Richard: We should just call them "input" and "output" in both places, and accept that sometimes it serves one, sometimes the other, and sometimes both purposes.
15:38:46 [Norm]
Norm agrees, after some exploration of his own difficulties with conditionals.
15:39:37 [Norm]
Richard: Another thing raised by that is that if we allow conditionals to do XPath tests against their inputs, we can no longer list all the inputs to the "if" component.
15:39:58 [Norm]
Richard: And if we allow "param" to evaluate XPath expressions, that becomes true of all the components.
15:40:19 [Norm]
Richard: It's rather analagous to the parameter case we were discussing earlier.
15:40:30 [ht]
15:40:30 [ht]
<when test="/root/@version < 3.0">
15:40:30 [ht]
<step process="xsdValidate">
15:40:30 [ht]
<input name="schemaDoc" href="stale.xsd"/>
15:40:30 [ht]
15:40:31 [ht]
15:40:33 [ht]
15:40:35 [ht]
<step process="xsdValidate">
15:40:37 [ht]
<input name="schemaDoc" href="current.xsd"/>
15:40:39 [ht]
15:40:41 [ht]
15:40:43 [ht]
15:41:06 [Norm]
HT: Those difficulties with conditionals makes me think we shouldn't allow those things in V1
15:41:51 [Norm]
Alex: This is related to my concept of a straight-through "pipe"
15:42:46 [Norm]
Norm asks about how to do HSTs example with two inputs.
15:43:01 [Norm]
HT: I'd write this instead:
15:43:10 [ht]
<input name="schemaDoc" from="foo.result"/>
15:43:33 [alexmilowski]
With <choose><input ref="foo.result"/> ...</choose>
15:43:36 [Norm]
Richard: Norm's point is that this allows the choose step to refer to arbitrary parts outside the step.
15:43:51 [Norm]
HT: Choose is a language construct not a component.
15:44:27 [Norm]
Richard: There are much more substantial problem with outputs from the choose. If things outside can reach back into the choose, then it becomes pervasive.
15:44:50 [Norm]
...Allowing inputs inside a choose to reach out but not allowing things outside reach in might work.
15:45:01 [Norm]
HT: All the branches of a choose have to have the same output cardinality.
15:45:16 [Norm]
Richard: In my example, you'd have to have exactly one output.
15:45:36 [Norm]
...OTOH, if you say that choose is like pipeline, and declares its own inputs and outputs, then you can do more.
15:46:18 [Norm]
Norm: My inclination is to have choose declare its inputs and outputs and then for the processor to make sure every branch produces the right outputs.
15:47:21 [Norm]
HT: Choose is a language construct, parallel with pipeline and not with component.
15:47:33 [Norm]
Richard: I think there's much to be said for saying that it's equivalent to a pipeline in some way.
15:49:17 [Norm]
HT: The way a pipeline works in Richard's syntax, the pipeline output names a step output to hook up to.
15:49:21 [Norm]
...That won't work for the choose.
15:49:43 [Norm]
Richard: Each branch is like a pipeline in that respect. But perhaps the surrounding choose is also like a pipeline.
15:49:56 [Norm]
HT: I don't think the inputs buys us anything.
15:50:42 [Norm]
Richard: I see your point, and it would be more convenient from the users point of view, but I would still like the choose to be equivalent to the pipeline.
15:51:38 [Norm]
Richard: The "choose" somehow has to define that all the branches have the same outputs. For each branch, you have to connect the output of branch to the output of the conditionals.
15:51:46 [Norm]
HT: They're going to be pushing not pulling.
15:52:13 [Norm]
Richard: What you could say is that a conditional construct declares the pipelines that must be in it. Then the branches are like pipelines that have already been declared.
15:52:17 [Norm]
Norm: I'm not sure I followed that.
15:53:59 [Norm]
Norm: Are we coming to consensus on the naming?
15:54:11 [Norm]
MSM: It depends on the separator.
15:54:40 [Norm]
I think the answer is yes.
15:55:25 [Norm]
Richard: I thought there was pushback later...
15:55:29 [Norm]
15:55:46 [Norm]
Richard: If we imagine that with-output is optional, then we could change our minds later without having any pervasive effect.
15:56:17 [Norm]
Topic: Any other business?
15:56:27 [MoZ]
Happy birthday for tomorrow Norm
15:56:31 [Norm]
15:56:51 [Zakim]
15:56:54 [Zakim]
15:56:55 [Zakim]
15:56:56 [Zakim]
15:56:56 [Zakim]
15:56:59 [Zakim]
15:57:02 [Zakim]
15:57:02 [Norm]
rrsagent, please make logs world-visible
15:57:06 [Zakim]
15:57:07 [Norm]
rrsagent, please draft minutes
15:57:07 [RRSAgent]
I have made the request to generate Norm
15:57:20 [Zakim]
15:57:20 [Zakim]
XML_PMWG()11:00AM has ended
15:57:21 [Zakim]
Attendees were [MIT528], Michael, [IPcaller], Alessandro, Alex_Milowski, Norm, ht, Rui, richard, +, MoZ, AndrewF
15:57:26 [alexmilowski]
alexmilowski has left #xproc
17:31:38 [Zakim]
Zakim has left #xproc
17:31:57 [Norm]
rrsagent, bye
17:31:57 [RRSAgent]
I see no action items