Applications that meet the requirements specified in this chapter may label themselves as OpenMath compliant. OpenMath compliance is defined so as to maximize the potential for interoperability amongst OpenMath applications.
This standard defines two reference encodings for OpenMath, the binary encoding and XML encoding, defined in Chapter 3.
As a minimum, an OpenMath compliant application, which accepts or generates OpenMath objects, must be capable of doing so using the XML encoding. The ability to use other encodings is optional.
All OpenMath objects generated by a compliant OpenMath application must validate against the Relax NG Schema given in Appendix B.
In the XML encoding, floating-point numbers may be defined using either decimal or hexadecimal notation. For numerical values, plus the two infinities, the two representations may be used interchangeably since there is a one-to-one correspondence between them. The exceptional case is that of not a number (NaN) which is defined in the IEEE standard [6] to be any number whose exponent has the maximum possible value (in this case the exponent is 11 bits so the maximum value is 2047) and whose mantissa is non-zero. The standard explicitly notes the use of the 52 bits in the mantissa (and also the sign bit) to store information about how the NaN was generated in a system-specific way. Thus in some cases the exact representation of the NaN is significant.
The semantics of the OpenMath object
<OMF dec="NaN"/> is that it represents
any NaN, and a phrasebook may substitute any
specific NaN value when processing it. The semantics of a NaN in
hexadecimal notation however, such as
<OMF hex="FFF8000000000001"/>,
is that this is a specific NaN, as distinct from all others.
If a phrasebook author substitutes
another value for the NaN or maps all NaNs to a single object then he or
she must recognise that this process is not an identity transformation.
An OpenMath Foreign Object may be attributed with a string indicating the format of its contents. Although this information is optional, an OpenMath-compliant application which generates OpenMath Foreign Objects should always include it where possible (see the discussion of MathML conversion below for an example of a situation where it is not always possible). It is recommended that, where the contents of the Foreign Object are in an XML dialect, the namespace [14] of the XML dialect is used as the value of the encoding. For example (using the XML encoding):
<OMATTR>
<OMATP>
<OMS cd="annotations1" name="description"/>
<OMFOREIGN encoding="http://www.w3.org/1999/xhtml">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>E</title></head>
<body>
<p>
The base of the natural logarithms, approximately 2.71828.
</p>
</body>
</html>
</OMFOREIGN>
</OMATP>
<OMS cd="nums1" name="e"/>
</OMATTR><OMATTR>
<OMATP>
<OMS cd="annotations1" name="description"/>
<OMFOREIGN encoding="text/latex">
\documentclass{article}
\begin{document}
\title{E}
\maketitle
The base of the natural logarithms, approximately 2.71828.
\end{document}
</OMFOREIGN>
</OMATP>
<OMS cd="nums1" name="e"/>
</OMATTR> An exception to the above guidelines occurs when a MathML object
is converted to OpenMath. MathML also has an
encoding attribute which can appear in various
places and whose format is a string. Only two values are predefined,
MathML-Content and
MathML-Presentation, and these may appear in
the resulting OpenMath object despite the fact that they are not namespaces
as recommended above. For example the following MathML expression:
<semantics xmlns="xmlns="http://www.w3.org/1998/Math/MathML">
<apply>
<sin/>
<ci>x</ci>
</apply>
<annotation encoding="MathML-Presentation">
<math>
<mi>sin</mi><mfenced><mi>x</mi></mfenced>
</math>
</annotation>
</semantics><OMATTR>
<OMATP>
<OMS cd="altenc" name="MathML_encoding"/>
<OMFOREIGN encoding="MathML-Presentation">
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mi>sin</mi><mfenced><mi>x</mi></mfenced>
</math>
</OMFOREIGN>
</OMATP>
<OMA>
<OMS cd="transc1" name="sin"/>
<OMV name="x"/>
</OMA>
</OMATTR>encoding attribute is in
effect optional (its default value is the empty string), a convertor
program may not in fact be able to provide a value for the OpenMath
encoding attribute. This is unfortunate but
unavoidable.
An OpenMath compliant application must be able to support the error Content Dictionary defined in Appendix A.5.
A compliant application must declare the names and version numbers of
the Content Dictionaries that it supports. Equivalently it may declare
the Content Dictionary Group (or groups) and major version number (not
revision number), rather than listing individual Content Dictionaries.
Applications that support all Content Dictionaries (e.g. renderers)
should refer to the implicit CD Group all.
If a compliant application supports a Content Dictionary then it must explicitly declare any symbols in the Content Dictionaries that are not supported. Phrasebooks are encouraged to support every symbol in the Content Dictionaries.
Symbols which are not listed as unsupported are supported by the application. The meaning of supported will depend on the application domain. For example an OpenMath renderer should provide a default display for any OpenMath object that only references supported symbols, whereas a Computer Algebra System will be expected to map such an object to a suitable internal representation, in this system, of this mathematical object. It is expected that the application's phrasebooks for supported Content Dictionaries will be constructed such that properties of the symbol expressed in the Content Dictionary are respected as far as possible for the given application domain. However OpenMath compliance does not imply any guarantee by the OpenMath Society on the accuracy of these representations.
Content Dictionaries available from the official OpenMath repository
at www.openmath.org need only be referenced by name, other Content
Dictionaries should be referenced using the
CDBase and the
CDName.
When receiving an OpenMath symbol, e.g. unhandled_symbol is the symbol from the
error Content Dictionary.
Similarly if it receives a symbol, e.g.
Finally if the compliant application receives a symbol from a
supported Content Dictionary but with an unknown name, then this must
either be an incorrect object, or possibly the object has been built
using a later version of the Content Dictionary. In either case, the
application will act as if it had received the OpenMath object
The previous section defines the behaviour of a compliant application upon receiving well formed OpenMath objects containing unexpected symbols. This standard does not specify any behaviour for an application upon receiving ill-formed objects.
Compliant OpenMath 2 documents and Content Dictionary files using the
reference XML encodings must be valid
according to the specified schema, and so will use the namespaces
http://www.openmath.org/OpenMath
and
http://www.openmath.org/OpenMathCD
respectively. Similarly CD Group and Signature files will use
http://www.openmath.org/OpenMathCDG
and
http://www.openmath.org/OpenMathCDS.
Applications may also support OpenMath 1.
XML-encoded OpenMath 1 documents may be in either the
http://www.openmath.org/OpenMath
namespace or in no-namespace (i.e., do not have any xmlns
declarations).
An application may accept either of
these forms. Note however that OpenMath documents that have a version attribute
should validate against the schema for OpenMath 2 (or later versions) and
so should always use the OpenMath namespace.
XML-encoded OpenMath 1 CD files, CD Group files and CD Signature
files must be in no-namespace. An OpenMath 2 application may support
these files by implicitly converting the documents to their respective
namespace. Apart from this change of namespace (and the addition of a
version attribute on OMOBJ) the OpenMath 1
documents should conform to the schema specified in this standard.
The use of documents in no-namespace should be restricted to reading existing OpenMath 1 files. No OpenMath 2 application should generate documents in this form.