Meeting minutes
Are you setting up to scribe today?
<Steven> Was I selected? I was just setting up the channel
I thought it was me, and I'm happy to do it. Ok. Cool. Me then. Unless someone else wants to do it :-)
<Steven> Be my gues ;-)
<Steven> guest
Identify a minute taker
Norm is scribe
Review of action items
ACTION 20220322-001: Michael to update schema for test catalogs to add dynamic error.
<trackbot> Sorry, but no Tracker is associated with this channel.
Ignore that action
ACTION 20220405-003: Norm: Add the error code linkages to the spec (for issue #44).
Norm: completed
ACTION 20220405-004: Norm: to add prose specifying the namespace to use if error codes are given as qualified names (for issue #61).
Norm: completed
ACTION 20220412-001: Steven - to review MSM's proposed text on ambiguity text and where it should end up (for issue #26).
Steven: I moved the text, but I didn't check the proposed change.
Continued
ACTION 20220412-002: Steven - Steven to review the possibility using the names s and RS for optional and required space, respectively.
Steven: completed
ACTION 20220412-003: All - Review of the namespace proposal (for #66).
All claim to have reviewed it
ACTION 20220412-004: Norm to produce some spec. prose on the version (conformance) issue (#63).
Norm: Completed. Michael proposed a change that I think is an improvement.
ACTION 20220412-005: Norm - Improve the README - what format - Markdown or HTML.
Norm: completed
ACTION 20220412-006: Tomos to ensure all can see the Balisage papers (https://
Tomos: completed
Status of implementations
John: My implementation now handles the ixml spec under the Earley parser in about 300ms.
… It's a set of JavaScript files. It uses a custom parser for the input ixml, then an Earley parser that I wrote from scratch.
… You can get the state chart, etc.
… I haven't done serious testing yet or handling ambiguity yet.
… Over the next few weeks I'll try to package that up better. I'm using the browser DOM to build the output.
Steven asks about the DOM. John says he parses to an internal representation, but uses the DOM to get the XML version.
John: It very much canonicalizes as it goes.
Norm: I’ve updated my processor to the (now current) grammar but I’m eager to see the other proposals adopted so I can update it again before making any sort of announcements about the changes.
Steven: I've updated mine to do the double ** and double ++.
Status of testing and test suites
Norm: I've updated the tests to the current grammar
Review and resolution of bug reports and technical issues
Change ~ to ! in character-set exclusions.
Steven: I'm ok with adding it, but not replacing it.
… I don't think "!" is a good choice, I don't think it means "not".
… In ixml, we're not using "not", we're using "complement of".
Tomos: I think it's about familiarity.
Some discussion of "^" instead of "!" or "~"
Bethan: The only issue I have with "~" is that it suggests "approximately" and I find it difficult to find "~" useful.
… I imagine that most of our users may be in the same position.
Conclusion: there is no consensus to make the change; the status quo remains.
Use '=' and '|' exclusively.
Steven: I'm of the opinion that different languages are allowed to have different syntaxes. I added them as a sop to users who wanted them.
… "=" doesn't mean "is defined as". It's not an equality relationship where we have it.
Bethan: Wait, you can't say that different languages can use different symbols and simultaneously that "=" doesn't mean something.
Tomos: I think the use case for "=" is less compelling than the use case for "|" because ";" and "," are harder to distinguish
Bethan: There seems to be a lot of support for defining a single character.
Norm: I think that's true. I thought the unnecessary syntactic variation is weird.
John: Does ";" get used as alternates compared to "|"?
Michael: It depends on how you count. The tradition of grammar notations that includes ALGOL-68 and friends uses ":" and ";".
… I've always found them appealing on that basis. But I think it's fair to say that YACC and it's workalikes are more used than any other notation and they tend to use "|".
… I think YACC may well use ":"
Some discussion of "::=" and it's alternatives.
Bethan: I find the ";" very hard to read as an "or" separator.
Tomos: I think objectively, semicolons are harder to read.
Steven: There are several things going on here. Do we want a single syntax or do we want to allow people to use the things they want to use?
… I personally don't see what's damaging about allowing a choice.
Norm: I think that cuts both ways, if authors use different characters it makes the grammar harder for a reader.
Norm: Using two characters instead of four saves us two characters for later
John: It sounds like we could remove "=" without too much objection.
… The advantage of getting that out of the way would allow us to reserve it for later.
… I don't think it matters from a performance point of view.
Tomos: I don't think it matters too much about the "=" used elsewhere. The characters have meaning contextually.
… I was ready to say that we should standardize on one or the other. But the more we talk about it, the less convinced I become.
John: Equally well, it's not just what the punctuation syntax is. It's the layout of the grammar, etc.
… Style matters as much as the particular punctuation characters.
Steven: May I also bring to your attention the whole point of ixml isn't the syntax, it's the data that matters.
Bethan: What I'm talking about isn't the person writing the grammar, it's about using grammars written by others.
Tomos: It should be a small step to normalize it to your preferred representation.
Bethan: Or we could not have to do that!
Steven: The two basic options are, we agree that there should be one representation or we let users do what they want.
John: I think what we should do is permit what we currently have.
Norm: I don't detect consensus forming here.
Conclusion: there is no consensus to make this change.
Add a version declaration
Agreed.
ACTION-20220426-01: Norm to propose spec and grammar changes for a version declaration.
Change ^ to + in literal insertions.
Tomos: Could we allow either?
Some discussion of how the specification currently describes them.
Michael: I applaud the attempt to make them parallel. I found it very problematic because I find it impossible to relate the behavior of marking tagging a nonterminal as an insertion.
… I think they are conceptually different.
Norm: My difficulty is that it removes the explicit mark that is the opposite of "-" for literals.
Michael: I think that having a character to mark the default explicitly is a standard feature of language design.
… You should be able to specify all defaults expicitly.
Steven: I don't like the fact that "+" gets two different uses.
Tomos: Grammatically, it's quite distinct because one is a prefix. and one is a postfix
Steven: I can live with it.
Norm: I'd like to do it.
Steven: So a tmark is now ^, -, and +.
… And mark is ^, -, and @
Consensus: make this change
ACTION 20220426-02 Steven to change ^ to + for insertions.
John: Are insertions limited to strings?
Steven: No, it can be hex as well, but not a charset.
Michael: "literal" but not "charset"
#44 Adopt proposal 3 for error codes.
Steven: Why do the error codes have to be in the spec?
Norm: Because we shouldn't make users go around the houses to find the prose.
John: I'm fine with the index, but I'd still expect to find the error *names* in the prose where they occur.
Bethan: Firstly, if you go from the index to the text, you can't expect users to magically know what sentence is about the error.
… Also, users are going to google the error codes, it would be nice if they got taken to the right part of the spec.
Steven: I'm happy to look up the error codes.
Tomos: Which would would you prefer?
Steven: My preference was the superscript.
Bethan: I'm having trouble understanding what's intrusive about the error codes.
Steven: Why do we want error codes? So that we could make implementations testable.
Bethan: If a user does something wrong, they're going to get back an error code.
Steven: They shouldn't have to, the get a message.
John posts an example from the XPath spec.
<Tom> https://
John: I think something like this at each error condition is what we need.
… These kinds of messages give me precision.
Bethan: A lot of StackOverflow questions are about the messages.
Steven: I can live with three
Consensus: Adopt positon 3.
ACTION-20220426-03 Norm to update the spec with error codes.
Adjourned