Meeting minutes
Action 2023-01-10-f continues.
Action 2024-03-05-c shows progress - using ssh is better, for github, than using http.
Action 2024-03-19-a is awaiting work by Norm.
Action 2024-04-16-a continues.
Action 2024-04-16-d is done.
Action 2024-04-16-e is done.
Other actions are continuing.
Status of implementations
Nothing to report.
Round-tripping
John asks for info from Steven's paper on round-tripping for Prague, to mention it in his round-tripping paper for Balisage.
Status of testing and test suites
Nothing to report.
Version numbers
<norm> https://
Pull request #243 is Norm's attempt to improve the situation, although it does not attempt to resolve all issues.
<norm> https://
John: so the upshot is that under these rules, a processor supporting renaming is no longer required to require a version 1.1 declaration.
Norm: yes.
Norm proposes to take another action to work on ixml:state.
At the least, 'version-mismatch' is a clumsy term. Perhaps you need to say which version you actually used.
John: no good to say "we ran it under some other version" without telling you what you ran it under.
Bethan: and the name ixml:state is not a great match for this meaning.
Steven: yes, it started simple and we have put a lot more into it.
Norm muses on a possible separate attribute like, say, ixml:version to say what version was used.
ACTION: Norm to propose wording for possible changes to status reporting.
Discussion over whether the presence of an ixml:* attribute is always / still an indicator that something did not run cleanly.
MSM thinks reporting which version was used for an unlabeled grammar is not a sign that something didn't run cleanly.
Norm suggests that perhaps it's just the presence of ixml:state that indicates something a bit off.
<Steven> I think that if you don't specify a number, you don't care, and so shouldn't get an "error"
RESOLUTION: to merge PR #243.
Issue #237 can now be closed.
Issue #238 can now be closed.
Issue #236 When must version numbers change?
Steven suggests that when new syntax is allowed, no version number change is needed. A down-version processor will reject the new syntax on purely syntactic grounds.
Discussion of what "no version number is needed" means.
Steven is considering the question "when does a grammar need to declare its version number?"
He is not proposing that we not use a new version number on the specification.
John suggests thinking about what language(s) a grammar is a sentence in.
To take a concrete example, a grammar that uses renaming will be a member of L(1.1) but not of L(1.0).
A grammar that does not use renaming will be a member of both.
MSM attempts to summarize our consensus:
… If the set of strings accepted by the specification grammar does not change,
… and the XML structures to which they are mapped do not change,
… and the meaning of those structures does not change,
… then a revision of the spec need not carry a new version number.
If any of those things change, the spec requires a new version number.
No version number is required on the input grammar.
Including it will assist clarification / diagnosis of problems.
Omitting a version number in the input grammar will lead the processor to process the grammar using some version. If the string is accepted,
… and the meaning has not changed, the user will be happy.
If the meaning has changed, the user may or may not be happy.
ACTION: Bethan to open an issue on whether to distinguish 'major' from 'minor' versions.
RESOLUTION: close issue #236 on the basis indicated.
(Steven points out that this resolution is not about what he thought #236 was about in the first place, but is willing to close #236.)
Any other business
Norm and Steven are going to Prague, but no one else is planning to be there.
Steven reports that John Chelsom's City EHR health records system is being rolled out in Ukraine.
John Chelsom is of course looking for volunteers to help on this open-source problems.
We agreed to cancel the meeting of 14 May (conflict for NTW and MSM).
Next meeting 28 May.
John Lumley offers regrets for 28 May.