Minutes: MathML Full WG 9 Mar, 2023

 Two hour meeting...
Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Bruce Miller
   - Steve Noble
   - Bert Bos
   - Patrick Ion
   - David Farmer
   - Sam Dooley
   - Deyan Ginev
   - Paul Libbrecht
   - Murray Sargent

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

NS: MUS, have you received the email I sent you over the past week? The
email concerned how to do things in Microsoft word.

MUS: Yes, I started working on it for you. Fred has done a good job trying
to figure things out from the outside. I am tempted to let him work on it
from the inside. But that might have legal problems.

MUS: Our apps begin to look like TeX.

MUS: We are doing the right thing with the open math tables, but I am not
totally sure how it works.

MUS: There is this minimum height in display mode parameter, which
apparently they're having a hard time using to get the right heights for
characters in in chromium and in web kit, and so on. It works perfectly in
Word, PowerPoint, or One Note. And my hypothesis is that that basically,
when you have something like an integral sign, or one of the integral
signs, I guess there are 8 or 9 out Then you have a bunch of glyphs with
different heights, and then, after a certain point, when it gets to be more
than 2 times the line height, maybe even 3 times the line height which we
don't really use much tech doesn't use it much either, then we go to a
Glyph assembly that consists of more than a single glyph, where you just
piece a lot of stuff together and have to make sure that when you piece it
together you don't get overlaps that will mess up true type. But the
display maybe making it darker or something. So basically, when it comes to
the integral signs, we just use the next size available.

MUS: What we ought to do is we ought to have a call, and just go through
debugging this stuff ourselves.

NS: That is a good idea.

MUS: Basically, it would be good to be able to write pros that guide people
in the right direction rather than having to reverse engineer something.

NS: So, you think the font designers basically don't understand?

DC: The spec isn't clean enough to really say what all the parameters do.

NS: The implementers don't know what to do, because the fonts don't all
agree on stuff. There is confusion among font designers and implementers.
DC agrees.

MUS: The spec should be clearer about this.

MUS: There's a person that was really super key in the original design of
our math layout program Online services. His name is Andre Bergo. Perhaps
we should reach out to him.

MUS: However, if you have access to the code, you can figure it out.

NS: But it is Microsoft code.

MUS: A lot of the design was guided by TeX. The TeX book appendix g.

NS: Another issue I wrote you about is where it looked like you weren't
using the clipboard flavors for MathML in word. It wasn't picking up the
presentation, or MathML flavors.

MUS: I will look into this.

NS: Had a notice that the community group email was going to be shut down
because of a lack of traffic.

DC: also received such notices about other groups.

NS: Also received a notice that MathML 3 now supersedes MathML 1 and 2.
This news is a decade old.

NS: wondered what was going on.

BB: There is a review of cg's to see if they are still active. The
reviewers will try to contact the heads of these CGs to see if the CGs can
be shutdown. This is a yearly event. It's just a reminder. You are not
obliged to close these groups if you get an email on this.

BB: Someone suggested that MathML 3 now superseded MathML 1 and 2. BB was
asked to republish our current state. MathML 1 and 2 are now labeled as
superseded.

