Minutes: MathML Full meeting 5 December, 2024

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Farmer
   - Bert Bos
   - Deyan Ginev
   - Patrick Ion
   - Bruce Miller

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

   - Paul Libbrecht

<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0-action-items>Action
Items
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0--a-href-https-github-com-w3c-mathml-issues-181-181-mathml-4-extensions-for-alignment-and-possible-deprecation-of-maligngroup-and-malignmark-a->#181:
MathML 4 extensions for alignment and possible deprecation of
(maligngroup/) and (malignmark/) <https://github.com/w3c/mathml/issues/181>

*ACTION* MuS will try to shorten the descriptions of maligngroup and
malignmark in the spec.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0--a-href-https-github-com-w3c-mathml-issues-434-434-language-variations-as-separate-intents-a->#434:
language variations as separate intents
<https://github.com/w3c/mathml/issues/434>

(close?)

DG Wrote: The WG meeting today, 12/5/2024, had consensus that these
questions are in AT's court and the spec can remain silent for the moment.

DG closed issue 434.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0--a-href-https-github-com-w3c-mathml-issues-448-448-what-39-s-in-a-name-also-quot-reference-quot-etc-a->#448:
What's in a name (also "reference", etc.)?
<https://github.com/w3c/mathml/issues/448>

(close?)

DG closed issue 448.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0--a-href-https-github-com-w3c-mathml-issues-449-449-intent-properties-ordering-amp-references-a->#449:
Intent Properties: ordering & references
<https://github.com/w3c/mathml/issues/449>

(hard/long one)

NS to DG: Put in a comment to use the last one for ordering properties.

DG wrote: In the WG meeting on 12/5/2024, we discussed what CSS does in
some analogous situations, and it appears that the last applicable rule is
used. Maybe this is a precedent to follow for which intent property gets to
apply in conflicting cases.

Example: plus:infix:prefix will have :prefix be the applicable/active
property.

*ACTION* NS: There are several more things to resolve in issue 449.

*ACTION* People should read this issue for the next meeting.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0--a-href-https-github-com-w3c-mathml-issues-473-473-core-concepts-how-should-the-multiple-forms-of-differentiation-be-handled-a->#473:
core concepts: how should the multiple forms of differentiation be handled?
<https://github.com/w3c/mathml/issues/473>

