OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] [SUMMARY #1] Why is there little usage of XML on the 'visi

[ Lists Home | Date Index | Thread Index ]

David Carlisle said:
>> --text follows this line--
>> The advantages of unified framework are inmense. For instance, instead
>> using SVG for graphics and p-MathML for mathematics one prefer an all
>> SVG approach.
> hmm, perhaps, but now, today, If you use MathML you can just "cut and
> paste" mathematical expressions from popular browsers (IE, firefox, in
> particular) and drop the expressions into popular mathmatical packages,
> (maple, mathematica) and have the expressions understood as
> mathematics.

In how many cases? How you know i did an experiment about that this year.
I generated MathML code for \dot{q} using several MathML tools (ORCCA,
IteX, ASCIIMath) and next submited the MathML code to online Mathematica
5.2 and two were rejected offering errors and other was incorrectly

It was a simple \dot{q} not a complicated two-lines quantum equation in

> The SVG may (see below) render OK but as far as any further
> processing is concerned is likely to be essentially the same as an
> image. Of course a browser that has SVG rendering capability (whether as
> part of the core code or as a plugin of some sort) may use SVG
> internally to render all sorts of things, including MathML, but that
> doesn't negate the benefits of serving the Math-specific markup to the
> client.

Use content markup for the encoding of the math, SVG for the rendering.
For instance instead supporting OpenMath + c-MathML + p-MathML + SVG,
browers would prefer OpenMath + SVG instead duplicating again and again
the same code (this is a real point against real lack of support for XML
nobody addresed still in this list).

> The document author doen'st need to know what rendering
> technology will be used to read the document. The document  might last
> 1000 years, it's unlikely that the processing pipeline used to render it
> will last that long.
>> In that case any SVG browser can render math without need for
>> native supprting MathML.
> SVG may render OK at a particular window size but it's hard to see how
> automatic line breaking would work in that case (as it happens today in
> a limited extent in mozilla) given an SVG encoding of a particular
> layout. SVG's very good at what it's good for, but it isn't designed
> for, and isn't particularly good at, expressing an inline mathematical
> expression that has to take part in the paragraph flow and line breaking
> of the surrounding text.

Then add one or two small modifications at the SVG place or better still
add the funcionality on the content markup + browser layer instead waiting
a full spec was spreaded over browsers in a magical way.

Your emphasis on inlines and baselines remember me your few days ago (in
another site) statement that CSS rendering i was promoting could not align
to baseline as specific MathML markup could do. I cited a link with
technical data and examples and George provided you a specific piece of
CSS doing just you claimed days before could be _not_ done. Well, there is
also ways to inline adjust in a XSL-FO and in a SVG rendering approach.

Moreover, let me also note that whereas i like the posibility for
automatic line breaking of math code, most of the MathML code is being
served on the web cannot benefit from 'thanks' to scary code as




> David

Juan R.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS