16:41:00 RRSAgent has joined #xproc 16:41:00 logging to http://www.w3.org/2009/11/02-xproc-irc 16:41:04 Zakim, this will be xproc 16:41:04 ok, Norm; I see XML_PMWG(TPAC)11:30AM scheduled to start 11 minutes ago 16:41:26 Meeting: XML Processing Model WG 16:41:26 Date: 2 Nov 2009 16:41:26 Agenda: http://www.w3.org/XML/XProc/2009/11/02-agenda 16:41:26 Meeting: 159 16:41:26 Chair: Norm 16:41:27 Scribe: Norm 16:41:29 ScribeNick: Norm 16:53:00 Hi MoZ 17:09:38 MoZ, let us know if/when you'd like to be on th ephone? 17:09:39 Vojtech has joined #xproc 17:17:58 Topic: 169 XQuery and statically known namespacesw 17:18:04 s/namespacesw/namespaces/ 17:18:09 Vojtech: What does p:namespaces mean there? 17:18:23 Norm: That's clearly just a cut-and-paste error, that can't have any meaning. 17:19:00 Norm: That leaves "The namespace declarations in-scope for the containing element". 17:19:18 Vojtech: What is that, the p:xquery, the c:query, or something else? What about inline vs. external queries? 17:19:24 Norm: Right. 17:19:41 Norm: I see three choices: 17:19:49 ...1. We could say it's the p:xquery element 17:19:59 ...2. We could say it's the c:query element, or 17:20:24 ...3. We could decide this was a mistake and just leave it "implementation defined" (per XQuery itself) and say that users have to declare new namespaces if htey want to use them in their query. 17:22:03 Vojtech: I've implemented 2, it's not hard. 17:22:17 Norm: Looking casually at my code, I seem to ahve implemented 3. 17:23:11 Norm: If you have an inline query, it makes some sense to take the namespaces declared "above you" 17:23:21 ...If you have an external query, then either you have to do this: 17:23:41 ...for $f in //foo:bar... 17:23:53 ...or this: declare namespace foo="http://..."; for $f in //foo:bar... 17:24:02 There's not a lot of value in taking them from the query in the external case. 17:24:59 Vojtech: What about conflicts, if you have something from the environment that's declare differently by the query 17:25:13 Norm: I think XQuery says that the ones explicitly declared win, but whatever it says, that problem already exists. 17:26:35 Norm: I'm inclined to say that using the bindings on p:xquery is the right thing. Or saying you don't get any at all. 17:28:54 Norm: What about the case where the p:xquery step is in a p:for-each. If the bindings come from the c:query element, then potentially the static context has to be reinitialized for each iteration of the loop. 17:29:08 ...I think right now you can instantiate the step and its static context once and use it over and over again. I think that's a good thing. 17:30:43 Vojtech: If we say that the bindings on the p:xquery would be used, it would be the first time we've done that in XProc. No other step behaves that way. 17:30:56 Norm: Well. Yes and know, those are used for things like shortcut options. 17:31:42 We can come back to this when Henry arrives. 17:32:19 Topic: 173 Change p:system-property to return an untyped atomic 17:32:37 Norm: Nevermind, this no longer makes any sense given the changes we made to the p:version system property. 17:33:37 Norm: Now I'll use p:version-available or construct a string based test of the p:version system property. 17:33:51 Topic: 175 Subtlety about p:xquery 17:34:36 Norm: On closer examination, this is editorial. And yes, Florent is right. 17:34:46 Instruct the editor to fix it. 17:35:11 Topic: 174 p:instruction-available() 17:37:15 Norm: I think that version-available is sufficient granularity. 17:37:43 Vojtech: Would this work for things in other namespaces? 17:37:55 Norm: Maybe, but we don't really let you put in your own stuff in arbitrary places. 17:38:04 Vojtech: Use-when is going to get used for other things. 17:38:31 Norm: A new function can be added in a later version, if a new class of these things really develops. The current non-step elements are pretty random, they don't form any sort of meaningful class in my mind. 17:39:39 Proposal: For V1.0, version tests are sufficiently granular. Keep the status quo. 17:41:44 Vojtech: What about testing for serialization options: is XML 1.1 available? 17:41:46 Norm: Yeah. 17:41:53 Vojtech: I think the function would be really complicated. 17:41:59 Norm: For V1.0 can we live with testing vendor strings? 17:42:58 ...It seems like an area that might be useful some day, but I'm not sure I want to add a whole raft of functions just to test serialization options. 17:53:49 Topic: 168 A imports B, B imports A 17:54:05 Vojtech: We say that circular imports are not allowed, but we describe how to deal with it. 17:55:58 Henry notes that it seems odd to forbid them. 17:56:15 Norm: I think we thought it would be an error, but in the light of re-entrancy, it probably shouldn't be. 17:58:12 Norm: It matters in XSLT because XSLT allows multiple definitions of the same thing. They get sorted in "import priority" order. 17:58:21 ...So if XSLT allowed circularity, they'd never bottom out. 17:58:50 ...We don't allow redefinition of the same step types, so I think we can allow circularity as a special case of re-entrancy. 17:59:11 Vojtech: So remove the static error. 17:59:14 Norm: Yes. 18:02:50 Topic: 170 Test p:import #006 18:03:01 Norm: I have mixed feelings about this one, but I think the answer is probably correct. 18:03:11 Norm: I wrote the spec the way I did because it wasn't clear that implementations would be able to tell. 18:03:24 ...But in fact, they have to for things like XInclude, so maybe we've already crossed this bridge. 18:06:38 Topic: Test suite coverage 18:06:52 Vojtech: I think we're still missing some tests for validation steps. 18:07:49 ...And I don't think we have tests for all the http-request options (multipart bodies and such) 18:20:00 Norm: (reviewing the coverage report) We're in remarkably good shape 18:24:42 XML_PMWG(TPAC)11:30AM has now started 18:24:49 +MoZ 18:26:25 s/ahve/have/ 19:04:53 Norm has joined #xproc 19:05:13 Cool ! Coffee did eventually end ! 19:06:26 Norm: I'm on Zakim since 42 minutes 19:09:42 Hi MoZ 19:10:19 Hi Norm, looks like you add a *french* coffee break :) 19:10:29 s/add/had/ 19:11:02 So you want to dial in? 19:11:07 What was french about it? 19:11:19 I'm already on Zakim, since 46 minutes 19:11:38 Zakim, call xproc 19:11:38 I am sorry, Norm; I do not know a number for xproc 19:11:51 oh, you're on the bridge. go tit. 19:11:56 s/go tit/got it/ 19:12:14 now if only I could figure out how to make zakim call *me* 19:12:50 it looks like the other group do Zakim, call Salon_5 19:13:04 ht has joined #xproc 19:13:28 So if you know the name of the room then it should work 19:13:43 Zakim, call suite_2 19:13:43 I am sorry, Norm; I do not know a number for suite_2 19:13:47 Zakim, call suite_1 19:13:47 I am sorry, Norm; I do not know a number for suite_1 19:13:53 Zakim, call salon_2 19:13:53 ok, Norm; the call is being made 19:13:55 +Salon_2 19:14:03 oops. I guess that wasn't me. 19:14:05 Zakim, hang up 19:14:05 I don't understand 'hang up', Norm 19:14:12 Zakim, bye 19:14:12 leaving. As of this point the attendees were MoZ, Salon_2 19:14:12 Zakim has left #xproc 19:14:14 Zakim has joined #xproc 19:14:51 Zakim, call suite_2 19:14:51 sorry, Norm, I don't know what conference this is 19:15:01 Zakim, call tag 19:15:01 sorry, Norm, I don't know what conference this is 19:15:05 Zakim, this is xproc 19:15:05 ok, Norm; that matches XML_PMWG(TPAC)11:30AM 19:15:07 Zakim, call tag 19:15:07 I am sorry, Norm; I do not know a number for tag 19:15:24 Zakim, who is there? 19:15:24 I don't understand your question, MoZ. 19:15:25 Zakim, this is tag 19:15:26 sorry, Norm, I do not see a conference named 'tag' in progress or scheduled at this time 19:15:30 Zakim, this will be tag 19:15:30 I do not see a conference matching that name scheduled within the next hour, Norm 19:15:45 Zakim, this is xproc 19:15:45 ok, Norm; that matches XML_PMWG(TPAC)11:30AM 19:15:50 zarella has joined #xproc 19:16:08 :-) 19:16:40 Zakim, call suite_1235 19:16:40 ok, Norm; the call is being made 19:16:42 +Suite_1235 19:16:46 Norm, you join Dap working group 19:16:57 -Salon_2 19:17:57 zakim, code? 19:17:57 the conference code is 97762 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), ht 19:20:53 Vojtech has joined #xproc 19:23:48 Present: Norm, Henry, Vojtech, Mohamed 19:23:53 Reviewing items from this morning. 19:24:51 Topic: Revisit 169 19:25:06 Norm summarizes the decision to use in-scope namespaces from the p:xquery element 19:25:27 Mohamed: I would prefer to say that "text" input formats don't inherit anything from the XML that contains them. 19:25:46 Norm: I can certainly live with that, I was going for a small change rather than a big one. 19:26:37 Henry: I like the consistency of saying namespaces only inherit in XML. So namespaces don't inherit into text formats. 19:27:49 Norm: I like it too. 19:29:11 Proposal: In p:xquery, change the "Statically known namespaces" to "unchanged". 19:30:15 Accepted. 19:39:58 Topic: Review 174 19:40:06 Henry: He's asking for granularity that no other spec provides. 19:40:25 Mohamed: Is an implementation able to provide specific functions in the static context for use-when? 19:42:31 Norm: 2.7.10 says you can 19:42:40 Vojtech: But you can't use them in use-when 19:43:21 Norm: Well, maybe you can, if you can use a group to wrap the test with some test that doesn't use them. 19:43:32 Mohamed: And you can have your own system properties, as long as they aren't in the p: namespace? 19:43:35 Norm: Yes. 19:44:54 Vojtech: It would be nice if the spec was clearer on this point. 19:45:16 Norm: Yes, it should say that implementations are forbidden from adding new system properties in the p: namespace, but may add ones in other namespaces. 19:46:35 Topic: Review 168: circular imports 19:48:33 Proposal: Remove the prohibition on circular imports, they're just a special case of re-entrancy. 19:48:37 Accepted. 19:49:09 Topic: Review 170: p:import #006 19:50:14 Norm: I was worried that the information might not be available, but you really already need it for XInclude and other things. 19:50:22 Proposal: The test is correct, update the spec. 19:51:02 Accepted. 19:51:30 Topic: Any other questions about the editor's draft? 19:54:07 Some discussion of the arrangement of the various schemas with respect to attributes and types. 19:56:47 Norm: Are we finished? 19:56:50 No dissent voiced. 19:57:13 Norm: We have to go back to Last Call, but there's precedent for going directly from LC to PR. I think we should plan to do that. 19:59:14 General support for that proposition. 19:59:21 Norm: When does the publishing moratorium end? 20:04:20 Henry: Requests to publish can begin again on Monday, 9 Nov. 20:04:33 Norm: Ok, so I'll plan on a date of perhaps 11 Nov. 20:04:44 Norm: What's the minimum length for a LC? 20:05:07 Henry: Three weeks. 20:05:18 Ok. So if we publish on 11 Nov, we can end on 2 Dec? 20:06:54 Henry: Yes. 20:08:05 Norm: Ok, we can, potentially pass a motion to go to PR on 3 Dec. 20:08:49 Proposal: The editor to implement the decisions made today and request a new LC draft be published on 11 Nov with a 3 week LC ending on 2 Dec. 20:09:04 Accepted. 20:09:36 Topic: Review test suite coverage 20:09:37 -> http://tests.xproc.org/testsuite/coverage.html 20:13:07 Returning for a moment to the question of teh version attribute, required or default to 1.0? 20:13:32 Henry: Two precedents: XSLT, where it's required, and everyone hates it. 20:13:42 ...but people have gotten used to it. 20:13:55 ...And XML where it was a huge mistake to require XML 1.1 documents to have an explicit version number. 20:14:30 ...I expect the language to be backwards compatible. I don't wish it to be the case that my pipelines simply stop running becuase 10 years from now peopel write processors that are only V2.0 and upwards supporting. 20:14:35 s/peopel/people/ 20:15:15 Henry: I'm happy for it to run in whatever the current version is. 20:15:28 Norm: Right. So this is an argument for no version numbers at all. 20:18:04 Mohamed: I think there are two levels: we already agreed that we need version to declare what version it is. 20:18:32 ...I think what Henry is asking for is some sort of default strategy. If you don't mandate to have a version, then the question is what is the default version? 20:18:44 ...What I hear Henry asking for is that the default be the implementations "current" version. 20:22:08 Norm: I'm coming around to Henry's way of thinking. 20:22:20 Mohamed: Yes, and you could request the version you wanted explicitly on the command line if the processor supports it. 20:24:20 -MoZ 20:24:24 I've been dropper 20:24:28 I've been dropped 20:24:33 Zakim, what's the code ? 20:24:33 the conference code is 97762 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), MoZ 20:24:49 Vojtech: Before it was hard to see what versions of XProc were supported. That's easier now with the new functions. 20:25:15 +MoZ 20:25:35 Norm: I see. So why would you want to put a version on a pipeline if the pipeline can dynamically change its behavior based on the version. 20:27:08 Norm: That's pretty compelling to mel. 20:27:11 s/mel/me/ 20:27:42 Mohamed: One argument in favor of keeping version is that it's easy to add when you're cutting and pasting. 20:31:05 Norm: So an existing V1 pipeline grows a V2 feature, it's fed back to a V1 processor and that processor falls over. 20:31:20 ...Either you have to add a version attribute or you have to use use-when to simplify the pipeline for the V1 processor. 20:31:39 ...The alternative is the same, you just forced to do the version story even when you don't have to. 20:34:36 Henry: The anti-version indicator camp say that version indicators create walled gardens. And also that they're a disincentive for people to get into the market. 20:36:30 ...So the question is, what are the semantics. I'm happy with an advisory semantics. I put them in to document what I meant. 20:36:47 ...I wrote this document against this version of this spec. It's helpful to authoring tools to know that. 20:37:10 ...That's not the kind of semantics that we're looking at here. Or that XSLT have used. 20:37:26 ...We have these notions of compatibility modes. 20:38:16 ...So either version identifiers are author metadata or implementation-driving compatibility modes. 20:38:27 ...In the former case, it doesn't make sense to make them required. 20:38:59 ...In the latter case, there I don't know which makes more sense. 20:41:15 Norm: I'm conflicted. I've come to prefer not requiring them, but the one concrete example I can think of is that requirement them improves interoperability. 20:44:54 -MoZ 20:47:20 RRSAgent, set logs world-visible 20:48:59 Henry: Schema says that they expect 1.0 schemas to be conformant 1.1 schemas. The vast majority of schema documents conformant to 1.1 should also conform to 1.0 leaving aside the new things. 20:49:07 ...And where they are compatible, the semantics will be the same. 20:50:04 JeniT has joined #xproc 20:50:16 ...Schema provides use-when semantics with vc: 20:50:28 Hi :) 20:50:41 RRSAgent, pointer 20:50:41 See http://www.w3.org/2009/11/02-xproc-irc#T20-50-41 20:51:24 Henry: Where they appear, minVersion and maxVersion are compared to *the version* supported by the processor. 20:52:21 ...So, if you don't use minVersion and maxVersion then the semantics of anything from previous versions will not have changed. 20:52:25 ...That's the contract that Schema have implicitly agreed to. 20:53:46 Henry: With the schema constructs, I don't think there is any way to produce a backwards compatibility mode, so maybe this wasn't a useful analogy. 20:55:27 Henry: Another way to come at this: does our definition give us any response to the people who say "version indicators require you to implement the history of the world". 20:57:30 Henry: I think we need to be clear that a V2 processor that sees a V1 pipeline can run it as long as it knows that it doesn't use anything that's incompatible with it's implementation. 20:58:49 ...You don't have to implement all the preceding versions, just tell if you can run them. 21:00:00 Henry: You only have to look at the pipeline if you know there's been a change or reduction in functionality from that version. 21:00:27 Henry: So the cost of saying that a pipeline is a "1.0" pipeline is nearly zero. 21:46:01 Norm has joined #xproc 21:46:11 Bah. Stupid hotel internet timed me out. 21:51:12 Vojtech has joined #xproc 22:11:14 I'm still here, but also doing useful things. 22:11:28 Cool. 22:11:35 Any thoughts on the straw poll? 22:15:16 I didn't see a straw poll 22:15:28 Just a few lines back up in your buffer? 22:15:38 Let's do a straw poll quickly before lunch: 22:15:38 [13:03] 1 = version is required 22:15:38 [13:03] 2 = version is not required, defaults go 1.0 22:15:38 [13:03] 3 = version is not required, defaults to implementation defined 22:15:38 [13:04] * Norm nods to jeni, think about your answer :-) I'll get you last 22:15:38 [13:04] Norm: 1 22:15:40 [13:04] Henry: 1 22:15:42 [13:05] ...The only one I can't live with is 2. 22:15:44 [13:05] Vojtech: 3 22:15:46 [13:05] And you, JeniT ? 22:16:07 Pfff 22:16:15 I can live with 1 or 3 22:16:20 ok. 22:17:49 The stringent wording in the backwards compatibility section makes me err towards 3 22:20:01 Yeah. Ok. So here's the rub as I see it. 22:20:34 If you don't specify the version, everyone is happy with the changing versions until an interoperability problem arises 22:20:48 We both work with 1.0 processors... 22:20:52 You get a 2.0 processor... 22:20:57 You start using 2.0 features... 22:21:18 Eventually you send me your pipeline and it's rejected immediately becuase I have only a 1.0 processor. 22:21:27 At this point one of us has to add "version='2.0'" to it. 22:21:48 (Let's assume that's enough to make it work, the cases where you also need use-when are even harder to justify) 22:22:13 But if you'd been forced to use it earlier, it'd been inconvenient for you, but then interoperability would have worked better. 22:22:23 So I'm really torn. 22:22:43 Yes, me too :) 22:22:45 Of course, if you think everyone is going to have to use use-when anyway, then what version you put on the thing is irrelevant and 3 is better. 22:23:00 So, we're all in agreement. We're all torn :-) 22:23:21 I think it partly depends on what you think is going to happen in the future. 22:23:25 htt has joined #xproc 22:23:46 Indeed. 22:23:53 ie how likely it is that future versions are going to change things in backwards-incompatible ways 22:24:01 wb ht 22:24:23 Well. Most steps are probably never going to change in a backwards-incompatible way. 22:24:50 OTOH, I won't be surprised if p:xslt grows a "messages" port, and for that you'll need "version='2.0'" to get a 1.0 processor to do the right thing. 22:25:11 So it's really the forwards-compatible changes that are the issue, I think. 22:30:25 So my inclination is that if we're torn, we shouldn't require the version: it becomes a best practices decision that individual developers can make depending on their situation. 22:30:40 Hmm. 22:31:11 Ok. I can live with that. I think we're going to try to shop it around to a few of the other TPAC folks and see if we get any compelling feedback. 22:31:19 Requiring the version is us saying "it will be good for you in the long run if you always put a version on the pipeline" 22:31:21 OK 22:31:32 Thanks for taking the time! 22:31:38 (Wish you were here :-) ) 22:31:42 :) 22:31:47 np 22:31:56 Now Vojtech and I are going to try to get the test suite up to 100% 22:32:00 Cool! 22:32:01 LC next week, PR in December! 22:32:10 Great 22:47:51 ht has joined #xproc 23:14:01 Tento odstavec je Ĩesky. 23:16:09 JeniT has left #xproc