Re: Math on the web without MathML (CSS 2.1 rendering for HTML and XML)

Mark P. Line wrote:
>
> None of that explains why you chose to claim that off-line publishing of
> math is the only successful application domain for MathML, which remains a
> clearly false statement that you've left unaddressed.

You are right, I do not think that off-line publishing of math was –in
rigor- a succesfull (see below) application of MathML.

>> Of course, you can disagree and then add lot of fields were MathML is
>> successful for you. That would be great for all of us here. Maybe we
>> would first begin to analize that “sucesfull” mean.
>
> I tried earlier to get you to explain what you meant by successful (in my
> question about your implied popularity metric), but you declined and said
> you'd covered that ground already on this list many times over.

Successful means winning, doing well, triumphant...

> Now,
> you're saying we should first analyze the meaning of "successful" before
> we go further.
>
> Where I come from, you can't have it both ways.

Above I was asking what you understand by "sucesfull" because I believe
that you are mixing "successful" with "working".

> A brief glance at the SBML website is all it takes to convince any
> reasonable person that SBML is a very successful standard (in the sense of
> being almost ubiquitously deployed throughout its intended domain of
> application). MathML is an essential part of SBML. SBML has nothing
> significant to do with off-line publishing of math. QED.

Fortunately, not all people has so great views on MathML like you; just
some thougts from the SBML community:

<blockquote>
Although MathML obviously has it's advantages (easier to parse than infix,
defined set of symbols) we should also be aware of it's disadvantages and
try to reduce the impact of these on the developer and user. It is the
developers of SBML libraries who have this responsibility (lucky me I'm not
one of them!) and we as arm-chair developers (speaking for myself in this
case) should be careful not to load the developers with needless tasks
unless we're sure that payback is well worth it.
</blockquote>

And MathML is so succesfull in the SBML community that last years was
launched a thread in the SBML site called "Complementary Alternative to
MathML Needed". I do not believe that mathematics done at the SBML
community was extensive or advanced still they are claiming for
alternatives.

Greg Blumenthal (BioKinetics, Inc.)

<blockquote>
A non-MathML approach should allow for a more
qualitative analysis of the metabolic network,
differentiating various types of inhibition
(competetive, noncompetetive, uncompetetive) by use of
simple tags. That would make my life much easier.
</blockquote>


Nicolas LE NOVÈRE (Computational Neurobiology)

<blockquote>
Careful. There are two different topics/issues here. And I suggest that we
use different threads.

1- Greg => Qualitatively characterisation of ratelaws => should be solved
by controled vocabularies.

2- Howard => Alternative way of encoding actual ratelaw.
</blockquote>

> Have you been ignoring the posts here about market penetration of MathML,
> or do they not meet your undefined criterion of "successful"?

Successful because fabulous spec? Because heritance from being a XML
application? Or do you mean "successful" (i.e. I would call "working")
because many marketing around the only current spec?

I think that MathML specification is very far from being remarkable. I
already wrote a bit about why several publishers are adopting off-line
MathML in a XML workflow because i) off-line you can use almost any thing,
ii) because benefits from an all-XML approach can supersed difficulties
with mixing languages e.g. XML and LaTeX. It is clear that part of the
adoption of MathML is related to the propaganda about it. It is just funy
reading someone that MathML is accesible whereas after writing MathML code
is less accesible than GIF + ALT.

13 Jul 2006 Paul Topping exclamed MathML was "alive and well" and cited
the introduction of MathML in the next version of DAISY, an XML format for
ebooks with special concern for accessibility. Then one goes to daisy
project one discover the next example

