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

Bruce Miller wrote:
> 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:
The irony is that I don't see the space to make things drastically better. 
Having isolated markup language without some extensible publishing
framework that can handle maths (like SGML+DSSSL) can hadly considered to be step
forward. In this respect MathML stands conceptually behind both SGML/DSSSL/EMS
and TeX/LaTeX.
Achieving drastical improvement in XML + CSS approach is also difficult, 
conceptually it provides good publishing framework but technically
stands behind SGML (usually XML syntax is more verbose due to stricter rules) with DSSSL 
(no math oriented properties in CSS). However XML1.0/CSS2.1 provides
sufficient functionality to pick up right direction and add functionality
incrementally as capabilities of basic XML + CSS framework grow stronger.

> Were browser developers slow to implement MathML because MathML
> was so poorly designed?  Or because "Who cares about math?"

If non-browser implementations of MathML florish (I did not try myself
but according to comments posted on this list MathML is widely adopted)
then "who cares" argument should not be the key problem, especially when
part of browser developers are former mathematicians themselves.
In case of authoring tools, convertors and computer algebra systems
one deals with MathML as isolated markup, while browsers deals with bunch of 
complex standards that should work together. 
So both requirements and design affect quality 
of implementation. If design would be suitable for implementation in browser's core
quality would be different comparing to what we have today. 


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

Alternative exists cannonically, as a niche in XML + CSS, in this
respect there is no need to propose anything, especially when any propsal is 
considered as proprietary stuff intended to undermine existing standards.

> 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.

Semantic and structure could be orthogonal layers of the single markup.
I don't see the problem here (apart of documenting and updating huge
content vocabulary)
<formula>E = mc<sup>2</sup></formula>
Could be enhanced with content without affecting structural layer.
<formula>E = mc<sup role="power">2</sup></formula>
or more detailed
<formula>
<group role="Energy">E</group> = 
<group role="mass">m</group><group role="speed of light">c</group><sup
role="power">2</sup>
</formula>
or
<formula pronounce="Energy is mass multiplied by square of speed of
light">
<group role="Energy">E</group> = 
<group role="mass">m</group><group role="speed of light">c</group><sup
role="power">2</sup>
</formula>

> Thus, for example,
> encapsulating the base of sub & superscripts is important;
> a simple <sub> tag doesn't do this.

What if there are rules that allow you to identify base without
enclosing it explicitly?

> So, where do we go from here?  Redesign MathML from the ground
> up?  Redesign CSS from the ground up?  

Redesigning the CSS means developing completely new browsers and
changing the web. Redesigning MathML will not affect browsers and web.
It depends what is more important browsers or tools. 
For me the web is more important, there are other opinions however.

> Lobby for enhancements,
> clarifications and even deprecations in both MathML and CSS?
I don't expect to get much in this way.

>> I am 100% sure that if Math WG would do nothing at all and HTML WG would just add couple of lines
>> <!ENTITY % Misc.class "| dformgrp | dformula | formula">
>> <!ENTITY % math PUBLIC "ISO 12083:1998//DTD Math//EN" "iso-12083-math.dtd">%math; 
>> to XHTML DTD we would have much better web today. For me it is cristally clear that
>> math community would quickly embrace ISO 12083 approach.
Robert Miner wrote:
> I disagree.  I don't think this would accomplish much of anything.  
> To embrace the ISO 12083 approach, someone would have to write all the
> software to make ISO 12083 useful.  Just adding those three lines won't
> mean that suddenly ISO 12083 is implemented in IE, Safari, Firefox and
> Opera, nor would it address the really intractible problem of XHTML /
> HTML incompatibility in browsers.  Nor would it mean suddenly you get
> ISO 12083 output from Open Office and Word + MathType.  Nor would there
> magically appear publishing workflow software based on ISO 12083.  ISO
> 12083 has been around nearly 20 years, and in the last decade, I know of
> more ISO 12083 publishing software that has been scrapped than has been
> implemented.  Nor would computer algebra systems support ISO 12083 (or
> could they) nor backend CMS and assessment systems or TeX translators
> nor commercial and open source rendering toolkits.  The list goes on and on.  

