Minutes: MathML full meeting, Oct 19, 2023

 Attendees:

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

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

The group is officially rechartered. Members should have received an
invitation and answered questions regarding agreement with W3C rules. Other
people interested in joining the WG who are W3C members should contact
their AC rep to initiate the joining process.

From Moritz Schubotz to Everyone: Thank you Bert. I send the request right
now https://phabricator.wikimedia.org/T349331

NS: Chemistry is getting added to the Wikipedia work that MoS did.

MoS: I must clarify this is only for some chemical formulas like h2o or
something like that. So, it's not a complicated structure. So, it's not a
3D animation or something like that.

NS: I hope you realize you should be using M Multi-script because that does
the alignment of the sub in superscripts across formulas.

NS: had problems with their method. He sent in a bug report.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.5.0-c#cp-md-0-2-a-href-https-w3c-github-io-mathml-docs-intent-core-concepts-core-concept-list-updates-a->2.
Core concept list updates
<https://w3c.github.io/mathml-docs/intent-core-concepts/>
<https://sandbox.cryptpad.info/code/inner.html?ver=5.5.0-c#cp-md-0-a-created-core-concept-character-lists-default-fixity-properties-should-we-do-the-same-for-constants->a)
Created Core Concept character lists (Default Fixity properties). Should we
do the same for constants?

NS: did some work on this list. He brought stuff in from MathCAT.

NS: These names may need some thought.

DC: By saying that these don't require any special speech templates, you're
putting a lot more pressure on deciding the concept names because you are
just going to read them.

NS: People should look at this list and give concept names suggestions.

PL: This came from MathML content and MathCAT.

PL: We need to go through every list we think would be a reliable source
and then make sure that we have what we need from these lists.

NS: Discussed his definite integral examples; where, one was integrated
over a domain, and the second was an integration from var1 to var2.

NS has integrals with arity one, two, and three. He has a separate concept
and speech template for these three cases. Is having different concepts,
depending on arity, a good idea?

DG: So, to be clear, Erity here is a system specific detail because it's
not part of the intense specification in the main text.

NS: If I gave an integral with no arguments or five arguments, then it
would not be in core because it is not known at that point.

DG: You must match arity to be a part of core. Arity is a critical factor
in determining the concept name in the core table. This should be
specifically mentioned in the definition of the core table in the spec.

NS: So, DG, do you have a problem with adding the number of arguments to
the spec?

DG: Yes because you're making it more complex and you're making open more
different from core. So, we're getting into a position where open is
gradually getting further and further from core, basically a second spec.

NS: If an integral had several arguments, well then it's a different
concept, possibly. Right? Cause what does it mean to have an integral with
5 arguments? How do you speak it?

DG: In open, everything is flexible.

DC: If you use a different number of arguments, it is not an error, but it
is a different concept.

DG: Used the example of minus where you can have zero to an unlimited
number of arguments, and it’s the same concept.

NS said that minus is binary but that plus would work for DG's example of
having many arguments but one concept.

NS: Sum and product are this kind of definition.

DC: The speech templates only make sense if you specify the number of
arguments.

DG: The speech templates are not part of the spec, they're part of this
document. They're specific to these documents, so they're non-standard, and
especially in open, everything is flexible, and you can always pronounce
it. So, this is the difference between speaking something and computing
something.

DC: Yes, that's the point. If you give it a different number of arguments,
it's not an error, it's just not in this list.

NS: If we really need arity to be normative in determining a concept
definition, we should mention it in the spec.

DC: If you do not have a speech template for something, then you just read
it.

MuS: He likes what is in the documents. Arity is important. For spacing,
you need to know the arity. We have a star for unknown arity, or unlimited
arity.

DG: Arity is not necessary; you can get it from the speech template.

DG: If you have an available speech template of that number of arguments,
you can use that. And if you don't, you fall back to the default readouts.

NS: I did mention to David, I thought, well, geez, why do I need to write
an Erity column because you could write a program to figure this out.

DC: We need an arity column because we do not want all the users to parse
the expression to see what the arity is.

DC: The core concept list has specified the arity. The open list does not.

NS: In the open list we could say arity is star.

NS: It is useful to have a template with an arity.

NS: Everything should have speech templates.

DC: Let us finish core then bring open more into agreement with it.

*ACTION* NS: If we feel that arity is important in knowing what to say,
then we should mention this in the spec. DC will do a PR for this issue.

MoS: Open is more important than core. We need a method to help people
pronounce their expressions. We need the ability to work with open nicely.
We should focus more on open than on core.

NS: I think intent is pretty darn general in allowing people to say stuff.
I hope we don't need to use the literal string very often.

DG: So, from the open perspective, this is the summary of my point. It is
the speech hint that has an arity, not the concept.

BM: The template has the arity and not the concept.

BM: The derivative can have up to three arguments. You want a single
concept with several arities. Each arity could have its own speech template.

NS: An integral has a fixed number of arguments related to the speech. If
it has a different number of arguments, it must be spoken differently.

NS: has a table of Constants and Sets. He considered moving this table up
to the start where you just list the characters and give them a name.

NS: decided to leave it as it is.

MuS: With the differential D And exponentials, how you pronounce something
depends on if it is standing alone or with other characters. If it stands
singly, you really do want to know that it's a differential D, not a D.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.5.0-c#cp-md-0-b-other-additions-to-the-list->b)
Other additions to the list?
<https://sandbox.cryptpad.info/code/inner.html?ver=5.5.0-c#cp-md-0-ii-a-href-https-docs-google-com-spreadsheets-d-1eswou1k5nxbdlpvqapdoa9h-s8lg_qjn8fjh64g9izq-edit-gid-1358098730-deyan-39-s-original-spreadsheet-a->ii.
Deyan's original spreadsheet
<https://docs.google.com/spreadsheets/d/1EsWou1K5nxBdLPvQapdoA9h-s8lg_qjn8fJH64g9izQ/edit#gid=1358098730>
<https://sandbox.cryptpad.info/code/inner.html?ver=5.5.0-c#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.5.0-c#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>
<https://sandbox.cryptpad.info/code/inner.html?ver=5.5.0-c#cp-md-0-iv-neil-39-s-mathcat-intent-list-and-mathplayer-39-s-rules-list-a-href-https-github-com-w3c-mathml-issues-476-subject-area-inferences-a-a-href-https-github-com-w3c-mathml-issues-475-units-a->iv:
Neil's MathCAT intent list and MathPlayer's rules list (subject area
inferences <https://github.com/w3c/mathml/issues/476>, units
<https://github.com/w3c/mathml/issues/475>)

Note: I want to leave 10 - 15 minutes to discuss the final item, so we
might not get through all the lists
<https://sandbox.cryptpad.info/code/inner.html?ver=5.5.0-c#cp-md-0-3-revisiting-unresolved-a-href-https-github-com-w3c-mathml-issues-473-differentiation-issue-473-a->3.
Revisiting unresolved differentiation issue (473)
<https://github.com/w3c/mathml/issues/473>

Continue discussion of DC's proposal of attaching the intent to the "d"s,
etc., rather than the entire expression.

DC: proposed tagging the Ds, the dots and the partial symbols used to
express derivatives.

NS: So, we have the four notations for derivatives. One proposal which I
was initially going with was, where they just have different number of
arguments, we somehow say them differently.

NS: David had this potentially interesting idea that I have not explored of
just tagging the lower level. So, in the Leibniz notation, just tagging the
D. In the Lagrange, tagging the F prime.

DC: Is trying to get intense that capture all these different things and
the difference between the diverse types of derivatives and integrals.

NS is worried about merging all the notations into one sentence.

DG: There are two issues. Every time you look at the fraction, you must go
digging in the numerator and denominator to check if there's a D in there
to see if it is a derivative, which is implementation wise, kind of scary.
That's pretty much what math parsing must do. The second point is the two
communities, the content generators and the content users, are different
and implement this based on how we make the decision.

We, as a generator, can provide the whole expression and it's almost the
same amount of work to just figure out the this is a derivative than to
annotate the intent.

Once you know it's a derivative, we can do the work as well. Otherwise,
people like Neo, implementers of AT, must always do the work of finding all
the arguments for the different differential notations, which may make it
hard to have non-math accessibility vendors ever support derivatives
because it will be too complicated. So, it makes a difference whether the
generator or the accessibility tool will be implementing the supports. If
you're annotated on the Mrow with the full expression, the AT can just
consume that without doing any logic. It's simple. Otherwise, the AT must
always parse the whole expression.

BM: You don't need disambiguation. You don't need intent at all. You know,
you just read what's there if that's all you're ever going to read. On the
other hand, if you want to read something like the derivative of y with
respect to x, you need some sort of concept and intent.

DC: Whatever we decide, making large intent expressions is difficult.
Marking up the d's is not difficult. Marking up an entire expression would
be hard because the person doing the work might have to understand the
entire expression, and that person may be non-mathematical.

NS: We need a core concept for derivatives.

NS: We will talk about it next week. I want to see DC's concept fleshed out.

From Deyan Ginev to Everyone: The derivatives discussion is on a good slope.