Minutes: MathML general meeting, 17 June

 Attendees:

   - Bert Bos
   - David Carlisle
   - Sam Dooley
   - David Farmer
   - Deyan Ginev
   - Paul Libbrecht
   - Louis Maher
   - Murray Sargent
   - Cary Supalo
   - Neil Soiffer
   - Moritz Schubotz
   - Laurence Zaysser
   - Stephen Watt
   - Steve Noble
   - Brian Kardell (late)
   - Bruce Miller

Regrets:

   - Christopher Comninel

Thanks to Louis for once again taking notes.
Announcements/updates

   - reminder to link your github account to your w3c account as per Bert's
   email


   - progress moving repositories

NS: see https://mathml-refresh.github.io/ for all the links

PL: support for media types in browsers (comment of Brian
<https://github.com/w3c/clipboard-apis/issues/141#issuecomment-862519013>).
Core spec -> Draft Spec

DC: is trying to get the MathML core through the rule process. Can ask BB:
to move it to the FPWD.

NS: We need to check the web platform tests. The tests must be in sink.

NS: Planning first core meeting for the last monday in June 28. Always use
the last meeting in the month for the core meetings.

DC: ask him if you want push access to the Mathml refresh repositories.

NS: has the core spec passed all the W3c requirements?

DC: The operators dictionary issue must be settled first. PULL Request for
operator dictionary https://github.com/w3c/mathml-core/pull/35
Intent discussion -- defaults semantics:what defaults do we want?

NS: we will need test using real world data.
how do these interact with multiple ways of writing mrows/should operator
dictionary be used for a canonical form?real world data?tests for
implementation?

DG: find the core list we all can agree on. The core list will be developed
by considering the math used in grades 1 through 14.

DG: avoid the grammar discussion. The simpler, practical, alternative to
defining a full grammar is to have a list of notation selectors with no
overlap.

DG: in the email thread Neil mentioned he hopes to leverage the operator
ditionary. But since we have no expression test bed, we do not know what
exactly is covered by the operator dictionary. We could eventually realign
with it after we have a finalized defaults deliverable. But it's a bad
vehicle, also since Frederic reminded us it has immediate implications for
browser vendors.

DG: there needs to be a way to turn off the defaults for some cases.

SW: there needs to be a way to turn off defaults either in a fine-grain or
coarse-grain mode. For coarse-grain defaults, it would be useful to be able
to set them as well, e.g. all bold face symbols are vectors.

DG: Providing an "intent" annotation is the fine-grained override over the
defaults. An explicit attribute is always consulted. The authoring tools
could turn off things in the coarse grain case, if we had a switch to flip.

NS: It is better to remediate in many cases instead of turning off the
defaults globally. You can use global replace to put intents to override
the defaults. Using subject area might make this easy in many cases.

DF: Show a use case of why you would not use the default. Also, if people
redefine things in the middle of a document, the document becomes difficult
to understand and maintain.

DG: Example: arXiv has decidedly higher than K-14 content. Defaults could
be designed to cover exactly K-14. Hence, I would always want defaults
disabled over arXiv expressions. But I still won't know what the intent *really
is* as a publisher that generates MathML without the author.

PL: global deactivation does not make sense for symbol defaults.

DG: the default fallback is to use directly the presentation MathML layout
tree with the Unicode readings of the symbols. That is understandible to a
human reader, more so than hearing a *wrong* default in a highly technical
expression. A sentiment Louis has expressed in past meetings.

NS: Deyan doesn't like this idea but... Maybe use subject area to help the
defaults? Use subject "unknown" saying that there are no defaults.

LZ: we may have three layers for defaults for: hearing, listening, and
ordering.

DG: asks that LZ: send him an example.

From Deyan Ginev to Everyone: Reposting Laurence's example indented if
you'd like to examine the full tree:
https://gist.github.com/dginev/06d18f4f2fb03623abff935e24b08b9e

MS: Likes document-level defaults for math. Linebreaking preferences would
be an example. This should work for intent also.

NS: math defaults have to be added to CSS or HTML. Linebreaking is one such
example.

MS: use an empty math tag that gives the defaults you want to use.

NS: anything presentational will be in CSS.

MS: It would be good to have document-wide math defaults perhaps given by
an empty math element. Math document properties are discussed in
https://docs.microsoft.com/en-us/archive/blogs/murrays/default-document-math-properties

NS: we are using private properties in CSS.

BM: authors could declare private properties in CSS. We can declare a
custom property in CSS.

BK/BB: You can use custom properties/houdini potentially (
https://developer.mozilla.org/en-US/docs/Web/API/CSS_Properties_and_Values_API/guide)
to define a kind of shared stylesheet and express values which *could* be
future CSS properties or just want to use the same parsing/architecture and
so on.

DG: Maybe a good time to express my preference to keep the "defaults" part
of the specification as simple as possible and *not* allow any
customization beyond on/off. Authoring tools are better positioned to
provide customization support, e.g. latexml has been able to provide
section-scoped macros for a decade.

SW: We must not forget computation as a main design goal of MathML and
design "intent" in a way that hinders that.

DG: We discussed the connection to CMML extensively in 2020. We've
tentatively decided Content MathML will be frozen for this release, and
computation is outside of our design requirements for "intent". The main
focus is accessibility.

SW: Mathematica seems to have used presentation MathML for computation.

DG: Could we invite them to the group? Best if they present their case
directly.

NS: will reach out to the mathematica group for a representative to the WG
as an invited expert.

LZ: if we use content semantics we will not have any accessibility issues.

BM: content MathML solves ambiguous issues, but it is difficult to produce.

DG: Parting words to counter-point Bruce: Fully formalizing to Content
MathML is a distraction for accessibility. A human reader can associate a
notation with its natural language spoken/written form as soon as someone
pronounces it for them, much before there is a full formal understanding.
Accessibility's focus is on enabling better communication between writer
and reader, focused on the linguistic form. And we can enable that with
very little effort, compared to a formalization project.

NS: we have agreed to publish the first fpwd. People have until June 23 to
submit changes to the fpwd. Please send corrections to DC.

NS: We will *not* have a meeting next week.

DG and NS need to have discussion on defaults.

NS: will write a wiki containing a list of what people volunteered to do
for the various items the WG has been chartered for.

NS: will send out a core meeting announcement.