Minutes: MathML full meeting on 1 Feb, 2024

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - David Farmer
   - Patrick Ion
   - Deyan Ginev
   - Cary Supalo
   - Murray Sargent
   - Paul Libbrecht
   - Stephen Watt
   - Bert Bos

<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0-introduction>
Introduction

This week we will devote two hours to a topic that has reared its head
several times and one that we still need to resolve conflicts in: concept
names.

There is a tension between concept names wanting to speak in a natural way
(which can lead to idiosyncratic names) and concept names being less ad-hoc
so that they follow some naming convention based on the concept they
represent (encyclopedic name).

This conflict sometimes shows itself in names for the Unicode characters
also. For example, "ellipsis" vs "dot-dot-dot" or maybe even "equals" vs
"equals-sign".

The naming problem is less of an issue for core concepts because AT can
speak to them as they see fit since they can know how the concept might be
spoken, but for open concepts, that ability is not likely present. We
agreed core and open should follow similar if not identical naming rules
because open concepts potentially will migrate into core. Also, some AT may
not implement all of core, so the speech issues for open are potentially
present for core.

One more facet related to naming: fixity properties. We have function
(default), prefix, infix, postfix, and silent. My belief is we need a few
more to allow for more natural speech in some cases, but I don't think
everyone shares that opinion. To throw out what is certainly a wild idea:
we could add a matchfix property that takes everything before the first "_"
or "-" (or both) and speaks it first and speaks the remainder after the
last item (e.g., "open-close" for parens). This potentially extends to a
notation with multiple "-"/"_" and multiple arguments. Of course, literals
can also be used, but that removes freedom from AT.

Apologies for any prejudice I may have shown in the above description of
the problem. We hopefully will have time to thoroughly discuss multiple
ideas related to naming during the call. This is a difficult topic to solve
(IMHO), but I hope we can at least make some significant progress towards a
solution even if we don't reach a final solution.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

NS: reports that BK has started the horizontal review as part of the CR
process.

DG writes: Following active encouragement, the group tried to pitch a small
Interop 2024 issue on MathML+CSS back in October:
https://github.com/web-platform-tests/interop/issues/556

With 65 netizens taking time from their busy days to upvote the issue and
indicate MathML has continued relevance.

And today we were officially ignored:
https://webkit.org/blog/14955/the-web-just-gets-better-with-interop/

NS: DF has done work on intent.

DF: wants to create a new markup language for math called Space Math using
ideas from Python and LaTeX. It's like writing math as a plain text email.

DF has shared a demo with NS.

NS: MuS is doing something similar except he is relying on people to be
able to enter Unicode.

MuS: Well, I made some significant progress. I've written a converter from
MathML back to Unicode Math. Since Unicode math and speech are similar, I
wrote a translator that converts MathML back into speech. I have a pretty
good implementation already. It is nice to have a public JavaScript
implementation that takes MathML and speaks it.

DG: From Deyan Ginev to Everyone: Moritz has a new preprint out documenting
their MathML Intent work in Wikipedia: https://arxiv.org/abs/2401.16786v1
<https://sandbox.cryptpad.info/code/inner.html?ver=5.7.0-rc1#cp-md-0-2-concept-names>2.
Concept names

NS: What is a concept name? Is it the way someone speaks it, or does it
represent the semantic (encyclopedic) name?

DG: Our big challenge is that we have a lot of notation that needs
accessibility treatment. This treatment may require a concept or keyword.
It is hard to select a lot of keywords without a guiding principle.

DG: To keep the spec simple, you need an organizing keyword naming
principle. If the core list has 100-200 items, we do not need an organizing
principle. If you want an open list that might have ten thousand items, you
need an organizing naming principle.

DG: Your principle should also give you guidance on the structure of the
application such as the order of the arguments.

DG: One principle is to use the encyclopedic name that everyone knows.

DG: People want us to keep intents simple.

DG: If we must decide every time about how prepositions are used, it
becomes hard to make the naming decisions.

DG said that BM suggested that the lists are more trouble than they are
worth. BM suggested just having a generic naming principle!

NS: There are 223 concepts already.

DC said he was all right not having a system for naming things.

DC assumed that anything in the open list will be read as is.

NS: We will probably adopt open names. It is not good to have different
ways to think up names for core and open. The names should be speakable and
understandable as spoken.

NS: "By" has the concept name of dimension. This is not how English
speakers would use it.

NS: "By" may work for a cross, but it might not work for an mrow.

DC: If there is a core concept, we can have a speech template.

NS: By being in core, these are the names we should use, and consumers
should expect to hear them. We must have a translation to other languages.

NS: By default, everything is spoken as a function. We have fixity names to
make things sound OK. Maybe we should use fixity in more cases.

