- From: William F Hammond <hammond@csc.albany.edu>
- Date: Wed, 26 Mar 2008 15:20:17 -0400
- To: Ian Hickson <ian@hixie.ch>
- Cc: www-math@w3.org, EMJ@listserv.albany.edu
(copies to www-math and emj)
Hi Ian --
You reference:
[1] http://www.whatwg.org/issues/#html-parsing-rules-namespaces-discussion
[2] http://wiki.whatwg.org/wiki/New_Vocabularies
[3] http://lists.w3.org/Archives/Public/public-html/2008Mar/0156.html
I very briefly scanned your references. I have a few comments that
may only be tangentially related to your present concerns with math
in html5.
1. Math in browsers:
xhtml+mathml is rock solid in Firefox and IE+MathPlayer.
(Moreover, it's fully interoperable with Dave Raggett's
slidy. I think that it is now the best slide show presentation
format since screen real estate is so easy to manage.)
2. Web visible adoption:
Some search engines seem not to see application/xhtml+xml.
Though adoption has been slow, it's happening. There are are at least
three math journal operations using xhtml+mathml at least for article
abstracts:
1. Mathematical Sciences Publishers, Berkeley and Warwick,
http://www.mathscipub.org/
2. NUMDAM, Grenoble, http://www.numdam.org/
3. Project Euclid (some of its journals, i.e., Duke, JMSJ, ...),
Cornell, http://projecteuclid.org/
AFAIK full articles in xhtml+mathml have not appeared at the above
yet, but the Lobachevskii Journal of Mathematics, Tatarstan,
http://ljm.ksu.ru/ is doing that, apparently by translating LaTeX
with tex4ht.
3. Direct authoring:
Forget "direct authoring" of MathML.
4. Authoring xhtml+mathml:
The best techniques are based on the use of an author-level XML
document type supporting math. The document type represented by
axgellmu.dtd in the tarball at CTAN:/support/gellmu
or at http://www.albany.edu/~hammond/gellmu/xml/axgellmu.dtd
is an example.
Apart from "regular" gellmu, the gellmu syntactic translator can
be used for latex-like "compact" markup, analogous to but
different from compact relaxng notation, with any xml document
type.
Other currently supported examples providing author-level math seem
to exist only behind closed doors.
5. Translating LaTeX:
More than 10 years of experimentation shows this is not a free
ride. Tex4ht, suitably configured, is good and gets wide use, but
requires care. http://www.cse.ohio-state.edu/~gurari/TeX4ht/mn.html
Another interesting translation project is "latexml",
http://dlmf.nist.gov/LaTeXML/, that is being used in an ambitious
project called "arXMLiv" at Bremen to translate the contents of
the arXiv http://kwarc.info/projects/arXMLiv/
Translation of LaTeX is important because there is more than 30
years of legacy content.
Translation of LaTeX is a workable, but inferior, route for new
content. It is inferior if only because it is essentially impossible
to define in a precise way what is correct markup.
6. Named entities, an observation:
Of course, we all know that a named cdata character entity becomes
numeric on first parse. However, it seems to be the case that
some user agents handling mathml are internally converting numeric
data points to names.
The sticky thing here is not the retro conversion but the fact
that nuggets of cdata have become decision points. Remember that
in sgml sdata entities (not currently available in xml) can
survive parsing and are sensible decision points.
7. Searching in math:
I will only speculate that the searching technique should operate
through attribute values.
For the interim I would like to see web search engines that
enable the user to search enter requests like:
attr%href:uchicago.edu
attr%div.class:^subsection$
attr%div.class:(display|inlineblock)
attr%key:thetaGenus1WithChar1001
8. Printing:
The best approach with new content is for the author to write
latex (to be translated, as above) or to write for an author-level
XML document that admits formatting both toward latex and toward
xhtml+mathml. For good results one may want more power than is
available with xslt.
It is sane to translate xhtml+mathml to latex. I expect that
piping from a browser to an external formatter is likely to be
better than what I imagine for any future browser print service.
You wrote:
> 4. Writing documents that include diagrams that include
> typographically-correct mathematics.
I assume you mean an svg diagram or a png image.
Someone from the WG might want to speak to this.
-- Bill
Received on Wednesday, 26 March 2008 19:21:05 UTC