Minutes: MathML full meeting, 6 Feb, 2025

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Bert Bos
   - Murray Sargent
   - Deyan Ginev
   - Paul Libbrecht
   - Bruce Miller
   - Stephen Watt

<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-2#cp-md-0-regrets>
Regrets

   - Moritz Schubotz

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

*Action Item*: BB outlined the steps to bring the full spec to CR. We will
have to work on these matters.

*Action Item"* NS: We need the consensus statement to go to CR by the
MathML group.

*Action Item* DC: We need to get changes between the last draft and the cr.
DC will look into this.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-2#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-2#cp-md-0-3-a-href-https-github-com-w3c-mathml-issues-385-385-comments-on-chapter-3-a->3.
#385: comments on chapter 3 <https://github.com/w3c/mathml/issues/385>

(new thoughts on how to handle examples?)

No updates.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-2#cp-md-0-4-a-href-https-github-com-w3c-mathml-core-issues-279-279-core-clarify-the-language-around-deprecated-features-of-mathml-a->4
#279 (core) Clarify the language around deprecated features of MathML
<https://github.com/w3c/mathml-core/issues/279>

*Action Item* NS would like to have more people say what the MDN should say
about these parameters, and what should be done in core.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-2#cp-md-0--a-href-https-github-com-w3c-mathml-issues-523-523-missing-property-to-indicate-needed-grouping-a->#523:
Missing property to indicate needed grouping?
<https://github.com/w3c/mathml/issues/523>

*Action Item:* NS to MuS: Murray, maybe you could write an example in
Bra-ket notation or, is there any name for the 1st and the second arguments
in a Bra-ket notation? Do they have meaningful names?
Response included at the end of the minutes.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-2#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-2#cp-md-1-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

BB sent the group an email outlining the steps to bring the full
specification to CR. These steps are:

First, I (BB) need to ask for a transition, i.e., I need to ask that some
people on the W3C team (not me) verify that all requirements are met. Apart
from some information that I can just copy & paste, I still need to provide
them with the following:

   1.

   A link to minutes or to an email from a WG chair that says that the WG
   has decided to request CR status. (A mail asking for objections that did
   not get replies also does the trick.)
   2.

   A list of substantive changes since the last publication, a bit more
   readable than a raw list of GitHub commits. It could be a section in the
   spec itself, or just some text that I can put in an email.
   3.

   If requirements (e.g., those in the charter) are not satisfied, an
   explanation why. We don't have unsatisfied requirements, do we?
   4.

   A list of dependencies (normative references) that are not (Candidate)
   Recommendations or equivalent and whose future changes may affect MathML
   Core. We have some references to drafts, notably CSS drafts. I think they
   are: CSS-VALUES-4, CSS-TEXT-4, css-sizing-3, CSS- POSITION-3, CSS-FONTS-4,
   css-box-4 and css-align-3. Apart from listing them, is there anything
   noteworthy about them?
   5.

   Show that we had wide review, or at least gave people the opportunity
   for review. A link to the closed issues is probably enough.
   6.

   Show that we had horizontal review. I think these are the reviews:


   - TAG: https://github.com/w3ctag/design-reviews/issues/438- a11y:
   https://github.com/w3c/a11y-request/issues/73 (still open, but long ago)
   - i18n: https://github.com/w3c/i18n-request/issues/226 (still open, but
   all review issues are already closed)
   - Privacy: https://github.com/w3cping/privacy-request/issues/130-
   Security: https://github.com/w3c/security-request/issues/64 (still open,
   but long ago)


   6.

   Show that all issues were addressed. There are still open issues, so we
   need to close them, or explain that they don't need to be closed.
   7.

   Describe the expected process for proving that the spec can be
   implemented, i.e., our plans for testing, including an estimate of how well
   the spec is already implemented now and an estimate of the minimal time
   until Recommendation. I think our process is simply to use the Web Platform
   Tests project. I think some 90% of the tests have already succeeded. How
   much of the spec do the test cover? What shall we say for the minimal
   duration of the CR period? Three months? (This is not a promise, just an
   estimated lower bound.)

When my colleagues say the transition request meets all requirements, I can
ask for a publication. (That involves making a copy of the document with
the proper style and some other things. I probably can do that myself.)

Bert

*Action Item"* NS: We need the consensus statement to go to CR by the
MathML group.

*Action Item* DC: We need to get changes between the last draft and the cr.
DC will look into this.

PL: I think you mentioned the safe list. Is there anything else about
security we need to worry about?

