Dear Moritz, dear all,
> On 8. Jul 2019, at 10:58, Moritz Schubotz <phy...@physikerwelt.de> wrote: > 1) The name of the attribute "kind" might be confused with the > proposed MathML4 attribute "kind" > https://github.com/mathml-refresh/mathml/issues/80, also > https://github.com/mathml-refresh/mathml/issues/68 Is that something > you are aware of? No, it’s not something I was aware of (the encoding was designed before any of those issues were filed). I’m happy to change it to something like ’type’ if there is a risk of confusion. > 2) What are the advantages over a generic http://www.jsonml.org/ or > the custom > https://github.com/lurchmath/openmath-js/blob/master/docs/api-reference.md#writingsaving-openmath-objects > (cf. http://mailman.openmath.org/pipermail/om/2018-May/thread.html) The main problems are: - JSONML uses a generic encoding instead of making use of JSON-native datatypes. This e.g. enforces encoding integers as strings instead of just using JSON numbers. - Parts of the XML encoding introduce extra elements, e.g. using OMATP for attribute / value pairs. JSONML would introduce some overhead for objects, which is avoidable in JSON by using things like nested arrays. - The custom approach linked was written as a JavaScript, not JSON, encoding. It uses minimal names, making it hard for users to write and programers to implement. - Neither JSONML nor JSON have a schema that allows validation of JSON-encoded OpenMath objects. This would be particularly useful as a schema can be used to nearly automatically generate type definitions for most programming languages. In particular, the goals of this proposed encoding are: - Create a programming language-independent JSON Schema - Ensure that all attibute names are human-reable and understandable - Make translation from XML to JSON schema easily possible - Use JSON-native types where possible, and avoid XML peculiarities like pseudo elements These points are more or less copied from the paper last year [1], in particular Section 2 “Existing JSON Encodings for OpenMath” (IIRC I linked this at the bottom of my last email). You can also find another writeup at [2]. Greetings, Tom [1] http://ceur-ws.org/Vol-2307/paper53.pdf [2] https://github.com/tkw1536/OpenMath-JSON/blob/master/doc/openmath.md > Best > Moritz > http://moritzschubotz.de | +49 1578 047 1397 > > On Mon, Jul 8, 2019 at 10:08 AM Tom Wiesing <tom.wies...@fau.de> wrote: >> >> Dear all, >> >> Me and Michael would like to propose an extension of the OpenMath standard >> to endorse an OpenMath JSON Encoding. We have made a pull request at [0] and >> attached a diffed pdf. >> >> JSON is a lightweight data-interchange format used heavily in the Web >> Applications area. Adding a JSON Encoding thus contributes to making >> OpenMath web-interoperable. The source code for a validator of this proposed >> encoding, as well as a translator from/to the XML encoding can be found at >> [1]. It is also accessible via API at [2]. >> >> We presented this encoding during the OpenMath workshop at CICM 2018 (see >> [3] and [4]), however we were only able to make a concrete standard proposal >> until now. We are hoping to discuss this during the upcoming OpenMath >> workshop at CICM 2019 next week, however wanted to send out our proposal >> beforehand. >> >> Greetings, >> Tom >> >> [0] https://github.com/OpenMath/OMSTD/pull/69 >> [1] https://github.com/tkw1536/OpenMath-JSON >> [2] https://omjson.openmath.org >> [3] http://ceur-ws.org/Vol-2307/paper53.pdf >> [4] https://www.cicm-conference.org/2018/slides/OpMa2.pdf _______________________________________________ Om mailing list Om@openmath.org http://mailman.openmath.org/cgi-bin/mailman/listinfo/om
