Minutes: MathML Full meeting 3 Oct, 2022

 Attendees:

   - Bruce Miller
   - David Carlisle
   - David Farmer
   - Dennis Mueller
   - Deyan Ginev
   - Louis Maher
   - Murray Sargent
   - Neil Soiffer
   - Paul Libbrecht
   - Sam Dooley

<https://sandbox.cryptpad.info/code/inner.html?ver=5.1.0-04#cp-md-0-regrets>
Regrets

   - Steve Noble
   - Stephen Watt

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

Dennis Mueller is a new member to the MathML Intent WG group. The group
introduced ourselves to him, and Dennis introduced himself to the group.

DG: performed the following action item from the September 29, 2022,
meeting. "DG: wants to try examples produced by MathJax. He will then add
intent and "isa" code to the expressions to make them clearer from an
accessibility point of view, without changing the appearance of the MathJax
MathML output." (see issue #426)

NS: needs to complete the horizontal review initiation items.

DC: did the last PR merge for core for the CR draft.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.1.0-04#cp-md-0-2-39-intent-39-name-list-registry-spreadsheet->2.
'intent' name list/registry/spreadsheet/...

Current list of intent values:
https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit?usp=sharing

MUS: (aside) If we want to create intent accurately, also consider input
via dictation.

NS: DG seeded a google spreadsheet with intent values which has a core and
an open set.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.1.0-04#cp-md-0-1-who-author-developer-end-user-will-make-use-of-the-list->1.
Who (author, developer, end user, ???) will make use of the list?

NS: Authors, developers, and users may make use of the intent list. Is that
the case and who else?

DG: The core list was the original goal, as we want to have common ground
between AT implementations, so that AT users can have guarantees for
narration quality.

DG: All AT should have support for the "Intent Core" values to be compliant
with MathML Intent.

DG: The "Intent Open" list is instead a stretch goal for implementers and
may be more useful as a collection of examples for remediators.

NS: (A remediator is someone tasked to turn an inaccessible document into
an accessible document.)

PL: We need to modify this table to make it more usable.

NS: Accessible document creators will look through this table and see what
they need to implement.

NS: Are some entries "self-voicing" and needing a separate list? E.g.
"factorial"

DG: Usually nothing is self-voicing if you consider localizing in enough
foreign languages. E.g. "3!" is "tre fakultet" in Swedish.

DG: Swedish factorial: https://sv.wikipedia.org/wiki/Fakultet_(matematik)

DG: I learned Swedish in realtime on the call by skimming wikidata:
https://www.wikidata.org/wiki/Q120976

PL: (fakultät just as in German)

NS: By self-voicing, I mean self-voicing after translation.

NS: Maybe the "self-voicing" distinction does not need to be in the list.

PL: How do you differentiate the various ways to speak fractions? How do
you search the table for this information? Different languages might use
different words to describe the same thing.

NS: Some localizations change constituent order - compare the same fraction
spoken "A over B" with "B under A"

BM: Some people want a short list of intent values to make a list easier to
implement. Some people want a longer list to include all possibilities.

DC: Would like the table to tell him what MathML should be generated from
TeX input.

NS: needs to infer the intent from the math. Intent should tell him how to
speak operators such as "plus".

NS: wants to find things in the table based upon a name where DC might look
up a character to see the MathML that should be created.

DC: wants to know what MathML to generate for a specific symbol.

SD: We have two classes of customers for the table: producers and
consumers. Producers want to know how to produce MathML while the consumer
wants to know how to speak MathML.

DG: The table can and should be improved, but we need to escape Google
Sheets. It is quite ugly to embed well-formed XML snippets in a regular
spreadsheet. The current "known notation" column is a freeform shorthand
and not valid MathML.

Ns: We need to decide what we want in the table, then we can discuss how to
write it.

BM: Ideally Chapter 3 of the spec should tell us how to generate MathML,
but it may be hard to find at times.

MUS: The values from this table could be used for enabling math dictation
into MathML+Intent.

PL: We have not discussed standardizing things yet.

NS: We are discussing the Intent Core list; it is meant to be standard
where everyone uses the same intent value for the notations in it ("power",
"plus", ...)

DF: Authors know what they mean. For example, the author knows when he
wants a times sign and when he wants a cross sign. The characters can look
the same. How can you tell if something is cross or times? This table does
not tell you this.

NS: The alias column might handle this.

DG: "cross" looks like a shorter alias for "cross-product", but is a
different intent entry from "times".

DC: This table does not tell you what to do. DC: I can't really put intent
on the "mo", so a known notation "mo +" and form "infix" does not help if I
want to annotate an "mrow".

BM: The developer of a macro must use the correct intent. I can use
whichever name is decided on as official, for cases where we have certainty
of which symbol was used. So if latexml can parse a sum, I can add the
"plus" intent, etc.

DG: There is a need for converting TeX into MathML shared by DC, DM, DF,
BM+DG. Maybe we need a new intent.sty package to provide a template for how
to author intent in TeX? And even consider providing pairs of (TeX input,
MathML+Intent output) either in the table or as a note.

DC: A new package is fine, but the concrete TeX input is not my problem.
The instructions I am missing for generating MathML should be more abstract.

DM: I think I need a specification explaining the general approach and the
different cases, with maybe a couple of examples.

NS: Maybe we should have several categories and tell the reader what
category each table entry is in?

MUS: In times vs cross, can figure out which via context, in general

NS: We can continue this discussion next week.