Minutes_ MathML Full Meeting_ 11 Sept_ 2025

9/11/2025
 Attendees:
* Neil Soiffer
* Louis Maher
* David Carlisle
* Deyan Ginev
* Bruce Miller
* Bert Bos
* Moritz Schubo

 Action Items
 2. Progress on spec-writing?
None.

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.

Agenda

 1. Announcements/Updates/Progress reports
There is a pdf week meeting, next week, in Berlin.

 2. Progress on spec-writing?
None.

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<https://github.com/w3c/mathml/issues/449%23issuecomment-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.

 Zoom Meeting Summary 9/11/2025

 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.

 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.

#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.

 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.

 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.

 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 implement ability 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.

 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.

 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.



 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.

 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.



Regards
Louis Maher
Phone: 713-444-7838
Email: ljmaher03@outlook.com