Meeting: XML Processing Model WG Date: 8 Mar 2007 Agenda: http://www.w3.org/XML/XProc/2007/03/08-agenda.html Meeting number: 58, T-minus 34 weeks Chair: Norm Scribe: Norm ScribeNick: Norm Roll: Norm, Rui, Andrew, Henry, Murray, Richard, Alex, Michael Regrets: Alessandro, Mohamed, Paul # Administrivia Topic: Accept this agenda? -> http://www.w3.org/XML/XProc/2007/03/08-agenda.html Accepted. Topic: Accept minutes from the previous meeting? -> http://www.w3.org/XML/XProc/2007/03/01-minutes.html Accepted. Topic: Next meeting: telcon 15 Mar 2007 Murray gives regrets # Technical agenda Topic: Review of the 28 Feb 2007 Editor's draft Henry and I reviewed it in person. Murray: I found the options and parameters wording a bit confusing. Henry: I remain unsure whether removing the distinct name for containers or language constructs and calling everything a step is the right thing or not. I can see both sides. Does anyone else have any concerns? Richard: I looked at the options and parameters alternatives, but didn't read the rest. Alex: We need to say something about in-scope namespaces to the parameters. Norm: I guess we'll come back to this a week from today. Topic: Consideration of options and parameters Norm: Murray, what did you find different than you expected? Murray: I thought options were like command line options. They're like an INI file as opposed to a command line options. Norm: Tries to explain...fails. Henry: I think the odd case is XSLT. We should think about things like delete-matching. It's absolutely the case that the options are passed to the step. What I don't understand is how to describe parameters. Richard: The difference as far as I understood it is that both are pairs of names/values. There's a set of fixed, named arguments that a step has (those are the options). Some kinds of steps can also take an arbitrary other mapping from names to values and those are the parameters. Pipeline implementors don't know in advance what parameters a step will have, but they do know what options they can take. In fact, they have to map those options from the XProc file to the implementation mechanism for the options. Henry: Equivalently, the options supply values that are in the interface to the step implementation. Whereas parameters are all going to be packed up and handed as one "argument" in the interface. Murray: I'm not entirely sure if I agree with Richard and Henry. It seems way to complicated, but it may be accurate. What I'd like to ask is what's wrong with the view that it's like command line options vs. an INI file. Richard: If I was going to do that, I'd have said it was more like the distinction between command line arguments and the environment. It'll ignore the extra environment variables but complain if it gets extra command line arguments. Norm: I wonder if we want to do away with p:parameter and just pass parameters to XSLT as an input? Henry: No, not really. Because we want to be able to set parameters on the command line to the pipeline. Norm: I think the editor should just take another wack at it. Henry: Be up-front about it and say that this mechanism is really only for the XSLT component. Alex: XQuery will also be in that camp. Michael: I wanted to hear the end of what Murray said... Murray: A thought: we could have on the command line that you could set a name/value pair and you could re-use that option. The processor is expected to create an entity with that name and value. Then the pipeline author could reference the entity. Richard: That would seem to imply that the pipeline document would have to be re-parsed each time. Michael: XML processors are not required to expand entities. So you could leave the entity references in the data structure. Providing a different replacement text for magic entities of the sort that Murray describes doesn't reqiure reparsing. Murray: We don't have a variables yet. Henry: We have pipeline parameters. Murray: What I'm talking about is that within the pipeline document itself we don't have a macro mechanism. Henry: I thought it was the case that we said that for XPaths, the parameters were available to discharge variable references in XPath. Richard: I think you can use parameters scoped to group. Michael: The one difference between variables and parameters is that the pipeline author cannot know what a variable is if it's just sait. Alex: Syntactically, default values are allowed, but that's not clear in the draft. Norm: I think we did say that the in-scope parameters would be available as variable references in XPath expressions. Henry: In 6.7.1 the syntax for declaring parameters doesn't include a mechanism for setting the default. Murray: But we did discover that we're using parameters in a different way. Alex: We've discussed structured parameters in email, but we're not doing that in V1, right? Richard: Wait, why do you need to declare parameters? Richard: In p:group, option doesn't make much sense. You only want parameters. Some discussion of whether it makes sense to declare parameters... Henry: Being able to define defaults for parameters is valuable. Murray: There's a defined set of options for any given component. But when it comes to parameters, they're open ended. Alex: For XSLT, we'd say parameter name="*" which would tell tools that this component takes any number of parameters. I think the right semantic is that you can set any parameter on any step. That would be legal. But that wouldn't be the case. Henry: The place I see defaults happening is on the p:pipeline or on the p:group. If I don't pass them in, they get default values so that they can be used or imported. Henry: What's the right thing to say here? It seems to me that those are pipeline options that are going to be imported as parameters to some styleshete. Norm: I think that just invites confusion. Murray: You can have an option on the command line that sets some parameter. Setting a parameter on the command line overrides the setting inside the pipeline. Henry: But that makes it seem like pipelines have options and pipelines. Norm: I don't think it makes sense for p:pipelines to have options. Henry: I think it's sensible. It's a little odd to think of it as having parameters. Pressing the Unix analogy further, it's a bit like -Dx=y to the C compiler. Alex: If we go look at things people are used to like parameters to XSLT, once you start using them, the values you set can't be changed from the command line, that only happens at the top level. Norm describes what he thinks. Henry: This means that p:pipeline only has parameters. Norm: It's a bug in the current spec that we don't allow implementations to specify values for top-level p:parameters. Richard: Pipelines are supposed to be components. If XSLT has parameters and options then I think it should be possible to make a pipeline a completely transparent wrapper around XSLT. So why can't p:pipeline have parameters and options? Henry: Options are things which control variability that's intrinsic to the nature of the step. Regardless of any contingent properties of any execution of a step, it always needs options. Parameters are things that are relevant to what conditionalizes the step. So if you had a step that produced a constant output, then it could only have options. At the other end of the scale, the pipeline compound step has no semantics of its own, it only makes sense for it to have parameters. Alex: There's a simpler way to think about this: what would a pipeline option be? I can't think of a single option that we need for a pipeline. Richard: There aren't any things that are intrinsic to all pipelines, but when you define a pipeline you are both declaring it and using it. Once you've declared it, that particular pipeline can only accept certain particular arguments. Richard: I want a pipeline that's exactly like the XSLT step except that it takes the name of the stylesheet as an option. So you always need a "stylesheet URI" option but you may also want arbitrary parameters. Norm: I'd do that with a required parameter. Richard: What about name conflicts? Now if I want to have a parameter to my stylesheet with the same name, I can't do it. Norm asks about how to refer to both options and parameters. Richard describes how shell scripts avoid this problem. It boils down to maybe we should just use namespaces after all. Henry: But I don't want people to have to declare more namespaces than they read. Richard: We could extend XPath with an an option() function to access the options. Norm: Yes, I thought of that too. ADJOURNED.