XProc Minutes 08 Mar 2007

See http://www.w3.org/XML/XProc/2007/03/08-minutes.html

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.