Minutes: MathML intent meeting 19 Aug

 Attendees:

   - Bert Bos
   - Sam Dooley
   - Brian Kardell
   - David Farmer
   - Deyan Ginev
   - Paul Libbrecht
   - Louis Maher
   - Bruce Miller
   - Murray Sargent
   - Neil Soiffer
   - David Carlisle
   - Stephen Watt

Regrets:

   - Laurence Zaysser
   - Patrick Ion

Announcements/updatesBB: sent out the following note.

The TPAC meeting organizers are asking all WGs if and when they want to
hold meetings during TPAC (25-29 October), and to fill in this wiki page:

TPAC Meeting Scheduling Form
<https://www.w3.org/wiki/TPAC/2021/GroupMeetings>
The deadline is September 10.

NS: I have reached out to the ARIA group twice about a joint meeting but
still haven't heard back.

NS: Do we want to have a half-day working meeting to go over the MathML
spec 3 and start converting it to MathML spec 4 document?

BB: TPAC is an opportunity to get observers who might want to listen to us.

NS: we could have a couple of hour-long meetings to discuss issues. A one-
hour meeting might be more attractive than a half-day session.

DC: Will not have multi days off from work to attend TPAC meetings this
year. An hour here and there would be more practical.

BK: was in favor of a couple of hour-long meetings.

BK: would like to talk about what is in math level one core and what is not
in level one.

BK: we have many issues like what do we do about shadow dom.

NS: a different group of people would be interested in intent than would be
interested in core level one issues.

BK: the challenge with intent is that it is big and complex. There is a
group of people who will have no interest in this discussion.

PL: Core and Intent are WG MathML internal topics. People may not come to
meetings with the words "intent" and "Core level one" in the meeting titles.

Some people might think that MathJax may make MathML unnecessary.

DC: Call the core discussion something like "How To Get MathML In To
Browsers".

BM: Use intent as a code word for semantics.

BM: We would like to brainstorm with the greater W3C community to see if we
are leaving something out or are we taking wrong approaches.

BK: have a session on gap analysis for Math accessibility.

SW: What does the w3 think about unsighted issues versus accessibility
issues? One unsighted issue could be speech capability on the web. Is the
MathML WG addressing unsighted issues like proper speech pronunciation?

BK: there will be four meetings about speech on the web. BK is giving one
of those talks. These groups may not be coordinating with one another in
their work.

NS: There was a CSS speech module which was never fully implemented.

BK: asked two questions: Is what we are doing more complex than the issues
that the other W3C groups are working on, and how does what we are doing
coordinate with what the rest of the w3C is doing?

PL: is there a list of meetings we should be watching?

NS: there will be a list of public meetings once everyone has scheduled
their meetings. For the most part, these meetings will be open to anyone
who wants to attend.

BK: we should coordinate on which MathML WG members go to what meetings.
Some other topics of interest to us are ARIA, CSS and AOM (accessible
object model).

BK: Maybe we should have an accessibility object model. We should attend
this meeting.
Drop search from WG goals (and in particular, from the gap analysis)?

NS: Showed two ways to do math searches. The first is by searching for text
like "Bessel functions". A second method is to search for equations. The
text searches work, the equation searchs sometimes work but were less
successful than text searches. There are specialized math search engines.

MUS: suggested turning equations into indices and doing searches on these
indices.

NS: Should we be doing something to make search easier?

MUS: use MathML and turn it into indices for searches.

BM: two aproaches to math search: Base your search on the information in
content MathML or base your search on indices.

LaTeX can be tokenized. You can walk the MathML tree and index it.

The search engines do not craw the web and turn equations into indices.

NS: Largely we do not need to do anything for search other than what we are
doing for accessibility.

BK: Seems like we are talking about 3 things here. 1) evaluate the status
of searching - can it be done today - the answer is yes, we have data. 2)
Would intent metadata or something *potentially* help it? Seems easy to say
"Yes, probably" but that isn't the driving factor here and we don't
actually have 'proof' yet for reasons discussed. I think that's not our
primary goal. 3) It is interesting to think about "how special math is, and
why?" There are many kinds of things you can't search for, for example lots
of programming constructs and topics that affect all sorts of people and
have a number of similarities. Seems harder to argue that Math (which is
underinvested in historically) just *needs* special complexity here without
data or proof.

SW: We want to Normalize math so that it can be searched for. If there are
several ways to mark up a thing, we should normalize the process so that
there is only one way to mark it. This would allow us to turn math into
indices for search purposes.

NS: should we try to normalize MathML? Do we want to have normalized MathML?

DG: Meta data helps get higher quality searches. We should not be talking
about this without the venders in the room. (SCO means search engine
optimization.)

DG: Search engines ignore text that is not visible on web pages. Such
things like attributes are ignored for search because people used to hack
the attributes to make certain web pages more popular, or to insert items
not related to the web page.

PL: The equivalence of two things is defined by the situation of use in
many different cases. is "j" current or an index. No way to support search
engines accept through normalization.

DG: it is more harmful than useful to create standards that are not used.
Make sure they will be used before placing the standards in specifications.

*ACTION ITEM:* DG: will send PL: information on search.

SW: We have not decided to work on the normalization issue. There are many
characters that look similar to one another but have different uses, and
people ignore the differences.

MUS: has contact with the Bing search engine people. He could encourage
them to work with us.
This might encourage google to also work with us.

BM: We should not get too far in specifying what a pure math search engine
should do.

BM: Normalization has been suggested for many different topics like
searches, accessibility, CSS and other issues.

NS: Do we need to discuss search in the gap document?

DG: what is out there works pretty well. Perhaps we could add meta data
that might be useful if other people pick it up.

BM: WE should mention search in the introduction as a reason for improving
accessibility.

NS: Should we drop search? Our consensus is yes. WE will just mention that
accessibility could improve search.
Gap Analysis Doc

The Gap Analysis document is at Gap Document
<https://docs.google.com/document/d/1Pzsf2dqTkbYXFmoKCLzvtrNERNmtF2MHX1WtugB3PfA/edit#>

NS: The parallel section is generating controversy. What should we do about
this?

SD: have one section on parallel markup and another section on intent
attribute, and one section on vocabulary.

NS: MOS: might not want to refer to open math content dictionaries. He has
had better luck with wiki sources.

NS: would like to see a larger example than our (a,b) case. He would like
to show nesting.

DG: and others, decided to have the same three examples in each section of
the Gap document. This would clarify how each point is implemented.

DG: has three examples in the ARIA portion of the gap document. He agreed
to make some of these examples more complicated so that they could be used
in each portion of the gap document.

*ACTION ITEM:* DG and NS will work together to make the three ARIA examples
more complicated.

*ACTION ITEM:* NS: what is our work item for next meeting? Have every
section have a reference to DG's three ARIA examples. If necessary
reference outside documents to demonstrate these three cases.

DG: we need an editor to resolve edits.

NS: does not feel comfortable with resolving issues involving parallel
disagreements.

*ACTION ITEM:* The parallel authors will resolve the edit issues among
themselves.

Our next meeting will be on September 2, 2021.