Minutes: MathML Full meeting, 27 July, 2023

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - David Farmer
   - Dennis Müller
   - Bert Bos
   - Deyan Ginev
   - Moritz Schubotz
   - Paul Libbrecht
   - Bert Bos
   - Bruce Miller

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

NS has not made any progress on the charter.

BB: Our charter is on the agenda of the people who oversee charters.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.0-rc5#cp-md-0-2-creating-work-assignments-to-move-things-forward->2.
Creating work assignments to move things forward.

NS: We must create a list of core properties and core concepts. We need a
method to get people started working on this. It has been two months since
we made progress on these lists.

PL: I will work on this but probably not next week. I know there are some
lists to take from. I have my own estimate of what is supposed to be K- 12.

NS: You could add the French or German if you are so inclined.

PL: The biggest work is to get a list big enough to have some
comprehensiveness. It should not go over two hundred entries.

NS: Do we include equals? I see no reason for an infix version of equals to
be on the list. Normally equals is a single character and you just speak it.

PL: More often, in French and German, you say "is equal to" instead of just
"equals".

From Deyan Ginev to Everyone: == in CS

PL: I am also afraid that Unicode has words in other languages like "sin".

DC: I am assuming that AT has a name for them and does not need to be on
the list.

NS: I just do not see them being a concept name. They are not like
transpose.

MoS: We have the pragmatic content MathML, which is a superlist of what we
are considering for our concept list. We have a lot of translations.

MoS: So, my suggestion would be to start with a core list which is based on
pragmatic content, and we can easily generate them in initial lists and
then Everything else can go to the user contributed extensions.

NS: The core list has things like equals and greater than, and lots of
things that we must resolve.

NS: If we put equals and similar things in the list, the list will be much
bigger than it needs to be.

NS: We had a discussion of when people say, "is equals to" versus just
saying "equals", and if equals should be in the core concept list. This is
about the ways a Unicode character could be spoken. We had a similar
discussion about sine and tan.

PL and NS talked how a single character could be translated into French and
German.

DF: We're talking about issues that are not ambiguous and notation that is
not really overloaded, and that is distracting us from what we really care
about which is the cases where you cannot tell what it means or how to say
it. So, you know, notation that is not inherently ambiguous just strikes me
as not worth paying so much attention to, and it is just going to pollute
our list with an enormous number of things.

DC: If things are described directly they should be listed.

NS: Transpose belongs as a core concept.

DG discussed the chemistry case where equals can stand for a double bond
like "C = C" for a "carbon carbon double bond", which is a postfix
description. A minus can stand for a single bond. The "equals double bond"
should be in the list because it is not spoken as written.

From Deyan Ginev to Everyone: https://en.wikipedia.org/wiki/Double_bond

NS: With equals you should use a single mo. Equal in chemistry is used for
a double bond.

DG: In programming, two equals sign together may be spoken as a single
equals.

DC: We can have a chemistry property which brings in a new set of
pronunciation rules.

BM: There's a distinction between disambiguating and whether the concept
needs to be listed in the core dictionary. Certainly, an equals that is
used for a double bond in chemistry needs to be disambiguated. But that
does not necessarily say that equals has to be in the core dictionary.

BM: Do translations have to be part of the spec? I mean, we might want to
provide a formative document that lists out common terms that AT ought to
be considered in translations.

NS: We should have a list of Unicode characters that AT should support in
translation. This list should be in a note and not in the spec.

NS: In MathCAT he has around 5,000 mostly funky Unicode names like square
with a cross, inside and a bar on top or something that has no clear
pronunciation.

NS: If we put 5,000 entries in a table, the table will be too big to
implement.

DG: I am wondering whether adjusting the open list where it is completely
out of the spec but has little additional metadata bits that say which AT
engines have implemented which concepts would be more useful so that you
know that in openness anything goes.

NS: JAWS is going to use MathCAT. If they did not, then the only way to see
what JAWS, or any other speech output program, implemented would be to
listen to the output of the program, and its pronunciations could change in
a few months.

PL: The role of our table is to provide the AT with various language
translations.

BM: The longer this discussion goes, the less I believe in having a core
list. These symbols should be relegated to an informational open note.

NS: The idea of a core list is to give a list that everyone should
implement.

PL: Both core and open are community-based lists.

PL: So, the many translations would benefit if they were notes.

NS: It is unclear where core should be placed in the spec.

BM: There should be a list in a note form that is moderated and can be
extended by the community. The developers should include the essential part
of the list. We cannot demand that people implement the list.

NS: If we put out the MathML standard which would contain MSUB, then
everyone would agree on how to speak and implement MSUB.

BM: There is no agreement on how much everything should be implemented.

NS: It is a concept list and not a word list. What are the concepts needing
to be implemented?

NS: And so, the question is, what are the concepts that are absolutely
necessary?

BM: They are important but do not need to be specified.

NS: One of the things about power and divide was that they would be in
core. That means that AT knows about it and is free to choose the wording.

DG: Special things like equals and power must be in core.

NS English says negative three where other languages say minus 3.

DG: You mentioned there are two ways of speaking equals, which are that
something equals something, or something is equal to something. Both of
those depend on knowing pretty much that there are two arguments with the
two sides. It is an infix.

DG to NS: Do you have the fixity information for all your Unicode
characters?

NS: In general, it is the Unicode character that is being spoken.

NS has some exceptional cases for some of the arguments. In general, the
characters simply say their name.

DG: The special cases would have to be in the core. Power is one such
example.

DC: For equals, there is no actual special case because you just are
reading the equals sign when you get to the equal sign.

DG: They are going for equals, so we say "is equal to" all the time in
Bulgarian but only if you have two arguments. We do not have simple equals
words. We do not have a single word pronunciation for it. It is always
these three pieces "is equal to".

BM: I am assuming that the AT has Access to all the basic Math and L
information already, right? So, it If you have an Mrow, A equals B, it
knows.

NS: An example of where things are different would-be dollars. So, you had
put dollar sign in front of three and yet you would say three dollars.

NS: We are at the end of the hour, and we have not made any decisions.

PL: Is anyone planning to present "intents" at the Math UI conference in
the first week of September? You can present remotely. The application
deadline is August 7.

DG is thinking about it.

BM this is an enjoyable workshop.

PL: it would be good for someone to present intents.

Search for CICM.

From Dennis Müller to Everyone:
https://cicm-conference.org/2023/cicm.php?event=mathui&menu=general

From Bruce Miller to Everyone: https://cicm-conference.org/

DG: He convinced himself to put double bond in the core list.

DC: there should be a separate thing for chemistry: minus for single bonds
and colons for double bonds.

NS: is trying to get Unicode to have more characters.

NS asks PL to work on something core list related.

NS: something must happen.