14:16:08 RRSAgent has joined #ixml 14:16:08 logging to https://www.w3.org/2022/03/29-ixml-irc 14:16:14 john has joined #ixml 14:16:19 RRSAgent, please make logs public 14:19:31 Meeting: ixml community group 14:19:40 Chair: Steven Pemberton 14:20:06 Agenda: https://lists.w3.org/Archives/Public/public-ixml/2022Mar/0096.html 14:20:20 Scribe: cmsmcq 14:20:34 Scribe: Michael Sperberg-McQueen 14:20:38 ScribeNick: cmsmcq 14:26:33 RRSAgent, generate minutes 14:26:33 I have made the request to generate https://www.w3.org/2022/03/29-ixml-minutes.html cmsmcq 14:27:51 norm has joined #ixml 14:27:55 RRSAgent, please set logs public-visible 14:30:31 topic: Review of agenda 14:30:58 Previous-meeting: https://www.w3.org/2022/03/22-ixml-minutes 14:31:06 Agenda looks fine. 14:31:16 Previous meeting: https://www.w3.org/2022/03/22-ixml-minutes 14:31:16 s/-/ / 14:31:43 Tom has joined #ixml 14:31:48 Actions: MSM add dynamic error to schema (not done) 14:31:59 Norm: done 14:32:38 s/done/action on #66: awaiting Michael's action/ 14:32:57 steven to change dot in names rule - not yet on github 14:33:40 msm to provide schema (not done) 14:34:04 steven to edit spec about varying ambiguity detection 14:34:16 (done) 14:34:38 steven to describe input as utf8 and optionally other (done) 14:36:10 Topic: Status of implementations 14:36:24 NDW: 1.0.0 of nineml is now out. 14:36:36 JL: I've run it successfully. 14:37:46 Topic: paper deadlines 14:37:58 XML Prague deadline Thursday. 14:38:04 Steven has submitted. 14:38:14 Balisage deadline 8 April. 14:38:18 various papers pending. 14:38:27 Topic: Status of testing and test suites 14:38:45 NDW: we can close 56 when MSM has done his action. 14:38:58 NDW has added some correct-grammar tests. 14:39:16 They are awaiting review. Currently they are for the February grammar. 14:39:59 SP reports that his parser is producing different results; NDW and SP discuss how NDW is invoking the parser. 14:40:33 NDW: another issue. There is an s missing in set, needed before closing bracket. 14:40:48 s does not work before a semicolon, either. 14:41:30 SP thinks he has a test that adds a space everywhere; he does not understand why that test did not pick this up. 14:41:45 Topic: Review and resolution of bug reports and technical issues 14:42:19 Topic: Pragmas proposal (continued) (issues #10, #29, #30) 14:42:39 SP: Norm's suggestion that we do email discussion was a good one. 14:42:58 I think Norm's mail shows there is disagreement about what pragmas are for. 14:44:00 MSM: what is ok and not ok? 14:44:16 SP: ok is choice of parsing algorithm, 14:44:29 or option to suppress ambiguity 14:44:48 or option to use a particular encoding 14:45:14 But we should not change the semantics of ixml. 14:45:21 or allow pragmas to do so. 14:45:45 JL: those examples are all configuration options - they aren't related to the grammar but to an execution. 14:46:06 SP: that's why I said at the outset that I didn't think pragmas are needed. 14:46:58 TH: if all you want to use pragmas for is to signal something for a single implementation, then why put it in the grammar? 14:47:49 SP: right at the beginning there appears to have been a misunderstanding about what work was being done. 14:53:55 MSM: The this-is-a-token pragma NDW mentioned does not in fact change the semantics of ixml. 14:53:59 SP: But it does. 14:54:53 MSM: if someone wants to extend the language at all, is it SP's position that they should do so silently? or not at all? 14:55:09 SP: by all means. But don't call it ixml. 14:55:42 MSM: is that a good way to promote ixml? It amounts to saying "don't use this spec" 14:55:58 JL: Consider the tree-trimming annotations. 14:57:13 It allows a concise description of a grammar whose XML ASTs are different, but which could be handled with a source-to-source transformation of the grammar. 14:57:55 What are the pragmas we are interested in that could be done with a source to source transformation? 14:58:21 NDW: some of them could, but some of the pragmas I'm interested in cannot. 14:58:49 NDW: I think having a documented extensibility mechanism is better than the alternative of saying "take your toys and play elsewhere". 14:59:56 TH: Saying that pragmas create an interoperability problem seems to ignore the fact that the proposal specifies that processors must be able to ignore all pragmas 15:10:26 We discussed whether the pragmas proposal requires that implementing a pragma not change the semantics of the grammar. 15:10:40 That has been proposed, but has not been adopted. 15:11:53 NDW: would it help to require that processors who have implemented a pragma have a mode in which they not only ignore the pragma but report if they see any pragmas that affect the semantics of the grammar. 15:12:01 s/grammar./grammar?> 15:12:15 s/grammar?>/grammar?/ 15:12:45 BTW: is it always clear whether it would produce a different result? 15:13:03 MSM: it really ought to be clear from a good specification of the pragma. 15:13:27 SP I really don't want to mess up interoperability. 15:14:36 Although everyone says ignoring pragmas will guarantee interoperability, it will happen that implementors say "to get this result, you must use this pragmas". 15:15:02 SP: the examples of CSS and HTML show that this can be a disaster. 15:21:43 MSM: but HTML and CSS are omnipresent. 15:22:43 SP: I'm not against experimentation. I'm against saying "this experiment is official ixml" 15:23:39 TH: should we be saying explicitly that pragmas are not in fact official ixml, but precisely marked segments of not-official-ixml 15:23:54 s/not-official-ixml/not-official-ixml?/ 15:29:30 BTW: would it help if the rule were not "processors must be able to ignore pragmas" but "pragmas must be able to ignore pragmas and report that pragmas were present but ignored" 15:30:08 NDW: or just "processors must have a mode in which all pragmas are signaled as errors"? 15:31:09 TH: if we allow pragmas, I'm happy to say that any processor actually paying attention to a pragma is operating in a non-compliant mode. 15:31:48 BTW: Or we could flag the output -- just as for ambiguity. We could say "ixml:state='pragma-dependent'" ? 15:32:46 BTW: this discussion does seem to reflect a surprisingly dim view of implementors and users of ixml. 15:33:10 Maybe we could take a chance on trusting people. 15:34:08 Next scribe is JL. 15:34:22 RRSAgent, publish minutes 15:34:22 I have made the request to generate https://www.w3.org/2022/03/29-ixml-minutes.html cmsmcq 15:43:40 s/various papers/Various papers/ 15:44:15 s/I think Norm's mail/SP: I think Norm's mail/ 15:45:04 s/saying "don't use this spec"/saying "don't use this spec"./ 15:45:27 s/It allows a concise/They allow a concise/ 15:46:45 s/Maybe we could/BTW: Maybe we could/ 15:46:57 RRSAgent, please publish minutes 15:46:57 I have made the request to generate https://www.w3.org/2022/03/29-ixml-minutes.html cmsmcq 15:48:43 Present: Tomos Hillman, John Lumley, Steven Pemberton, Michael Sperberg-McQueen, Bethan Tovey-Walsh, Norm Tovey-Walsh 15:48:54 RRSAgent, please publish minutes 15:48:54 I have made the request to generate https://www.w3.org/2022/03/29-ixml-minutes.html cmsmcq 15:49:12 Regrets: none 15:49:40 Regrets: none 15:49:42 RRSAgent, please publish minutes 15:49:42 I have made the request to generate https://www.w3.org/2022/03/29-ixml-minutes.html cmsmcq 17:12:57 <`join_subline> `join_subline has joined #ixml 18:59:32 cmsmcq has joined #ixml