MathML is a failed web standard • Hacker News Board

Re: MathML is a failed web standard

#151

Post by jdmichal » Thu, Apr 07, 2016, 9:53 PM UTC

roller wrote: post #129

jdmichal wrote: post #122

Earlier quoted context omitted.

What you have doesn't work. What if I have "mi, mo, mfrac, mo, mi" at the top level? So something like "a - b/c + d". You can't specify the same key twice in JSON. Also, keys are technically unordered, so there's no guarantee that a parser will put that top-level "mi" before the "mfrac". JSON is great at many things, but polymorphic substructures are AFAIK only really possible with everything being an object defining…

While this format is more generic, an abbreviated encoding can sometimes accomplish the same thing. For example, just moving the "type" to be the object key and removing the implied secondary name gets you this far: { "mrow": [ { "mi": "x" }, { "mo": "=" }, { "mfrac": [ { "mrow": [ { "mo": "-" }, { "mi": "b" }, { "mo": "±" }, { "sqrt": { { "mrow": [ {"mi": "b"}, {"msup": { "mi": 2 }}, {"mo": "-"}, {"mi", "4ac"} ]} }}…

Sure, that works as long as each type only has one property. Decoding it might be problematic; I don't know any serializers that would handle that kind of mapping natively.

Re: MathML is a failed web standard

#152

Post by ga6840 » Thu, Apr 07, 2016, 10:19 PM UTC

PaulTopping wrote: post #100

One of my biggest complaints about Peter K's "MathML is a failed web standard" is that most people read that without taking note of "web" in the middle. MathML has been quite successful in publishing and as a computer representation. As far as whether or not MathML is a failed WEB standard, I have a lot more to say about that here: http://bit.ly/1ZLfCF8 .

Thanks for your response. I totally agree it is not useful trying to code semantic into math markups.

Re: MathML is a failed web standard

#153

Post by pfooti » Thu, Apr 07, 2016, 11:00 PM UTC

koolba wrote: post #51

spicyj wrote: post #23

Earlier quoted context omitted.

Yeah. I think that's inevitable with an XML syntax. XML is good at some things, but representing math expressions clearly is not one of them.

> Yeah. I think that's inevitable with an XML syntax. XML is good at some things, but representing math expressions clearly is not one of them. What is XML good at? (by good I mean better than alternatives like JSON, YAML, HAML, etc) The only thing I that might qualify is a long term/archival quality document format like ODF/OOXML. The inherently embeddedable nature of XML does seem like a nice fit but it gets very b…

Whenever I need to send dates across the wire with a JSON API, I sort of miss XML a little bit. It's a lot easier, and there are existing patterns and tools to help there. JSON really only supports three data types - boolean, numeric, and string. Any other type needs to be fiddled with some ad-hoc system for communicating the schema or just expecting created_at to be a date.

XML, on the other hand, had the ability to do something using attributes in the element or a DTD / XSL. Occasionally I do miss that ability to communicate data schema alongside the data. But only occasionally.

Re: MathML is a failed web standard

#154

Post by ga6840 » Thu, Apr 07, 2016, 11:39 PM UTC

spicyj wrote: post #148

ga6840 wrote: post #146

Earlier quoted context omitted.

I think we do not need semantic representation in HTML case at all. For example, f(x+1) can be a multiplication, or a function, but should we write something like \function f (x+1) ? I think knowing the layout similarity with query is enough for math-ware search engine to identify similar math expressions. Adding too much in Math HTML standard is not helpful but redundant.

For sighted users it may be possible to differentiate, but whether "f of x plus 1" or "f times x plus 1" is read aloud is a significant difference.

What I really want to say is whether f(x+1) is function or multiplication does not matter that much in terms of both browser presenting and math-aware search, moreover, extracting semantics can be done by algorithm from context. Considering that few author want to annotate on their expression semantic, and adding semantic does not really help math-aware search, I argue for the necessity for bringing math semantic notation into WEB.

Re: MathML is a failed web standard

#155

Post by wtbob » Fri, Apr 08, 2016, 12:34 AM UTC

roller wrote: post #129

jdmichal wrote: post #122

Earlier quoted context omitted.

What you have doesn't work. What if I have "mi, mo, mfrac, mo, mi" at the top level? So something like "a - b/c + d". You can't specify the same key twice in JSON. Also, keys are technically unordered, so there's no guarantee that a parser will put that top-level "mi" before the "mfrac". JSON is great at many things, but polymorphic substructures are AFAIK only really possible with everything being an object defining…

While this format is more generic, an abbreviated encoding can sometimes accomplish the same thing. For example, just moving the "type" to be the object key and removing the implied secondary name gets you this far: { "mrow": [ { "mi": "x" }, { "mo": "=" }, { "mfrac": [ { "mrow": [ { "mo": "-" }, { "mi": "b" }, { "mo": "±" }, { "sqrt": { { "mrow": [ {"mi": "b"}, {"msup": { "mi": 2 }}, {"mo": "-"}, {"mi", "4ac"} ]} }}…

FWIW, this would be a literal s-expression translation:

    (mrow (mi x)
          (mo =)
          (mfrac (mrow (mo -) (mi b) (mo ±)
                       (sqrt (mrow (mi b) (msup (mi 2)) (mo -) (mi 4ac))))
                 (mrow (mi 2a))))

And this would be a saner one, where mrow is implied:

    ((mi x) (mo =) (mfrac ((mo -) (mi b) (mo ±)
                           (sqrt (mi b) (msup (mi 2)) (mo -) (mi 4ac)))
                          (mi 2a)))

I think either of those is clearly and inarguably superior.

Re: MathML is a failed web standard

#156

Post by Retra » Fri, Apr 08, 2016, 12:56 AM UTC

analyst74 wrote: post #95

dginev wrote: post #85

I don't know how many of the people lamenting MathML ever came to exist are active math-on-the-web developers. I for one am dealing with third-party math equations on a daily basis and can only dream of the wonder of ubiquitous MathML support in all major browsers. The details as to why are here: http://prodg.org/blog/mathml_please/2015-09-16/MathML%20on%2... ! As things stand, math handling on the web is inconvenien…

I am with you. Some people write their math by hand in LaTeX or other formats, but many use visual tools and draw math similar to drawing diagrams. Then those tools generate whatever source code necessary. In those scenarios, MathML would be much easier to deal with than most other formats. Also, Presentation MathML support is much easier to implement than full-scale support of LaTeX or other more complete math solut…

And "many people" write code by dragging squares around in a GUI and entering equations into spreadsheets, but that method is completely unacceptable to a professional.

The only people who write math in a drawing program are people who don't do enough math to be bothered to learn it.

Re: MathML is a failed web standard

#157

Post by nickpsecurity » Fri, Apr 08, 2016, 4:03 AM UTC

flatline wrote: post #66

koolba wrote: post #51

Earlier quoted context omitted.

> Yeah. I think that's inevitable with an XML syntax. XML is good at some things, but representing math expressions clearly is not one of them. What is XML good at? (by good I mean better than alternatives like JSON, YAML, HAML, etc) The only thing I that might qualify is a long term/archival quality document format like ODF/OOXML. The inherently embeddedable nature of XML does seem like a nice fit but it gets very b…

XML grew out of SGML/HTML, and there's no denying that its age shows. It's kind of like going into a house built in the 90s and seeing all the little things that just scream "90s house - that looks so dated!" Did you know that web browsers have native support for XML? Try fetching an xml resource and pulling the responseXML value off the XHR - you have another DOM object right in your hands, that you can treat just l…

Great explanation. The tooling and first mover advantage were the reasons I started working with it back when it was in its infancy.

Re: MathML is a failed web standard

#158

Post by dginev » Fri, Apr 08, 2016, 7:56 AM UTC

ga6840 wrote: post #143

I am building a project and doing research on math-aware search (my project is hosted on https://github.com/t-k-/the-day-after-tomorrow ) As for the search engine for math, it is a pity that MathML has become a standard "input" for mainstream research. The most famous conference on Math search: NTCIR, is actually publishing its main dataset/corpus in MathML. Converting MathML back into LaTeX is possible but error-pro…

I am the person behind generating the original NTCIR math datasets, and probably most of the research-produced MathML out there. We've recently presented that we have more than 350 million formulas from arXiv converted over to MathML, together with the rest of the papers as HTML5.

As someone who has stared at arXiv TeX/LaTeX for years, I can testify you don't want to be looking at TeX math in actual latex documents, there is a lot more that goes in there beyond the toy formula syntax used on the web.

As also someone who has worked on math search engines and math-rich NLP for a few years, complaining that you have a structured machine-parseable representation for mathematics and wanting TeX instead sounds naive. On one hand, the MathML formulas in the datasets already could preserve the source TeX (the TeX annotations may even be there, I can't remember right now), should you need it directly. On the other hand, you can use any structured methods, such as the ones used by content-based search engines such as MathWebSearch, or handpick any relevant information from the MathML tree to feed it back into a statistical algorithm, as done for example by the WebMIAS search engine.

The most fundamental bit to understand if you're doing research on automated processing of human mathematics is that formulas are two dimensional objects best represented as trees, be they layout trees describing the presentation, or operator trees describing the content, or some other hybrid tree that tries doing both (such as LaTeXML's XMath spec).

Re: MathML is a failed web standard

#159

Post by dginev » Fri, Apr 08, 2016, 8:27 AM UTC

magicalist wrote: post #114

dginev wrote: post #85

I don't know how many of the people lamenting MathML ever came to exist are active math-on-the-web developers. I for one am dealing with third-party math equations on a daily basis and can only dream of the wonder of ubiquitous MathML support in all major browsers. The details as to why are here: http://prodg.org/blog/mathml_please/2015-09-16/MathML%20on%2... ! As things stand, math handling on the web is inconvenien…

All you've really written here is that you want a spec and support for properly displaying math content in the browser, but then you jump to happily taking MathML because it already exists in some places. None of that addresses the critiques of MathML as a bad standard, one that fits poorly with the layout and display of the rest of the web. The author here is saying we want a spec and support for properly displaying…

"None of that addresses the critiques of MathML as a bad standard, one that fits poorly with the layout and display of the rest of the web."

I can't but see these as secondary to why MathML isn't supported yet. The current state works already well enough in Firefox, but no one would use it, since why support a single browser? And we've had it working nicely in Chrome before the devs pulled the plug because of lack of manpower. You could try to overrule the cruft from say the upcoming HTML5.1 spec, and find a good alignment with CSS. If it proves annoying or impossible, you could take the process further towards a MathML 4 that offers a CSS-compatible subset, etc. And the W3C Math group could approve of an experimental note much quicker, so that we don't sit around for years waiting for the standardization process.

The web mathematics community is a small one, and most of us have strong opinions on MathML. The way this debate is heading will tear the community in various tinier subfractions and likely continue the "math-on-the web winter" for another decade.

In my eyes, nothing has changed really - we've had browsers silently complicit in ignoring MathML, and a community tiny enough to not be able to move them in any direction. The two important bits for a math-on-the-web developer to have sanity are 1) expose the mathematics content of a page as data (the way we do tables) and 2) do so in a standard cross-browser way. Anything else leads to insane hacks, and tools such as math search engines, clipboards etc. can not be implemented directly.

Re: MathML is a failed web standard

#160

Post by dginev » Fri, Apr 08, 2016, 8:31 AM UTC

ga6840 wrote: post #145

erikpukinskis wrote: post #99

Earlier quoted context omitted.

Do you think other kinds of content should be included in the web spec too? So, special tags for musical notation, special tags for all forms of maps and geographic, geological features, tags to represent chemical structures, tags for all major forms of engineering notation, etc? To me, it's not that I don't think there is a use case for MathML, it's that it's too content-specific to make sense at the browser level.…

Agree, we do not include a 4*4 image in HTML by inserting ...... In browser level, I think we should treat math expression as a simple and atom component, and the only benefits to expose DOM/XML/JSON or whatever structural information in webpage is probably you can manipulate/extract info from it (e.g. using Javascript). Do we really need to manipulate a math expression? I think a simple " \frac a b " makes much sens…

"Do we really need to manipulate a math expression?"

If you don't, please don't say no one does. Having a math DOM allows for actual interactivity with mathematics, from highlighting, copying subtrees, embedding links, having on the fly computations/simplifications, etc.

Not to mention add-on services like math indexing and search.

Yes, we need to manipulate and machine-read math expressions, if we want to finally take online math workflows to the 21st century.