(don't see a resolution)

DG wrote: The WG discussed this issue during the meeting on 12/5/2024. We
had consensus that we speak the notations as written, without any Intent
annotations. We will leave it to people to come up with intents in Open
that potentially might migrate to Core if they turn out to be productive
and widely adopted, in a future version of the Core list.

DG closed issue 473.

*ACTION* Next week, NS wants to talk about the "legacy, common, and
literal" ways to speak intents.

*ACTION* NS: several issues need to be moved to core.

*ACTION* Let NS know if you have agenda items.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

   - doc updates/completed action items

MuS suggested restarting the MathML 2 effort to have a JavaScript library
to help with MathML. He has some scripts to help with MathML working with
XML.

NS: Polyfills help fill the gap between full and core.

MuS: The polyfills would be in the library. Library functions could be used
to eliminate superfluous mrows which make navigating the DOM difficult.
JavaScript functions can be used to eliminate row and column attributes.

MuS: JavaScript uses UTF16. You can write scripts to give you the UTF32
value of a higher plane character.

MuS: JavaScript, Windows, and Office uses UTF16.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0-2-any-further-thoughts-on-priorities-or-things-that-need-to-be-done->2.
Any further thoughts on priorities or things that need to be done?

BM spoke about a DF idea that when we speak an expression, that we speak
its full description the first time we speak it, and give it a terse
pronunciation the rest of the time we speak it.

NS: We could have the AT do this. Intent does not currently allow an author
to do this.

BM: It is important, but it is not clear how to make intent do this. The
intents would get excessively big to implement this.

NS: We could have an "intent", then an "intent-after" to say how it should
be pronounced after the first time it was spoken. The intent would grow in
size. Maybe this could be done with a property.

MuS: The Office applications can give a terse pronunciation after the first
time something is spoken.

MuS says this is related to the issue that character navigation is
different from speech navigation.

NS says you get quite a different experience, using MathCAT, for character
navigation when intents are present. For example, in character navigation,
you would hear the word "determinant" instead of hearing "vertical bars"
when intents are present.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-0-3-mathml-4-issues->3.
MathML 4 issues:
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-1--a-href-https-github-com-w3c-mathml-issues-181-181-mathml-4-extensions-for-alignment-and-possible-deprecation-of-maligngroup-and-malignmark-a->#181:
MathML 4 extensions for alignment and possible deprecation of
(maligngroup/) and (malignmark/) <https://github.com/w3c/mathml/issues/181>

NS: With just a little CSS and a polyfill, you can duplicate the function
of maligngroup and malignmark by adding padding to either sides of a
character.

DG thought that tall expressions may not be able to be aligned using this
method. He made an example involving a complex fraction, and it aligned.

NS: Maligngroup and malignmark are not in core and take a lot of MathML 4
spec text to describe their function. Eliminating maligngroup and
malignmark will simplify the spec.

NS: They have never been implemented by browsers. MathJax does not support
them.

NS Let us have MathML 4 aligned with reality.

NS The maligngroup and malignmark descriptions take about four pages. The
examples are folded; therefore, the descriptions are really larger than
four pages.

NS is unclear, about maligngroup and malignmark, on what happens outside of
the web.

MuS: They do work with Word, the Microsoft apps, and PowerPoint.

MuS: Because it has never been supported on the web, it could be considered
a long-term bug. However, it is a direct mirror of what TeX does, so it is
not so extraordinary and has worked with Microsoft applications.

*ACTION* MuS will try to shorten the descriptions of maligngroup and
malignmark in the spec.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-1--a-href-https-github-com-w3c-mathml-issues-434-434-language-variations-as-separate-intents-a->#434:
language variations as separate intents
<https://github.com/w3c/mathml/issues/434>

(close?)

PL brought this up.

NS: Do we support different languages with intent? There was a discussion
of the use of gender in different languages. Should intent support this?

DG: Let us not worry about other languages and handle these situations with
literals.

NS: We can let the AT handle language translation issues.

DG wrote: The WG meeting today, 12/5/2024, had consensus that these
questions are in AT's court and the spec can remain silent for the moment.

DG closed issue 434.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-1--a-href-https-github-com-w3c-mathml-issues-448-448-what-39-s-in-a-name-also-quot-reference-quot-etc-a->#448:
What's in a name (also "reference", etc.)?
<https://github.com/w3c/mathml/issues/448>

(close?)

NS: What literals belong in a concept name.

NS: We have a grammar, and we know what is allowed for intents.

closed
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-1--a-href-https-github-com-w3c-mathml-issues-449-449-intent-properties-ordering-amp-references-a->#449:
Intent Properties: ordering & references
<https://github.com/w3c/mathml/issues/449>

(hard/long one)

NS: The ordering of properties was resolved.

NS: If you have a list of properties, does the first property take
precedence, or does the last property take precedence?

DG: I have a very generic thought of it would be nice if this follows the
same intuition as CSS selectors, but I'm not sure what that actually is.

NS to BB: Which ordering happens for CSS selectors?

BB: There are two rules. One is the specificity so the longer the selector
the more specific it is and the longest gets precedence. If they are at
equal lengths, then it's the last one.

NS: I guess that maybe attributes might be another one if you listed more
than one attribute, and there were two that were the same, Do you know if
it's the first attribute that's used or the last one?

NS: If you had display and you set it to block and then you had display
again and set it to inline, which one would win the block, the first or the
second?

BB: Oh, in that case, again, it's the last one.

NS to DG: Put in a comment to use the last one for ordering properties.

DG wrote: In the WG meeting on 12/5/2024, we discussed what CSS does in
some analogous situations, and it appears that the last applicable rule is
used. Maybe this is a precedent to follow for which intent property gets to
apply in conflicting cases.

Example: plus:infix:prefix will have :prefix be the applicable/active
property.

*ACTION* NS: There are several more things to resolve in issue 449.

*ACTION* People should read this issue for the next meeting.

DG put in "needs spec update".
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.1#cp-md-1--a-href-https-github-com-w3c-mathml-issues-473-473-core-concepts-how-should-the-multiple-forms-of-differentiation-be-handled-a->#473:
core concepts: how should the multiple forms of differentiation be handled?
<https://github.com/w3c/mathml/issues/473>

(don't see a resolution)

NS: We have different differentiation symbols plus higher order derivatives.

LM: I thought we agreed to read what is there.

Mus: In my application (
https://murrayiii.github.io/UnicodeMathML/playground/) I have more elegant
intense. It did take a certain amount of JavaScript to go parse the tree,
But it does do things like second derivative of u with respect to x.

Mus: I think in terms of verbosity, it's not that much more verbose. And I
have a feeling that if you're giving a lecture, you probably would say it
that way rather than D squared u over dx squared. To say D squared u over
dx squared is just about the same as saying second derivative of u with
respect to x.

LM: Can your application speak higher order derivatives?

MuS: Yes.

NS: Murray, did you have a list of the different ones or you just
internally do your work and come up with it?

MuS Does not talk about all the separate notations. He does the Leibniz and
Euler descriptions.

DG: This would be one of the first, if not the first, open list
contributions if we don't include it, exactly because people like Murray
would implement something using derivative or partial derivative.

Mus is ok with not putting them in core, but can put them in open.

NS: Read the derivatives as they are written and put the high-quality
speech in open.

DG wrote: The WG discussed this issue during the meeting on 12/5/2024. We
had consensus that we speak the notations as written, without any Intent
annotations. We will leave it to people to come up with intents in Open
that potentially might migrate to Core if they turn out to be productive
and widely adopted, in a future version of the Core list.

DG closed issue 473.

*ACTION* Next week, NS wants to talk about the "legacy, common, and
literal" ways to speak intents.

*ACTION* NS: several issues need to be moved to core.

*ACTION* Let NS know if you have agenda items.