Minutes: MathML meeting 14 Dec, 2023

Attendees:

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

<https://sandbox.cryptpad.info/code/inner.html?ver=5.5.0-g#cp-md-0-regrets>
Regrets

   - David Farmer

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

LM: Folks, I lost the last line of some of the chat messages.

NS: We will meet on December 21, 2023. After that, our next meeting will be
on January 4, 2024.

DG: reported on meetings that he, and DF, had attended. It was a friendly
crowd for MathML.

DG: I think we'll have some switch over to MathML in the coming year. David
Farmer semi-officially announced Space Math which will also have MathML as
a primary target.

DG: Space Math is a new syntax that David Farmer has invented, and it will
be primarily used for the Pretext language initially but can be used as a
stand-alone product to enter mathematics on the web.

DG: The goal of accessibility had a lot of support.

MoS: We also got some feedback from the Wikimedia crowd. Basically, people
had problems with rendering. Symbols did not look like they had before.
There are some rendering bugs as well. These bugs might be because Chrome
and Firefox support different things.

From Moritz Schubotz to Everyone (original comments, in German):
https://de.wikipedia.org/wiki/Portal_Diskussion:Mathematik#Native_MathML_rendering_option

From Paul Libbrecht to Everyone: My announce in chat: I made a research at
the ISM Symposium around a product called MathSTAAR which seems to be doing
a

MuS: Discussed a new way to send images using plane text. People were
worried that this would have security problems.

MuS: I did figure out a nifty way of doing transpose. I don't know if it's
relevant to mention that or not, but it's a lot more concise than The
proposals. It is using different Unicode math. different ways to render
transpose. 𝐴^⊺ gets the MathML A global setting chooses which rendering
from ("T", "𝑇", "t", "⊺", "⊤")

From David Carlisle to Everyone: https://tex.stackexchange.com/a/435363/1090

MuS: So, it's simple and it's easy for an AT to speak it because you just
have a superscripted variable. So, you say that variable and then you run
into the MI for the superscript, and it says intent transpose you just say
transpose and you did it.

NS: Using screen sharing, NS reviewed some of the progress he had made with
the core concept list. He discussed the markup for line segment and length.

DG: found a bug because of a misplaced bracket.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.5.0-g#cp-md-0-2-large-operators-integral-sum-union-etc-max-10-minutes>2.
Large operators (integral, sum, union, etc.): max 10 minutes

NS: Some of the terms brought up were integrals, sums, products, unions,
and intersections. These terms all need to have some kind of markup.
They're all identical except for the symbol, and the word that you would
say based on that symbol.

NS: And so there are A dozen or so that are there, not all of them are
necessarily core concepts, but at least 6 or 8 of them are core concepts.

NS: They can have a single argument (like being applied over a domain) or
have double arguments (like being applied from some number to some other
number).

NS: Instead of having several concepts, we could just have a list of
symbols.

NS: If we listed all of them, then they would be scattered over several
subjects instead of being together. NS wanted to have a process of listing
them together since they all had the same format.

NS: Should they all get just listed out? Should they get grouped together?

DC: One approach is to list all of them together and saying they have the
same speech template.

MuS: We called the narries. They had three potential arguments: the lower
limit, the upper limit, and the integrand.

MuS: I really think that the right place to put the intent is on the mrow
because if you put it on the sub or super, you will miss the integrand.

DG: said that if you do not have proper fences, you will not know where an
expression ends. For Example: the sin of 2A + 1. Is the +1 included in the
sin?

NS: We will create an issue and discuss it.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.5.0-g#cp-md-0-3-derivatives-first-higher-order-different-notations->3.
Derivatives (first, higher order, different notations):[

473 <https://github.com/w3c/mathml/issues/473>]

NS: There are two problems with derivatives. The first problem is that
there are first derivatives, and higher order derivatives. The higher order
derivatives will have an extra parameter specifying the order of the
derivative.

NS: The second problem is there are four notations for derivatives:
Leibniz, Lagrange, Euler, and Newton. They all tend to be spoken
differently, which suggests that they should have different names.

BM: Are they different other than in the sense that A common reading of
these is independent of the semantics, and it's just reading notation?

NS: You could have terse or verbose pronunciations. If you have a more
verbose reding, they are much more like one another.

NS: We should supply a way to have the derivative read the way the author
would like it to be read instead of having one way to read all derivatives.

MuS: We do not need to worry about Lagrange, Euler and Newton.

MuS: I think that terse is the way to speak the Lagrange, Euler, and Newton
expressions.

MuS: The second derivative of y with respect to x sounds better than d
squared y by dx squared. NS disagreed with this sentiment.

DC: You would have to read out completely the partial derivatives.

From Deyan Ginev to Everyone: terse is a great default, but if a novice
could request the verbose reading for a confusing expression, it might be
helpful.

The Leibniz case may need special treatment.

DG: My main point was that it's unfortunate if we must split the
derivatives into too many concepts unless we have no other choice. It seems
like properties could be a nice vehicle to share a single derivative
concept but annotate the notation as a property.

DC: You do not want four concepts. No one would get this right.

NS: Use derivative for a property name.

DG: has an example of his proposal in the issue (473).

NS: It feels right to have a property.

MuS: for 𝑑²𝑓(𝑥)/𝑑𝑥², how about the MathML

MS: For 𝜕²𝜓(𝑥,𝑡)/𝜕𝑥𝜕𝑡,

BM: The properties tend to be for the purpose of choosing between overall
notations and structures. Keep the concept for something simple like
derivative.

NS: It feels right to have a property.

DC: Noone uses Euler anymore.

DC: We are always tempted to put in properties because it solves our
problem, but you just assume somebody else is going to do something.

NS: It sounds like we have two potential ideas here. One is to use
properties, and the other is to basically let's just name stuff for the
likeness case, which could be used elsewhere.

BM: These are two independent things. One is the notation, and one is
addressing the question of derivative with respect to what and what order.

BM: You can think of derivative, in the general sense, with up to 3
arguments, and then with the property to clarify the chosen notation.

BM: You would write derivative colon, whatever notation, and then somewhere
would be a one for first derivative 2 for second derivative.

NS: Just giving the property alone would not be useful.

DC: Properties are not needed.

NS: Do we go with derivative and ignore properties?

NS: We will not include properties.

NS: Speech order is not related to argument order.

BM: It might be better to make the order be the third argument so that it's
more easily optional.

BM: This would be used when it is the first derivative.

MuS: Having the order be first more closely resembles the speech order.

DC: Rather than an optional argument, we could just describe two
derivatives with different numbers of arguments.

NS: The partial derivatives are a more complicated case.

DG: The higher order derivatives are not in core because they are not used
in High school.

NS: Acceleration, in physics, is a second derivative.

NS: We can close the issue once we put in the solutions.

NS: will try to finish DG's list.

NS: In the case of limits, you have to say in which direction you are
approaching the limit.

After the meeting, in issue 473 <https://github.com/w3c/mathml/issues/473>,
NS writes: ' In the Math WG meeting today, we agreed to the following:

   1. Of the four notations Leibniz, Lagrange, Euler, and Newton, only
   Leibniz notation ($dy/dx$) needs to be marked with intent. The others can
   be spoken as their notation.
   2. The intent is intent='derivative(function, order, var)'. We may add a
   second two argument form that drops order for first order derivatives based
   on experience. However, for now, we are going with a single form.
   3. Based on experience, we may add properties to core to distinguish the
   various forms of derivatives: :Leibniz, :Lagrange, :Euler, and :Newton. For
   example, intent="derivative:leibniz($f,2,𝑥).
   4. Partial derivatives will have their own intent: partial-derivative.
   Partial derivatives might use a vector or specify the components of a
   vector and so take any number of variables.

An example of the usage of intent for the derivative: $\frac{d^2
f(x)}{dx^2}$

<mrow>
    <msup><mi>&#119889;</mi><mn>2</mn></msup>
    <mrow arg="f">
        <mi>f</mi>
        <mo>&#x2061;</mo>
        <mrow intent=":fenced"><mo>(</mo><mi>x</mi><mo>)</mo></mrow>
    </mrow>
</mrow>
<mrow>
    <mi>d</mi>
    <msup><mi>x</mi><mn>2</mn></msup>
</mrow>

The discussion continues in issue 473
<https://github.com/w3c/mathml/issues/473>.