The problem with requiring MathML for all math expressions is that users are likely to type simple expressions such as "2+2" or "a < 3" into a document editor directly and not invoke its math editor.  This would be translated into regular text and not recognized as math.  Something this simple would likely be spoken correctly, could be navigated OK (there's not much to navigate), and textual synchronized highlighting would probably work.  However, it would not translate to into a Braille math code.  More complicated linear expressions such as a long (linear) multivariate expression would not be easily navigatable because there would be no structure to it.

We require authors to tag headers of various sorts, so it is certainly reasonable to require them to at least tag expressions as math.  If one was careful and created a "formula" style in (at least) Word, then that style gets carried through to the PDF.  MathML would not be generated although it is not hard to imagine a tool could patch the instances up.  Alternatively, users could add the MathML tags themselves, although that would rapidly become tiresome.  Without the conversion to MathML, assistive technology would need to deal with both MathML and "simple" math.

As noted in the discussion on "What is 'simple' Math", there could be ordering problems so the apparently simplicity is probably an illusion.

If we require MathML (vs simple math), there is a single target for all tools.  This simplifies the development of math tools for PDF.  Also, there is an economic argument:  if you dilute the market by allowing (say) 50% of the math to be non-MathML, you've removed half the incentive for a company to develop a tool.  For example, there would be less incentive to develop a tool to convert "simple math" to MathML, making the development of such a tool less likely.

Sense of September 9 teleconference:  allow only MathML (no simple math).

Below are notes from some discussion that occured in May, 2006.  Summary by Neil Soiffer:

• Simple Math
  Some math such as "a+b" is linear and is easily represented using Unicode.  This is "simple" math, although other proposed definitions of "simple" are given.  Joe and Jacques think "simple" math might also include subscripts and superscripts (presumably because these can be generated by Word and other editors without the use of a math tool).
  
  Jacques Distler and Joe Clark argue that authors may be lazy and not use a math editing tool (MathType, TeX, ...), so simply allowing an outer layer "formula" tag to say "this is math" is better than nothing.  Neil takes a perfectionist line and feels that a single method for tagging is best.  Subscripts and superscripts present a particular problem if included in simple math because they need to be tagged, and this introduces a second set of tags.

• Complex Math
  Complex Math includes fractions, radicials, and tabular layouts like matricies and determinants.  These definitely need to be tagged.

• Really Complex Math
  Jacques pointed out that some areas that MathML can't deal with (eg, tricky communative diagrams).  Neil said that these would probably require an alt tag.  In Braille, these would be rendered as tactile graphics because Nemeth code and other Braille math codes don't have a way to describe the complex layouts

• One Standard
  Joe proposed allowing for more than one way to tag complex math.  Both Jacques and Neil think getting people to implement a single standard will be work; they feel getting people to support two standards isn't going to happen.  Both Jacque and Neil agree MathML is a good choice for the standard.

• Murray Sargent's Unicode math proposal
  Murray Sargent's Unicode math proposal (which includes 2D formatting characters) was considered a poor idea for math representation by Jacques, Neil and Paul Topping.

Notes from our conversation with Prof. Jacques Distler:

Joe recommended we speak with him since he is one of the few people in the world actually using MathML in the real world.

Does simple math require MathML?

a + b = c
a plus b equals c
H2O   X

At what point must we start using MathML instead of regular text? Can we define a boundary?

Joe: If you can use Unicode characters to represent an inline mathematical equation without a hard line break,
Neil: Must somehow tag it as <math> so that it can be properly represented in Braille.

 inline vs. block (display) math

Loretta: <formula> tag already exists and anything contained within will be treated like an image in that it won't be reflowed.

Jacques: the vast majority of math in PDF files is published using TEX.

Notes from Jacques:

There's really a 2-dimensional grid here: inline vs. display (or "block") equations and MathML vs. a plain string of Unicode characters.

 In TeX, inline equations are demarcated by $...$; display equations are demarcated by $$...$$. Tagging such things as equations (like tagging the output of Word's equation editor) is trivial and should be required.

 Now, it's always true that a lazy author can write "a+b=c" instead of "$a+b=c$" (or the Word equivalent), and there's no programmatic way to know that the resulting string of Unicode characters is an equation which should have been tagged. C'est la vie.

Whether a MathML version of the equation ought to be required really depends  on the complexity of the equation. If it can be represented as a simple string of Unicode characters (i.e., requires no more fancy positioning than "this is a subscript" and "that is a superscript"), then a MathML version is optional.

 Most equations of any complexity, however, require positioning characters in a 2-dimensional space (think about matrix). That clearly needs to have a MathML equivalent. (This is slightly different from Joe's "hard break" criterion. Even inline equations may involve fancy positioning which defies a simple representation as a string of Unicode characters.)

As I mentioned, there are equations of sufficient complexity that MathML is inadequate. As an example, consider the commutative diagrams produced by the "dcpic.sty" package for LaTeX, such as the ones in http://arxiv.org/pdf/hep-th/0206242   (look, for instance, at equations (2.7)-(2.10) on page 5). I don't know what to recommend in such cases. Maybe MathML 4.0 will be able to handle such things.

 We discussed alternate markup languages to MathML (e.g., TeX itself). But, as Neil argued, from an implementor's point of view, being able to handle one markup language (MathML) is hard enough. Allowing authors to choose between multiple markup languages means implementors have to be able to handle all of them. Not gonna happen.

TeX, in particular, is HARD to parse. And, with the addition of external macro packages, like the aforementioned dcpic.sty,  infinitely extensible. Here's the rather elegant, but nonstandard, dcpic syntax which produced equation (2.10) in the above pdf file

\newcommand{\complex}[1]{\mathcal{#1}^\bullet}

\begin{equation}
\begin{aligned}
\mbox{
\begindc[6]
\obj(25,25){$\complex{E}$}[E1]
\obj(20,18){$\complex{E}$}[E2]
\obj(30,18){$\complex{F}$}[F1]
\obj(15,11){$\complex{F}$}[F2]
\obj(35,11){$\complex{F}$}[F3]
\mor{E1}{E2}{$\mathit{id}$}[\atright,\dasharrow]
\mor{E1}{F1}{$s$}[\atleft,\dasharrow]
\mor{E2}{F2}{$s$}[\atright,\solidarrow]
\mor{E2}{F3}{$s$}[\atright,\solidarrow]
\mor{F1}{F2}{$\mathit{id}$}[\atleft,\solidarrow]
\mor{F1}{F3}{$\mathit{id}$}[\atleft,\solidarrow]
\enddc
}
\end{aligned}
\end{equation}

Embedding that LaTeX source code in the PDF file would not buy  anyone anything.

So I'm with Neil in recommending that you mandate the use of MathML for those equations which cannot be adequately represented as ordinary Unicode strings. The very rare edge-cases which cannot currently be represented in MathML will probably have to remain inaccessible, until the technology catches up.

If some better non-proprietary technology comes along in the future, you can always revise the Spec...

Notes From Neil

I was tasked to summarize what we discussed on the call, but Jacques beat me to it and did a nice job.  I'll add a little here that mostly reinforces what Jacques says, but has some of my own opinions also.

First and foremost, if there isn't a tag that says "this is math", it isn't math.  It doesn't matter if it looks like math, it simply won't be able to be translated to Braille properly if it isn't tagged as such, and there is no way for any math accessibility tool to be invoked by AT software if it doesn't know it is math.  For speech, this might not be a problem with something simple, but it is a problem for a refreshable braille display.

 Given that it has to be tagged, the next question is "what are the tags".  I can not over emphasize what Jacques says about the complexity of handling more than one standard.  Math is complicated enough -- requiring two implementations doesn't benefit the accessibility community because there will never be code that implements two complete solutions (especially when dealing with something open-ended as TeX is).  There was some early seminal math accessibility work done by T.V. Raman that used TeX as its source, but these days, almost all math accessibility work uses MathML.  For this reason, and for compatibility with the (not yet finished) DAISY Math Extension which uses MathML, it really makes sense to focus on the standard for PDF/UA on MathML.

One area that I differ with Joe and perhaps Jacques is "simple math".  Some math can be represented without invoking/using a math composition language like MathML.  Unicode has over 2,000 symbols that are meant to be used for math, and even using just ASCII characters, one can write "a+b<c".  This isn't great typography:  the "a", "b", and "c" should be in italics and the spacing around the "+" and "<" should really be increased.  Nonetheless, assuming someone somehow got that to translate into PDF with a "formula" tag or some such wrapped around it, it could potentially be considered math.  I feel that allowing "Unicode math" is a bad idea for the following reasons:

1. This introduces a second language that must be translated.  Although it is not a complicated second language, it does require effort to convert this to speech with prosody (pauses, pitch changes, etc) or to convert it to Braille.

2. There is no clear dividing line when MathML should be used and when Unicode math can be used.  Joe suggested one possibility on the call: "no hard line break" and can it can be represented using Unicode characters.  However, this leads to messes such as math accessibility software needing to deal with weird Unicode compatibility chars such as the superscripts and subscripts block (U+2070) or the "vulgar fractions" in the number forms block (U+2150).  It is going to take a really comprehensive piece of software to cover all of the "weird" Unicode blocks.  A stronger rule is needed
   
   Appendum 8/8:  If subscripts and superscripts were part of simple math, they would need to be tagged in some way so that AT software would be able to figure out that there is a script.  Without the tagging, the AT software would need to look at graphic positioning of the characters, which I think is too hard a problem.

3. Authoring tools such as TeX always require the math to be inside of an inline or block math mode (assuming good authoring practices), so they would never generate just a Unicode representation.  Hand coding of PDF is not done by mortals, hence, I don't think there is a compelling reason to have a "simpler" mode for PDF.  Because of the "second language" problem mentioned in '1', there is a strong argument against this idea.

4. Although not an accessibility argument, Unicode math typically results in low quality math typography such as the "a+b<c" example discussed above.

Joe raised two other points on the call.  One was what to do about math that MathML doesn't handle easily or at all.  I think those tend to be more esoteric math.  In those cases, my feeling is that you will have to resort to an image with alt text.  In the case of Jacques' example, this does not pose a problem for braille because commutative diagrams are (AFAIK) not part of Nemeth code and would typically be make accessible as tactile graphics (ie, images).

The other point that Joe raised was what to do when, sometime in the future, some other encoding supplants MathML as the standard to use.  I don't feel this really is any different than worrying about a successor to Unicode.  PDF/UA needs to be flexible enough so that when some underlying technology changes, it too will change.  Indeed, PDF/UA is based on a particular version of PDF and as PDF changes, PDF/UA may need updates -- some probably small and some probably large.

 "Plain Equations" (a response from Jacques)

Neil wrote:

Hand coding of PDF is not done by mortals, hence, I don't think there is a compelling reason to have a "simpler" mode for PDF.

Hand coding of PDF  is not done by mere mortals, but hand tagging is . Consider a scenario where an author prepares a document without the aid of any special mathematical authoring software, and then uses Adobe Acrobat to tag the resulting PDF file.

The document contains some simple equations of the "a+b=c" sort. Yes, the typography will be crappy, but if that doesn't bother the author, it's really not our concern. Should we mandate that equations be tagged, and should we demand that, if something is tagged as an equation, a MathML equivalent be supplied?

If you demand both, I can guarantee that the author in question will not tag "a+b=c" as an equation. Generating a MathML equivalent is too much trouble (if, at this stage, it's even possible at all). If you allow a "simple mode," there's a  good chance (not a great chance, but a good one) that the  equation will be tagged by the author.

As an implementor, you're really no worse off with a "simple mode" than you were without one. If you apply no special parsing rules, and treat "simple mode" equations as unicode text, then you have just reproduced the status quo ante, where "a+b=c" was untagged. If you apply any special parsing at all to "simple mode equations", it can only be an improvement over the status quo ante.

Note that this really does not affect users of mathematical authoring software (TeX, etc.). Their equations are all clearly demarcated as such, and there's no reason their authoring software would single out some equations as "simple", and treat them differently.

Having said that, pdftex does not produce tagged PDF (at all), let alone embed MathML equivalents for equations.

There's a long way to go on the authoring-tools side...

Having made a pitch for a "simple equation" mode, I realize that the question is really a philosophical, rather than a technical one: does one take a meliorist stance (tagging unicode strings like "a+b=c" as equations is better than not tagging them)  or does one take a perfectionist stance (equations should always be treated specially - laid out using mathematical typographic conventions and supplied with MathML equivalents).

 On that score, I'm really an outsider, looking in. Y'all need to decide (realizing that the perfectionist stance really makes a high demand on the authoring side).