W3C home > Mailing lists > Public > public-pfwg-comments@w3.org > January to March 2008

Re: proposed ARIA role for math [DRAFT 1]

From: Neil Soiffer <Neils@dessci.com>
Date: Wed, 12 Mar 2008 23:50:19 -0700
Message-ID: <d98bce170803122350m38aa5438kd05c73f8b080b020@mail.gmail.com>
To: "Simon Pieters" <simonp@opera.com>
Cc: "Aaron M Leventhal" <aleventh@us.ibm.com>, brewer@w3.org, "Gregory J. Rosmaita" <oedipus@hicom.net>, public-pfwg-comments@w3.org, unagi69@concentric.net, w3c-wai-pf@w3.org, w3c-wai-pf-request@w3.org
On Wed, Mar 12, 2008 at 4:36 AM, Simon Pieters <simonp@opera.com> wrote:

> On Tue, 11 Mar 2008 06:49:42 +0100, Neil Soiffer <Neils@dessci.com> wrote:
>
> > Sorry for the dreadfully slow response -- travel is killing me.
>
> No worries, and thanks for the information.
>
>
> > FYI: TeX, LaTeX, etc.  TeX is basically a programming language, although
> > most people don't think of it as such.  Much of TeX's functionality is
> > via
> > using one of its many macro packages.  LaTeX is one such package.  Many
> > journals implement their own macros for submission.  TeX's power is also
> > what makes it difficult to import in general since you can add new
> > functionality and pretty drastically change what TeX looks like, even at
> > the
> > syntax level.
> >
> > For math, this tends not to be too hard a problem since people tend to
> > use
> > the base set of macros along with a few added by LaTeX.  Some more
> > advanced
> > math, such as tensors or matrices might have differing macro for them,
> > but
> > at least for simple matrices, I think two macros are commonly used.
> >
> > The bottom line is that for most math, you don't care whether it is TeX
> > or
> > the LaTeX extensions, or AMSTeX, or macro packages, they are similar
> > enough
> > that a single processor can handle them.
>
> But interoperability for all cases is desired, not just the common cases.


Anyone, including the document an expression comes from can create or delete
macros.  Math is "just" another part of TeX that can be modified, contain
embedded non-math TeX, macro definitions, etc.  Interoperability of
arbitrary (aka all) TeX is simply not a feasible option.  Potentially naming
the macro packages used (there can be multiple ones) might be of some use,
but as there are literally thousands of packages (tens of thousands?),
that's probably not useful either.  Most macro packages don't modify math
mode, but since you can go back into text mode in math mode, you could make
use of them.

>
>
>
> > And if someone doesn't use this
> > base set, a processor would have trouble unless they implemented the TeX
> > engine and read the macros, or built in knowledge about the functions
> for
> > that package.
> >
> > I am somewhat ambivalent about labeling the expression.  It is easy to
> > tell
> > the difference between TeX and MathML,
>
> ...and MathML content is inherently math, and hence, doesn't need
> role='math'.


It may not need it, but what is wrong with using it?  Ideally, the browser
would do the appropriate mapping for <math>, but IE doesn't do it and if I
read what Aaron said earlier, Firefox doesn't do that either.

>
>
>
> > and most new math notations for input
> > are similar to TeX.  The exceptions would be if someone used Maple or
> > Mathematica or some other computation system's language.  They are
> > somewhat
> > different from TeX.  Labeling would help in situations like that, or if
> > someone had some other format such as MathType's MTEF format which is an
> > ASCII representation of its internal format.
>
> I haven't seen it proposed before that authors should label which format
> they use for their role='math' expression. Even though that would make it
> possible to disambiguate different expression syntaxes, it's not the
> simplest solution to the problem. The simplest solution I can come up with
> is to say that the expression must be encoded as and parsed as LaTeX
> (implying leading and trailing $ or $$).


That shuts out other formats, and other TeX macro packages.  Perhaps that is
OK with others, but I'm a little concerned.  Also, one needs to be careful
when you say it is "LaTeX".  As I mentioned earlier, math mode in LaTeX is a
small part of LaTeX, which itself includes all of TeX, so LaTeX itself can
(and is) extensible.  To be truly useful, one needs to define precisely what
is allowable for "LaTeX" inside an element with role="math".  You might want
to look at something like "blahtex" (
http://www.mediawiki.org/wiki/Extension:Blahtex).  This is basically a
non-extensible list of what is allowed that corresponds to common math usage
in LaTeX.

>
>
> >> But how do you implement it? Should the UA autodetect whether it's TeX
> >> or
> >>
> >> LaTeX or something else? How are authors supposed to know what to
> write?
> >> How do we achieve interoperability? What's the advantage of leaving it
> >> open-ended?
> >>
> >>
> >> > See the thread I started called 'New role="math" in ARIA, how to
> >> author
> >> > and how browser would expose it'
> >> > In that thread we're discussing some of the remaining issues, and you
> >> can
> >> > see the current definition.
> >>
> >> The current definition doesn't seem to handle:
> >>
> >>    <object role="math" data="foo">a^2+b^2=c^2</object>
> >>
> >> Also, when would it be better to have the expression in another element
> >> than as text in the element itself (i.e. when is labelledby needed for
> >> role=math)?
> >>
> >> Finally, I don't know (La)TeX very good, but shouldn't $ or $$ be
> >> implied
> >>
> >> around the expression?
>
> (I'm still not sure about the answers to these questions.)


It could be implied if you say that only TeX is allowed.  Alternatively, you
could *define* that $...$ means it is some TeX-like syntax.

I'm a little reluctant to force a particular syntax on everyone, especially
one that is as fluid as TeX is.  On the other hand, limiting math to either
some TeX-like syntax or MathML does make life simpler for implementors.

   Neil Soiffer
Received on Thursday, 13 March 2008 06:50:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:56 UTC