Re: Minutes: MathML general meeting, 23 July

That was in reference to someone saying we could add Unicode code points to
capture the various meanings of semantics of different characters. The
problem is that there areadly too many look-alike characters, so which is
the right one to use? Does every MathML system have to know about all of
them?

There is zero chance MathML generators will generate the "right" one in all
or even most cases. There's already a big problem. For example, if you want
AT to speak "x hat", what's the character you use in MathML for the "hat".
Or for the overline? See https://github.com/w3c/mathml/issues/247 for more
examples and details.

Right now there is ":" and “∶” (U+2236) for ratio. What percentage of the
MathML out there correctly distinguishes between the two? Do we really need
another ":" for maps, another one for field extensions, etc.

    Neil


On Mon, Jul 26, 2021 at 2:01 PM Hammond, William F <whammond@albany.edu>
wrote:

> Hi Neil,
>
> Why did you say that "unicode has too many characters already" ?
>
> Thanks,
>
>               -- Bill
> ------------------------------
> *From:* Neil Soiffer <soiffer@alum.mit.edu>
> *Sent:* Sunday, July 25, 2021 3:23 PM
> *To:* www-math@w3.org <www-math@w3.org>
> *Subject:* Minutes: MathML general meeting, 23 July
>
> Attendees:
>
>    - Bert Bos
>    - Christopher Comninel
>    - Sam Dooley
>    - David Farmer
>    - Deyan Ginev
>    - Patrick Ion
>    - Brian Kardell
>    - Charles LaPierre
>    - Paul Libbrecht
>    - Louis Maher
>    - Bruce Miller
>    - Murray Sargent
>    - Cary Supalo
>    - Neil Soiffer
>    - Stephen Watt
>    - Laurence Zaysser
>
> Regrets:
>
>    - David Carlisle
>    - Steve Noble
>
> Announcements/updates
>
> CS: Reminder to Bert to send Cary the W3C Template mentioned in the last
> week's meeting.
> Action Item followup
>
> NS: No consistent support for ARIA on MathML in alternative AT engines,
> see email on the mailing list for details.
>
> LZ: Is aria-description handling similar to footnotes in that they don't
> happen by default?
>
> NS: Tried alternative keys as well, but no meaningful behavior was
> produced for Neil's specific keyboard setup.
>
> Using ARIA for intent Follow up on Deyan Presentation last week on his
> idea of using ARIA Where do we go from here/how do we make progress?
>
> NS: If the aria behavior is currently not well-defined, this could be a
> place for the Math WG to provide that meaningful definition, going forward.
> Especially in order to avoid problematic AT results with Braille.
>
> *ACTION ITEM:* NS: Will begin to write a report on where we are, and
> where we want to go. We will use Google Docs for our report.
> MathML in the wild -- see mail archive thread
>
> https://lists.w3.org/Archives/Public/www-math/2021Jul/0051.html
>
> DF: three categories
>
>    1. tools that do the best they can to meet the spec that we come up
>    with
>    2. all the stuff in arXiv and elsewhere. That won't be improved.
>    Should be spoken character-by-character
>    3. remediated math. Someone can add info such as "number theory paper"
>    to my writings.
>
> LZ: You would have to come up with standards for the separate subject
> catagories.
>
> SW: There is a difference on how you would want to pronounce things,
> depending on area. For example, in probability E be read as "expectation",
> but in some areas of physics as "energy". Would we have defaults or have to
> tag every instance in a section?
>
> NS: Anything we do for math has to be contained within math. Math is one
> topic no matter what kind of document we are processing.
>
> MS: Two kinds of math speech: coarse-grained or fine-grained. Most people
> talk about coarse-grained. If you are reading a p in math, you want to call
> it p and not probability in fine-grained navigation.
>
> PI: We could have a in which we could specify the local type of math. But
> that's not going to happen. So one could have settings on a math element
> that persisted until another math element turned them off. But that's
> demanding technically. So the math elements would have to have repeated
> values of such intents. Is that the only way we have? Does each object have
> to have its own math setting?
>
> PL: It's difficult to specify all fields of mathematics. Accessibility
> tools read the DOM and can have intent injected with JavaScript.
>
> NS: The accessibility tree is ignored by the AT. The AT looks at the DOM.
> MathML lives beyond the browsers, MathML is used for many types of
> documents besides web pages.
>
> DG: We need to develop a list of tools where we want to be able to specify
> the document forms we should be able to process.
>
> NS: The core work is browser related, but MathML lives in a bigger world
> that has other formats than browsers. WCAG is an example of a group that
> goes beyond the browser in their rec. They basically specify the
> aspirational goals of accessibility and have different documents on how to
> obtain that in HTML, PDF, etc.
>
> LZ: Their specification separates the stable from the unstable practices,
> which is great.
>
> BK: ARIA is similar in that they talk about OS-specific accessibility and
> how to map HTML to that.
>
> DF: 1. perfectly constructed MathML as per spec. 2. the MathML that is out
> there now and unaware of what we are doing. 3. the current MathML which
> tries to follow some of the rules we have specified.
>
> NS: We have constructs like overbar, but what character represents this as
> part of mover? Is it "-", "_", some other Unicode char? Which one will
> trigger "x bar" as speech? In general, should the spec say what character
> should be used for common situations. MathML 3 says this for primes and
> degree.
>
> NS: Going back to a comment Deyan made on the mailing list, if you type a
> colon, does it mean an actual colon or does it stand for a ratio. You would
> have to have an intent attribute to make this clear.
>
> LZ: We must be able to deal with characters that look like one another
> using intents.
>
> DG: Unless we receive an offer from Unicode to include at least another
> couple of thousand characters, (that look like existing glyphs, but have
> dedicated mathematical intent), we don't have enough characters to rely on
> Unicode as a primary solution.
>
> NS: Unicode had too many characters already.
>
> SW: discussed using style sheets to give the meaning of symbols for
> different subjects. This may be beyond our scope.
>
> NS: If the document is in english, then the math will be expected to be in
> english.
>
> BM: The emails discussed different levels of accessibility. The bottom
> level has no interpretation. Higher layers may be topic specific. Should we
> break down our specifications into layers?
>
> NS: there is nothing we need to do to read out the raw form without
> interpretation. People would like to have semantic interpretation. There
> have not been formal studies on this topic so maybe people just *think*
> they want a semantic interpretation.
>
>
> <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>
> <#m_-6684927564773425249_x_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>