15:57:10 <RRSAgent> RRSAgent has joined #xproc
15:57:11 <RRSAgent> logging to http://www.w3.org/2007/02/08-xproc-irc
15:57:15 <Norm> Meeting: XML Processing Model WG
15:57:15 <Norm> Date: 8 Feb 2007
15:57:15 <Norm> Agenda: http://www.w3.org/XML/XProc/2007/02/08-agenda.html
15:57:15 <Norm> Meeting: 54, T-minus 38 weeks
15:57:15 <Norm> Chair: Norm
15:57:16 <Norm> Scribe: Norm
15:57:18 <Norm> ScribeNick: Norm
15:59:15 <Alessandro> Alessandro has joined #xproc
16:00:04 <richard> richard has joined #xproc
16:00:10 <AndrewF> AndrewF has joined #xproc
16:00:21 <Zakim> +??P34
16:00:22 <Zakim> -??P34
16:00:22 <richard> zakim, ? is me
16:00:23 <Zakim> +??P34
16:00:24 <Zakim> +??P33
16:00:25 <Zakim> sorry, richard, I do not recognize a party named '?'
16:00:37 <rlopes> Zakim, ??P33 is me
16:00:37 <Zakim> +rlopes; got it
16:00:46 <Norm> zakim, ? is richard
16:00:46 <Zakim> +richard; got it
16:00:51 <Norm> zakim, mute richard
16:00:51 <Zakim> richard should now be muted
16:01:01 <Norm> zakim, unmute richard
16:01:01 <Zakim> richard should no longer be muted
16:01:12 <Norm> zakim, who's on the phone?
16:01:12 <Zakim> On the phone I see Norm, richard, rlopes
16:01:15 <ht> zakim, please call ht-781
16:01:16 <Zakim> ok, ht; the call is being made
16:01:16 <Zakim> +Ht
16:02:04 <Zakim> +??P9
16:02:07 <AndrewF> zakim, ? is AndrewF
16:02:10 <Zakim> +Alex_Milowski
16:02:12 <Zakim> +AndrewF; got it
16:02:26 <Zakim> +[Stanford]
16:02:26 <Norm> zakim, who's on the phone?
16:02:36 <Zakim> On the phone I see Norm, richard, rlopes, Ht, AndrewF, Alex_Milowski, [Stanford]
16:02:47 <Norm> zakim, [Stanford is MoZ 
16:02:52 <Zakim> +Alessandro_Vernet
16:02:57 <MoZ> Zakim, P9 is MoZ
16:03:04 <Zakim> +MoZ; got it
16:03:04 <MSM> zakim, please call MSM-Office
16:03:12 <Zakim> sorry, MoZ, I do not recognize a party named 'P9'
16:03:22 <Zakim> ok, MSM; the call is being made
16:03:24 <Zakim> +MSM
16:03:26 <Norm> zakim, who's on the phone?
16:03:30 <Zakim> On the phone I see Norm, richard, rlopes, Ht, AndrewF, Alex_Milowski, MoZ, Alessandro_Vernet, MSM
16:03:49 <Norm> Present: Norm, Richard, Rui, Henry, Andrew, Alex, Mohamed, Alessandro, Michael
16:04:04 <Norm> Topic: Accept this agenda?
16:04:04 <Norm> -> http://www.w3.org/XML/XProc/2007/02/08-agenda.html
16:04:08 <Norm> Accepted.
16:04:11 <Norm> Topic: Accept minutes from the previous meeting?
16:04:11 <Norm> -> http://www.w3.org/XML/XProc/2007/02/01-minutes.html
16:04:16 <Norm> Accepted.
16:04:20 <Norm> Topic: Next meeting: telcon 15 Feb 2007
16:04:40 <Norm> Richard gives possible regrets. Andrew gives regrets.
16:04:47 <Norm> Topic: Face-to-face in 2007?
16:05:00 <Norm> Nothing new to say; keep thinking about it.
16:05:11 <Norm> Topic: Is the defaulting story right?
16:05:56 <Norm> Henry: I don't think I feel any differently this week: it all ought to work.
16:06:26 <Norm> ...I ought to be able to write straight-through pipelines including both components and atomic steps.
16:07:22 <Norm> Richard: I agree with Henry's aim, but I remain concerned that doing so will make it less natural to write fully elaborated pipelines.
16:08:00 <Norm> Henry recalls off-line discussion with Richard
16:08:26 <Norm> Henry: Suppose we add an attribute to containers to specify how many output ports it has. It defaults to 1. 
16:08:57 <Norm> Henry: Because absence was being overloaded in the default syntax.
16:09:00 <Zakim> +Murray_Maloney
16:09:54 <Norm> Norm: How about simply an attribute to say "this component has no outputs"
16:10:00 <Norm> Henry: That works.
16:10:06 <Norm> Richard: It does cover the only case where there was an ambiguity.
16:10:50 <Norm> Norm asks about the defaulting story.
16:11:08 <Norm> Alex: What about an input that becomes an output.
16:12:59 <Norm> Proposal: The editor shall attempt to write up the defaulting story as we've described it here, with some mechanism for dealing with the single ambiguity we can see.
16:13:25 <Norm> Accepted.
16:13:37 <Norm> Topic: Is the choose/when story right?
16:14:01 <Norm> Norm: this is the use of xpath-context instead of input for the choose/when.
16:14:14 <Norm> Alex: We have the issue that the XPath works differently.
16:15:02 <Norm> Alex: In the examples that we have here, Henry matches against an attribute node where we have an input everywhere else.
16:15:23 <Norm> Alex: If you use input, you always get a document. On xpath-context, Henry's proposing that it's a node, not a document.
16:16:06 <Norm> Norm: My inclination would be to keep them the same, and wrap the matches that xpath-context returns in a document node.
16:16:22 <Norm> ...This would make the XPath expression a little odd, but would be consistent.
16:16:32 <Norm> Alex: But that's not what the author would expect.
16:16:49 <Norm> Alex recounts an XSLT example.
16:17:02 <Norm> Norm: Ok, the other alternative is to make it different.
16:18:00 <alexmilowski> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Feb/0012.html
16:18:24 <rlopes> rlopes has joined #xproc
16:19:20 <Norm> Richard: I'm in favor of it being a document because apart from this, we pass documents everywhere.
16:19:55 <Norm> Alex: If we go the document route, then this could be better if xpath-context would be a wrapper for input.
16:20:14 <Norm> Henry: I'm happy with the resolution that it's a document.
16:21:38 <Norm> Proposal: Describe the result of select expressions as a document.
16:21:57 <MSM> clarification?
16:22:12 <MSM> if I select //foo, how many documents do I get?
16:22:22 <Norm> Henry: Parenthetically, it should be said that without the select expression the result is a document.
16:22:36 <MSM> count(//foo) ? or the number of //foo that don't have a foo ancestor?
16:22:59 <Norm> Norm: Whatever you get for input, you should get here.
16:23:17 <Norm> Richard: Isn't this supposed to be a context *node*"
16:23:28 <Norm> Henry: I agree. There's no way to do unfolding or iteration at this level.
16:23:34 <alexmilowski> 4.2.2: "... Each matching node or set of nodes is wrapped in a document and provided to the input port."
16:23:42 <Norm> Henry: I'd like to make it an error if the select expression doesn't match a single element node.
16:23:51 <alexmilowski> ...but later: "...provides a sequence of zero or more documents, one for each matching html:div in the document "
16:24:03 <Norm> Norm: I'd be happy to impose that restriction.
16:25:32 <MSM> so: 'set of nodes' just means 'subtree' here, and if you have a div within a div, each of them gets wrapped as a document (so one of them goes through twice, once as root element and once as descendant)
16:26:42 <MSM> If getting zero is OK, I don't quite understand why getting n > 1 istn't ok
16:26:45 <Norm> Henry: The results should be just like concatenating the two expressions, the select on xpath-context and the test on when. It follows that zero would fall through to the otherwise.
16:27:07 <alexmilowski> not(/)
16:27:57 <Norm> Alex: I think we have an issue about an empty sequence of documents.
16:28:10 <Norm> Henry: That's the what does select=not(/) mean on input questoin.
16:28:34 <Norm> Proposal: We'll say select on xpath-context must match exactly one element or document, otherwise it's an error.
16:28:46 <Norm> Accepted.
16:29:53 <Norm> ACTION: Editor to clarify the text in 4.2.2
16:30:47 <Norm> Topic: Do we want to do something similar about for-each/viewport?
16:30:57 <MSM> [I'd like to be sure I understand our rationale.  If we want the kind of flexibility we'd get from allowing 0 or n, what we can do is not write a select on the xpath-context element, and write a longer test on the when ... is that right?]
16:31:35 <Norm> [Yes]
16:32:35 <MSM> [I do wish we would talk about data sources and data sinks, insted of input and outputs ...]
16:32:46 <MSM> s/we would/the spec would/
16:33:19 <MSM> q+
16:33:34 <Norm> ack msm
16:33:42 <richard> that's what we considering michael: that both outputs of earlier components and inputs of ancestor components are data sources
16:33:59 <ht> MSM: the outputs property in the context are the set of data sources
16:34:30 <ht> ... inside a construct, the outputs of your siblings, and the construct's inputs, are available to you
16:34:57 <Norm> <p:pipeline name="pipe">
16:34:58 <Norm>   <p:input port="foo">
16:34:58 <Norm>   <p:step>
16:34:58 <Norm>     <p:input port="xxx">
16:34:58 <Norm>       <p:pipe step="pipe" port="foo"/>
16:34:58 <Norm>   ...
16:35:03 <ht> AM: The construct's contents can _already_ point to the same things that the inputs point to
16:35:29 <Norm> <p:for-each name="iter">
16:35:29 <Norm>   <p:input port="source">
16:35:29 <Norm>   <p:step>
16:35:29 <Norm>     <p:input port="xxx">
16:35:29 <Norm>       <p:pipe step="xxx" port="foo"/>
16:35:30 <Norm>   ...
16:35:43 <ht> NW: See above example, works because the pipeline's input are in the available inputs of the context for the step
16:36:09 <Norm> <p:for-each name="iter">
16:36:09 <Norm>   <p:input port="source">
16:36:09 <Norm>   <p:step>
16:36:09 <Norm>     <p:input port="xxx">
16:36:09 <Norm>       <p:pipe step="iter" port="source"/>
16:36:10 <Norm>   ...
16:36:47 <ht> AM: 'pipeline' is special, because there's no outer context 
16:37:01 <ht> ... we don't _need_ this for for-each and viewport
16:37:38 <ht> RT: I think AM has a point, there would be no problem if we didn't do this, _except_ for pipeline
16:38:10 <Norm> Henry: I like what Alex is saying. Pipeline inputs are different.
16:38:33 <ht> RT: we could provide some _other_ means for users to bind pipeline I/O
16:39:22 <Norm> Richard: We could say that invoking a pipeline creates a context which must include certain things.
16:40:29 <Norm> Alex: We discussed this last week, but I don't remember why this came up.
16:42:56 <Norm> Norm tries to reconstruct how we got here
16:43:00 <ht> HST: Norm, I think your example would be clearer wrt Alex's point if it were completed (?) by having <p:input port="source"><p:pipe step="x" port="y"/></p:input>
16:44:37 <Norm> <p:for-each name="iter">
16:44:37 <Norm>   <p:input port="source">
16:44:37 <Norm>     <p:pipe step="somewhereelse" port="someport"/>
16:44:37 <Norm>   </p:input>
16:44:37 <Norm>   <p:step>
16:44:38 <Norm>     <p:input port="xxx">
16:44:40 <Norm>       <p:pipe step="iter" port="source"/>
16:44:42 <Norm>   ...
16:44:44 <Norm>   <p:step>
16:44:46 <Norm>     <p:input port="yyy">
16:44:48 <Norm>       <p:pipe step="somewherelese" port="someport"/>
16:44:50 <Norm>   ...
16:46:02 <Norm> Norm: I hear a bunch of people who want to change the way we describe why inputs are visible in the pipeline.
16:46:38 <Norm> Richard: One reason that the current semantics are reasonable is by analogy with functions. Functions parameters are available inside function.
16:47:12 <Norm> ...Rather than saying pipelines are an exception, it's really the components that are the exception.
16:47:48 <Norm> Alex: If we switch the input to xpath-context of whatever for viewport/for-each, then we have this xpath-context thing doing something that it doesn't do in the case of choose.
16:48:03 <MSM> [Richard, I wonder, though.  If we had a way to encapsulate constructs (e.g. in separate pipeline documents) and call them from multiple locations, the function analogy would be more persuasive.  But do we have any such information-hiding mechanism?]
16:48:03 <Norm> Alex: So that would be a change in how that works.
16:48:23 <ht> HST would find it clearer if we called the hypothetical parallel something such as p:iteration-source -- p:xpath-context is surely misleading here
16:48:31 <richard> [MSM, No, except for cut-and-paste in a graphical interface]
16:49:08 <MSM> [Or a general entity, I guess, for those of us who do that kind of thing]
16:50:00 <ht> [MSM, yes, for v.next we've several times talked about having a 'call-named-pipeline' component]
16:50:07 <Norm> Norm: Following on Richard's observation, the current situation does make components more self-contained.
16:50:36 <Norm> Alex: If you didn't allow inputs to be declared on for-each and viewport then this issue would go away.
16:51:09 <Norm> Henry: that's just saying that we'll allow you to treat for-each and viewport as a group.
16:51:58 <Norm> ...Aside from the name which is clearly broken, I'm inclined toward that proposal.
16:52:06 <Norm> ...I suggested "iteration-source"
16:52:36 <Norm> Alex: You can still have inputs, they just have nothing to do with what you're iterating.
16:52:56 <Norm> ACTION: Editor to clarify how multiple inputs work---maybe this is just a note to the editor for his own understanding
16:53:23 <Norm> Richard: You're saying that for-each and viewport no longer have an input used for iterating, there's a special element called iteration-source that specifies it.
16:53:26 <Norm> Henry: yes.
16:54:08 <Norm> Richard: How do the things inside viewport get their input?
16:54:21 <Norm> Henry: References to "current" remain the same.
16:55:22 <Norm> Richard: Maybe the name shouldn't be fixed, but be something that you can specify.
16:55:32 <ht> HST agrees we also set aside whether interation-source allows a 'select' attribute 
16:55:36 <Norm> Norm: Let's not.
16:56:23 <ht> +1 to having an attr on p:iteration-source which names the iteration port, possibly defaulting to 'current'
16:57:31 <Norm> Topic: Use "environment" for "context"?
16:58:09 <Norm> More support than opposition, editor will try.
16:58:31 <Norm> Topic: Any other business?
16:58:42 <Norm> Adjourned.
16:58:47 <Zakim> -Murray_Maloney
16:58:48 <Zakim> -richard
16:58:49 <Zakim> -Alessandro_Vernet
16:58:50 <Zakim> -Norm
16:58:51 <Zakim> -Ht
16:58:53 <Zakim> -rlopes
16:58:54 <Zakim> -Alex_Milowski
16:58:55 <Zakim> -AndrewF
16:58:56 <Zakim> -MoZ
16:58:57 <Norm> rrsagent, please make logs world-visible
16:59:01 <Zakim> -MSM
16:59:02 <Norm> rrsagent, draft minutes
16:59:02 <RRSAgent> I have made the request to generate http://www.w3.org/2007/02/08-xproc-minutes.html Norm
16:59:02 <Zakim> XML_PMWG()11:00AM has ended
16:59:03 <Zakim> Attendees were Norm, rlopes, richard, Ht, Alex_Milowski, AndrewF, [Stanford], Alessandro_Vernet, MoZ, MSM, Murray_Maloney
17:00:09 <alexmilowski> alexmilowski has left #xproc
17:19:48 <Norm> ht?
17:20:01 <ht> I'm here
17:20:09 <Norm> How much do you remember about XInclude?
17:20:24 <Norm> Suppose I say <xi:include parse="xml" xpointer="foo"/>
17:20:35 <Norm> The semantics of that are, find xml:id="foo" in the current document.
17:20:53 <Norm> When I'm looking for the element with the ID foo, do I expand XIncludes or not?
17:20:55 <ht> No, not by any rule I know of
17:21:10 <ht> Oh, sorry, yes
17:21:15 <ht> confusion -- start over
17:21:18 <Norm> heh
17:22:00 <ht> I was thinking "foo" wasn't an XPointer, because no  #, but xinclude/@xpointer is not a URI.. ..
17:22:39 <Norm> Right. I'm pretty sure that part's right. It's the question of resolving the pointer that's troubling me.
17:22:39 <ht> hang on . . .
17:25:38 <ht> Your case is specifically covered:
17:25:42 <ht> "[Definition: xi:include elements in this infoset are recursively processed to create the acquired infoset. For an intra-document reference (via xpointer attribute) the source infoset is used as the acquired infoset.]"
17:26:04 <ht> Phew.  You had me worried.
17:26:20 <ht> GTG -- away until next Thursday
17:26:30 <Norm> have fun!
17:26:43 <ht> Try to make Core call in my absence -- xml:base/XLink/XRIs needs some thoughtful consideration
17:26:56 <Norm> Ok. I will.
18:01:56 <MSM> Norm?
18:02:17 <MSM> what's your estimate on timing for next WD?
18:02:41 <Norm> I hope to have another review draft for next week
18:02:50 <Norm> Nothing public until we settle the chameleon question
18:03:04 <Norm> porquoi?
18:03:12 <MSM> I'm trying to finish this paper on Alloy modeling of XProc, and I am trying to figure out how to go about finishing it.  
18:03:48 <MSM> I think what I'll do is finish the paper on its own terms (referring only to November draft), and then review the current document
18:03:58 <MSM> to see which comments in the paper have been overtaken by events.
18:04:00 <Norm> Sounds like a plan
18:04:21 <MSM> What is our current most recent status quo document?
18:04:37 <MSM> [me looks at /XML/XProc/docs, knowing he ought to be able to find out the answer himself[
18:05:31 <Norm> .../XML/XProc/docs/langspec.html, I believe
18:05:35 <Norm> That is, I believe that is now the status quo
18:06:02 <Norm> It's a bit drafty from an editorial perspective, but I'll try to correct that in the coming week
18:06:54 <MSM> And as you make changes over the next week, they'll go into .../docs/langspec ?  That would be good from my pov
18:07:05 <Norm> Yes
18:07:13 <Norm> That's always the development "head"
18:07:39 <MSM> well, except when the status quo was represented by docs/alternate/Overview ...
18:07:40 <Norm> I make dated copies for milestones. I probably should have made one for the current head, but I forgot.
18:08:06 <Norm> I only use the "alternate" branch to float experimental ideas. They go into langspec as soon as they get a thumbs up
18:08:14 <Norm> s/branch/subdir/
18:08:32 <Norm> But yeah, ok, it's not quite as clean as might be ideal. Life's messy etc.
18:08:42 <MSM> ok.  just teasing.
18:08:57 <MSM> it works, as long as you don't start having more than one idea at a time. :)
18:09:10 <Norm> heh
18:21:04 <Norm> Two print heads and two printer bodies and I'm still not able to print.
18:21:07 <Norm> rrsagent, bye
18:21:07 <RRSAgent> I see 2 open action items saved in http://www.w3.org/2007/02/08-xproc-actions.rdf :
18:21:07 <RRSAgent> ACTION: Editor to clarify the text in 4.2.2 [1]
18:21:07 <RRSAgent>   recorded in http://www.w3.org/2007/02/08-xproc-irc#T16-29-53
18:21:07 <RRSAgent> ACTION: Editor to clarify how multiple inputs work---maybe this is just a note to the editor for his own understanding [2]
18:21:07 <RRSAgent>   recorded in http://www.w3.org/2007/02/08-xproc-irc#T16-52-56
18:21:09 <Norm> zakim, bye
18:21:09 <Zakim> Zakim has left #xproc