From: <juanrgonzaleza@canonicalscience.com>

Date: Mon, 24 Jul 2006 02:26:25 -0700 (PDT)

Message-ID: <3078.217.124.69.253.1153733185.squirrel@webmail.canonicalscience.com>

To: <www-math@w3.org>

Date: Mon, 24 Jul 2006 02:26:25 -0700 (PDT)

Message-ID: <3078.217.124.69.253.1153733185.squirrel@webmail.canonicalscience.com>

To: <www-math@w3.org>

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> ⁡ </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 π >> >> 3) -5 >> >> 4) ∫ sin ω dω >> >> 5) 3/4 >> >> 6) sqrt(x)/(y^2 -1) >> >> 7) -x >> >> 8) ∫_a^b ω dω >> >> 9) x >> 0 >> >> 10) <p>My favourite Greek letter is β</p> >> >> 11) x_i = 5 >> >> 12) {}^7log x >> >> 13) (x+3)^2 >> >> 14) a/b; a=3, b=4 >> >> 15) 123/456 >> >> 16) (&partial;ρ / &partial;t) = L ρ + ε(&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 GMT

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