- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 14 Feb 2008 13:43:17 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2bq6jtm4a.fsf@nwalsh.com>
See also: http://www.w3.org/XML/XProc/2008/02/14-minutes
W3C[1]
- DRAFT -
XML Processing Model WG
Meeting 102, 14 Feb 2008
Agenda[2]
See also: IRC log[3]
Attendees
Present
Henry, Mohamed, Norm, Richard, Andrew, Alex, Michael
Regrets
Paul
Chair
Norm
Scribe
Norm
Contents
* Topics
1. Accept this agenda?
2. Accept minutes from the previous meeting?
3. Next meeting: telcon 21 February 2008?
4. Rename p:declare-step to p:step?
5. #58, Scope of options
6. Any other business
* Summary of Action Items
----------------------------------------------------------------------
Accept this agenda?
-> http://www.w3.org/XML/XProc/2008/02/14-agenda
Accepted.
Accept minutes from the previous meeting?
-> http://www.w3.org/XML/XProc/2008/02/07-minutes
Accepted
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:group>
<p:option name="a" value="5">
<someStep>
<p:option name="a" value="7"/>
<p:option name="b" select="$a + 1"/>
</someStep>
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:group>
<p:option name="a" value="5">
<someStep>
<p:with-option name="a" value="7"/>
<p:with-option name="b" select="$a + 1"/>
</someStep>
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:pipeline>
<p:option name="a" value="1"/>
<p:option name="b" select="$a"/>
scribe:
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: 5.7.1.3 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 5.7.1.3
leads to somewhere that says it doesn't apply to you.
Run out of time
Any other business
None.
Adjourned.
Summary of Action Items
[End of minutes]
----------------------------------------------------------------------
[1] http://www.w3.org/
[2] http://www.w3.org/XML/XProc/2008/07/14-agenda
[3] http://www.w3.org/2008/02/14-xproc-irc
[7] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[8] http://dev.w3.org/cvsweb/2002/scribe/
Minutes formatted by David Booth's scribe.perl[7] version 1.133 (CVS
log[8])
$Date: 2008/02/14 18:42:08 $
Received on Thursday, 14 February 2008 18:43:34 UTC