IRC log of xproc on 2008-02-14

Timestamps are in UTC.

15:58:08 [RRSAgent]
RRSAgent has joined #xproc
15:58:08 [RRSAgent]
logging to http://www.w3.org/2008/02/14-xproc-irc
15:58:12 [Norm]
Zakim, this will be xproc
15:58:14 [Zakim]
ok, Norm; I see XML_PMWG()11:00AM scheduled to start in 2 minutes
15:59:52 [Norm]
Meeting: XML Processing Model WG
15:59:52 [Norm]
Date: 14 February 2008
15:59:52 [Norm]
Agenda: http://www.w3.org/XML/XProc/2008/07/14-agenda
15:59:52 [Norm]
Meeting: 102
15:59:52 [Norm]
Chair: Norm
15:59:53 [Norm]
Scribe: Norm
15:59:55 [Norm]
ScribeNick: Norm
16:01:14 [Zakim]
MoZ, you asked to be reminded at this time
16:01:28 [MoZ]
Zakim, thanks
16:01:28 [Zakim]
you are very welcome, MoZ
16:01:35 [AndrewF]
AndrewF has joined #xproc
16:02:02 [ht]
zakim, please call ht-781
16:02:04 [Zakim]
ok, ht; the call is being made
16:02:07 [Zakim]
XML_PMWG()11:00AM has now started
16:02:09 [Zakim]
+Ht
16:02:13 [Zakim]
+MoZ
16:02:23 [Zakim]
+Norm
16:02:43 [Zakim]
+??P17
16:02:45 [richard]
richard has joined #xproc
16:03:04 [richard]
zakim, who is on the phone?
16:03:04 [Zakim]
On the phone I see Ht, MoZ, Norm, ??P17
16:03:10 [richard]
zakim, ? is me
16:03:10 [Zakim]
+richard; got it
16:04:30 [Zakim]
+ +1.734.214.aaaa
16:04:34 [AndrewF]
zakim, ? is Andrew
16:04:34 [Zakim]
sorry, AndrewF, I do not recognize a party named '?'
16:05:11 [MoZ]
Zakim, ??P17 is Andrew
16:05:11 [Zakim]
I already had ??P17 as richard, MoZ
16:05:46 [richard]
zakim, + is Andrew
16:05:46 [Zakim]
+Andrew; got it
16:06:18 [Norm]
Zakim, who's on the phone?
16:06:18 [Zakim]
On the phone I see Ht, MoZ, Norm, richard, Andrew
16:06:36 [MoZ]
MoZ has changed the topic to: http://www.w3.org/XML/XProc/2008/02/14-agenda
16:06:45 [Norm]
Present: Henry, Mohamed, Norm, Richard, Andrew
16:07:36 [alexmilowski]
alexmilowski has joined #xproc
16:08:07 [Norm]
Present: Henry, Mohamed, Norm, Richard, Andrew, Alex
16:08:12 [Zakim]
+alexmilowski
16:08:14 [MSM]
zakim, please call MSM-617
16:08:14 [Zakim]
ok, MSM; the call is being made
16:08:16 [Zakim]
+MSM
16:08:24 [Norm]
Present: Henry, Mohamed, Norm, Richard, Andrew, Alex, Michael
16:08:33 [Norm]
Topic: Accept this agenda?
16:08:33 [Norm]
-> http://www.w3.org/XML/XProc/2008/02/14-agenda
16:08:37 [Norm]
Accepted.
16:08:44 [Norm]
Topic: Accept minutes from the previous meeting?
16:08:44 [Norm]
-> http://www.w3.org/XML/XProc/2008/02/07-minutes
16:08:57 [Norm]
Accepted
16:09:00 [Norm]
Topic: Next meeting: telcon 21 February 2008?
16:09:20 [Norm]
Possible regrets from Mohamed
16:09:33 [Norm]
Topic: Rename p:declare-step to p:step?
16:09:38 [Zakim]
-MSM
16:10:06 [MSM]
zakim, please call MSM-617
16:10:06 [Zakim]
ok, MSM; the call is being made
16:10:08 [Zakim]
+MSM
16:10:15 [Norm]
Henry: I'm a little bit opposed.
16:10:30 [Norm]
...Only in so far as it has a side effect that none of the other elements do.
16:10:45 [Norm]
Norm: Yes, I see your point.
16:11:18 [richard]
i'm opposed to <step>
16:11:25 [Norm]
Henry: Maybe p:step-type would be ok, but it's a little rarified.
16:11:46 [Norm]
Resolved: No change.
16:12:02 [Norm]
Topic: #58, Scope of options
16:12:12 [Norm]
-> http://www.w3.org/XML/XProc/2007/09/lastcall/comments.html#C058
16:13:25 [Norm]
Norm outlines the situation; states a strong preference for changing to the XSL style.
16:13:38 [Norm]
Henry: I don't feel as strongly as I used to, but I thought Richard had a counter example.
16:13:42 [Norm]
Richard: I don't recall it.
16:14:49 [Norm]
Richard: Order is important
16:14:51 [Norm]
Norm: Yes.
16:15:15 [Norm]
Norm: I should also say that I imagine this only applies to compound steps.
16:15:42 [Norm]
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.
16:15:58 [Norm]
...There may be some implied circularity.
16:16:32 [Norm]
...Suppose we have a step that appears before the following step, but the ... [scribe lost the example]
16:17:28 [Norm]
Norm: I don't think that's the case, but I could be wrong...
16:18:07 [Norm]
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.
16:18:55 [Norm]
Alex: I don't think this adds any more complexity, except that you have to keep track of the document order of options.
16:19:37 [Norm]
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.
16:21:14 [Norm]
Some discussion of compound versus group.
16:22:59 [Norm]
Norm observes that XSL does have the distinction between p:param and p:with-param...
16:23:51 [ht]
HST thinks Norm's point is a good one
16:24:16 [Norm]
<p:group>
16:24:16 [Norm]
<p:option name="a" value="5">
16:24:16 [Norm]
<someStep>
16:24:16 [Norm]
<p:option name="a" value="7"/>
16:24:16 [Norm]
<p:option name="b" value="$a + 1"/>
16:24:17 [Norm]
</someStep>
16:25:04 [Norm]
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.
16:25:26 [Norm]
<p:group>
16:25:26 [Norm]
<p:option name="a" value="5">
16:25:26 [Norm]
<someStep>
16:25:26 [Norm]
<p:with-option name="a" value="7"/>
16:25:26 [Norm]
<p:with-option name="b" value="$a + 1"/>
16:25:27 [Norm]
</someStep>
16:25:45 [Norm]
Henry: If we say that only p:option binds, then that would resolve the question.
16:25:53 [Norm]
Alex: I'm wondering why we can't leave things the way they are.
16:27:05 [Norm]
Norm: See my first example from #58
16:27:28 [Norm]
...You can't pass a and b if you put b in a group, it's no longer an option of the pipeline
16:27:36 [Norm]
Alex: Then I think we have to rename one of them, it's too confusing otherwise.
16:28:41 [Norm]
Alex: I don't see why we don't make it the same for compound and atomic steps.
16:29:39 [Norm]
Richard: The reason why they behave differently is that it's a default value in one case and a value in another.
16:30:03 [Norm]
...If we're going to rename things, I'd prefer to rename the value attribute
16:30:13 [Norm]
s/value="$a/select="$a/
16:30:17 [Norm]
s/value="$a/select="$a/g
16:30:27 [Norm]
Richard: We could use default-value and default-select.
16:31:02 [Norm]
...It's only in default-select that the binding becomes visible.
16:31:29 [Norm]
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.
16:32:35 [MoZ]
what about p:let ?
16:33:01 [Norm]
Richard: If instead you've got p:pipeline, then you'd use default-select and then it would use the local binding.
16:33:12 [MoZ]
q+ for p:let
16:33:20 [Norm]
Alex: Invoking a pipeline is special.
16:34:05 [MSM]
q?
16:34:10 [MSM]
queue=
16:34:17 [MSM]
q+ Moz to talk about p:let
16:34:25 [Norm]
ack moz
16:34:25 [Zakim]
Moz, you wanted to talk about p:let
16:34:50 [Norm]
Mohamed: Maybe instead of renaming p:option to p:with-option, changing the "outer" option to p:let
16:35:16 [Norm]
...So this way we can make the difference between the option and the variable clearer.
16:35:47 [Norm]
Norm mumbles a bit.
16:36:06 [Norm]
Mohamed: The problem with p:pipeline is inside pipeline, I don't see how to fix that.
16:36:29 [Norm]
Henry: Following Mohamed's lead, we could introduce p:variable.
16:37:01 [Norm]
..We don't need a new scoping mechanism
16:37:18 [Norm]
...Pipelines can have options and variables, compound steps can have variables, and atomic steps can have options.
16:38:14 [Norm]
Richard: If you've got some builtin step type, you could have different declarations for it.
16:39:22 [Norm]
Some discussion of our backards compatibility story
16:40:03 [Norm]
<p:pipeline>
16:40:03 [Norm]
<p:option name="a" value="1"/>
16:40:03 [Norm]
<p:option name="b" select="$a"/>
16:40:03 [Norm]
...
16:40:27 [Norm]
Norm: I don't think adding p:variable helps. Because I still want two options.
16:40:32 [Norm]
Henry: That works in XSLT?
16:40:37 [Norm]
Norm: I think so.
16:42:50 [Norm]
Norm confirms that XSLT works they way he thought.
16:43:05 [Norm]
Richard: That's to be expected because xsl:param is pretty much like an assignment.
16:44:29 [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.]
16:47:41 [Norm]
Some discussion continues. Perhaps compound steps have variables not options.
16:48:18 [Norm]
Henry: Suppose we said that p:option can only occur with default values is in a declare-step.
16:48:54 [Norm]
...You use p:option whenever you invoke something that's declared with declare step
16:49:10 [Norm]
...And in the latter case, the scope is uniform across all of them.
16:49:39 [Norm]
...But that for evaluating variable references in defaults, XSLT scoping rules apply.
16:50:00 [Norm]
...And we have a new thing, p:variable, that is very similar to xsl:variable, except that we use a value vs. select attribute.
16:50:23 [Norm]
...It may appear in any compound step, including declare-step.
16:50:59 [Norm]
Henry: I'd like to also consider abandoning @value and using only @select.
16:51:16 [MSM]
including declare-step? doesn't that open up issues of lexical vs dynamic scoping?
16:52:15 [Norm]
Norm: Given that we don't allow options/parameters/etc. to have compound values, I'd be reluctant to allow content.
16:53:22 [Norm]
Scribe got lost
16:53:56 [Norm]
Henry: I don't think we've every said you're not allowed to have defaults on the options of declared steps.
16:56:35 [Norm]
Henry: 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.
16:57:31 [Norm]
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.
16:57:58 [Norm]
Henry: I don't know, but it doesn't matter with respect to variables.
16:58:06 [Norm]
Richard: I think p:declare-step should be totally opaque.
16:58:10 [Norm]
Norm: I agree.
16:58:19 [MSM]
[so I can't write a sort of generic declaration that I could parameterize ?]
16:59:48 [Norm]
Henry asserts some sort of dynamic scoping of options.
16:59:54 [Norm]
Norm and Richard balk.
17:00:37 [Norm]
Henry: 5.7.1.3 is broken with respect to this, the XPath processor context for the default value is uninterpretable.
17:01:12 [Norm]
Richard: The answer should be in 2.x, the environment which specifies the optoin environment.
17:01:24 [Norm]
...What it says so far is right at the moment
17:01:51 [MoZ]
but visible is not defined !!
17:02:10 [Norm]
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.
17:03:10 [Norm]
Run out of time
17:03:14 [Norm]
Topic: Any other business
17:03:15 [Norm]
None.
17:03:33 [Norm]
Adjourned.
17:03:35 [Zakim]
-alexmilowski
17:03:36 [Zakim]
-Ht
17:03:37 [Zakim]
-richard
17:03:38 [MSM]
bye
17:03:38 [Zakim]
-Norm
17:03:40 [Zakim]
-MoZ
17:03:41 [Zakim]
-Andrew
17:03:42 [Zakim]
-MSM
17:03:43 [Norm]
FAIL. FAIL. FAIL. :-)
17:03:43 [Zakim]
XML_PMWG()11:00AM has ended
17:03:44 [Zakim]
Attendees were Ht, MoZ, Norm, richard, +1.734.214.aaaa, Andrew, alexmilowski, MSM
17:03:52 [Norm]
RRSAgent, set logs world visible
17:03:52 [RRSAgent]
I'm logging. I don't understand 'set logs world visible', Norm. Try /msg RRSAgent help
17:03:57 [Norm]
RRSAgent, set logs world-visible
17:04:03 [Norm]
RRSAgent, draft minutes
17:04:03 [RRSAgent]
I have made the request to generate http://www.w3.org/2008/02/14-xproc-minutes.html Norm
18:37:06 [Zakim]
Zakim has left #xproc
19:48:02 [Norm]
Norm has joined #xproc