Minutes: MathML Meeting 9 Jan, 2024

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Bruce Miller
   - Murray Sargent
   - Paul Libbrecht
   - Bert Bos

<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-regrets>
Regrets
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-action-items>Action
Items
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

The Monday, January 13, 2025, Math WG Core meeting has been canceled. The
next Core meeting, scheduled for January 27, 2025, will be scheduled to
last 1.5 hours.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-2-a-href-https-github-com-w3c-mathml-issues-181-181-mathml-4-extensions-for-alignment-and-possible-deprecation-of-maligngroup-and-malignmark-a->2.
#181: MathML 4 extensions for alignment and possible deprecation of
(maligngroup/) and (malignmark/) <https://github.com/w3c/mathml/issues/181>

(updates?)

No updates.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-3-a-href-https-github-com-w3c-mathml-issues-482-482-intent-for-large-operators-a->3.
#482: Intent for large operators <https://github.com/w3c/mathml/issues/482>

(new thoughts on the property name?)

NS: We will leave issue 482 open.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-4-a-href-https-github-com-w3c-mathml-issues-469-469-svg-mathml-interop-for-accessibility-a->4.
#469: SVG + MathML interop for accessibility
<https://github.com/w3c/mathml/issues/469>

*ACTION:* DC will write a comment to look for arguments in nested math.

NS: We will bring this up later.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-5-a-href-https-github-com-w3c-mathml-issues-433-433-comment-include-or-not-a-sample-set-of-default-conversion-from-plain-mathml-to-mathml-with-intent-a->5.
#433 (comment) include (or not) a sample-set of default conversion from
plain-MathML to MathML-with-intent
<https://github.com/w3c/mathml/issues/433>

(discuss need for "Common" for "intent-default")

NS: This discussion will be continued.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

The Monday, January 13, 2025, Math WG Core meeting has been canceled. The
next Core meeting, scheduled for January 27, 2025, will be scheduled to
last 1.5 hours.

DG: I made a pull request in MathML-docs fixing a Unicode speech entry. It
is here: https://github.com/w3c/mathml-docs/pull/77

DG: This pull request led to the question; what is the intended coverage of
that list.

DC wrote: PDF latex tagging
https://latex3.github.io/tagging-project/documentation/prototype-usage-instructions
You can get fully tagged PDF with MathML out of that.

DC: I have been working quite a bit over Christmas on PDF accessibility
stuff, So I just thought I'll show people the code state of latex automatic
tagging since it had MathML in it.

DC: So it generates Pdf, as usual Latex. But it also tags, Pdfs of the
whole structures there. So the new thing, as of a Christmas break is, we
now have a for any Pdf. Whether it's made by Latex or not. We've got a tech
lua based thing that outputs the tagging tree.

NS: Will this method create intent?

DC: Eventually it will.

MuS: In my UnicodeMathML implementation I had backslash abs for a while,
and then I decided, that's really kind of wordy. So I took it out. So my
current algorithm is basically Of course, if it's If you have vertical bars
around a matrix, I'm going to call it a determinant. If you have vertical
bars around anything else, I'm going to call it absolute value unless you
specify cardinality.

NS: What happens if someone has "M" as a matrix and they want its
determinant?

MuS: They will have to put in an intent.

NS: So there are cases where you will need intent.

Mus: Oh, yes, I agree, you may need to put in intents in but by having
reasonable defaults, by you can save an awful lot of effort on the part of
content creators and programmers.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-2-a-href-https-github-com-w3c-mathml-issues-181-181-mathml-4-extensions-for-alignment-and-possible-deprecation-of-maligngroup-and-malignmark-a->2.
#181: MathML 4 extensions for alignment and possible deprecation of
(maligngroup/) and (malignmark/) <https://github.com/w3c/mathml/issues/181>

(updates?)

No updates.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-3-a-href-https-github-com-w3c-mathml-issues-482-482-intent-for-large-operators-a->3.
#482: Intent for large operators <https://github.com/w3c/mathml/issues/482>

