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

White Lynx wrote:
> Bruce Miller wrote:
> 
>>However,  I  think  that  your  comments  would  be  more
>> productive  
>>---  assuming  you're  actually
>>trying  to  have  a  constructive  discussion
> 
> Productive in what sense? It clear that W3C will
> not change basic design principles of MathML
> no matter how constructive, consistent and relevant
> our comments are. W3C left no space for productivity
> and we are forced to seek for niches either in current
> web stanadrds (XML/CSS/ECMAScript/DOM)
> or take more radical approach and create something
> completely new like Juan wan't to do.
> Inspite the fact that Math WG is unlikely to change
> anything I reserve right to express my concerns regarding design of MathML.

Hi George;
  Productive in the sense of working _with_ us to do
what is _possible_ to improve MathML.

Or alternatively by proposing new basic design principles
that solve the problem better. Of course, you'd be kinda
obligated to demonstrate that these new principles
actually can solve the _whole_ problem better,
or whatever you think is the important part of the problem.
And in fact, it would need to be dramatically better:
David has already pointed out the impact of making radical
changes to MathML now; that really can't be done.
A new markup will have to be compelling enough for
both authors and implementors to adopt.  Were browser
developers slow to implement MathML because MathML
was so poorly designed?  Or because "Who cares about math?"

Nevertheless, if you find that MathML is truly unredeemable,
then you really should propose an alternative, and work
to get it adopted.

As you know, MathML also has a goal of representing the "meaning"
of math, or at the least it's structure, beyond mere presentation.
You might reasonably debate whether it _should_ have that goal,
or whether it meets it, but it's there. Thus, for example,
encapsulating the base of sub & superscripts is important;
a simple <sub> tag doesn't do this.

As you also know, I share your frustration that MathML can't be
presented solely by CSS.  I wasn't part of the group at
the time, but the first MathML recommendation came only
a year (early 1998) after the first CSS recommendation (late 1996).
I doubt that it could have been forseen at that time that CSS
would become the basis for rendering engines, rather than
icing on top of it.  If it had, might MathML have come out
differently? Perhaps...  Maybe CSS would have, too.

In any case, the languages of MathML & CSS don't match so
well.  There are some `accidental' choices made in MathML
that are hard to address with CSS's Selectors.  On the other
hand, while CSS's box model comes surprisingly close, it
really isn't yet up to the task of Math either (Math in general,
not specifically MathML).

So, where do we go from here?  Redesign MathML from the ground
up?  Redesign CSS from the ground up?  Lobby for enhancements,
clarifications and even deprecations in both MathML and CSS?
 
-- 
bruce.miller@nist.gov
http://math.nist.gov/~BMiller/

Received on Wednesday, 12 April 2006 14:53:06 UTC