Minutes: MathML Full meeting 27 April, 2023

Apologies for the late minutes or repeat -- I thought I sent these out over
the weekend but I don't see a record of them.Attendees:

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

<https://sandbox.cryptpad.info/code/inner.html?ver=5.3.0-rc1#cp-md-0-regrets>
Regrets
<https://sandbox.cryptpad.info/code/inner.html?ver=5.3.0-rc1#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=5.3.0-rc1#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

NS: sent the charter to BB who will forward the charter to the appropriate
W3C people. There is a one-month period for people to say yes or no, and to
raise objections to the charter.

NS: Did not think there would be a problem with the charter extension while
the new charter is being approved.

MUS: I've been playing with something that's I think is kind of
interesting. A guy named Noah Doersino has done an interesting master's
thesis in which he converts Unicode math into MathML, and he does it with a
parsing expression grammar (PEG). MUS uses JavaScript on this project. PEG
was introduced in 2005. repo: https://github.com/doersino/UnicodeMathML

MUS: Can do an intent implementation using this approach.

MUS: It seems like a really powerful technique of converting one kind of
format to another. This technique could turn out content MathML as well as
presentation MathML.

DG: has heard of PEG.

NS: Used PEG in his MathCAT work.

NS: I found that there are some chemistry symbols missing from Unicode.
Murray has been working with me to get them into Unicode.

NS: What is the status of that effort.

MUS: They want a more user-friendly introduction than just getting the
formal proposal. So, I'm happy to do that.

MUS: The changes will not go out on the next Unicode version, but in the
version after that.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.3.0-rc1#cp-md-0-2-closing-intent-issues->2.
Closing intent issues?
<https://sandbox.cryptpad.info/code/inner.html?ver=5.3.0-rc1#cp-md-0--a-href-https-github-com-w3c-mathml-issues-q-is-3aissue-is-3aopen-label-3aintent-list-of-open-issues-a->List
of open issues
<https://github.com/w3c/mathml/issues?q=is%3Aissue+is%3Aopen+label%3Aintent>
<https://sandbox.cryptpad.info/code/inner.html?ver=5.3.0-rc1#cp-md-0-discussion-done-421-moritz-433>Discussion
done? #421 (Moritz?), #433

Issue 421 and 433

It is about whether we are going to have a list of examples showing how to
go from MathML 3 to MathML 4 with intent.

DC: Isn't this about defaults?

NS: No.

PL: thought DG said if we give any examples, that we are implying
completeness, and specifying the rules used to write MathML with intent.

DC: is not sure anyone will write the examples.

DG: We do not want to mislead people. We can show contradictory examples
next to one another. For example, show powers and superscripts. A
superscript can be a named variable or derivative.

NS: Sometimes AT will try to guess. A capital letter can imply the variable
is a matrix, thus vertical bars can indicate a determinant instead of an
absolute value.

DC: has a table of examples. They are just examples not rules.

DC: If you give examples, they may be understood as defaults. We should
stay clear of this.

We are not in a good position to show defaults.

PL: Why not just show examples. These are not defaults.

DC: It is hard to specify rules.

BM: Examples are good.

NS: could see adding examples at the head of the intent session. does not
want to add pages of examples.

PL: It would be better to put the examples at the end of the chapter.

NS: proposes putting the examples at the beginning of the chapter to
motivate the reader.

NS: Should the examples go in the spec, or in a separate document?

PL: I'm proposing that the examples go in a spec, because the spec has this
advantage of being a reference that everyone can talk about.

Keep issue 433 open.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.3.0-rc1#cp-md-0-language-related-425-434->Language-related:
#425, #434,
<https://sandbox.cryptpad.info/code/inner.html?ver=5.3.0-rc1#cp-md-0-these-may-be-pending-small-clarifications-examples-in-the-spec-text-441-454>These
may be pending (small?) clarifications/examples in the spec text: #441, #454

Issue 441 using color and diagrams to help demonstrate mathematics. How do
we show this to a blind user.

You must link the colors and diagrams to explanations in the text.

LM: You can get screen readers to tell you the attributes of a line
including color.

DG: I think we actually had a resolution for the issue in the discussion,
which is, we shouldn't expect that the style should be spoken by AT, and
that you would have to add an intent notation to mark that it's important
for accessibility. If it's a variable, you can say red X for the name of
the variable and kind of the reason why I think this is staying open is
that it would be nice to have a sentence or 2 in the spec that just
measures style and accessibility, and says for style, if it's important to
be conveyed, put something, and maybe put one example with the red X or
something.

*ACTION* NS: Okay, can you add what you basically just said to that issue
after the call? And hopefully, then we can mark it with a spec label, and
then we can resolve it.

DG: Yes.

SD: For this example, the purpose of the colors is simply to link to some
existing text in the description.

SD: So perhaps, for this example, something that allows us to treat this as
if it were almost like an aria-long description, or something like that,
would provide the necessary information, for AT to be able to read this
color information without actually needing to know the colors themselves.
Does that help us out here, or is the issue that we're trying to deal with
more general than that?

