Minutes: MathML Full meeting 11 September, 2025

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - David Carlisle
   - Deyan Ginev
   - Bruce Miller
   - Bert Bos
   - Moritz Schubo

<https://cryptpad.fr/#cp-md-0-regrets>Regrets
<https://cryptpad.fr/#cp-md-0-action-items>Action Items
<https://cryptpad.fr/#cp-md-0-2-progress-on-spec-writing->2. Progress on
spec-writing?

None.
<https://cryptpad.fr/#cp-md-0-3-a-href-https-github-com-w3c-mathml-issues-449-intent-properties-ordering-amp-references-issue-449-a->3.
Intent Properties: ordering & references Issue #449
<https://github.com/w3c/mathml/issues/449>

(progress during the week?)

*ACTION:* DC will delete his original version and write out a complete
description of his second version, and NS will explain his ideas about
properties going down, and references coming up.
<https://cryptpad.fr/#cp-md-0-agenda>Agenda
<https://cryptpad.fr/#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

There is a pdf week meeting, next week, in Berlin.
<https://cryptpad.fr/#cp-md-1-2-progress-on-spec-writing->2. Progress on
spec-writing?

None.
<https://cryptpad.fr/#cp-md-1-3-a-href-https-github-com-w3c-mathml-issues-449-intent-properties-ordering-amp-references-issue-449-a->3.
Intent Properties: ordering & references Issue #449
<https://github.com/w3c/mathml/issues/449>

(progress during the week?)

https://github.com/w3c/mathml/issues/449#issuecomment-3274662336

BM: If an application can be a head, then an application needs to also be
able to get properties.

NS: At one time we allowed it, then we decided That was a complication that
we didn't need.

NS: We want this to be implementable. I will make it work, no matter what
it takes, but the Question is, how much work would people be willing to do.

From Deyan Ginev to everyone: Current syntax has a trick to wrap a property
around any expression. The underscore:

_:infix( converse:postfix(L) )

PL: We need to strive for simplicity.

NS: Simplicity of the grammar or simplicity of the implementation?

PL: Simplicity of grammar.

DG: The one thing we should not forget is that the intent is a partial
annotation framework, meaning we will always allow raw presentation nodes
in legacy mode Around intent expressions. And, as long as we have a
reference, we can refer to a legacy presentation node And we will always
have undefined behavior as part of resolving intent expressions. Or, if not
undefined maybe too strong, but let's say it's not fully within the syntax
of intents.

From Moritz Schubotz to everyone: our intent-grammar currently looks like
that

https://github.com/wikimedia/mediawiki-extensions-Math/blob/master/src/WikiTexVC/parserintent.pegjs

From Paul Libbrecht to everyone: Linearizing is only or some selected
cases… i.e.. should not be super encouraged. Most people will use the depth
of the xml anyways. Or?

NS: We have two audiences, the authors, and the implementers.

NS: It better be simple for the authors to understand so that they can
generate it. Otherwise, it's like, well, I don't understand what's going on
with intent, I can't use it. There's a lot more authors than there are
implementers, and I think that's something that tips the balance towards
making it better for authors than for implementers.

BM: We should simplify the grammar to cope with this case.

From Deyan Ginev to everyone: As long as we never use the word "inherit" :-)

From Deyan Ginev to everyone: excellent, no use of the i-word

BM: I think we're actually surprisingly close to all agreeing what should
happen, we just can't agree how to describe it.

From Deyan Ginev to everyone: intent=":literal" makes the presentation tree
part of the scope of intent

BM: I know we're trying to bend over backwards to avoid making any of the
properties be special, and somehow, some of them always end up special.

BM: If I can summarize, properties on references go after the references,
equivalent, but self-properties go before it.

NS: The way I think of it is, references get lifted up, and properties get
pushed down.

DC: We must come up with a conclusion.

From Moritz Schubotz to everyone: I forgot one point in updates. I think I
found a regression in Chrome https://issues.chromium.org/issues/443107123

DG will begin a three-week trip starting on Thursday, September 18. We do
not want to decide in his absence; however, DC and NS will write up their
descriptions hopefully before DG leaves on his trip.

NS: I might take a crack at trying to explain my idea about lifting up and
pushing down. Properties go down, and references come up.

*ACTION:* DC will delete his original version and write out a complete
description of his second version, and NS will explain his ideas about
properties going down, and references coming up.

Next week, we will go to another issue.
<https://cryptpad.fr/#cp-md-0-zoom-meeting-summary-9-11-2025>Zoom Meeting
Summary 9/11/2025 <https://cryptpad.fr/#cp-md-0-quick-recap>Quick recap

The group discussed upcoming PDF accessibility topics and specifications
for LaTeX, including MathML considerations and property handling. They
explored technical issues related to property inheritance, application
behavior, and the interpretation of infix properties in mathematical
expressions, with various proposals for grammar changes and implementation
approaches. The team concluded by discussing the complexity of intent
expressions and documentation needs, agree to write different explanations
of technical concepts while postponing final decisions due to upcoming
holidays.
<https://cryptpad.fr/#cp-md-0-next-steps>Next steps

   - David to rewrite his version of the intent properties and order
   references explanation in light of the comments, without the navigation
   comments.
   - Neil to write up his version explaining the idea about lifting up and
   pushing down properties.
   - David and Neil share their written explanations by the weekend so
   Deyan can review before his vacation.

