Minutes: MathML Full Meeting, 21November, 2024

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Murray Sargent
   - Bert Bos
   - Moritz Schubotz
   - Paul Libbrecht
   - Bruce Miller
   - Patrick Ion

<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0-regrets>
Regrets
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0-action-items>Action
Items

*ACTION* DC has asked LM to look at some mathematics-bearing pdf files to
see if they are accessible for the blind. LM agreed. DC will prepare these
files and a modified version of NVDA to read them.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0-bert-39-s-quot-old-docs-quot-question->Bert's
"old docs" question:
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0-1-a-href-https-www-w3-org-tr-mathml-types-structured-types-in-mathml-2-0-a->1
Structured Types in MathML 2.0 <https://www.w3.org/TR/mathml-types/>
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0-2-a-href-https-www-w3-org-tr-mathml-bvar-bound-variables-in-mathml-a->2
Bound Variables in MathML <https://www.w3.org/TR/mathml-bvar/>

An editor for these two documents is Michael Kohlhase.

*CONSENSUS* DC will contact Michael Kohlhase. Unless Michael Kohlhase
objects, these two documents will be removed.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0--482->
#482:

Intent for large operators <https://github.com/w3c/mathml/issues/482>
(status?)

*CONSENSUS and ACTION* We will accept the :largeop property defined as a
core property, and DC will clean up the large Ops and concepts related to
them.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0-3-taking-stock-of-where-we-are-at->3.
Taking stock of where we are at:

*ACTION* NS: asked MuS to add an issue on math editing.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

Note: Next week (11/28/2024) is Thanksgiving in the US, so there is no
meeting next week.

*ACTION* DC has asked LM to look at some mathematics-bearing pdf files to
see if they are accessible for the blind. LM agreed. DC will prepare these
files and a modified version of NVDA to read them.

NS for DC and BB: If you saw a pound sign 1.23, how would you say that? NS
is working on MathCAT on translating currency units.

-DC: One pound, 23.

NS: Bert, if you saw that with a euro sign, what would you say?

BB: I think the same, one euro 23.

NS: In the US, we would say one dollar and 23 cents.

BB: No, I would never say the word "cents", and I would never say "the word
and".

DC: In tables, people might write 23 p.

NS for BB: So, if it weren't a full euro, what would you say?

BB: I would say the cents in that case.

   - doc updates/completed action items

DC worked on "WG meeting 2024-11-14 agreed to change full to match core,
noting that css length allows calc syntax for issue 103-- Extend mpadded
attribute syntax to be closer to MathML3
<https://github.com/w3c/mathml/issues/103>.

DG reported on a discussion with aria-description. If information is
provided for the blind, then it should be provided for the sighted user as
well, perhaps with a tooltip.

NS to LM: Do screen readers provide a tone when a tooltip is present?

LM: No. I do not thing I have ever encountered a successful implementation
of an accessible tooltip for the blind.

NS: Perhaps you can use some JavaScript to turn an aria-description into a
tooltip.

DG: There is some parity with the web in that you can use intent to match
aria-provided information.

MuS: I'm wondering how rigorously schemas are applied because I'd like to
add a couple of attributes for WYSIWYG editing that are helpful for me,
like when you're browsing over a table, or rather a matrix. He wanted to
get information on the position of the cell he was browsing.

NS: You're doing this with JavaScript for the speech, right? So, you could
just do a count of the number of proceeding cells.

MuS: I could derive it, but it takes too long.

NS: Since this is for your own private data, it does not go into the spec.

MuS: When I do a control C to copy the MathML, I could just delete any
internal attributes.

NS: You should delete the internal attributes because this is private
information.

PL: I am worried when I hear you say you may be including some things to
help the internal working of word in the copying process because often when
you copy from a word file to an online document, you get garbage. I think
you should be very strict and make sure that things specific to word do not
leak out in the copying process.

MuS: I will cleanse the control c so that private stuff does not leak out.

MuS: The row and column count are useful for accessibility in general, but
I don't think we want to start adding them to the control c process.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-1-bert-39-s-quot-old-docs-quot-question->Bert's
"old docs" question:
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-1-1-a-href-https-www-w3-org-tr-mathml-types-structured-types-in-mathml-2-0-a->1
Structured Types in MathML 2.0 <https://www.w3.org/TR/mathml-types/>
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-1-2-a-href-https-www-w3-org-tr-mathml-bvar-bound-variables-in-mathml-a->2
Bound Variables in MathML <https://www.w3.org/TR/mathml-bvar/>

An editor for these two documents is Michael Kohlhase.

*CONSENSUS* DC will contact Michael Kohlhase. Unless Michael Kohlhase
objects, these two documents will be removed.

BB: In place of these notes will be a statement saying that these notes are
no longer relevant. A link to the old notes will be left as part of the "no
longer relevant" note.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0-2-mathml-4-issues->2.
MathML 4 issues:
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0--482-a-href-https-github-com-w3c-mathml-issues-482-intent-for-large-operators-a->#482:
Intent for large operators <https://github.com/w3c/mathml/issues/482>

(status?)

NS: The proposal is that we have the :largeop property defined in core, and
then we do not have to list each of the large operators as individual core
concepts. We do not have to individually list each of the large operator
speech patterns.

NS: So yeah, I want to get a sense of the meeting. Is this problem solved,
or has this problem begun?

DC: largeop is already in the list of core properties.

DG: Large operators are tricky because sometimes they have an index
variable, and sometimes they do not. They can vary with various kinds of
ranges and specifications.

