Minutes: MathML Full Meeting 11 Jan, 2024

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Moritz Schubotz
   - Bruce Miller
   - Bert Bos
   - Deyan Ginev
   - Paul Libbrecht
   - Cary Supalo

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

International Conference on Computers Helping People with Special Needs,
(ICCHP) submission
<https://icchp.org/sites/default/files/ICCHP_CALL_2024.pdf> (Feb 2
deadline)?

NS: asked for people to help him with writing a paper for this conference.
The following individuals said they would help: DC, MoS, and PL.

NS will try to come up with an outline this weekend.

PL: We should attend conferences and publicize our MathML work.

PL: Are there technical sessions on Math in the ICCHP?

NS: They have a special session on math and science. This conference is
held every other year. They have about 30-50 people in the math and science
session.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-2-a-href-https-github-com-w3c-mathml-issues-484-mixed-fractions-in-core-484-a->2.
mixed-fractions in core (484) <https://github.com/w3c/mathml/issues/484>

PL: This needs to go in core. Not sure what name it should have.

PL: You should not say mixed-fraction one and one half. You should leave
out the word mixed-fraction. You should just say one and one half.

NS: Use "and" as the linker word.

NS: Do not say mixed-fraction and do not say "comma": "one comma one half"
is not good.

NS: This issue (484) can be closed.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-3-a-href-https-github-com-w3c-mathml-issues-483-ellipsis-483-a->3.
Ellipsis (483) <https://github.com/w3c/mathml/issues/483>

NS: I did use what DG pointed out is an encyclopedic name for ellipsis. You
can see it towards the top of the concept list. There are names for
ellipses going in different directions.

DG: The Unicode name is better than what NS chose because it gives the full
information.

There was a discussion on what the proper names for directions would be.

NS: What do other people think? Is Downright better than downwards and to
the right, and is upright better than upwards and to the right?

DC: Do the directions have any mathematical meaning? Can they all just say
ellipsis?

NS: If you cannot see the characters, then you are losing some of the
meaning of the symbol.

NS: If you had a matrix, you could have a diagonal ellipsis in the middle.
The directions could tell you that there is some type of structure in your
matrix.

NS: Since the ellipsis with different directions gives you information,
they should be named.

NS is unsure if this issue should be closed.

PL: You should speak the directions for the ellipses.

NS: This would give the blind the same information that the sighted have.

From Deyan Ginev to Everyone: directionality will come up often with
arrows, e.g., \upmapsto and \downmapsto could be up-maps-to and
down-maps-to https://tex.stackexchange.com/a/54639

DG: We need to have a method to select concept names for symbols that have
directional information.

NS wants to have a meeting on naming.

NS: We are ok with the names for the ellipsis.

DG: Agrees with the current naming scheme in the short term. He wants to
come back and revisit our naming strategy.

NS: Okay. Well, we are going with sort of the encyclopedic names. Your
objection was that the Unicode name was a better choice, but I think
they're both falling in the category of an encyclopedic name.

DG: So, this is great. The tiny detail that is left is when and how we add
topographic information on top of the encyclopedic name.

DG: The concept is ellipsis. Sometimes we should give directional
information.

DG: You do not want to give directional information all the time because
sometimes it is superfluous information.

NS: This really comes up in the cases involving arrows. The convention that
they used in Unicode for the Arrows is basically trying to just describe
what the arrows are. The arrow names do not try to say what the symbol
means.

DC: The directional ellipsis case, where the direction makes a difference,
is rare, and we do not have to worry about it.

DC: We give names to arrows which describe what the arrows do. We do not
have to describe what the arrows look like.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-4-a-href-https-github-com-w3c-mathml-issues-485-tends-to-485-a->4.
tends-to (485) <https://github.com/w3c/mathml/issues/485>

NS: Summarized the issue.

It breaks down into three different cases. One is generic tends-to. Another
is one where it tends-to from a certain direction, Either from below or
left, or from above and to the right. This is one way to name the
directions.

NS: DG suggested adding a third optional argument of above or below.

NS: AT can read things poorly.

DG: There's a fourth example if you open the Wikipedia page on one sided
limits that doesn't use an arrow. I didn't quote it, but it's in the
comment. If you open that link, there's this beautiful example with the
superscript.

NS is not a fan of using three concept names.

NS: There is a notion that, if AT doesn't know about it, then the AT should
simply read what is there. It still should speak it in a comprehensible way.

NS asked DG if there was another case where you could throw on an added
argument.

DG: I was thinking of maps-to since we just discussed arrows. Because
maps-to can point: top to bottom, or bottom to top, or left to right, or
right to left.

