From: William F. Hammond <hammond@csc.albany.edu>

Date: Thu, 28 Oct 1999 11:10:21 -0400 (EDT)

Message-Id: <199910281510.LAA07636@hilbert.math.albany.edu>

To: www-math@w3.org

Date: Thu, 28 Oct 1999 11:10:21 -0400 (EDT)

Message-Id: <199910281510.LAA07636@hilbert.math.albany.edu>

To: www-math@w3.org

David Carlisle writes, quoting Hugh Devlin: > > I don't know if you guys are working on a new rev of the dtd's [snip] > Yes, we are (there is a charter to produce a revised MathMl 2 spec early > next year) [snip] > So if MathML is to be embedded into a larger document type for > controlling the rest of the document (xhtml, docbook, Kluwer Journal > DTD, ...) then it can not have `variants' of the ISO declarations > all parts of the document have to be using the same definitions for the > ISO entity names. MathML is much more granular than either xhtml or docbook, both of which *can* be edited by hand. While I have nearly ended my period of editing html by hand, I doubt if hand-editing of docbook is about to disappear. I find this lack of parllelism bothersome in the case of docbook even though it is not a formal problem. (Of course, there is a way of viewing things so that those who create docbook docs spin them out from personal or house document types.) Would, for example, anyone care to show us something that is a reasonable editing interface (aside from CAS GUI authoring systems) for docbook+ezmath or something similar just to boost our confidence in the idea of docbook+mathml? If it comes down to the situation that the only way MathML will ever be created in the real world is with CAS output, then I wonder at what time it becomes credible that mass market pc's will be delivered having browsers that handle MathML out of the box? (In fact, on a mass market pc purchased here at the University a few months ago, I find a native browser that apparently thinks a document served through http as "text/plain", but with a uri ending in ".sgml", should be handled as "text/html" with unknown tags and their recursive contents ignored.) Until out of the box pc's have browsers that handle MathML, a teacher in the U.S. will not be able to assume that a significant fraction of his or her students have easy access to online documents with MathML. So why bother making them? It seems better for now to use TeX-like or CAS-like notation inside ordinary HTML. An issue from the very beginning in 1995 (when the draft for HTML 3.0 was dropped by W3C) for the HTML Math WG has been access to math for the widest audience. Remember that by mid 1993 one could deliver dvi's across the network either with http/html or with gopher+, and the only problem was that there was no distribution of dvi viewing systems. Even today I believe that only a third of my students have easy access to online pdf. It has been a long time. With my personal production system, still under development, involving a LaTeX-like SGML application that admits down-translation to an essentially equivalent XML application, I would need to add symbol declarations, something that is not at all like present LaTeX, in order to think about translating rigorously to (xhtml|docbook|tei) +mathml. This would be a large undertaking on which I would want help. That said, it is also unclear to me at this point whether it would eventually be the best route through the formatting object language (still a moving target, I believe) to a mass-market browser screen formatting. If it is not the optimal such route, then the only reason to provide translation to MathML might be for enabling CAS input clipped from an online document. Do the CAS folk have any thoughts about this? -- BillReceived on Thursday, 28 October 1999 11:10:27 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:29 UTC
*