DG then listed some of the many ways indices and ranges and other modifiers
are specified.

From Patrick D F Ion to everyone: $ \sum_{(j,k) \in [0\dots
n]_{\integers}^2} I$

From Patrick D F Ion to everyone: Should be $ \sum_{(j,k) \in [0\dots
n]_{\integers}^2} } $

PL: There will always be new patterns. You have seen 10 patterns today. I'm
sure you will find more at axXiv. You will find lots more that are super
hard to interpret. So, this is why we have intents so that people can
express themselves in special funky ways in case they need it.

DG: Sometimes you integrate around differently shaped paths.

NS: This means we can drop a few things from the core concepts.

NS: In these descriptions, you can have different multi-dimensional domains
with different ranges.

MuS: I'm intrigued with the idea of the largeop Property, but I'm wondering
if it's redundant, because of two different possibilities: one is that the
large Ops are pretty well defined in Unicode as large Ops already, and the
other thought is that on the mrow, It contains the whole thing.

From Patrick D F Ion to everyone: ‘Integral over a region’ or ‘a curve’

From Patrick D F Ion to everyone: Also $\forall_{some proposition} … $

*CONSENSUS and ACTION* We will accept the :largeop property defined as a
core property, and DC will clean up the large Ops and concepts related to
them.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-1-3-taking-stock-of-where-we-are-at->3.
Taking stock of where we are at:

   - 42 Open issues (~5 are assigned to people to close after a little work)
   - 12 have "MathML next" label
   - 10 have the "intent" label
   - 7 have "need specification update" label
   - 6 have "need polyfill" label
   - 6 have "need tests" label

Note that many issues have more than one label. Removing the "MathML next"
and already assigned issues, that leaves ~25 open issues.

We only have a few more meetings left this year. I'd like to prioritize any
larger unresolved MathML 4 issues. Please think about what you feel are the
critical issues (either github issues or unfiled ones). We'll go "around
the table" to get everyone's input.

NS: When I was going through the issue list, I noticed that some just
needed specification updates. We do not have to discuss these, we just need
to do it. this is also true for issues that need polyfills and tests.

NS moved some of the issues over to core.

NS wants to get peoples' thoughts about what we need to do independent of
issues. What bigger things do we need to do with the spec before it becomes
a candidate recommendation?

DG: So, the way I see it, the less we do the better. We should just clean
up what we have right now and finalize it, and I think it's good for people
to read.

MuS is concerned about making editing possible for math expressions. He
wants to give a demo showing what he means by this. Without using vision,
You should be able to use your right and left arrows to navigate around,
and know where you are. So, if you're at the end of a numerator, it says,
end of numerator, etc. He believes that office applications are the only
applications that make this possible.

*ACTION* NS: asked MuS to add an issue on editing.

LM: No suggestions.

DC: We have to read the entire spec before we go to CR.

DC: In previous years, I'd have read the whole spec before we went to Cr. I
think we need to acknowledge that we cannot do everything. We need to have
a spec.

NS: We need to revisit our concept and property lists.

PL: We need more implementation experience. We need to be confident how the
process of enriching fine-grained intense is going to be happening so that
we become publisher quality.

MoS: Wants to consider the process of converting TeX to MathML.
Mathematical type setting is TeX He wants to consider this conversion
process without considering one specific conversion package. He wants a
general overview.

MoS wants a document explaining how one thing relates to another.

MoS: This could be in a separate document and not the spec. This would be a
best practices document.

DC: This is a fork of the latex project website with working examples
including automatic TeX to MathML examples: "
https://davidcarlisle.github.io/tagging-project/documentation/prototype-usage-instructions
".

DG: would like to have a community group to discuss: 1) standardizing the
TeX inputs for the web, and 2) how to map it to MathML. You cannot do this
fast.

NS: This could be done in parallel with releasing MathML 4.

DG: What you could do fast is to document what someone else has implemented.

BM: We are close to where we need to be for CR. There are some dangling
issues like the idea that the first time you pronounce something, you use
its full name, while the rest of the time you pronounce it, you give it a
terse vocalization.

BM: We do not want to get bogged down in endless details, or produce a spec
that is so complicated that no one will implement it. We need to get
something out there so we can gain experience in seeing how it is
implemented.

PI thinks that MoS' suggesting about documenting how TeX and be converted
into MathML is a good idea; however, it could be an add-on and not part of
the spec.

PI: The next spec version must be implementable.

NS: Implementations must have dependability. You must know what the AT is
going to produce. Do you need an intent for everything, or can you depend
upon some defaults?

NS: Consider include (or not) a sample-set of default conversion from
plain-MathML to MathML-with-intent - Issue #433
<https://github.com/w3c/mathml/issues/433>.

NS proposed an attribute intent-default with the following values: legacy
-- AT is free to apply any heuristics they want, structure (later called
literal) -- speak the structure, and common -- speak the common
interpretation in lower-level math. You get the common default if you do
not specify an intent.

Note: in all cases, if intent is given, it should be used (if appropriate).
Even for legacy, it is possible remediation may have added an intent value.

From Deyan Ginev to everyone: We can try, but only :literal is easy.

DC: We could have these defaults in a separate document.

NS: We would have to complete discussing issue 433.

DG: What is doable? So legacy is extremely easy because we can't specify
it. It's basically done what you have been doing, and we don't know what
that is. Literal is the easy one, because it has no context, it is just
getting what's there. Common is the one we haven't finished. And we
discussed 2 years ago. That is exceedingly difficult, because we have
expectations that are bound to certain materials.