[XML Entities published] (
https://www.w3.org/TR/2023/REC-xml-entity-names-20230307/)

[MathML1] (https://www.w3.org/TR/2023/SPSD-MathML-20230307/) and MathML2
<https://www.w3.org/TR/2023/SPSD-MathML2-20230307/> now labeled as
‘Superseded Recommendation’

BB: The latest publication rules involve things that are not in the xml
spec. BB is working on these changes. There is an update for xml entities
recommendation.

NS: reminder: TPAC 2023 Hybrid Meeting 11-15 September 2023

Main in-person hub:

Meliá Sevilla Hotel Calle Dr. Pedro de Castro, 1 41004 Sevilla Spain

NS: Please put this in your calendar.

BB: I think registration will not open until June.

NS: Not sure if Hybrid attendees have to pay. NS is unsure if he will go
physically.

NS: Thinks we will have a hybrid intent meeting during TPAC.

BB: You can register for just hybrid meetings. BB is not sure about the
cost. BB suggested looking at the web for the cost information.

NS: Reminder time change: The U.S. will set their clocks forward one hour
on Sunday March 12, 2023. Europe does not change this weekend. The intent
meeting will keep its usual time in U.S. time; therefore, the meeting will
occur one hour earlier in Europe.

*ACTION:* NS will include the time change and meeting length in the next
meeting notice.

NS: Sent out a request for AT providers to attend our meetings to discuss
intent. He thought that there were only three AT vendors that are doing
work on intents these days: Apple, Vispero, and SRE. So, he sent the
invitation to the Apple W3C contact that he knew. He has not heard back
from them. It has only been a day or so since he sent the invitation.

NS: I did hear back from the Vispero (JAWS) people. The guy said he would
be interested in joining a meeting, and I asked him which week he'd like to
join, and I have not heard back.

NS: The third person I contacted was Volker sorge for SRE. NS has not heard
back from him.
2. Functional vs templated speech (#443
<https://github.com/w3c/mathml/issues/443>,#444
<https://github.com/w3c/mathml/issues/444>,#445
<https://github.com/w3c/mathml/issues/445>)

NS: During the past week's email exchange, people came close to a stopping
point, and they are waiting for input.

NS: asked for a summary of the discussion.

We discussed two formats for intent. The functional format for intent is
well suited to core expressions where rules are well defined. AT can easily
reconstruct the underlying structure of a functional expression, and AT can
control the speech. The second format for intent, that we discussed, is the
template format which makes use of strings, and is useful for open MathML.
Descriptions are written in plain language, and the underlying structure is
difficult to reconstruct from the intent. In this format, the AT must read
how things are written, and the author, not the AT, controls the speech.

We discussed the advantages of using either format or using both formats.

DC: Shared his screen and started showing examples.

DC: The issue is what to put in the intent. We have added more and more
features over the years. Last week, we said intent would be a string but
within its simplest form.

DC: showed a string example with no structure.

DC: showed sup being a power.

DC showed examples with different syntaxes.

DC: It's simple to express the text you want. Just override the AT with the
text you put in. The danger is that you force the AT to throw away its
reading. The AT does not speak it the same way a visual reader would
describe things.

NS: So I was going to say that the other danger is that you're forcing the
generator to do all the special casing like the squared and the cubed.

NS: The open issues on this are: 443, 444, 445, and 446.

DC and NS: discussed the example of the fraction x squared + 1 / x squared
- 1. Without intent, how could a listener know what is in the numerator and
what is in the denominator? Strings can be really bad for accessibility.

DC: The advantage of strings is that you have full control of what is
spoken. The syntax is kind of weird. You would have lots of hints and
underscores.

DC: Thinks the template versions allow you to throw away the structure. All
of the issues 443 through 446 allow you to write arbitrary text in the
intents. You just basically write in alt text. The system speaks how you
saw it.

DG: Look at issue 444, look for "progressive". That gave him clarity. What
are we trying to add.

DG: Navigation is important. You must be able to navigate with Braille and
speech. You want fine grain navigation.

DG: discussed his punctuation. "And one of my small achievements for the
week was realizing that if you have the colon you can do both concepts and
properties with one character meaning the colon."

DG: So my final "triple" proposal is that there is just grouping with
parentheses, dollar references, and a single colon character that gives you
customs and properties.

DG was told by one of the "David"s that this does not give you full speech
control.

DC: decided that DG's syntax was simpler and preferable.

DG: discussed connecting the concept to the custom speech. He discussed the
vertical bar where you automate between speech and concepts.

DG: We have 4 options: the simple, pure, functional syntax; or the simple,
pure templating syntax;, or a complicated syntax where we have a functional
expression with templating inside, or a templating syntax that has
functional details inside.

NS: The colon is a separator. Left of the colon is where you recover the
name of something important as opposed to just text; and, to the right, are
the properties.

DC: My concern with these ones where you're basically starting with free
text and allowing you to embed the notation inside is that I don't think
people would do it.

PL: Navigating by levels is allowed if you choose the appropriate
boundaries. You could generate pauses by using nested brackets.

NS: Jaws does not use pausing and Orca does not use pausing, and I don't
know about voice over on Apple.

NS: did a study with clear-speak and tried pausing. Students wanted
delimiters to separate the parts of equations.

NS: MathCAT does have a pausing option.

MUS: worked with Narrator and found that people needed delimiters.

NS: His worry is that people who generate the speech don't think about what
it's like if you cannot see the equation.

DF: He stated two principles: One is, you put the intent as deep as you
can, and second is, you only put intent if there's ambiguity and what it
means.

DF: So we keep talking as if our audience is some guy who's going to
hand-edit the MathML. But really our audience is the people producing
programmatically the MathML.

DF: So maybe we're getting caught up too much in what some hypothetical
person hacking away will do, and we can maybe focus better on what is our
recommendations to the few people producing the code which is going to
programmatically generate MathML.

DC: show more examples. In the template version, once the author enters
intent parameters, the author takes over speech generation. It is hard to
make your own speech.

NS: There is a verbosity setting to tell the AT to add the "the". The AT
could see a core thing and speak it according to core.

DG: Program it with the templates and you get correct language. With
functions, you must worry about fixities. Functions are more complicated.
In the templates if you need to overwrite the language, you can. AT does
not need to do anything. The author can always get a good outcome. In the
core list, AT does well with functional forms. In the open list, AT knows
nothing. The template is easier. You must force the language with a
templated form. You should have both capabilities.

DC: Good speech is speech that sounds like the way you would read it.

NS is on the fence. NS thinks that GD says authors will write MathML. NS
thinks that almost no one will write MathML. Some remediators might, but
not many.

NS: More likely most MathML will be written by a software generator.

From Deyan Ginev to Everyone: \intent {free #1 algebra over #2}{#1 \langle
#2 \rangle}

DC: in the template you get to say what you want to say. With the
functional form, you have to hope the AT does what you want on the function.

DC: The template is tempting.

SD: The template version is more prescriptive of what speech the AT will
generate. The more prescriptive the intent string, the more we take control
away from screen reader preferences. By using the template string version
of intent have we taken away those choices? BM: yes.

SD: This will have a negative impact on accessibility.

DF: We are focusing too much on core.

*ACTION:* We should find things not in core and say how intent should be
put.

DF: Authors should not try to change the default ways core items are
pronounced.

SD: DG does not want to mix and match intent formats. He wants to use one
or another.

BM: So, my summary is that we come up with a functional concept-based
syntax which assumes that the AT has some idea of what these things mean
and their special ways of saying them and that generates the objection that
someone wants to be able to override the world. When we look at a syntax
that focuses on the exact speech pattern, people object that it will take
away the AT's flexibility to adapt, and so forth, and if we come up with
any of several hybrid variations, we get too ugly, too complex, too messy.
So I think that among the various issues, and including the current spec,
pretty much every possibility is explored there, and we simply need to
decide amongst ourselves what's most important and essential, and whether
the extra things are really worth the cost that they would impose. My
personal opinion is, I would go either with the functional syntax, and drop
the whole thing about underscore Magic phrases, or go with an ultra simple
template syntax that allows references and forget concepts.

BM: Go with the simplest thing that does the most important thing. And get
that out there and used. And if we find that people, either implementers or
users of the system, start wishing for the other capability, we might
consider it in the next iteration.

SD: DG does not want to mix and match intent formats. He wants to use one
or another.

DC: We fail if we have both. If it is only for a trial and you plan to get
rid of one, that is ok. You do not want to always have both.

DC: Do not call either one intent because you do not want to bias your
choice.

DC: label them intent functional and intent template.

NS: To give AT control the at must be able to recover the functional
syntax. He would have to add this to MathCAT. That would make things
uglier.

NS: If I can recover the underlying structure, I can do the correct thing.

BM: The templating syntax gives the author control.

DC: The functional form lets AT control the speech. The template string
sets the speech.

DC: We should come up with a nice simple template mechanism, but having
done it for a week, I found it to be difficult.

DG: It would make a lot of sense to me if given all the uncertainty we have
with the advanced features, the group just agrees on The intersection of
everything we like together, so the smallest possible thing we all feel
comfortable with, and the fact of syntax in its smallest form can convinced
most of us here that it's useful and nice and to go with that. Then we can
forget about the underscores in terms of making them a very important
vehicle of the spec. We can tell people to please try not to use
underscores too much, but if you really need it, it's there.

NS: In some sense I was going to propose that we could put both proposals
into the spec with a comment, saying, and this is again trying to get this
to Cr, we invite implementers to try both solutions, and we want to get
feedback on both the templated version and the functional version. Then we
look to see what implementers have tried to implement.

NS: We have DF, BM, and DG to work with the intermediate spec, and MathCAT
is the only one that's going to implement something until there's a final
spec.

NS will implement the template version in MathCAT.

DG: It seems to me that if we cannot come to an agreement today in any
realistic sense, then what you're suggesting is a great way to buy some
time. So sure.

NS: I am worried because we need to recharter and to do that and have some
credibility, we need to move the spec to CR, and to do that, we must do
something with intent.

NS: Neither Apple or JAWS is going to work on an incomplete spec.

SD: If I am representing this right, David, that you said that it feels
like that, we can't make up our minds between these 2 different ways of
approaching this, and it actually feels to me like that one way of
approaching it favors one set of stakeholders, and the other one favors
another set of stakeholders, and that is that the functional form tends to
favor deferring decisions as long as possible into the screen reader or
other AT software, and the template form tends to favor the content
Authors, imposing their expertise on what should be spoken. I think that
it's probably appropriate that either one or the other can win in different
circumstances. And so, I kind of liked Neil's proposal from that
standpoint. If there were some reasonable ways of combining both the
functional and templated forms, a way that you could tell which one was
being used without much difficulty, then that might give us a way to move
forward.

BM: But, when we do that, we tend to get the response that it's too
complicated.

NS: If I can recover core, then I can do the right thing.

BM: This is my bias, but I viewed the whole point of the templating syntax
was to get the AT to say exactly what the author wants it to say.

NS: But yeah, I do worry about people saying it's too complicated, and so
the template string is nice in that sense.

DC: If we just say the templates mean what they say, then it's much simpler.

DC: It is hard to parse the template versions.

NS: It's not the parsing but the interpretation that’s hard.

BM: If you are looking for simplicity, the simple template is simpler, but
you will have problems recovering the structure.

NS: I would like to see, maybe from BM, SD, or DG, The intent that's more
semantically oriented. So, for you guys, are you going to be able to
recover anything from this? Or is this like? Well, this is all text. I
can't do anything with this.

SD: I can recover things from the functional form, but the templated form
will be much harder.

SD: If I have a templated intent, I might try to recover those things from
the presentation markup rather than from the intense string.

NS: That is opposite of what intent is supposed to do.

SD: This is why I say that for me the functional form is what I would
prefer to see, but I can certainly understand that there is an application,
for if the author wants to come in and say I'm the expert I want to say how
this thing is going to be spoken then it's certainly going to be the case
that the template form is going to accomplish that goal.

NS: is not sympathetic with this view because of the number of errors that
MathML generators make and that N/S has to account for.

DF: says the template form is not easier. how can an author make MathML
pronounce something. it is not obvious that the functional form is harder.
He wants more actual examples. Until we try it, we do not know what is
easier.

NS: So, it sounds like I should implement something.

NS should implement something like simple templates.

DG: I suspect people will use natural language, and again, I can only
testify as one person that we need open concepts that are beyond the course
sets or the documents I care about.

DG: Okay, actually, the simple functional syntax is good enough for now.
And let's just try it and see what happens. And if we need more, we add
more next time In MathML 5.

DG: You may be working on something that AT will not support in the next
five years, then you better have the option to force your own speech.

DG: Let us solve the simple ones. archive will start remediating its
documents by the end of the year with author help. These documents are
obscure. It will be great if we're in a position to experiment with some of
what you can offer at that time.

**ACTION: NS will implement issue 446.