a. Building user community around simple, human processable markup language is much easier, it forms quite naturally.
b. Transforming documents from LaTeX and SGML DTDs (AAP Math, Elsevier's DTD etc.) to ISO 12083 is easier then transforming them to MathML.
c. Implementing ISO 12083 basically means implementing "embellishments" model and fence resizing, the rest can be achieved by applying CSS style sheet.
d. If I am not mistaken (never tried to use) there were some WYSIWYG toys with ISO 12083 support.
e. If computer algebra systems are happy with presentational MathML, then what is wrong with ISO 12083, could it be worse?

> But the obstacles to putting in place a functionally
> equivalent ISO 12083-based system are practically insurmountable at this
> point.  You would have to write a mountain of software for a market that
> doesn't really exist.

Today it is probably too late to talk about revival of ISO 12083, I just meant that
if in 1998 W3C would not replace it with MathML, today we would have several problems less.

> As for the "math community" embracing any XML/SGML standard, I think you
> are overly optimistic there too. 
Probably. But it does not mean that usability of XML markup does not matter, and social factors 
like building creative user community does not matter either. Verbose low level markup is an obstackle.

> The problem comes when someone says, gee, wouldn't it be nice if we
> could have the same kinds of knowledge management capabilities for
> scientific documents that we have for text?  Wouldn't it be nice if we
> could build the same kinds of digital libraries for science that we do
> for other disciplines?  Wouldn't it be nice if we could build that
> distributed authoring system, or validate our documents, or
> automatically extract metadata, or publish to multiple media, or
> effective search, or make accessible versions, or interact with
> computational back ends.

And would not it be nice indeed? Why not to make things better?

> Oh, wait, there is such a standard and it's called MathML...

WOW. What's the problem then? 

> But what I see is the other side of the coin.  I don't really see any
> space for progress with browser vendors, for example, or many of the now
> largely frozen technologies with which math solutions must integrate.

Maybe boundary conditions are not perfect for integration, but they are part of the problem
and if you don't take them into account it means that you simply don't solve the problem.
Ignoring this conditions you can write arbitrary number of math DTDs, then make "political decision"
inside WG to pick up one of them and then hope that for some day boundary conditions will be relaxed
and you solution will be integrated with the rest.

> After stuggling for years and years, we do have at least *some* browser
> support for MathML.
The point is that one could simply get certain level of support for granted without any struggle,
if capabilities of existing standards would be reused wisely.

> To get even that required people like Roger Sidje
> spending years working for free on the Mozilla engine, and Design
> Science writing off a couple hundred thousand dollars in MathPlayer
> development to make a free IE plug-in. 
> And even then it required several
> letter-writing campaigns from publishing executives and prominent
> scientists to pursuade the Mozilla folks to leave on the math support,
> since at one point they told us they doubted math support was even worth
> the added download size.

Now imagine if someone would implement inline-blocks and inline-tables in Mozilla.
a. No one would ever try to remove support for this part of CSS 
b. Mozilla would gain de facto math support in XML + CSS framework
c. Whole web community (not just mathematicians) would benefit  from new features
d. You would have much more freedom in improving/changing DTD as changes in DTD would not require changes in rendering engine.

> My own view is
> that sooner or later, the basic HTML paradigm that rules the web now
> will be replaced by something else.

I expected to hear this. But if transition from HTML to XHTML already took ages and is still far from
being finished (MSIE does not support XHTML unless it is served as text/html in backward compatible way, 
Mozilla can not render XHTML pages incremantally) how long will it take to change whole web architecture?
What will you do with huge number of existing web pages?

> To me, that next paradigm shift, when it comes, will be the next
> real opportunity to revamp the entire spectrum of electronic scientific
> communication applications.  

Will I live that long?

David Carlisle wrote:
> The implication that the Working Group (Currently Interest Group) is
> dominated by makers of Commercial Wysywig systems is simply false.
In fact I don't really like conspiracy theories. So let's hope it is false.

> You typically (but probably not always) _save_ space by switching from bitmap images to
> MathML.

MathML is step forward comparing to bitmap and step backwards comparing to either TeX or old SGML DTDs.

> Do you really think making incompatible
> changes to any language after 8 years public use is something to be
> considered lightly?
It is difficult, it is unlikely to happen and this is the reason why I rarely post anything on this discussion list.


-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com

Powered by Outblaze

Received on Thursday, 13 April 2006 15:34:01 UTC