Minutes: MathML Full meeting, 31 Aug, 2023


   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Dennis Müller
   - Bruce Miller
   - David Farmer
   - Paul Libbrecht
   - Murray Sargent
   - Deyan Ginev
   - Bert Bos

Announcements/Updates/Progress reports

NS: There is a call for TPAC breakout sessions. This can be an opportunity
to meet with other groups on specific issues. This meeting would be
separate from our September 14, 2023, meeting.

The group decided not to schedule an additional meeting.

NS: said that DG found areas where units conflicted. Does "C" mean Celsius
or Coulomb?

NS: said that DG once proposed compass directions to be units. In this
case, would "s" mean south or seconds.

DG: The conclusion was if we want to have any sort of predictable usability
of the core properties such as coulomb unit, you will have to say what goes
in there from a presentational MathML perspective. So, you would require
documentation for the guessing of the properties if they're to be usable.

DC: Discussed the Unicode document he is working on. This documents says
what the various Unicode characters mean. DC is the editor of this document.

DC: is also working on a project that can convert LaTeX files into tagged
pdf files. Eventually these tagged pdf files can store their math in
MathML. Adobe is paying for most of this work.

BB: About the new charter: the call for review
<https://www.w3.org/mid/e58a8cb6-6d3c-6ee2-6f3a-3354b3d25da5@w3.org> was
sent to the W3C members (visible to members only).

BB: asked us to have our organizations vote for the charter. The W3C wants
to see interest in W3C projects, and having W3C members vote for charters
is how this interest is shown.
Agenda for TPAC?

Our TPAC meeting is on Thursday, September 14, 2023, for 1.5 hours. We
should do something different from our usual meeting schedule to interest
people who have not been to our meeting previously.

NS is looking for agenda topics.

MuS said he has made a lot of progress on his Unicode to MathML converter.
He would like to demonstrate his application.

MuS said his application is open source and is available for people to use.
It is on GitHub and can get intent into MathML.

NS: It might be good to have a roundup of new MathML generators.

PL: If someone from Apple comes along, then it would be worth clarifying
the discussion about the clipboard Uniform Type Identifier specified in
MathML3 which, apparently, may be a problem with the current Apple
guidelines: public.mathml, public.mathml.presentation and

*ACTION* NS said that he could ask James Craig to stop by.

PL: I do not know if he will be there.

*ACTION* NS said: PL, if you know Apple representatives, you should ask
them to attend our meeting.

NS: I have some things we could discuss during the TPAC meeting.

NS: Do we want to plan? We could layout a timeline for next year.

NS: There has been a question about MathML 5 and content MathML.

NS: A part of our new charter is to start thinking about a roadmap for
MathML 5.

NS: We would like to know peoples' implementation plans. At some point we
are going to CR, and we need to collect implementations. We need to have
ways of testing things.

DC: We are not making rapid progress with MathML 4. Talking about MathML 5
and content MathML is premature.

NS: We have been asked how content MathML will relate to intent; therefore,
discussing content MathML is not out of scope.

DM: There is lots of confusion about intent. People project their
understanding of content MathML into intent. We should clarify how they are

NS: needs an TPAC meeting agenda by the end of our next meeting.

*ACTION* We should send NS any agenda items we might have.

DG brought up issue 47 <https://github.com/w3c/mathml/issues/47> which is
to decide what to do with Content MathML. In that issue, MoS discussed the
relationship between content MathML and intent.

DG said the issue should be closed.
Progress/discussion on core concepts/properties lists

NS: was the only one who worked on PL's core concept list

NS: I took Paul's list and changed the names on several things so that they
fit the naming conventions that we have. NS also changed some of the
properties to be what he thought would be correct.

NS: had some questions about PL's list.

NS discussed "inverse" which is postfix. Does it need to be a core concept?

PL: Instead of seeing exponent minus one, it's useful to see inverse.

NS: From high school, NS remembers -1 being a procedure and not a concept.

DF: So, you want it to be called function inverse, because that's the

NS: It's a bit like the trig functions. Sine squared does not mean applying
the sine function twice.

NS: Perhaps it should be called inverse function or function inverse.

PL: I tried to stick to the content name, so that's the reason I called it

PL: The reciprocal is not the inverse.

NS: The names are by our naming convention. They should be defaultable so
that if the AT doesn't do anything it's still reasonable.

NS: In this case, saying inverse and making it post-fixed, would give you
"f" inverse.

Consensus: The resolution is to make it post fix.

NS: next discussed "piecewise".

NS: Piecewise is really kind of like a property on a table where we have
systems of equations.

NS: It'd be a property on an Mrow. It is not a concept name.

DC: Because if you make it the intent concept, you'd have to give it
arguments for each piece. That's the problem we have with all these things
where you would duplicate the entire expression into the intent.

NS: piecewise gets turned into a property.

NS next considered max and min. We do not have a method to say we have an
unlimited number of arguments. NS suggested putting "*" in the arity column
to indicate an unlimited number of arguments.

*ACTION* NS should put absolute value for 'ABS".

NS: In complex numbers, we have the real part and the imaginary part. What
do we call the "phase angle" of the complex number?

NS: In content MathML, it is called "arg".

DG: Wikipedia says it is the "arg" applied to something.

DF: I understand the principle that we want these things to be
self-pronouncing if AT doesn't know about them, but Let's not go overboard.

From Deyan Ginev to Everyone: "arg" notation documented here: (

DF: I think we should error on the side of it being clear what the meaning
is. And that's more important than it being self-pronouncing.

NS: We go with "complex arg".

NS: There's the concept name "SINE". We agreed last time that is how we
want to manage trig functions.

NS: The one I wanted to particularly bring out was "arc-sine"

DC: Why the hyphen?

NS: Just because I thought we tended to hyphenate things that were really 2
words So when you write arc-sine, Sometimes you write it as one word,
sometimes you write it as 2 words.

MuS: In German, you would never put a hyphen in there.

NS: Shall we go with one word and no hyphen?

MuS: Yes. That is how Wikipedia does it.

NS: Next considered constants and sets.

NS: In PL's list were: E, I, pi, true, and false.

NS: Infinity was also in PL's list.

NS: was dubious about infinity because its meaning is a little less defined
than constants like E and I…

NS: asked, Do we really need these things in core?

NS: wanted to remove all the constants.

DC: We have thousands of other symbols we could name.

DC: You could use the top and bottom symbol, or you could use true or false
in your expression.

MuS: Let me just bring up the subject of differential Because if you're
speaking a whole formula, you would just call it D. But if you're going
through character by character, you really should say differential D, if it
is that.

DC: I would not mind losing true, false, or infinity. Well, Pi is a bit

NS: The top and bottom symbols do not appear in K-12 material.

*ACTION* PL will open an issue about single letter core concepts. Should we
keep them?

DG convinced NS that they needed to be in the core concept list.

NS: Well, so arctan might be arctan in another language, or you might say

NS: will continue to work on the list.

NS: I have a fork.

PL: Can you merge it and continue in main so that people can see it?

NS: Yes.

NS wants others to work on the core list because it is large.

NS: The property list is the hard part.

NS: But what are the properties for the constants?

NS: Well, it's going to default to something. It defaults to function. I
kind of feel like we missed something.

DC: There may be no default property.

NS: We should see what the spec says about that.

NS: I didn't have a property that I could put down for complex numbers.

NS: Maybe we need to add a literal, which we used to call hints.

Received on Tuesday, 5 September 2023 23:57:41 UTC