W3C home > Mailing lists > Public > public-mathonwebpages@w3.org > January 2018

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

From: Peter Krautzberger <peter@krautzource.com>
Date: Mon, 29 Jan 2018 15:58:06 +0100
Message-ID: <CABOtQmGFBQjx6JTYJWjQs806bpFQQP-ZJT8DR4MaPcRrCLmhpA@mail.gmail.com>
To: Ivan Herman <ivan@w3.org>
Cc: mathonweb <public-mathonwebpages@w3.org>
Thank you, Ivan.


On Jan 29, 2018 15:52, "Ivan Herman" <ivan@w3.org> wrote:

> No problems.
> Ivan
> On 29 Jan 2018, at 15:49, Peter Krautzberger <peter@krautzource.com>
> wrote:
> Hi Ivan,
> I'm sorry about my previous message. I've grown very frustrated trying to
> respond on this thread as I seem unable to make myself understood and I
> seem unable to understand your position.
> However, my last email was simply rude for which I apologize. It does not
> represent the way I wish to communicate on this list or elsewhere; I will
> do better in the future.
> With best regards,
> Peter.
> 2018-01-27 17:39 GMT+01:00 Peter Krautzberger <peter@krautzource.com>:
>> 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
> ----
> 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
Received on Monday, 29 January 2018 14:58:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 January 2018 14:58:51 UTC