W3C home > Mailing lists > Public > www-math@w3.org > April 2006

Re: Technical reasons for some options taken on design of MathML

From: <juanrgonzaleza@canonicalscience.com>
Date: Fri, 7 Apr 2006 08:10:38 -0700 (PDT)
Message-ID: <3970.217.124.69.246.1144422638.squirrel@webmail.canonicalscience.com>
To: <www-math@w3.org>

Mikko Rantalainen wrote:

[snip]

> Okay, could you point us to correct basis for over and under scripts?

Well, in the ASCII rendering the base for over is "base" and in your
MathML example the base for over is ("base" + "sub" + "sup").

> If you render the above MathML example by e.g. Gecko rendering
> engine you end up something fairly similar to above ASCII presentation.

And in some cases <msub><msup> can render similar to <msubsup> but we need
the latter, ok?

> If you want to transfer more semantics you have to give us more
> information but just the ASCII rendering of the end result.
>

As already explained I used an ASCII art contained in a *standard* for
math. Any case the point is not possible misunderstanding about above
ASCII art did mean. The important question is that MathML 2.0 cannot
encode that (like cannot encode other things).

> Are you asking for a way to markup a multiscript where you have
> scripts at N, NE, SE and S locations (compass directions)? Would you
> be happy with a multiscript construct that allowed 8 positions (N,
> NE, E, SE, S, SW, W, NW)? Or would there be need for more script
> positions?

No! I was not asking for. That IS already solved by available *standards*
previous to MathML.

Today, I do not know of needing for more script positions, but if tomorrow
more were needed would be relatively easy extend SGML model because solid
markup design. In MathML you would need of dozens of new tags and novel
content/processing models.

>
> Multiscript rendering vs. actual logic
>
> I believe that there's always some logic for multiscript rendering
> that would result from some kind of nested elements. If you have
> rendering such as
>         sup
>     BASE
>         sub
> then it's always logically either "(BASE_sub)^sup" or
> "(BASE^sup)_sub. Usually the former.

No!

(BASE_sub)^sup

and

(BASE^sup)_sub

and

BASE_sub^sup

are three different things!

Only BASE_sub^sup corresponds to ASCII

    sup
BASE
    sub

This is reason of MathML difference between

<msup><msub>BASE sub</msub> sup</msup>

and

<msub><msup>BASE sup</msup> sub</msub>

and

<msubsup>BASE sub sup</msubsup>

Others markups also differentiate (including TeX and, of course, ISO
12083). The PROBLEM with MathML is the poor design model for scripts,
which is not easily extensible except by complicating a lot of the DTD and
the parsing. Previous standards did a better work.

> Likewise, if you have markup like
>     ____
>     BASE
>         sub
> it's either "(BASE with overline)_sub" or "(BASE_sub) with
> overline". I've yet to see a construct where you *logically* have
> "BASE with both overline and subscript".

Your example would be interpreted like "(BASE with overline)_sub". The
render of

"(BASE_sub) with overline" would be more close to

     _______
     BASE
         sub

Now, I cannot remember of any construction special kind you are requiring,
which, of course, does not mean can it be useful in some discipline.
Simply I do not know.


> There's, of course, the
> rendering. I understand the need to render
>         sup
>     BASE
>         sub
> instead of
>            sup
>     BASE
>         sub
> where the superscript would be leftwards from "BASE_sub"
> combination. However, it's only rendering detail, the logic still
> applies that it's (usually) "BASE_sub" to power of "sup".
>
> --
> Mikko
>

You are saying is not compatible with both computational and notational
issues. One does not render your first example _instead of_ second. That
is not true. Two ASCIIs are usually different things! Already in pure
mathematics

  k
T
 i ,

 k
T
  i,

and

 k
T
 i

are (usually) three different mathematical objects, *none* of them meaning
"BASE_sub" to power of "sup" you wrote. Therefore, you are forced to
render them in three different ways.


Juan R.

Center for CANONICAL |SCIENCE)
Received on Friday, 7 April 2006 15:10:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 February 2010 06:12:58 GMT