OMV with complex presentations

[jbs1]

migrated from Trac, where originally posted by kohlhase on 26-Oct-2007 6:06am

We have to get a final view on how we want to handle variables with complex presentations e.g. x_1. There was a discussion on the mailing list on this topic, in the thread starting at http://openmath.org/pipermail/om3/2007-July/000028.html. Many of the issues are resolved now: for OMS, the new notation definitions do most of the work.

For OMV, the problem somewhat remains; there are essentially four possibilities:

1. use OMATTR and friends to attach presentation (the classical OM solution).
2. use global? notation definitions (proposed by Paul in the thread above)
3. use use local notation definitions (proposed by Michael in the OMDoc book).
4. change the model of OpenMath Objects to have shared OMV in an OMBIND

The advantage of 1. is that we have to change nothing, the disadvantage is that we either have to attribute every occurrence of a bound variable (or that is what I understand) or we have to use sharing via an OMR element. Which makes it harder to see that we are actually dealing with a variable.

If I understand 2. correctly, notation definitions for variables are generic and global, they would associate a variable of name gothicA with a presentation MathML rendering via a notation definition.

<notation>
  <prototype>
    <om:OMOBJ><om:OMV name="gothicA"/></om:OMOBJ>
  </prototype>
  <rendering>
    <m:math><m:mi mathvariant="fraktur">A</m:mi></m:math>
  </rendering>
</notation>

This is very elegant in theory, but I see a problem where to keep the notation definitions. Is there a "presentation dictionary" mechanism needed? Another problem is that the set of variables names is infinite (think x_1, x_2,...). Another advantage (shared by proposal 3.) is that we can have nice presentations of function variables (see the example in section 19.4 of the OMDoc book http://omdoc.org/pubs/omdoc1.2.pdf).

Propoal 3. is similar in spirit to 2., but it keeps the notation definition locally in the <bvar> element via an attribution, something like

<OMBIND>
  <OMBVAR>
    <OMATTR>
      <OMATP>
        <OMS cd="something" name="notation-def"/>
        <OMFOREIGN>
          <notation>... from above</notation>
        </OMFOREIGN>
      </OMATP>
      <OMV name="gothicA"/>
   </OMATTR>
 </OMBVAR>
...
</OMBIND>

This gets around the referencing and infinity problems in proposal 2., but is still relatively heavy in representational overhead. Of course that could be fixed by giving OMBIND (or actually OMBVAR) a place to store notation definitions, as in

<OMBIND>
  <OMBVARS>
    <OMV name="gothicA"/>
    <notation>... from above</notation>
  </OMBVARS>
...
</OMBIND>

Finally 4. is probably the most radical (as it changes the concept of OM objects). It solves the sharing problem by simply stating that all bound (and binding) occurrences of the variables are identical.

[jbs1]

migrated from Trac, where originally posted by kohlhase on 26-Oct-2007 6:07am

I must say that after I have written up everything I still like proposal 3. best :).

[jbs1]

migrated from Trac, where originally posted by kohlhase on 26-Oct-2007 6:10am

But of course proposal 3. is probably the largest change to OpenMath, since we would include notation definitions into the language of OM Objects. So, I do not know, maybe I am tending towards 1. then with OMR best practice then.

[jbs1]

migrated from Trac, where originally posted by kohlhase on 25-Feb-2011 12:33pm

rescheduling.

[jbs1]

_migrated from Trac, where originally posted by lars_h on 15-Mar-2011 6:06pm_

A newcomer's take on this: I don't see why we can't have (1), (2), and (3).

To elaborate, when I wrote an OM->LaTeX converter (the code of which can be seen here if anyone feels an uncontrollable urge to RTFS), I designed it as a multistage process, in which an OMOBJ is gradually converted to LaTeX code. In the main step, we're basically at (1): things should have an altenc#LaTeX_encoding attribution unless the wanted presentation is literally the name. Before that, various preprocessing steps have however been around to massage the OMOBJ into something more presentation-like (inserting where needed and migrating minuses to their usual positions as two notable activities). One of these steps is to attach OMATTRs controlling the presentation of OMSes (even standard ones like arith1#plus), and it's a trivial extension to do the same to OMVs, which would give us the functionality of (2), while also taking care of the "infinitely many variables" problem. Having the OMV-attributor record and give prescendence to attributions available already in the input would then provide (3).

Finally, since the linked-to discussion speaks about putting content in OMV elements, I have to say that I find it quite useful that many OM elements are specified to be empty: this makes the bodies of those elements a convenient place for early conversion stages to stash partial conversions of said elements, ;-) so I wouldn't like it if something else suddenly turned up there. OTOH, that part of the discussion might rather have been about the MathML counterparts of OMVs.

[kohlhase]

moved to https://github.com/OpenMath/OMSTD/issues/31