[Om] Proposal for Extending OpenMath Standard with a JSON Encoding

Tom Wiesing tom.wiesing at fau.de
Mon Jul 8 11:28:15 CEST 2019


Dear Moritz, dear all, 



> On 8. Jul 2019, at 10:58, Moritz Schubotz <physik at 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.wiesing at 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



More information about the Om mailing list