# Minutes: MathML general meeting 30 July, 2020

• From: Neil Soiffer <soiffer@alum.mit.edu>
• Date: Thu, 30 Jul 2020 17:00:27 -0700
• Message-ID: <CAESRWkDMO-OydY2TSXRTLUwYQOyWbYBXDdypd8GUHRh9NsAw4w@mail.gmail.com>
The meeting was recorded:
https://benetech.zoom.us/rec/share/uP5lL5Hd52ZJb6fcuEH7aI5-QqPiX6a8gXUf-KILmksD9FHVeiuoN-SACovklEko

It was a very lively meeting today. Thanks to Patrick Ion for a valiant
effort trying to keep up with the note taking!

Attendees:

Neil Soiffer

David Farmer

Deyan Ginev

Sam Dooley

Louis Maher

David Carlisle

Murray Sargent

Patrick Ion

Bruce Miller

1. MathML WG Charter: comments, suggestions, etc

NS: Do please look at this charter draft and do what you think is needed; I
want to move from the gathering ideas phase to the winnowing down phase in
a week or two.

BM: Please leave it open to that for a couple of weeks; recent conferences
have left me no time to do what I’d like to and some things need to be
thought over, in my opinion.

1. deprecate fence, separator?

NS: malign and mgroup should be added to the list; I’m probably the only
implementor ever

DC: You may be the only one to have understood them!

SD: Maybe I did more on them a long time ago

NS: They’re difficult to have in Core; indeed to do at all

DC: Random alignment points in arbitrary formulas is really hard

NS: There may be things in elementary math that might extend. It’s a
natural extension of long division for number to long division of
polynomials. This requires lining of the terms in the polynomials. From
there, it’s not a big step to support more general polynomial term
alignment in systems of equations, equations. I wrote an elementary math
polyfill that works after a fashion not so badly

MS: We use maligngroup and malignmark in Office Math for arrays; you can
use phantoms perhaps; but characters have different widths ..[we had UTC
this week and it took time]

DC: Already we had to restrict these from arbitrariness in MathML1 quite a
bit for  MathML2 because of the difficulties of implementation. What
restrictions does MS do with them, if any.

MS: I need to look into that.

NS: Deprecating fence and separator are minor issues in my view

What about content MathML if semantics are powerful enough? Dump it?

MS:I gave an example of Dirac notation in physics where you really have to
say the vertical bars are separators; and I don’t see how to do it otherwise

NS:The semantics can take care of that

MS: It’s surely simpler for persons that don’t implement the semantics
handling to have what’s there now?

NS:It’s just ambiguous notation like absolute value vs. determinant already

MS: It’s the problem of stretch handling in part that’s annoying

DC: I still don’t get it  a bit of your example, Murray

BM: The author needs to say if the inner bars are fences or separators

NS: mrows are really useful for structuring;Too many editors leave them out
or just have them flat

DC: I can have 6 nested <mrow>s in extreme cases; I clear some of them later

MS: Too many mrows makes it unreadable

BM: <mrow>s make a thing that can be passed around

MS: Re maligngroup and malignmark, in OfficeMath, the equation array

exports in MathML as

<?xml version="1.0" standalone="no"?>

<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML" display="block">

<mml:mtable>

<mml:mtr>

<mml:mtd>

<mml:maligngroup/>

<mml:mn>10</mml:mn>

<mml:malignmark/>

<mml:mi>x</mml:mi>

<mml:mo>+</mml:mo>

<mml:maligngroup/>

<mml:mn>2</mml:mn>

<mml:malignmark/>

<mml:mi>y</mml:mi>

<mml:mo>=</mml:mo>

<mml:maligngroup/>

<mml:mn>5</mml:mn>

</mml:mtd>

</mml:mtr>

<mml:mtr>

<mml:mtd>

<mml:maligngroup/>

<mml:mn>3</mml:mn>

<mml:malignmark/>

<mml:mi>x</mml:mi>

<mml:mo>+</mml:mo>

<mml:maligngroup/>

<mml:mn>20</mml:mn>

<mml:malignmark/>

<mml:mi>y</mml:mi>

<mml:mo>=</mml:mo>

<mml:maligngroup/>

<mml:mn>10</mml:mn>

</mml:mtd>

</mml:mtr>

</mml:mtable>

</mml:math>

2. Continue comparison of semantics proposals    a) new work

DG: {Shares Screen} : https://dginev.github.io/tiny-mathml-a11y-demo/

Examples of Accessible Formula Narration

Depending on the data-semantic attribute value and the Javascript
associated it can be sent over to a screen reader.  Sounds and looks very
good

NS: Very good for speech; Sam?

SD: the multiple infix case handling; how does it go; 1 + 2 - 3 + 4 + 5
etc.?

