XML Processing Model WG

Meeting 102, 14 Feb 2008


See also: IRC log


Henry, Mohamed, Norm, Richard, Andrew, Alex, Michael


Accept this agenda?

-> http://www.w3.org/XML/XProc/2008/02/14-agenda


Accept minutes from the previous meeting?

-> http://www.w3.org/XML/XProc/2008/02/07-minutes


Next meeting: telcon 21 February 2008?

Possible regrets from Mohamed

Rename p:declare-step to p:step?

Henry: I'm a little bit opposed.
... 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.

#58, Scope of options

-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments.html#C058

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

Norm: Yes.
... 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 some problems.
... 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 #58
... 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 to p:let
... 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 declare-step.
... 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 declared steps.
... 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: 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 environment.
... 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 leads to somewhere that says it doesn't apply to you.

Run out of time

Any other business



Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/08/12 18:54:23 $