OpenMath 2 Table of Contents

Previous: 4 Content Dictionaries
This: 5 OpenMath Compliance
    5.1 Encodings
        5.1.1 The XML Encoding
            5.1.1.1 Generating Valid XML
            5.1.1.2 Decimal versus Hexadecimal Float Representation
    5.2 OpenMath Foreign Objects
    5.3 Content Dictionaries
    5.4 Lexical Errors
    5.5 OpenMath 1 Objects
Next: A CD Files

Chapter 5
OpenMath Compliance

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.

5.1 Encodings

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.

5.1.1 The XML Encoding

5.1.1.1 Generating Valid XML

All OpenMath objects generated by a compliant OpenMath application must validate against the Relax NG Schema given in Appendix B.

5.1.1.2 Decimal versus Hexadecimal Float Representation

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.

5.2 OpenMath Foreign Objects

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>
Where the contents of the Foreign Object is a format other than XML, it is recommended that its MIME type [2] is used as the value of the encoding. For example (again using the XML encoding):
<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>
is equivalent to the OpenMath expression:
<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>
Since in MathML the 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.

5.3 Content Dictionaries

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. s, that is not defined in a supported Content Dictionary, a compliant application will act as if it had received the OpenMath object error(unhandled_symbol,s) where unhandled_symbol is the symbol from the error Content Dictionary.

Similarly if it receives a symbol, e.g. s, from an unsupported Content Dictionary, it will act as if it had received the OpenMath object error(unsupported_cd,s)

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 error(unexpected_symbol,s)

5.4 Lexical Errors

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.

5.5 OpenMath 1 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.

OpenMath 2 Table of Contents

Previous: 4 Content Dictionaries
This: 5 OpenMath Compliance
Next: A CD Files