# ISSUE-9: Sort out integrals between OpenMath and MathML

## Sort out integrals between OpenMath and MathML

- State:
- CLOSED
- Product:
- All
- Raised by:
- Michael Kohlhase
- Opened on:
- 2007-02-06
- Description:
- Integrals are used differently in OpenMath and MathML. In OpenMath, we have two

symbosl int@calculus1 for the indefinite integral and defint@calculus1 for the

definite integral. Both are operators applied to functions (to be constructed

by

lambda). In MathML we have the int element for definite and indefinite

integrals, and it can both be used both as a binder and as an applied operator.

Both usage patterns are sensible, but we must (the CDs mandate it) distinguish

between binder- and applied symbols. The question now is how to best deal with

legacy representations of integrals, there are lots of them out there.

I propose to keep the intuition that all of these are binding constructs, so

that the current MathML2 code base stays valid. We should probably introduce

new

symbols for the OpenMath-style operators (e.g. define for the definite

integral), so that we can say that

<apply><int/><domainofapplication>S</domainofapplication><ci>f</ci></apply>

refers to defint

The same observation holds for sums and products, and probably in general for

operators with qualifiers, which seem to have been largely forgotten in the

MathML CD group of OpenMath. - Related Actions Items:
- No related actions
- Related emails:
- AW: ISSUE-9: Sort out integrals between OpenMath and MathML (from stan.devitt@gwi-ag.com on 2007-02-07)
- ISSUE-9: Sort out integrals between OpenMath and MathML (from dean+cgi@w3.org on 2007-02-06)

## Related notes:

It is clear that OpenMath insists on the two separate representations, one

definite, and one indefinite, while MathML infers intent from the signature.

So the current situation is that the OpenMath mapping is to the same element

with two different signatures and it is well defined and unique and

invertable. But, I can understand the desire for the one-to-one mapping at

the element to element level.

While one way of solving this is to add optional and redundant defint operator

to MathML this does not solve the problem in general (unless we are going to

add a whole long list of operators). Can we do better?)

If I recall the comments from \'lastcall\' last time around, at the same time as

we are fixing these operators, we need to regularize the capabilitz.

That is, we need the same capability (bind versus apply using Michaels

terminology) as a more general construct for user defined operators if we do

not already have it, or at least we need to clarify that it is there and how

to use it.

The absence of such a capability would truly limit the expressivity of MathML

and is at some level much more important to address than the exact syntactic

mapping between the two.

Could we not introduce some sort of markup that triggers mapping to OpenMath\'s

definite form more explicitly versus the other? It would be optional, clarify

our definite int, and be usable in general.

we have done that, closing the issue

Michael Kohlhase, 8 May 2008, 06:14:25Display change log