Meeting minutes
<Steven> (I think)
Discussion of Steven's renaming proposal.
Steven: In brief, you can say "identifier>name" to change "identifer" into "name" in the serialized form.
In the grammar, you refer to the identifier, not the name.
Norm: And I've implemented it.
John: Can we wait until I've had a chance to try implementing it?
Michael: Ok, let's wait and then bless it next time.
Steven: I want to come back to the topic of round tripping, which is certainly made more interesting by this proposal.
Next meeting
Cancel 19 September, next meeting is 3 October 2023.
Refer to control characters by class
Norm: This is PR #193
Michael: That leads me to a follow-on question, since conforming behavior depends on what version of Unicode it supports, should there be a statement somewhere that says a claim of conformance needs to contain what version of Unicode is supported.
Norm: Yes, we could say the version of Unicode is "implementation defined", obligating the implementor to define it.
ACTION: Michael to open "version of Unicode" as an issue.
Michael: We probably want a checklist for implementors so they know what they need to define.
Accept PR 193
ACTION: Norm to merge PR 193
Fix typo in ABNF grammar (PR #195)
Norm: These are easy.
John: Do we say that our identifiers are case *sensitive*?
ACTION: Michael to raise an issue about making the case-sensitivity of iXML names explicit
Proposal to accept PR 195
Accepted.
ACTION: Norm to merge PR #195
ABNF sample grammar that incorporates errata (PR #196)
Accepted.
Proposal for options, environment, and dependencies
This is PR #173
Michael: This is for identifying things like the Unicode version in the test suite.
Accepted
ACTION: Norm to merge PR #173
ACTION: Michael to update (some of) the test drivers
ACTION: John to implement the renaming proposal
Grammar composition
John: See https://
John walks us through the document
John: There are two parts: what are you combining and how. This could be done in XML (but not iXML text) or in both.
John: For referencing, we could have a URI reference to the grammar file. Or, like XSLT packages, it could be done by reference to names and versions defined some other way.
… In the case of XSLT packages, the expectation is that packages will evolve through versions so it seems worthwhile.
… Less clear that it's worthwhile for grammars. I suggest we go the URI reference route.
John: The next question is, what rules do you want to combine?
… There are a bunch of options in the use cases document.
John: Let's hypothesize an iXML grammar for these things
(See the grammar in the document)
John outlines the rules for what to accept.
Michael: If I say "accept month" I think you're saying I want months as they're defined in that grammar over there.
… But if there are other nonterminals reachable from month, are they imported in a way that means I can refer to them, or are they invisible?
John: That's an open question.
Steven: My feeling is that for managable grammars, the grammar maker wants to say "you can use this and this" but not everything.
John: The next question is one of renaming while importing.
… You might need to do bulk renaming.
John: The final bit is the whole issue of overriding.
… There are two ways of thinking about it: in the declaration, we say this is overridden and the declaration is below, or we could say "here is the overriding definition"
… Then there are edge cases: is it an error to override a rule that isn't in the grammar?
John: We could say, you can override everything.
John: Then there's the question of wanting to override rules as they're being imported.
John: We could even provide a mechanism for referring to the original rule. Something like `$original`.
John: I've implemented some of these things.
John: I thought maybe we could get away without having to deal with visibility, but I think that's probably not possible.
Norm: Thanks, John. This is a great exploration of the space. I think what I'd like to see is a concrete proposal for the smallest practical set of features and see how it covers the use cases. Not a maximal proposal that implments everything, but the smallest thing.
Steven: In some sense, I feel a little difficult about making alterations to something you've imported.
… Importing a program library often involves importing a couple of top-level functions, but not the ability to change things "under the hood"
… It would be nice if the way we define it doesn't compell you to do it one way or another.
Norm: Yes, I think we need to describe the process at a level above the syntax.
Michael: What worries me is that there are use cases where you want to import a start symbol and have all the internals be a black box. But if we want to define a composite grammar, we won't find anything in current grammar theory that guides us.
… There are use cases where that is going to be what you want, but in practice, you are going to get cases where people want to make exceptions.
… I'd like to be able to support both a black box and a whilte box.
Steven: Isn't the white box case just copy-and-paste?
Michael: I'd like to be able to do something that has that effect but allows me to maintain more modularity. Having 17 copies of it is going to be problematic.