- From: David Carlisle <davidc@nag.co.uk>
- Date: Wed, 5 Apr 2006 14:44:03 +0100
- To: juanrgonzaleza@canonicalscience.com
- CC: www-math@w3.org
> Maybe, but I wrote a basis with four "embellishments" and the MathML > received is not encoding that, you know. This is true, now you've explained what you mean but I don't think that is too serious a limitation. If you are concerned about the layout rules for such a construct, then you need to specify whether if the over-script and super-script would collide, which one moves. In Presentation MathML you would control that by nesting the munderover inside the msubsup or the other way round. If you are interested in the mathematical meaning that this is a single base with four embellishments then it is possibly a function applied to 5 arguments that just happen to be laid out in that way so you could supply content mathml markup that reflects that along with either a stylesheet or parallel presentation markup that gives the layout. > I do not know exactly about LaTeX, because I do not know how the base for > > \sideset{}{_*^*}\symbol_*^* Yes exactly what I was refering to. TeX's layout model has no support for prescripts. It is of course possible to write macros such as \sidescript that measure the base and attempt to position the prescripts by hand but it's not easy. But this is in the user-level macro layer above the TeX layout engine so is more or less equivalent to saying that MathML has the same feature because you can write <any>markup</any><you>want</you> and transform it to presentation mathml via XSLT. When you compare the two cases it is in principle easier in MathML as there is underlying support for prescripts in the layout model. Of course a typical TeX user doesn't necessarily notice the difficulty as the amslatex macros already exist. > That is just free propaganda. > > 1) MathML is not vastly superior to TeX. Er that isn't what I said. I said that its support for pre and multiscripts is vastly superior which is clearly true as TeX has no support for pre or multi scripts. I'm hardly likely to engage in propaganda against latex am I? (In case you were not aware, have a look at the list of authors of the latex system). ftp://tug.ctan.org/pub/tex-archive/macros/latex/base/legal.txt > In SGML 12083 you have tags for sup, sub, over, and under script and you > can combine them. The basis is outside as usual in almost any computer > model: Fortran, Tex, IteX, ASCIIMAth, Maple, Mathematica... Any system has advantages and disadvantages. MathML is one of the few I've seen with good support for multiple superscripts for example. These are not supported by TeX $ tex \\relax "\$a^1^2\$" ! Double superscript. <*> \relax $a^1^ 2$ ? or maple > a^2^3; on line 4, syntax error, `^` unexpected: In both of those systems, to use the shorthand ^ syntax you can't put two superscripts on the same base. Of course in maple you could define a function of three arguments (a,2,3), but that is exactly analogous to the mathml example I gave earlier, you can encode the mathematical meaning using content mathml and the layout using presentation. They are supported by ISO 12083 but of course that's just an input syntax, as far as I'm aware it's often transformed to something like TeX (or in house proprietary typesetting codes) for printing so it depends on how accurately any such translation captures complicated arrangements of multiple scripts. (Maybe it works out in practice, i don't know...) > For instance, I already said you are saying now about the absence of > prescript model in TeX oriented system but you, apparently, have forgotten > it. No. I hadn't forgotten it I refered to that in my original reply! there is a big difference with a user-level macro and support in the basic system. > My previous example cannot be encoded in MathML see above. > base<sup>script</sup> --SGML way Where you mean ISO 12083 you really should say so, it is just confusing to use SGML to mean one particular DTD. > That is, MathML is better from a structural point of view; > TeX/LaTeX is better for authoring. If writing (as I do) in a text editor rather than some GUI that is certainly true. > Therein that the own MathML WG encourages the use of TeX, TeX-like, or > TeX dialects as IteX, as input syntax for authoring. You can find it > in the w3c official MathML Software list. You've refered to that list several times, but you should note that that list is not a list of software endorsed or recommended by the W3C. If you have software that supports MathML you just need to write in and ask that it be listed. So long as you can point to some public documentation or announcement that confirms that it does have MathMl support it will be listed. It does not imply that the software is recommended by anyone, the list is provided as a service to the community to help people find software. > And we could talk days and days about many other limitations and errors of > the MathML design (and why MathML is far from popular). For example, the > next under-overline structure (i obtained from the ISO standard) MathML is of course not perfect, nothing is (and incidentally I wasn't on the first WG that designed MathML 1.0 where all the script markup comes from) But I do believe that experience shows that putting the base as a child of the script elements has proved to be a good design. As for popular, it's clear that MathML has been vastly more popular than any previous SGML or XML markup for mathematics. ISO 12083 and other SGML DTD for mathematics (eg Elsevier's) were pretty much only used by large publishing houses. many of them are switching or thinking of switching to MathML and MathML is used in so many more contexts. If it's so clear that ISO 12083 is superior, why was it not picked up to be used in Computer algebra systems (mathematica and maple both support mathml) or word processors (Word+MathPlayer, OpenOffice, AbiWord and SciWriter for example all support MathML) Plus of course support in web browsers. We are currently looking for requirements for improvements to MathML for a possible MathML3, but clearly MathML is not going to make a backward incompatible change to its script markup. So I'm not sure what you are aiming to achieve. I suspect that what you want to do is design your own XML DTD and then have stylesheets that translate this to MathML for public use. That way you can have convenient short forms for constructs that you use often, and can make different design choices in element markup, according to taste. There is nothing wrong with that (It's what we do here at NAG for example, where documents are authored to a private DTD but converted to XHTML+MathML (and pdf) for publication. Speaking of personal taste in design of XML markup, in an earlier message you mentioned > I would prefer DTDs for something like > > <h1>This is my favourite heading</h1> > > <p>This is a paragraph</p> > > over > > <appply><h1/><cnt>This is my favourite heading</cnt></appply> > > <appply><p/><cnt>This is a paragraph</cnt></appply> Most commentators that I have seen have suggested that the heading markup is one of the more problematic areas of the HTMl design. Most document oriented DTDs (DocBook, TEI, etc) have a structure more like <section> <head>This is my favourite heading</head> <p>....</p> </section> this makes it easy to have outlining support in editors, or to extract the second section in Xpath etc select="section[2]" being rather easier than select="h2[2]|h2[2]/following-sibling::node()[count(following-sibling::h2)=count(current()/h2[2]/following-sibling::h2)" this is finally being addressed in XHTML 2 http://www.w3.org/TR/xhtml2/mod-structural.html#sec_8.8. <section> <h>This is my favourite heading</h> <p>....</p> </section> Note that this XHTML2 markup, like Docbook's, is structually identical to the Content MathML <apply> markup..... David ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________
Received on Wednesday, 5 April 2006 13:47:44 UTC