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