NS: I think it's more general.

NS: There is a long sentence which is almost the intent of the expression.

DG: will write a conclusion for this issue.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.3.0-rc1#cp-md-0-conflicting-intents-and-conflicting-properties-439-449>Conflicting
intents and conflicting properties: #439, #449
<https://sandbox.cryptpad.info/code/inner.html?ver=5.3.0-rc1#cp-md-0-popovers-and-screen-readers-465>Popovers
and screen readers: #465

DF: If he knew how a decorated variable, like F^, would be spoken by
default, then he would know if he needed to use intent to correct the AT
speech. F^ can be pronounced F hat. Often it is the Fourier transform of F,
but not always.

DF: It would be good to put a property on it so that it is known to be a
Fourier Transform.

MUS: It would be good to know the defaults.

NS: has proposed defaults which were not completely accepted.

NS: I hope we have some defaults, and that they get mentioned somewhere. I
also hope that there's a way to have no defaults, which is what I think DG
wants.

NS: Also wanted to talk about popovers.

NS: As you mouse over the expression, it could pop up something that shows
all the properties of it.

LM: believes that Popovers should be called mouse overs. The NVDA command
to read "on mouse over" is NVDA+control+m. The JAWS command to read "On
Mouse Over" is control + JAWS + enter.

NS: Can you read "on mouse overs" in iOS Safari?

LM: I do not know.

NS: Thought that a browser extension could make mouse overs readable.

BM: Question: What does AT do with something like "F^"? Should it be
pronounced "F caret", or "caret over F?

DF: wants to hear "F caret".

NS: For all these characters should just speak the characters. proposal to
say F Caret" and not say "caret over "F".

NS: believed there should be a way to make sure that the system would
always say "caret over F" which would describe the structure of the
character. Do not use the description defaults.

NS: We will talk about defaults in the future.

NS: believed that defaults were discussed in another issue.

*ACTION:* DF will find the other issue dealing with defaults, and add
something to it, then close issue 465.

BM: The second issue, when should it say ""F Fourier Transform" or say the
Fourier transform of F"? When should it use the short or long description
of the decorated character. This has not been decided upon.

BM: It's easy to fall down a hole where you've got so many complicated
things that you're trying to specify that the spec is unusable.

NS: Asked PL to see if BM's question had an issue assigned to it. ** LM: I
thought that DF was supposed to look for an issue discussing when to use
short or long descriptions of characters.

NS: Should we reopen a new issue?

DC: thought the issue was closed.

DG: Does this tie into the comments we heard from the accessibility vendors
the other week, about the clear speak versus mass speak versus the other
styles on how that interacts with intent because they determine often the
style of pronunciation, whether it's longer short or other considerations
involved with the specific listener or reader, that you may have, so
wouldn't that be better delegated to the style of speech rather than the
intent?

NS: When someone gives an intent, do you use the given intent, or would you
use the long form the first time the character appears, and use the short
form description for the rest of the occurrences of the character?

NS: If you give an intent, you're telling the system that you know
information that the AT otherwise doesn't have, and the AT should use the
given intent.

BM: The choices of what to do with each particular instance should be left
to the AT, but the AT does at least need to have the information of what
the options are.

NS: The AT needs as much information as possible.

NS: It would be better for the author to say, here's a short form and a
long form, if that's what they want to do, and I'm not sure how we can
manage that with the current intent syntax properties.

We then had a discussion of how to specify local and global information
with intent. The result was that the current intent grammar could specify
local things, but not global things.

DG: Should this be done with CSS?

NS: So, you're saying, we're going to have sheets of defaults, and there'll
be a kind of a global default that AT may or may not use.

NS: But what if an author wants to specify the long and short ways to
pronounce things, and the author's choices are not on the default sheets.

BM: The author should supply style sheets saying what defaults to apply.

BM: These defaults should be out of scope until we get more experience.

NS: Allowing people to specify something locally doesn't prevent them from
having something global.

DG: The global approach is the conceptually better one.

NS: You must allow local and global options. You cannot decouple the local
and global issues.

NS: Intent is inherently local.

DG: I'm just thinking of postponing this, together with the aliasing issue,
because to me they're connected. The short names and long names and the
aliases are synonym names. To me it feels like the same bag of problems to
tackle together that's why I'm saying what I'm saying.

PL: BM says we do not currently do anything global.

*ACTION* NS: The way to resolve this is to close issue 465, and open one on
local and global names, and how they can be done with intent. We should
also label it as "MathML Next" which implies that we will think about it.

NS: There are bigger issues yet to be worked on. One of them is concept
names versus literals.

NS: would like to get to that next week.

NS: We also have the issue of defaults.

PL: wanted to talk about translating MathML to see if words changed their
gender and if they are singular or plural.

NS to PL: Do you have access to an Apple device?

PL: Yes.

NS: You could test their translation tool to see if they change things.