Re: [MathOnWeb] Peter K's comments on directions for 2018

Hi Peter,

indeed, we do not seem to find a common ground:-( so let us try again. Reset (symbolically, I removed all the previous threads from this mail:-).

The discussion started with your statement whereby you think MathML should be removed from HTML. What I was trying to understand is what you would replace it with. Put it another way, if there is no MathML in HTML, what is the vision of displaying math in a Web page?

What I could gather from your replies and also some of our earlier discussions is that, in your view:

1. Authors should use some tools (authoring tools, AI, simple screen editors, whatever) to author/describe their math content. Let thousands of tools bloom.
2. Some process, possibly bound to these tools, would turn, on the server side, these formulae into HTML+CSS+SVG content and incorporate those directly into the overall HTML of the enclosing Web page. (Let us put issues of accessibility and interactivity aside for now.)
3. That web page then displays in the browser as usual and everybody is happy:-)

MathML, in this view, is "reduced" (although that sounds pejorative, which is not my intention) to, e.g., publishing workflow usage, part of step (1) above, it can be used for interchange among mathematical systems, etc. And, in a way, that is also what happens often in practice, except that, instead of HTML+CSS+SVG, MathML content is turned into images.

If this is indeed your vision, then it is obviously a radical departure from the current HTML+MathML approach. The fundamental difference, in my view, is that the math rendering happens on the client vs. the server side. And, I believe, that is also at the core of our disagreement: I am not convinced that this is the right architecture.

I think we can agree that the CSS+HTML+SVG "encoding" (let me call it this way) for a mathematical formula is extremely verbose. You guys have much more data on this than I would ever have, but I believe my gut feeling is correct. That means the load will be on the amount of data transferred to the client over the wire; that may very well become a major bottleneck. The processing power of clients is, after all, getting huge and I do not see that evolution slowing down; the speed of the network is far from following that pace. There are other problems with this architecture (eg, I am a bit worried about the extreme proliferation of different tools and conversion engines) but that is the essential one.

What it means is that I still believe the fundamental architecture of the current HTML+MathML is right: use a succinct representation of mathematics on the wire and let the client do the job. Hence the necessity, again in my view, of having such succinct representation as a standard.

Now... we know there are problems, to say the least, with the practicalities today. And it may well be that MathML does not hit the right target in making that architecture viable. For example, one of the comments I often get is that MathML is aiming way too high: the goal is to be able to represent PhD level mathematics, whereas, on the Web, the mass publication would what our American friends call K12 or even elementary mathematics. Ie, maybe the current approach should be changed by replacing MathML with something simpler. Also, the implementation strategies used so far may not have been not the good ones, because they did not use CSS & co properly. Etc. And, probably, the two architectures will have to coexist side-by-side and we have to understand the details. So yes, the current situation does need improvement.

Do we at least agree where we disagree?

Ivan

P.S. You realized that I did not use the L-word, right? :-)

----
Ivan Herman, W3C
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>