From: Pankaj Kamthan <kamthan@cs.concordia.ca>

Date: Thu, 13 Apr 2000 20:41:12 -0400

Message-Id: <200004140041.UAA09585@spamburger.openface.ca>

To: cool@dataweb.nl

CC: www-math@w3.org, timbl@w3.org

Date: Thu, 13 Apr 2000 20:41:12 -0400

Message-Id: <200004140041.UAA09585@spamburger.openface.ca>

To: cool@dataweb.nl

CC: www-math@w3.org, timbl@w3.org

Thomas, Here are some comments on your message as well the paper you refer to at http://www.dataweb.nl/~cool/Papers/MathML/OnMathML.html . "You are probably under the impression that MathML is a good idea." MathML is more than an idea. It has been formalized (specification) as well as realized (documents, software). "It is Byzantinely complex, unintuitive, unesthetic, highly undocumented, it requires complex software support, etcetera." What exactly is complex? [Re]presenting mathematical notation on the Web for subsequent actions is a nontrivial problem. Nontrivial problems can have nontrivial solutions. (Now, if only there were (on a 8 1/2 x 11 inch paper) a one-line proof of the Fermat's Last Theorem or one-line numerical solutions of bifurcation problems in nonlinear elliptic partial differential equations ...) MathML is not designed (only) for aesthetics. Aesthetics in mathematical notation have no known bearing towards human understanding or machine- based "intelligent" searching. Whether raw MathML is/is not "aesthetically pleasing" is subjective. The burden of aesthetics is on the processor at the delivery-end (renderer, printer). If needed, MathML can be transformed to "aesthetically pleasing" formats, including [La]TeX and/or PDF. MathML is not "highly undocumented"; see the pointers at http://www.w3.org/Math/ . In particular, (aging) http://indy.cs.concordia.ca/mathml/ and http://www.webeq.com provide documentation on various aspects of MathML. "A quite perfect alternative already exists in Mathematica: simple, elegant, intuitive, highly documented etcetera - and users of Maple may think similarly about Maple." 1. Mathematica or Maple are not perfect alternatives to MathML. They all serve different purposes (though overlap in intent) and are complementary. This judgement is based on experience with all three, and not heuristics. 2. Mathematica and Maple are both proprietary solutions. MathML is not. 3. Simple, elegant, intuitive, ... are all subjective terms. Arbitrarily complex Mathematica or Maple programs can be written and so can MathML documents. "The real reason why W3C developed MathML is ... (b) that they didn’t really deal with the makers of Mathematica(or Maple)." Representatives from both Mathematica and Maple are (have been) on the W3C Math WG. "Scores of programmes have been written in Mathematica ... All that software becomes inaccessible in MathML - needs to be retranslated again etc." 1. Mathematica documents can be made available on the Web (via plug-in solution). 2. Mathematica 4 provides support for Mathematica document conversion (import/export) to MathML. "W3C supposedly comes up with all kinds of subtleties. But it appears that such issues, and even more, already have been covered in Mathematica. They ‘only develop a standard’ and other - commercial ? - institutions will need to provide the real services." W3C has developed: 1. Amaya, which provides rendering for MathML Presentation Markup. 2. EzMath, which provides a plug-in and an editor for MathML Content Markup. "The idea is that a user will not see the MathML input." Why not? It can (and has) been done. Use, for example, Form + CGI/[Programming Language of Choice] + MathML-aware parser. "Please, if Mathematica can read "(a + b)^2", why should MathML make it so difficult ?!" MathML is based on XML syntax. This can (but not always) lead to verbosity. This is an issue but there are several benefits (such as, more precise resource discovery) as trade-offs that outweigh that. It, however, remains an issue (typing errors, "too much" markup for "too little" result) if you insist on text-oriented editing (such as, via Emacs). Whether mathematical notations should be based on XML or whether embedded markup is the right direction, is an entirely different issue. See http://www.xml.com/pub/w3j/s3.nelson.html . "What will put the horse behind the cart is that MathML creates the illusion that mathematics as a language is copyrighted - as the language for example is used in Mathematica." There is no illusion. MathML Specification, like all W3C technical reports, explicitly state legalities surrounding it. See, for example, http://www.w3.org/Consortium/Legal/ipr-notice . "In the short run, MathML should be reduced to the statement <mathematics use=...> ... </mathematics> and the browser should have to capacity to call onto the computer language package." MathML (and other external) objects can be incorporated in XHTML via the object tag. However, this plug-in/helper application view has several (by now, well-known) limitations. "... An ANSI standard should be developed that takes its point of reference in the history of mathematics and not in commercial developments of the last 10 years." MathML Specification takes into account and makes several references to mathematical development that go beyond the last 10 years. See, for example, http://www.w3.org/TR/MathML2/appendixi.html . The power of MathML comes from several sources, including: 1. MathML is an open, extensible format that leverages on other (open) standards. Nobody "owns" SGML, XML or MathML. 2. Based on XML syntax, as well as with the induction of semantics for both presentation and content MathML provides data (machine-to-machine interface) and as well as document view (human-to-machine interface) of the same MathML file, MathML record in a relational database, MathML object delivered by an Object Request Broker, and a MathML stream of bytes arriving at a network socket. Since the structure is separated from presentation, you can author MathML once, and use it in various contexts: present it (using CSS, XSL) on different devices (on desktop, PDA), manipulate/interact with it (using Computer Algebra Systems, DOM, XSLT), print it (by MathML -> PDF), exchange it between two MathML-aware servers. In conclusion, MathML related issues remain (and are being addressed, within or outside the scope of MathML Specification), including: 1. A robust infrastructure for large-scale, transparent (minimal, ideally zero loss of information) and automated (such as, by batch processing) legacy (say, [La]TeX, RTF) document transformation to MathML Content Markup. 2. Native rendering support in "popular" user agents to ensure a broad accessibility of MathML. 3. Mathematics-specific metadata that conforms with RDF Schema and takes into account existing metadata efforts (such as, Dublin Core, IMS metadata). 4. A stable list of MathML Content Markup elements that addresses localization. (It takes into account basic and widely-used mathematical notations used around the world (and not just those in USA or Europe.) 5. Semantic bindings for representing mathematical notations within the XML architecture that are external to the list of MathML Content Markup elements as well as external to OpenMathML CDs. A (constructive) criticism is useful but your work, unfortunately, misrepresents the capabilities of both MathML and Mathematica (as well as, other Computer Algebra Systems), and does not address the essence of the issue well. The horse is in front of the cart and galloping. Pankaj Kamthan P.S. There are typographical and grammatical errors in the paper. Examples: unesthetic, WC3.Received on Thursday, 13 April 2000 20:41:50 GMT

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