Meeting minutes
Review of agenda
Previous-meeting: https://
<cmsmcq> Previous meeting: https://
Actions: MSM add dynamic error to schema (not done)
Norm: action on #66: awaiting Michael's action
steven to change dot in names rule - not yet on github
msm to provide schema (not done)
steven to edit spec about varying ambiguity detection
(done)
steven to describe input as utf8 and optionally other (done)
Status of implementations
NDW: 1.0.0 of nineml is now out.
JL: I've run it successfully.
paper deadlines
XML Prague deadline Thursday.
Steven has submitted.
Balisage deadline 8 April.
Various papers pending.
Status of testing and test suites
NDW: we can close 56 when MSM has done his action.
NDW has added some correct-grammar tests.
They are awaiting review. Currently they are for the February grammar.
SP reports that his parser is producing different results; NDW and SP discuss how NDW is invoking the parser.
NDW: another issue. There is an s missing in set, needed before closing bracket.
s does not work before a semicolon, either.
SP thinks he has a test that adds a space everywhere; he does not understand why that test did not pick this up.
Review and resolution of bug reports and technical issues
Pragmas proposal (continued) (issues #10, #29, #30)
SP: Norm's suggestion that we do email discussion was a good one.
SP: I think Norm's mail shows there is disagreement about what pragmas are for.
MSM: what is ok and not ok?
SP: ok is choice of parsing algorithm,
or option to suppress ambiguity
or option to use a particular encoding
But we should not change the semantics of ixml.
or allow pragmas to do so.
JL: those examples are all configuration options - they aren't related to the grammar but to an execution.
SP: that's why I said at the outset that I didn't think pragmas are needed.
TH: if all you want to use pragmas for is to signal something for a single implementation, then why put it in the grammar?
SP: right at the beginning there appears to have been a misunderstanding about what work was being done.
MSM: The this-is-a-token pragma NDW mentioned does not in fact change the semantics of ixml.
SP: But it does.
MSM: if someone wants to extend the language at all, is it SP's position that they should do so silently? or not at all?
SP: by all means. But don't call it ixml.
MSM: is that a good way to promote ixml? It amounts to saying "don't use this spec".
JL: Consider the tree-trimming annotations.
They allow a concise description of a grammar whose XML ASTs are different, but which could be handled with a source-to-source transformation of the grammar.
What are the pragmas we are interested in that could be done with a source to source transformation?
NDW: some of them could, but some of the pragmas I'm interested in cannot.
NDW: I think having a documented extensibility mechanism is better than the alternative of saying "take your toys and play elsewhere".
TH: Saying that pragmas create an interoperability problem seems to ignore the fact that the proposal specifies that processors must be able to ignore all pragmas
We discussed whether the pragmas proposal requires that implementing a pragma not change the semantics of the grammar.
That has been proposed, but has not been adopted.
NDW: would it help to require that processors who have implemented a pragma have a mode in which they not only ignore the pragma but report if they see any pragmas that affect the semantics of the grammar?
BTW: is it always clear whether it would produce a different result?
MSM: it really ought to be clear from a good specification of the pragma.
SP I really don't want to mess up interoperability.
Although everyone says ignoring pragmas will guarantee interoperability, it will happen that implementors say "to get this result, you must use this pragmas".
SP: the examples of CSS and HTML show that this can be a disaster.
MSM: but HTML and CSS are omnipresent.
SP: I'm not against experimentation. I'm against saying "this experiment is official ixml"
TH: should we be saying explicitly that pragmas are not in fact official ixml, but precisely marked segments of not-official-ixml?
BTW: would it help if the rule were not "processors must be able to ignore pragmas" but "pragmas must be able to ignore pragmas and report that pragmas were present but ignored"
NDW: or just "processors must have a mode in which all pragmas are signaled as errors"?
TH: if we allow pragmas, I'm happy to say that any processor actually paying attention to a pragma is operating in a non-compliant mode.
BTW: Or we could flag the output -- just as for ambiguity. We could say "ixml:state='pragma-dependent'" ?
BTW: this discussion does seem to reflect a surprisingly dim view of implementors and users of ixml.
BTW: Maybe we could take a chance on trusting people.
Next scribe is JL.