- From: Neil Soiffer <soiffer@alum.mit.edu>
- Date: Thu, 30 Jul 2020 17:00:27 -0700
- To: public-mathml4@w3.org
- Message-ID: <CAESRWkDMO-OydY2TSXRTLUwYQOyWbYBXDdypd8GUHRh9NsAw4w@mail.gmail.com>
The meeting was recorded:
https://benetech.zoom.us/rec/share/uP5lL5Hd52ZJb6fcuEH7aI5-QqPiX6a8gXUf-KILmksD9FHVeiuoN-SACovklEko
(Access Password: d20jm0!$)
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
1. 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
DG: Just add another <mrow>
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
BM: I had wondered about this sort of thing and its relation to linebreaks
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
added
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