BB: Another requirement for us so far is just to ask the security people
for a review. They should come up with whatever is dangerous; but, if we
know about exploits already, it would be good to mention them.

BB: For the formal requirements for us for now it's just we need to have
asked the security That's all that's being checked.

From Deyan Ginev to everyone: MathML-core #227 is still open, my CVE
mentions were here here is a link to the MathML-related CVEs on record,
currently 8: NIST national vulnerabilities database, keyword MathML
<https://github.com/w3c/mathml-core/issues/227#issuecomment-2031868032>

From Deyan Ginev to everyone: you can close it if it is completed

BB: I was looking if we had the privacy review. I don't think they did a
review, but we can argue that they had enough opportunity for that.

NS: We'll probably need to take a pass over all the core issues and close
what we can and explain why we have not closed others.

PL: We have issue 103 Proposed API: MathML, SVG support, plus localname
case-handling <https://github.com/WICG/sanitizer-api/issues/103> and 227
<https://github.com/w3c/mathml-core/issues/227>.

PL: Issue 103 is the sanitizer issue corresponding to 227 on core.

NS: I think the group pretty much agreed that whatever they needed, we just
take out of MathML because it's better to have something than nothing.

NS: When we are in CR, we can update the draft.

NS: Is there a maximum time for CR to exist?

BB: No. We must give a minimum time to generate sufficient implementations
for the spec.

BB: Issue 227 will probably not be closed.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-2#cp-md-0-2-181-mathml-4-extensions-for-alignment-and-possible-deprecation-of-maligngroup-and>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-2#cp-md-1-3-a-href-https-github-com-w3c-mathml-issues-385-385-comments-on-chapter-3-a->3.
#385: comments on chapter 3 <https://github.com/w3c/mathml/issues/385>

(new thoughts on how to handle examples?)

No updates.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-2#cp-md-1-4-a-href-https-github-com-w3c-mathml-core-issues-279-279-core-clarify-the-language-around-deprecated-features-of-mathml-a->4
#279 (core) Clarify the language around deprecated features of MathML
<https://github.com/w3c/mathml-core/issues/279>

DG and NS have commented on the 37 items that were listed in this issue for
public comment. DG was in favor of deprecating almost everything. NS wanted
to have some as presentational hints.

DC: But just to be clear, deprecated here means it doesn't mean that either
the MathML full, or core, spec will deprecate it. It means that the MDN
description will say it's deprecated.

*Action Item* NS would like to have more people say what the MDN should say
about these parameters, and what should be done in core.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.12.0-2#cp-md-1--a-href-https-github-com-w3c-mathml-issues-523-523-missing-property-to-indicate-needed-grouping-a->#523:
Missing property to indicate needed grouping?
<https://github.com/w3c/mathml/issues/523>

