Meeting minutes
Review of previous action items
ACTION (2022-06-21): Tom isn't here
<trackbot> Sorry, but no Tracker is associated with this channel.
ACTION (2022-11-15): Completed by Joel.
ACTION: Norm to put the information about Joel's implementation on the home page
Norm ACTION (2022-11-15): Done.
<cmsmcq> https://
<john> https://
Norm will merge pull request
ACTION: Michael to take another pass on the EBNF to BNF document
Norm (2022-11-15): completed
Norm (2022-12-13): completed
Steven (2022-12-13): continued
Steven (2022-12-13): continued
Steven (2022-12-13): completed
ACTION: Steven to expand the tests in PR 169.
<cmsmcq> combining grammars: https://
Steven (2022-12-13): PR 167, compelted. Steven agrees.
Michael (2022-12-13): completed
Norm (2022-12-13) partially completed
Status reports
Joel: I'd love some help on my implementation.
Steven: How does it do against the test suite?
Joel: It's just about ready to start running tests.
John: When I was implementing my parser, I didn't find the parsing tricky. Threading your way back up to where you started was the hard part.
Norm: I have some quite complicated data structures for managing the state.
Steven: How about you Bethan?
Bethan: My thesis is coming along nicely!
Testing and test suites
Norm: I've got PR 169 but Steven's already agreed to extend that.
Norm: How about we commit #169 and you add more?
<Github> https://
Steven: That's ok by me.
Michael: The inventory of characters in any class (and possibly known classes) may vary from version to version of Unicode. Strictly speaking, we ought to label the tests with the versions of Unicode that they pass.
ACTION: Michael to work out the metadata for identifying the Unicode version(s) associated with a test.
Some discussion of what the parameters of the tests are.
Steven: I want to have one character from each class and each block.
Michael: That's incomplete unless you identify the Unicode version.
Joel: Is it the case that a test we write today would become invalid?
Michael: If anyone can show me a commitment to that kind of stability on the Unicode site, I'll believe they intend that. But they've got it wrong in the past!
Norm: I don't see any problem with having the metadata.
Michael: When any spec refers to another spec, the question arises of what version is referenced.
<mjoel> http://
Michael: I think our current state is that the version of Unicode is implementation defined, but we don't say that.
Some discussion of the stability policy linked above.
<mjoel> Java 11 looks like it uses Unicode 10.0
John: Can I suggest in two months time we try to get to a position where we can publish test reports.
Michael: The test suite schema also defines a report format.
John: Some of the tests with high ambiguity are problems for my implementation.
Issue #147, are control characters allowed?
<Github> https://
Steven: We agreed to the change, but not the errata.
Michael: I've been persuaded that "cannot" is an acceptable verb.
Michael: The erratum is currently listed as proposed.
Norm: If we accept it, I'll move it!
Michael: I propose we accept it.
Steven: Agreed.
ACTION: Norm to merge it and close #147
<Github> https://
Pull request #146, EBNF
<Github> https://
Norm: We've agreed that to merge that and hand it to Michael
Steven: Ok
Issue #139, continued action on Steven
<Github> https://
Issue #137, document the XML tag set
<Github> https://
Michael: We publish an XML grammar, people including myself use it, so it's useful to document it.
Michael: Norm has produced mock ups and I have not attempted to read them in full. Mostly, the descriptions are elided.
Michael: The formatting looks great.
Michael: With one exception, either the generic identifiers need to be visually distinct, or description needs to be indented more.
Michael: And generally, my instinct is to put the short description and paragraphs before the formal definition.
Norm: I did it that way out of habit; that's the way the DocBook document does it.
John: Is there any sense that this could get out-of-sync?
Norm: No. It's generated from the spec.
ACTION: Norm and Michael to do a bit of revision to improve it for further discussion.
Combining grammars
Norm gives a brief outline of his sketch
Steven: My one main objection is that if you import something and then the author changes the grammar you're importing.
Norm: That's just like any API, surely?
Steven: We could have a mechanism for defining what's exported.
Norm: That's more complex, but sure.
Michael: I think there's going to be a curve where the more complex the needs get, the more complex the syntax.
Steven: A while back, I sent a message with questions about the requirements. Are we importing text, or parsed grammars? There are lots of questions.
Steven: I think a requirements document is necessary.
Michael: Are questions about how the grammar appears in the imported grammar, requirements or implementation details?
John: I think they're implementation details.
Michael: I suppose the fact that if I hand an iXML grammar to a processor as the input string, specifying the iXML spec grammar as the input grammar, the visible XML version is currently just what you'd get for that parse.
Michael: I think an argument that will come up is saying that the imported rules should be included in the XML output requires ad hoc processing for certain elements, so we might want not to do that. It loses the current invariant that processing a grammar as a string produces the expected XML.
Michael: I think Steven has made a good point that we should think hard about whether or not import and export will solve problems we have. I think some capability for overriding is important.
Michael: In some cases, modularity will also be important to avoid name conflicts. I think that a useful set of capabilities is exhibited for us by the rules for imports and inclusions in RELAX NG grammars.
<Steven> My mail on requirements: https://
Michael: Maybe we need to assign some actions for use cases. And I'll take an action to review RELAX NG's rules.
ACTION: Norm to start a use cases and requirements document.
ACTION: Michael to review RELAX NG rules and report back.
ACTION: Michael to close issues #29 and #30.
<Github> https://
<Github> https://
Next meeting
Steven: I have a conflict for 14 February.
Norm: I'd prefer 7 to 21.
<Steven> So agreed
The next meeting is 7 February 2023.