Meeting minutes
Actions
Norm did his!
Norm made a proposal, but Steven hasn't had a chance to review.
Steven's action on examples is ongoing.
Steven's action on well-formed is ongoing
<cmsmcq__> Is there a pointer to the proposal for error codes?
Steven's action on issue #33 is ongoing.
Norm's action on unused non terminals, #45 is closed.
Implementations
Norm's implementation is much faster.
Michael: We had some new tests; I made a PR for some hygiene tests that I'll merge in shortly.
… Partly redundant because they're examples of different forms of oddities in grammars.
Issues
issue 43
Subcluster -- constraints on grammars
https://
https://
https://
Steven: I think we've dealt with the first one.
… In the as-yet uncommitted changes on my machine.
Michael clarifies that those messages are background reading. The first issue is #43.
Steven concurs with the proposal in Michael's comment on #43
ACTION: 20220315-01 Steven to implement proposal in #43
<trackbot> Sorry, but no Tracker is associated with this channel.
Issue 48
Discussion moves on to issue #48, ambiguity in grammars
Steven can live with it.
Tom: I don't like it, wouldn't it be better to require whitespace before the terminating full-stop?
Steven: We could do that.
Bethan: That's hard to see.
Tom: We could require them to be on newlines.
Michael: I think of line-oriented syntaxes as a relic of punched cards.
… So, no, I like that worse. Require whitespace, I like worse, but some whitespace I like more than requiring a newline.
… I'm still with Norm's proposal to remove full stop.
Steven: So resolved, then.
ACTION: 20220315-02 Steven to remove full-stop from namefollowers
<trackbot> Sorry, but no Tracker is associated with this channel.
Issue 53
Moving on to #53
Steven, I have a proposal that I'll publish later. I posted the XML part of that proposal in email earlier today.
https://
<Steven> https://
Michael: It works for me, thanks.
ACTION: 20220315-03 Steven to implement his proposal to resolve #53
<trackbot> Sorry, but no Tracker is associated with this channel.
Issue 20
Moving on to #20
Steven: This appears to be a wording issue.
Michael: No, I think there are two substantive questions here. 1. Are processors required or encouraged or allowed to accept grammars in XML form.
… related but not part of this issue is what constraints there are on that form (separate issue)
Michael parts quote of the issue.
Michael: What is our level of tolerance in a conforming processor for non-conforming grammars.
… In the past, I think we've said that we have zero tolerance. Extensions are a non-conforming behavior. Fine, but you must have a mode in which those are all rejected.
Norm: I agree, conforming processors must reject non-conforming grammars.
Steven proposes some text from his current editorial draft.
<Steven> My draft spec says: "A conforming processor must accept grammars in ixml form, and should accept grammars in XML form. A conforming processor must not accept non-conforming grammars. For any conforming grammar and any input: "
Norm: I'm happy with that text.
That resolves issue #20
Issue 21
Moving on to #21
Steven: I didn't like previous wording because it allowed a processor that did nothing to be a conforming processor.
Michael: If, for every conforming grammar and input, I must produce a result, I will never be able to make a conformant implementation.
… In the past, working groups I've been on have said that the market will discriminate against processors that do nothing. But making the set of conforming processors the empty set doesn't make the term conformance useful.
Bethan: We're saying that conforming processors should fail for grammar-related reasons, but they may fail for technical reasons unrelated to the structure of the grammar or the input.
Steven: How about doing this: adding "within resource limits" to the sentence about conforming grammars and inputs.
Michael: Is it only resource limits?
Tom proposes that we try to be intentionally vague here.
Bethan: how about "all other things being equal..."
Some additional discussion about vagueness.
Michael: I think that what some specs do is essentially say "if you can distinguish between normal operation that leads to a successful result and abnormal endings, then normal operations should lead to a parse or a failure to parse.
… It's the normal operation that the spec describes.
Norm: I mused earlier about changing the third bullet to "must indicate failure"
Bethan: In a sense, we are including the possibility that it should fail for some reason outside of control. That's an accidental, in the philosophical sense, result. The substance of what the processor does is described in the spec.
Tom: So accidents aren't within the scope of the spec.
Bethan: (scribe lost the response)
Michael: I disagree on the essence of computing. I think you can make a serious case that it is part of the nature of computing that the machines are finite.
… I like where you're trying to get, but I don't like your starting point.
Steven: Another problem for me is that I don't like conformance clauses that are untestable.
Bethan: How about "within the [technical] capacity of the hardware on which it runs ..."
Norm: I think "within resource limits" is good enough, if we take a broad enough view of "resource limits"
<cmsmcq__> Concrete proposal: For "For any conforming grammar and any input:", read "For any conforming grammar and any input, in normal operation:"
Bethan: Is it likely that we might be talking about failure for a reason that isn't to do with hardware.
ACTION: 20220315-04 Steven to implement the proposal to add "normal operation"
<trackbot> Sorry, but no Tracker is associated with this channel.
Administrivia
Moving on to "other issues"
Tom: Could we talk about some boring administrivia.
… It was difficult to run the meetings without Steven, could we try to fix that.
Steven: Am I the only one who can start the meeting?
Some discussion of problems with IRC and its incantations
Michael: I have a conjecture, there are two forms of the invite command, "/invite user channel" and "/invite user" without the channel. I think the second form relies on the IRC client supplying the name of the channel.
Steven: That's almost certainly the case.
Tom: Good. I think we can start a meeting somewhere else if we need to.
Steven: More administrivia?
Michael: Yes, I would like to discuss Prague and Balisage. Does Prague require speakers to be present?
Consensus is yes.
Steven and Tomos say they'll be in Prague.
Michael: If we want to make a debut, we should have something to debut and we should have a session at the conference. And I'd like to offer a report to Balisage.
Steven: I submitted the tutorial and a paper about my implementation to Prague. For Balisage, I'm going to submit something but not about ixml.
Michael: I will start an outline of a "this is where we are, this is what has changed, etc." draft. Anyone interested in helping, please contact me by email.
Michael: Because extensibility is of quite general interest, I would like to offer a paper together with Tom on our pragma's proposal.
Tom: Presented as a case study.
Steven: Any other business?
<Tom> It lives!
<Tom> (assuming that Steven didn't also invite rrsagent back - Steven?: