Minutes: MathML meeting 10 August, 2023

 Attendees:

   - Neil Soiffer
   - Louis Maher
   - Dennis Müller
   - David Carlisle
   - Johannes Stegmüller
   - Bert Bos
   - Cary Supalo
   - Paul Libbrecht
   - David Farmer
   - Bruce Miller
   - Murray Sargent

<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.0-rc5#cp-md-0-agenda>
Agenda
<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.0-rc5#cp-md-0-1-announcements-updates-progress-reports>1.
Announcements/Updates/Progress reports

NS and BB had a call with Philippe Le Hégaret about the charter. It appears
that math, and other working groups, do not die when the charter expires.
We cannot put out new candidate recommendations, but we can make editorial
changes in the spec. We can continue to have meetings. This change came
into effect in 2021.

NS: Philippe also said that there's a list of current recommendation
publications by the Math WG
<https://www.w3.org/groups/wg/math/publications/>. He asked us to remove
the publications that were obsolete. We have a recommendation for CSS which
is no longer valid.

NS: Philippe also discussed what needed to be changed in the charter.

JS: Gave an update on his work for intent implementation.

JS: discussed how to write h two instead of h squared.

NS: was concerned that JS's system would put too much work on the authors.
NS was discussing a variable squared case.

From Deyan Ginev to Everyone: Our group has enough expertise to publish a
sample "intent.sty" syntax to CTAN, if we wanted to.

DF suggestion for JS's example is "From David Farmer to Everyone:
\mathrm{H}^\index{2}"

DF: said that almost no one writes MathML.

NS: DG, BM, and DF are working on methods to make entering intent easier
for the authors.

DG: If you get 10 people, you pretty much have at least 2 or 3 different
competing levels of verbosity, how many macros, how precise you want to do
with the macro so you may get several different surface syntax ideas. And
you could Either decide on one or provide multiple ones and then group them
together in a style guide and publish that.

NS: that is a great idea and as obvious as you say this group is the one to
do it. We should not wait for it to happen; we should make it happen.

DC: The LaTeX project is working on pdf tagging. We will not get to math
until the first quarter of 2024. It is quite likely that all standard data
commands will get optional arguments that will allow tagging, which is
intent with the different name.

NS: It depends on how user friendly your things are, but I just see that it
seems like to me you have now been given an easy target. So, these macros
are easy to write. You just must connect each intent concept name and
property.

PL: I am a little scared to say that this is easy to expect backslash
applications.

PL: I do not expect it will be so easy to just use the macros. It will be
difficult to remember all the macro names. This is a common problem.

PL: This is one way, but there might be better ways.

From Paul Libbrecht to Everyone: One thing that might be “pangalactical”
might be that a macro is “enriched” (injected, decorated…) with intent
information.

DG: Question to David. I did not understand. So is the LaTeX team scope of
work for Q one next year on the math syntax to the level where the provided
new features will be sufficient to do intent entirely and you're
discouraging us, or do you think that would be enough to do intent and we
would not need a new package in CTAM that just provides additional
capabilities, Or do you think that a package approach where we're trying to
like coordinate on the surface and text has merit.

NS: We need a way to make it easier for tech to understand how to generate
MathML.

DC: This is a big project.

NS: You must have a bottom level structure that macros can target. If it is
too much for the authors to write with it, then it will not be used.

BM: What JS has written is like a low-level assembly language approach
which will not be used. BM has vlmf experience with this. The hard thing is
to come up with a meaningful lesson that he can convey in a few words. BM
has hundreds of special function macros. On the other hand, there is buy in
if you can make it worthwhile for the authors to use them.

BM does not remember his own macro names.

BM: Sometimes the authors will want to tweak their spacing and this can be
difficult to manage with a general-purpose macro. Michael Downs has macros
that show how this can be done.

NS: After we decide what core should be, then perhaps we can write a tech
macro package.

DG: The open set is DG's target. He is happy to have macros which only work
on that set.
<https://sandbox.cryptpad.info/code/inner.html?ver=5.4.0-rc5#cp-md-0-2-review-of>2.
Review of

