Minutes: MathML Full meeting 11 May, 2023

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Bruce Miller
   - David Farmer
   - Murray Sargent
   - Bert Bos
   - Steve Noble
   - Patrick Ion
   - Deyan Ginev
   - Paul Libbrecht
   - Cary Supalo
   - Murray Sargent

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

NS: There's been a little bit more progress on the accessibility mappings
that we should pay attention to coming from the ARIA group. James Craig,
from Apple sent a message that said the consensus from the ARIA face to
face was that we may need a MathML accessibility mapping.

NS: Math accessibility mappings:
https://github.com/w3c/aria/issues/660#issuecomment-1539158035

W3C wants a sense of how many people will attend the TPAC meeting
in-person, in Sevilla Spain. The TPAC meeting runs from September 11
through September 15. The answer was two from our group and perhaps three
from Igalia, for a total of five.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.3.0-rc1#cp-md-0-2-intent-location-format>2.
Intent location/format

DC: I am just experimenting. His first table was using Markdown, but this
proved to be painful when he started including languages. He converted it
to YAML. Editing in Google docs proved to be painful.

NS: Do you understand that language, or did you just copy and paste it from
somewhere?

DC: Yes.

DC: Showed the languages in his table.

DC: It is easy to edit this including changing its styles like color.

PL: It is easy to edit DC's table.

PL: The first usage of this table is display. The second usage is that this
table serves as input to some implementers.

PL: We can generate XML from this table.

DC: And that is why I did not want to use Google docs.

DC: We should not worry about translation so much now because we do not
have an English core list.

PL: Had a good experience translating DF's core list table. It only took
him two hours to translate the table.

DC: This table is usable as a system. I am happy with it.

PL: Do we want this table to be inside or outside the spec?

DC: It should be outside the spec. If it is in the spec, you cannot edit it.

DC: It can have a W3C GitHub location.

PL: Wondering whether to offer YAML source to the implementers or xml or
JSON or some other standard format to have flexibility in coding things?

DC: You could make an XML or JSON file at each commit.

DC: The hard part is getting a list of concepts.

NS: YAML is a superset of JSON.

PL: YAML is far more flexible than JSON.

DC: The hard part is getting from google docs to YAML. Now it is easy to
edit with global edit. We can change the format on the fly.

NS: wants to get us refocused on the actual list.

NS: Two questions: Where do we place this file? DC wants it out of spec.
The second question is the file's format.

NS: DC thinks this is a reasonable format for core. DC, Is this a
reasonable format for the open list?

NS wants a format that people would be likely to contribute to. Would
having the file in GitHub discourage people from contributing to it? Would
having the file in GitHub make people a little more thoughtful about their
contributions?

DG: wants a visual interface so that people would not be looking at the
underlying data. IN that case, the format of the underlying file would not
be important to the contributors.

DG: I never wanted people to be editing the raw open list. It is just too
large.

NS: Can GitHub track the changes when the user interface is used for edits?
Google docs have a history capability.

DG: So, having GitHub as the guardian of the original source is the wise
approach compared to Google Docs. Just using the history feature is not,
especially because you do not know when things change. The pull request
sends notification to anybody watching the repository.

PL: So, if you use translation tools, the tools will generate pull
requests.

NS So people agree that GitHub is the right place. We will have an external
interface that makes the list easier to deal with.

NS: I assume that people think the W3C repository is the right place for
the list? It will be stored under math.

NS: People do not have strong opinions on its internal format.

DC: will move the list to its new home.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.3.0-rc1#cp-md-0-3-review-core-intent-names-and-properties-related-to-410-432>3.
Review Core intent names and properties (related to #410, #432

NS: Now we come to deciding what names and properties go into core. While
we cannot decide this in our current meeting, perhaps we can decide on the
criteria to guide DC or myself or someone else on what to put in core.

NS: Then we create the initial list, and then we can discuss the objections
as to what's missing and what it should be in core.

NS: One criterion could simply be to take everything in DG's and DF's list
and make that our initial list.

DC: Start small and add things as required. DG's list is an open list and
is big.

NS: Does the name of a Unicode character need to be in core?

General agreement that Unicode characters don't need to be listed in core.

DC: MathCAT has transpose as a built-in object with a postfix fixity. DC
tried to override the postfix functionality. He tried to force it to say
"transpose of X" in his list examples, but that did not work.

DC: There was a discussion on transpose and fixity and what should be
stored in core. Should transpose be in core with a postfix fixity as
opposed to being in core as a function?

DG: There's a second list that I worked on, which is not the open one, but
is constrained by being for K-12 grades. DG believes this is a good
constraining factor for core. It is for lower grades.

DG: DF developed a list for K-14 bringing in undergraduate material.

DG: So, Maybe K-14 is fine, and so add the common things to core.

DG: The K-14 brought non-math material into the list. For example, units
and chemistry symbols were brought into the list.

DG: Do we want to keep core to be just math?

From Deyan Ginev to Everyone:
https://www.matematika.bg/algebra/hyperbolic-functions/hyperbolic-functions-bg.html

We had a discussion on how hyperbolic functions are translated into various
languages.

From Patrick D F Ion to Everyone: Read ‘sinh’ as ‘shine’ (the editor
corrected the first go to ‘sing’

From Patrick D F Ion to Everyone: Oscar Wilde “Two countries separated by a
common language.”

From David Farmer to Everyone:
https://docs.google.com/spreadsheets/d/1cLPaIy9kX5K-67RG6rjSAXErDSB-_iYmgZaTKQjShVg/edit#gid=0

DG: What you are doing is mainstreaming the Western notation rather than
the name? So, what we say when you pronounce sh is hyperbolic sign in
Bulgaria, and what we share between the different realms is the actual name
of the of the mathematical object.

DG: The point was, even though it's less brief, using the actual name of
the concept has merits from the perspective of inclusiveness, making sure
everybody understands what you wrote down. Hyperbolic sign is very long,
and probably unpleasant to look at, but it has the benefit of being
understood when it translates.

*ACTION* DF action unfreeze your list. Make your list more public.

NS: DC is volunteering to move the repo that he has written to core and to
trim and add to this list.

DC: The open list is more difficult.

NS: Let us concentrate on core first. Properties are missing from this
list. Properties such as units and "fill-in-the-blanks".

NS: Wants someone to propose a name for "fill-in-the-blank". He would like
to add it to MathCAT.

PL: Call it "blank".

NS: It might not actually be a blank. It might be an open square or
question mark. It might be some kind of input field, or place holder.

DG: HTML input seems very appropriate.

NS: But it might not be an input field. It could be a printed worksheet or
be Word doc.

?: Call it a placeholder.

NS: That sounds good.

NS: I thought that we agreed not to include Unicode characters in our core
list. That would include Greek and Hebrew characters.

DC: Do you know how many symbols we have in the operator table?

NS: Thought that it was around 1,500 symbols, but he could be wrong.

DC: It is 1,177 symbols.

NS: We've resolved the contentious issue about concepts, sources, and
literals.

NS: We will focus on core.