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

Thank you, Ivan.

Best,
Peter.

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
>
>