[math-on-web] CG meeting minutes, 2018/05/10

Hi everyone,

Here are the minutes from the meeting on May 10.

Best,
Peter.

# MathOnWeb CG 2018-05-10


* Present: Peter, Mike, Steve, Arno, Volker, Neil
  * Regrets: Charles

* Agenda
  * update on TPAC 2018
  * update on Arno's json proposal
  * updates from CSS TF

* AGENDA: TPAC 2018
  * we got in
  * TFs should think about early appointments
  * Neil: where is it?
    * Lyon, ~Oct20
  * Volker: precise schedule?
    * Peter: comes out next week
  * ACTION Peter email to mailing list
* AGENDA: JSON proposal
  * Arno: walk through
    * http://docs.mathlive.io/tutorial-MASTON.html
    * a JSON format for storing the formula semantic
    * idea is to convert from various formats, outputing as well
    * but intent is not to be an alternative to LaTeX or MathML
    * no guarantee that you can render from it
    * focused on the structure
    * Volker: noticed that binary operators are binary
      * that makes parsing difficult sometimes, depending on parser
      * e.g., a+b+c might have different LHS / RHS depending on how your
parser starts
    * Arno: good point!
      * I'm trying to not have too many cases for encoding so you have
easier decoding
      * more work encoding, less decoding
      * burden on producer since that works is done once, decoding will be
many times
    * Arno: that's why it tries to avoid doing things in many ways
      * of course with addition it's so common, so there's a reasonable
case to have multiple versions
      * can either present + as binary or n-ary add function
  * Neil: equality is also a=b=c=d but here LHS/RHS
    * Arno: yay, feedback!
      * let's look at Grammar=>function
        * some predefined, possible to customize
        * no predefined function for equality
        * but can be customized or added permanently
      * equality is tricky, it means a lot of things (assignment,
definition, equality operators)
        * in sequence, it's not clear what it means
      * but could be clarified with different functions
  * Arno: let's move back a bit
    * => Native Strings
    * JSON AST
      * native strings
      * favoring Unicode
        * in particular imaginary i, not ascii i
      * not favoring mathvariants or xml entities
      * but e.g. U+2102 ℂ is clearly best
        * but hard to input
        * easier with mathvariants
        * Neil: but human input is not the goal, right?
          * Arno: sure
          * Neil so commands or \u should be fine
  * Peter: my only complaint (not to you) is that Unicode decided to
enshrine mathvariants rather than mathematical entities that are
represented by single glyphs (e.g., reals, rationals,)
    * Arno: right. sidesteppgin that issue (at least for now). Otherwise
we'd need dictionaries or some such and that's been tried
  * Arno: => optional keys
    * two representational: latex or mathml fragment for subexpression
      * to ensure visual representation
    * class and styles could also suit this
    * I've found this to be helpful
    * Neil: question on mathml/tex/style
      * optional to clarify how it's displayed
      * e.g., in MathML you could use IDs to connect the two
      * does this lead to exponential explosion?
        * or just partial?
      * Arno: just partial and just for avoiding unclear/non-standard
presentation
      * for example: parentheses. If expression doesn't need it, but you
want it there, you could use this attribute
  * Arno: on the other hand, attaching semantic information
    * e.g., attaching wikidata information c => Q2111 (speed of light)
    * e.g., i imaginary, Complex numbers: Q26851286
    * optional but allows to carry more semantic information
    * allows for more precision
  * Arno: => grammar
    * Basic expression
    * you identify the type of a node by presences/absences of attributes
      * e.g., num
      * JS polymorphism allows for {"num": 1} and 1 being identified
      * native-number can be higher precision
    * ARno: complex number
      * Peter: question: why not nums for re & im
        * Neil: a+bi
        * arno: will think about it.
    * Neil: for high precision, just a string and read in later? Precision
problems?
      * Arno: bigint becomes string
      * also infintiy and NaN (which are not strictly JSON)
  * Arno: if not number, then => symbol
    * index seemed common enough (e.g., subscript for array index)
    * accent (as usual)
    * Neil: some accents are below. This would lead to ambiguity?
      * Arno: right. Assume above since the list so far from Unicode/MML
just have those
    * Neil: index. a_i in sequence an example?
      * Arno: yes. Just convenience
      * Neil: worried about two different representations for the same
thing?
        * Arno: yes. trying to strike the balance
          * try to limit complexity on the decoding
          * might be better to have more simplicity and regularity while
limiting expressivity
  * Arno: => functions
    * for ease, I've split functions and operators
    * name, argument(s), fence, sub, sup, accent
      * sup for inverse
    * Volker: do you always have to have an argument?
      * for writing notation it is common not ot
      * Arno: right. should clarify that it's optional there
    * Arno: some functions included (add, mult)
      * not sure how far to go
      * eg trigonometry (with branch cuts)
      * wikidata might be a better way to be clear on what function you're
after
    * Neil: a bit arbtiraty, what about subtraciton, equality
      * Arno: yes. not commutative thus problem for JSON
      * Neil: brings up weirdness
      * not all operators can be represented as functions?
      * Arno: options are array, so has order
      * Neil: so what's the problem?
       * Arno: e.g., need parentheses (1+2+3 but 1-2-3 you need to know
which order to apply)
* Peter: let's continue next time
  * due to the AIM workshop, that's in **4 weeks**