IRC log of xproc on 2006-09-28

Timestamps are in UTC.

14:55:28 [RRSAgent]
RRSAgent has joined #xproc
14:55:28 [RRSAgent]
logging to http://www.w3.org/2006/09/28-xproc-irc
14:55:44 [PGrosso]
PGrosso has joined #xproc
14:56:47 [Norm]
Meeting: XML Processing Model WG
14:56:48 [Norm]
Date: 28 Sep 2006
14:56:48 [Norm]
Agenda: http://www.w3.org/XML/XProc/2006/09/21-agenda.html
14:56:48 [Norm]
Meeting: 37
14:56:48 [Norm]
Agenda: http://www.w3.org/XML/XProc/2006/09/28-agenda.html
14:56:57 [Norm]
Ok, thx
14:57:06 [alexmilowski]
alexmilowski has joined #xproc
14:57:59 [Zakim]
XML_PMWG()11:00AM has now started
14:58:06 [Zakim]
+Alex_Milowski
14:58:49 [Zakim]
+[IPcaller]
14:58:58 [rlopes]
Zakim, [IP is Rui
14:58:58 [Zakim]
+Rui; got it
14:59:42 [Zakim]
+[ArborText]
15:00:40 [ht]
zakim, please call ht-781
15:00:41 [Zakim]
ok, ht; the call is being made
15:00:41 [Zakim]
+Ht
15:01:38 [ht]
zakim, who is on the call?
15:01:38 [Zakim]
On the phone I see Alex_Milowski, Rui, PGrosso, Ht
15:01:59 [MoZ]
Zakim, what is the code ?
15:01:59 [Zakim]
the conference code is 97762 (tel:+1.617.761.6200), MoZ
15:02:08 [ebruchez]
ebruchez has joined #xproc
15:02:38 [Zakim]
+Murray_Maloney
15:02:40 [Zakim]
+??P30
15:02:47 [MoZ]
Zakim, ? is me
15:02:47 [Zakim]
+MoZ; got it
15:03:39 [ht]
zakim, who is on the call?
15:03:39 [Zakim]
On the phone I see Alex_Milowski, Rui, PGrosso, Ht, Murray_Maloney, MoZ
15:04:30 [ht]
http://www.w3.org/XML/XProc/2006/09/28-agenda.html
15:04:55 [richard]
richard has joined #xproc
15:04:57 [Zakim]
+??P35
15:05:07 [richard]
zakim, ? is richard
15:05:07 [Zakim]
+richard; got it
15:05:21 [ht]
Agenda agreed
15:05:43 [Zakim]
+[IPcaller]
15:05:44 [MSM]
MSM has joined #xproc
15:05:47 [ht]
Accept minutes of previous meeting as a valid record
15:05:50 [ebruchez]
zakim, [IP is ebruchez
15:05:50 [Zakim]
+ebruchez; got it
15:06:12 [MSM]
zakim, please call MSM-Office
15:06:12 [Zakim]
ok, MSM; the call is being made
15:06:14 [Zakim]
+MSM
15:06:18 [MoZ]
Zakim, who is on the phone ?
15:06:18 [Zakim]
On the phone I see Alex_Milowski, Rui, PGrosso, Ht, Murray_Maloney, MoZ, richard, ebruchez, MSM (muted)
15:06:28 [ht]
Apologies for next week from HST, Norm
15:07:04 [Zakim]
-Rui
15:07:08 [Zakim]
+[IPcaller]
15:07:26 [rlopes]
Zakim, [IP is Rui
15:07:26 [Zakim]
+Rui; got it
15:07:32 [ht]
Tentative agreement from MSM to chair next week
15:08:46 [ht]
MM: Suggest we do 2 minutes around the table, then discuss
15:09:00 [ht]
zakim, who is on the call?
15:09:00 [Zakim]
On the phone I see Alex_Milowski, PGrosso, Ht, Murray_Maloney, MoZ, richard, ebruchez, MSM, Rui
15:09:53 [MSM]
zakim, give each speaker 2 mins
15:09:53 [Zakim]
ok, MSM
15:09:57 [MSM]
ack Alex
15:10:20 [MSM]
queue= Alex, Paul, HT, Murray, MoZ, Richard, Erik, MSM, Rui
15:10:24 [MSM]
ack Alex
15:10:31 [ht]
AM: Pop the whole discussion up several levels
15:10:45 [ht]
... The level of detail shown in these diagrams is too great to be helpful to readers
15:11:12 [ht]
... I use that level in my implememntation, but I wouldn't expose it to users
15:11:25 [ht]
... Maybe we should even just drop all mention of graphs from the spec
15:11:32 [ht]
... and not constrain implementaitons
15:11:38 [MSM]
ack Paul
15:11:40 [ht]
ack paul
15:11:44 [ht]
ack ht
15:12:43 [Zakim]
+Norm
15:12:58 [alexmilowski]
Clarification: I mean delete the computer science terminology of a "directed acyclic graph"
15:14:11 [MSM]
q?
15:14:17 [ht]
ack Murray
15:14:56 [Norm]
Murray: Like what Alex said. Move to a higher level. Don't need to talk about graphs.
15:15:12 [ht]
ack MoZ
15:15:16 [Norm]
Murray: Can move this discussion elsewhere.
15:15:25 [Norm]
MoZ: Need to have a formal semantics in the near future.
15:15:50 [Norm]
MoZ: Agree we don't need to talk about this now.
15:16:16 [Norm]
MoZ: Go further with semantics and models in parallel.
15:16:26 [ht]
ack Richard
15:16:30 [Norm]
MoZ: Don't want to loose focus on semantics.
15:16:49 [Norm]
Richard: I think graphs are great. They're easy to understand and we should have lots of them in the spec.
15:17:02 [Norm]
Richard: But they aren't the semantics. We should have a straightforward semantics written in English.
15:17:08 [Norm]
Richard: They should work in a natural way describing each of the components.
15:17:31 [Norm]
Richard: Don't need to describe the semantics of the whole flow; do it in a modular way for each component.
15:17:41 [Norm]
Richard: We don't need to decide how the diagrams look because they aren't in the semantics.
15:18:02 [Norm]
... They don't even have to be right; they can give the users an idea without mapping onto the semantics.
15:18:17 [alexmilowski]
+1 to that !
15:18:33 [Norm]
... It's irrelevant whether or not the pictures are accurate as long as they're helpful to the reader.
15:18:37 [Norm]
q?
15:18:41 [Norm]
ack Erik
15:18:53 [Norm]
Erik: I like what Richard said.
15:18:55 [Norm]
ack MSM
15:19:05 [Norm]
Michael: I'm made nervous by some of what I've heard.
15:19:22 [Norm]
... I think we need two things, or one thing with two aspects.
15:19:39 [Norm]
... 1. We need to understand what we think pipelines are; we need a story.
15:19:51 [Norm]
... I'm not committed to the graph description as the best or only story
15:19:55 [Norm]
... But at some level it's clearly appealing.
15:20:21 [Norm]
... I'm made nervous about the proposals that say let's not go there, unless they mean let's find another way to reach clarity.
15:20:55 [Norm]
... I worked on a spec 10 years ago that has worked pretty well, and I remember Dan Connolly pushing often to answer the question "what is an XML document".
15:21:24 [Norm]
... I didn't think we needed that kind of clarity; everyone knows what we mean.
15:21:30 [Norm]
... But many of the hardest problems have come from the fact that we didn't answer the question that Dan asked.
15:22:07 [Norm]
... I now think that it would have been useful
15:22:16 [Norm]
s/; we need/; and 2. we need/
15:22:43 [Norm]
... I'm not sure defining a pipeline as a graph is useful, but it may tell a good story.
15:22:43 [Norm]
... My goal here is clarity.
15:22:43 [Norm]
q?
15:23:13 [Norm]
... If we don't say a pipeline is a graph, I want something similarly concise and suggestive.
15:23:16 [Norm]
ack rui
15:23:31 [Norm]
Rui: I tend to be pragmatic; I agree with Alex and almost everyone else.
15:23:53 [Norm]
q+ norm
15:23:55 [Norm]
ack norm
15:24:35 [Norm]
Norm: I'm happy to move on to something else for a bit. I'll assume to the extent that people agree or disagree with what the spec says, they'll comment on the words in the spec.
15:24:45 [Norm]
... Sorry I missed what Alex said.
15:25:34 [MSM]
zakim, stop timing speakers
15:25:34 [Zakim]
ok, MSM
15:25:35 [alexmilowski]
q+
15:25:46 [Norm]
q+ ht
15:25:48 [richard]
q+
15:25:50 [Norm]
ack ht
15:26:22 [Norm]
Henry: My experience producing these diagrams: XXXX
15:26:37 [Norm]
... I started trying to produce diagrams that were faithful to my understanding.
15:26:57 [Norm]
... Convinced me of two things: a lot of detail is necessary and when we state the semantics of the components, it will not be appropriate to try to do so int erms of the diagrams
15:27:01 [Norm]
s/int er/in ter
15:27:23 [Norm]
... We'll want to use words like the spec currently does perhaps with a more explicit abstract model.
15:27:28 [MSM]
Henry, can you say a bit more about what kind of detail you found necessary and why it proved essential?
15:27:39 [Norm]
... It did help me understand
15:27:43 [Norm]
s/XXXX/http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Sep/0071.html/
15:27:47 [Norm]
-> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Sep/0071.html
15:28:32 [Norm]
Henry: If we look at figur 1a, a nested graph mode of a for-each
15:28:39 [Norm]
s/figur/figure/
15:29:19 [Norm]
Henry: The distinction between thick gray lines and dotted black lines are that the gray lines are the pies and the dotted lines that are the lines of the approrpiate type for the component.
15:29:38 [Norm]
... Documents flow down think gray lines.
15:29:55 [Norm]
... What a dotted line means is context dependent, in 1a the top dotted line means send a single document down this repeatedly.
15:30:45 [Norm]
... The bottom dotted line is the concatenation of the output of all the iterations.
15:31:02 [Norm]
... Now compare with figure 1b
15:31:08 [MSM]
and why is it essential to distinguish single-document data flows from multi-document data flows / loops?
15:31:20 [Norm]
... In the computed schema case, I've put the computation outside the for-each
15:31:36 [Norm]
... There is an auxilliary input to the for-each because I need a new kind of connection.
15:32:16 [Norm]
... The dotted line from the XSLT result to the XInclude port. This time the dotted line means repeatedly include the same component.
15:32:26 [Norm]
Alex: This is where we need to pop up a level.
15:32:59 [Norm]
... There are some constraints here, but the schema is not an input to the for-each. It's used inside, so your implementation has to do something about it.
15:33:04 [MSM]
At the point where we start saying it's essential to distinguish three kinds of edges, I think we have left any story about graphs behind.
15:33:14 [Norm]
... I think there needs to be a line that crosses the red box. It's not formally an input to the for-each.
15:33:24 [Norm]
Alex: I don't do it that way and it works just fine.
15:33:36 [ht]
http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2006Sep/0073.html
15:34:16 [Norm]
Alex: There's a constraint here that you can describe to the user, that the scheme has to be the same each time. You don't have to say that it's an input.
15:34:49 [Norm]
Murray: In fact, isn't the computed schema a pull? It's not a computed input, it's a pull from the validate.
15:35:18 [Norm]
Norm: No, it's not a pull, it's not a URI, it's computed by a previous step.
15:35:46 [Norm]
Alex: That's the kind of clarity we need. It's not something you're iterating over, it's a value that goes along from the rid.
15:35:49 [Norm]
s/rid./ride./
15:35:54 [Norm]
q?
15:35:59 [Norm]
ack alexmilowski
15:36:19 [Norm]
Richard: I don't think we want any diagrams like this in the spec. A diagram with three kinds of lines just isn't useful to a new user.
15:36:19 [alexmilowski]
+1 to that
15:36:24 [MSM]
+1 to opposition to three kinds of dotted lines
15:36:35 [Norm]
Richard: They're useful to us to argue about what we actually mean.
15:36:50 [Norm]
Richard: OTOH, I think diagrams like the ones currently in the spec, which are much more informal, are what we need.
15:37:57 [Norm]
Richard: I'd like to compare the XML spec to the Schema spec. I don't want this spec to be like the Schema spec where you have to analyze every sentence for meaning.
15:38:27 [Norm]
... There should be a place where the semantics are spelled out clearly. If there are errors there, we should fix them. If there are other descriptions that seem to say something slightly different, that shouldn't matter.
15:38:54 [Norm]
... If in the course of producing the semantics, it turns out to be useful to produce a specialized diagram, we can do so.
15:39:01 [MSM]
[I agree with Richard that we don't want readers to have to be language lawyers. But I believe one reason the schema spec is unclear is that we did not insist on clear common understanding of what schemas and schema components are. That means the prose has to avoid saying things clearly, it has to say things obscurely so different WG members can each think it's saying what they mean.]
15:40:41 [Norm]
Richard: (replying to MSM's comment above) I don't think that has anything to do with what's wrong with the Schema spec. It simply tries too hard to be declaritive. It lays things out as discrete declarations instead of providing a place to read from to understand procedurally what validation does.
15:41:04 [Norm]
Alex: I'm looking at things that say, if you used an input inside a for-each that isn't something you're iterating, then it's constant during iteration.
15:41:07 [MSM]
[I think part of the reason the validation rules are hard to read is that they aren't in fact declarative, they are an algorithm pretending not to be an algorithm. What the spec needs is more declarativity not less.]
15:41:14 [Norm]
Richard: I think the easiest way to describe this is in terms of the documents produced by ports.
15:41:34 [Norm]
... The fact that there's a line going across a box simply means that this document is used in each iteration.
15:41:59 [Norm]
Alex: It turns out that implementations are going to have to do something to make that work.
15:42:25 [Norm]
Richard: We can simply describe what happens (the component gets that document) without describing how the component achieves that result.
15:42:49 [Norm]
Alex: I wonder if we can try to restate what was going on in the deleted section 4.1.3.
15:43:12 [Norm]
Alex: I think there are a handful of rules that we could say concretely without going into particular implementation semantics.
15:43:26 [Norm]
q?
15:43:36 [Norm]
ack richard
15:44:04 [Norm]
Henry: The only reason that I'm unsure of our ability to do that is that I'm worried about the cross-product phenomenon.
15:44:42 [Norm]
... The reason for stating things in terms of the auxillary-input story has the advantage that there are no cross-prodcut problems.
15:45:22 [Norm]
... It worries me that it's not going to be the case that if you refer to a port across a choose boundary and say "thus and such"
15:45:39 [Norm]
... Instead, you're going to have to say "if you refer to one across this boundary and that boundary"...
15:45:52 [Norm]
... I can't prove that, but I'm worried that it won't be possible to say things once.
15:46:35 [Norm]
Alex: I think we have two kinds of things we have to worry about, output of regular steps and these "dangling" inputs.
15:47:15 [Norm]
Norm: I'm also worried about the choose component and dealing with branches that don't execute.
15:48:00 [Norm]
Henry: I thought about that too and I'm less worried. Outputs are always produced (crucially), the fact that it's input is plugged into the branch of a choose that doesn't execute can't matter.
15:48:32 [Norm]
Richard: The flow and pipe metaphor is unuseful in this case. It works much better to explain it in terms of a document being produced and saying that it will be availble if it is executed.
15:49:06 [Norm]
Alex: I think for-each and viewport have a similar but somewhat simpler story. So if we get it right it should work everywhere.
15:49:19 [Norm]
Alex: As a concrete exercise, can we think about those constraints.
15:49:54 [ht]
s/can't matter/can't matter, because the producer of the unused input might have side effects, and they must always happen/
15:50:11 [Norm]
Richard: Michael said earlier that conceptualizing this as a graph is very attractive, but it seems to me that it has not so far proved to be a useful way of describing the details.
15:50:45 [Norm]
Richard: In a regular programming language, this sort of problem never arises and that's an indication that perhaps it's not useful here.
15:50:53 [Norm]
Alex: I agree.
15:51:46 [Norm]
Norm: Perhaps that's the highest level take away from three weeks of discussion.
15:52:02 [Norm]
Richard: If we use graphs but they don't map to the semantics, Micheal will tell us we're being misleading, right?
15:52:23 [Norm]
Michael: It depends. I notice that lots of people draw pictures and can't actually tell you what the lines and symbols mean.
15:52:42 [Norm]
... If we have a coherent explanation of what the symbols mean, that might be sufficient.
15:53:09 [Norm]
... If they don't depict graphs, then we shouldn't say they are. We should say they "show the data flow" or something like that.
15:53:36 [Norm]
... There's a distinction between drawing something that is false and something that is a simplification.
15:54:02 [Norm]
Richard: Maybe we should instead say that even if we use graphs as diagrams, we shouldn't use it in any kind of prose if we aren't intending to be precise.
15:54:47 [Norm]
Richard: Perhaps we shouldn't say that a pipeline is a directed acyclic graph...I'd rather keep the lines and boxes as informal descriptions than to formalize them so that they are consistent with graph theoretic terms.
15:54:49 [ht]
s/use it/use formal graph-theory language/
15:54:50 [Norm]
Michael: It's not entirely clear to me that the complications Henry found it necessary to introduce are in fact necessary.
15:55:35 [Norm]
... If you just say that for any pipeline we can struct a graph with nodes and arcs, that's much simpler. That doesn't draw you a picture of parameter passing or flow of control, but as long as you don't say it does, you're not telling a lie.
15:56:58 [Zakim]
-Rui
15:57:00 [Zakim]
+[IPcaller]
15:57:08 [rlopes]
Zakim, [IP is Rui
15:57:08 [Zakim]
+Rui; got it
15:57:53 [ht]
q+ to offer one thing
15:58:22 [Norm]
Norm describes next steps: changes to the document to remove graph theoretic terms we aren't apparently comfortable with and another to propose areas where the spec needs more prose.
15:58:41 [Norm]
Henry: I'm going to take a stab at writing some class definitions for a few of the constructs.
15:58:49 [Norm]
... To see if the lessons I learned can be expressed in one way or the other.
15:58:53 [Zakim]
-Murray_Maloney
15:59:15 [Norm]
Alex: I'm going to try to recodify some of my constraints.
16:00:07 [Zakim]
-richard
16:00:09 [Zakim]
-Norm
16:00:10 [Zakim]
-Rui
16:00:11 [Zakim]
-ebruchez
16:00:12 [Zakim]
-PGrosso
16:00:13 [Zakim]
-MoZ
16:00:13 [Zakim]
-Alex_Milowski
16:00:15 [alexmilowski]
alexmilowski has left #xproc
16:00:24 [Zakim]
-MSM
16:00:30 [PGrosso]
PGrosso has left #xproc
16:00:59 [Norm]
Norm: I'll see what develops in email and publish an agenda next Wednesday either cancelling the call or proposing an agenda.
16:02:53 [Norm]
Adjourned
16:05:18 [Norm]
rrsagent, make logs world-visible
16:05:25 [Zakim]
disconnecting the lone participant, Ht, in XML_PMWG()11:00AM
16:05:27 [Zakim]
XML_PMWG()11:00AM has ended
16:05:28 [Zakim]
Attendees were Alex_Milowski, [IPcaller], Rui, PGrosso, Ht, Murray_Maloney, MoZ, richard, ebruchez, MSM, Norm
16:07:22 [Norm]
rrsagent, draft minutes
16:07:22 [RRSAgent]
I have made the request to generate http://www.w3.org/2006/09/28-xproc-minutes.html Norm
16:07:22 [Norm]
Chair: Norm
16:07:22 [Norm]
Scribe: Norm
16:07:22 [Norm]
ScribeNick: Norm
16:07:23 [Norm]
rrsagent, draft minutes
16:07:23 [RRSAgent]
I have made the request to generate http://www.w3.org/2006/09/28-xproc-minutes.html Norm
16:07:25 [Norm]
zakim, bye
16:07:25 [Zakim]
Zakim has left #xproc
17:47:29 [MSM]
MSM has joined #xproc
17:50:01 [MSM]
MSM has changed the topic to: XProc first public working draft published at http://www.w3.org/TR/2006/WD-xproc-20060928/
18:52:14 [Norm]
Norm has joined #xproc