Minutes: MathML Full meeting, 24 July, 2025

 Attendees:

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

<https://cryptpad.fr/#cp-md-0-action-items>Action Items
<https://cryptpad.fr/#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

*ACTION:* NS: The Thursday, July 31, 2025, intent meeting has been
cancelled.

*ACTION:* NS: We will take up charter writing in a couple of weeks.

*ACTION:* BB will check to see if we can use the same charter templates and
procedures as the last time we worked on the MathML charter.
<https://cryptpad.fr/#cp-md-0-2-progress-on-spec-writing->2. Progress on
spec-writing?
<https://cryptpad.fr/#cp-md-0-3-a-href-https-github-com-w3c-mathml-issues-449-intent-properties-ordering-amp-references-issue-449-a-round-3->3.
Intent Properties: ordering & references Issue #449
<https://github.com/w3c/mathml/issues/449> (round #3)

*ACTION:* DG will check to see if documents carry meta data to identify the
system for which they were generated.

*ACTION:* NS: we will say that we do not have enough experience to come to
a resolution for issue #449 <https://github.com/w3c/mathml/issues/449>. We
will continue to discuss this at the next meeting.
<https://cryptpad.fr/#cp-md-0-4-a-href-https-github-com-w3c-mathml-issues-q-is-3aissue-20state-3aopen-20-20core-20concept-20label-3aintent-there-are-5-open-intent-issues-a-including-449-can-any-of-them-be-closed->4.
There are 5 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?

Consider Naming the arguments to intent: new property needed? issue #524
<https://github.com/w3c/mathml/issues/524>.

*ACTION:* NS: The thing to do is to put in some more realistic examples. We
will come back to this at the next meeting.
<https://cryptpad.fr/#cp-md-0-agenda>Agenda
<https://cryptpad.fr/#cp-md-1-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

*ACTION:* NS: The Thursday, July 31, 2025, intent meeting has been
cancelled.

PL: Did we bury MathML3? Firefox does not do mfence.

DC: mfence has been removed from Firefox.

PL: It basically means without a polyfill mfence is going to be completely
ignored.

NS: Frederick was involved in the Firefox implementation, so when he took
mfence out of core, he took it out of Firefox. It's been gone since around
when core came out.

NS You need polyfills if you want to work with the full spec.

NS: Eri Pérez, from Igalia, has joined the group.

DC: Last week was the TeX Users Group Conference in India. There was A few
accessibility talks, and they're all on YouTube, if you Google for them.
Frank Middleback has a talk on accessible PDF.

*ACTION:* NS: We will take up charter writing in a couple of weeks.

*ACTION:* BB will check to see if we can use the same charter templates and
procedures as the last time we worked on the MathML charter.

