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

Hi Ivan,

It's difficult to reply as there are many details in your message that are
off, uninformed or incorrect.

I think we fundamentally do not understand each other; we do not understand
how each of us views the current state of affairs, the available tools and
standards, what each of us considers to be problems see or how to try to
resolve them.

So I cannot even agree to disagree as it would presume an understanding of
each other's position.

Peter.




2018-01-26 13:41 GMT+01:00 Ivan Herman <ivan@w3.org>:

> 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/
> mobile: +31-641044153 <+31%206%2041044153>
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>