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:
  1. AW: ISSUE-9: Sort out integrals between OpenMath and MathML (from stan.devitt@gwi-ag.com on 2007-02-07)
  2. 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.



7 Feb 2007, 00:00:00

we have done that, closing the issue

Michael Kohlhase, 8 May 2008, 06:14:25

Display change log ATOM feed


Chair, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: 9.html,v 1.1 2016/05/09 13:05:45 carine Exp $