Minutes: MathML Full meeting 19 Dec, 2024

 Apologies for the late minutes. I thought I had sent them out a few days
after the meeting...
Attendees:

   - Neil Soiffer
   - Louis Maher
   - Bruce Miller
   - Deyan Ginev
   - Paul Libbrecht
   - Murray Sargent
   - David Carlisle
   - Stella Vouthsina

<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-regrets>
Regrets
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-action-items>Action
Items
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

This is our last meeting of the year. The next meeting will be on 9 January
2024.

DC wrote: PDF latex tagging
https://latex3.github.io/tagging-project/documentation/prototype-usage-instructions

You can get fully tagged PDF with MathML out of that.

*ACTION:* DC will open an issue on pdf tagging inside of MathML leaf tags.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-2-a-href-https-github-com-w3c-mathml-issues-181-181-mathml-4-extensions-for-alignment-and-possible-deprecation-of-maligngroup-and-malignmark-a->2.
#181: MathML 4 extensions for alignment and possible deprecation of
(maligngroup/) and (malignmark/) <https://github.com/w3c/mathml/issues/181>

*ACTION* DC make a pull request on this issue for maligngroup and
malignmarks in chapter 3 of the full spec to add MuS's comments, and
simplify the rest of the section.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-3-a-href-https-github-com-w3c-mathml-issues-433-433-comment-include-or-not-a-sample-set-of-default-conversion-from-plain-mathml-to-mathml-with-intent-a->3.
#433 (comment) include (or not) a sample-set of default conversion from
plain-MathML to MathML-with-intent
<https://github.com/w3c/mathml/issues/433>

(this is a shortened version of this doc
<https://github.com/w3c/mathml-docs/blob/main/minimal-intent-core.md>)

*ACTION:* NS: In MathCAT, NS should say root with an index and not square
root.

*ACTION:* NS: For the core list, NS should add to the literal or property,
a list of suggested things to say for each of the tags.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-4-a-href-https-github-com-w3c-mathml-issues-482-482-intent-for-large-operators-a->4.
#482: Intent for large operators <https://github.com/w3c/mathml/issues/482>

*ACTION:* NS will record that we discussed alternative names, and we did
not come up with a new term. NS will say why largeop is not optimal.

NS: We will leave issue 482 open.

*ACTION:* NS: Feel free to work on the spec or add polyfills over the
holidays.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

This is our last meeting of the year. The next meeting will be on 9 January
2024.

NS transferred several issues from "full" to "core".

NS: We have 32 open issues, 12 of them are for MathML 5, which leaves 20
issues. Of those 20 issues, 10 need a spec update, which means we have
settled the questions in those issues, now the issues just need some work.
Five of the ten left need polyfills, and there was one overlap. The
remaining four issues are on the agenda today.

DC wrote: PDF latex tagging
https://latex3.github.io/tagging-project/documentation/prototype-usage-instructions

You can get fully tagged PDF with MathML out of that.

*ACTION:* DC will open an issue on pdf tagging inside of MathML leaf tags.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-2-a-href-https-github-com-w3c-mathml-issues-181-181-mathml-4-extensions-for-alignment-and-possible-deprecation-of-maligngroup-and-malignmark-a->2.
#181: MathML 4 extensions for alignment and possible deprecation of
(maligngroup/) and (malignmark/) <https://github.com/w3c/mathml/issues/181>

(updates?)

MuS: LaTeX (see Sec. 3.6 of
https://mirrors.rit.edu/CTAN/macros/latex/required/amsmath/amsldoc.pdf)
uses &’s to align an array of equations with expressions appearing in
columns aligned alternately right and left. Such alignments can be
represented by an < mtable> with each < mtr> containing a single < mtd>
starting with an < maligngroup/> to align the first expression to the right
followed by an < malignmark/> to align the next expression to the left.
Each < mtd> contains one or more of these alternating sequences. The
alignments can also be represented by < mtr>’s with multiple < mtd>’s that
have style attributes alternating between text-align:right and
text-align:left. Microsoft Word represents such equation-array alignments
using < maligngroup/> and < malignmark/>. Inasmuch as Word is in widespread
use, this simplified role of the < maligngroup/> and < malignmark/>
elements needs to be preserved.

MuS: The parent of < maligngroup/> and < malignmark/> can only be 1) an <
mtd> or 2) an < mrow> whose parent is an < mtd>. No attributes are defined.

