Minutes: MathML Full Meeting 10 October, 2024

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Patrick Ion
   - Bruce Miller
   - Paul Libbrecht
   - Deyan Ginev
   - Bert Bos

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

   - Moritz Schubotz

<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.0-3#cp-md-0-action-items>Action
Items
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.0-3#cp-md-0-core-meeting-on-monday-wpt-tests->Core
meeting on Monday (WPT tests)

BK wants to create a WPT (web protocol test) during the Monday, October 14,
meeting. NS encourages everyone to come and see how easy it is to insert a
test. If people add more tests to issues, this will improve the interop
testing environment. These tests get run on all the browsers, and the
browser developers see the results of these tests and hopefully improve
their browsers.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.0-3#cp-md-0-2-mathml-interop-items-proposals-closed-9-october->2.
MathML interop items proposals (closed 9 October)

The following two were submitted, but can be amended:

   - MathML Core rendering (issue #787)
   https://github.com/web-platform-tests/interop/issues/787
   - CSS styling for MathML Core (issue #861)
   https://github.com/web-platform-tests/interop/issues/861

*ACTION:* Give these issues a thumbs up.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.0-3#cp-md-0-3-a-href-https-github-com-w3c-mathml-issues-473-issue-core-concepts-how-should-the-multiple-forms-of-differentiation-be-handled-473-a->3.
Issue: core concepts: how should the multiple forms of differentiation be
handled? #473 <https://github.com/w3c/mathml/issues/473>

New thoughts?

*ACTION:* NS will take an action item to investigate in MathCAT what it
would be like to use a property to see if it would be simple to implement,
or there's all these cases and it's a lot of work to figure out what to say.

*ACTION:* NS: I would like help in adding to the cases in David's intent
example sheet (https://w3c.github.io/mathml-docs/intent-examples)
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.0-3#cp-md-0--a-href-https-github-com-w3c-mathml-issues-304-potential-presentation-mathml-items-to-deprecate-in-mathml-4-304-a->Potential
presentation MathML items to deprecate in MathML 4 #304
<https://github.com/w3c/mathml/issues/304>

*ACTION:* DC: Make a pull request to remove the attribute called "other".

*ACTION:* NS: If anyone has suggestions for modifying the spec, they can
either: Do a PR to add to issue 304 what your proposal is, or, if you feel
that your changes are not controversial, go ahead and submit a pr.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.0-3#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.0-3#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

We discussed Standard prefix form of derivative operators in Leibniz
notation and D-notation should be in category L to match ISO 80000-2 core
issue 256 <https://github.com/w3c/mathml-core/issues/256>

NS: It can still be a standard even if it is behind a paywall. It has been
that way for 30 years.

DC: It'd be an endless argument about which letters do whatever. J is the
Bessel function. Every letter means something to someone.

PL: So, there's many semantics. He claims, for example, that you would put
D as not an operator, but as an identifier if you use it for distance.

NS: How would a MathML generator know whether to use mo or mi with "d"?

DC: It's the same as everything else. You'd use a differential d macro and
then you'd make it make whatever you want.

DC: Originally we had "sin" as an MO and put it in the operator dictionary
and we've kind of like moved off to saying it should be an MI with an MO
with an apply operator.

   - spec updates

For Deprecate/Remove mlabeledtr #72
<https://github.com/w3c/mathml/issues/72>, DC merged his changes which
removed mlabeledtr from full.

   - Core meeting on Monday (WPT tests) BK wants to create a WPT (web
   protocol test) during the Monday, October 14, call. NS encourages everyone
   to come and see how easy it is to insert a test. If people add more tests
   to issues, this will improve the interop testing environment. These tests
   get run on all the browsers, and the browser developers see the results of
   these tests and hopefully improve their browsers.

<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.0-3#cp-md-1-2-mathml-interop-items-proposals-closed-9-october->2.
MathML interop items proposals (closed 9 October)

The following two were submitted, but can be amended:

   - MathML Core rendering (issue #787)
   https://github.com/web-platform-tests/interop/issues/787
   - CSS styling for MathML Core (issue #861)
   https://github.com/web-platform-tests/interop/issues/861

NS: We can still edit our issues which have been submitted.

DG: You cannot edit these issues directly, but you can comment on them.

*ACTION:* Give these issues a thumbs up.
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.0-3#cp-md-1-3-a-href-https-github-com-w3c-mathml-issues-473-issue-core-concepts-how-should-the-multiple-forms-of-differentiation-be-handled-473-a->3.
Issue: core concepts: how should the multiple forms of differentiation be
handled? #473 <https://github.com/w3c/mathml/issues/473>

New thoughts?

In this discussion, we used Intent Examples from MathCAT Version: 0.2.6
<https://w3c.github.io/mathml-docs/intent-examples/>

NS: The group has no strong feelings on this.

NS: People liked the terse form more than the verbose form.

NS: In MathPlayer you get verbose or terse. In the verbose reading, you get
the first derivative or second derivative of y with respect to x. And in
the terse reading, you'll get D squared y by dx squared.

DC: If you use intent, intent is what gets said.

NS: Well, except if it's in core, it's not what it gets at. It's telling
the AT, this is what it is, and you do what you want.

NS: If in core, the AT can see the intent and then the AT will decide what
to do.

NS: The intent allows the AT to do something better. The intent does not
force speech.

NS: Do we need to change something in the spec?

DG: You need at least one derivative concept in core.

NS agrees.

NS: Do we have to do something for the different syntaxes of the derivative?

DG: My point is the decision will be de facto made whether here as a group
or when the list is given an example as a speech hint.

PI: We should be as simple as possible. The use of various notations for
derivatives or styles of derivative is usually expressed in the context.
And now we're trying to somehow or other get it into the symbols in some
way by making the symbols increasingly complicated. And the other thing is
that most of the time they're all just iterates of a single derivative.

There was then a discussion of increasingly complicated expressions
involving derivatives.

NS: We could have a derivative property attached to an expression in the
form of a fraction. The AT would see the derivative property and know not
to say fraction. Also, the At would know instead of saying "over" it could
say "by" So dy over dx would be dy by dx.

PL suggested that we use two or three examples to give speech hints about
how derivatives should be spoken.

BM: I'm kind of feeling like it's useful to have a property which then
leaves it to the AT to' kind of analyze what the content is and figure out
how to specialize what it otherwise would have read as the structural
reading. So instead of saying fraction, it says derivative.

BM: I think that comes down to a choice between either coming up with some
scheme to deal with a complicated argument pattern, or alternatively we'll
have an infinite number of concepts, first derivative, second derivative,
first derivative operator, first derivative of an expression, et cetera, et
cetera.

*ACTION:* NS will take an action item to investigate in MathCAT what it
would be like to use a property to see if it would be simple to implement,
or there's all these cases and it's a lot of work to figure out what to say.

DG: Can we ask MuS to do a similar investigation?

*ACTION:* NS: I would like help in adding to the cases in David's intent
example sheet (https://w3c.github.io/mathml-docs/intent-examples)
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.0-3#cp-md-0-4-other-issues->4.
Other issues:
<https://sandbox.cryptpad.info/code/inner.html?ver=2024.9.0-3#cp-md-1--a-href-https-github-com-w3c-mathml-issues-304-potential-presentation-mathml-items-to-deprecate-in-mathml-4-304-a->Potential
presentation MathML items to deprecate in MathML 4 #304
<https://github.com/w3c/mathml/issues/304>

Consider namespace attributes for undefined behavior.

NS: We have this left over from MathML one is the attribute "other".

NS: It says here that "other" is deprecated in favor of using attributes
from other namespaces.

DC: But that doesn't work in core or in HTML at all for that matter.

DG: I have a suggestion. Use the dash attributes.

DC: Because that's inherited from core so core allows like HTML, you can
have data dash anything.

DC: Well, the simple solution is just to remove all mention of namespace
attributes and pretend they were never there and then adding them to the
change log, and say we remove them.

NS: Do we talk about that anywhere else? I guess we're going to have to
look in the spec to see whether it is used elsewhere.

DC: If you use a namespace attribute like the local dot color equals red
whether you if you wanted to access that with a JavaScript polyfill, the
name and the attribute would depend on whether you are looking in HTML or
XHTML. the local name will be different because one of them would treat it
as a namespace attribute and the other one wouldn't. So, it's just like a
whole pile of political issues you really don't want to get into.

BM: Since these cases are informative rather than Prescriptive, we're
talking about where you're intentionally stepping outside of pure MathML,
but we're trying to give advice and in that case, is it not fair to say
that if you're in an XL environment you might choose to use namespaces. If
you're in an HTML environment, you should consider data attributes.

NS: So just a quick look through the spec. We do mention namespaces in many
places, particularly annotation XML. So, it's probably if we got rid of
namespaces altogether, it would be a pretty substantial change to the spec.

NS: Yes, so it would be some more cleanup, I think, maybe needed in the
spec with respect to namespaces, but "other: can certainly go away.

DC: Do you want me to make a PR to remove all that?

*ACTION:* DC: Make a pull request to remove the attribute called "other".

*ACTION:* NS: If anyone has suggestions for modifying the spec, they can
either: Do a PR to add to issue 304 what your proposal is, or, if you feel
that your changes are not controversial, go ahead and submit a pr.

NS: Getting rid of "other" is non-controversial.

NS: We will revisit this next week.

NS: Final thought, give a thumbs up to the interop issues.