text: Agenda
  See also: IRC log
  ->
  Accepted.
  ->
  Accepted.
  No regrets given
  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.
  <MSM> "one for each" vs. "one for all" - nice formulation of the choice.
  Mohamed: Suppose we say we have
  p:validate, then we can defer the fact that some may be core
  and some may not.
  ... But if we say we have to have specific names, then we need to fix the list as soon as possible.
  ... It will be difficult to come to it later.
  Norm: What's "it"?
  Mohamed: The question of the list of what is in the core and what is not.
  <alexmilowski> (currently, we don't have "p:transform"... we have "p:xslt")
  Mohamed: We'll be able to defer
  the specifics to later.
  ... I fear that the fact we will have to define each element in detail will make us lazy.
  <MSM> [so we'll end up with a much smaller set of components, just to reduce our own work load]
  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.
  Straw poll: Shall we have components that act as interfaces to multiple applications?
  Results: 6:1 against.
  Norm: We will not have components that act as interfaces to multiple applications.
  Mohamed: In the examples there is a p:validate, so what is it's meaning in the spec.
  Norm: Do you think that component does multiple kinds of validation?
  Mohamed: Yes, I think so. We at least infer multiple interfaces.
  <alexmilowski> (anyone can write a custom component that supports multiple schema languages at once)
  Norm: Any further discussion before I attempt a straw poll?
  None heard
  Straw poll: Shall we identify steps with the form "<p:step" or with the form "<p:xslt>"
  Mohamed: So we'll have both?
  Norm: No
  Murray: Oh, I thought we'd further allow p:xslt but we'd still have p:step.
  Norm: Why two ways?
  Murray: That's a deeper question. I thought we'd still want the p:step way, but I take it back.
  Alex: I think in the spec we'll define some sort of abstract p:step type in the spec.
  Richard: I hadn't previously considered the possibility of allowing both.
  Richard: 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.
  Norm: Yes, probably.
  Richard: But if we were going for the element names as step types, you could just call it by name.
  Alex: Right now our spec says
  that you'd put it in a library and it becomes as a component
  type.
  ... Now it would be available as a name.
  Richard: So the new proposal
  means that you'd call a pipeline by using its name.
  ... that sounds plausible to me.
  Straw poll: Shall we identify steps exclusvely with the form "<p:step" or with the form "<p:xslt>"
  Straw poll: Shall we identify steps exclusively with the form "<p:step" or exclusively with the form "<p:xslt>"
  Results: 7:1 in favor of p:xslt
  5 yes, 1 no, 2 concur
  Norm: This is <p:parameter vs. <p:initial-mode>
  ... The one hard problem I see is that we don't have a mechanism for making the value of <p:initial-mode> dynamic.
  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.
  ... That's very nice syntactically.
  ... The values that are not easy to put into attributes are easy to put in sub-elements.
  ... So I'm torn on the syntax.
  ... Then there's the question of what things need to be known statically.
  ... There's application parameters vs. stylesheet parameters.
  ... Perhaps we could separate the questions?
  ... It seems unfortunate not to take advantage of the attributes on p:xslt.
  Norm: Does anyone think that these configuration parameters have to be dynamic?
  Alessandro: Yes, I think pretty strongly that they have to be dynamic.
  Murray: What's the issue with dynamic parameters?
  Norm: We'd need new syntax.
  Alessandro: Couldn't we just allow select and value on the p:initial-mode element?
  Norm: Yes that seems the simplest answer.
  Alex: Is it really an issue of p:initial-mode is both an application parameter and a configuration parameter?
  Norm: I could certainly live with that.
  Richard: I'm uncertain whether
  it's a problem or not.
  ... 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.
  Alex: We don't have a use case for that.
  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.
  Murray: I'm an XProc processor
  and there are some parameters being set inside of my pipeline;
  foo=1, bar=2, etc.
  ... Then I invoke a component. I see myself as a shell wrapped around that component.
  ... The component may want to be able to get at the values of foo and bar.
  ... Now the component is a shell wrapped around a component that it's running.
  ... Right so far?
  Yes.
  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.
  ... Then components should be able to get at them.
  Richard: But there are also
  programs that take arbitrary parameters.
  ... Can someone give an example?
  Norm: How about 'make-manifest'
  Richard: That's one it wants, what about ones it doesn't want.
  Norm: Well, I could want make-manifest to be set or unset on two different stylesheets in the same pipeline.
  Scribe attempts to keep up, but fails
  Murray: So you should be able to say the name of the parameter and either its value or a reference to another value.
  Norm attempts to describe the problem...
  Richard: In the unix command
  'ls', you give it a bunch of flags and some filenames.
  ... 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.
  ... In the xslt case, since you always look for parameters by name, there are no problems.
  ... But if your component prints out all the parameters that it gets, then you'll have extra things you don't want.
  ... But if p:initial-mode is recognized by the processor, why not simply not pass it through?
  Alex: We also have import param
  that was meant to handle some of these cases.
  ... I wonder if we want to use that kind of mechanism to solve this problem.
  ... We're circling around this issue but we haven't considered import-parameter
  ... For general things, you could have the inverse of import-parameter.
  <richard> <p:without-param ...> ?
  Mohamed: I think the problem is
  we have to identify parameters that are for or not for the
  component.
  ... I think we need to separate them or we need to exclude them by names or namespaces.
  ... I think we need this kind of distinction. But we have to lower the heavy difficulty of users.
  ... I propose that we have p:parameter with names and if there's nothing specified then it's passed through.
  ... If we have something like a target, like target on <a>, then we can use that.
  Norm: I think if we need something that complicated, I think I'd rather have <p:initial-mode>
  Alessandro: Now that we have
  p:xslt, we can have code-completion and syntax checking on
  those parameters that are predefined.
  ... It makes the code clearer and solves the distinction that we need to make.
  Alex: I'm still questioning
  whether or not we need to go here.
  ... 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.
  Norm: It's the point Alessandro made that makes me favor slightly the <p:initial-mode> approach
  Alex: Can't those things be solved in the component definitions?
  Norm: Yes, probably.
  Straw poll: Shall we allow pre-defined configuration parameters like <p:initial-mode> (which can have value and select attributes)?
  Result: 6 yes, 1 Abstain, 1 No, but it's 2 Yes and 4 concurs
  No real conclusions here. Try again next week.
  None
  Adjourned.