PL: What does it mean to solve the issues? We have two solutions. One is to
have a strategy for naming things that can be used in open and core. The
other solution is to do what is convenient in open knowing that open is
open.

PL: We should aim at something that is speakable if it is understandable,
or except encyclopedic names.

NS: In the core list, it should have an encyclopedia name with a note to
say how it should be spoken.

PL: discussed the case of times in French.

SW: One of the things we discussed is that the first time we read a term,
we may use a long name. After the first time, we may use a terser name. Can
the AT be trained to do this?

NS: The core list should have a concept name and a speech hint or template
to give a more detailed reading.

NS: Should it be that the first time the AT reads a term, the AT should
read a long term followed by using a shorter term, or should the author
have to do this?

NS: Should the author control whether the AT reads a long or short
description?

NS: says that the reader generally selects whether he wants the AT to give
a long description or a terse description.

MuS: should you have a hot key asking for a full explanation of a term?

NS: MathCAT has terse and verbose readings upon user request. The AT does
not do this automatically.

DF: Authors would not be able to figure this out. The AT is the only way
for the reader to get what is needed.

MuS The reader will find a couple of good ATs to do this. You cannot get
authors to do this.

PL: Thought that authors could handle speech output. If we had a property,
then it would be useful.

PI: I do not have the experience of what the blind need to hear. Screen
reader authors do have this experience.

NS: Authors cannot know what the audience wants. Move the speech control as
close to the audience as possible.

DG: If we get a core backbone reading capability in MathML4, we can enhance
it in MathML5.

DG: It's easier to ask for a brief readout of something I know than it is
to ask for a long description of something I do not know. If you want to go
in both directions, you will have to provide more meaningful names.

NS: It's easier to look at a long name and come up with a short name than
vice versa.

DC: We do not have any way in the spec of providing two names in the
syntax. There is no fallback except to read the notation literally, like J0
for a Bessel function.

DC: We decided not to require different levels of verbosity.

DC: We cannot redo the basic intent design.

MuS: talked about the digital library of mathematical functions. A lot of
work has been done to provide background information. You can hover your
mouse over something, and you receive more information about that object,
so perhaps part of what we want to do isn't going to be done by intent at
all.

SW: Much of our mathematical notation is written in shorthand so we can
capture as much detail as possible at a glance. It may not be well-suited
for speech. We need to give enough information to be understood. He likes
encyclopedic names if the speech can be made terse.

SW: The way things are laid out usually may guide the speech explanation of
it.

MuS: Trying to force it all on intent may not be good. There are other
attributes like title which might help.

SW: We need an organized scheme to help name things, and we need a method
to shorten the reading when desired.

DG: We must annotate individual formulas. Things fit better as a global
implementation so you do not have to annotate it every time it is used. You
do want to have it spoken hundreds of times. You want a global intent, so
the author does not have to write it every time it is used.

DG: There should be a table that would help everyone speak the same things
identically. This would be an open list that everyone could use.

NS: It would be good to have a column in an open list that would give
computer guidance on how an intent should be spoken.

NS: wants to focus on the naming topic to get a concrete solution to help
name remaining concepts.

DG: He has a different point of view. It is more valuable to have a
systematic method to generate many names than it is to have a series of
names.

If you have names in a systematized system you can build what you need. Our
default position is to just read what is there.

DG: We can gradually implement enough important concepts from the open list
to grow at least to bachelor level, maybe when the early master's level
concepts.

NS: what do you mean by implementing the open list?

DG: It's funny you would ask that because you've done this for core. Do the
exact same thing for concepts that are not in core but are in the open list
that need special treatment.

DG: If you have an interval that is not an open interval, but is something
like an extended conjugated interval of something, you will just change the
function name, but you will still use the form to Construction for the
application. If you're doing it completely symbolically with classical
linguistic methods, you would have a dictionary of little symbolic
constructs that build phrases up with different prepositions in different
connector words.

From Patrick D F Ion to Everyone: Is there a YouTube, or other record of
someone reading out math as a screen reader client? I remain very ignorant
of what the target audience for screen reading might appreciate.

DF: Talk about dimension which is "by". It must be in core. Say m by n
matrix. The intent dimension is not the best name according to DF. If AT
knows about core and the intent that is dimension, then AT will call it by.
Then he could accept dimension.

NS: He will take the MathCAT list and do the best job to read intents. He
cannot say what Apple would do. They may use the very basics (read the
syntax) and just read the words used for intent.

DF: What is the point of making intent if they do not implement it? Why
have a standard if any product doesn't follow the core descriptions?

NS: In MathML history, they added two ideas alt text and alt image to make
it trivial to support MathML. No one bothered to do that.

NS is worried about putting more load on developers.

DC: what does it mean for arXiv to implement a list.

