See also: IRC log
Possible regrets from Mohamed
Henry: I'm a little bit
... Only in so far as it has a side effect that none of the other elements do.
Norm: Yes, I see your point.
<richard> i'm opposed to <step>
Henry: Maybe p:step-type would be ok, but it's a little rarified.
Resolved: No change.
Norm outlines the situation; states a strong preference for changing to the XSL style.
Henry: I don't feel as strongly as I used to, but I thought Richard had a counter example.
Richard: I don't recall it.
... Order is important
... I should also say that I imagine this only applies to compound steps.
Mohamed: I'm not sure about the
counter example, but the fact that option can read its value
from a port and that some ports may be reorganized may make
... There may be some implied circularity.
... Suppose we have a step that appears before the following step, but the ... [scribe lost the example]
Norm: I don't think that's the case, but I could be wrong...
Richard: These are defaults, right, on p:pipeline? So in addition to the order question, there's the question of which ones are provided and not defaulted.
Alex: I don't think this adds any more complexity, except that you have to keep track of the document order of options.
Richard: In the case of pipeline, the values given to options are default values. In the case of p:group, they're not defaults, they're always taken.
Some discussion of compound versus group.
Norm observes that XSL does have the distinction between p:param and p:with-param...
<ht> HST thinks Norm's point is a good one
<p:option name="a" value="5">
<p:option name="a" value="7"/>
<p:option name="b" select="$a + 1"/>
Richard: Option creates a new value in the called step, you don't get a new scope in the *calling* step. That would just be strange.
<p:option name="a" value="5">
<p:with-option name="a" value="7"/>
<p:with-option name="b" select="$a + 1"/>
Henry: If we say that only p:option binds, then that would resolve the question.
Alex: I'm wondering why we can't leave things the way they are.
Norm: See my first example from
... You can't pass a and b if you put b in a group, it's no longer an option of the pipeline
Alex: Then I think we have to
rename one of them, it's too confusing otherwise.
... I don't see why we don't make it the same for compound and atomic steps.
Richard: The reason why they
behave differently is that it's a default value in one case and
a value in another.
... If we're going to rename things, I'd prefer to rename the value attribute
... We could use default-value and default-select.
... It's only in default-select that the binding becomes visible.
Alex: When you're invoking the option, you're setting the value. If that happened to be a pipeline then it would set the value.
<MoZ> what about p:let ?
Richard: If instead you've got p:pipeline, then you'd use default-select and then it would use the local binding.
Alex: Invoking a pipeline is special.
<Zakim> Moz, you wanted to talk about p:let
Mohamed: Maybe instead of
renaming p:option to p:with-option, changing the "outer" option
... So this way we can make the difference between the option and the variable clearer.
Norm mumbles a bit.
Mohamed: The problem with p:pipeline is inside pipeline, I don't see how to fix that.
Henry: Following Mohamed's lead,
we could introduce p:variable.
... We don't need a new scoping mechanism
... Pipelines can have options and variables, compound steps can have variables, and atomic steps can have options.
Richard: If you've got some builtin step type, you could have different declarations for it.
Some discussion of our backards compatibility story
<p:option name="a" value="1"/>
<p:option name="b" select="$a"/>
Norm: I don't think adding p:variable helps. Because I still want two options.
Henry: That works in XSLT?
Norm: I think so.
Norm confirms that XSLT works they way he thought.
Richard: That's to be expected because xsl:param is pretty much like an assignment.
<MSM> [I am not able to follow the details here, but on the surface AM's position sounds plausible and orthogonal and good. I could be wrong.]
Some discussion continues. Perhaps compound steps have variables not options.
Henry: Suppose we said that
p:option can only occur with default values is in a
... You use p:option whenever you invoke something that's declared with declare step
... And in the latter case, the scope is uniform across all of them.
... But that for evaluating variable references in defaults, XSLT scoping rules apply.
... And we have a new thing, p:variable, that is very similar to xsl:variable, except that we use a value vs. select attribute.
... It may appear in any compound step, including declare-step.
... I'd like to also consider abandoning @value and using only @select.
<MSM> including declare-step? doesn't that open up issues of lexical vs dynamic scoping?
Norm: Given that we don't allow options/parameters/etc. to have compound values, I'd be reluctant to allow content.
Scribe got lost
Henry: I don't think we've every
said you're not allowed to have defaults on the options of
... We should exclude p:import and p:declare-step from p:declare-step when an atomic step is declared. We could do the same thing for p:variable.
Richard: Now that we declare pipelines with declare-step, declare-step can occur inside itself. Can it's options see the values of options outside declare-step.
Henry: I don't know, but it doesn't matter with respect to variables.
Richard: I think p:declare-step should be totally opaque.
Norm: I agree.
<MSM> [so I can't write a sort of generic declaration that I could parameterize ?]
Henry asserts some sort of dynamic scoping of options.
Norm and Richard balk.
Henry: 18.104.22.168 is broken with respect to this, the XPath processor context for the default value is uninterpretable.
Richard: The answer should be in
2.x, the environment which specifies the optoin
... What it says so far is right at the moment
<MoZ> but visible is not defined !!
Henry: But declare step is not a step. Following your nose from 22.214.171.124 leads to somewhere that says it doesn't apply to you.
Run out of time