charter changes
<https://mathml-refresh.github.io/charter-drafts/math-2023.html>

NS: is going to use "to be decided (TBD)" for a start date because we do
not know when things will happen. The rest of the dates are TBD plus a
number of months or years.

The interested reader should review charter section three entitled
Deliverables for details about the delivery schedule.

NS: The end date is TBD plus two years, and that is what people are
interested in—how long is this charter going to run.

NS did not change the non-normative documents to be delivered.

NS: Philippe was not happy in the sections where we did not follow the W3C
charter template. The template puts a lot of stress on testing. This is
discussed in section 4 Entitled Success Criteria. Section 4 is:

{To advance to Proposed Recommendation, each normative specification is
expected to have at least two independent interoperable implementations of
every feature defined in the specification, where interoperability can be
verified by passing open test suites, and two or more implementations
interoperating with each other. To advance to Proposed Recommendation, each
normative specification must have an open test suite of every feature
defined in the specification. The larger Web Platform ecosystem shows signs
of movement toward creating and using new MathML content, including direct
use of core features and direct use of new accessibility features by
authoring tools that create MathML content. Additionally, at least two
assistive technology products make use of the accessibility features when
they are present in MathML content. There is proven advancement and
interest by implementers in MathML Core Level 2, exploring linking, better
alignment with how the larger Web Platform evolves (Shadow DOM, Custom
Elements, CSS). There should be testing plans for each specification,
starting from the earliest drafts. To promote interoperability, all changes
made to specifications in Candidate Recommendation or to features that have
deployed implementations should have tests. Testing efforts should be
conducted via the Web Platform Tests project. Each specification should
contain sections detailing security and privacy implications for
implementers, Web authors, and end users, as well as recommendations for
mitigations. There should be a clear description of the residual risk to
the user or operator of that protocol after threat mitigation has been
deployed. Each specification should contain a section on accessibility that
describes the benefits and impacts, including ways specification features
can be used to address them, and recommendations for maximizing
accessibility in implementations. The Math Working Group expects to follow
the TAG Web Platform Design Principles.}

NS: Each normative specification must have an open suite test for every
feature to find in the specification.

NS: I am a little bit concerned about that language because I do not know
how we can design test suites for intent. This makes a whole lot of sense
for core. I am a little less clear how it makes sense for full since it is
not part of the web platform directly, so it is hard to do some web
platform tests. Philippe said it does not have to be a web platform test.
You just must have a way to test it. We must think about how this testing
can be done.

NS: That is the biggest thing that is a change in focus in the success
criteria is this emphasis on testing.

NS: Wants everyone to look at the deliverables schedule and the extra
testing, described in the success criteria section, that may be necessary.
We should say that some of this is not testable.

It may be difficult to look at a MathML string with intent and test to see
that its voice output is appropriate.

NS: The spec does not specify the content of the voice output from intent.
I do not think it should specify this output. I do not know how to write
tests for this.

DC: I think we should push back a bit on the web platform test because it
has always been a thing that MathML will not just be on the web. Philippe
is OK with that.

NS: We need to say test where appropriate because not all tests are
computer testable.

NS: People should submit a pr on these changes so that we can reach
agreement by August 17's meeting.

NS: BB, can you add the history section by next week?

BB: yes.

BB: believes he has all the charters and can use them to write the history
section.

PL: Testing speech output is the correct thing to be done for intent.

NS: If you are evaluating a spec, you can test the software but not the
spec. Just get someone to say that the spec is appropriate.

NS: The spec should have a test plan. Everyone should look at the charter
and look for problems. we need to add a testing section to the spec.

PL: has been adding things to the core intent list referenced in the August
3, 2023, minutes list of core concepts
<https://polx.github.io/mathml-docs/intent-core-concepts/>

PL: Some people might want to continue to think about what a property is. I
have not gone into extending the list yet.

NS: The goal is to approve the charter next week.