<https://cryptpad.fr/#cp-md-0-summary>Summary

PDF Accessibility and MathML Discussion

The group discussed the upcoming PDF meeting in Berlin, where LaTeX and PDF
accessibility will be key topics, though some parts are ISO-related and not
public. They addressed an issue with MathML 3 vs MathML 4 in the
specification, noting that MathML 4 could be important for accessibility.
David completed work on a specification, and the group examined a problem
with intent properties and orderings, particularly focusing on how to
handle properties with references. Deyan mentioned there was more to
discuss regarding the property handling than just the specific case they
were examining.
<https://cryptpad.fr/#cp-md-0-property-inheritance-and-application-behavior>Property
Inheritance and Application Behavior

The team discussed a technical issue regarding property inheritance and
application behavior in their system. Deyan identified a case where
properties do not descend properly when applied to infix references, which
David confirmed was a result of intentional restrictions made to simplify
the grammar by excluding properties from applications. Bruce suggested that
applications should be able to get properties as well, which Neil
remembered was previously allowed but later removed due to implementation
complications. The discussion highlighted the need to address these edge
cases while maintaining system simplicity.
<https://cryptpad.fr/#cp-md-0-infix-property-grammar-changes>Infix Property
Grammar Changes

David and Neil discussed the syntax and interpretation of the infix
property in the context of application terms. David proposed changing the
grammar to treat application similarly to numbers and concepts, allowing
properties to be applied after it. They explored different interpretations
of how the infix property would be handled in various expressions,
emphasizing that even if not written explicitly, the property would still
be in scope and affect the interpretation of the operation. Bruce agreed
with the proposed changes, suggesting that the expression should be written
as "XL Converse y" with the infix property applied between x and y.
<https://cryptpad.fr/#cp-md-0-intent-attributes-syntax-discussion>Intent
Attributes Syntax Discussion

The group discussed the syntax and semantics of intent attributes, with
Deyan explaining the difference between effective intent and intent
attributes. Bruce and David expressed concerns about the awkwardness of
allowing intent attributes through references rather than directly in the
syntax. Neil raised questions about implementability and the amount of work
users would be willing to do to make the system work. The discussion
touched on the naturalness of functional heads and infix usage, with David
and Bruce drawing from their backgrounds to support their perspectives.
<https://cryptpad.fr/#cp-md-0-intent-expressions-implementation-challenges>Intent
Expressions Implementation Challenges

The team discussed the complexity of implementing intent expressions and
the need to balance simplicity for authors versus implementers. David
proposed a grammar change to simplify the specification, while Deyan
emphasized the importance of allowing undefined behavior and legacy modes.
Bruce suggested that they are close to agreeing on the desired outcome but
struggle with how to describe it. Neil expressed concerns about the
implementation complexity, highlighting the need to prioritize simplicity
for authors who generate content. The group acknowledged that while there
are fewer implementers than authors, both groups need clear documentation
and specifications.
<https://cryptpad.fr/#cp-md-0-algorithmic-property-reference-handling-discussion>Algorithmic
Property Reference Handling Discussion

The team discussed the handling of properties and references in their
algorithm, focusing on how self-properties and ancestors should be
interpreted differently. David explained that his modified algorithm allows
for the kernel to be placed at the end, addressing issues with
self-properties that were not functioning correctly. Neil and Bruce
clarified that properties are pushed down while references are lifted up,
with Neil suggesting that this approach aligns with Deyan's algorithm.
Deyan highlighted the complexity of the situation, noting that both
self-properties and reference properties need to be considered
simultaneously, even in cases where the common is on the reference and the
infix is a self-property.
<https://cryptpad.fr/#cp-md-0-math-expression-intent-discussion>Math
Expression Intent Discussion

The group discussed the interpretation of mathematical expressions and
their associated intents. Bruce and Neil debated whether navigating to a
sub-expression should follow the intent of the containing expression or the
intent of the sub-expression itself. David noted that his current
description algorithm calls out what happens when navigating into
sub-terms, but agreed this might not be necessary. They concluded that the
MathML specification should focus on what should be read for a given
expression, rather than describing navigation behavior, as navigation is
not part of the intent.
<https://cryptpad.fr/#cp-md-0-technical-explanation-approaches-postponed>Technical
Explanation Approaches Postponed

The team discussed different approaches to explaining a technical concept,
with David presenting his version and Neil planning to write an alternative
explanation based on lifting and pushing properties. Due to upcoming
holidays for Deyan and Neil, they agreed to postpone making a final
decision and instead focus on writing specifications and polyfills in the
meantime. David will write up his version by the weekend, and Neil will
work on his explanation, with both versions to be reviewed before any group
decisions are made.