From: <juanrgonzaleza@canonicalscience.com>

Date: Fri, 9 Jun 2006 02:57:56 -0700 (PDT)

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

Date: Fri, 9 Jun 2006 02:57:56 -0700 (PDT)

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

About markup model. It has been proposed a specific markup language (Whyte Lynx) and now variations from Michel Fortin and some other. I agree with most of Lynx?s one but think we would not propose semantic markups. Even Content MathML or OpenMath are not still sufficiently thought as for broad adoption. In fact, both markups contained several serious errors in the past have been corrected in recent versions. OpenMath is more solid than Content MathML and probably latter never was adopted in practice. Today implementation of both is close to zero. I think that markup would be more easy possible with posibility of ampliation, such that better authors could do a better job but average users could easily obtain results in a cheap and rapid way. I would disacourage any semantic markup and a focus only in structure (markup) and presentation (CSS with XSL-FO as second choice). In that case something like <frac> <num>b</num> <den>2</den> </frac> is structural. Somewhat as a html document is composed of head and body, here I am encoding a fraction (structure) is divided into numerator (substructure) and denominator (substructure). Next structure can be styled with CSS (or XSL-FO also) applying different styles to <num>, <den>, and <frac>. There will be a default stylesheet (as in LaTeX) but fine tuning of some special fraction can be achieved using CSS rules directly somewhat as one can use special style attributes for finetuning of some part of text, but in general one uses defalt stylesheet for HTML. Okay. MathML is only presentational not structural -there is not explicit numerators or denominators- just a <mfrac> and two childs. It is not CSS friendly, and for modifying fine-tuning of some fraction you may use special MathML attributes, a new styling language, etc. This is not rational. I would not encourage usage of a type attribute. A simple class would be sufficient and then we can reuse available CSS and HTML engines. The implementation of full semantics in browsers would be very, very complex and nobody has proved that using type=?matrix? or type=?vector? the semantics can be unambiguosly encoded. The forcing of special types for each token would be so boring as if HTML text use a type attribute in span, p, and divs for each posible semantic one can imagine: lemma, chapter, manifesto, group, afilliation, booksection, etc. For that detailed markups as ISO12083 or Docbook are better in text, OpenMath or some other approach will be better in math. I find also rendering difficulties. For example in physicochemical comunity <var type="matrix">X</var> would be render in bold *X*, but <var type="matrix">X</var><sub>2,2</sub> I would use normal rendering for because is a matrix element, moreover <sub>2,2</sub> has not clear semantic meaning and is mixing semantics with presentation; at the poor you would use <sub type=?index?>2,2</sub> but at the best each index would be independently encoded and the comma typed as separator of indices. But all of that is complex. <var class="matrix">X</var> and a CSS rule would be cheap with <var>X</var><sub>2,2</sub> in non-bold face. I find boring also the double markup at Content MathML 2.0 with type=?matrix? being used sometimes but <matrix> in others. In MathML above example would be retypped via <selector> operator <apply><selector/><ci type="matrix">X</ci><cn>2</cn><cn>2</cn></apply> For any array structure ?matrix, vector, determinant or any other- why do not simply reuse available HTML elements: <table>, <td>... instead proposing new ones <mr>, <md> doing the same? CSS rules could use different selectors body> table: CSS rules for text tables body> formula> table: CSS rules for text tables fences could be done as <fence left="round" right="square">expression</fence> I would disacourage usage of <bounds>, <integral>, <product>, and all those. They are semantic, when we would focus on structure more presentation. Some constructs proposed here are CSS unlikely and from a semantic point of view not correct at all. Look for next code submited to this lists. <integral> <bounds> <sub>0</sub> <sup>100<sup> </bounds> 3<var>x</var> d<var>x</var> </integral> This mixes presentation and semantics. The usage of external containers as <integral>, <sum>, <product>, was done in previous versions of MathML code but abandoned in recent proposals. Math on the web began with insane code as <root>2<of>x</root> and finalized with current MathML 2.0 proposal: presentational part being CSS and XSL-FO unfriendly, and the content part also rejected. In fact, the encoding for something so simple as the integral sin (x) have changed three or four times due to weakness of markups proposed, with last Content MathML 2.0 being rudely critiqued from some comunities, for instance OpenMath one. As illustration compare above code for integrals with HTML 3 Math, with MathML 1, and in content MathML 2 with most recent OpenMath code for the integral of sin (x) <OMOBJ> <OMA> <OMS cd="calculus1" name="int"/> <OMBIND> <OMS cd="fns1" name="lambda"/> <OMBVAR> <OMV name="x"/> </OMBVAR> <OMA> <OMS name="sin" cd="transc1"/> <OMV name="x"/> </OMA> </OMBIND> </OMA> </OMOBJ> Ian Hickson wrote: > I would be very cautious about introducing an entirely new language to > do this (even if it is "just" an extension of HTML4). For something as > big as Mathematics, we want to simply re-use an existing language, not > invent a new one. Inventing a new language for encoding content with as > wide a problem-space as mathematics would require months, as well as > the time of domain experts, etc. This work has already been done, e.g. > in ISO12083, MathML, LaTeX, and other such languages. Nobody want reinvent the wheel, but people reuse languages when these *work*. By reusing MathML one finalizes with an ugly language is not compatible with rest of w3c technologies, semantically incorrect (or at least incomplete) and practically nobody want waste time with it. You look like a fervent admirer of the re-use of MathML, however some of your proposal, such as special parsing mode or mixture of pure and mixed content were proposed by other people (e.g. Juan R.) and completely rejected by the own w3c MathML IG people even before begin a serious debate. Moreover, by reusing MathML 2.0 we are reusing exactly the same errors that w3c MathML IG did with its last specification. For example, why the own MathML IG did not reuse (all of) MathML 1.0 and on the other hand proposed a new mayor revision with important changes? Why did the own MathML IG decide to invent new tags such as <apply> instead reusing MathML 1.0 code as <fn>, <reln> and others? Why did the own w3c not reused <min> and <max> for integrals? Why were <of> and <left> and <rigth> and <root> and <over> and several other tags not reused from the early w3c Math draft of 1994? Why was the initial <EXPR> Math tag finally abandoned? Do you know? When mathematicians stated that TeX would be reused in XML (most of mathematicians and just users of TeX and know little of internal design and less still of web and XML requirements) Neil Soiffer ?one of w3c MathML authors- replied <blockquote> Which part of TeX? TeX is not amenable to the growing number of XML tools such as CSS, XSLT, DOM, parsers... </blockquote> Therefore it is perfectly reasonable our rejecting of MathML because ?is not amenable to the growing number of XML tools such as CSS, XSL-FO, DOM, parsers...? This debate would be about Whyte Lynx proposal for mathematics in HTML5 rather than discussions about the reuse of MathML. However, since it may be informative explain why MathML is not popular. I offerede many examples if incorrect code, incorrect desing, criticism and others. Now some additional comments about MathML Reference NSF / NSDL Workshop: Scientific Markup Languages Workshop Report Hosted by the National Science Foundation June 14-15, 2004 Report prepared by: Laura M. Bartolo, Kent State University Timothy W. Cole, University of Illinois at Urbana-Champaign Sarah Giersch, Association of Research Libraries Michael Wright, UCAR ? DLESE Program Center **** EXTRACT, comments for mine between [] ********************* Initial work on MathML predates even the formal release of XML as a W3C Recommendation and draws on early experiences from SGML (e.g., the ISO 12083 Mathematics DTD fragment) and HTML (e.g., the abortive effort during the development of HTML version 3 to augment HTML with a number of math specific elements, attributes, and constructs). [...] There remain, however, a number of substantive issues with regard to MathML. As one of the very first domain-specific implementations of XML, there were (necessarily) growing pains, and MathML is still seen as somewhat experimental by many potential users in the math community. [...] MathML is therefore recognized as inherently incomplete. The authors of MathML have explicitly targeted it for the expression of mathematical content up through the early undergraduate level (first-order calculus). Its utility for research mathematics, even with its explicit built-in extension mechanisms (e.g., as exploited in the EU funded OpenMath project), is still uncertain. MathML is also intentionally bimodal, containing sets of elements to describe separately the presentation of mathematics and the semantics of mathematics. Generally, early implementers have focused on one or the other but not both parts of the ML, resulting in asymmetrical implementations that don't always interoperate as well as might be desired. Adoption has been somewhat slow, _in part_ [emphasis mine] because of the entrenchment of TeX within the research mathematics community. Additionally, although mathematics is recognized as key to many scientific disciplines, and there have been some attempts to incorporate or accommodate MathML markup rules within other domain-specific markup languages, there are examples of domain-specific markup languages (outside of pure mathematics) that include their _own markup semantics_ [emphasis mine] for basic mathematics needed within the domain of interest, rather than borrowing from MathML as needed. [...] The mathematics breakout discussion included a diversity of MathML experts and current and would-be users and consumers of MathML. This diversity of backgrounds and perspectives made for an energetic and wide-ranging discussion. In discussing the potential benefits that MathML might bring to bear on educational services and models of learning, there were multiple points of consensus as well as several open issues and uncertainties identified. [...] That said there remain several open issues as well regarding the potential of MathML to help meet educational needs for a better way to express mathematics in online documents and learning resources. The utility of MathML to enhance searching and improve accessibility of online mathematical content has not yet been proven. Searching of mathematically laden content by the mathematics it contains is a complex issue. It's not altogether clear whether the level of description implicit in content (semantic) and/or presentational MathML is sufficient to support robust searching on the mathematics contained in a resource. It's also not yet certain that readers and other accessibility tools will be able to exploit MathML effectively to make the mathematics embedded in a resource more accessible, though that seems a safer bet. While MathML is being adopted (at least experimentally [this was the case at the Center for CANONICAL |SCIENCE) sure]) behind the scenes -- e.g., as an exchange format for interoperation between applications like Mathematica and Maple and in the editorial workflow of scholarly journals [I studied with detail the case of the giant Elsevier and they are using an in-house modification of MathML instead the w3c standard, because they also got problems and, moreover, they are complementing the usage with own mathematical CEP markup e.g. <ce:sub> and <ce:sup> for simple formulae], it has not been widely adopted by the authors of educational and scholarly mathematical content. Research mathematicians continue to rely heavily on TeX, which though exclusively presentation oriented (really a specialized language for the typesetting of mathematics) is firmly entrenched. Educators continue to rely on cruder technologies (e.g., embedding mathematics as static images within HTML or presentation only markup within PDF documents) or exploit proprietary solutions such as Mathematica workbooks. There remains a bit of a "chicken and egg" problem in that authors are hesitant to adopt a new technology until it has proven its value, and it remains difficult to prove the value of MathML without a sufficient body of MathML content. Discussion of this issue led naturally into an extended discussion as to how MathML is now or might in the future engage the mathematics community. It is clear that MathML at this point in time is more appealing to organizations or institutions than it is to individual practitioners. As a non-proprietary, expressive, comparatively low-loss way to represent mathematics, MathML has clear attractions for long-term archiving and interchange of mathematics on a large scale. Hence its attractiveness to publishers and middleware tool developers. Several participants in the breakout session suggested that MathML may continue to develop as a largely or even exclusively back-end technology, used behind the scenes as a way to store and exchange mathematical content, but not necessarily as a format with direct impact on the author's or the end-user consumer's experience interacting with mathematical content [this clearly indicate that WE would provide a cheap but powerfull mathematical language for the web, with end-users and authors in mind]. That would still make MathML useful, but the consensus was that MathML's greatest potential both economically and in terms of new functionality will not be realized until it is used more widely by content creators and ultimate consumers [the problem is that specification is weak and available tools cannot generate first-class MathML code]. This will require even more aggressive development of necessary authoring and presentation tools (including interactive presentation tools) and the inclusion of MathML within markup schemes developed by other science and technology communities that require the ability to express rich mathematics in documents and learning resources. This, in the collective opinion of those participating in the Mathematics breakout discussion, suggested avenues of common interests with other markup language communities represented at the workshop and led to the identification of several key issues of importance to the further development and future evolution of MathML: ? the need for more ubiquitous, more transparent (to the user) support for MathML in the Web environment; ? the need for better support within XML and Web-based applications for "compound documents" (i.e., as defined by the W3C, documents that combine multiple formats, such as XHTML, SVG, SMIL and XForms); ? better assurance that MathML will be maintained as a standard going forward; ? more sophisticated tools, especially on the authoring side, that can facilitate inclusion/embedding of MathML within online resources (e.g., within Web pages); ? continued development of better, more robust transformation tools (e.g., between TeX and MathML); and ? viable business models to better support and encourage ongoing development of MathML. *********************************************************** A simple and cheap structural markup based in ISO-12083 (which is an international standard, MathML is not) that can be styled with CSS (or XSL-FO) and that do not need of special fonts, plugin, native support, special tools, etcetera would be easily implemented and accepted by authors. Juan R. Center for CANONICAL |SCIENCE)Received on Friday, 9 June 2006 02:57:56 UTC

*
This archive was generated by hypermail 2.3.1
: Monday, 13 April 2015 23:08:27 UTC
*