Summary Some intents are formed from linear notations and some from 2d
notations. That information is lost when the intent is used and so the need
to verbally group the intent (such as would be done for "fraction x plus 1
over y end fraction") is lost.

NS: With intent there's no information about should this be grouped or not
grouped.

NS: The issue is, do we need some way of telling when terms have a
beginning and ending? The proposal is to have a :fenced attribute that
says, oh, you need to say the begin and end words here because this is
coming from something that's not linear, and essentially that's not already
understood where the arguments are.

DG: The functional applications of intent imply a scope. And the argument
of those functional expressions also imply argument scopes. So a completed
functional expression in intent has all the arguments, all the scoping
information needed.

From Deyan Ginev to everyone: Example is:

intent="cross-product(plus(a,b), c)"

or

intent="cross-product($1, $2)"

DG: One of the premises of creating the functional expressions is that we
would not have to enter low level speech overrides or speech directives.
Instead, we would let the AT use the intent to make its own decisions and
make its own algorithms work well.

DG: But on the other hand, I also have another horse in the race, which is
that there is an existing mechanism that I insisted on for ARIA parity for
speech overrides which are literals. And if you really wanted to say start
and end somewhere, you could just underscore start and end.

NS: I see the difference between literal and a property is that with a
literal you are actually forcing a specific speech, whereas with the
property your enhancing.

NS: The idea being if something is simple, you don't need to do the
bracketing. So if you have this rule that If I had A over B, the numerator
and denominator are simple. Don't bother saying start fraction and end
fraction. You resolve the ambiguity because you know that you don't need
to. And if I had an (A + 1) in the numerator, Then I would have said start
fraction, and end fraction, and so that same simple speech idea would
extend to intents.

DG: We discussed this years ago when we were designing how to annotate with
the attributes, where to put the intent attributes. We have many options
because we have references. One of the conclusions we reached after many
discussions is that it's something like a best practice or At least it's
better more often than not to push down the tree, the intent attributes to
the closest scope you have to the presentational piece you're working on.

MuS: Homing in on… cross product in particular, I just want to reiterate, I
really think we should push using the Unicode code point for this purpose
And that needs no intent because it's defined as U+2A2F.

NS: Well, you don't have a name for any of the parts in the intent. I don't
know whether that's useful, but I'm getting ahead, and we should stay
focused on this problem of whether one needs to bracket it, or with their
words or not.

MuS: My algorithm for bracketing is How many children are there. If you
have more than one child, then you're going to need bracketing.

DG: I'm going to revise another couple of details about properties. One is
that we don't have a default fallback behavior. So if a concept is not
implemented by an AT, we have a default of just speak what is there, speak
it as text.

DG: The second thing I want to revise is that the core properties are an
implementation requirement for ATs. They're expected to be implemented in
some way. So every time we add a new one, The burden gets heavier. And I
also had this tongue-in-cheek thought that we should have defined the core
properties to be the ones that have two or more ATs implementing them
because they are the important ones.

NS: I have no way of knowing whether or not an expression was laid out on
one line versus it coming from something that was not on the line and
therefore was not intended to interact visually with the rest of it, in
which case it needs to be bracketed.

BM: Whether having an extra property would help I'm skeptical. It seems it
would be a lot of trouble for the author to decide when It needs to be
added or not.

BM: I didn't think that the 2D has anything to do with it. I think in your
2 examples it's a case of you're processing a reference, and in one case
perhaps, the AT can recognize. Oh, there's parenthesis already around this,
so it's as bracketed as I will ever need, and I don't need to say, begin
Foo and foo. Whereas in the second case there's no bracketing, and it
clearly has some internal structure, because it's a whole Mrow with 3
children. So possibly you would want to infer it needs to have a begin
something in something.

NS: We are at an impasse.

DG: Would you object to moving it to the next MathML version?

DG to NS: I'm also still hoping, and I would again encourage you if you're
interested to make a list of just interesting experimental MathCAT
properties that people can try and not necessarily start with core. Some of
these things could end in core eventually.

BM: That theoretically rather than go and completely reparse all the math
ml I guess where I'm ending up is feeling like The best default is to err
on the side that The reference has structure, so let's By default, assume
that there's grouping words around it.

BM: Some people are going to need a lot of extra words, and some people
will be distracted by them.

BM: Let us err on the side of clarity rather than terseness.

NS: Yeah, but it could result in an extremely verbose speech.

NS: So I will introduce the next issue of potentially adding names to each
argument. It is nice to be able to say I'm in the numerator, I'm in the
denominator.

*Action Item:* NS to MuS: Murray, maybe you could write an example in
Bra-ket notation or, is there any name for the 1st and the second arguments
in a Bra-ket notation? Do they have meaningful names?

From Copilot:

In quantum mechanics, bra-ket notation (also known as Dirac notation) is a
standard notation used to describe quantum states. It's named after Paul
Dirac, who introduced it. This notation is especially useful for dealing
with states and operators in a complex vector space (Hilbert space).

The "bra" and "ket" are two different components:

   - *Ket (|ψ⟩)*: A ket represents a vector in a Hilbert space, symbolizing
   a quantum state. For example, |ψ⟩ (read as "ket psi") denotes a specific
   state of a quantum system.
   - *Bra (⟨φ|)*: A bra is the Hermitian conjugate (complex conjugate
   transpose) of a ket. It's written as ⟨φ| (read as "bra phi").

When you put a bra and a ket together, you get:

   - *Bra-ket (⟨φ|ψ⟩)*: This represents the inner product (a complex
   number) between two states, φ and ψ. It essentially measures the "overlap"
   between these states.

Bra-ket notation is powerful because it simplifies the mathematics involved
in quantum mechanics and provides a compact and convenient way to describe
quantum states and their properties.

Here's a quick example:

   - If |ψ⟩ and |φ⟩ are two quantum states, then ⟨φ|ψ⟩ represents the
   probability amplitude of transitioning from state |ψ⟩ to state |φ⟩.

Shortly after the meeting, NS opened issue 524 Naming the arguments to
intent: new property needed? <https://github.com/w3c/mathml/issues/524>