NS: Patrick Ion will give a MathML talk at the SIAM conference in Montreal
in a couple of weeks.
<https://cryptpad.fr/#cp-md-1-2-progress-on-spec-writing->2. Progress on
spec-writing?
None
<https://cryptpad.fr/#cp-md-0-3-a-href-l-intent-properties-ordering-amp-references-issue-449-a-round-3->3.
Intent Properties: ordering & references Issue #449 <https://cryptpad.fr/l>
(round #3)

NS wrote: This issue is meant to pull together some threads on how
properties are handled, whether there is an order, and what happens if
there is a conflict. Any other conceptual issues related to properties are
also appropriate here. Their syntax is part of issue #448
<https://github.com/w3c/mathml/issues/448>. I am probably missing some
issues raised elsewhere (issue #446
<https://github.com/w3c/mathml/issues/446>, but here's a starting list:

   - How should a headless property "headless" be interpreted (standalone
   and when referenced)
   - If multiple properties are given, does the order matter?
   - If a property exists on a referenced item and the referencing item has
   a property, if order matters, what's the order that should be used?

It would be good to ground some of these examples with real life cases.
Hopefully, people can generate some.

DC:  if the leaf wins, then what's the point of having a property on a
reference?

MuS: One general rule should be "keep it simple", else otherwise people
will do it wrong.

DC: I think the problem is: if this is the algorithm we have to do, then it
doesn't really matter whether it's right or not, it's just not workable,
because nobody's going to know how to implement it.

DG: The behavior is not clearly specified.

PL: We may produce a very fragile design.

NS: We could simplify it, as David says, and take out references. That's
one way to resolve this, it's not clear that's a great thing, because it
may take away too much power.

NS: We have to be specific on what we mean.

NS: Maybe we should say that here is what happens in the common case and
the other cases remain undefined and will be specified more fully when we
have more experience. We need more use cases.

NS: We do not have a good sense of how the generators will be generating
MathML.

DC: Our discussions may not lead to a solution.

NS: We just don't have the experience at the moment to know how this thing
is going to be used. We do not know what the complicated cases should do.

DC: Currently we say: A property annotates the intent, with an additional
property which may be used by the system to adjust the generated speech or
braille in system-specific ways. So the entire behavior is system-specific.

DC: If we had a page worth of inheritance rules to say which properties we
are in,
then some system-specific things can still happen.

NS: It would be nice if the outcome were not system-specific.

NS: Well, my feeling is, if we're not going to specify it, we have to say
something in the spec.

NS: We must have some complicated examples.

DC: Yeah, I think we should have some examples with more than one property
because currently they're all kind of trivial.

DG: Does HTML, or MathML, have any mechanism to annotate which system a
document was generated for?

NS: I do not think there is anything.

DG: It would be nice to have some custom meta tag because it would just be
helpful to know what the document was generated for/tested with..

From Moritz Schubotz to everyone: Outside of the MathML object this could
be part of FairDigitalObject properties

NS: MathML doesn't have any metadata associated with itself. Documents
typically hold the metadata, and I'm sure there's a way in some metadata
system, which I'm not familiar with for specifying these kinds of things,
but I don't have the information to answer that.

*ACTION:* DG will check to see if documents carry meta data to identify the
system for which they were generated.

*ACTION:* NS: we will say that we do not have enough experience to come to
a resolution for issue #449 <https://github.com/w3c/mathml/issues/449>. We
will continue to discuss this at the next meeting.
<https://cryptpad.fr/#cp-md-1-4-a-href-https-github-com-w3c-mathml-issues-q-is-3aissue-20state-3aopen-20-20core-20concept-20label-3aintent-there-are-5-open-intent-issues-a-including-449-can-any-of-them-be-closed->4.
There are 5 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?

Consider Naming the arguments to intent: new property needed? issue #524
<https://github.com/w3c/mathml/issues/524>.

NS: When you navigate around a fraction, a part of the expression is
labeled numerator, and another part of the expression is labeled
denominator. Should we have a method to label the parts of any expression
in an analogous manner? An example of this is a 3D point (X, Y, Z). Can
each of these components be given a label?

MuS: If we knew something was a binomial, we could just say its parts.

MuS: In principle if we knew how to say it, we could just do it.

PL: This would be useful.

PL: Sometimes people use tables to show their layouts.

DC: There are two suggestions: NS has suggested adding something like
":navname-xxx" to the arguments. DC has suggested adding the :argname
property having the effect that the argument is announced with the name
used for arg, this does force you to use descriptive arg names.

NS likes DC's solution more than his own suggestion.

*ACTION:* NS: The thing to do is to put in some more realistic examples. We
will come back to this at the next meeting.
<https://cryptpad.fr/#cp-md-0-zoom-math-wg-intent-meeting-summary-2025-07-24->Zoom
Math WG Intent Meeting Summary (2025-07-24)
<https://cryptpad.fr/#cp-md-0-quick-recap>Quick recap

The team discussed precedence rules for properties in tree structures and
mathematical expressions, with debate over whether leaf properties or
reference properties should take precedence and how fixity properties are
applied. They explored the complexity of implementing intent and properties
in MathML, including concerns about algorithm workability and the need for
more real-world use cases. The group also discussed adding system-specific
metadata to MathML documents, naming conventions for mathematical concepts,
and solutions for argument naming in speech systems, concluding with plans
to add more complex examples and reconvene in two weeks.
<https://cryptpad.fr/#cp-md-0-next-steps>Next steps

   - Team to add more realistic examples of intent and properties
   combinations to the spec, including logical deduction and coordinates
   examples
   - Team to revisit and potentially resolve intent/properties
   specification in 2 weeks
   - Team to focus on charter writing and proposal preparation after break
   - Bert to check and share updated charter writing template if any
   changes from 2 years ago
   - Team to continue discussion on naming arguments/concepts when
   navigating math content
   - Team to consider implementing single "arg-name" property solution for
   consistent argument naming

<https://cryptpad.fr/#cp-md-0-summary>Summary
<https://cryptpad.fr/#cp-md-0-tree-property-precedence-rules-debate>Tree
Property Precedence Rules Debate

The team discussed the precedence rules for properties in a tree structure,
particularly whether leaf properties or reference properties should take
precedence. David and Deyan explained that reference properties would
override leaf properties, similar to how assignments override each other in
procedural programming. Neil expressed concern about this approach, arguing
that leaf properties should always take precedence, and the team debated
whether this would make refer properties redundant. The discussion ended
with Murray suggesting that keeping the rules simple would prevent users
from making mistakes, though no final decision was reached.
<https://cryptpad.fr/#cp-md-0-fixity-properties-in-mathematical-expressions>Fixity
Properties in Mathematical Expressions

The group discussed the handling of fixity properties in mathematical
expressions, particularly focusing on how properties are applied to leaf
elements versus references. Deyan explained his algorithm which prioritizes
self-properties on leaf elements, followed by properties on leaf elements
themselves, and finally properties on references, with the latter having
the highest priority. The discussion revealed that intent properties on
leaf elements don't have practical effect, properties on references can
influence how expressions are evaluated and spoken, though there was some
debate about whether this was the intended behavior.
<https://cryptpad.fr/#cp-md-0-challenges-in-mathml-intent-implementation>Challenges
in MathML Intent Implementation

The team discussed the complexity of implementing intent and properties in
MathML, with David expressing concerns about the algorithm's workability
and the lack of clear specifications. Neil suggested simplifying the
algorithm by removing references on properties, while Paul proposed
postponing some reflections to a later stage. The group agreed that more
real-world use cases are needed to fully understand and specify the
behavior of complex intents and properties. They also discussed the
system-specific nature of property effects, with David noting that the
final result is still largely determined by the underlying system.
<https://cryptpad.fr/#cp-md-0-mathml-metadata-implementation-discussion>MathML
Metadata Implementation Discussion

The group discussed the possibility of adding system-specific metadata to
MathML documents to help with implementation tracking and market research.
Deyan suggested using custom meta tags to annotate which system a document
was generated for, but Neil and David noted that MathML itself doesn't have
built-in metadata capabilities. While the idea of including such
information in a metadata system was proposed, David warned that it might
face resistance during review. The discussion concluded with Bruce
suggesting that this could potentially be implemented as a media query,
though Neil expressed uncertainty about this approach.
<https://cryptpad.fr/#cp-md-0-complex-examples-and-naming-conventions>Complex
Examples and Naming Conventions

The team discussed adding more complex examples to the specification to
address cases they lack experience handling. They decided to take a break
from meetings next week due to some members being away. The group also
explored the need for a way to name parts of mathematical concepts,
particularly in fractions and binomials, with Murray suggesting that some
naming could be done automatically while allowing for user overrides.
<https://cryptpad.fr/#cp-md-0-speech-system-argument-naming-solutions>Speech
System Argument Naming Solutions

The group discussed solutions for naming arguments in speech systems, with
David proposing a single "arg-name" property to ensure consistent and
readable argument naming, while Neil suggested a "navname" convention.
Murray expressed concerns about using impractical examples, and Bruce
emphasized the importance of clear naming to avoid confusion. The team
agreed to add more realistic examples and reconvene in two weeks, with Neil
noting the need to focus on charter writing and proposal development. Bert
was asked to check for any updates to the charter template.