Minutes: MathML Full meeting 6 June, 2024

 Attendees:

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

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

NS was unable to enter all the units discussed in the May 30 intent
meeting. Some of the units were unclear what to do with them. One example
of this was calories (little calories) and kcal (kilo-calories also called
big calories).

Little c was used for little calories, and cap c was used for big calories.
He will put both in the units list.

Argument order inside intent applications #478
<https://github.com/w3c/mathml/issues/478>

*ACTION* DC will make his open list have a format similar to the core list.

*ACTION* NS: Close issue 478.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.1#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.1#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

The following action item came from the May 30, 2024, intent meeting:

Follow up from last week: C followed by a degree sign versus a degree sign
followed by C?

Both Greg and Joseph said they had not seen C followed by a degree sign.
For this reason, C followed by a degree sign will not be included in our
list of symbols that get the units property.

From Deyan Ginev to everyone: °C vs C° is explained in a bit of detail on
Wikipedia, they confirm "this usage is non-standard"
https://en.wikipedia.org/wiki/Celsius#Temperatures_and_intervals

Degrees Fahrenheit and degrees (angle) will get the units property.

NS was unable to enter all the units discussed in the May 30 intent
meeting. Some of the units were unclear what to do with them. One example
of this was calories (little calories) and kcal (kilo-calories also called
big calories).

Little c was used for little calories, and cap c was used for big calories.
He will put both in the units list.

The intent group is developing a list of Unicode symbols, related to math,
which should be spoken by AT. It is not useful for AT to ignore these
Unicode symbols or to read the Unicode numbers for these symbols. DC, MuS,
and NS have been developing such lists. NS has been consolidating these
lists into one list, and will give the list to DC, who plans to make it
available to the developer community.

DC is adding speech templates to the symbols.

NS: The point of this list is: if this character shows up, it should be
spoken.

DC: The CJK (Chinese Japanese Korean) list of units will not be included in
DC's list.

DC discussed Planck's constant (shown by h) and the reduced Planck's
constant (shown by h bar) which is h / 2pi.

PL: Wants the currency table to be referenced. He thought that it was up to
Unicode to make these symbols understandable.

DC: AT does not speak the Unicode symbols.

We cannot handle all the Unicode symbols.

From Murray Sargent to everyone: 149,186 characters in Unicode 15

NS: We need to have a discussion on where this list should reside. We want
to make this list official in some sense. Should it be a note?

DC: This list of Unicode math symbols, with speech templates, should be on
GitHub so that it can be updated.

NS: We are not saying use these specific words, we are just saying that AT
should do something comprehensible when these symbols are encountered.
Reading the Unicode symbol numbers is not helpful, but it is better than
skipping the symbol entirely.

MuS: In writing up a description of this list we should say that we are
including characters that might show up but are not officially math
characters.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.3.1#cp-md-0-2-potentially-closable-intent-issues-after-a-little-discussion->2.
Potentially closable intent issues after a little discussion:

   - Argument order inside intent applications #478
   <https://github.com/w3c/mathml/issues/478>

Early on, NS had suggested some text that would clarify this issue:
https://github.com/w3c/mathml/issues/478#issuecomment-1786492698

Unless otherwise noted below, the argument order of the concepts follows
the order used by the presentation MathML elements that are typically used
to represent the concept. For linear notations such as "plus", this means
the left-to-right order used in an mrow. For power, it means the order used
in msup (base, exponent). And for "root", it means the order used in mroot
(radicand, index). Some concepts such as "binomial-coefficient" have
multiple notations ( n choose k, cap c sub n, to the k-th, cap c, open n
comma k close
). Where the order might not be clear from the standard notation, the
speech hint or comments should make clear what is the intended order of
arguments.

NS said that DC doesn't particularly like this text For the core list, but
does like it for the open list.

NS added text to the open list.

Ns says it should be like the core list with a speech template so that the
order of arguments is clearer.

DG: Oh, I'm happy the problem is understood. I have not yet understood what
prohibits us from just putting this in the spec itself. But apart from
that, I'm happy that there's progress.

NS: The formats for the open and core lists are not in the spec. There is
nothing normative in these list. It has advice on how to choose the order.

BM: For divide, the template makes clear what the role of one and 2 are.
For divides we should make clear what is on top and bottom. The template
should make sure people know what the argument roles are.

NS: Fraction does that.

NS: DG wants this in the spec, but normally it is not in the spec.

NS: The core list gives the order of arguments.

NS: The example that I always give is fraction. So, in Western cultures, we
say A over B, but in least some East Asian countries you say the equivalent
of B under A.

NS: The core listing should make it clear what is argument one and what is
argument 2. The core list is in English.

NS: The intent always has the numerator 1st and the denominator second.

NS: By specifying it in the open list, we are telling people you should
follow some conventions and you should have a speech template that makes it
clear what are the roles of the arguments.

DC: The open list lets different systems have distinct roles for the
arguments.

NS: What if someone says that two people want to do it two different ways
in the open list?

DC: We should not allow two contrasting alternatives in the open list. It
should be first come first served.

DC: However, if two people disagree, we cannot do anything about it.

DC: If something in open is well used, it should go to core.

PL: I would be interested in maintaining this list.

DC: The Google docs version is not usable.

NS: The plan is not to use google docs as the primary source.

NS wants a more formal style.

*ACTION* DC will make his open list have a format similar to the core list.

MoS: Who is going to maintain this list in the long run? This would be an
opportunity to move the maintenance to another group.

NS: We need to discuss where these lists will live, do they move into the
W3C space, or do they stay in GitHub, or do they go somewhere else. The
open list is in particular something that we have not figured out. Should
it have a moderator, or can anyone change it?

DC: Currently we can use pull requests.

DC: Maybe a community group could maintain it.

DC: If we wish, the intent group can maintain it.

DC: All the specs are on GitHub.

MoS: We can work with pull requests. This is a good solution. Everyone can
contribute.

NS: Hopefully, we get a lot of interest at the start. Later, interest will
shrink.

PL: I would warn about deciding on a governance policy on how to work on
it. I think Murray made a very nice warning statement that the problem with
Unicode corrections is that you are never going to change a symbol's name.

NS: Do we close issue 478, or leave it open?

BM: Entries in the open list should make clear what the argument order is.
That would seem to resolve it in my mind, but I'm not sure if I'm missing
something.

BM: Close issue 478.

After the meeting, NS wrote: Although DG feels that the spec itself should
have mention of argument order, he deferred to BM who felt the current
solution of adding text to the open list and having speech templates is ok.
Others agreed that the issue can be closed.

*ACTION* NS: Close issue 478.