Meeting minutes
Review of action items
ACTION 2023-01-10-f continues.
ACTION 2023-11-28-a continues.
ACTION 2023-11-28-c continues.
ACTION: 2023-11-28-e was done in https://
ACTION 2024-02-20-a
has been done.
ACTION 2024-02-20-b continues.
ACTION 2024-02-20-c has been done (issues #234 - #236)
Pull request #224 Mitigating ambiguity in mod357
Status reports
JL reports he has done a lot of exploration of generating ixml grammars, with special reference to auto-generation of XPath 4 grammar.
You can generate quite big ixml grammars, and the issue of controlling inherent ambiguity really needs to be looked at.
Any spec which uses extra-grammatical constraints to resolve ambiguities will exhibit this problem.
JL uses an ixml grammar to parse the source code for the specification of the XPath 4.0 grammar in the specs, and produces an ixml grammar.
NTW has nothing to report.
SP is working to prepare for Prague, but has nothing visible to report.
Pull request #224 Mitigating ambiguity in mod357
<norm> invisibleXML/
We discussed.
Ultimately, GR's suggestion is a way to make the test catalog more manageable.
We can do that by making the results deterministic, as GR suggests.
Or by using only unambiguous test numerals.
We reached consensus that we should accept the pull request.
ACTION: Norm to confirm correctness of #224 and commit the pr
ACTION: Norm to test the correctness of PR #224 and merge if it is correct.
Pull request #225 Fix errors in ixml-spec-grammar performance test for XPath
Yes, accept.
Pull request #226 Additional result for performantce/xpath xsltforms-3
Accept this.
Pull request #227 Add .gitattributes
NTW suggests leaving #227 unresolved until we have resolved issue #192.
Issue #233 There are other things called iXML
ACTION: Norm to add a section to the home page pointing to other things named "ixml" or "9ml" or ...
Jim mentions another recipeML
Issue #139 Sample grammars for IRIs and URIs
SP clarifies that he doesn't propose to replace the existing ixml grammars, just to add a new one.
NTW says that's fine, just modulate the tone in the README a bit.
ACTION: SP to prepare pull request to resolve issue #139 (new grammars, new README).
Issue #236 When must version numbers change?
<norm> SP: I don't like version numbers.
<norm> CM: I don't like them either but consider the case of a C program from the mid-eighties that heavily used some extensions...I can't compile it.
<norm> ... If something claims to be a correct iXML grammar for version 3, I don't need to be surprised if it isn't processable by a 1.1 processor.
<norm> ... If there's no version number, then, "well, sometimes iXML grammars work and sometimes they don't." A race to the bottom.
<norm> Some discussion about whether or not a construct that is an error in 1.0 that is then allowed in 1.1 is considered a change of semantics or just a change of syntax.
<norm> SP asserts strongly that adding new syntax not valid in 1.0 is not a change.
MSM asserts strongly that the change from "not a grammar" to "a grammar with a particular meaning" is a change to the semantics of an input.
We discussed, without any visible forward progress.
next meeting 19 March.
Beware time zone shift in US
typo in 1.0 spec
Pi should be defined as 3.1415926 not 3.145926