Meeting minutes
<norm> I think you're on the hook to scribe today, Steven, but let me know if you'd like me to.
I'm OK
What's the official position on non-members of the CG being on the calls, since they haven't signed the agreement.
Accept the minutes of the previous meeting
Steven: There's a topic heading missing; otherwise fine
Review of open actions
2024-03-05-c: SP to prepare pull request to resolve issue #139 (new grammars, new README)
[Done]
Steven: Agenda item for next time
ACTION: Steven split PR into three
Norm: I think the tests are uncontroversial
2026-03-03-b: Bethan to try making the title screen
Bethan: Continues
Status reports
Norm: I made a minor bugfix release
Steven: I'm in discussion with the students on how to go about the release
ACTION: Steven to find out the Delft testsuite results
Progress report on symposium output?
Bethan: Working on it.
… I use Adobe premiere pro
… it's a boring process
Open issues
Modularisation
Norm: Neither of the two are very different
… a lot of overlap
… a lot of difference is of opinion.
<norm> Norm observes that we'll be taking the two proposals as input; we'll be making a blend of those I expect.
John: It could be open or closed; I'm not sure how to resolve that
… the distribution of the grammars is in plain text at the moment.
Steven: The original version of a grammar may be textual, but the implementation can do what it wants with it.
David: Do I understand correctly that Norman describes a compiled format of ixml that would be distributed? In that case, I think that it's not really ixml but some implementation-specific distribution outside of ixml definitions.
Steven: My modularization proposal assumes that it gets the textual form and then compiles it into an internal form.
Bethan: That's an implementation detail.
Norm observes that we're doing a bit of cooperative scribing, so the record of "scribe" may be a bit confusing to the reader.
<aljo> Norm: Stepping back: what is modularization for?
Steven: To allow you to split up a grammar and allow you to include parts of other grammars.
Alan: Reuse.
Steven: Also for managing the components of a grammar.
David: Is there a useful difference between a situation where you have multiple iXML grammars and you can import pieces of them vs a situation where you have libraries of XML productions each of which lives in a file that isn't necessarily a valid iXML grammar.
… For example, in XQuery, a library module can't be used as a main module.
… Is it necessarily the case that the things your pulling together are complete grammars?
Some discussion of the question of whether or not included parts must be complete grammars.
David: If you're using some compiled functionality, how is there any guarantee that what you're including is just a bunch of rules.
Steven: A user thinks of it as iXML. The interface says you have these rules at your disposal and you can use them in your grammar.
David: XSLT packages give you a way to have private members.
David: If that's the goal, that seems orthogonal to the compiled/binary distinction.
John describes how packages work in XSLT, and how you might be able to use them in a compiled or source format.
Norm: I think the enforced contract is one of the distinction between my proposal and Stevens is how much enforcement is done.
Bethan: So it's like leading underscores in Python modules.
Norm: Interfaces in Java are so constrained, they're often avoided. Abstract classes are used instead.
Norm: I think we should make the interfaces useful but not a straight jacket that makes people want to avoid them.
Some discussion of how much an author needs to know about the grammar that's being included.
Bethan: Knowing how a nonterminal is defined, how it might react to whitespace boundaries for example, is critical to using the grammar.
Steven: You're complaining that you have a module doesn't do what you want.
Alan: Not exactly, but I need to know how things are defined so I know how to reuse them.
David: The amount of detail you'd need is basically the same as exposing the grammar.
Steven: I don't see the issues here. I hear you describing things that a module doesn't work very well, and you want to fix it, but that doesn't sound like an inherent problem.
… But I don't see the problem.
Bethan: You're hearing "this module doesn't work very well", I think what we're saying is "this module is great, but I want to make one small tweak to it."
… If all I can use the grammar for is exactly what you had in mind, that's very fragile.
Steven: Suppose you make a change that's outside the agreed on interface; the writer of that module rewrites it without changing the contract, but now everything breaks.
Norm: that's the point of "_" in Python. Don't use or change things that begin with "_" if you want to be safe.
Bethan: I want to be able to tell users that I might screw with this or that, but it also makes sense that I might want to play around with it.
Steven: I produce a huge module, then I change something, I don't want thousands of people yelling at me.
John: I've been think about what Alan and David were saying. There's a grammar and there's a domain of inputs that the grammar works over. The problem we might find with modularity, take the "does this module handle trailing whitespace", just taking the nonterminal...how do you define and make it clear to the person what the domain of the input is for that nonterminal.
… I don't think we in packages with functions, we have the same problems. Functions have well defined interfaces.
Norm: That's a good point, that's not quite how I've been thinking about it.
Alan: That's what I said.
Norm: I think we should start collecting use cases.
Alan: volunteers to describe an example of trailing/leading white space ambiguity from included grammars.
Next meeting
Steven: In two week's time, 21 July. The one after that clashes with Balisage on 4th August, and is duly cancelled.
<Steven> s/tehse/these
<Steven> iNorm: Stepping back: what is modularization for?/scribe: aljo
<Steven> s;iNorm: Stepping back: what is modularization for?/scribe: aljo;;