14:55:50 RRSAgent has joined #xproc 14:55:50 logging to http://www.w3.org/2007/04/26-xproc-irc 14:56:10 Norm has changed the topic to: XProc WG: http://www.w3.org/XML/XProc/2007/04/26-agenda.html 14:56:32 Norm, unfortunately I'm only able to join today's conference on IRC and just for half an hour (schedule conflicts) 14:56:40 Meeting: XML Processing Model WG 14:56:40 Date: 26 Apr 2007 14:56:40 Agenda: http://www.w3.org/XML/XProc/2007/04/26-agenda.html 14:56:40 Meeting number: 65, T-minus 27 weeks 14:56:40 Chair: Norm 14:56:42 Scribe: Norm 14:56:42 PGrosso has joined #xproc 14:56:44 ScribeNick: Norm 14:56:46 Ok, thanks for letting me know, rlopes 14:59:55 XML_PMWG()11:00AM has now started 15:00:05 +[ArborText] 15:00:28 Zakim, what is the code ? 15:00:28 the conference code is 97762 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), MoZ 15:00:51 +Norm 15:00:55 ht has joined #xproc 15:01:14 +MoZ 15:01:20 zakim, hit me 15:01:20 I don't understand 'hit me', MSM 15:01:23 +Alex_Milows 15:01:38 zakim, please call MSM-Office 15:01:38 ok, MSM; the call is being made 15:01:39 zakim, please call ht-781 15:01:39 ok, ht; the call is being made 15:01:41 +MSM 15:01:42 +Ht 15:01:54 zakim, who's on the phone? 15:01:54 On the phone I see PGrosso, Norm, MoZ, Alex_Milows, MSM, Ht 15:01:57 +Alessandro_Vernet 15:02:13 richard has joined #xproc 15:02:45 +??P37 15:02:52 zakim, ? is me 15:02:52 +richard; got it 15:03:01 alexmilowski has joined #xproc 15:03:20 Regrets: Andrew, Rui 15:04:00 zakim, who's on the phone? 15:04:00 On the phone I see PGrosso, Norm, MoZ, Alex_Milows, Alessandro_Vernet, MSM, Ht, richard 15:04:23 Present: Paul, Norm, Mohamed, Alex, Alessandro, Michael, Henry, Richard 15:04:46 Topic: Accept this agenda? 15:04:46 -> http://www.w3.org/XML/XProc/2007/04/26-agenda.html 15:05:16 Amended with proposals from Alex, Norm, and Mohamed 15:05:23 Topic: Accept minutes from the previous meeting? 15:05:23 -> http://www.w3.org/XML/XProc/2007/03/19-minutes.html 15:05:28 Accepted. 15:05:31 Topic: Next meeting: telcon 3 May 2007 15:05:40 No regrets given. 15:05:43 I'll be off to Banff for WWW2007 15:05:48 Topic: Error vocabulary proposal 15:05:48 -> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0141.html 15:05:52 regrets for next 2 meetings 15:05:59 Thanks, rui 15:07:36 Norm: I think I should move name and type down from err:errors to err:error. 15:08:05 Rui: If we have a nested try/catch and the inner catch fails, what will the outer catch get? 15:08:15 what data stream is referred to in the line and column numbers? 15:08:28 All of them, maybe? 15:08:32 Henry: The error in the catch? 15:08:40 Rui: Yes, in the catch. 15:08:47 s/what/[what/ 15:08:57 s/column numbers?/column numbers?]/ 15:09:04 Henry: I think the catch should be transparent to the error and the outer try gets the failure as if the had occurred directly inside it. 15:09:17 MSM, The line/column are whatever the step thinks is helpful. 15:09:46 Rui: So the first error is lost and the outer catch gets the errors from the inner catch. 15:10:02 yes, that's what I was thinking 15:10:17 s/Rui/MoZ/ 15:10:34 Norm: I suppose we could say that all the errors are propagated upwards, but for V1, I'd rather not. 15:10:40 MoZ: Ok. 15:10:46 [MSM meditates on the utility of an XSLT processor (for example) giving two locations (in input, in stylesheet)] 15:11:15 Norm: Is everyone happy enough to put this in the next spec? 15:11:29 MoZ: Does #error contain a single document or a sequence? 15:11:34 Norm: A single document, I think. 15:11:52 MoZ: But the document may contain multiple error elements. 15:11:53 [MSM then wonders whether location info should be in a p:loc child of p:error, rather than in attributes ... or perhaps that's just too complicated?] 15:11:53 Norm: Yes. 15:13:08 Michael: Do we want to consider allowing a step to provide multiple locatoins? 15:13:13 s/locatoins/locations/ 15:13:28 Henry: Maybe an alternative way would be to allow the error element to contain error elements. 15:13:46 Michael: It's not forbidden, so we could allow it. 15:14:14 Henry: I think most of the XML vocabularies do use attributes for this. 15:14:36 MoZ: For the location, if we are doing some streaming, it's not obvious that the SAX API give the location every time. 15:15:22 Norm: I think the location information is optional; not all steps will always be able to give it. 15:15:42 MoZ: That's why I was supporting MSM, so that we could have an other mechanism to identify the location. 15:15:53 MSM: There's nothing that prevents you from putting a different location in the content of the error. 15:16:42 MSM: If you have a specialized way of identifying a location, that's OK, we just don't expect the framework to understand it. 15:16:56 MSM: Having thought about it now for a few minutes, I think this is probably OK. 15:17:19 +1 15:17:26 Norm: I guess what I'd like to suggest is that we go with this for the next draft and see if real world experience makes us want to change it. 15:17:30 [p:code optional? No - better to require that people define an ERROR U000 miscellaneous unknown catastrophe] 15:18:01 MSM: We have href/line/column optional, but is code really supposed to be optional? 15:19:08 Norm: I think for components that don't have defined errors, there's no point insisting on a bogus error code. 15:19:20 Accepted, as amended above. 15:19:26 Topic: Select vs. match in steps 15:19:26 -> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0137.html 15:20:22 http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0142.html 15:21:51 Henry: Why is it only the outer match that gets selected? 15:21:55 Norm: Consistency with p:viewport. 15:22:15 Henry: In the p:viewport case, there's nothing there to match, that's why. The same is true of delete and replace. 15:22:26 Henry: In the rename case, you can continue processing the subtree. 15:23:12 Henry: I'd hate to have to write select expressions all over the place when I just want to hit all the elements that match a pattern. 15:23:33 Henry: In the markup pipeline, all of these components use match semantics and no one has ever complained. 15:23:48 Norm: You could sell me either way. 15:24:46 Alex: I'm looking at these two renames and I think the select version looks really strange. 15:24:59 Alex: I'd prefer to use match here. 15:25:05 This one surely looks simpler: 15:25:07 15:25:07 15:25:07 15:25:07 15:26:32 -MoZ 15:26:38 Henry: I really really really think people are going to want to write that. 15:27:35 Richard: I agree that people will want to write these short things, but there are cases that are hard with match; I'd prefer to have both. 15:27:46 Richard: The first para of a book, for example. 15:27:51 +MoZ 15:28:12 (//p)[1] 15:28:52 p[not(preceding::p)] 15:29:02 Norm: You're suggesting that it should use select or match 15:29:20 Richard: I agree that having both would be extra work, but it would be obvious. 15:29:26 Alex: I could live with boht. 15:29:29 s/boht/both/ 15:29:44 Mohamed: Is there really some matching pattern that we really cannot have with match that we can have with select. 15:30:57 Norm: So I'm hearing a consensus that we want both on some. 15:31:00 Henry: Yes. 15:31:44 Henry: I note that there's a very substantial set of match patterns that's easy to stream and select patterns tend to be much harder. I suspect that getting interop on the select side is going to be harder. 15:32:23 Richard: I'm not convinced by that because you can look at a select pattern and determine if it's really a match. Then you're in the same case. 15:32:48 Alex: If you're going to worry about the streaming in all these components, you can't do it in the general case. 15:33:16 ...The reality is, are we making it harder for the implementor that can only stream in one case. 15:33:45 Richard: If we had a way of asserting that something was streamable, then I'd think Henry has a point. But we don't, so you have to test pattern. 15:33:57 Alex: You could just say that if you use select, you lose. 15:34:08 -MoZ 15:34:11 Alex: People interested in streaming are already interested in a subset of XPath. 15:34:29 (really a subset of XProc) 15:34:52 Alex: I'm in favor of putting both options on all these components. 15:35:11 +MoZ 15:35:40 +1 for both on some 15:35:58 agree with Henri's position for delete and replace 15:37:32 Norm: Only on some? 15:37:52 MoZ: I think that both makes sense on rename, but for delete and replace, I really like the fact that it's the same as viewport. 15:38:01 Norm: But I think that anything that's true of rename is true of delete. 15:38:47 what about delete //*/@id ? 15:39:07 MoZ: I'd prefer to be consistent with viewport than with components. 15:39:30 Alex: I'm not sure I see an inconsistency. They have some similarity to viewport, but they're more similar to themselves. 15:39:47 @id[count(parent::*)=1] 15:39:55 sorry 15:39:59 zakim, who's on the phone? 15:39:59 On the phone I see PGrosso, Norm, Alex_Milows, Alessandro_Vernet, MSM, Ht, richard, MoZ 15:40:06 @id[count(parent::*)>1] 15:40:15 Richard: I didn't understand Alex's example. 15:40:30 Alex: If I want to delete all ID attributes, there are lots of ways to write that as a select or match pattern. 15:40:50 Alex: My point is that if we're not putting a huge burden on implementors, then it's a question of what authors find easier. 15:41:00 Alex: We should make things easier for authors. 15:43:08 Richard: I feel I should point out that //*/@id is a match pattern. You're allowed to write rooted match patterns. 15:44:20 Richard: It is slightly tedious to implement delete when you might get back lists of nodes that contain descendants. 15:44:54 Straw poll: Should we allow both select and match patterns on all of the microcomponents? 15:46:27 Yes: 3, No: 3, Abstain: 2 15:46:41 Norm: I suggest we take this to email and come back to it in a week 15:47:05 Paul: The last email I saw was Norm proposing which one's use select and which one's use match. 15:48:12 Norm: Yeah, I just abstained in the hope it would help get consensus. 15:48:23 Norm: We need to get to last call. 15:48:29 Henry: I think each of these does merit discussion. 15:49:18 Topic: p:error proposal 15:49:18 -> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0114.html 15:49:42 Accepted. 15:50:09 Topic: p:tee proposal 15:50:09 -> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0138.html 15:50:30 Henry: I like the idea, but I hate the name. 15:51:08 ...The only thing I would consider as an alternative is to be able to annotate any connection with a URI. 15:51:35 ...This is mostly for debugging. Maybe we should try for something even lighter weight. 15:51:56 ...Adding an optional journal, log, or URI attribute to some elements. 15:51:57 +1 for henry's proposal, it is a debuging feature and should be thought more broadly 15:52:23 Alex: Any implementor could provide features to do this. 15:53:34 @p:use-output="..href.." 15:53:49 ACTION: Henry to look at the language and see if a broader debugging proposal can be made. 15:54:08 Topic: p:string-replace proposal 15:54:08 -> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2007Apr/0132.html 15:55:44 Alex: For attributes it replaces the string value; for elements it should replace the descendants, yes? 15:55:49 Norm: Hmmm. Maybe. 15:56:15 Henry: Wait. We have to address the case where the delete component ends ../text(). 15:56:28 Alex: It deletes all the text nodes. 15:57:37 Henry: Given that you can write text() at the end of the pattern, whether that allows us to clarify the question about the diffrence between elements and attributes. 15:58:23 Norm: I think I want attributes to be treated specially. 15:59:32 Henry: So we can write .../foo or ../foo/node() for the two cases. 16:00:08 Alex: If you say text() shouldn't it merge adjacent text nodes. 16:00:12 Norm: Yes. 16:01:41 Norm: Do we have consensus to add string-replace? 16:01:45 Accepted. 16:01:53 Topic: Any other business 16:02:37 -Ht 16:02:44 None. 16:02:49 -richard 16:02:50 -Norm 16:02:51 -Alex_Milows 16:02:53 Adjourned 16:02:53 -MoZ 16:02:55 -PGrosso 16:02:56 -Alessandro_Vernet 16:02:57 PGrosso has left #xproc 16:02:59 rrsagent, make logs world-visible 16:03:00 -MSM 16:03:02 XML_PMWG()11:00AM has ended 16:03:02 rrsagent, draft minutes 16:03:02 I have made the request to generate http://www.w3.org/2007/04/26-xproc-minutes.html Norm 16:03:04 Attendees were PGrosso, Norm, MoZ, Alex_Milows, MSM, Ht, Alessandro_Vernet, richard 16:05:06 rrsagent, draft minutes 16:05:06 I have made the request to generate http://www.w3.org/2007/04/26-xproc-minutes.html Norm 16:05:25 rrsagent, make logs world-visible 16:05:29 rrsagent, draft minutes 16:05:29 I have made the request to generate http://www.w3.org/2007/04/26-xproc-minutes.html Norm 16:05:48 Nevermind, ht 16:08:59 avernet has left #xproc 17:43:33 Zakim has left #xproc 18:03:30 Norm, JimM is looking for you on xquery. 18:03:33 You might want to go there. 18:03:36 Ok. 18:03:37 Or you might want to hide. 18:03:39 Your call.