IRC log of ixml on 2023-12-12

Timestamps are in UTC.

14:42:41 [RRSAgent]
RRSAgent has joined #ixml
14:42:45 [RRSAgent]
logging to https://www.w3.org/2023/12/12-ixml-irc
14:44:46 [norm]
Meeting: Invisible XML
14:44:53 [norm]
Chair: steven
14:44:56 [norm]
Agenda: https://lists.w3.org/Archives/Public/public-ixml/2023Dec/0001.html
14:45:00 [norm]
Scribe: norm
14:45:05 [norm]
ScribeNick: norm
14:45:19 [norm]
rrsagent, draft minutes
14:45:20 [RRSAgent]
I have made the request to generate https://www.w3.org/2023/12/12-ixml-minutes.html norm
14:45:29 [norm]
rrsagent, set logs world-visible
14:45:34 [norm]
rrsagent, draft minutes
14:45:35 [RRSAgent]
I have made the request to generate https://www.w3.org/2023/12/12-ixml-minutes.html norm
14:46:49 [norm]
Regrets: Bethan
14:46:52 [norm]
Scribe: Norm
14:47:01 [norm]
rrsagent, draft minutes
14:47:03 [RRSAgent]
I have made the request to generate https://www.w3.org/2023/12/12-ixml-minutes.html norm
14:51:05 [Steven]
Steven has joined #ixml
14:51:21 [Steven]
rrsagent, here
14:51:21 [RRSAgent]
See https://www.w3.org/2023/12/12-ixml-irc#T14-51-21
14:51:41 [norm]
rrsagent, draft minutes
14:51:42 [RRSAgent]
I have made the request to generate https://www.w3.org/2023/12/12-ixml-minutes.html norm
14:52:37 [cmsmcq]
cmsmcq has joined #ixml
14:55:16 [john]
john has joined #ixml
14:57:32 [norm]
Previous meeting: https://meet.google.com/dfz-rwpj-opq
14:57:46 [norm]
Previous meeting: https://lists.w3.org/Archives/Public/public-ixml/2023Nov/0021.html
14:59:01 [norm]
Previous meeting: https://www.w3.org/2023/11/28-ixml-minutes.html
14:59:05 [norm]
rrsagent, draft minutes
14:59:06 [RRSAgent]
I have made the request to generate https://www.w3.org/2023/12/12-ixml-minutes.html norm
15:00:09 [norm]
Topic: Review of agenda
15:00:44 [norm]
Present: Steven, Michael, John, Norm
15:02:05 [norm]
Present: Steven, Michael, John, Norm, Jim Saiya
15:04:50 [norm]
The group welcomes Jim.
15:05:07 [norm]
Accepted.
15:05:30 [norm]
If there's time, or for next time, prolog and version changes
15:05:39 [norm]
Topic: Previous Actions
15:05:43 [norm]
2023-01-10-f: Norm and Michael to do a bit of revision to the XML vocabulary
15:05:47 [norm]
Continued
15:05:50 [norm]
2023-10-17-a: SP to document the modified IRI/URI grammar
15:05:53 [norm]
Continued
15:05:58 [norm]
2023-11-28-a: SP to make pull request adding his proposed addition to section 3.3 ("Names are case-sensitive.").
15:06:14 [norm]
Continued
15:06:17 [norm]
2023-11-28-b: SP as group chair to ask W3C to publish the ixml spec as report.
15:07:02 [norm]
Steven reports that he generated the static version and requested a URL from W3C staff contact.
15:07:04 [norm]
Continued.
15:07:07 [norm]
2023-11-28-c: SP to review the EBNF to BNF document.
15:07:09 [norm]
Continued
15:07:12 [norm]
2023-11-28-d: Norm to tidy 'Extraneous material in section on Serialization'
15:07:13 [norm]
Done.
15:07:17 [norm]
2023-11-28-e: MSM to write a proposal regarding full stops in names.
15:07:55 [norm]
MSM: I wrote a proposal, but several of us wrote proposals that defined the wrong language!
15:08:37 [norm]
MSM: I'm putting together a test catalog based on the sample names, I'll add a few more. Started but unfinished.
15:08:39 [norm]
Continued.
15:09:09 [norm]
JL: This is a niggle that came up when you're writing a parser. A name that ends in a full stop causes real problems with lookahead.
15:09:20 [norm]
... We decided that we'd forbid full stops at the end of names.
15:10:25 [norm]
Topic: Status of implementations
15:10:38 [norm]
Norm: Nothing exciting to report.
15:11:01 [norm]
JL: I'm continuing to work on detecting regex and using them in the parser; managed to do it successfully for repeat1, but repeat0 is causing me trouble.
15:11:14 [norm]
Steven: I have nothing to report.
15:11:22 [norm]
MSM: No news hear either.
15:11:32 [norm]
Topic: Status of testing and test suites
15:11:47 [norm]
MSM: There are pull requests related to the test suite that will come up shortly.
15:11:52 [norm]
Topic: publication plans
15:11:55 [norm]
Already discussed.
15:12:00 [norm]
Topic: Review and resolution of bug reports and technical issues
15:12:16 [norm]
Topic: Pull request #224 Mitigating ambiguity in mod357
15:12:48 [norm]
These are related to the performance tests.
15:13:18 [norm]
ACTION: MSM to review the open pull requests from Gunther Rademacher and respond to them
15:13:57 [norm]
MSM: This PR is about the mod357 grammar. Right now, it asks that the parser tell you which number the number is divsible by.
15:14:06 [norm]
... So it's ambiguous on 15, for example, which is divisible by 3 and 5.
15:14:31 [norm]
... I didn't attempt to filter out ambiguities. The way we've addressed that in the past is to add your results to the list of acceptable results.
15:15:14 [norm]
... Gunther suggests instead, since the specifics don't matter, and just make it return "yes" or "no" instead of reporting the reason.
15:15:29 [norm]
JL: Is this an "am I passing the test or not" rather than "what is the parse tree"?
15:16:31 [norm]
MSM: The purpose of all these performance tests is to provide a simple grammar that demonstrates performance issues.
15:16:44 [norm]
... It's relatively simple for humans to understand but hard to optimize.
15:17:44 [norm]
Steven: If the only thing is checking performance then it doesn't matter what it produces.
15:18:10 [norm]
MSM: I will think about it, but I'm coming to believe that he's probably right.
15:19:02 [norm]
Steven: Gunther is not a member of the group, should we not propose that he join and come to these calls?
15:19:12 [norm]
MSM: I can certainly ask.
15:20:07 [norm]
JL: I've been doing lots of stuff on performance; once you know that you're getting the right results, you don't care about the results anymore, you only care about performance.
15:20:32 [norm]
... What I really want to know is just how long did it take. And, of course, what is the point at which your parser breaks.
15:20:56 [norm]
... The performance tests are in a slightly different ballpark; we might want to think about describing them differently.
15:21:16 [norm]
MSM: That's probably worth adding to the README file and the descriptions of the tests in the test catalog.
15:21:41 [norm]
... It may be worthwhile to tinker with your test harness so that you're only timing the parsing rather than the parsing and the results.
15:22:12 [norm]
JL: When you're doing a conformance test, your compiling the grammar, parsing against the grammar, serializing, and then comparing that result. In most of my cases, the parsing is the one that takes the time.
15:22:29 [norm]
... So you're focusing on just trying to get the parsing piece fast.
15:22:39 [norm]
MSM: You might not even want to bother writing the output to a file.
15:23:03 [norm]
... I compare the XDM instance and then serialize for the record; but I don't serialize and then do the comparison.
15:23:19 [norm]
JL: I don't either, but I think of the XDM as a serialization of the parse tree.
15:23:46 [norm]
MSM: Depending on what your parser produces, extracting a parse tree can be part of the performance measurement.
15:25:49 [norm]
Topic: PR #228 Correct several typos in the text of the EBNF/BNF working paper #228
15:25:51 [norm]
Accepted.
15:25:57 [norm]
Topic: Issue #198 Check test suite browser is updated on additions
15:26:29 [norm]
Norm: I'd like the group to accept https://github.com/invisibleXML/ixml/pull/229 to close the issue.
15:26:51 [norm]
Accepted.
15:27:32 [norm]
Topic: Issue #210 Extraneous material in section on Serialization
15:27:44 [norm]
Norm: Fixed by https://github.com/invisibleXML/ixml/pull/221
15:27:48 [norm]
Accepted.
15:28:13 [norm]
Topic: Problems with the prolog
15:28:30 [norm]
https://lists.w3.org/Archives/Public/public-ixml/2023Oct/0004
15:28:31 [norm]
Steven posts
15:29:16 [norm]
Steven: I don't like the syntax; it upsets me but I don't have a solution for it.
15:29:33 [norm]
... The second I think we should fix
15:30:05 [norm]
Scribe: "the second" is: the semantics. The default is version 1.0, but if I say ixml version "I really don't care" you get errors.
15:30:35 [norm]
JL: Is there a sense that the prolog should be a property table of some form?
15:30:45 [norm]
Steven: I don't know how to answer that question.
15:31:12 [norm]
... It's really the potential long lookahead before you know if you're looking at a rule or a version. The ixml grammar begins with the word "ixml".
15:31:55 [norm]
JL: So you could have a case of "ixml" followed by an arbitrary amount of stuff.
15:32:09 [norm]
Steven: A simple solution is just to say that "ixml version" has to be two words with a single space.
15:32:59 [norm]
MSM: I confess that the rhetorical effect of the example is enhanced by the length of the comment, but technically speaking I have "ixml" that could be the beginning of a rule or the prolog
15:33:42 [norm]
... I might consume a lot of whitespace before the version. It doesn't trouble me that much. But it's also true that some sort of bracketing around the prolog wouldn't trouble me very much.
15:34:08 [norm]
... I'm used to SGML and XML documents beginning optionally with metadata.
15:34:24 [norm]
Norm: Why is it special here?
15:35:12 [norm]
MSM: Because this is the one place where I've read something that could be a name and you don't know if it's a name or the prolog.
15:35:34 [norm]
Steven: It could be just the quoted version numberr.
15:35:38 [norm]
s/numberr/number/
15:35:50 [norm]
MSM: I want a label to go with the data.
15:36:04 [norm]
Steven: We don't have to decide this now, but I'd like to let it sink in for a little while.
15:36:16 [norm]
MSM: Before we go, how do other people feel about the possibility about some sort of bracketing.
15:36:54 [norm]
Norm: I'm okay with that. I want the prolog to be flexible enough to hold other things but I'm okay with bracketing.
15:37:03 [norm]
ACTION: Steven to propose alternative syntaxes for the prolog.
15:37:26 [norm]
Topic: Version number naming
15:37:36 [norm]
Steven reports https://lists.w3.org/Archives/Public/public-ixml/2023Oct/0005
15:38:30 [norm]
Steven: If there's no version, it uses 1.0; if it can recognize a version, it uses that, if it doesn't recognize the version, then it'll do whatever it can.
15:38:49 [norm]
... I think it should be: if it can recognize the number and process it, it should use that version, otherwise it should use whatever version is available.
15:39:06 [norm]
JL: Don't we report a version mismatch in the state?
15:39:57 [norm]
Steven: My proposal is that the processor can use any version it wants; if there's a version and it can use that version, I should use that one.
15:40:05 [norm]
MSM: There is a keyword in the state attribute for version mismatches.
15:40:21 [norm]
JL: So there's a mechanism to report that it worked but it may not be the version you expected.
15:41:15 [norm]
MSM: I think I'm sympathetic to this. If you didn't label it with a specific version, let the parser use what it wants. There's an analogy with the XML version declaration and my recollection is that at least some people say no the reason that XML 1.1 was doomed to failure was that the spec required people to assume 1.0.
15:41:54 [norm]
... A number of very smart people have told me that the reason that turned into a disaster, we botch the handling of version numbers.
15:42:23 [norm]
... It was botched from the start, but then it was made worse when "you may fail" was changed to "you must fail".
15:42:50 [norm]
... The advice I disregarded at the time was that a processor be allowed to fail instead of requiring that it soldier on.
15:43:19 [norm]
... I thought early failure was too important to give up, but that was wrong. I wish I knew exactly what lessons to draw from that for this case!
15:43:52 [norm]
... If you don't recognize the version number, we should probably say that you have to try anyway.
15:44:13 [norm]
MSM: The absence of a version number should not be assumed to be 1.0.
15:44:23 [norm]
Steven: The absence of a version number should mean use the best version you've got.
15:44:31 [norm]
JL: I agree. If you specify a version, then that's what you want.
15:44:46 [norm]
"Flag the version mismatch but soldier on."
15:45:46 [norm]
Topic; Next meeting
15:45:54 [norm]
s/Topic;/Topic:/
15:46:16 [norm]
No meeting on 26 December, 2023. Next meeting is 9 January.
15:46:34 [norm]
MSM gives regrets for 23 January and 6 February.
15:47:45 [norm]
Norm volunteers to handle agendas if MSM can't.
15:48:16 [norm]
rrsagent, draft minutes
15:48:17 [RRSAgent]
I have made the request to generate https://www.w3.org/2023/12/12-ixml-minutes.html norm
15:48:49 [norm]
Scribe: Norm
15:48:59 [norm]
s/Scribe: "the/Scribe reports "the
15:49:04 [norm]
rrsagent, draft minutes
15:49:05 [RRSAgent]
I have made the request to generate https://www.w3.org/2023/12/12-ixml-minutes.html norm
15:49:33 [norm]
s/Scribe: "the/Scribe reports "the/
15:49:38 [norm]
Scribe: Norm
15:49:45 [norm]
rrsagent, draft minutes
15:49:46 [RRSAgent]
I have made the request to generate https://www.w3.org/2023/12/12-ixml-minutes.html norm
15:50:55 [norm]
@Steven I think the minutes are good. Do you want me to send mail to the list, or do you usually do that?