Meeting minutes
Accept the minutes of the previous meeting
[Accepted]
Review of open actions
Steven: I have done some research on the disambiguation operators
… see the paper
https://
Norm: If that code is open source, it would be good to know.
ACTION: Steven to find out if GLL parser is open source
Status reports
[None]
New open issues
Issie #295, ixml or iXML?
<Steven> s/Iss #295/Issue #302/
Steven: I don't see why it is an issue. It has always been ixml up to now
Norm: It's not a hill I want to die on.
Norm: It is split 60/30
David: Is there a rule about what can and cannot be changed?
… a switch to mixed case now would change what has been established.
… In unicode there is a principle that character names cannot be changed.
Norm: What's in the draft is clearly a change
Bethan: We should listen to the community as well.
Steven: We normally work on consensus. A change gets made is everyone can live with it.
Steven: We close this issue, with no change.
Perspectives on serialization
Steven: I have read it it, but I have some suggestions
… I don't think it covers what I had intended when I wrote "serialisation"
… so I plan to produce an edited version
[Discussion on what serialization means]
Pragmas
https://
The legal form of a pragma name must be defined in the specification.
[Agreed]
The structure of the optional pragma data following the pragma name must not be defined in the specification.
There must be a mechanism by which implementers can ensure that a chosen pragma name will not conflict with any pragma name used in other implementations.
David: How?
… is it possible to ensure it?
Bethan: namespace-like
Norm: Namespaces allows an insurance.
… domain names in reverse order is also possible
Simplicity of syntax and semantics should be the most important priority in adding pragmas to iXML.
Bethan: Not sure how easy it is to judge
… a problem is two proposals where one was simpler
Steven: "of importance" would be fine
The processor need not inform the user that it has encountered an unrecognized pragma.
Norm: Implementation issue, but not by default
Recognized but ill-formed pragmas need not cause the parse to fail, or cause the processor to issue a warning. That is, if a processor recognizes a pragma identifier, but the pragma data cannot be parsed successfully as input to the relevant code block, the response is wholly a matter for the implementer.
Bethan: No requirement that an illformed pragma causes the processor to stop
A pragma’s attachment to a specific syntactic construct must be unambiguous to software for parsing iXML grammars.]
Nico: My question is if this can be implementation specific
[Discussion on "Attachment"]
David: About implementations agreeing on pragmas, how would that agreement be reconciled with point 15?
<Steven> s/ABOUT IMPLEMENTATIONS AGGREEING ON PRAGMAS. hOW WOULD THAT AGREEMENT BE RECOGNISED WITH POINT 15??About implementations agreeing on pragmas, how would that agreement be reconciled with point 15?/
Norm: A unique name insures you won't have mismatching semantics
Bethan: Collaborative decisions, should use a combined space
Nico: 20 implies 19.
… when you place a pragma in the linear notation, would that be enough to require it to be in the same location in the XML notation?
Bethan: We separate syntax and semantics already.
Nico: I could make a pragma that depends on all parsing that has gone before
… so then it doesn't depend on a particular construct
[Long discussion of attachment and whether it is required or optional]
[ADJOURN]