Minutes: MathML General meeting 24 March, 2022

 Attendees:

   - David Carlisle
   - Sam Dooley
   - David Farmer
   - Deyan Ginev
   - Murray Sargent
   - Neil Soiffer
   - Bert Bos
   - Paul Libbrecht
   - Bruce Miller
   - Cary Supalo
   - Steve Noble
   - Louis Maher

<https://sandbox.cryptpad.info/code/inner.html?ver=4.13.0-18#cp-md-0-regrets->
Regrets:

   - Patrick Ion
   - Stephen Watt

<https://sandbox.cryptpad.info/code/inner.html?ver=4.13.0-18#cp-md-0-announcements-updates>
Announcements/updates

David C's plan for informative part

DC: Notes on MathML (the informative part) --
https://w3c.github.io/mathml-docs/notes-on-mathml/

DC: has prepared a document that will be the informative note explaining or
supplementing the MathML specification version 4. People are welcome to
drop notes, from the various sections they are working on, into this
document.

DC: tried to make PL a reviewer. Did not work.
<https://sandbox.cryptpad.info/code/inner.html?ver=4.13.0-18#cp-md-0-go-over-progress-on-a-href-https-github-com-w3c-mathml-issues-issues-a-from-last-week>Go
over progress on issues <https://github.com/w3c/mathml/issues> from last
week

NS: The media registration type, set in MathML 3, should not be in MathML
4. The standards body referenced MathML 3.

PL: We may need to move this section to MathML 4 or remove the section
entirely.

NS: Is it possible to pull the media type out?

DC: Yes.

PL: Obsoleting things is a problem.

DC: will create an issue on this.

DC: It would be good if we could arrange with IANA to give a stable
document that just has the registration without being tied to a versioned
MathML version x. Y, then we could reference that from MathML 4, i.e.,
change the MathML3 links listed at (
https://www.iana.org/assignments/media-types/media-types.xhtml#application).

NS: Can our group create a new specification for things that should not
exist in MathML?

BB: Yes, it does not need to mentioned in the charter if it is related work.

NS: We need to talk to IANA about this.

PL: will help with IANA.

Ns: issue 294: drop maxsize=infinity. If maxsize is not defined, it
defaults to infinity.

DC: maxsize has (since the beginning with MathML 1.0) allowed <mo
maxsize="infinity" so has a unique syntax not shared with any other
attribute taking a length. As far as I can tell, the intended effect of
mathsize="infinity" is the same as not having the attribute at all as
extending the maximum amount is the default (once stretchy="true") . I
think the motivation is to be able to give a default value and/or to give a
value that can be used in the operator dictionary but no entry in the
current operator uses this value. Having custom length syntax complicates
the story re unifying length syntax with css, so I'd like to drop this.

Consensus.

SD: issues on chapter 4.

SD: Issue 278: Section 4.6 Collect Pragmatic-to-Strict Transformation

SD: Chapter 4 currently spends lots of words on the description of the
pragmatic-to-strict transformation algorithm in section 4.6 and its
subordinate rules, distributed throughout the chapter. Move the bits of
this algorithm from other sections into new subsections of section 4.6 that
link back to their original locations.

SD: This may be informative or normative.

SD: thinks section 4.6 should be informative.

SD: cannot 't see people implementing this algorithm.

DC: Move this section to appendix E.

SD: wanted the section in an informative separate document.

NS: This section may be normative.

NS: We could say that this algorithm provides a way to understand the
linkage between old math content MathML names and the open math definitions.

From Sam Dooley to Everyone: https://samdooley.github.io/mathml/#contm_cds

SD's plan: move all the algorithm into subsections of 4.6, then decide what
to do with section 4.6.

Consensus.

NS: would like to reduce the number of examples in this section.

ACTION: SD will look at reducing the number of examples in section 4.6.

ACTION: SD will look at collapsing much of chapter 4 into a table.

NS: Rename and refocus Chapter 5: Issue #281.

DC: The current name "Mixing Markup Languages for Mathematical Expressions"
Stresses the "mixing" aspect and highlights mixing content and presentation
elements, but more abstractly the main purpose of the chapter is the
general issue of semantic annotation e.g., the subheadings such as
"Annotation Framework". I propose we rename the chapter to something like
"Semantic Annotation" and describe intent here first, and then, after that
have a somewhat cut down version of the current description of
<semantics>/<annotation-xml> as a more general but more verbose mechanism
available when intent is not enough.

We discussed mixing content and presentation elements.

DC: has moved intent into this chapter.

dg: thinks that "intent" is only a presentation attribute.

NS: Why can't you use 'intent' with content MathML?

DG: thinks that "content" MathML needs to be reworked.

NS: intent gives guidance on how things should be spoken.

PL: intent can be used on content MathML as well.

DG: If you let people experiment with specifications, then they can break
things. Specifications are not for experimentation, but for specifying
standard practice.

NS: We have not thought about using intent with content.

SD: The only purpose for using intent with content is so that the intent
information can be used to give speech guidance to the presentation MathML
that comes from the content MathML.

ACTION: NS will make an issue about using 'intent' with content.

DC: se (closed) issue https://github.com/w3c/mathml/issues/289

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>