Minutes: MathML full meeting 18 May, 2023

*Attendees*:

* Neil Soiffer

* Louis Maher

* David Carlisle

* Sam Dooley

* David Farmer

* Moritz Schubotz

* Steve Noble

* Murray Sargent

* Jonathan Fine

* Deyan Ginev

* Paul Libbrecht





*Agenda*



*1. Announcements/Updates/Progress reports*



People introduced themselves to Jonathan Fine who then introduced himself
to the rest of the group.



Lauren Wood, who runs xml.com, has asked NS to write a current description
of MathML. The last MathML paper for xml.com was written in 2018.



From Jonathan Fine to Everyone:
https://www.xml.com/articles/2018/01/15/observations-equational-content-xml-workflows/



NS: asked if one of us would collaborate on this paper. This would be a
high-level view of MathML.



DC: Can we recycle parts of the explainer? We would have to check with
Brian Kardell to see if this was OK.



SN: offered to collaborate with NS on this paper.



**ACTION** NS will send SN information on the proposed paper.



MUS: working with Noah doersing (https://github.com/doersino/unicodemathml)
on his project. MUS wants to bring his UnicodeMath up to date with what is
shipping in Microsoft. He wants to use it as a platform to input intent.



MUS shared his screen and showed examples of how UnicodeMath works. This
system converts UnicodeMath into MathML.



MUS: discussed the absolute value case. If we knew the kind of object that
is inside the vertical bars, you would know if it should be treated as an
absolute value or a determinant.



MUS: Okay, David Farmer is really into this stuff. So therefore, I can just
look at what he has done, and I will get the answers.



DF says his system is a little easier for the authors. DF showed a case
where he did not need a backslash nor parentheses around his arguments.



JF: MUS says it would be nice to know you can do things if you know the
kind of object in the vertical bars.



JF: What does your software give for ^2He (an isotope of Helium). The
answer is a prescript, which is the right thing.



NS asked DF to someday give a demonstration of DF's system.



JF: Lots of software today used Martin-Lof type theory to know the kind of
an object. It is what the LEAN theorem prover uses.



JF: (n choose m) is a special case of multinomial coefficients. The special
case is a binary operator, but the general case is not.



MOS: I just had an idea to use the domain attribute.



MOS: We could allow, in addition to intent, a domain attribute for
presentation.



NS: The idea has been that you would just use the property like "real".



NS: We have not formalized what the properties are.



NS: We do not have to keep introducing more attributes, and that mixes well
with intent.



MOS: So, I would suggest using the already existing attribute in intent
which we can use on content elements.



*2. Defaults ([comment thread starting here on #433
<https://github.com/w3c/mathml/issues/433#issuecomment-1420212046>]*



NS writes:

I strongly feel there needs to be a math level (or higher) attribute that
controls defaulting behavior so that legacy documents can be interpreted
with the knowledge that the authors were not able to make use of intent
(hence, AT can infer whatever it feels is appropriate). I proposed an
attribute intent-default  with the following values:

• legacy (default) -- AT is free to apply any heuristics they want

• structure -- speak the structure, and

• common -- speak the common interpretation in lower-level math.

Note: in all cases, if intent is given, it should be used (if appropriate).
Even for legacy, remediation may have added an intent value.



NS: We could either say, you know, feel free to speak whatever you want, or
we can say here is the recommendation of what to say in each of these cases.



NS: The overall point here is, I would like to have something that authors
can count on, and that AT can implement, rather than saying, well, you
know, there is nothing out there, and you can do whatever you want.



MUS: thinks this is cool.



DG: The effect is cool but how are these things specified?



DG: How do you change between common, legacy,  and structural?



NS: There was an intent-default attribute.



DG: You go to a math formula, and specify the intent-default attribute on
top

of the method.



NS: It would be good to have the intent-default attribute specified on the
document level.



DG: We do not need a new attribute. You can device a default series of
properties where the default:  common, structure, and legacy being core
properties.



DC: The speech is generated by NS's MathCAT software.



DC: So, this shows the first cost is changing the defaults which are, I
think, the common ones.



DF: I like this. I like the clarity it gives. I hope we do not get
distracted by having long conversations about exactly what the defaults are.



DF: Does this open the door so that I can declare a  subject instead of
saying common?



DF: Can I say this is linear algebra, so that vertical bars mean
determinant instead of absolute value?



DC: We have chemistry examples.



DC: They are not concept names. They need to be read  as they are.



DC: The default behavior of any property you make up is that it is ignored.



NS: For JF's benefit, if the intent is given, for example absolute value,
then the AT reads absolute value even if the AT does not know what AT is.
Without the intent, the AT does not know what to say. It is not
self-voicing.



DG: Actually, I think,  they are self-voicing, but behavior requires
specification. So, we do not have automatically formable behavior. Speaking
them is fine.



DG: I wanted to see if we still have agreement on the defaults. So, there
is this understanding that we currently have a lot of mathematics out there
on the web: billions of formulas, maybe more, and they must be treated some
way by AT without anything having to be specified on top of the expressions.



DG: NS and I had an understanding that the legacy defaults would be what is
used when nothing else is specified which by extension means I must add an
archive every single formula.



DG: Is that correct?



NS: Yes.



NS: It could be left to the user to say, I want it to be read structurally,
or read by using common defaults. It would be up to the user to switch
speech modes when the content changes.



NS: So, it is better for the content to say it, that is, the author
specifies how it should be read, instead of the listener deciding when the
speech style should be changed.



DG: I have a follow-up question to this, which is, doesn't this mean that
the default being legacy, still allows the wild West for all the
mathematics currently out there?



NS: Yes.



PL: I want to consider the basic idea to bring up style sheets for
particular subjects to define the behavior for specific domains. He does
not think we can do this for this version of MathML, but we can make a
start on this procedure.



NS: originally proposed a subject attribute. dg's property idea was more
powerful.



NS: It gets very messy to try to give a subject area because often subject
areas would overlap in the same document.



JF: I am really focusing on the defaults that match the common cases in
k-14 math.



JF: A k-14 student would like a crib sheet containing the list of symbols
used in this type of document. The K-14 student would like to share the
crib sheet with the sighted students at school So that he can relate what
he hears to what they see, and there's some sort of harmony between the way
in which they speak About their mathematics to him, and the way the
computer speaks to him.



JF: What I am saying is that in a school setting sighted students would
like to know how the stuff that is visually displayed in a particular way
is spoken to the blind person.



JF: As a teacher, I would very much like to know if the material I am
presenting, which might be coming from an external supplier such as
Pearson, if that material will voice itself properly for my K 14 students.



NS: So, what is appropriate for your blind student might not be appropriate
for your dyslexic student or low vision student, or some other disability.



NS: Around 2008, SN and NS participated in a study to see how MathPlayer
should verbalize mathematics. Different instructors had different ideas of
how things should be spoken. An example of this is should the AT say left
parenthesis and right parenthesis, or open parenthesis and close
parenthesis.



NS: There's not one way that is right for every student, because every
student has unique needs.



JF is in favor of diversity and uniformity. He is unsure how to satisfy
both needs.



NS: The AT also may use regional dialects.



JF: Regional dialects can be thought of as different languages.



JF: It would be nice to be able to evaluate a document to see if it met the
k-14 style.



PL: Mathematicians would not want to be limited to a k-14 style.



DF: If you are producing educational materials for the US, you must meet
required standards.



NS: Next week, we will try and see if there is some vote we can take about
defaults. If you do not like some of the defaults I proposed, please say
so. If you do not like the whole notion of defaults, please say so.



NS: I want to consider properties and discuss some of those, because,
unlike the intent names , I need to implement them If they are going to do
anything.



NS: wants to write some more implementations.



NS: I want to give a heads up because I am going to be taking a vacation in
Europe in the week after this next meeting, so somebody else will need to
be the meeting chair unless everyone also wants a vacation.



NS: We'll try hopefully and focus on a vote on this and see if people can
produce some properties that are important and useful.



DC will put a properties link in the minutes.



*3. What properties (and intent names) should be in core?*



DC: https://w3c.github.io/mathml-docs/intent-core-properties/