14:58:02 RRSAgent has joined #xproc 14:58:02 logging to http://www.w3.org/2014/03/05-xproc-irc 14:58:18 Norm has changed the topic to: XProc WG meeting http://www.w3.org/XML/XProc/2014/03/05-agenda 14:58:42 rrsagent, set logs world-visible 14:58:42 Meeting: XML Processing Model WG 14:58:42 Agenda: http://www.w3.org/XML/XProc/2014/03/05-agenda 14:58:42 Date: 5 Mar 2014 14:58:42 Meeting: 244 14:58:43 -Chair: Norm 14:58:45 Scribe: Norm 14:58:47 ScribeNick: Norm 14:59:02 zakim, passcode 14:59:02 I don't understand 'passcode', Norm 14:59:04 alexmilowski has joined #xproc 14:59:09 zakim, passcode? 14:59:09 sorry, Norm, I don't know what conference this is 14:59:15 zakim, this will be xproc 14:59:17 ok, Norm; I see XML_PMWG()10:00AM scheduled to start in 1 minute 14:59:19 zakim, passcode? 14:59:19 the conference code is 97762 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Norm 14:59:23 jfuller has joined #xproc 14:59:38 XML_PMWG()10:00AM has now started 14:59:44 +Norm 15:00:47 +Alex_Milows 15:01:02 +[IPcaller] 15:01:24 zakim, +ipcaller is jfuller 15:01:24 sorry, Norm, I do not recognize a party named '+ipcaller' 15:01:30 zakim, +[ipcaller is jfuller 15:01:30 sorry, Norm, I do not recognize a party named '+[ipcaller' 15:01:34 zakim, ipcaller is jfuller 15:01:34 +jfuller; got it 15:02:08 Vojtech has joined #xproc 15:02:43 ht has joined #xproc 15:02:51 +[EMC] 15:03:01 zakim, emc is me 15:03:01 +Vojtech; got it 15:03:53 +??P10 15:03:59 zakim, ? is me 15:03:59 +ht; got it 15:05:07 zakim, mute ht 15:05:07 ht should now be muted 15:05:15 that was audio, sort of! 15:05:23 it was like a freight train whistle 15:05:28 try again, ht 15:07:34 still working ht? 15:07:48 Losing still 15:07:57 I'm sorry, I was busy right up until the top of the hour 15:08:01 Go ahead w/o me 15:08:28 ok 15:08:32 -ht 15:09:03 Topic: Accept this agenda? 15:09:03 -> http://www.w3.org/XML/XProc/2014/03/05-agenda 15:09:10 Accepted 15:09:16 Topic: Accept minutes from the previous meeting? 15:09:21 Norm: Except there aren't any 15:09:31 Topic: Next meeting: 12 Mar 2014 15:09:46 No regrets given 15:10:25 Topic: Bugs against 1.0 15:10:41 Norm: I want to do a few bugs each week. 15:11:00 ht_home has joined #xproc 15:11:16 Topic: Bug 21015 15:11:25 -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21015 15:13:03 ht2 has joined #xproc 15:13:03 view source on http://tests.xproc.org/tests/required/err-d0026-004.xml 15:13:21 Norm: I think Tim's right. If you never need to evaluate $var, then you may never get the error 15:13:28 Norm: I propose to rewrite the test so that $var is needed. 15:14:05 Vojtech: We say that the names and values are added to the environment; I guess that doesn't preclude lazy evaluation but i guess it depends how you read that. 15:14:23 Norm: I don't think we want to forbid lazy eval. 15:14:38 Vojtech: I agree. 15:14:45 Norm: Any objections to my proposal? 15:15:05 None heard. 15:15:19 Topic: Bug 20135 15:15:24 -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21035 15:15:41 ht has joined #xproc 15:16:43 +??P11 15:17:24 Norm: I think we added XD0030 as an escape hatch; we don't want to forbid steps from giving more specific errors 15:17:35 Jim: Is he saying that other errors should be bubbling up instead? 15:18:29 Norm: I think Tim thinks that errors should be consistent across impls; we don't say that. 15:21:40 Norm proposes: 15:21:41 The WG's position has been that errors do not have to be consistent across implementations; that was viewed as too large a burden to impose. The spec, alas, appears not to say that anywhere. We'll fix that. 15:21:41 The error XD0030 is a "standard" escape hatch for errors that don't have a more specific error code. Impls are free to provide more specific/better error codes. We suggest such codes for some errors in some steps. 15:21:54 we have http://tests.xproc.org/tests/required/err-d0030-001.xml 15:21:56 and 15:21:59 http://tests.xproc.org/tests/required/err-d0030-002.xml 15:22:47 Norm: Anyone unhappy with my comment? 15:23:03 Jim: To be clear: if we have no support for the xsl formatter step, and this step runs, we want an XD0030 15:23:15 Vojtech: No, there's a different error for "unsupported atomic step" 15:23:27 Norm: Both of those tests are bogus 15:23:56 Vojtech: Another thing that Tim mentions in that bug is that he would like to be able to catch a specific XQuery error code. 15:23:56 ...We don't provide that. 15:24:44 Norm: You only get one catch bucket in V1 but you can test for the error you got. 15:24:56 Vojtech: But the errors are implementation defined. 15:25:08 Norm: Yes. Well, mostly. We specify a few errors. 15:25:13 ...We could have done better. 15:25:18 ...Maybe we can do better in Vnext 15:25:56 Vojtech: Maybe we can make well defined error codes more visible. 15:27:22 Norm: Are we happy with my comment? 15:27:24 No objections heard. 15:27:34 +1 to Norm's comment 15:27:55 -jfuller 15:28:00 Topic: Parameters proposal 15:28:19 +[IPcaller] 15:28:27 back 15:28:32 Norm asks about the parameters proposal 15:29:19 Vojtech: It took me a while to understand it. Maybe I still don't completely understand it. My feeling is that if you depend on third party pipelines, you're limited by what they provide. 15:29:35 ...Even if it's hidden to you as a top level consumer, you still have to learn about that. 15:30:00 ...My main worry is that you'll end up in a situation that's a mess. 15:30:12 ...On the other hand, I like other things about it a lot. It simplifies a lot of things. 15:30:46 ...The pipeline doesn't declare any of the parameter maps that it expects. 15:31:42 Norm: I think an empty parameter map is always an option 15:32:01 Vojtech: Suppose that you don't have any parameters, but you use a third party library that runs XQuery or XSLT 15:32:28 ...In V1, you know that the third party pipeline has three parameter input ports and you know how they're used. 15:32:41 ...In the current proposal, there's no way to declare that. There's no contract. 15:33:05 ...I as a user have no control over that. 15:33:48 ...A simple pipeline that doesn't import anything, one that runs a query, a stylesheet, and an XSL formatter. You may want to pass different parameters to all of them. 15:34:06 Jim: I think this is a classic engineering balance question. 15:34:29 Vojtech: In V1, the parameters are crazy to use but it's clean in the sense that it's maintainable. 15:34:56 ...A step declares what it expects. With this situation, there's something going on that you have no control over. And you can't work around it. 15:35:22 Alex: I hear two things: one is the ability to scope and control the parameters... 15:35:28 Vojtech: I think that's my main concern 15:35:43 Alex: ...and there's also the question of declaring the maps that get used. 15:35:46 zakim, mute me 15:35:46 Norm should now be muted 15:36:05 Vojtech: You don't really know, you have to look at the source code. And at the source code of all the imported pipelines. 15:36:40 zakim, unmute me 15:36:40 Norm should no longer be muted 15:37:48 Some discussion of how steps get parameters. 15:40:26 Alex: My concern is that we're going to have to eventually say that parameter maps are in the context and you're not supposed to use them. 15:41:02 Norm: They're in the pipeline's context, not the step context. The pipeline knows lots of things that the steps can't see. 15:41:09 Vojtech: We're throwing away any kind of scoping. 15:41:15 Norm: Yep. 15:42:41 Alex: That's the other issue. Somewhere deep within the pipeline you're importing, there's a reference to the default parameter map. You can't override that when you call it. 15:43:05 ...That's the concern. 15:43:58 Alex: I want to be able to say "at this point, new scope, I don't want any parameters." 15:44:26 Norm: Maybe we need some way to deal with that. 15:45:32 Henry: I don't want to go there until I see a real use case. We've perfectly reasonably circled back around to where we were about 3/4 of the way through the discussion in Edinburgh. 15:45:57 ...I agree that in principle, you could get into trouble, but I'd like to see a practical use case. I don't think we need it. 15:46:04 Alex: I'm on the fence, I think we should be aware that it's something we can't do. 15:46:26 Norm: Fair enough, the spec for this certainly should make clear what it's deficiencies are. 15:47:00 Alex: The analogous case for code is I write a library that uses a global variable and bad things happen. Don't do that. Could you say that's a poorly written library? Possibly. 15:47:43 ...If you don't want magic, then you have to make explicit calls. 15:48:06 Vojtech: Maybe there's a story that's in between. There's some magic in the pipeline, but at the step boundaries there isn't. 15:48:48 Norm: There's nothing that prevents a pipeline author from doing better. 15:50:50 ...You can control all the parameters, what you don't get is after-the-fact control over a third party pipeline that wasn't written carefully. 15:51:07 Alex: Unintended things can happen if you use a library that was written carelessly. 15:51:14 ...that's just a fact of life. 15:51:37 Vojtech: Since we're adopting the map type, and we will have AVTs. Why do we need to have this mechanism at all? 15:51:59 ...If you want to pass parameters, just use options that are maps. 15:54:04 Some discussion of other mechanisms 15:54:57 Jim: The main reasons why we have a difference today is that because we might not know the name. 15:54:58 Vojtech: Yes, but maps solve that problem. 15:57:06 Topic: Any other business? 15:57:13 None heard. 15:57:19 Adjourned. 15:57:22 -Alex_Milows 15:57:24 -[IPcaller] 15:57:24 -Vojtech 15:57:28 -Norm 15:57:43 rrsagent, draft minutes 15:57:43 I have made the request to generate http://www.w3.org/2014/03/05-xproc-minutes.html Norm 15:57:54 -ht 15:57:56 XML_PMWG()10:00AM has ended 15:57:56 Attendees were Norm, Alex_Milows, jfuller, Vojtech, ht, [IPcaller] 15:58:57 Present: Norm, Alex, Vojtech, Jim, Henry 15:58:57 rrsagent, draft minutes 15:58:57 I have made the request to generate http://www.w3.org/2014/03/05-xproc-minutes.html Norm 15:59:19 chair: Norm 15:59:21 rrsagent, draft minutes 15:59:21 I have made the request to generate http://www.w3.org/2014/03/05-xproc-minutes.html Norm 16:07:31 alexmilowski has joined #xproc 17:11:30 ht has left #xproc 18:01:56 Zakim has left #xproc