16:02:29 <RRSAgent> RRSAgent has joined #xproc
16:02:29 <RRSAgent> logging to http://www.w3.org/2007/02/22-xproc-irc
16:02:38 <Zakim> +Norm
16:02:45 <Zakim> +Alessandro_Vernet
16:03:00 <MoZ> Zakim, who is here ?
16:03:00 <Zakim> On the phone I see MSM, rlopes, MoZ, Norm, Alessandro_Vernet
16:03:01 <Zakim> On IRC I see RRSAgent, alexmilowski, Alessandro, rlopes, Norm, Zakim, MoZ, ht, MSM
16:03:06 <Zakim> +Alex_Milowski
16:03:11 <Norm> Meeting: XML Processing Model WG
16:03:11 <Norm> Date: 22 Feb 2007
16:03:11 <Norm> Agenda: http://www.w3.org/XML/XProc/2007/02/22-agenda.html
16:03:11 <Norm> Meeting number: 56, T-minus 36 weeks
16:03:11 <Norm> Chair: Norm
16:03:12 <Norm> Scribe: Norm
16:03:14 <Norm> ScribeNick: Norm
16:03:38 <Zakim> +Murray_Maloney
16:03:50 <MoZ> ScribeChair: Norm
16:04:42 <Norm> zakim, who's on the phone?
16:04:42 <Zakim> On the phone I see MSM, rlopes, MoZ, Norm, Alessandro_Vernet, Alex_Milowski, Murray_Maloney
16:04:58 <Norm> Present: Michael, Rui, Mohamed, Norm, Alessandro, Alex, Murray
16:05:01 <Norm> Regrets: Paul
16:06:48 <Norm> alexmilowski, your VoIP is a bit noisy
16:08:02 <alexmilowski> yes... bad DSL connection...
16:08:09 <Norm> Topic: Accept this agenda?
16:08:09 <Norm> -> http://www.w3.org/XML/XProc/2007/02/22-agenda.html
16:08:14 <Norm> Accepted.
16:08:18 <alexmilowski> I'm getting a wimax connection soon...
16:08:19 <Norm> Topic: Accept minutes from the previous meeting?
16:08:19 <Norm> -> http://www.w3.org/XML/XProc/2007/02/15-minutes.html
16:08:28 <Norm> Accepted.
16:08:34 <Norm> Topic: Next meeting: telcon 1 Mar 2007
16:08:55 <Norm> No regrets given
16:09:12 <Norm> Topic: Components that act as interfaces to multiple applications
16:10:32 <Norm> Mohamed: Today we have p:xslt and p:validate. Do we want to have one for each technology or one for all? The problem I see is that the answer won't be so simple.
16:10:43 <MSM> "one for each" vs. "one for all" - nice formulation of the choice.
16:10:54 <Norm> ...Suppose we say we have p:validate, then we can defer the fact that some may be core and some may not.
16:11:13 <Norm> ...But if we say we have to have specific names, then we need to fix the list as soon as possible.
16:11:20 <Norm> ...It will be difficult to come to it later.
16:11:28 <Norm> Norm: What's "it"?
16:11:38 <Norm> Mohamed: The question of the list of what is in the core and what is not.
16:12:09 <alexmilowski> (currently, we don't have "p:transform"... we have "p:xslt")
16:13:30 <Norm> Mohamed: We'll be able to defer the specifics to later.
16:14:09 <alexmilowski> q+
16:14:16 <Norm> ...I fear that the fact we will have to define each element in detail will make us lazy.
16:14:29 <Norm> ack alexmilowski 
16:14:45 <MSM> [so we'll end up with a much smaller set of components, just to reduce our own work load]
16:15:47 <Norm> Alex: I think that the problem is the same. Either the names are available as step types or they're available as step names. Either way we have to define them all. And pipeline library developers can always add more. We need to enumerate our list of components in either case.
16:16:17 <Norm> Straw poll: Shall we have components that act as interfaces to multiple applications?
16:16:40 <MSM> msm: no
16:16:41 <MSM> rui: no
16:16:44 <MSM> moz: yes
16:16:52 <MSM> ndw: no
16:16:55 <MSM> Alessandro: no
16:16:58 <MSM> Alex: no
16:17:01 <MSM> Murray: concur
16:17:13 <Norm> Results: 6:1 against.
16:17:19 <richard> richard has joined #xproc
16:17:41 <Norm> Norm: We will not have components that act as interfaces to multiple applications.
16:17:58 <Zakim> +??P2
16:18:01 <richard> zaim, ? is me
16:18:03 <richard> zakim, ? is me
16:18:03 <Zakim> +richard; got it
16:19:26 <Norm> Mohamed: In the examples there is a p:validate, so what is it's meaning in the spec.
16:19:54 <Norm> Norm: Do you think that component does multiple kinds of validation?
16:20:06 <Norm> Mohamed: Yes, I think so. We at least infer multiple interfaces.
16:20:12 <alexmilowski> (anyone can write a custom component that supports multiple schema languages at once)
16:20:56 <Norm> Topic: Step names
16:21:40 <Norm> Norm: Any further discussion before I attempt a straw poll?
16:21:43 <Norm> None heard
16:22:17 <Norm> Straw poll: Shall we identify steps with the form "<p:step type='p:xslt'>" or with the form "<p:xslt>"
16:22:30 <Norm> zakim, who's on the phone?
16:22:30 <Zakim> On the phone I see MSM, rlopes, MoZ, Norm, Alessandro_Vernet, Alex_Milowski, Murray_Maloney, richard
16:23:04 <Norm> Mohamed: So we'll have both?
16:23:06 <Norm> Norm: No
16:23:19 <Norm> Murray: Oh, I thought we'd further allow p:xslt but we'd still have p:step.
16:23:26 <Norm> Norm: Why two ways?
16:23:43 <alexmilowski> q+
16:23:53 <Norm> Murray: That's a deeper question. I thought we'd still want the p:step way, but I take it back.
16:23:57 <Norm> ack alexmilowski 
16:24:17 <Norm> Alex: I think in the spec we'll define some sort of abstract p:step type in the spec.
16:24:27 <richard> q+
16:24:34 <Norm> ack richard 
16:24:45 <Norm> Richard: I hadn't previously considered the possibility of allowing both.
16:24:53 <alexmilowski> Maybe two polls ?
16:25:27 <Norm> ...We're assuming that we have a construct that allows you to call another pipeline. Given the goal of interoperability then it seems quite plausible that whatever allows you to call pipelines would allow you to call single components.
16:25:57 <Norm> Norm: Yes, probably.
16:26:15 <Norm> Richard: But if we were going for the element names as step types, you could just call it by name.
16:26:46 <Norm> Alex: Right now our spec says that you'd put it in a library and it becomes as a component type.
16:26:52 <Norm> ...Now it would be available as a name.
16:27:04 <Norm> Richard: So the new proposal means that you'd call a pipeline by using its name.
16:27:14 <Norm> ...that sounds plausible to me.
16:28:05 <Norm> Straw poll: Shall we identify steps exclusivley with the form "<p:step type='p:xslt'>" or with the form "<p:xslt>"
16:28:20 <Norm> s/ivley/vely/
16:28:52 <Norm> Straw poll: Shall we identify steps exclusively with the form "<p:step type='p:xslt'>" or exclusively with the form "<p:xslt>"
16:29:09 <Norm> zakim, who's on the phone?
16:29:09 <Zakim> On the phone I see MSM, rlopes, MoZ, Norm, Alessandro_Vernet, Alex_Milowski, Murray_Maloney, richard
16:30:01 <Norm> Results: 7:1 in favor of p:xslt
16:30:09 <Norm> 5 yes, 1 no, 2 concur
16:30:42 <Norm> Topic: Pre-defined vs. arbitrary application parameters
16:31:11 <Norm> Norm: This is <p:parameter name="initial-mode"> vs. <p:initial-mode>
16:31:12 <alexmilowski> q+
16:31:42 <Norm> Norm: The one hard problem I see is that we don't have a mechanism for making the value of <p:initial-mode> dynamic.
16:32:06 <Norm> ack alexmilowski 
16:32:35 <Norm> Alex: I'm torn in a number of directions. Now that we have p:xslt, we can have attributes to set the initial mode, etc.
16:32:40 <Norm> ...That's very nice syntactically.
16:32:56 <Norm> ...The values that are not easy to put into attributes are easy to put in sub-elements.
16:33:26 <Norm> ...So I'm torn on the syntax.
16:33:38 <Norm> ...Then there's the question of what things need to be known statically. 
16:33:47 <Norm> ...There's application parameters vs. stylesheet parameters.
16:34:11 <Norm> ...Perhaps we could separate the questions?
16:34:47 <Norm> ...It seems unfortunate not to take advantage of the attributes on p:xslt.
16:36:05 <Norm> Norm: Does anyone think that these application parameters have to be dynamic?
16:36:15 <alexmilowski> I think you mean "configuration parameter"...
16:36:15 <Norm> Alessandro: Yes, I think pretty strongly that they have to be dynamic.
16:36:23 <Norm> s/application parameters/configuration parameters/
16:37:25 <Norm> Murray: What's the issue with dynamic parameters?
16:37:30 <Norm> Norm: We'd need new syntax.
16:38:11 <Norm> Alessandro: Couldn't we just allow select and value on the p:initial-mode element?
16:38:23 <Norm> Norm: Yes that seems the simplest answer.
16:38:45 <Norm> Alex: Is it really an issue of p:initial-mode is both an application parameter and a configuration parameter?
16:39:13 <Norm> Norm: I could certainly live with that.
16:39:23 <Norm> Richard: I'm uncertain whether it's a problem or not.
16:39:49 <Norm> ...For XSLT it's not a problem, but maybe some other language is expects to be able to do things like enumerate parameters which means that extra ones could be a real problem.
16:40:26 <Norm> Alex: We don't have a use case for that.
16:40:47 <Norm> Richard: That's true, but we don't want there to be something that's more difficult for people to make arbitrary existing tools into components.
16:41:03 <Norm> Murray: I'm an XProc processor and there are some parameters being set inside of my pipeline; foo=1, bar=2, etc.
16:41:25 <Norm> ...Then I invoke a component. I see myself as a shell wrapped around that component.
16:41:35 <Norm> ...The component may want to be able to get at the values of foo and bar.
16:41:56 <Norm> ...Now the component is a shell wrapped around a component that it's running.
16:42:04 <Norm> ...Right so far?
16:42:06 <Norm> Yes.
16:42:39 <Norm> Murray: Up in the pipeline processor, I'd have thought that all we'd have to do is assign values to tokens and then be able to refer to them.
16:42:54 <Norm> Murray: Then components should be able to get at them.
16:43:04 <Norm> Richard: But there are also programs that take arbitrary parameters.
16:43:13 <alexmilowski> q+
16:44:10 <Norm> Richard: Can someone give an example?
16:44:14 <Norm> Norm: How about 'make-manifest'
16:44:25 <Norm> Richard: That's one it wants, what about ones it doesn't want.
16:45:16 <Norm> Norm: Well, I could want make-manifest to be set or unset on two different stylesheets in the same pipeline.
16:46:07 <Norm> Scribe attempts to keep up, but fails 
16:46:36 <Norm> Murray: So you should be able to say the name of the parameter and either its value or a reference to another value.
16:47:52 <Norm> Norm attempts to describe the problem...
16:48:01 <Norm> Richard: In the unix command 'ls', you give it a bunch of flags and some filenames.
16:48:30 <Norm> ...If the way that the mechanisms worked meant that the component got both the filenames and the flags so that the flags were printed out, that would be a problem.
16:48:41 <Norm> ...In the xslt case, since you always look for parameters by name, there are no problems.
16:48:44 <Zakim> -MoZ
16:49:04 <Norm> ...But if your component prints out all the parameters that it gets, then you'll have extra things you don't want.
16:49:21 <Norm> ...But if p:initial-mode is recognized by the processor, why not simply not pass it through?
16:49:32 <Norm> Alex: We also have import param that was meant to handle some of these cases.
16:49:33 <Norm> q?
16:49:36 <Norm> ack alexmilowski 
16:49:53 <Norm> Alex: I wonder if we want to use that kind of mechanism to solve this problem.
16:50:27 <Zakim> +MoZ
16:50:28 <Norm> Alex: We're circling around this issue but we haven't considered import-parameter
16:51:39 <Norm> Alex: For general things, you could have the inverse of import-parameter.
16:51:58 <richard> <p:without-param ...> ?
16:52:15 <MoZ> q+
16:52:24 <Norm> ack MoZ 
16:52:48 <Norm> Mohamed: I think the problem is we have to identify parameters that are for or not for the component.
16:53:04 <Norm> ...I think we need to separate them or we need to exclude them by names or namespaces.
16:53:23 <Norm> ...I think we need this kind of distinction. But we have to lower the heavy difficulty of users.
16:53:40 <Norm> ...I propose that we have p:parameter with names and if there's nothing specified then it's passed through.
16:54:00 <Norm> ...If we have something like a target, like target on <a>, then we can use that.
16:55:28 <Norm> Norm: I think if we need something that complicated, I think I'd rather have <p:initial-mode>
16:55:54 <Norm> Alessandro: Now that we have p:xslt, we can have code-completion and syntax checking on those parameters that are predefined.
16:56:07 <Norm> ...It makes the code clearer and solves the distinction that we need to make.
16:57:15 <Norm> Alex: I'm still questioning whether or not we need to go here.
16:57:47 <Norm> ...We have a bag of parameters and you can set them, components do what they will. If you have a strange component that can't sort things out then you have a problem in V1. I'm ok with that.
16:59:01 <Norm> Norm: It's the point Alessandro made that makes me favor slightly the <p:initial-mode> approach
16:59:16 <Norm> Alex: Can't those things be solved in the component definitions?
16:59:20 <Norm> Norm: Yes, probably.
17:00:27 <Norm> Straw poll: Shall we allow pre-defined configuration parameters like <p:initial-mode> (which can have value and select attributes)?
17:00:45 <Norm> zakim, who's on the phone?
17:00:45 <Zakim> On the phone I see MSM, rlopes, Norm, Alessandro_Vernet, Alex_Milowski, Murray_Maloney, richard, MoZ
17:01:56 <Norm> Result: 6 yes, 1 Abstain, 1 No, but it's 2 Yes and 4 concurs
17:02:26 <Norm> No real conclusions here.
17:02:34 <Norm> Topic: Any other business?
17:02:35 <Norm> None
17:02:40 <Norm> Adjourned.
17:02:41 <Zakim> -Murray_Maloney
17:02:42 <Zakim> -richard
17:02:42 <Zakim> -Norm
17:02:43 <Zakim> -Alessandro_Vernet
17:02:43 <Zakim> -rlopes
17:02:45 <Zakim> -Alex_Milowski
17:02:47 <Zakim> -MoZ
17:02:52 <Norm> rrsagent, please make logs world-visible
17:02:55 <Zakim> -MSM
17:02:56 <Zakim> XML_PMWG()11:00AM has ended
17:02:57 <Zakim> Attendees were MSM, Norm, [IPcaller], MoZ, rlopes, Alessandro_Vernet, Alex_Milowski, Murray_Maloney, richard
17:02:58 <Norm> rrsagent, please draft minutes
17:02:58 <RRSAgent> I have made the request to generate http://www.w3.org/2007/02/22-xproc-minutes.html Norm
17:06:21 <alexmilowski> alexmilowski has left #xproc
18:44:24 <Norm> rrsagent, bye
18:44:24 <RRSAgent> I see no action items