(new thoughts on the property name?)

NS: We are still looking for a better name than largeop.

MuS: Call it nary.

DG wants to call it indexed for index notation because the idea is that we
are explaining what the property will do to the speech or to the accessible
outcome. It would speak scripts as if they're indices.

DG: I have a citation in the thread of a published paper that calls it
index notation. So it's not me that invented it.

DC: Indexed is good if you have a countable index. It is less good for
integrating over a domain.

NS: We will leave issue 482 open.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-4-a-href-https-github-com-w3c-mathml-issues-469-469-svg-mathml-interop-for-accessibility-a->4.
#469: SVG + MathML interop for accessibility
<https://github.com/w3c/mathml/issues/469>

DG: Showed a math expression that starts with the identifier A, then it has
an MText which contains an SVG element, and that draws the zigzagging arrow
to the right. In the middle of that SVG diagram you have a foreign object
which opens a nested math element. This is still inside the outer math
element, and that has a little expression explaining the operation that the
arrow carries. On the other side of the arrow you have a little identifier
B, so the point of the example is, you can nest Math and SVG both ways, so
you can have one inside the other in both directions.

DG: My desire would be to be able to say references in intent could go down
through SVG into nested math expressions, or something like that that would
be nice. But it's also just asking the general question, how should the 2
interoperate.

PL: You cannot plan for everything someone can do with SVG.

DG: So to also expand on a MathML core perspective, here, if you take a 1
platform view of HTML, MathML SVG, you have sufficient access accessible
descriptions available with aria, and also with the description elements in
SVG Or title attributes. So the main question is, do we want them to be
able to anchor into each other, or reference into each other and then you
just delegate to whichever piece of the accessible stack is dealing with
that markup language?

DG: Another idea is to just say, shouldn't intend to be a global HTML
attribute, because it's the one thing that has a tree structure. So you
could just supplement aria with an intent attribute that goes on any
possible element.

NS: I like intent being a global attribute.

NS to BB is this possible?

BB: Yes, sounds difficult indeed. But what do you mean? How global do you
want it to be?

DG: As global as html.

BB: So maybe it is actually implementable because most of the people don't
have to do anything with it.

NS: This is something we should consider but not in MathML 4. Tag it with
MathML next.

BM: I hate to point out that a global accessibility set of attributes
already exists, and this is kind of the moral equivalent of aria growing to
accommodate the needs of Math.

BM: The likelihood of adopting a new system to cover html when aria is
already there is a nonstarter.

NS: Another approach is to get intent inserted. Aria has or aria-abel.
There is a complex algorithm that computes the label, because the label
might have multiple references, and the references might have references.
And so it's a recursive tree computation that builds up an aria label.Maybe
that's something we could get into where the aria label looks at intent and
incorporates that into its algorithm. Again, I think a relatively heavy
lift, but I don't know.

NS: Put a next label on it and add the comment saying here is one way to
approach it in using arialabel.

DC: The spec should say if this will work.

From Deyan Ginev to everyone:

NS: What do we want to say for MathML4? Perhaps we say nothing. For MathML
next we consider making intent to be a global attribute.

DG: What happens when the systems delegate to each other, say if I just
leave the SVG there in the mtex? We don't specify what happens when an
intent system enters an mtext with an SVG in it that's still interoperating.

NS: The mtex has no intent on it.

NS: Yes, that's something we need to specify. Because I would say with the
current spec, then you kind of reach the end of the road.

DC: You should read that mtext the same way you'd read an entire document.
I mean, if the SVG was the entire document, you start off with the SVG with
hopes that you could read it somehow, and then eventually you'd hit the
foreign object with the math, and then you drop to the math reading.

DG: Actually what I aspire to resolve is that text delegates to some other
subsystem for the foreign thing inside it.

NS: I can do stuff with speech. I have no idea what would happen with the
braille. Braille is not ready to handle graphics inside of math. No braille
code that I know of does that.