PL: Has there been any discussion about copy and paste?

DC: Yes.

MuS can simplify the maligngroup and malignmark section.

NS If you have maligngroups and malignmarks, can they be imported into word?

MuS: Yes.

DG: So, the question I have is about Microsoft Word's plans for this
feature. Is this to be seen as a legacy feature that is kept, and maybe
should be deprecated with an eye towards doing something new that is
different, or is this a commitment of words to keep this future as a core
priority of mathematics so we just keep it as it always has been.

MuS: While I do not really know the Microsoft current point of view, my
feeling is that it's very unlikely that word's going to change anything
here.

*ACTION* DC make a pull request on this issue for maligngroup and
malignmarks in chapter 3 of the full spec to add MuS's comments, and
simplify the rest of the section.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-3-a-href-https-github-com-w3c-mathml-issues-433-433-comment-include-or-not-a-sample-set-of-default-conversion-from-plain-mathml-to-mathml-with-intent-a->3.
#433 (comment) include (or not) a sample-set of default conversion from
plain-MathML to MathML-with-intent
<https://github.com/w3c/mathml/issues/433>

(this is a shortened version of this doc
<https://github.com/w3c/mathml-docs/blob/main/minimal-intent-core.md>)

NS: In this literal mode of interpreting speech, do we give suggestions of
what the expression is, or do we suggest how things should be spoken.

NS: People need to know that they can override the defaults.

NS: the defaults are minimal.

DG: I have encountered some bad results from OCR where the OCR could not
tell a super script from a subscript. This does not happen with primes, but
does happen with expressions characters involving dots like x dot.
Sometimes equations end with a dot that is just punctuation and not part of
the math.

From Deyan Ginev to everyone: but do you say accent if (mover
accent="false")?

In MathCAT, NS tries to handle the punctuation at the ends of equations by
removing them.

DG: This kind of treatment would be fine for the literal property where the
AT goes and creates some smart upgrades so that the literal thing works. I
just don't know if it should be standardized in the main text or should be
a note on the side.

NS: This is tough to decide. And there's also the questions which we didn't
resolve of 'how do you say some of these other things like square roots'.
You do not want to say square roots because this has a semantic meaning as
does the word "fraction" when you are trying to describe something over
something else. A square root involves the radical sign which can have a
non-mathematical meaning.

NS: Well, so maybe the thing is we should say root and root with index and
not square root. We should not say radical.

*ACTION:* NS: In MathCAT, NS should say root with an index and not square
root or radical.

*ACTION:* NS: For the core list, NS should add to the literal or property,
a list of suggested things to say for each of the tags.

DG: We should also show potential problems and perhaps give examples of the
problems.

NS: We are saying something about the implementation, but we are not
enforcing the implementation. We are making suggestions and giving warnings
about what to do.

NS: At a later meeting, we can discuss these suggestions and warnings.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-4-a-href-https-github-com-w3c-mathml-issues-482-482-intent-for-large-operators-a->4.
#482: Intent for large operators <https://github.com/w3c/mathml/issues/482>

NS: The issue here is that we have had intents for integrals and sums and
all the other large ops, and then I realized, why not just say it's the
property of a large op? Why do we have to write intents out for them? Just
mark them as large ops and they'll all speak perfectly fine.

DC: For summation examples, index is certainly a better name than largeop,
but we also use largeop for integrals where you have integral over "C"
where it's explicitly not indexed. It is integrated over a continuous
domain.

DC: An index really means some kind of accountable index thing.

*ACTION:* NS will record that we discussed alternative names, and we did
not come up with a new term. NS will say why largeop is not optimal.

In issue #482, NS wrote: "This was discussed at the meeting on 19-12-2024.
The group's feeling is to leave the name as :largeop but see if anyone
comes up with a better name. There are two problems with :largeop:

   - mo has a largeop attribute, so there is potential confusion because
   these are similar but not identical;
   - As noted in Deyan's comment
   <https://github.com/w3c/mathml/issues/482#issuecomment-2537307558>,
   this can apply to notations that are not large operators, so the name is
   misleading in these cases.

NS: We will leave issue 482 open.

*ACTION:* NS: Feel free to work on the spec or add polyfills over the
holidays.