NS: For this sort of example (cf. Deyan screen); there’s difference between
binary and unary operators; in speech there might be pauses; in MathPlayer
you’d get bigger pauses depending on depth, say 50ms;  details are not clear

BM: In current LaTeXML these things get accumulated as a long tail

NS: That will mess line-breaking up

DC: Why does the relation example come out flat while  +s come out nested

BM: I was fishing for what the semantics really are for relations; these
are not n-ary operators in the normal case

NS:There’s a problem that is known

…

DC:I’ve been generating C from this sort of thing; but it depends on the
target language whether you want to unwind or not; there’s a danger in
over-expanding semantics

SD: Functional notation let’s you delay the choice; ‘multirelation’ does
this; is the functional syntax not to everyone’s liking?

NS: Here the multirelation includes both operands and operators; \pm and +s
seems to give a single operator distinguished in the list and not the
others. A <  B < C < D or  A +  B +- C + D, say [see the comparison doc]

SD: You just effectively renamed mrow essentially

NS: n-ary and special place arguments would be a pain for speech rendering

BM: I don’t see there being any definitive operator on any <mrow>; parsing
into some tree is simple enough, but that’s not the same as multirelation
… ; I might have done differently for such cases

This is a case where the semantic tree and the presentation tree have very
different shapes

NS: Given semantic marking, it’s still my decision as the converter what to
do with it, say speak it according to my likes, whatever they may be.

BM: Again it’s the question of the purpose of the semantic attribute:
speech or computation

SD: Anyone using the semantic info has to make decisions as to what to do

DC: Looking at the a  < b \leq c example vs a < b < b < c (a monotonic
list, in our cases typically long)...

Monotonic lists are easy to check all the time, as we do for up to 10^6
elements; you should be able to express such semantics; multirelation and
arguments wouldn’t do;   I’d like  a #* option

PI: regex handling would be very powerful but difficult to have implemented
as well

DC: Sum isn’t a repeated binary operation; it’s a sum; developers make
demands of my generated code

SD:  …

BM: The case with all operators the same were rare; you can’t count on them

DC: They are different things; arrays of numbers have a limited number of
natural operations.

SD: For me there’s an uncomfortable aspect to combining operators and data
as arguments of a function

Do we want to impose a functional form for 1 + 2 - 3 + 4? Deyan picked one
but do we want

to fix such a thing with a semantic label (thus have a lot of slightly
different labels)?

NS: very lively discussion, but we need to move on as we are running out of
time. We will pick this up again next week.
3. Drafting a list of "known" semantics.

NS: I do want to get this done.  It likely will turn things up that need
more thought for semantics.  I suggest we start by taking the function
names of pragmatic content mathml  (except unifying the trig functions with
the apply cases)

SD: they involve apply ..

NS: OK, they aren’t special then

MS: sin you have to know to speak as “sine”

NS: you also need to know that a power with ‘2’ is spoken as “squared”.
Special case rules will always be needed.

NS: I’ll share screen …

[Discussion: PI note hiatus]

We’d have list of known things as Semantics1 and later Semamtics2 could be

DC:Iit’s the same as what happened with the MathML Operator Dictionary---as
Unicode got bigger over time; you could have the same situation (as
non-normative) here

SD: Deyan’s done a fine job outside the MathML spec

NS: The problem with data-* is it’s not passed along to the Accessibility
Tree; this came up elsewhere recently and had to be rejected as “the easy
solution” for exactly that reason

DG: Opening up to, say, Math Overflow could get us a list of hundreds of
items easily

SD: (sarcastically) David, how did that work for OpenMath?

NS: A blessed list is something you want everyone to implement; start with
500 not 5000 items, and then add 100 or so in version/level 2, then more in
level 3, etc.

BM: There are slight duplicates and you can’t tell which one

NS: Translation to other languages is often too much; opening up to get a
long list to consider is fine; then curate this down to Level 1 to be
immediately implemented and proceed from there

DG: ..

….

NS: What do we want in a list  format: Markdown, HTML; Google sheets; ..

BM: Sortable.

SD: Some indication of the provenance is needed; e,g. All Pragmatic Content
Symbols; Bruce’s dreams, …

BM: That’s the advantage of pages where we can put math

NS: Can DC generate a start of this from Chapter 4

DC: More or less, and I did so a month ago

SD: Yes you can get a basic 150 or so that way

NS: Sam?

SD: I’ll send my most recent list

DC: I’m away next week

SD: Found it

NS: I will do a Google Sheet; we clearly have more on semantics; 2 more
weeks on charter comments, then we’ll nail it down to W3C standards.  Thank
you all


Received on Friday, 31 July 2020 00:00:54 UTC