NS: Maybe this is something to pitch to the HTML working group?

*ACTION:* DC will write a comment to look for arguments in nested math.

DC: If we wake this issue up, which has been dormant for a year and a half
or so, if anybody can have comments, then we can see if there's any kind of
consensus. But I'll definitely do something.

NS: We will bring this up later.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-1#cp-md-1-5-a-href-https-github-com-w3c-mathml-issues-433-433-comment-include-or-not-a-sample-set-of-default-conversion-from-plain-mathml-to-mathml-with-intent-a->5.
#433 (comment) include (or not) a sample-set of default conversion from
plain-MathML to MathML-with-intent
<https://github.com/w3c/mathml/issues/433>

(discuss need for "Common" for "intent-default")

NS: This item is related to our discussions of literal from the previous
meeting.

NS has suggested that we have a set of defaults that someone can apply the
common defaults or the high school defaults, or whatever we end up naming
it. I called it common.

NS: It gives authoring software something that they know. The author does
not have to use intent for these cases. An example of this is mfrac. No
intent would be needed to explain fractions in this case.

NS: This might be a problem for msup where the superscript might be -1
which might mean an inverse, or a prime might be as part of the variable,
or might be a derivative indicator.

DG: But what I'm constructively thinking of today is that, remember, there
are these vendor extensions in CSS things like property, starting with
-webkit, some frame, or something. It would be very productive to have a
math cat dash common, which MathCAT evangelizes essentially with MathML 4.
And by MathML 5, it becomes so good and so adopted that it becomes common.

From Deyan Ginev to everyone: I think I like a vendor :mathcat-common
similarly to the -webkit CSS extensions:
https://developer.mozilla.org/en-US/docs/Web/CSS/WebKit_Extensions

NS: I had an attribute called intent-default. We would add intent-default,
legacy, and structure.

DG: Well, that's a separate discussion that I have to kind of defer to
Murray's decades old fight about. I was even wondering whether we can use a
meta element from HTML to say intent defaults globally for the whole
document, because this way you would have to do it. Per formula, right?
Every single formula has an intent default, attribute.

MuS: You know, one interesting idea would be you could just have a little
script that does something slightly ugly, but namely, uses globals. The
script would be included in your web page, and that script would define
various stuff that should be applied to all the math stuff. It would just
be a global specification and so then it doesn't matter as long as the web
pages include that little script.

MuS: You could have a little JavaScript that says, Okay, there to make it
the global defaults or something like that, and then that would be a string
of information, saying, This is the way to do stuff.

PL: I had understood your description, Neil, is completely different. So we
would edit this kind of a default set as being something that implementers
would speak about to their users, for example, without any relationship to
any annotation or anything. But just as a suggestion, this is what we think
would be good at school level. This is the recommendation this is what an
author would be expecting from an AT or from an authorized system.

NS: No? Well, maybe I'm misunderstanding. But what I'm thinking is that
basically, these are the assumptions that I'm making. And the AT says, Oh,
okay, these are the assumptions you're making great. I will implement those
assumptions.

PL: It seems to me that it's not clear. I believe the interesting thing
might be to deliver one or 2 of these default suggestions, but not
necessarily define all the attributes, because web page makers and the
JavaScript writers are going to be inventing new things, and we need to let
them invent.

NS: Yes, but there has to be something that the AT knows to look at, to
know what to do with the MathML otherwise.

PL: No, if you have JavaScript running, then you don't have this need.

NS: The AT needs to get instructions from somewhere.

PL: So JavaScript is going to be changing the MathML and the intents. So
the AT will do nothing.

NS: So what you're saying is, there should be a whole JavaScript library
that takes something the author says, and converts that into intense.

PL: Yes.

DG: So just to draw a parallel, something like this exists for CSS, That
Paul is explaining, called SAS. There are actually several of them, but
it's a preprocessing language.

DG: So you could do this outside of the spec. Yes, for sure, defaults could
be a preprocessor step.

NS: This discussion will be continued.