Minutes: MathML meeting 8 Oct, 2020

The meeting was recorded:
https://benetech.zoom.us/rec/share/lc-isZzLdhapri6XHAGejamMKBJbwHMS999PVqKr6z4jgJCuSRvVXy8d5dnMFWVH.5mnnXlIsn6Cr-uvP
Passcode: 2n+KP4r$ (starts about 10 minutes in)

Attendees:

Neil Soiffer

Deyan Ginev

Sam Dooley

Patrick Ion

David Carlisle

Murray Sargent

David Farmer

Moritz Schubotz

Steve Noble

Louis Maher

Thanks to Patrick Ion for help with the minutes.
1. Charter

NS: Draft is at
https://mathml-refresh.github.io/charter-drafts/math-2020.html

TPAC breakout session: https://www.w3.org/wiki/TPAC/2020/SessionIdeas

  a) Discuss Moritz's concerns for the charter and adding an alternative to
Content MathML (
https://lists.w3.org/Archives/Public/public-mathml4/2020Oct/0003.html)

Moritz: We shouldn’t limit our accessibility exploration to just adding
attr to presentation MathML. People aren’t sure in Europe how to make math
accessible.

NS: In the US, the statement is “use MathML” for accessibility. Works with
almost all AT.

Moritz: People often use MathJax, but don’t know if that is ok

NS: MathJax hides the MathML, and AT finds it and uses it.

MS: Nemeth is universal -- it is language independent

NS: Most countries have their own braille codes

MS: But math is independent of the language

Moritz: Is there a drawback to saying something more general about
accessibility.

DC: I have something with that, but we have a deadline, so we have to
decide what to do. If we don’t say what we will do in the charter, then we
could end up spending the whole time arguing what we should do. We have to
add attrs, not elements because it can’t be added to HTML/Core in a shorter
timeline.

DG: You can use RDF to get similar functionality to the attrs. I did a
sample implementation.

NS: We did look at RDF earlier. I don’t remember why we rejected that
approach.

DC: We only mention attributes in couple of places, so I’m ok with making
the change.

Moritz: Returning to what people are doing in Europe are starting to return
to RDF. We want people to have tools to add intent. In the end we need to
convince someone to add something to tools to allow intent.

NS: …

DG: If you use RDFa, it will deal with search. Accessibility is more of a
problem

SD:....

Moritz: If we use RDF, we get indexing for free.

BM: We run the risk of saying CSS isn’t enough, then we run the risk of
having to play catch up. We should seriously look at that as math is
special, but maybe not that special.

BM: Is there a way to use the raw pieces of ARIA?

NS: ARIA doesn’t allow to distinguish between disabilities. If you are
blind, you want to say it one way and if you have dyslexia, you want to say
it another way.

SD: Names for mathematical objects involved with what is being presented as
a main design goal. By externalizing those we can enable a range of
applications, beyond ARIA’s scope.

Moritz: Example: The superscript is not aways a power. Hence, required
annotation to make it clear. A math-specific annotation for the website,
the screenreaders and indexing tech (not aware of math apriori) will have
to consume that, and “see nothing” by default. E.g. “Einstein notation” is
not something one can search for today. If we use more general technologies
(e.g. RDFa) not tailored to math, we will get some free support from
existing adopters (search).

Moritz: When discussing how to share research data in Germany we implicitly
expected everybody will implement every detail of that standard. Our goal
was to express as much as possible for tech that was not math aware in a
general data sense (?). We should be careful not to overlap existing
technologies, and instead use them where available, to both avoid confusion
and increase “free” adoption. Of course math *is* different from SVG and
chemistry and other content types, but there *are* commonalities in general
application domains.

NS: Agree on the tech overview. On the other hand we have tech that
generates MathML for display, which is inherently not RDF directly (it is
pres-only), and we have this tension of a format good for search, bad for
display vs a format good for display, bad for search. You need to bring
them together to make them work. You could run a separate tool on them, but
that extra information - how does it get in there? Is there a good path to
authoring for end users?

BM: If we look at ARIA and RDFa, that does not preclude an “intent”
attribute. At least in latexml, if I know what the math is that the author
is trying to write, I can generate any/all of: Content MathML, “intent”,
ARIA+RDFa, presentation MathML… They are all possible.

NS: As Moritz said, what can we do to make it easier for the tools and
authors? What can you do to make it easy to remediate documents that are
*not* annotated, to make them as accessible as possible.

NS: Chemistry, an annotation at the top-level of the math formula makes the
remediation very easy, with minimal markup. It is much harder to add RDFa,
a tool would help.

BM: Isn’t there a way to mark up the subject area in RDFa? DG: yes.

BM: Dublin core has a subject area.

NS: Maybe we have to revisit this. We have looked at it in the past, have
to look up the conversations.

BM: Inventing our own attributes won’t get google to index any details out
of the box. So whatever else we do should try to get support. RDFa would be
a big assist in searchability.

NS: If we had a tool to add RDFa over MathML, one could make a case for
remediation. Does anybody know if Google uses RDFa?

Murray: Will take a look.

DC: We just spent an hour discussing moving forward. At this point we
should do it or not do it. We should just agree to remove the attribute
language from charter.

BM: “intent” is good for certain uses, but in the charter there are places
where “semantics” is a more accurate description of the subject we are
discussing.

DG: I have a procedural issue. I don’t like that at the least few minutes
of a meeting we end up taking a vote. It is rushed and people are tired. We
should vote at the start of a meeting.

NS: The end is the logical place to take the vote, but maybe I need to stop
the discussion earlier so people don’t feel rushed. We can vote at the
start of a next meeting, but then the ideas aren’t fresh and maybe there
are new people.

NS: We are trying to work by consensus and since DG objects to taking a
vote on the charter now, we’ll do it next week. But we have deadlines and
we can’t keep discussing things. We need to make decisions and people need
to do work outside of the calls so we can have the facts/data on which to
make decisions. If new info comes to light, we can always vote and change a
decision.