13:25:46 RRSAgent has joined #ixml 13:25:50 logging to https://www.w3.org/2025/04/29-ixml-irc 13:25:54 rrsagent, make logs public 13:26:44 Meeting: Invisible XML Community Group 13:26:44 Chair: Steven 13:26:58 Agenda: https://lists.w3.org/Archives/Public/public-ixml/2025Apr/0009 13:27:07 Previous meeting: https://www.w3.org/2025/04/15-ixml-minutes 13:27:18 rrsagent, make minutes 13:27:19 I have made the request to generate https://www.w3.org/2025/04/29-ixml-minutes.html Steven 13:50:24 nico has joined #ixml 13:55:18 norm has joined #ixml 14:00:17 Present: Norm, Bethan, Nico, Steven, David 14:00:56 Regrets: John 14:01:58 Topic: Accept the minutes of the previous meeting 14:02:03 [Accepted] 14:02:36 Topic: Review of open actions 14:03:06 Steven: I have done some research on the disambiguation operators 14:03:45 ... see the paper 14:04:49 https://ics-archive.science.uu.nl/research/techreps/repo/CS-2001/2001-39.pdf 14:05:31 Norm: If that code is open source, it would be good to know. 14:06:05 ACTION: Steven to find out if GLL parser is open source 14:06:31 Topic: Status reports 14:06:35 [None] 14:06:55 Topic: New open issues 14:07:03 Issie #295, ixml or iXML? 14:08:10 s/Iss #295/Issue #302/ 14:09:16 Steven: I don;t see why it is an issue. It has always been ixml up to now 14:09:25 Norm: It's not a hill I want to die on. 14:09:32 s/;/'/ 14:09:57 Norm: It is split 60/30 14:10:26 David: Is there a rule about what can and cannot be changed? 14:10:46 ... a switch to mixed case now would change what has been established. 14:11:27 ... In unicode there is a principle that character names cannot be changed. 14:12:44 Norm: What's in the draft is clearly a change 14:13:20 Bethan: We should listen to the community as well. 14:13:44 Steven: We normally work on consensus. A change gets made is everyone can live with it. 14:16:36 Steven: We close this issue, with no change. 14:17:26 Topic: Perspectives on serialization 14:17:26 See https://github.com/invisibleXML/ixml/pull/296 14:20:46 Steven: I have read it it, but I have some suggestions 14:21:17 ... I don't think it covers what I had intended when I wrote "serialisation" 14:21:52 ... so I plan to produce an edited version 14:22:06 [Discussion on what serilaization means] 14:22:33 s/serilaization/serialization/ 14:23:08 Topic: Pragmas 14:23:46 https://github.com/invisibleXML/ixml/blob/master/proposals/pragma_req.md 14:24:20 The legal form of a pragma name must be defined in the specification. 14:24:51 [Agreed] 14:24:58 The structure of the optional pragma data following the pragma name must not be defined in the specification. 14:25:23 There must be a mechanism by which implementers can ensure that a chosen pragma name will not conflict with any pragma name used in other implementations. 14:25:34 David: How? 14:25:45 ... is it possible to ensure it? 14:26:15 Bethan: namespace-like 14:26:32 Norm: Namespaces allows an insurance. 14:26:47 ... domain names in reverse order is also possible 14:28:27 Simplicity of syntax and semantics should be the most important priority in adding pragmas to iXML. 14:28:47 Bethan: Not sure how easy it is to judge 14:29:35 ... a problem is two proposals where one was simpler 14:30:23 Steven: "of importance" would be fine 14:30:42 The processor need not inform the user that it has encountered an unrecognized pragma. 14:31:13 Norm: Implementation issue, but not by default 14:31:27 Recognized but ill-formed pragmas need not cause the parse to fail, or cause the processor to issue a warning. That is, if a processor recognizes a pragma identifier, but the pragma data cannot be parsed successfully as input to the relevant code block, the response is wholly a matter for the implementer. 14:33:09 Bethan: No requirement that an illformed pragma causes the processor to stop\ 14:33:13 s/\// 14:34:14 A pragma’s attachment to a specific syntactic construct must be unambiguous to software for parsing iXML grammars.] 14:35:34 Nico: My question is if this can be implementation specific 14:42:53 [Discussion on "Attachment"] 14:43:22 Davis: ABOUT IMPLEMENTATIONS AGGREEING ON PRAGMAS. hOW WOULD THAT AGREEMENT BE RECOGNISED WITH POINT 15? 14:44:13 s/ABOUT IMPLEMENTATIONS AGGREEING ON PRAGMAS. hOW WOULD THAT AGREEMENT BE RECOGNISED WITH POINT 15??About implementations agreeing on pragmas, how would that agreement be reconciled with point 15?/ 14:44:42 \Norm: A unique name insures you won't have mismatching semantyics 14:44:48 s/yics/ics/ 14:45:00 s/\Norm/Norm/ 14:45:38 Bethan: Collaborative decisions, shoudl use a combined space 14:45:46 s/shoudl/should/ 14:46:44 Nico: 20 implies 19. 14:47:29 ... when you place a pragma in the linear notation, would that be enough to require it to be in the same location in the XML notation? 14:48:35 Bethan: We separate syntax and semantics already. 14:48:58 Nico: I could make a pragma that depends on all parsing that has gone before 14:49:19 ... so then it doesn't depend on a particular construct 14:56:19 [Long discussion of attachment and whether it is required or optional] 14:56:23 [ADJORN] 14:56:46 s/ADJORN/ADJOURN/ 14:56:57 rrsagent, make minutes 14:56:58 I have made the request to generate https://www.w3.org/2025/04/29-ixml-minutes.html Steven 14:58:40 s/Davis/David/ 14:59:12 s/ABOUT IMPLEMENTATIONS AGGREEING ON PRAGMAS. hOW WOULD THAT AGREEMENT BE RECOGNISED WITH POINT 15?/About implementations agreeing on pragmas, how would that agreement be reconciled with point 15?/ 14:59:18 rrsagent, make minutes 14:59:19 I have made the request to generate https://www.w3.org/2025/04/29-ixml-minutes.html Steven