Meeting minutes
<cmsmcq_> Hmm. I wonder why I am here twice
Actions
Michael: Nothing done, even the easy ones!
ACTION: 2023-07-25-a: Norm to create an issue w.r.t. end of line
normalization: Done
Norm: All my actions done except publishing the report
John: Done ACTION 2023-07-25-c: JL to redraft his notes on grammar combination
and send something to the public list.
John: Done ACTION 2023-09-05-g: John to implement the renaming proposal
Status of implementations
John: Added renaming
… works fairly well
… Need to talk about "version" later
… there are a number of symbols we haven't used, like %
… we might want to bear in mind that they are available
Norm: Working on improveemts
Status of testing and test suites
John: Are there renaming tests?
<cmsmcq_> We definitely do need tests for renaming.
ACTION: Norm create tests for renaming
Issue #199 Require whitespace between prolog and first rule?
Michael: It's not ambiguous, but we should do it for consistency
Steven: So resolved
ACTION: Steven to make pull request for grammar for space after prolog
Issue #197 Remove the Unicode non-character constraint
Norm: RFC for JSON, and they have a rule that includes non-unicode characters
"An encoded character is an optionally marked hexadecimal number. It starts with a hash symbol, followed by any number of hexadecimal digits, for example #a0. The digits are interpreted as a number in hexadecimal (error S06) , and the character at that Unicode code-point is used [Unicode]. The number must be within the Unicode code-point range (error S07), and must not denote a Noncharacter or Surrogate code point (error S08)."
Norm: I'm happy to say that you can't have them in Unicode, and you can't use them.
Michael: the ixml grammar of the JSON grammar can't then be a simple transcription.
Steven: We leave the spec as is then.
ACTION: Norm close issue 197 without changes
Norm: Should we have an FAQ?
Michael: A good idea.
Norm: You could create a range that is expressible, but that includes noncharacters...
Michael: But the input still can't contain those characters
Norm: I can live with that
ACTION: Michael draft a FAQ
Steven: The spec requires UTF-8 encoding, but doesn't explicitly restrict noncharacters
Michael: I think that our rules effectively mean that noncharacters are excluded
Steven: Except exclusions
… would allow noncharacters
… input: ~[]*.
… input: -~[]*, +'.'.
Norm: I'd like to see what Michael writes in the FAQ.
Issue #189 What are the control characters
Norm: This is resolved using character classes. We can close.
Issue #181 Non-serializable characters in the input
Norm: Has been closed
… raises error D04
Issue #139 Sample grammars for IRIs and URIs
Steven: Where are we at?
Michael: Awaiting review
Steven: On the agenda for next time
Issue #192 Normalizing line endings in ixml inputs
John: Before that. About version
Version
John: Are the version numbers collatable?
… is there a strict ordering?
Bethan: It would be good to agree a format
Norm: I'd rather put off the decision till when we have a versionable number
Michael: How about "Tokenise on '.', that is a sequence of keys, if a key is a number, then compare numerically, otherwise lexically"
Bethan: Rather just use numbers
Michael: Are we the only ones to create a version number?
Bethan: Yes.
John: Leave it on the backburner
Issue #13 Renaming proposal (for v.Next)
Steven: Nothing to discuss?
Norm: Merge?
All: Yes
Issue #192 Normalizing line endings in ixml inputs
Norm: 4 options.
… it is a pain
Michael: I would like our abstraction to be that we are parsing unicode characters, without an abstraction on top of that.
… normalising default is OK; require it to be disableable
… I see uses cases for not normalising
John: So what do I write?
Steven: I was thinking of U+2028
… line separator
Bethan: I like the idea
… would it be in input anyway
Michael: Could be
Michael: We need a written proposal
AOB
Steven: Next meeting in 2 weeks
John: Regrets
[ADJOURN]