IRC log of xproc on 2007-02-08

Timestamps are in UTC.

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:01:18 [alexmilowski]
alexmilowski has joined #xproc
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