Minutes: MathML Full meeting 29 Sept, 2022

Attendees:

   - Neil Soiffer
   - Louis Maher
   - Steve Noble
   - David Carlisle
   - David Farmer
   - Bert Bos
   - Bruce Miller
   - Cary Supalo
   - Paul Libbrecht
   - Murray Sargent
   - Deyan Ginev
   - Sam Dooley

Regrets Agenda1. Announcements/Updates/Progress reports

NS: The MathML Core group voted to make a candidate release (CR). Part of
this process is to guarantee not to change the specification until a
certain date so that others can review a static document. NS set December
31, 2022, as the deadline for holding the specification unchanged.

BB: said that this was a reasonable time.
NS: Need to fill out some forms for various horizontal reviews. I set a
transition request date for October 16, 2022 as that gives them a little
time for review if they want to say something.

*ACTION* BB: Will not be available next week. Let him know if something
needs to be done.
2. Brainstorming around Deyan's "isa" idea #426
<https://github.com/w3c/mathml/issues/426>

DF: presented DG's "isa" proposal.

DF: We have been saying that math notation is ambiguous. Instead, we should
say that math is overloaded: more than one function is assigned to a
symbol. An example is (m superscript t). "m" could be a matrix and "t"
could mean transpose, or "m" could be a variable and "t" is a power to
which "m" should be raised.

The cardinality of a set is the number of elements in the set. Vertical
bars can mean cardinality or absolute value.

The same notation can mean several things depending upon the subject (or
context) in which it appears.

NS: (a,b) can be a point or an interval and unfortunately types don't help
there, so intent is still needed.

NS: isa avoids the hard problem of having to classify math, but does mean
we need to make a list of known "types".

DG's proposal will avoid using subjects in MathML.

DG: For accessibility there is an area which gives accessibility
information about an expression. You can use a shortcut command to get
information on what an expression is.

DG's proposal will handle a document with many subjects.

SD: likes DG's idea. The description is more precise than using subjects.
This will help give information on overloaded symbols.

SD: How do we represent types?

DG: Intent-isa is an attribute name. if you do not have this attribute, you
could use the AT "@" sign to link a symbol to an explanation.

DG: Do we create a new attribute, or do we put something into the present
structure that will not add new attributes?

NS: Likes to use a colon to indicate a variable's type. He would like to
create more attributes.

DC: This will make the grammar slightly more complicated.

DG: There is a danger of having confusing markup.

BM: He thinks "intent arg" keeps things together. He thinks "isa" is too
generic. He wants something associated with intent.

BM: Should we bring in new attributes or complicate the current structure.
the perceived complexity of intent is an issue. If the structure of MathML
allowed you to put a description on a specific element instead of having
the description higher in the accessibility tree, your MathML would be
simpler.

DG: There is no natural intent carrier for anything that has fences. You
must go a level up in the accessibility tree or add "mrows". This makes
very large MathML code.

DG: You should put your description near the expression, and not coming
from a higher part of the tree.

DG: wants to try some simpler syntax in MathML4 and revisit the issue in
MathML5.

NS: discussed an example from chemistry which made very complex MathML
code. Can "isa" make this clearer and simpler?

*ACTION* NS: will put the chemistry example into issue 426.

DG: wants to use intent in MathML4 and see if "isa" is needed in MathML5.

BM: Looking into the future, can we do things more elegantly by using more
"mrows"?

NS: MathML5 should focus on content to make it more usable.

DG: Our current charter says we are going to collect feedback then focus on
content.

DG: suggested that using ARIA-Described-by and ARIA-description might help
us use less complicated intent grammar. If we do not want to use ARIA, then
we can use "isa".

NS: "isa" value is very concise. ARIA-description might be language
oriented with longer descriptions. aria-description is for
"telling-me-more" about the expression, where "isa" can tell the "AT" what
to say on the first pass through the description.

NS: would like to see more examples worked out. He would like to see if you
need as many "mrows".

DG: wants to try examples produced by MathJax. He will then add intent and
"isa" code to the expressions to make them clearer from an accessibility
point of view, without changing the appearance of the MathJax MathML output.

DF: will also try this.

NS: MathJax can produce more spans very similar to the "mrows" used in
MathML.

*ACTION* DG: NS should send DG a complicated formula for testing.

From Deyan Ginev to Everyone: "progressive enhancement" / "remediation" ?

From Sam Dooley to Everyone: MathML-PI for MathML presentation plus intent

NS: If you are asking for ideas from others, then make an issue.

NS: We must talk about accessibility and internationalization in the
Specification. SN has written some text on this.

NS: We will talk about our Google Sheet table which lists intent values. NS
wonders is there a better way to store this information for MathML
generation.