MathML-Core Meeting Minutes from February 28_ 2022

02/28/2022 MathML Core Meeting

 Attendees

* Bert Bos
* Deyan Ginev
* Brian Kardell
* Louis Maher
* Bruce Miller
* Murray Sargent
* Patrick Ion
* Neil Soiffer
* Moritz Schubotz
* Oriol Brufau
* David Carlisle

 Regrets

* Manuel Rego
* Stephen Watt
* Fred Wang

 Announcements

NS: has filled out the form for the MathML working group for the 2022 TPAC conference which will be held in September.

Brief progress updates/plans?

 Issue reopened from last month on
Stable and compact operator dictionary #104<https://github.com/w3c/mathml-core/issues/104>

NS: Fred had added a check list of to do items. NS has not gotten through this checklist. Something is inconsistent with the colon.

NS: Does anyone know about Z notation?

DC: Z notation colon on stackexchange
https://tex.stackexchange.com/a/315327
(it is \mathrel in unicode-math)

NS: Removed two-letter ascii notation.

NS asked about dot-dot notation.

DC: did not think it was used.

NS it is used in Rust.

NS: There is a list of characters including vertical bars that have several meanings. The meanings change depending on if they are used as a prefix or
an infix.

PI: The symbols for "because" and "therefore" are shown by triple dots.

NS: Tilde has prefix and infix meanings.

DC: We should not have to change core values to protect them from being deleted.

DC: We should not drop default values to shrink the spec.

NS: We want to shrink the operator dictionary. We cannot prune it if the prefix and infix have different values.

DC: will take some action on this.

Follow-up on
Include mo@accent attribute into MathML Core? #52<https://github.com/w3c/mathml-core/issues/52>

DC: Accents again.

NS Get rid of accents on mover.

NS: MathJax depends on this.

DG: MathJax is willing to make a change.

NS: We are going to say that core does not need to support accent equals true false on MO mover and munder.

BM: Will the full spec allow it or deprecate it?

NS: Generators need to know which character is an accent. perhaps put this information in the informative document.

NS: There are a lot of lookalike characters. The core does not specify which character should be used.

NS: The informative spec should recommend which character should be used for symbols like overbars. This is not part of core.

NS Currently core says nothing about which characters should be used for which symbols. This information should be written somewhere. This information should not be in the spec itself.

NS: There needs to be implementations and tests before this can be closed.

Continue discussing U+002D HYPHEN-MINUS in operators #70<https://github.com/w3c/mathml-core/issues/70>

NS: We do not know how to proceed without Fred. Fred disagrees with the rest of the WG.

NS We will pass on this until Fred comes to the meeting, or the WG just decides.

Decide how to handle unknown MathML elements (issue #71)<https://github.com/w3c/mathml-core/issues/71>, U+002D HYPHEN-MINUS in operators (issue #70)<https://github.com/w3c/mathml-core/issues/70> and related splitting of issue
----------------------------------

NS: How do you handle unknown elements?

NS: We do not want negative tests that might keep MathML from being supported.

DC: Will see if the mfence test fails.

From David Carlisle to Everyone: https://github.com/web-platform-tests/wpt/blob/015524b5fa/mathml/presentation-markup/mrow/legacy-mfenced-element-001.html

NS: There is an IDL issue.

NS: Some things in the full MathML spec, and not in the core spec, may be moved to level two in the core spec.

NS: Will this cause tests to fail because these items are new to core?

NS: How do we add new things without causing tests to fail?

NS: What do tests due when they run into unknown items.

DG: Tests should not fail if a browser supports more things than are in the spec.

DC: The tests are at the top of the spec.

NS: How do we handle unknown MathML elements. SVG is parallel to us.

BK: The spec does not need to be careful, but the tests need to be careful. They should not fail because the tests handle more things than are in the spec.

BK: There are known unknowns and unknown unknowns.

BK: The first browser might be hurt because things change after it has been shipped.

NS: We removed support for mfence.

BK: We should have a test saying something is an unknown element.

BB: Have the test come out successful if you support or do not support an element.

BM: Are you checking for support or forbidding support? Certain attributes are in the full spec but not in core. The test suite should not punish people for supporting these attributes.

NS: CSS can query for what is supported. Your test should ask if something is supported before the test is run. HTML script elements also have this support test strategy.

BM: this assumes that you are testing for the extension. If your spec says this element is missing, then the test will fail if it finds this element.

BK: We need to know what is and is not supported.

BK: When a person ships something that is not yet supported, do you allow them to pass tests?

DG: Have a supported flag to guide which tests to run. If something is not supported then they are unknown elements. the supported flag guides the main tests and the fallback tests.

BK: this problem is not unique to MathML. Different browsers can give you different answers.

DG: He mentioned "mpadding" attributes which do not conform to the spec. This is for "plus minus".
---------------------------


Regards
Louis Maher
Phone: 713-444-7838
E-mail: ljmaher03@outlook.com