Integrated treatment of formulas/equations in OpenDocument

[Bryce L Nordgren <bnordgren@fs.fed.us>]

If you like the following, you probably want to read the attachment.  Otherwise, you probably don't.  It's pretty pie-in-the-sky, but it's a rational direction to go in, I think.  

"The vision for formula objects is universality: all office
documents recognize the same formula objects.  Given the same formula
object, text and presentation documents should render the formula
correctly, and spreadsheet documents should perform the correct
calculation.  The user does not need to manage two separate
articulations of the same concept: one for display and one for
calculation.  Cutting and pasting (or even linking) an equation from
a context where it is rendered to a context where it is calculated
should automatically produce the correct results."

and

"

The vision for formula documents is that they should serve as an
organizing force for formulas introduced into, or commonly used with,
a user's office documents.  If a user deals with mathematical objects
at all, they should be expected to deal with a core set of formulas
on a regular basis.  Users exploring a new domain may wish to borrow
their colleague's formula library to avoid painstakingly re-entering,
and subsequently debugging, a complex equation.  The formula document
is a hub for the definition, documentation, and organization into
libraries of the formulas commonly required by the user."

This is an offshoot of the discussion last week/earlier this week with Leonard Mada regarding regression lines on charts and the desire to implement other regressions in something like S+/R.  The only thing I didn't really like about that idea was the selection of a particular implementation language.  So I started to investigate how far one might be able to run with just Content MathML and the OpenMath content dictionaries.  Viola.

Thanks for listening,
Bryce

MathMLOpendocument.odt