- From: Neil Soiffer <soiffer@alum.mit.edu>
- Date: Mon, 30 Mar 2026 11:15:46 -0700
- To: "www-math@w3.org" <www-math@w3.org>
- Message-ID: <CAESRWkArmecz6iwKG53CS9_ZgTNBfrpbLAYHkUY1tH7zanY3NQ@mail.gmail.com>
Attendees:
- Neil Soiffer
- Louis Maher
- David Carlisle
- Paul Libbrecht
- Deyan Ginev
- Patrick Ion
- Bruce Miller
- Bert Bos
<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-review-the-a-href-https-w3c-github-io-mathml-docs-charter-2026-html-draft-charter-a->2.
Review the draft charter
<https://w3c.github.io/mathml-docs/charter-2026.html>.
Issues on it are here <https://github.com/w3c/mathml/issues/568>.
*ACTION:* DG will run Claude over the charter once NS has finished his
current changes.
*CONSENSUS:* NS: The charter is ready to be submitted.
*ACTION:* We will have another charter submission vote in the core meeting
of March 30, 2026, because there will be a different set of people there.
*ACTION:* BB: The process is that NS tells BB that the charter is ready to
be started.
<https://cryptpad.fr/#cp-md-0-3-discuss-the-appropriateness-of-a-href-https-www-w3-org-policies-process-registries-registries-a->3.
Discuss the appropriateness of registries
<https://www.w3.org/policies/process/#registries>
for intent concepts
*CONSENSUS:* We agree that we will not pursue the registry track at this
time.
*ACTION:* NS: If anyone has issues for next week, send them to me and I
will put them in the minutes.
<https://cryptpad.fr/#cp-md-0-agenda>Agenda
<https://cryptpad.fr/#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports
NS: The person who is the primary maintainer of Orca, the Linux screen
reader, has been working on incorporating Mathcat into Linux, so that
MathML can be supported in Linux.
NS said that DG had reported that the LaTeXML project is moving along with
a Rust implementation replacing PERL.
DG said that the Rust implementation was 30 times faster than the PERL
implementation.
PL: Are we having a re-implementation of Net XML in Rust, or are you
keeping it just internal to Archive?
DG: If I complete the work without major cataclysms, then I will publish it
with the same license as LaTeXML, or as close as possible, in the public
domain.
DG: This will be coordinated with BM.
<https://cryptpad.fr/#cp-md-0-2-review-the-a-href-https-w3c-github-io-mathml-docs-charter-2026-html-draft-charter-a-a-href-https-github-com-w3c-mathml-issues-568-issues-on-it-are-here-a->2.
Review the draft charter
<https://w3c.github.io/mathml-docs/charter-2026.html>. Issues on it are here
<https://github.com/w3c/mathml/issues/568>.
NS: I have incorporated the suggestions from the meeting last week, along
with suggestions from PL and MOS.
PL: I think the bigger question is whether we want to optionally leave
something said about content MathML, or say explicitly that we exclude
anything there. I think that bothered Moritz.
NS: We're not changing MathML in any significant way, from Content MathML,
for MathML 4, but, larger changes will be considered for MathML5.
DC: We are not adding anything to MathML4 at this time. We want to get the
spec out to CR.
NS: If there is something that is plain wrong, then we will fix it.
NS: We start on MathML5 as soon as we get out of the door.
NS: In the other deliverables, I added a suggested list of LaTeX teX
macros, names and arguments, and their mapping to intent core concepts and
properties as one of the potential deliverables. This idea came from MoS
and PL.
NS: I changed the timeline based on what Bert told us last time. I
stretched it out a little bit, too, so there's no proposed recommendation,
you just go to recommendation.
NS: I have our polyfill implementations finishing in June of 2027.
NS: The recommendation from MathML4 is scheduled for March of 2027.
NS: I added the PDF Association and the Unicode Consortium to the list of
External Organizations.
*ACTION:* DG will run Claude over the charter once NS has finished his
current changes.
*CONSENSUS:* NS: The charter is ready to be submitted.
*ACTION:* We will have another charter submission vote in the core meeting
of March 30, 2026, because there will be a different set of people there.
*ACTION:* BB: the process is that NS tells BB that the charter is ready to
be started.
<https://cryptpad.fr/#cp-md-0-3-discuss-the-appropriateness-of-a-href-https-www-w3-org-policies-process-registries-registries-a-for-intent-concepts>3.
Discuss the appropriateness of registries
<https://www.w3.org/policies/process/#registries> for intent concepts
NS: I asked Gemini for the pros and cons of using the registry track.
Why Registries Are a Good Fit
-
*Lightweight Updates:* Unlike the Recommendation Track, changes to *registry
entries <https://www.w3.org/policies/process/#registry-entry>* do not
require a new *Advisory Committee Review
<https://www.w3.org/policies/process/#advisory-committee-review>* or
patent exclusion opportunities, provided the changes follow the
established *registry
definition <https://www.w3.org/policies/process/#registry-definition>*.
-
*Separation of Concerns:* The *Registry Track
<https://www.w3.org/policies/process/#registries>* allows the Working
Group to define the *structure* and *policy* of the list once (the
definition), while the actual *data* (the list of concepts) can evolve
as the community identifies new needs.
-
*External Submissions:* The process facilitates *submission
<https://www.w3.org/policies/process/#reg-def>* and ease of adding new
terms, including by stakeholders who may be external to the core Working
Group.
-
*Formal Status:* A *W3C Registry
<https://www.w3.org/policies/process/#w3c-registry>* still carries the
endorsement of W3C, providing the "core concepts" with more weight and
stability than a simple *Group Note
<https://www.w3.org/policies/process/#Note>*.
Cons of Using a Registry (vs. a Group Note)
-
*Significant Initial "Definition" Burden:* Unlike a Group Note
<https://www.w3.org/policies/process/#WGNote>, which can be relatively
free-form, a registry requires a formal registry definition
<https://www.w3.org/policies/process/#reg-def>. The Working Group must
achieve consensus on and document:
-
The exact *fields and constraints* of the data.
-
The *criteria for approval* (e.g., who can submit, what background
info is required).
-
A *change policy* for how entries are deleted, deprecated, or
modified.
-
*Maintenance Infrastructure Requirements:* A registry is a "living"
document that necessitates ongoing administrative support:
-
*Designated Custodian:* You must identify a custodian
<https://www.w3.org/policies/process/#custodian> responsible for
evaluating requests. If that custodian becomes unresponsive, it
requires a W3C
Decision <https://www.w3.org/policies/process/#def-w3c-decision>
and Advisory
Committee Review
<https://www.w3.org/policies/process/#advisory-committee-review> to
replace them.
-
*Notification Systems:* The W3C Team
<https://www.w3.org/policies/process/#team> is required to provide a
means for interested parties to be notified of updates, adding technical
overhead to the publication process.
-
*Strict Structural Limitations:* Registries
<https://www.w3.org/policies/process/#registry> are designed strictly to
document values and data. They are subject to specific restrictions that
don't apply to Notes <https://www.w3.org/policies/process/#WGNote>:
-
*No Normative Requirements:* A registry report
<https://www.w3.org/policies/process/#registry-report> or embedded
registry <https://www.w3.org/policies/process/#embedded-registry> *must
not* define any architectural or interoperability requirements.
-
*Patent Policy Exclusion:* Registries
<https://www.w3.org/policies/process/#registry> are not subject to
the W3C Patent Policy <https://www.w3.org/policies/patent-policy/>.
If the "core concepts" imply specific implementation requirements or IPR
commitments, they would need to be in a Recommendation Track
<https://www.w3.org/policies/process/#w3c-recommendation-track>
document instead.
-
*Complexity in Referencing:* As a registry
<https://www.w3.org/policies/process/#registry> is essentially a lookup
table, any specification that references it
<https://www.w3.org/policies/process/#reg-ref-specifications> must be
carefully written to ensure that a change in the registry doesn't
accidentally change the conformance of the specification.
Finally, here are all the existing registries. They are all in a draft
state:
-
*WebCodecs Codec Registry
<https://www.w3.org/TR/webcodecs-codec-registry/>*
-
*WebCodecs VideoFrame Metadata Registry
<https://www.w3.org/TR/webcodecs-video-frame-metadata-registry/>*
-
*Encrypted Media Extensions Stream Format Registry
<https://www.w3.org/TR/eme-stream-registry/>*
-
*Encrypted Media Extensions HDCP Version Registry
<https://www.w3.org/TR/eme-hdcp-version-registry/>*
-
*Encrypted Media Extensions Initialization Data Format Registry
<https://www.w3.org/TR/eme-initdata-registry/>*
-
*Web of Things (WoT) Binding Registry
<https://www.w3.org/TR/wot-binding-registry/>*
-
*Media Source Extensions Byte Stream Format Registry
<https://www.w3.org/TR/mse-byte-stream-format-registry/>*
-
*W3C Alternative and Augmented Communication (AAC) Symbol Registry
<https://www.w3.org/TR/aac-registry/>*
All of the lists are quite short except the last one. For that, they have a
JSON list link and a table for visual display. The data is very simple. It
is draft dated 2022.
There is also "DID Methods <https://www.w3.org/TR/did-extensions-methods/>"
(which Gemini halunciated as being on the registry track). The
Decentralized Identifier Working Group <https://www.w3.org/groups/wg/did/> used
a series of W3C Notes to publish their list. They have a list of over 100
entries.
NS: Basically it says, unlike the REC track, registry entries do not
require a new review or patent exclusion opportunity, so, we can change
things easily.
NS: The registration track allows the working group to define the structure
and policy once, and make the changes anytime we want.
NS: The other benefit was that it's in the TR space, so it's more formal.
NS: The cons are that we have to actually really formally define the
format, and the format can't be changed once we have a definition of it
without changing our registry stuff, and that probably requires approval.
NS: It is a living document, and someone has to maintain it.
NS: There could be multiple lists, one for open and one for core.
NS: There were only eight registry track registries, and they all were in
the working draft state.
BB: It is a new process, and we have not gotten registries to the
recommendation stage.
BB: The groups have not completed the work.
DC: We have not had a published spec with registries.
DC: If we used registries, the spec would have to point to them, and, since
the registries are not ready, the spec could not be ready.
DC: We could consider registries for MathML5.
NS: We could store values with a note.
PI: We could suggest in the charter that we look at the registry option.
This would be a tentative deliverable.
DC: The activity investigating a registry could be an activity.
*CONSENSUS:* We agree that we will not pursue the registry track at this
time.
*ACTION:* NS: If anyone has issues for next week, send them to me and I
will put them in the minutes.
NS: Some Microsoft people are coming to the Monday Core meeting.
PL: I believe that Outlook receiving a mail message with HTML and MathML
inside Outlook still fails.
NS: There is little progress on the horizontal reviews.
NS wants to go to CR.
<https://cryptpad.fr/#cp-md-0-zoom-intent-meeting-summary-for-3-26-2026>Zoom
Intent Meeting Summary For 3/26/2026 <https://cryptpad.fr/#cp-md-0-summary>
Summary
The meeting focused on reviewing and finalizing a draft charter for
MathML4, with participants discussing updates to scope, deliverables, and
timeline based on feedback from previous meetings. Key discussions included
whether to address Content MathML in the current specification, with
consensus to defer major changes to MathML5, and the addition of a LaTeX to
MathML macro mapping deliverable. The group also evaluated the potential
use of W3C registry tracks for intent concepts, ultimately deciding to
investigate this possibility but not commit to implementing it for MathML4.
Deyan provided an update on his Rust implementation of LaTeXML, reporting
92% of tests passing with significant performance improvements. The team
also discussed progress on horizontal reviews and noted that Microsoft
representatives would attend the upcoming core meeting.
<https://cryptpad.fr/#cp-md-0-mathml-repository-automation-discussion>MathML
Repository Automation Discussion
The main focus was on Deyan's use of Claude Code, a command line tool, to
automate proofreading of the W3C MathML repository. Deyan explained how he
used the tool to make corrections to the introduction chapter, controlling
the type of edits made and choosing not to change stylistic elements. The
tool allowed for local editing and could be configured to create commits
and push changes to the repository as desired.
<https://cryptpad.fr/#cp-md-0-latexml-project-update-and-progress>LaTeXML
Project Update and Progress
Deyan provided an update on the LaTeXML project, reporting 92% test passing
in the Opus 4.6-based REST rewrite, with 100,000 lines of code generated
from the model. Neil expressed concerns about the model's code quality when
examined closely, though Deyan noted that weaker models might make mistakes
and emphasized the benefits of working with translation tasks and having
strong compiler messages. David mentioned a change request that Neil would
review, and Neil shared an announcement about the primary maintainer of
Orca Linux screen reader incorporating Mathcat to improve MathML support,
with ongoing work on navigation and TTS implementation.
<https://cryptpad.fr/#cp-md-0-latexml-migration-to-rust-progress>LaTeXML
Migration to Rust Progress
Deyan reported progress on migrating LaTeXML from Perl to Rust, achieving a
30x speed improvement and 92% test pass rate compared to the previous
implementation. The new Rust version handles HTML with MathML output and
features a more expressive CFG ambiguous grammar compared to the previous
recursive descent grammar. Deyan indicated plans to publish the Rust
implementation under a public domain license if the work is completed
successfully, though coordination with Bruce would be necessary.
<https://cryptpad.fr/#cp-md-0-latex-and-mathml-charter-updates>LaTeX and
MathML Charter Updates
The group discussed LaTeX and its development challenges, with Neil sharing
a story about Donald Knuth's reluctance to change the system despite being
asked for improvements. They then reviewed updates to a draft charter,
incorporating suggestions from previous meetings. The discussion focused on
scope and deliverables, particularly regarding MathML, with the group
confirming they are not planning significant changes to MathML 4 at this
stage but will consider larger changes for MathML 5. Paul raised questions
about deprecated elements and potential clarifications within the text.
MathML 4 Specification Changes
The team discussed whether to make changes to Content MathML 4 during the
current specification process. David and others agreed that any significant
technical cleanups or structural changes should be deferred to MathML5 to
avoid delays, with only critical fixes being made to MathML4. The group
decided that any noted ambiguities or issues should be documented as
separate issues for future MathML5 consideration, rather than making
normative changes to the current specification.
<https://cryptpad.fr/#cp-md-0-charter-updates-and-timeline-adjustments>Charter
Updates and Timeline Adjustments
The team discussed updates to a charter, including the addition of a
suggested list of LaTeX tech macros and their mapping to intent core
concepts. They reviewed and adjusted the project timeline, extending
deadlines and setting polyfill implementations for June 2027 and MathML4
recommendations for March 2027. The group also added the PDF Association
and Unicode Consortium as external organizations. Neil sought consensus to
move the charter forward, with plans for a separate vote at the core
meeting on Monday.
<https://cryptpad.fr/#cp-md-0-registry-track-implementation-discussion>Registry
Track Implementation Discussion
The team discussed the possibility of using the registry track for intent
concepts but ultimately decided against pursuing it at this time. Neil
proposed adding an investigation of the registry track as a potential
delivery, but the group agreed to downplay its importance. David and Deyan
expressed concerns about the risks and timeline associated with
implementing the registry track before MathML 4 reaches Candidate
Recommendation status. Finally, Neil mentioned that Microsoft
representatives would be attending the upcoming core meeting, and he
encouraged anyone with agenda items to reach out to Brian.
Received on Monday, 30 March 2026 18:16:08 UTC