Minutes: MathML Full meeting, 17 July 2025

With Louis's return, the good minutes are back...Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Deyan Ginev
   - Moritz Schubotz
   - Paul Libbrecht
   - Bert Bos

<https://cryptpad.fr/#cp-md-0-regrets>Regrets

   - Bruce Miller
   - Murray Sargent

<https://cryptpad.fr/#cp-md-0-action-items>Action Items
<https://cryptpad.fr/#cp-md-0-3-a-href-https-github-com-w3c-mathml-issues-522-nested-math-in-token-elements-issue-522-a->3.
nested math in token elements issue 522
<https://github.com/w3c/mathml/issues/522>

*ACTION:* DC will write a PR to close nested math in token elements issue
522 <https://github.com/w3c/mathml/issues/522>.
<https://cryptpad.fr/#cp-md-0-4-a-href-https-github-com-w3c-mathml-issues-449-intent-properties-ordering-amp-references-issue-449-a->4.
Intent Properties: ordering & references · Issue #449
<https://github.com/w3c/mathml/issues/449>.

(round #2)

*ACTION:* NS: Bring Intent Properties: ordering & references · Issue #449
<https://github.com/w3c/mathml/issues/449> back next week

DC: The "equation-label" property has been added to the core-properties,
and implemented in MathCAT. equation numbers: issue 525
<https://github.com/w3c/mathml/issues/525> was closed.
<https://cryptpad.fr/#cp-md-0-agenda>Agenda
<https://cryptpad.fr/#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

   - Igalia has funding to work on MathML interop

NS: Brian Kardell wants to focus on making CSS the same everywhere.

NS: The funding is for approximately one full person for a year. The
funding covers some non-MathML interop also.
<https://cryptpad.fr/#cp-md-0-2-progress-on-spec-writing->2. Progress on
spec-writing?
None last week
<https://cryptpad.fr/#cp-md-1-3-a-href-https-github-com-w3c-mathml-issues-522-nested-math-in-token-elements-issue-522-a->3.
nested math in token elements issue 522
<https://github.com/w3c/mathml/issues/522>

DC: The concern is that some systems don't want nested math.

DC: I will write a PR for the spec. What I plan to do is to not let the
purest MathML keep not allowing nested math, or nested anything. Currently
we offer the HTML as an example extension that allows all the inline HTML
there.

DC: I want to offer Math as a built-in possible extension, so that for the
PDF, I can say it's allowed without having to write my own extension.

*ACTION:* DC will write a PR to close nested math in token elements issue
522 <https://github.com/w3c/mathml/issues/522>.
<https://cryptpad.fr/#cp-md-1-4-a-href-https-github-com-w3c-mathml-issues-449-intent-properties-ordering-amp-references-issue-449-a->4.
Intent Properties: ordering & references · Issue #449
<https://github.com/w3c/mathml/issues/449>.

(round #2)

NS: There are two components determining the property of an element, a
property that is part of the element, and the property inherited by the
element.

NS: There really are two kinds of properties, some that apply only to the
current element, and some that are inherited.

NS: If we have some properties that are inheritable and some that aren't,
then maybe the solution is syntactic. And so you have colon and colon,
colon, where, colon means it's inherited, and colon colon means it's not.

DG: This is similar to CSS.

NS: This could lead to many mistakes.

DG: You can add some syntax If you want an algorithm. You need a handle on
their behavior.

DC: I'm losing faith that we can syntactically copy all these things in,
because I don't think it makes sense.

NS: The other issue that came up last week was whether it was useful to
allow properties on references, which was not really necessary for the
examples that DC had.

*ACTION:* NS: Bring Intent Properties: ordering & references · Issue #449
<https://github.com/w3c/mathml/issues/449> back next week.


*There are 6 open intent issues
<https://github.com/w3c/mathml/issues?q=is%3Aissue%20state%3Aopen%20%20core%20concept%20label%3Aintent>
(including #449) Can any of them be closed?*

Let us consider equation numbers: issue 525
<https://github.com/w3c/mathml/issues/525>.

From Deyan Ginev to everyone: Just do... or don't :-)

DC: The "equation-label" property has been added to the core-properties,
and implemented in MathCAT. equation numbers: issue 525
<https://github.com/w3c/mathml/issues/525> was closed.
<https://cryptpad.fr/#cp-md-0-zoom-meeting-summary>Zoom AI Meeting Summary

For Math WG (2025-07-17)

Lightly edited...
<https://cryptpad.fr/#cp-md-0-quick-recap>Quick recap

The team discussed solutions for handling nested math and token elements,
with David proposing to keep current restrictions while adding MathML as an
extension point and planning to write a PR for schema adjustments. They
explored property inheritance and intent handling approaches, including
discussions about default values, overrides, and context-specific
properties, while also addressing equation label handling in MathML. The
conversation ended with plans to review and potentially close open intent
issues, with Neil agreeing to continue discussions about equation labels in
the following week.
<https://cryptpad.fr/#cp-md-0-next-steps>Next steps

   - David to write a PR for the spec regarding nested math and token
   elements.
   - Neil to read and understand Deyan's gist on the intent properties
   algorithm in detail.
   - All participants to continue the discussion on intent properties
   algorithm next week.
   - All participants review open intent issues and prepare to close some
   of them in the next meeting.

<https://cryptpad.fr/#cp-md-0-summary>Summary
<https://cryptpad.fr/#cp-md-0-mathml-extension-for-nested-elements>MathML
Extension for Nested Elements

David proposed a solution for nested math and token elements by keeping the
current restriction on nested math while offering MathML as a built-in
extension point, similar to HTML. He plans to write a PR to adjust the
schema and make this option explicit. Moritz suggested generalizing the
approach to allow any outer element from the host language, but David
explained that this might not be feasible due to the complexity of
incorporating other schemas. The group agreed to make the current approach
more explicit in the specification, particularly for MathML.
<https://cryptpad.fr/#cp-md-0-schema-customization-and-documentation-discussion>Schema
Customization and Documentation Discussion

David and Neil explored the possibility of overriding default settings in
MathML to allow specific HTML or TEI elements, with David suggesting a
simple one-liner solution for customizing token content. Moritz and David
debated the feasibility of defining custom elements within the current
namespace constraints, but David noted that allowing HTML elements through
the 'star' option already provides flexibility. They agreed to draft a pull
request to finalize the discussion and include example schemas.
<https://cryptpad.fr/#cp-md-0-property-inheritance-implementation-discussion>Property
Inheritance Implementation Discussion

The team discussed property inheritance in their system, with David
explaining that some properties only apply to the current element while
others can be inherited. They explored different approaches to implementing
inheritance, including a syntactic copying method that David rejected as
impractical. Neil suggested using a colon syntax to distinguish between
inheritable and non-inheritable properties, which Deyan noted matches CSS
behavior. The discussion concluded with David proposing that properties
should specify their scope (element and children) without necessarily
affecting all descendants, and Neil confirmed that MathCAT's current
implementation follows a similar approach where each property decides
whether to check ancestors or the current element.
<https://cryptpad.fr/#cp-md-0-intent-inheritance-and-default-handling>Intent
Inheritance and Default Handling

The team discussed the behavior of intent inheritance and default values in
their system. Deyan proposed using two priority queues for handling
defaults and overrides, while Neil suggested adding intent in common cases
or when the common property is set. They debated how to handle cases where
properties like matrix or system of equations are inherited, with Deyan
warning about potential issues with nested annotations. The group agreed
that a clear distinction between default behaviors, overrides, and
context-specific properties was needed, but left open the question of how
to handle complex cases like nested matrices or chemical formulas.

Property Inheritance and Context Handling David, Neil, and Deyan discussed
the scope and inheritance of properties in a system. They explored how
properties apply to descendant nodes and the concept of an active context.
Deyan proposed using two distinct data structures for defaults and
overrides, which simplifies the algorithm but still leaves open the
question of how far a property applies. The team agreed that properties on
references might not be necessary for the examples they had, but Deyan was
satisfied with his solution for handling references.
<https://cryptpad.fr/#cp-md-0-algorithm-development-and-issue-review>Algorithm
Development and Issue Review

The team discussed ongoing algorithm development work, with David noting
that while some members had criticized the current algorithm, they should
put their money where their mouth is by proposing alternatives. Due to time
constraints, the discussion was postponed to the following week when Bruce
would be available to join and help address several open issues.
<https://cryptpad.fr/#cp-md-0-mathml-equation-label-implementation>MathML
Equation Label Implementation

The team discussed equation label handling in MathML, particularly for
single-line equations and table cells. There was discussion to allow
equation labels in any MathML element, though Neil noted he could implement
additional label detection for single-line equations if needed. They
decided to close a related PR since the core properties for equation labels
had been implemented and accepted through a previous vote.