Minutes: MathML full meeting, 13 March, 2025

 Attendees:

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

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

NS's paper was voted best paper at the 2025 CSUN conference.

Next week, on Thursday March 20, our intent meeting will continue to begin
one hour earlier in Europe due to the U.S. time change.

PL dropped his idea for a breakout talk
<https://github.com/w3c/breakouts-day-2025/>. NS encouraged others to
listen to this conference.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-0-2-a-href-https-github-com-w3c-mathml-issues-525-525-equation-numbers-a->2.
#525: Equation Numbers <https://github.com/w3c/mathml/issues/525>

*CONSENSUS* Move :pause-xxx to the core property list. Put :equation-label
and :no-equation-label on the core property list, and remove the open
property list. Close issue 525.

*ACTION* DC will do a PR to change the name of the core property list to
the property list.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-1-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

NS's paper was voted best paper at the 2025 CSUN conference.

Next week, on Thursday March 20, our intent meeting will continue to begin
one hour earlier in Europe due to the U.S. time change.

PL dropped his idea for a breakout talk
<https://github.com/w3c/breakouts-day-2025/>. NS encouraged others to
listen to this conference.

DG and MoS have started working on their idea of making a web interface for
contributing concepts to Intent Open. DG said that: "It was interesting
that we have already encountered the old questions of aliasing and concept
overlaps and many-to-many relationships and uh Yeah, we'll probably have an
update a couple of weeks from today.". The YAML file must be kept valid
because some Automated processes want to use it.

PL: I had a student who delivered a bit of work on evaluating the
performance of math rendering. He believed that the server-side rendering
of MathJax would be the fastest, but no, it turned out MathML was twice as
fast.

DG: I think there's a second catch actually in that server-side rendering
of MathJax, I believe you lose their accessibility suites on the front end.
So it will not be accessible if it's server-side rendered.

PL: That is correct.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-1-2-a-href-https-github-com-w3c-mathml-issues-525-525-equation-numbers-a->2.
#525: Equation Numbers <https://github.com/w3c/mathml/issues/525>

DC wrote: Equation numbers in MathML have always been a bit problematic as
they typically relate to a global counter and are typically typeset at page
margin, both of which are document level constructs that are hard for the
MathML specification to constrain. mlabeleddtr is dropped from core and
dropped from MathML4 apart from legacy support. When auto converting to
mathml while typesetting the mathematics, latex now has some experimental
support for equation labels. We give up on aligning at the page boundary
(perhaps external css can be applied later) and for all alignments such as
amsmath package align the generated MathML is an with an extra dedicated
first column which contains the equation labels. The question is, how
should AT know that this is a label and not part of the equation? Currently
we are experimenting with adding an intent so (1) 1 =1 Is this reasonable,
and if it's not reasonable what should the markup be instead?

NS: The basic issue is that mlabeleddtr is gone. we need to suggest an
alternative. DC proposes the :equation-label property.

NS: David proposed a property called :equation-label so that AT knows that
a particular entry in a table is meant to be a label and not part of the
contents of that table. I implemented that in MathCAT as long as the
equation label was the first entry in a row.

DG: The perspective I had is mlabeleddtr was deprecated for a reason and
that is implementer agnostic attitudes in a way And… What we want to do
depends on several factors. One is core versus open. Another is ecosystem
host environment from MathML. So I've mentioned before JATS
<https://en.wikipedia.org/wiki/Journal_Article_Tag_Suite> has equation
labels on the outside.

DG: One positive outcome I had with discussing with David at length was we
kind of both agree the open properties list is more problematic than useful
in discussing this.

DG: A lot of the process questions I had pretty much had to do with what's
open and what's core. And in the end, is it really useful for the
properties and maybe it isn't. So my kind of easier answer out of this is
to say, let's just drop the open list. There's one properties list and it
is what it is. And everybody does it the way the working group specifies it.

DC: We need a list that should be implemented and that does something.

NS: things on the core property list should, not shall, be implemented.

DG: You can add whatever you need in the open list to the core list.

NS: There is a use for the open list for experimentation.

DC needs to generate something that makes aligned equations. He needs this
now.

dc: Having one list will help us get things to the end user.

BM: Concepts are what to say, and properties are how to say them.

BM: Equation-label is a critical property to include.

NS: In the PR, there is no restriction on which cell has the equation
label, and this makes it difficult to implement.

NS: So does this make sense to limit the position of the equation label?

BM: No, absolutely. I'm against that. You don't know where the label is
going to go.

NS: I can read the label before I read the equation no matter where the
label is located in the row.

DC: This does not support having two labels in a row.

MuS: I like to have elements stored in the speaking order. MathML does not
do that with mroot.

MuS: Usually people put the equation labels on the right-hand side.

DG: I can supply you with many examples of the equation labels being on the
left-hand side.

NS: It is easier to understand the equation if you first read the label
then the equation no matter where the label is.

DG likes equation-label but thinks no-equation-label is unnecessary. He
believes that silent or padding would work better.

NS: So you say that because no-equation-label would typically be on an
empty cell, where you wouldn't say anything anyway.

DC: The reason no-equation-label is there is because it controls the
alignment. You have in an aligned equations pairs of right-left alignments.

DC: :silent is not as good as an extra cell because it would not take part
in the alignment.

NS: The AT needs to get an accurate column count on things like
determinants, and no-equation-label would help the AT do this.

DC: The empty label columns are real things.

DG: If we get rid of the open properties list we can add things to the core
property list.

dc: Move pause to the core list.

*CONSENSUS* Move :pause-xxx to the core property list. Put :equation-label
and :no-equation-label on the core property list, and remove the open
property list. Close issue 525.

*ACTION* DC will do a PR to change the name of the core property list to
the property list.

PL: Once we eliminate the open property list, we will need a place to store
experimental properties while they are being developed.

DG: If you do that, they'll have to start asking which ones go there. So
please don't do that first.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-3#cp-md-0-3-a-href-https-github-com-w3c-mathml-issues-528-528-remove-continued-row-from-core-properties-a->3.
#528: Remove :continued-row from Core properties
<https://github.com/w3c/mathml/issues/528>

BM We want to connect the math to the labels. We end up with subblocks.
Start with one equation per row. Next you can have an equation extending
over the next row, and perhaps the row below that. In this case, each row
contains parts of only one equation.

Next you can have a case where a row can have parts of several equations.
The remainder of each equation is contained on the part of the row below
the original row.

:continued-row cannot describe this structure.

Instead of putting :continued-row on the beginning of your next row, you put
:continue-on-next-row on the end of each of your equations.

BM: The portion of the equation targeted on the next row will start in the
cell below where the continued equation started.

NS: We do not want two ways to do the same thing because the AT would have
to decide which method to read. Also the author may use both of the methods
on the same line.