DC: We should not have a common naming system for both core and open. If
it's in core, people should implement it. If it is open, they do what is
reasonable, like using by instead of dimension. If a name changes when it
goes to core, then so be it.

You should not put up with a suboptimal description of matrices because it
might get to core one day.

NS: Then is it a concept or literal?

DC: It is a concept.

DC: The only way to get many systems to read the same is to have a concept
name that is followed.

DC: Believes in making up concept names as you go along. It's still a
concept if it is a function.

DG: Literals are designed to control exact speech. The bigger threat is
that people do not use the spec at all. If I do not like the design of the
spec, then just use another system, and ignore the spec. The spec must be
compelling.

NS: Wants a name that can be spoken well when used with fixity, so you get
a good reading even with an open name.

DC: If arXiv decided to put in ten millions of intents, then they will be
spoken by a default reader. The reader does not implement these names.

DG: The point of openness is so that systems going beyond core have some
place to go.

NS: There are 2 authors. There's the authoring software and there's the
author who's writing the document.

DC: But neither has any control over the reader which is what matters here.

Ns: If we have something that is complicated to implement, people will not
use it. Err on the side of simplicity. It still must provide a good reading
experience.

NS: The names in core are almost irrelevant because you have a dictionary
that looks up the names.

PL: We need a column for the core for a speech template to accompany the
concept name.

NS: By having the speech template, the concept name does not have to be
spoken so we can use the encyclopedic name.

SW: Maybe we do not need a speech template, the name of the argument is
fine. Do something lightweight where something following a colon is
ignored. After the colon is how you prefer it to be spoken.

NS: Magnitude does not have a template because it is simple enough. Other
terms need a template if they are more complicated.

SW: The discussion is if someone does not give a speech template, what do
you do? Give systematic names for the concepts that can be spoken.

DC: These speech templates have no MathML semantics.

If the names are not in core you can suggest speech, if not you cannot do
anything in MathML.

NS: You can force them to speak with literals. This is not using a concept
name.

DC: We cannot change the intent syntax and get it out this year.

NS: You can use a concept name, followed by silent, followed with literals.

From Deyan Ginev to Everyone: Is the suggestion to have literal properties
suggesting speech?

intent="dimension:by"

From Deyan Ginev to Everyone: that seems to abbreviate the existing
solution:

intent="dimension:silent(_by)"

This could bypass the concept name.

PL: What is the implementation problem? We say how we can pronounce the
concept name without a template. If there is a problem, use a speech
template. We do not want to have a template for all cases.

SW: It is not completely implementable.

NS: DG may be happy because we should push towards encyclopedic names in
core because it is a dictionary look up to make better speech.

PL: We want to avoid a speech template and use a name that is expressive
enough.

PL: We want to avoid, if possible, putting a speech template and keep a
name that is pronounceable for some of these things.

NS: There seems to be some agreement that we should be pushing towards
encyclopedic names in the core list to be used because it's just simply a
table lookup to a dictionary.

NS: What is an example?

PL: tangent instead of tan.

DC: Encyclopedic may not be good because two encyclopedias may have
different descriptions for the same name.

DG: wrote a note on this subject (
https://w3c.github.io/mathml-docs/concept-lists/). The idea there was that
he would just read it. Each core list concept is represented by its English
encyclopedic name.

DG: There is a clear line where language starts and STEM starts, and
there's a grey zone where they overlap a little, and there you can choose
the most pleasing, speakable concept names.

*Summary* NS: We will use encyclopedic names that are well known that may
not be good for speech in the core list. There will be a speech template
column which may use different names.

DF: The value of the intent is an encyclopedic name accept when there is a
well-known name like max ... Encyclopedic names backed up by speech
templates.

DC recommends the Open Concept List as a reference source.
https://w3c.github.io/mathml-docs/intent-open-concepts/

NS: You would say that this is a good list to start building a core and an
open list.

DG: Notice that intent is becoming increasingly relying on speech hints.

DG: The speech hints are now crucial in 2 different ways. One is that any
time the encyclopedic name is uncomfortable you must have as hints to
rescue the user experience of that intent value, and the second is the
argument order of intent described applications are pretty much determined
by the way the speech hint is written in the list.

NS: The speech templates are hints, not requirements.

DG: Presentation MathML specifies the order of the arguments.

DC: This is only for simple cases like fractions. You cannot say anything
about an arbitrary function.

DC: If you do not know what the function is, you cannot say what the
arguments are. If you know the arguments, you can know the order.

DG: In practice, while we cannot mandate anything, the speech hints give an
anticipation of the order.

DG: Sometimes the order is obvious, but it may not be for other languages.

next week, we will not due chemistry because CS is gone.

NS: We will work on properties list or finish off the rest of the list.

NS wants a session on units. We will talk about units in a week or so.

NS: Let us finish the lists we have.