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

Hi Ivan,

I keep coming back to your email and since I don't see an opportunity to
talk directly, I'll try once more.

> I think here is the core of our differences. I believe it is necessary to
have a standard (or maybe 1-2 standards if necessary) to provide a standard
syntax for mathematics on the Web; you seem to be comfortable having just
tools around with renderers around without any standards.
> I do not really care whether it is MathML or LaTeX or something else, but
it has to be
>
> - usable for the various communities
> - it is unambiguously implementable within or on top of browsers
>  I am not saying it must be part of HTML5 as it is today, that is a
different issue.

It seems we cannot agree on what we're talking about. You continue to
mention MathML and LaTeX as examples but they are wildly different things
(both from each other and from current web technologies); I find this
difficult.

So repeat myself: I'm trying to keep two things separate: standards for
rendering equation-like layout on the web and standards for expressing
mathematical and scientific knowledge on the web. These are orthogonal
problems.

For the former, we could use a handful of improvements in CSS or SVG (but
really only to make it easier or make it easier faster). But those are good
standards with great tools for authors to leverage them; I don't see a use
case for new standards here.

For the latter, I suspect it's still too early to work on it; very little
STEM content goes beyond replicating (unsemantic) practices from print. I
think it is, ultimately, a creation/authoring problem (or perhaps one of
"AI" if one is so inclined) and thus a cultural one. Granted, I'd be happy
to be wrong on this. If you want to build such a standard, I would suggest
to start forming a task force and seeking others to join it.

Anyway, I hope this makes it slightly clearer why I think we're talking
about very different things.

Best,
Peter.


2018-01-16 18:54 GMT+01:00 Ivan Herman <ivan@w3.org>:

> Hi Peter,
>
> On 16 Jan 2018, at 16:08, Peter Krautzberger <peter@krautzource.com>
> wrote:
>
> Hi Ivan,
>
> I feel like we're talking about different things and I don't think know
> how to overcome this miscommunication. One last try though.
>
> > Well, that is where we may disagree. You say 'might be nice', and I say
> it is a necessity.
>
> I agree that we disagree. But I have more reasons that will be
> side-tracking even further.
>
> > Let me turn the question around: what is your view (because I do not
> really understand) on how authors should author their mathematical
> formulae? What should a publisher use in their workflow, what should an
> educational publisher use? Do you mean that each of them should use a
> different tool and there is no need for anything standard?
>
> This sounds as if people didn't have anything to work with. Everyone has a
> solution that works for them. Some better, some worse.
>
> At the same time it's also not like there's a mess of hundreds of ways of
> doing this. There are a handful of formats used for storing equation layout
> information (with TeX, MathML, Word probably representing an exremelty vast
> majority) combinend with a handful of ways of rendering such content on the
> web.
>
> Most publishers are still only capturing print-style equation layout; TeX
> and MathML are prefectly fine for that.
> Those who do things beyond print usually have more complex, web-centric
> scenarios; the equation layout becomes fragmented in a more complex web
> application structure, e.g., interactive teaching or assessment tools. If
> those groups feel the need for standardization, they should speak up.
>
>
> I think here is the core of our differences. I believe it is necessary to
> have a standard (or maybe 1-2 standards if necessary) to provide a standard
> syntax for mathematics on the Web; you seem to be comfortable having just
> tools around with renderers around without any standards. I do not really
> care whether it is MathML or LaTeX or something else, but it has to be
>
> - usable for the various communities
> - it is unambiguously implementable within or on top of browsers
>
> I am not saying it must be part of HTML5 as it is today, that is a
> different issue.
>
> (I work for a standards body, remember? :-)
>
>
> > And I am not sure that is a good thing. That is exactly my point.
>
> I agree but it's what MathML wanted to do and I think it's what endears it
> to the XML community.
>
> >  I could say: "Literary content/knowledge is not determined by layout
> even if the textual layout does express it." Nevertheless, there was/is a
> need to produce a very precise definition on how HTML elements are laid out
> by the browser engines: publishers, for example, rely on this.
> > I do not think there is such a big difference in this respect between
> math and, say, HTML.
>
> This completely confuses me.
>
>
> Let us forget about this then. I answered to one of your side issue.
>
>
> >  I am not sure I agree. A mathematical layout is, in this context, part
> of a larger layout which is the page in a book (offline or online). If the
> result of the equation's layout is unpredictable, because the underlying
> layout engines follow very different strategies, we may have a problem.
> Unless the specification on how the layout should/must happen is more
> strictly determined.
>
> I was talking about different but equally robust ways of doing design on
> the web. So I think we're agreeing?
>
>
> Not sure. Equally robust is fine. But, regardless of whether the
> implementation is based on CSS, SVG, or anything else, they should also
> produce the same layout as identically as possible. Just like the same HTML
> page should look, essentially, the same on a FF and Chrome browsers with
> only very small differences.
>
>
> Let's continue in live conversation some time.
>
>
> Sure
>
> Ivan
>
> Best,
> Peter.
>
>
>
>
>
> 2018-01-16 11:28 GMT+01:00 Ivan Herman <ivan@w3.org>:
>
>> Hi Peter
>>
>> (skipping things where we agree:-)
>>
>> On 15 Jan 2018, at 20:59, Peter Krautzberger <peter@krautzource.com>
>> wrote:
>>
>> <skip>
>>
>>
>> >  I believe there is a need for some declarative (or mostly
>> declarative) syntax for mathematics.
>>
>> Are you mixing equation layout with mathematics or are you really
>> thinking about Content MathML? If you have used it, what was your
>> experience?
>>
>>
>> No, I do not mean content markup. That part of MathML seems to be, alas!,
>> dead I guess.
>>
>> Anyway, yes, it might be nice if it existed (I say might because I'm
>> generally not a huge fan of print-focused equation layout on the web). In
>> my experience, we'd really have to talk about human authoring if we wanted
>> to solve this.
>>
>>
>> Well, that is where we may disagree. You say 'might be nice', and I say
>> it is a necessity.
>>
>> Let me turn the question around: what is your view (because I do not
>> really understand) on how authors should author their mathematical
>> formulae? What should a publisher use in their workflow, what should an
>> educational publisher use? Do you mean that each of them should use a
>> different tool and there is no need for anything standard? (This is where
>> this issue _is_ close to the HTML level, ie, to the fact that the existence
>> of an HTML element set is important.)
>>
>> (I suspect that authors/content providers would vote with their feet.
>> Whether it is MathML or LaTeX or something else may be open, but the
>> community needs a stability in this respec… ie, a standard would or does
>> emerge…)
>>
>> > Furthermore: there is an issue of interoperability. The HTML community
>> has put in an enormous energy to define, in a real detail, on what really
>> happens for each HTML element, and how they are presented on the screen.
>> What they achieved is a significant interoperability among browsers as for
>> layout and other things.
>>
>> Yes. And MathML intentionally wants to leave it up to the renderer:
>> Section 3.1.1 "MathML presentation elements only suggest (i.e. do not
>> require) specific ways of rendering".
>>
>>
>> And I am not sure that is a good thing. That is exactly my point.
>>
>>
>> > Isn't there a need to do something similar for math? Some sort of a
>> specification that says "this and this feature is implemented through this
>> and this CSS/SVG/HTML element"?
>>
>> Again, I think this is mixing layout with semantics. Mathematical
>> knowledge is not determined by layout even if equation layout is.
>> Presentation MathML does not encode mathematical knowledge, it encodes
>> equation layout information; those are two very different things.
>>
>>
>> I could say: "Literary content/knowledge is not determined by layout even
>> if the textual layout does express it." Nevertheless, there was/is a need
>> to produce a very precise definition on how HTML elements are laid out by
>> the browser engines: publishers, for example, rely on this.
>>
>> I do not think there is such a big difference in this respect between
>> math and, say, HTML.
>>
>>
>> CSS and SVG are very good at capturing layout information and they are as
>> robust as it gets for today's web. Obviously, they make no claims on
>> semantics.
>>
>> > Otherwise we incur the danger of different tools mapping math on
>> completely different feature sets, leading to a possible mess...
>>
>> Again, it's not about math but equation layout. I don't think the "mess"
>> of doing things one way with CSS, another way with SVG is a problem; it's
>> something you see every day on the web; sites like codepen are full of
>> examples; it's creative and inspiring, both for authors, specs, and
>> implementations.
>>
>>
>> I am not sure I agree. A mathematical layout is, in this context, part of
>> a larger layout which is the page in a book (offline or online). If the
>> result of the equation's layout is unpredictable, because the underlying
>> layout engines follow very different strategies, we may have a problem.
>> Unless the specification on how the layout should/must happen is more
>> strictly determined.
>>
>>
>> Cheers
>>
>> Ivan
>>
>>
>>
>> Best,
>> Peter.
>>
>>
>>
>> 2018-01-15 16:15 GMT+01:00 Ivan Herman <ivan@w3.org>:
>>
>>> Oops, sorry
>>>
>>> On 15 Jan 2018, at 16:05, Ivan Herman <ivan@w3.org> wrote:
>>>
>>> I am bound to the current MathML syntax.
>>>
>>>
>>> I should have written: "I am not bound" :-)
>>>
>>> ivan
>>>
>>>
>>> I could even to have several syntaxes aimed at different communities.
>>> But you seem to say that there is no need for such standard whatsoever.
>>> This may be a source of our disagreement… (unless I completely
>>> misunderstand what you say).
>>>
>>> Furthermore: there is an issue of interoperability. The HTML community
>>> has put in an enormous energy to define, in a real detail, on what really
>>> happens for each HTML element, and how they are presented on the screen.
>>> What they achieved is a significant interoperability among browsers as for
>>> layout and other things. Isn't there a need to do something similar for
>>> math? Some sort of a specification that says "this and this feature is
>>> implemented through this and this CSS/SVG/HTML element"? Otherwise we incur
>>> the danger of different tools mapping math on completely different feature
>>> sets, leading to a possible mess...
>>>
>>> Ivan
>>>
>>>
>>>
>>> ----
>>> 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
>>>
>>>
>>
>>
>> ----
>> 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 Thursday, 25 January 2018 17:03:20 UTC