Meeting minutes
Previous Actions
Steven: I see 4, but there were another 4, and I have done all 8 and republished the draft
Michael: So all implementations are now broken
Status of implementations
John: All broken
Status of testing and test suites
Michael: also broken
Norm: I submitted a bug
… there is a question to be considered.
<norm> https://
Steven: How the test should be classified.
Michael: Dynamic errors are errors in the grammar; another analysis is that we have "not a sentence" "not a grammar" or "dynamic error"
Norm: Or "Not XML"
John: Like XSLT for some inputs it will cause an error, but not for others, so the stylesheet is not in error
Michael: Depends
Tomos: I don;t think the error is in the input.
Steven: We have no conformance requirements on input.
ACTION: Michael to update schema for test catalogs to add dynamic error
<trackbot> Sorry, but no Tracker is associated with this channel.
ACTION: Norm edit the pull request for #56
<trackbot> Sorry, but no Tracker is associated with this channel.
Michael: I rely on the test suite, so would like it to be up to speed as soon as possible.
[General agreement to work on it]
Pull request #54, partial draft of error codes for spec
https://
https://
Norm: I did a few of them, to see what it would look like.
… Michael gave it the thumbs up
Tomos: I saw some, but not this one
Steven: I shall look this week.
Tomos: Maybe we should write the spec in a different way
Norm: But with a processing step that generates the errors appendix
Norm: I will set up a CI tool to do the build.
ACTION: John Steven Bethan Tomos to review the errors proposal
<trackbot> Sorry, but no Tracker is associated with this channel.
John: Could we have a prefix on the error numbers, not just a number?
Issue #48 S=a.a.a=c;a.a.a=c;.c='x';a;a.a.
https://
https://
<norm> FYI: Github is bork. https://
Michael: I agree with Steven's proposal
ACTION: Steven to change the "." in names rule.
<trackbot> Sorry, but no Tracker is associated with this channel.
Issue #28 Schema for grammars
https://
https://
Michael: In December I proposed that we have a schema for the grammars in XML form
… we should create and publish such a thing
… that also allows extensibility
… allow namespaced attributes
… in a namespace not in ixml
… and even namespaced elements
… that may be a step too far for some.
John: Namespaced attributes matches xslt, foreign declarations allowed, not sure about elements.
… Can we derive such a schema from ixml?
Michael: Yes
Steven: Sounds like a great topic for a paper
Michael: My code provides relaxng
… still not perfect
… requires some hand editing
John: Is there a tool we could make to provide a schema for the output from ixml?
Michael: Yes
Norm: Are we opposed to such a proposal?
[No]
ACTION: Michael to provide a schema for ixml in XML
<trackbot> Sorry, but no Tracker is associated with this channel.
Spec issue #26 - how is ambiguity defined?
https://
https://
Norm: I started this...
… I believe I have now concluded that even if all ambiguous parses produce the same XML it is still ambiguous.
Steven: Agree
Michael: We could create test cases. I would like to find wording that alerts users to the possibility that different processors may return different results.
Michael: for instance is "S: "a"*; "b"*. ambiguous on the empty string?
Michael: I would like to make flagging of ambiguity a SHOULD rather than a MUST
Tomos: I don't see the value of knowing something is ambiguous.
Bethan: I can think of lots of reasons why people would care.
Norm: We've agreed that it is a user option.
… this satisfies the I don't care people.
… a paragraph that calls out that ambiguity is differently spotted
Tomos: If something is ambiguous we shouldn't care which parse we get
Michael: No, for some it is important.
… if we've got the wording that Norm mentioned, I'm happy.
ACTION: Steven observing that 'ambiguity' isn't precisely defined
<trackbot> Sorry, but no Tracker is associated with this channel.
Bethan: I think users should be able to say that they don't care about ambiguity, is different from an implementor saying that.
Norm: You won't pass the test suite if you don't report ambiguity
Tomos: One of the strengths of ixml is allowing ambiguous parses
Michael: Still, an ambiguous parse is almost always an error in the grammar.
Steven: And ambiguity slows parsing quite a lot.
Issue #50 Characters or octets? both? either?
https://
Norm: The current spec is unclear about the input "string".
… I would prefer not to say that the input has to be an stream of unicode.
… I would also like to parse binary files possibly.
Michael: I'm nervous. My parser needs to be a sequence of unicode. I don't want to prevent binary parsing though. How gracefully can we say? Implementation defined?
Norm: Maybe use "it may be able to process binary".
John: Seems like a huge rabbit warren.
Tomos: Be loose about what we accept?
Michael: Which encoding?
Steven: We say UTF-8
<norm> The string "utf" does not appear in the 2022-02-22 spec
Norm: No, there is no UTF in the spec
Steven: Oh!
ACTION: Steven to make it UTF-8
<trackbot> Sorry, but no Tracker is associated with this channel.
Norm: Do we do line ending normalisation? To deal with different line-ending styles?
Steven: You can write a grammar that accepts all possible line endings, so we should just leave it at that.
Norm: I can live with that.
Steven: Do we want to mention octets?
Michael: The more I think about it, the more I think we should say that the input stream is implementation defined.
Tomos: I think "may accept other forms" is best
ACTION: Steven to add MUST accept UTF-8, MAY accept other forms.
<trackbot> Sorry, but no Tracker is associated with this channel.
AOB
Steven: Next week pragmas, with an email discussion beforehand
Steven: Next week back to the normal time for USA