IRC log of xproc on 2006-02-23

Timestamps are in UTC.

15:29:28 [RRSAgent]
RRSAgent has joined #xproc
15:29:28 [RRSAgent]
logging to
15:30:32 [Norm]
Meeting: XML Processing Model WG
15:30:32 [Norm]
Scribe: Norm
15:30:32 [Norm]
ScribeNick: Norm
15:30:32 [Norm]
Date: 23 Feb 2006
15:30:32 [Norm]
Chair: Norm
15:30:33 [Norm]
15:30:44 [Norm]
Norm has changed the topic to: XProc:
15:52:17 [Alessandro]
Alessandro has joined #xproc
15:57:13 [Norm]
zakim agenda+ Administrivia
15:57:26 [Norm]
zakim agenda+ Technical
15:58:13 [rlopes]
rlopes has joined #xproc
15:59:46 [alexmilowski]
alexmilowski has joined #xproc
16:00:16 [Norm]
zakim, who's on the phone?
16:00:16 [Zakim]
sorry, Norm, I don't know what conference this is
16:00:18 [Zakim]
On IRC I see alexmilowski, rlopes, Alessandro, RRSAgent, Zakim, Norm, ht
16:00:21 [Norm]
zakim, this is xproc
16:00:21 [Zakim]
ok, Norm; that matches XML_PMWG()11:00AM
16:00:23 [Norm]
zakim, who's on the phone?
16:00:23 [Zakim]
On the phone I see [IPcaller], Norm
16:00:29 [AndrewF]
AndrewF has joined #xproc
16:00:31 [ht]
zakim, please call ht-781
16:00:32 [Zakim]
ok, ht; the call is being made
16:00:33 [Norm]
zakim, [IPcaller is rlopes
16:00:35 [Zakim]
16:00:37 [Zakim]
+rlopes; got it
16:00:45 [richard]
richard has joined #xproc
16:01:32 [Zakim]
16:01:34 [Zakim]
16:01:43 [Zakim]
16:02:00 [Norm]
zakim, ??P31 is AndrewF
16:02:00 [Zakim]
+AndrewF; got it
16:02:06 [Zakim]
16:02:47 [Norm]
zakim, who's here?
16:02:47 [Zakim]
On the phone I see rlopes, Norm, Ht, Alessandro_Vernet, Alex_Milowski
16:02:48 [Zakim]
On IRC I see richard, AndrewF, alexmilowski, rlopes, Alessandro, RRSAgent, Zakim, Norm, ht
16:03:08 [Zakim]
16:03:22 [Norm]
zakim, ??P39 is AndrewF
16:03:22 [Zakim]
+AndrewF; got it
16:03:58 [Zakim]
16:03:59 [richard]
zakim, ? is richard
16:04:01 [ebruchez]
ebruchez has joined #xproc
16:04:05 [Zakim]
+richard; got it
16:04:31 [Norm]
16:04:41 [Norm]
16:05:01 [Norm]
zakim, who's on the phone?
16:05:08 [Zakim]
On the phone I see rlopes, Norm, Ht, Alessandro_Vernet, Alex_Milowski, AndrewF, richard
16:05:26 [Zakim]
16:05:36 [Norm]
zakim, [IPcal is ebruchez
16:05:39 [Zakim]
+ebruchez; got it
16:06:03 [Norm]
Present: Alessandro, Alex, Andrew, Erik, Henry, Norm, Richard, Rui
16:06:11 [Norm]
Regrets: Paul, Robin, Michael
16:06:27 [Norm]
zakim, next agendum
16:06:27 [Zakim]
I see nothing on the agenda
16:06:35 [Norm]
zakim agenda+ Administrivia
16:06:40 [Norm]
zakim agenda+ Technical
16:06:56 [Norm]
zakim, next agendum
16:06:59 [Zakim]
I see nothing on the agenda
16:07:22 [Norm]
Topic: Administrivia
16:07:37 [Norm]
Alex points to the latest requirements document:
16:07:45 [Norm]
Topic: Accept this agenda?
16:07:45 [Norm]
16:08:03 [Norm]
16:08:07 [Norm]
Topic: Accept minutes from the previous teleconference?
16:08:07 [Norm]
16:08:13 [Norm]
16:08:18 [Norm]
Topic: Next meeting: 27/28 Feb at the technical plenary.
16:08:56 [Norm]
Room 157 at the Royal Casino Hotel
16:09:13 [Norm]
Henry reminds us that there's a wiki for ride sharing
16:09:51 [ebruchez]
16:10:09 [ht]
16:10:16 [ebruchez]
Wrong link
16:10:17 [ebruchez]
16:10:45 [Norm]
Topic: Agenda planning for the face-to-face
16:10:45 [Norm]
16:11:39 [Norm]
Who's willing to speak about exisitng tools?
16:11:40 [Norm]
16:11:42 [Norm]
16:11:52 [Norm]
16:11:57 [Norm]
16:12:37 [Norm]
Andrew will send a summary of the Arbortext pipeline
16:12:38 [Norm]
16:12:44 [Norm]
16:14:49 [Norm]
Norm reviews the rest of the planned agenda
16:14:50 [ebruchez]
all good
16:15:23 [Norm]
Andrew would like the presentations to be in the afternoon because he'll be calling in
16:16:06 [Norm]
I'll move it to the afternoon
16:17:03 [Norm]
Monday morning: administriva and use cases
16:17:15 [Norm]
Monday afternoon: presentations and infoset input/output discussoin
16:17:46 [Norm]
Norm will update the agenda
16:18:46 [Norm]
Norm to add note about asking in IRC for phone connectivity
16:19:19 [Norm]
Topic: Technical
16:19:29 [Norm]
Requirements and use cases.
16:19:50 [Norm]
Alex: Changes from last week: make validation a design principle a design principle; removed naming of pipelines as a requirement
16:20:08 [Norm]
Alex: No more editorial changes.
16:20:20 [Norm]
Alex: We were working our way through issues on the list.
16:20:49 [Norm]
Norm asks for explanation of the table at the beginning of section 4
16:21:12 [Norm]
Alex: It's supposed to map requirements to use cases. The presentation doesn't work but it's saying that for each requirement, here's the use case that supports that requirement.
16:21:31 [Norm]
Alex: I wanted to get rid of having the links in the requirements list so that they would be easier to read.
16:21:48 [Norm]
Alex: The presentation needs to be fixed.
16:24:09 [Norm]
Alex: I'm not really concerned about the presentation right now, just as long as we get the content in place.
16:24:14 [Norm]
Norm: +1
16:25:30 [Norm]
Norm: One issue that I thought we could talk about is the issue of string paramer or simple datatype parameters as opposed to infoset parameters.
16:26:14 [Norm]
Norm observes that the last word on this thread was from Erik.
16:26:29 [Norm]
Erik: We didn't have many use cases that required parameters so we didn't mind using a little trick for XSLT
16:26:40 [Zakim]
16:27:02 [Norm]
Henry: I think we have a terminology problem, the example is full of parameters!
16:27:20 [Norm]
Erik: I think the distinction is between infosets and datatype parameters.
16:27:56 [Norm]
Erik: The question is do we need to kinds of parameters in the language to be able to do this?
16:28:15 [Norm]
Erik: If we decide we can only pass XML infosets between components, then how do you pass a numeric parameter to a stylesheet?
16:28:49 [ht]
q+ to distinguish at least three cases
16:28:49 [Norm]
Richard: Ok, so this is a small subset of the parameter problem. You're talking about parameters that come from other components, rather than parameters that are specified when you write the pipeline?
16:29:00 [Norm]
Erik: Why should parameters only be static?
16:29:51 [Norm]
Richard: I can see that that's a good generalization, but in my pipeline virtually every step has some parameters, but none of them are derived from previous steps.
16:29:58 [Norm]
Erik: Maybe it depends what you call parameter.
16:30:07 [Norm]
Richard: The sort I'm talking about are XPaths to identify bits of a document
16:30:10 [Norm]
16:30:31 [Norm]
Alex: My pipelines run in a J2EE environment, so I'm passing all sorts of stuff to the pipeline.
16:31:15 [Norm]
ack ht
16:31:15 [Zakim]
ht, you wanted to distinguish at least three cases
16:31:31 [Norm]
Henry: It's clear that we're talking a little bit at cross-purposes
16:32:00 [Norm]
Henry: I can see at least three cases: there are things that I think of as parameters that are static, pipeline-design time XML resources: stylesheets for XSLT or schema documents for validation.
16:32:51 [Norm]
Henry: The second class are design-time controls for components: XPaths, etc. I agree with Richard that the 99% case is that that's known at pipeline-design time. It's a static parameter.
16:33:37 [Norm]
Henry: Another case is command line switches to command line invocations: switches with values and booleans, switches that are either present or absent. An XInclude impl could have a command-line switch that indicated whether or not base fixup is applied.
16:33:44 [Norm]
Henry: That's another example of a design-time choice.
16:34:07 [Norm]
Henry: The third case is runtime parameterization that gets accessed by various components at run time.
16:34:36 [Norm]
Some discussion of what Alex meant.
16:35:04 [Norm]
Henry: I think the point about the third class is that they often go hand-in-hand with the second case.
16:35:14 [richard]
If your pipeline is compiled, then Alex's examples are parameters whose values are not known at compile time
16:35:20 [Norm]
Henry: Often you have a slot in the pipeline at design time and a run-time parameter that fills that slot.
16:36:11 [Norm]
Norm: design-time parameters in the pipeline, design-time controls for components, run-time parameters passed to the pipeline.
16:36:16 [Norm]
Norm: those are the three cases?
16:36:27 [ht]
HST distinguished between static resources (stylesheets, schema documents)
16:36:54 [Norm]
Henry: I think it's useful to distinguish between those and others.
16:37:34 [Norm]
Norm: I think a third case is parameters that come out of one component and flow into another.
16:37:57 [Norm]
Norm: In the full generality, those could be any kind of parameter, but I've been thinking of those only in terms of infosets.
16:38:37 [Norm]
Richard: One way to deal with it would be to have an XML document that contains the parameters and then that could be generated by a stage in the pipeline.
16:38:41 [Norm]
16:38:48 [Norm]
ack ebruchez
16:38:48 [Zakim]
ebruchez, you wanted to discuss using XML infosets to do that or the XDM
16:39:10 [Norm]
Erik: I just wanted to point out that there's some conceptual simplifications that could be made.
16:39:39 [Norm]
Erik: For example, when I hear of a stylesheet or schema as a parameter, I know that in many cases that's static, but you can also simplify it by saying that they're both XML documents and you can combine them.
16:39:42 [richard]
16:39:54 [Norm]
Erik: You can just consider an XSLT stylesheet or a schema is just an infoset.
16:40:07 [Norm]
Erik: In XPL we've been trying to maximize this simplification.
16:40:13 [alexmilowski]
q+ parameter binding
16:40:40 [Norm]
ack parameter
16:40:41 [Norm]
ack binding
16:40:44 [Norm]
q+ alex
16:40:56 [ht]
HST likes the idea that follows from merging Richard's suggestion with Norm's resource pool idea: Provide an name:value store as part of the pipeline engine, which can be set a) at pipeline invoication; b) via a pseudo-output URI and a standardised XML document; via the engine API as it faces the components
16:41:01 [Norm]
Erik: This way you don't need to switch between concepts. We should try to keep that simplification in mind.
16:41:24 [alexmilowski]
alexmilowski has left #xproc
16:41:26 [alexmilowski]
alexmilowski has joined #xproc
16:41:34 [Norm]
Erik: If we use the XDM data model then the whole question becomes simpler because we can just pass around XDM simple types.
16:41:44 [Norm]
16:42:15 [Norm]
Erik: In XPL since we only have infosets, when we need to pass the user principle, we encapsulate it all in an XML infoset. So most components take an XML infoset as a configuration.
16:42:21 [Norm]
I think this is what Henry was suggesting a few moments ago
16:42:48 [Norm]
Henry: no, actually not.
16:42:50 [Norm]
ack richard
16:43:41 [Norm]
Richard: I agree that Erik's simplification is good, I just don't want it to make the simple case where you have a static stylesheet or schema more complex or inefficient.
16:43:45 [Norm]
Richard: So if we can keep the generality without precluding optimization, I'm all for it.
16:44:23 [Norm]
Erik: There are ways to avoid the optimization problems.
16:44:24 [Norm]
ack alex
16:44:33 [Norm]
Alex: I feel really strongly that simple things should be simple.
16:45:00 [Norm]
Alex: If I have a simple string and I need to assign it to a name so that some component can access it, turning it into an XML resource seems really hard.
16:45:46 [ht]
HST strongly endorses this, even if all it means is that the XML _syntax_ for pipeline authoring makes it transparent
16:45:47 [Norm]
Alex: We need a simple way to bind simple values to names
16:46:12 [Norm]
Erik: Alex, I think that's fine when you just write them statically. It's where you want to generate them that it becomes problematic.
16:46:38 [Norm]
Erik: I think you're going to have to have a way to allow a component to generate a parameter for some other component.
16:46:49 [ht]
q+ to remind ourselves about using the infoset for this . . .
16:47:25 [Norm]
Alex: I think if we could come to agreement that there are parameters and resources, that would be good. Being able to formally declare a dependency on a resource is a good thing.
16:47:29 [Norm]
16:48:07 [Norm]
Alex: That means that you have the use case of generating something in the middle of a pipeline that is a parameter. But that's a sepearate problem and we can decide if that's possible separately.
16:48:08 [Norm]
ack ht
16:48:08 [Zakim]
ht, you wanted to remind ourselves about using the infoset for this . . .
16:48:19 [Norm]
q+ murray
16:48:55 [Norm]
Henry: Just to add to the dimensionalities we're thinking about, I think there's an important distinction between parameterizations of components on the one hand and out-of-band computed information on the other.
16:49:23 [Norm]
For out-of-band computed information, the infoset is your friend. For example, what do you do with an XSLT step in the middle of a pipeline which sets the output encoding?
16:49:28 [Norm]
s/For /
16:49:35 [Norm]
s/For out/Henry: For out/
16:49:55 [Norm]
Henry: You put an annotation in the ...where... so that the information is available when you need to serialize it.
16:50:07 [ebruchez]
You may also want to completely separate serialialization in pipelines.
16:50:18 [Norm]
Henry: What's interesting is that it's not information for the next step, it's for someone else later.
16:50:30 [Norm]
Henry: Infoset annotations are the way to go here.
16:50:52 [Norm]
Murray: I liked Henry's characterization of the three different kinds of parameters.
16:51:09 [Norm]
Murray: I'm a pipeline processor, I have a blank mind. Once things get going, I start to become aware of stuff.
16:51:11 [ht]
16:51:25 [Norm]
Murray: I want to be able to store that away so that I can use it later.
16:51:46 [Norm]
Murray: Some of it is in files that I can assign URIs to, and some of it is in memory (which might also have URIs). I can build this little environment.
16:51:58 [Norm]
Murray: I might be operating many components and there might be an arbitrary number of steps.
16:52:18 [Norm]
Murray: Along the way, I'm going to have to calculate things. For example, processing a book might require multiple passes to get all the page numbers correct.
16:52:38 [Norm]
Murray: I might store the infoset for the ToC somewhere, then later when I know the page numbers, I might want to edit it.
16:52:58 [Norm]
Murray: Then later, I might grab that and actually use it to build a PostScript rendering of the ToC.
16:53:12 [ht]
HST observes this connects up with Norm's pool idea, understood as a little local filesystem
16:53:16 [Norm]
Murray: Then later still, I might build an online version of that ToC.
16:53:30 [Norm]
Norm agrees with HST, but is frightened of mutable infosets.
16:53:32 [ht]
each instance of the pipeline starts with an empty disk, as it were
16:53:50 [Norm]
Murray: When the job ends, I go back to having a blank mind. Maybe some of my stuff is stored, maybe it isn't.
16:54:08 [Norm]
Murray: All of these things are resources that are created as we go (or before we start).
16:54:09 [alexmilowski]
mid-pipeline binding of parameters is something I do all the time...
16:54:22 [alexmilowski]
16:54:28 [ebruchez]
It's called a variable ;-)
16:54:47 [Norm]
ack murray
16:54:49 [Norm]
ack alexmilowski
16:54:53 [ht]
MT Pipeline does the same thing as XPL here, using no-URI fragments to identify such local resources, e.g. #tempDoc
16:55:15 [Norm]
Alex: I'm with you Murray, I think the problem we're having is with the distinction between parameters and infosets.
16:55:32 [Norm]
Murray: But aren't they all resources?
16:55:53 [Norm]
Murray: If I say "-j Alex", if that value needs to be assigned, somehow I have to be able to reference that value.
16:56:41 [Norm]
Alex: I think it's useful to treat the infosets differently, but maybe there's room for debate on that. I think there should be simple parameter values too.
16:57:05 [Norm]
Alex: They're all resources philosophically, but lots of processors have a distinction betwen "the input" and parameters that are sent to them.
16:57:17 [Norm]
Alex: Look at the Java components that wrap up XSLT for example.
16:57:43 [Norm]
Norm: The Java/XSLT case might be useful to consider.
16:58:38 [ebruchez]
It's a push vs. pull, in a way.
16:58:56 [ebruchez]
XSLT's source is pulled by the transformer, and the other parameters are set in advance.
16:59:04 [ebruchez]
Not sure if that has to hold though.
16:59:29 [alexmilowski]
the parameters do not have to set in advance
17:00:14 [Norm]
17:00:18 [Zakim]
17:00:20 [Zakim]
17:00:21 [alexmilowski]
alexmilowski has left #xproc
17:00:22 [Zakim]
17:00:23 [Zakim]
17:00:24 [Zakim]
17:00:25 [Zakim]
17:00:26 [Zakim]
17:00:28 [Zakim]
17:00:28 [rlopes]
rlopes has left #xproc
17:00:29 [Zakim]
17:00:30 [Zakim]
XML_PMWG()11:00AM has ended
17:00:32 [Zakim]
Attendees were [IPcaller], Norm, Ht, rlopes, Alessandro_Vernet, Alex_Milowski, AndrewF, richard, ebruchez, Murray_Maloney
17:04:46 [Norm]
rrsagent, draft minutes
17:04:46 [RRSAgent]
I have made the request to generate Norm
17:07:18 [Norm]
rrsagent, make minutes public
17:07:18 [RRSAgent]
I'm logging. I don't understand 'make minutes public', Norm. Try /msg RRSAgent help
17:07:27 [Norm]
rrsagent, make minutes world-readble
17:07:27 [RRSAgent]
I'm logging. I don't understand 'make minutes world-readble', Norm. Try /msg RRSAgent help
17:07:29 [Norm]
rrsagent, make minutes world-readble
17:07:29 [RRSAgent]
I'm logging. I don't understand 'make minutes world-readble', Norm. Try /msg RRSAgent help
17:07:31 [Norm]
rrsagent, make minutes world-readable
17:07:31 [RRSAgent]
I'm logging. I don't understand 'make minutes world-readable', Norm. Try /msg RRSAgent help
17:07:35 [Norm]
17:07:53 [Norm]
rrsagent, set logs world-visible
17:07:58 [Norm]
17:38:22 [Norm]
zakim, bye
17:38:22 [Zakim]
Zakim has left #xproc
17:38:24 [Norm]
rrsagent, bye
17:38:24 [RRSAgent]
I see no action items