DG: I found a good counter-argument to my own point, and in support of
Neil's suggestion for multiple names, which is that we have precedent for
adding multiple entries for the same concept with different boundary
conditions. Namely for the same interval concept, we have open-interval,
open-closed-interval, closed-open-interval and closed-interval. So, based
on that precedent, it is reasonable to do the same kind of branching for
tends-to. Thinking about this some more, the interval example highlights
both points. 1. We have done it before, so we can do it again (multiple
concepts varying on boundary conditions). 2. Without better argument
support, various adverb phrases arguments will require branching into
multiple concepts.

NS: We ended up saying there's really 2 arguments. And they are very
related concepts, but they're not the same concept. So, I think that
argument would apply here for the tends-to.

DC: Do you have a proposal for the names?

NS: I am open to tends-to or approaches left to right.

DC: I prefer tends-to rather than approaches, and above and below to left
and right.

NS: DG, do you agree with this?

DG: To me they're all arbitrary so any ones you pick are fine. I'm just
wondering whether it's even worse than what I thought in the sense that
above and below are just the same as left and right but it's just the
y-axis instead of the x-axis.

NS: I do not have an effective way to choose between up and down and left
and right.

NS will remove "approaches" from issue 485.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-5-a-href-https-github-com-w3c-mathml-issues-482-large-operators-482-a-integral-sum-union-etc-max-5-minutes-issue-opened-at-the-last-minute-so-not-much-discussion->5
Large operators (482) <https://github.com/w3c/mathml/issues/482> (integral,
sum, union, etc.): max 5 minutes (issue opened at the last minute, so not
much discussion)
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-6-derivatives-first-higher-order-different-notations-a-href-https-github-com-w3c-mathml-issues-473-473-a->6.
Derivatives (first, higher order, different notations):473
<https://github.com/w3c/mathml/issues/473>

max 10 minutes (lots of discussion)
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-7-a-href-https-w3c-github-io-mathml-docs-intent-core-concepts-core-concept-list-updates-a->7.
Core concept list updates
<https://w3c.github.io/mathml-docs/intent-core-concepts/>

(finished the first item so we will start on David F's wish list)
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-i-a-href-https-docs-google-com-spreadsheets-d-1eswou1k5nxbdlpvqapdoa9h-s8lg_qjn8fjh64g9izq-edit-gid-1358098730-deyan-39-s-original-spreadsheet-a->i.
Deyan's original spreadsheet
<https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit#gid=1358098730>

(done)
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-ii-a-href-https-docs-google-com-spreadsheets-d-1clpaiy9kx5k-67rg6rjsaxerdsb-_iymgzatkqjshvg-edit-gid-0-david-f-39-s-wish-list-a->ii.
David F's wish list
<https://docs.google.com/spreadsheets/d/1cLPaIy9kX5K-67RG6rjSAXErDSB-_iYmgZaTKQjShVg/edit#gid=0>
<https://sandbox.cryptpad.info/code/inner.html?ver=5.6.0-b#cp-md-0-iii-a-href-https-gist-github-com-dginev-825078ae316c32c312436f42061b3d05-deyan-39-s-physics-list-a-and-a-href-https-gist-github-com-dginev-ff7e6e090b79a0389fc2eff2b9961331-chemistry-list-a->iii.
Deyan's Physics list
<https://gist.github.com/dginev/825078ae316c32c312436f42061b3d05> and Chemistry
list <https://gist.github.com/dginev/ff7e6e090b79a0389fc2eff2b9961331>

(finished first part of physics list)

discussed line 78 in DG's table which was: "name (do we use
_($piece1,$piece2,...$piecen) or name($piece1,...)?)"

start with Misc

NS: So, we have several separators Listed there. I know Murray was like, oh
you can't use time because time is so location dependent on how it's
spoken, but this is more about just specifying what say the colon means.

NS: What is "list-separator"?

DG: There was an example with a nested list where you had colon, semicolon
and comma as the separators.

NS: Maybe it is a property more than a concept.

time-separator

NS You would have hours minutes and seconds, thus you would have three
arguments.

Interval-separator

DG: So, consider integral from 1.1 to 1.9. It could be the integral from
1,1 to 1,9.

NS: We already named "interval:, so we do not need an "interval-separator".

NS: We maybe need something about time. Would it just be called time?

DG: Time is complicated.

*ACTION* Neil will set up a time issue.

NS: Is still trying to figure out what a list-separator is.

NS: The fourth one is where-separator ( : such-that?)

NS: This is some sort of "set" concept and does not matter.

DG: So maybe we do not need any of them. We only must figure out time.

NS: Will set up an issue for "time", and that is where we are stopping for
today.

PL: We need to tell the outside world about our work. We need to put out
another snapshot of our status. NS's ICCHP paper may be such a status
report.

NS: has a paper describing how he got pdf accessibility to work.

NS: There is an accessibility conference in Japan from February 14-16 that
is virtual.

NS: Next meeting, NS will discuss having two-hour meetings. That will allow
us to have our discussion on naming.