Minutes: MathML General Meeting, 6 August 2020

There was an interesting and lively discussion today. Unfortunately, we
couldn't capture all of it in the minutes. There is no recording for
today's meeting.


Attendees:

Neil Soiffer

Deyan Ginev

Sam Dooley

Louis Maher

Murray Sargent

Patrick Ion

Bruce Miller

Moritz Schubotz

Regrets: David Farmer, David Carlisle


MathML WG Charter: comments, suggestions, etc

MS: I’m happy to see the progress with Core, but I’m concerned the
semantics work is not mature enough to put into a standard.

MS: Not clear how the new standard conflicts with content MathML. We
shouldn’t have two ways to do things.

SD: Semantics is more like an upgrade path from content MathML. So it
becomes a functional replacement for content MathML 4.

NS: Could say we should eliminate Chapter 4 since it is a duplicate?

SD: There is a lot there. I’m not sure about that. The syntax is not the
important part, it is content that matters.

[discussion of how open math and content math relate]

BM: Possibly in the long run, content MathML could be deprecated, but only
if the developing attribute format becomes sufficiently expressive and
successful. I am not sure if semantics is expressive enough to get rid of
content MathML, particularly since we’re still grappling with speech vs
computation distinctions.

NS: There is strict and pragmatic content, and semantics is aimed at
pragmatic mathml.

BM: There was a lot of work in MathML 3 to show how pragmatic maps to
strict. I think people should be aiming at strict, not pragmatic.

DG: There is a research project (MathWebSearch) that uses “strict Content
MathML” to index 500 million formulas from arXiv, also some experiments
with ZBMath. It’s a huge index, but generally not online / not a production
deployment. Has a “more academic” status, well-known in the (modest) Math
Information Retrieval community.

[more discussion on the discussion of differences between strict and
pragmatic]

BM: I could see a few steps down the road deprecating pragmatic. We
shouldn’t put up barriers between the various forms (ie. pragmatic, strict
and semantic-attributes should be compatible).

MS: the ability to map to something else is what makes it so useful because
math is not fixed. It makes it easier for accessibility because there is so
much less.

[not captured]

DG: Scope depends on the application. For presentation MathML, it is if
browsers render this, we are done. For speech and other applications, what
determines what is done?

[not captured]

SD: people just care about appearance. Presentation works for them. Others
want to specify semantics. There is a sweet spot where they want both for
some common things. I think we should support all three communities.

MS: I agree that content MathML has remained very academic. It was very far
from being used.

BM: I think it is a false dichotomy (between being able to express the
simple cases simply and still handle more complex cases) that it is an all
or nothing enterprise. There is a slice of openmath that is very generic.
Coming up with a list that is short enough to find it easily and having a
complete enough list. WIth OpenMath, you spend days looking for something
and never finding the symbol…

MS: Who will be creating MathML output. Most people use TeX to create math.
That is then converted to MathML. They won’t write presentation MathML
directly. If it is generated by a program, why is it easier to generate?

SD: from experience, it is much easier to generate semantics than both
contents and presentation.

NS: it is locally generated for each construct, rather than globally
generating two trees.

PI: we are generating a new markup that might be easier to maintain, but it
is not clear that the details are as complex as before. Sam did this and
I’ll have to take his word that it is easier. I agree with Deyan that the
target audience is important.

DG: I claim that there are different representational decisions for
different applications, and we have several for Content MathML. It is
different for a11y on the web than for a notebook that wants to do
computation. Similarly there are differences between inputting TeX syntax
and using a palette-based input such as MathQuil. We should list the
applications we are aiming to facilitate, and not make claims about
applications we have not thought of yet.

NS: I agree. This should go into the charter in success criteria.

BM: We should focus on what we want to and not focus on things we aren’t
interested in.

SD: For example, I want to deal with online testing and capture enough
semantics so I can score the result.

BM: If it can do K12 and still be expandable, that’s a win-win.

MS: We need three things: presentation, accessibility, and search.

PI: That’s my list.

DG: We need to discuss intended input methods (e.g. not by hand, yes by
TeX, Office, palette widgets in javascript). We should specify that in the
spec.

Summary:

   1.

   Charter should mention goals of presentation, accessibility, and search
   2.

   Charter should mention that input needs to be supported (from at least
   TeX and WYSIWYG). Not decided is how many implementations mean that we
   succeeded.


Mid-meeting note from DG: The big problem with adoption of Content MathML
is connected to the academic approach to the spec, which wasn’t close to a
wide community of practitioners. It was indeed closer to CAS systems. We
know it wasn’t successful because no one is publishing new Content
Dictionaries. Finding a way to avoid the block that is incurred by
requiring CDs is crucial to future adoption of a content standard, in my
opinion.