Meeting minutes
Previous Actions
ACTION 2023-01-10-b: Michael to take another pass on the EBNF to BNF
document
Michael: Continues
ACTION 2023-01-10-d: Michael to work out the metadata for identifying
the Unicode version(s) associated with a test.
Done: https://
Michael: Let's discuss later
ACTION 2023-01-10-f: Norm and Michael to do a bit of revision to
improve the draft documentation of the XML
vocabulary (see #137) for further discussion.
Norm: Continues
ACTION 2023-01-10-h: Michael to review RELAX NG rules and report back.
Done: https://
ACTION 2023-02-07-a: Steven to make Pull Request for Unicode test
[Done]
Steven: There is a test to try and comment on
Steven: I copy the input to output, not strictly needed
Norm: I think it's a good thing
ACTION 2023-02-07-b: Michael to think about adding to the test suite
schema to cover browser (etc) version
Done: https://
ACTION 2023-04-11-a: Norm to investigate production of
rules-conformant version of spec, for publication
as CG Report
Norm: Continues
ACTION 2023-04-11-b: Michael to explore the use of named environments
in the test suite
Done: https://
Michael: We shouldn't do it now, we can discuss shortly
ACTION 2023-04-11-c: John to write up his work on grammar import.
John: Half done
… in Markdown
… I may send the draft to us individually tomorrow
ACTION 2023-05-09-a: Norm to revise the erratum to include stripping
the BOM from UTF-8 input strings (as a should).
Done: pull request 178.
ACTION 2023-05-09-b: Norm to make a pass attempting to describe
serialization.
Done: pull request 179.
Norm: Reformatted today with changes from Michael
… All to check
ACTION 2023-05-09-c: Steven to produce new sample grammars for issue
#139 for discussion in June.
Steven: Posted today
<norm> https://
Steven: run it on the examples and see what you think of the output.
ACTION 2023-05-09-d: Steven to produce a discussion document for
renaming (issue #13).
Steven: Continues
Status reports
John: I updated based on comments from Steven
… there were spaces missing in the output
… it's implementation dependent whether whitespace is preserved
Steven: Did you track down the problem where out implementations differ?
John: Not yet
ACTION: Steven to upload ambiguous test to test suite
Norm: I tidied some stuff
Steven: Small changes, nothing special
publication plans
Norm: Continues
Steven: I gave tutorials and talks at web conference and MarkupUK. Went well
Review and resolution of bug reports and technical issues
Issues #174 and #175 BOMs
RESOLUTION: accepted
Norm: I will republish the errata
Issue #176 Encoding CR, NEL, LINE SEPARATOR etc.
Bethan: I disagree with the use of "not constrained" in this paragraph.
[Discussion]
Bethan: OK, I'm OK with it
John: I have an example where spaces are removed from the serialization. Is that allowed?
… under indentation conditions, whitespace is elided.
Norm: This is about indentation. It's covered in the XML Serialisation spec.
Michael: It's ok to have an option for indented output
… I think that as long as there is an option NOT to indent, it's OK
Steven: Do we normatively reference the serialisation spec?
John: It's only when we serialise that the whitespace rules kick in
… we have an XML tree, what we do then
Norm: Our spec says it is manditatory to serialise
Michael: It troubles me how we use serialistion as term.
… making a tree is parsing not serialisation
… I don't think we should police APIs
Michael: When you pass a tree to a consumer, you are out of the purview of the spec
… we don't specify how DOM trees are handed over
Bethan: The spec does say that processors SHOULD be able to serialise as characters, but, also, ....
… is that 'also' instead or in addition?
Michael: An ixml processor must be able to produce a sequence of characters
Steven: We haven't answered John's question yet
Norm: Serialisation is constrained that it has to provide the right XML
Michael: For "the XML" read "the selected parse tree".
Bethan: That resolves my position
Michael: for the minutes we have two questions: John's question, and Steven's about whether we reference the serialisation spec.
… I would like to avoid referencing the serialisation spec.
Norm: I don't want to impose the constraint that we are building an XDM instance
Michael: It would make sense to say that processors could use options defined in the serialisation spec.
… It would allow John to offer indentation
Norm: I'd be prepared to stop short of requiring those options be able to be turned off
Michael: There may be choices in serialisation that the Serialisation spec allows that we don't want to allow as options
… indentation=off is a requirement for the testsuite
John: I do my test checks not at the text level, but compare XML trees
ACTION: Steven to add spaces test to suite
Norm: how about a nonnormative ref to Serialisation, and a note about not adding new whitespace as a SHOULD
ACTION: Norm to assemble a proposal on Serialisation
[We read Norm's new paragraph, and grunt in agreement]
AOB
Norm: We need to speed up. For instance every two weeks.
[Agreement]
Michael: Second and fourth weeks?
Norm: No, every 14 days
<Steven> Next meeting: 27th of June; after that maybe 11th July, play it by ear
rrsaget, make minutes