Copyright???2003?W3C^{?} (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This Note is a self-contained discussion of mathematical types in Content MathML. It contains non-normative interpretations of the MathML 2 Recommendation (2nd Edition) [MathML22e] and provides guidelines for the handling of advanced mathematical types using Content MathML. Please direct comments and report errors in this document to www-math@w3.org.
This document has been produced by the W3C Math Working Group as part of the W3C Math Activity (Activity statement). The goals of the Working Group are discussed in the Working Group Charter. A list of participants in the W3C Math Working Group is available.
Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. Patent disclosures relevant to this Note may be found on the Math Working Group's patent disclosure page.
1 Introduction
????1.1 Goals
????1.2 Overview
2 The type attribute
3 Advanced Typing
????3.1 The semantics Element
????3.2 Some Encodings for Structured Type Objects
????3.3 Associating Structured Types with MathML Objects.
????3.4 Structured Types and Bound Variables.
4
Related Work: Types in OpenMath
????4.1 Representing and Associating Types in OpenMath
????4.2 OpenMath's Small Type System
5 Types as used in appendix C of MathML 2
6 An Example with Complex Types
demonstrate in detail how to attach more advanced type information to a MathML object,
illustrate this technique with examples using various type systems, including the types discussed in Appendix C (Content Element Definitions) of the MathML 2.0 Recommendation, the type system used by OpenMath [OpenMath], and an example of a more complicated type system.
Content MathML, as specified in Chapter
4 of the MathML 2 Recommendation defines an
attribute called type
, which provides limited
support for mathematical types by allowing authors to
specify simple values such as "real",
"integer" or
"complex-cartesian" as the content of the
attribute. Such a simple construct is hardly sufficient
for specifying complex type information, especially as the
use of the attribute is not allowed on all the elements
where one might want to use it. Furthermore, another
problem is illustrated by the example below:
<math> <apply> <tendsto type="above"/> <ci>x</ci> <cn>0</cn> </apply> </math>
In this example, the type
attribute does not indicate
the domain of the tendsto
element, but rather the fact that
the limit is reached from above. The attribute can therefore not be
used to specify the domain of the tendsto
operator.
Another situation where the current approach is
problematic is where one needs to specify more complex
types, for instance the type of functions on complex
numbers yielding pairs of real numbers. Even though the
content of the type
attribute is open-ended, a
specification of all possible object types would
necessitate defining an attribute value syntax, e.g.
"complex → pair(real,real)". However,
this would add considerable complexity to the design of
MathML implementations, as this syntax would require
writing an specific parser.
Nevertheless there is a pressing need to express complex structured types in MathML, as modern treatments of formal and computational aspects of mathematics increasingly make use of elaborate type systems. However the observation that structured objects such as the example type above can be expressed very naturally in Content MathML leads to a better mechanism, detailed below.
The next section discusses the type
attribute in detail. The following sections describe and
discuss methods for incorporating richer type systems in
Content MathML, followed by a number of examples showing
possible scenarios.
In order to deal with more sophisticated typing systems, two key issues must be solved:
Specify a way to encode non-trivial mathematical type objects.
Determine a method to associate the type objects with the corresponding MathML object.
Regarding the encoding problem, it is a well-known fact
that developing a mathematical typing system is a difficult
task. However, several such systems exist and each represents
a major piece of development effort. Examples include the
Simple Type System developed by the OpenMath Consortium
[STS]. A significant part of Appendix C of
MathML itself deals with the issues of types and how they are
related. Fortunately, the semantics
element is
designed to support alternative notations, and thus allows
using the typing systems mentioned.
The following section discusses in detail how the
semantics
element can be used to describe types.
semantics
ElementThe next section discusses some of the possible type encodings supported by this approach.
In summary the MathML specification allows using the
semantics
element as a general annotation device
for MathML objects, where the definitionURL
attribute specifies the relation of the annotation to the
first child of the semantics
element. In
particular, this mechanism can be used to attach
structured type objects to mathematical objects. Below is
a more complex example showing such a type annotation in
OpenMath markup of the variable X_{Z}
represented using Content MathML markup.
(see 4
Related Work: Types in OpenMath for more details).
<semantics> <semantics id="typed-var"> <ci>X</ci> <annotation-xml definitionURL="type.html" encoding="MathMLType"> <integers/> </annotation-xml> </semantics> <annotation-xml encoding="OpenMath"> <OMOBJ xmlns="http://www.openmath.org/OpenMath"> <OMATTR xlink:href="typed-var"> <OMATP> <OMS cd="sts" name="type"/> <OMS cd="setname1" name="integers"/> </OMATP> <OMV name="X"/> </OMATTR> </OMOBJ> </annotation-xml> </semantics>
To make the correspondence clear, the parallel markup uses cross-references, as described in section 5.3.4 of the MathML2 specification.
A natural place to annotate types in formulas is in the declaration of bound variables. For example:
Here the bound variables
F
and
x
are annotated with type information by using the
semantics
element. The correspondence between
the declaring occurrence of the variable and the bound
occurrences are made explicit by the use of the
definitionURL
attribute, which points to the
respective bvar
element (see [MathMLBVar] for a discussion of this
technique).
Note that in this example, only the type information makes the formula true (or even meaningful) as in general it is not the case that applying arbitrary functions to arbitrary values yields results that are greater than or equal to zero.
A related way to express the information in the example above
that does not use the semantics
element in
bvar
is:
<math> <apply> <forall/> <bvar><ci>F</ci></bvar> <condition> <apply> <csymbol definitionURL="types.html#type_of"/> <ci>F</ci> <apply> <csymbol definitionURL="types.html#funtype"/> <csymbol definitionURL="types.html#int_type"/> <csymbol definitionURL="types.html#nat_type"/> </apply> </apply> </condition> <bvar><ci>x</ci></bvar> <condition> <apply> <csymbol definitionURL="types.html#type_of"/> <ci>x</ci> <csymbol definitionURL="types.html#int_type"/> </apply> </condition> <apply><geq/><apply><ci>F</ci><ci>x</ci></apply><cn>0</cn></apply> </apply> </math>
Here, the condition
element is used to express the type condition "such
that
F
has type
Z
→
R".
The transformation from the first to the second representation is a
well-known technique in typed logics called
relativization [Oberschelp], which transforms
formulas in a typed logic into untyped formulas without changing their
meaning. Although the two representations have similar semantics (given
reasonable assumptions), both have dramatically different
computational properties in most formal systems. Therefore, they
should not be conflated in Content MathML.
OpenMath comes with a dedicated type system, the "small type system (STS)" [STS]). Since all the core OpenMath symbols (which include counterparts to all MathML symbols and containers) have STS types, this makes it a good candidate for using structured types in content MathML. The simple type system can be used to check arities of functions, and expresses roughly the same information as the content validation grammar in Appendix B of the MathML 2 specification.
The symbols supplied by the STS system can be found in the
sts
OpenMath Content Dictionary; the symbols corresponding to the values
used in the type
attribute discussed in
2 The type attribute can be found in the
mathmltypes Content Dictionary. Using these
Content Dictionaries as targets for the definitionURL
attribute
makes the following three representations equivalent:
<ci type="integer">φ</ci> <semantics> <ci>φ</ci> <annotation-xml encoding="Content-MathML" definitionURL="http://www.openmath.org/standard/sts.pdf"> <csymbol definitionURL="http://www.openmath.org/cd/mathmltypes.html#complex_cartesian_type"/> </annotation-xml> </semantics> <semantics> <ci>φ</ci> <annotation-xml encoding="OpenMath" definitionURL="http://www.openmath.org/standard/sts.pdf"> <OMS xmlns="http://www.openmath.org/OpenMath" cd="mathmltypes" name="complex_cartesian_type"/> </annotation-xml> </semantics>
For example, the definition of csymbol
provides a
signature which takes the form:
The signature of more traditional mathematical functions such as exp
is given as:
A more complicated example is the definition of limit, which has the signature: