Minutes: MathML Full meeting 28 Sep, 2023

<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.1#cp-md-0-attendees->
Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Moritz Schubotz
   - Bruce Miller
   - Paul Libbrecht
   - Deyan Ginev
   - Cary Supalo
   - David Farmer

<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.1#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.1#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

NS: We are coming up on our recharter date. NS believes that we have been
rechartered.

PL: I'm currently reviewing a very interesting master thesis about using
transformer architectures to read out loud formulas which are written out
in Latex format, graphically. So, the author is basically doing OCR, then
LaTeX and then he's having like individual pipelines that do the whole
thing and then he's having like individual pipelines that test the whole
thing and then it's comparing this to ChatGPT.

PL: The author did not know about MathCAT.

PL: This could be an intent enrichment process.

NS: MathCAT is now in the 2024 JAWS beta. JAWS is possibly the most widely
used commercial screen reader. MathCAT is getting some good traction.

PL: could invite the author to our meetings if we wish.

DC: has become the editor of technical article 25 on the Unicode site. It
started as a pdf document. Now moving to an HTML base. He would like the
document to be pure MathML. If anyone has comments about this document,
please let DC know.

PL: is giving a talk on mathematical cultures. He was surprised that
standardization can be considered a bad thing. ISO tried to make
mathematical standards. ISO 80000 is available, but it is unclear how this
can be reached or if, at all, we could contact them somehow.

Example https://webstore.iec.ch/publication/29416

MoS: I just wanted to give a short update on my project. It is now a public
demo.

From Moritz Schubotz to Everyone:
https://en.wikipedia.beta.wmflabs.org/wiki/Help:MathTestNative

PL: The web clipboard enterprise, which was discussed in the TPAC in
Vancouver last September, just got unblocked. So, it seems like we are
converging, and I'm not sure Mozilla has yet voted to accept it, but this
is coming to a reality soon now, and that means that offering a
JavaScript-based copy that applications might take over. If they take over
the charge of sanitizing, it is going to be a possibility.

PL: So, it's migrated into the current spec of the clipboard operations.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.1#cp-md-0-2-interop-submission-suggestions>2.
Interop submission suggestions

NS: We want to make sure that all browsers work with a certain feature.

BK said that if we want something to be considered, it should be a small
item, and our group should suggest it as a group. Last year, we suggested
getting CSS to work with MathML. This was not accepted.

NS: What should we be suggesting? Is it better to say what would work if
our item was accepted, or would it be better to say the problems that occur
because our item does not work.

DG: I am mostly thinking of the political path forward where we can get the
most out of the process. We could try an alternative angle of finding the
small, practical, easy, focus area for MathML that is one specific feature.
These are wonderful examples of accepted issues from last year where it's
Very targeted small things.

DG: One of my favorite ones is math, such as, supporting CSS where the
added support that's cross-browser standards for trigonometric functions.

DG: It is good when everyone can see that there is an easy path to solve it.

DG: Some trick functions were missing, and some were not exactly accurate,
so they just made sure everything is consistent and fully implemented for
trigonometric functions in CSS.

NS: Do you have any suggestions for something that is small?

DG: So, I really like the CSS aspect also because it's their core focus and
if we could pick one CSS feature that would be kind of exciting for us and
exciting for them and it's small.

DG: I have been thinking about widths and heights. In particular mean and
max within heights. I know that however, the implementer Fred would have a
whole paragraph of caveats here.

DG: So, we should have the implementers' support before we suggest
something.

*ACTION* NS Said "I can look at the polyfills that I wrote and see which
CSS properties They depended on because there are some that depended on the
CSS property to work and of course they don't work outside of the Chrome
browser. Focus on one or two things that would make some things work across
browsers.

DG: I could probably find an archive article that exhibits any of the
issues that we find with CSS by just opening the article.

NS: I believe the interop group is not starting to meet until November.
Last year, I believed that they did not make decisions until February.

BM: Originally Firefox was the only player.

BM: Then Chrome caught up and we worked on keeping both browsers working.

BM Safari was surprisingly close.

*ACTION* DC: showed an issue where Firefox was having spacing errors. He
showed a spacing error where a plus sign was too tall. NS asked: Do you
think you can isolate this down to something you could describe, and then
we could think about, whether this is what we want to push as a group?

NS: wants to have action items where committee members demonstrate problems
caused by small things that could be solved.

*ACTION* NS will look at his polyfills and see if some small set of things
is blocking them.

*ACTION* DC: You have an action item to identify one or 2 things in this
document that are problematic.

NS: We are looking for bugs or implementation gaps like a lack of CSS
support. We are also looking for bad implementations. A lack of CSS support
is an implementation gap.

NS: If we have a problem, find out what is behind the error.

NS: The point of interop is to get everything working the same.

*ACTION* BM should look at the DLMF and look for problems which he will
present next week.

BM Also should include a browser bug. So what David was showing is a
Firefox bug and BM might find a Safari bug.

NS: We want everything to be the same.

*ACTION* PL should look for web clipboard bugs. He should be able to copy
from browsers to Microsoft word.

NS: Anyone can submit anything. If we submit something, and others give it
a thumbs-up, that will help our case to get the project accepted. It helps
us to get support from outside of our group.

DG: 2 important limiting factors for finding these issues. One, it must be
a settled specified issue. So, MathML core must have clearly set out on
this. It must not be an operation in the tracker because 2 of the biggest
pain points I have still have open issues in MathML core, and so they are
not eligible for interop. For interop, you must have it settled in the
spec. And the second It's not necessarily a limitation, but it really
proves the chances of it being accepted is if there's an associated browser
test already there. It's one of the preexisting failing tests.

DG: Problems must have tests to demonstrate the issue.

NS: If we find a problem, we should add a test.

NS: We will come back next week for the action items.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.1#cp-md-0-3-a-href-https-github-com-w3c-mathml-labels-mathml-next-mathml-next-issue-cleanup-a->3.
MathML next issue cleanup <https://github.com/w3c/mathml/labels/MathML-Next>

*ACTION* DG: Some of our issues with the next label has MathML 4 label in
them. rename the label to next or five so that they are not to be
considered for spec version 4.

DC: We should just make the change.

DG: We need to decide what to do with content MathML.

DG: It is easier to close issues and reopen them in MathML 5 if needed.

MOS: He agrees that things should be closed. issue 47 (What to do with
MathML). see if there is a future for content MathML. In our version 5
discussions, we should consider how to align our new ideas about intent
with content MathML.

NS: We do have users of content MathML in the group. SD uses content MathML.

NS: DLMF generates content MathML.

DC: Can not decide on the content future. He uses it. open math has more
users than people think. There are some requirements to support things we
supported in previous years. Content MathML will continue to be supported.

NS: content MathML is not going away.

DC: We are waiting for the description of intent to be stable. Once it is,
we can discuss matching content MathML with Intent. Intent has moved
further from content MathML.

DC: Believes that issue 47 should be closed. Issue 47 would start a
discussion that we are not going to have in this MathML iteration.

*Consensus* close issue 47.

*ACTION* DG will do the cleanup of 4 to 5 in the issue labels, and close
issue 47.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.1#cp-md-0-4-a-href-https-w3c-github-io-mathml-docs-intent-core-properties-mathml-intent-core-properties-a->4.
MathML intent core properties
<https://w3c.github.io/mathml-docs/intent-core-properties/>

NS: has cleaned up some typos, and David has fixed up the display.

NS: I added 2 things. I added Roman numerals and omissions as properties. I
want to see if people think this is reasonable and if they want to The same
names.

NS: is not sure how Roman numerals should be spoken.

NS: I think you just say the letters. What I'm completely unclear of and
this turned out to be a real nuisance to implement, is that at least in
this banish Portuguese Braille code, they have a special notation for Roman
numerals, so that if you have a line over it, the Roman numerals are
multiplied by 1000. NS does not know how you say this.

NS: Something that distinct makes it into a property.

No one disagreed with making it a property.

DG: Yeah, complications. So, we have Arabic numerals with all kinds of
Unicode characters available for the digits, would we have a property that
indicates this is a regular Arabic numeral if you have stylized Unicode
characters in there?

NS: Is there ambiguity here? No ambiguity, no properties.

DG: The number one in a specific font can be an indicator function or a
real number one.

DG: Do we need a property for weird Arabic numerals?

DG: If you use the number one as an indicator function, you need intent.

DC: said: Just use the correct Unicode.

DC: There is a block of Unicode numbers, people should use them.

NS: must figure out if something is a roman numeral.

NS: We had a discussion about how should you speak an empty space.
Originally Neil used the word omission from Braille which used the word
"omission" when they came to a "fill in the blank".

Examples of this character are underscores and empty boxes.

PL: But Wouldn't you use something like an input element in HTML to perform
the interactive part of the thing?

MoS: worried that discussion like this would make the core list hundreds of
times bigger than it currently is.

MoS: We have made intent more complicated than it originally was. This
might have made intent too complicated for general use.

NS: We have about fifteen things as core intent properties.

NS: The open list is whatever someone wants it to be.

DG: Yeah, on the specific question of omission, just wanted to remark that
to me, it looks like this could be an intent value or concept. It doesn't
need to be property. And I would prefer the word blank.

DG: Do not worry about a project having an end. The project ends when
people do not want to work on it.

DG: I'm worried about ending with something that's not good enough. I don't
want to add anything spurious that nobody uses.

DG: So, at some point, 200 entries or so, we're done with core.

DG: I did want to add 1 point of agreement with Moritz, which is that I
agree we should not overdo the properties because every property implies an
algorithm that must be implemented.

NS: Omission will be called blank and moved over to the core concepts.

DC: We then discussed how you should say 1.50 pounds. Should it be 1.50
pounds or a pound 50.

NS (added afterward): Notice that word order changes. For example "$2" is
"two dollars" -- the prefix "$" is a postfix word. Hence, adding "intent"
on "$" itself isn't really helpful.