[http://www.daisy.org/projects/mathml/call-for-review.htm]

<m:math id="math001" smilref="example1.smil#math001"
altimg="example1-001.png" alttext="f of x">
  <m:mrow>
    <m:mi> f </m:mi>
    <m:mo> &ApplyFunction; </m:mo>
    <m:mrow>
      <m:mo> ( </m:mo>
      <m:mi> x </m:mi>
      <m:mo> ) </m:mo>
    </m:mrow>
  </m:mrow>
</m:math>

Well if usage of ***presentational*** markup (with entities) for encoding
a trivial f(x) is the example of accesibility is being promoted, then
sorry to say this but one would not wait a lot of from this project.

It is clear that presentational MathML was not designed for accesibility.
f(x) is trivial, but try to encode the simple {ds}^2 = \nu_{ab}d{x^{ab}}
in presentational MathML.

Also i find curious that Topping did not notice the presence of the
alttext attribute on the math root.

>> Maybe I would remember you that MathML is about communicating something:
>> mathematics. Presentation MathML is about visual rendering, whereas
>> content MathML would be about transfer of precise mathematical content
>> (not meaning).
>
> What do you mean by "content" and "meaning" such that content MathML is
> about the one but not about the other? I don't think these words mean what
> you think they mean.

Then you already know the reply better than me.

>> Ok, let us focus then on that: communication. I am just
>> curious how you (or your software) would encode next basic expressions
>>
>> 1) a + b
>>
>> 2) sin &pi;
>>
>> 3) -5
>>
>> 4) &int; sin &omega; d&omega;
>>
>> 5) 3/4
>>
>> 6) sqrt(x)/(y^2 -1)
>>
>> 7) -x
>>
>> 8) &int;_a^b &omega; d&omega;
>>
>> 9) x >> 0
>>
>> 10) <p>My favourite Greek letter is &beta;</p>
>>
>> 11) x_i = 5
>>
>> 12) {}^7log x
>>
>> 13) (x+3)^2
>>
>> 14) a/b; a=3, b=4
>>
>> 15) 123/456
>>
>> 16) (&partial;&rho; / &partial;t) = L &rho; + &epsilon;(&rho - &rho;_0)
>>
>> in content (or parallel) MathML and how would I (or my software)
>> interpret it?
>> Of course, this is more than a theoretical exercise; take as practical
>> exercise the internal and or external communication of research results
>> at some official body.
>
> I'll assume that's a challenge to the whole list, since almost anybody
> here will have more experience in MathML coding than I. Surely you don't
> expect me to have time do it myself unless you provide a billing address.

Wait, first you claim that MathML is sucesfull and apparently your basic
evidence is because MathML is included in SBML or something but now you
cannot encode those simple examples. Time? Do not you have time enough for
encoding examples 1), 2), or 3) in content MathML; that sound rare.

Well, I can provide you a billing address if that is your only problem.
Could you encode above examples for this week please?

Also if you have time I would be glad to know what are the strong points
of MathML for you and for what you claim it is working (or in your words
"it is successful")

>
>>> Why would I be interested in CSS rendering, or any other kind of
>>> rendering?
>>
>> Why not? In fact, without rendering how can you read my message here? The
>> 100% of math books in the University’s library are rendering math on
>> paper...
>
> As you know, my question in context was about why you were telling me
> about CSS rendering of math in a discussion about whether or not MathML
> had any good use outside of STM publishing.
>
> In that context, you haven't answered my question. You have, however,
> answered the unrelated and unasked question about how rhetorically
> sophisticated you think the people on this list are. Right?

1) Have you read the title of this thread?

2) You appears to unknow that rendering is a critical issue in mathematics
and that design of content MathML markup is related to how sucesfull the
rendering can be.

It is not how you think that one can design a content markup for people
who is not interested in rendering issues and next one design a
presentational layer for rendering. Precisely, one of criticisms to
OpenMath (e.g. Richard Fateman) is that has not addressed rendering issues
with care.

>
> -- Mark
>
> Mark P. Line
> Polymathix
> San Antonio, TX

Juan R.

Center for CANONICAL |SCIENCE)

Received on Monday, 24 July 2006 09:26:40 UTC