Minutes: MathML Full meeting 1 Dec, 2022

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Moritz Schubotz
   - Steve Noble
   - Deyan Ginev
   - Bruce Miller
   - Paul Libbrecht
   - David Farmer

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

   - Cary Supalo

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

DG: The “none” attribute is being eliminated.

*ACTION* DG will do a PR for the main spec, and for the schemas.

NS: says that we might align the MathML row and column span names, for
tables, with the HTML terms.

There was a discussion about symbol sizes, and that changing a symbol size
might affect the alignment of one symbol with respect to another symbol in
a math expression.

BM: asked if this issue should be discussed in the core meetings. NS said
yes.

NS: then described the rest of the agenda and asked the other meeting
attendees what they would like to discuss.

DG: began a discussion on when we would accomplish some goals. Our charter
expires on 5/31/2023.

NS: said we will need a charter extension.

DG: said that we should concentrate on a few ideas and finish them.

DG: wants to push several major ideas into MathML 5. He wants to finish a
few things like intent. He asked once MathML 4 is completed; how soon can
we start working on MathML 5.

NS: said we can start MathML 5 work as soon as we get a charter to work on
it.

DC: If we do not have a charter for MathML 5, then we will go back to being
a working group until we make enough progress to show people that we should
have a charter.

DC: Charters are decided by the members of the W3C.

BM: Spending time as a community group before asking for an official
charter is not a bad idea. We could accomplish a lot of things without
being under the deadline of a charter.

NS: We cannot move out of CR until every MathML 4 feature has at least two
implementations.

NS: Things are vague as to what a feature is, and what an implementation is.

NS: We need two independent implementations of the features in the spec.
MathCAT is one implementation, but we need another for AT, and we may need
an authoring tool for intent.

DC: You do not have to have a graphical user interface (GUI) implementation
of everything.

DC: have two speech producing polyfills for the AT applications, one in
Chrome, and one in Firefox.

DC: We only have mathCAT on the consumer end now.

NS: The implementations do not have to be fully commercial products which
have been shipped. You can show a demo, even if no one else is using it.

MOS: is working on an implementation whose prototype will be completed by
January 24, 2023. This prototype is supporting a paper MOS is writing.

DC: Other things might use intent for other things than just speech.

NS: We will not get out of CR by May.

DG: By May we can stabilize core. If we focus on this, we can finish
something.

NS: We will ask for a one-year extension of our charter.

DC: We will do level two in the next iteration.

DC: We must stay in CR for at least three months.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.2.0-rc2#cp-md-0-2-neil-39-s-simplified-core-intent-list-suggestion-see-a-href-https-w3c-github-io-mathml-docs-minimal-intent-core-thoughts-on-mathml-core-intent-and-defaults-a->2.
Neil's simplified core intent list suggestion see Thoughts on MathML Core
Intent and Defaults <https://w3c.github.io/mathml-docs/minimal-intent-core>

BM: We should come up with a list of things that need to be finished.

NS: summarized his paper.

What Needs to be in intent Core The items that need to be in core are
concepts with the following properties:

   1. The speech differs depending on the types of the arguments.
   2. The speech differs depending on the needs of the listener.
   3. The speech isn’t covered by using an intent concept@hint and is
   otherwise a notation that should be in core.

NS: discussed examples of these three conditions.

The listener must actively tell the AT what they need.

From Deyan Ginev to Everyone: I personally prefer intent="_(open-interval,
_from, $start, _to, $end)" rather than the example Neil has.

[NS changed the example after the meeting]

DC: Speak plainly and simply and you may not need special intent
attributes. Just write what you want to say.

You want Superscripts and intervals to be in core because they do not fit
the standard patterns.

DC: Drop the hints and just say what you mean.

MOS: Our first focus is on speech. Whenever we want to do something else,
why make it more complicated than it needs to be. If we publish the first
version of intent, and three years later we want to remove something, can
we do another version of intent?

DC and NS: You cannot take things away because you will break existing
code. You can add stuff more easily.

DG: Speech is important. The underscore items must be there. We will not
depend on ARIA. He likes the underscore mechanism. Do we still care about
content?

DG: *ACTION* will write the algorithm to go into the spec. DG will contact
DC for clarification on some items.

DF: It would help me if actual, useful, examples were used.

NS: I'm suggesting that there would be 3 values of intent defaults in the
future. Taking these into account, we should have an intent-default
attribute on the math element with the following values: • legacy (default)
– AT is free to apply any heuristics they want. • structure – speak the
structure; and • common – speak the common interpretation in lower-level
math.

NS: summarized more of his paper.

NS: I think internationalization of intent names is something that will be
a hot debate topic. As it stands, what's used for a intent name or literal
is spoken as is and is not translated.

NS: That puts the onus on the speech generating software. But will a TeX
package that knows \abs{x} should use intent be able to generate
intent="absolute-value($arg)" if the document text is English and something
else if the document text is a different language?

NS: If the onus is on AT to generate a translation, then because most AT
won't go out to google translate or the like on the fly, we need to define
a list of words or intent names for which it should have a translation.

NS: encourage people to go read this paper and make comments.

DG: To get the perfect list of defaults is harder than just putting in the
intents.

NS What is the topic for next week?

DC: will not be here next week.

NS: This paper could be an appendix saying what the AT must accomplish.

PL: Internationalization will get us comments from many people who would be
motivated to contribute to this project.

NS: We have not gotten confirmation from someone knowledgeable to know if
intent works for vertical languages. Hopefully that is what we will get
from PL's survey.