13:56:05 RRSAgent has joined #xproc 13:56:05 logging to http://www.w3.org/2014/03/19-xproc-irc 13:56:10 zakim, this will be xproc 13:56:11 ok, Norm; I see XML_PMWG()10:00AM scheduled to start in 4 minutes 13:56:22 rrsagent, set logs world-visible 13:56:22 Meeting: XML Processing Model WG 13:56:22 Agenda: http://www.w3.org/XML/XProc/2014/03/19-agenda 13:56:22 Date: 19 Mar 2014 13:56:22 Meeting: 245 13:56:23 Chair: Norm 13:56:25 Scribe: Norm 13:56:27 ScribeNick: Norm 13:59:16 zakim, passcode? 13:59:17 the conference code is 97762 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Norm 13:59:39 XML_PMWG()10:00AM has now started 13:59:44 +Norm 14:00:42 +??P9 14:01:05 zakim, ??P9 is ht 14:01:05 +ht; got it 14:01:38 ht has joined #xproc 14:02:00 Vojtech has joined #xproc 14:02:20 ok, ht, but if you need to say something you may have to type it :-) 14:02:28 (did you hear what I said to you?) 14:02:36 +[EMC] 14:02:43 zakim EMC is Vojtech 14:02:44 zakim, emc is me 14:02:44 +Vojtech; got it 14:03:43 +Alex_Milows 14:03:51 zakim, who's here? 14:03:51 On the phone I see Norm, ht (muted), Vojtech, Alex_Milows 14:03:53 On IRC I see Vojtech, ht, RRSAgent, Zakim, Norm, jfuller, liam 14:04:05 coming 14:04:07 Present: Norm, Henry, Vojtech, Alex 14:04:09 2 more mins 14:04:38 alexmilowski has joined #xproc 14:04:45 lol 14:04:58 Topic: Accept this agenda? 14:04:58 -> http://www.w3.org/XML/XProc/2014/03/19-agenda 14:05:05 Accepted. 14:05:09 Topic: Accept minutes from the previous meeting? 14:05:09 -> http://www.w3.org/XML/XProc/2014/03/05-minutes 14:05:16 Accepted. 14:05:31 Topic: Next meeting: 26 Mar 2014 14:05:42 No regrets heard. 14:05:51 Vojtech gives regrets for 26 Mar 14:06:07 + +420.7.332.2.aaaa 14:06:20 Topic: Review of open action items 14:06:25 I am here 14:06:26 Norm has done some of his, see the errata document 14:06:33 Present: Norm, Henry, Vojtech, Alex, Jim 14:06:50 Topic: Review response to bug 21005 14:07:05 -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21005 14:12:35 Jim proposes adding a may requirement to make static compilation possible. 14:12:42 Norm proposes that it should be a should at least. 14:15:41 Norm muses about why we have "optional options". In XPath 2.0 I think we have more leeway because we can say that the default value is the empty sequence. 14:20:02 -ht 14:20:36 +??P0 14:21:31 The fact that XProc 1.0 conflates the notion of variable binding 14:21:31 across the static and dynamic contexts means that attempting 14:21:31 to compile XPath expressions in a purely static way will still 14:21:31 require determining whether or not there are bindings for all 14:21:32 the variables at runtime. 14:22:04 +1 14:22:17 +1 14:22:24 s/variables/XPath variables/ 14:22:36 +1 14:22:45 or /variables in the expression/ 14:24:05 Norm: I added that to the bug. We'll see what the commenter says and get back to adding errata shortly. 14:24:49 Topic: Review proposed errata 14:24:57 -> http://htmlpreview.github.io/?https://github.com/xproc/specification/blob/xproc10/10errata/proposed.html 14:25:28 Vojtech: The first comment I had was about p:choose; 14:25:52 -> http://lists.w3.org/Archives/Public/public-xml-processing-model-wg/2014Mar/0016.html 14:25:57 Vojtech explains. 14:26:07 Norm: I think you're correct. 14:29:02 'to invoke' 14:29:03 ? 14:38:47 jfuller has joined #xproc 14:39:39 Vojtech: Sometimes we say 'connected' and sometimes we say 'bound' and we don't clearly define those terms. 14:39:52 Henry: I agree absolutely. 14:40:05 Vojtech: Does connected meaning consumed or consuming? 14:40:08 "If a (non-primary) output port of a compound step is left unconnected" 14:40:09 Norm: I have an action to fix that. 14:40:27 "An output port may have more than one connection: it may be connected to more than one input port," 14:40:50 Norm: But I hadn't seen the connection to bound. 14:41:05 Vojtech: In 2.2 you end up with a different picture depending on which side you look at. 14:41:41 Henry: In 2.2, three paragraphs apart, one use of connection is pull and one is push. 14:41:50 So I'm glad to hear that Norm has an action to fix this 14:42:31 Vojtech: Another distinction between connected and bound: for output ports it is an error if they remain unconnected. That made me realize that connected means being consumed. 14:42:42 Norm: It just means ... connected 14:43:17 Vojtech: If you look at it from an implementation standpoint, pull or push, it can be different. 14:43:33 Not just connected -- for _compound_ steps, the output port can be connected twice 14:43:40 ... Once to pull its value 14:43:47 ... The other to push its value 14:44:38 Norm: Thank you, I see the problem more clearly now. 14:44:58 Yes, yes we are 14:45:20 Topic: Bugs against 1.0 14:45:42 -> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21053 14:47:50 In the p:wrap case, unless you wrap "/", it doesn't change. Right? 14:47:50 what does p:base-uri() return 14:47:58 s/it/the base URI/ 14:48:02 Base URI changes all over a document 14:48:22 If you mean the base URI property in the infoset 14:49:15 In the p:wrap case, unless you wrap "/", the base URI property of the document in the infoset doesn't change. 14:49:19 Do we agree with that? 14:49:58 NOOOOIO 14:50:54 Because it's _elements_ that have base URIs! 14:51:09 Don't document infoset items have base URIs? 14:52:13 Vojtech: It feels to me that in p:wrap-sequence alone, if you wrap a single document or 10 the base URI of the result should be consistent. 14:53:15 Norm: in the wrap-sequence case where we're creating a whole new document with a new root element 14:53:19 Alex: I think it should be emtpy 14:53:23 s/emtpy/empty/ 14:53:25 NOTE: This is wrong, in the def'n of p:xinclude: "The included documents are located with the base URI of the input document and are not provided as input to the step." 14:53:51 We're not talking about document URI 14:55:01 +1 14:55:07 Norm: I think I heard "empty" as the proposed value for base-uri from p:wrap-sequence, does anyone disagree? 14:55:08 None heard. 14:55:29 Norm: I think a p:wrap that wraps "/" should behave exactly like p:wrap-sequence on that document, does anyone disagree? 14:55:44 None heard. 14:55:50 Note that that is _only_ on the document node and the document element node 14:57:05 Henry: We need to fix XInclude. We're being too glib in talking about base-URIs. All of the elements in the document potentially have base-uri properties. 14:57:07 We shouldn't think about fixing this without doing fixup. 14:57:42 Henry: the part about the base-uri property is that it provides the base for resolving URI references. 14:57:58 ...It doesn't get copied but you have to look up the chain to your ancestors until you find a base URI 14:58:11 base uri fixup reference - http://www.w3.org/TR/2004/REC-xinclude-20041220/#base 14:58:24 ...What that makes me think is that the result should have a base URI on the document node and that's it. 14:59:05 ...It follows that if you wrap it, in order to make the relative references work, you should copy the base URI onto the element that used to be the document element and is now submerged. 14:59:47 Alex: If you think of it conceptually, they're equivalent to "this XInclude" where this document has no URI/base-uri. Or it's embedded. 14:59:54 ...I wonder if the outcome is similar. 15:00:08 ...If you look at it from an XInclude perspective is it similar, is it the same. 15:00:11 the right base uri fixup reference - base uri fixup reference 15:00:17 http://www.w3.org/TR/xinclude/#base 15:00:40 ...It would be nice if these things could work in the same way. We need to think this through more carefully. 15:01:05 Norm: I'll make this base URI question an explicit agenda item for next week. 15:01:05 Topic: Any other business? 15:01:10 Adjourned. 15:01:14 - +420.7.332.2.aaaa 15:01:15 -Alex_Milows 15:01:16 -Vojtech 15:01:18 -Norm 15:01:41 rrsagent, draft minutes 15:01:41 I have made the request to generate http://www.w3.org/2014/03/19-xproc-minutes.html Norm 15:03:15 -ht 15:03:17 XML_PMWG()10:00AM has ended 15:03:17 Attendees were Norm, ht, Vojtech, Alex_Milows, +420.7.332.2.aaaa 15:03:37 Man, this sucks 15:04:14 Yeah. 15:04:19 xml:base doesn't give the [base URI] property any standing at all, afaics :-( 15:04:33 How do you mean? 15:04:34 xml:base the spec., that is 15:04:38 Have a look 15:05:00 It says the base URI of an element is the value of its xml:base attr, otherwise the base of its parent. . . 15:05:18 And the only way parents get bases is by being 'read' from them 15:05:31 I need to look at xinclude now, hold on 15:06:20 Right 15:06:51 Any change in the [base URI] property that matters has to be reflected in a (synthesised if necessary) xml:base attribute 15:07:48 So XInclude does the right thing 15:07:49 I'll try to find some time to review this whole question. . . 15:07:51 Yes 15:08:07 And we would need to do it too, e.g. in the wrap-sequence case as discussed 15:08:09 Ok. That'd be good. I'll try to construct some explicit examples and send them to the list as fodder for discussion 15:08:23 Every former document element would need an xml:base attribute added 15:08:42 Yes, that's probably the right answer 15:08:43 s/would need/might need/ 15:12:59 alexmilowski has joined #xproc 15:32:38 alexmilowski has joined #xproc 16:13:39 ht has left #xproc 17:26:37 Zakim has left #xproc