The OpenMath Standard

This chapter is a historical account of OpenMath and should be regarded as non-normative.

OpenMath is a standard for representing mathematical objects, allowing them to be exchanged between computer programs, stored in databases, or published on the worldwide web. While the original designers were mainly developers of computer algebra systems, it is now attracting has since attracted interest from other areas of scientific computation and from many publishers of electronic documents with a significant mathematical content. There is a strong relationship to the MathML recommendation [15] from the Worldwide Web Consortium, and a large overlap between the two developer communities. MathML deals principally with the presentation of mathematical objects, while OpenMath is solely concerned with their semantic meaning or content. While MathML does have some limited facilities for dealing with content, it also allows semantic information encoded in OpenMath to be embedded inside a MathML structure. Thus the two technologies may be seen as highly complementary.

Chapter 1
Introduction to OpenMath

This chapter briefly introduces OpenMath concepts and notions that are referred to in the rest of this document.

Chapter 2
OpenMath Objects

In this chapter we provide a self-contained description of OpenMath objects. We first do so by means of an abstract grammar description (Section 2.1) and then give a more informal description (Section 2.2).

2.1 Formal Definition of OpenMath Objects

OpenMath represents mathematical objects as terms or as labelled trees that are called OpenMath objects or OpenMath expressions. The definition of an abstract OpenMath object is then the following.

2.1.1 Basic OpenMath objects

The Basic OpenMath Objects form the leaves of the OpenMath Object tree. A Basic OpenMath Object is of one of the following.

(i) Integer.
Integers in the mathematical sense, with no predefined range. They are "infinite precision" integers (also called "bignums" in computer algebra).
(ii) IEEE floating point number.
Double precision floating-point numbers following the IEEE 754-1985 standard [6].
(iii) Character string.
A Unicode Character string. This also corresponds to `characters' in XML.
(iv) Bytearray.
A sequence of bytes.
(v) Symbol.
A Symbol encodes two fields of information, a name and a Content Dictionary. Each is a sequence of characters matching a regular expression, as described below.
A Symbol encodes three fields of information, a symbol name, a Content Dictionary name, and (optionally) a Content Dictionary base URI, The name of a symbol is a sequence of characters matching the regular expression described in Section 2.3. The Content Dictionary is the location of the definition of the symbol, consisting of a name (a sequence of characters matching the regular expression described in Section 2.3) and, optionally, a unique prefix called a cdbase which is used to disambiguate multiple Content Dictionaries of the same name. There are other properties of the symbol that are not explicit in these fieleds but whose values may be obtained by inspecting the Content Dictionary specified. these include the symbol definition, formal properties and examples and, optionally, a Role which is a restriction on where the symbol may appear in an OpenMath object. The possible roles are described in Section 2.1.4.
(vi) Variable.
A Variable consists of must have a name which is a sequence of characters matching a regular expression, as described in Section 2.3.

2.1.2 Derived OpenMath Objects

Derived OpenMath objects are currently used as a way by which non-OpenMath data is embedded inside an OpenMath object. A derived OpenMath object is built as follows:

(i) If A is not an OpenMath object, then foreignA is an OpenMath foreign object. An OpenMath foreign object may optionally have an encoding field which describes how its contents should be interpreted.

2.1.3 CompoundOpenMath Objects

OpenMath objects are built recursively as follows.

(i) Basic OpenMath objects are OpenMath objects. (Note that derived OpenMath objects are not OpenMath objects, but are used to construct OpenMath objects as described below.)
(ii) If A1, …, An (n>0) are OpenMath objects, then application(A1, …, An) is an OpenMath application object.
(iii) If S1, …, Sn are OpenMath symbols, and A, A1, …, An, (n>0) are OpenMath objects, then A is an OpenMath object, and A1, …, An (n>0) are OpenMath objects or OpenMath derived objects, then attribution (A, S1 A1, … , Sn An) is an OpenMath attribution object.
and A is the object stripped of attributions. S1, …, Sn are referred to as keys and A1, …, An as their associated values. The operation of recursively applying stripping to the stripped object is called flattening of the attribution. When the stripped object after flattening is a variable, the attributed object is called attributed variable. If, after recursively applying stripping to remove attributions, the resulting un-attributed object is a variable, the original attributed object is called an attributed variable.
(iv) If B and C are OpenMath objects, and v1, …, vn (n ≥ 0) are OpenMath variables or attributed variables, then binding (B, v1, …, vn, C) is an OpenMath binding object.
(v) If S is an OpenMath symbol and A1, …, An (n ≥ 0) are OpenMath objects or OpenMath derived objects, then error (S, A1,…,An) is an OpenMath error object.

2.1.4 OpenMath Symbol Roles

We say that an OpenMath symbol is used to construct an OpenMath object if it is the first child of an OpenMath application, binding or error object, or an even-indexed child of an OpenMath attribution object (i.e. the key in a (key, value) pair). The role of an OpenMath symbol is a restriction on how it may be used to construct a compound OpenMath object and, in the case of the key in an attribution object, a clarification of how that attribution should be interpreted. Possible roles are:

binder The symbol may appear as the first child of an OpenMath binding object.
attribution The symbol may be used as key in an OpenMath attribution object, i.e. as the first element of a (key, value) pair, or in an equivalent context (for example to refer to the value of an attribution). This form of attribution may be ignored by an application, so should be used for information which does not change the meaning of the attributed OpenMath object.
semantic-attribution This is the same as attribution except that it modifies the meaning of the attributed OpenMath object and thus cannot be ignored by an application.
error The symbol can appear as the first child of an OpenMath error object.
application The symbol can appear as the first child of an OpenMath application object.
constant The symbol cannot be used to construct an OpenMath compound object.

A symbol cannot have more than one role and cannot be used to construct a compound OpenMath object in a way which requires a different role (using the definition of construct given earlier in this section). This means that one cannot use a symbol which binds some variables to construct, say, an application object. However it does not prevent the use of that symbol as an argument in an application object (where by argument we mean a child with index greater than 1).

If no role is indicated then the symbol can be used anywhere. Note that this is not the same as saying that the symbol's role is constant.

2.2 Further Description of OpenMath Objects

Informally, an OpenMath object can be viewed as a tree and is also referred to as a term. The objects at the leaves of OpenMath trees are called basic objects. The basic objects supported by OpenMath are:

Integer

Arbitrary Precision integers.

Float

OpenMath floats are IEEE 754 Double precision floating-point numbers. Other types of floating point number may be encoded in OpenMath by the use of suitable content dictionaries.

Character strings

are sequences of characters. These characters come from the Unicode standard [10].

Bytearrays

are sequences of bytes. There is no "byte" in OpenMath as an object of its own. However, a single byte can of course be represented by a bytearray of length 1. The difference between strings and bytearrays is the following: a character string is a sequence of bytes with a fixed interpretation (as characters, Unicode texts may require several bytes to code one character), whereas a bytearray is an uninterpreted sequence of bytes with no intrinsic meaning. Bytearrays could be used inside OpenMath errors to provide information to, for example, a debugger; they could also contain intermediate results of calculations, or `handles' into computations or databases.

Symbols

are uniquely defined by the Content Dictionary in which they occur and by a name. In definition in Section 2.1 we have left this information implicit. However, it should be kept in mind that all symbols appearing in an OpenMath object are defined in a Content Dictionary. The form of these definitions is explained in Chapter 4. Each symbol has no more than one definition in a Content Dictionary. Many Content Dictionaries may define differently a symbol with the same name (e.g. the symbol union is defined as associative-commutative set theoretic union in a Content Dictionary set1 but another Content Dictionary, multiset1 might define a symbol union as the union of multi-sets). The name of a symbol can only contain alphanumeric characters and underscores. More precisely, a symbol name matches the following regular expression:

[A-Za-z] [A-Za-z0-9_]*

Notice that these symbol names are case sensitive. OpenMath recommends that symbol names should be no longer than 100 characters.

Variables

are meant to denote parameters, variables or indeterminate (such as bound variables of function definitions, variables in summations and integrals, independent variables of derivatives). Plain variable names are restricted to use a subset of the printable ASCII characters. Formally the names must match the regular expression:

[A-Za-z0-9=+(),-./:?!#$%*;=@[]^_`{|}]+

Derived OpenMath objects are constructed from non-OpenMath data. They differ from bytearrays in that they can have any structure. Currently there is only one way of making a derived OpenMath object.

Foreign: is used to import a non-OpenMath object into an OpenMath attribution. Examples of its use could be to annotate a formula with a visual or aural rendering, an animation etc. They may also appear in OpenMath error objects, for example to allow an application to report an error in processing such an object.

The four following constructs can be used to make compound OpenMath objects out of basic or derived OpenMath objects.

Application

constructs an OpenMath object from a sequence of one or more OpenMath objects. The first argument of an application is referred to as its "head" while the remaining objects are called its "arguments". An OpenMath application object can be used to convey the mathematical notion of application of a function to a set of arguments. For instance, suppose that the OpenMath symbol sin is defined in a suitable Content Dictionary, for trigonometry then application(sin, x ) is the abstract OpenMath object corresponding to sin (x ). More generally, an OpenMath application object can be used as a constructor to convey a mathematical object built from other objects such as a polynomial constructed from a set of monomials. Constructors build inhabitants of some symbolic type, for instance the type of rational numbers or the type of polynomials. The rational number, usually denoted as 1/2, is represented by the OpenMath application object application(Rational, 1, 2). The symbol Rational must be defined, by a Content Dictionary, as a constructor symbol for the rational numbers.

Figure 3.1 The OpenMath application and binding objects for sin (x ) and λ x.x + 2 in tree-like notation.

Binding

objects are constructed from an OpenMath object, and from a sequence of zero or more variables followed by another OpenMath object. The first OpenMath object is the "binder" object. Arguments 2 to n-1 are always variables to be bound in the "body" which is the nth argument object. It is allowed to have no bound variables, but the binder object and the body should be present. Binding can be used to express functions or logical statements. The function λ x.x +2, in which the variable x is bound by λ, corresponds to a binding object having as binder the OpenMath symbol lambda: binding(lambda, x , application(plus, x , 2)).

Phrasebooks are allowed to use α conversion in order to avoid clashes of variable names. Suppose an object Ω contains an occurrence of the object binding (B , v , C ). This object binding (B , v , C ) can be replaced in Ω by binding (B , z , C') where z is a variable not occurring free in C and C' is obtained from C by replacing each free (i.e., not bound by any intermediate binding construct) occurrence of v by z. This operation preserves the semantics of the object Ω. In the above example, a phrasebook is thus allowed to transform the object to, e.g. binding (lambda, v , binding (lambda, z ,application (times,z ,z))). binding(lambda, z , application(plus, z , 2)).

Repeated occurrences of the same variable in a binding operator are allowed. An OpenMath application should treat a binding with multiple occurrences of the same variable as equivalent to the binding in which all but the last occurrence of each variable is replaced by a new variable which does not occur free in the body of the binding. binding (lambda, v , v ,application (times,v ,v) ) is semantically equivalent to: binding (lambda , v' , v ,application (times,v ,v) ) so that the resulting function is actually a constant in its first argument (v' does not occur free in the body application (times,v ,v) )).

Attribution

decorates an object with a sequence of one or more pairs made up of an OpenMath symbol, the "attribute", and an associated OpenMath object, the "value of the attribute". The value of the attribute can be an OpenMath attribution object itself. As an example of this, consider the OpenMath objects representing groups, automorphism groups, and group dimensions. It is then possible to attribute an OpenMath object representing a group by its automorphism group, itself attributed by its dimension.

OpenMath objects can be attributed with OpenMath foreign objects, which are containers for non-OpenMath structures. For example a mathematical expression could be attributed with its spoken or visual rendering.

Composition of attributions, as in attribution(attribution(A, S1 A1,…,Sh Ah), Sh+1 Ah+1, …, Sn An) is semantically equivalent to a single attribution, that is attribution(A, S1 A1, …, Sh Ah, Sh+1 Ah+1, …, Sn An). The operation that produces an object with a single layer of attribution is called flattening.

Multiple attributes with the same name are allowed. While the order of the given attributes does not imply any notion of priority, potentially it could be significant. For instance, consider the case in which Sh = Sn (h < n) in the example above. Then, the object is to be interpreted as if the value An overwrites the value Ah. (OpenMath however does not mandate that an application preserves the attributes or their order.)

Attribution acts as either adornment annotation or as semantical annotation. When the key has role attribution, then replacement of the attributed object by the object itself is not harmful and preserves the semantics. When the key has role semantic-attribution then the attributed object is modified by the attribution and cannot be viewed as semantically equivalent to the stripped object. If the attribute lacks the role specification then attribution is acting as adornment annotation.

Objects can be decorated in a multitude of ways. In [3], typing of OpenMath objects is expressed by using an attribution. An example of the use of an adornment attribution would be to indicate the colour in which an OpenMath object should be displayed, for example attribution(A, colour red ). Note that both A and red are OpenMath objects. An example of the use of a semantic attribution would be to indicate the type of an object. For example the object attribution(A, type t ) represents the judgment stating that object A has type t. Note that both A and t are OpenMath objects.

Attribution can act as either annotation, in the sense of adornment, or as modifier. In the former case, replacement of the adorned object by the object itself is probably not harmful (preserves the semantics). In the latter case however, it may very well be. Therefore, attribution in general should by default be treated as a construct rather than as adornment. Only when the CD definitions of the attributes make it clear that they are adornments, can the attributed object be viewed as semantically equivalent to the stripped object.

Error

is made up of an OpenMath symbol and a sequence of zero or more OpenMath objects. This object has no direct mathematical meaning. Errors occur as the result of some treatment on an OpenMath object and are thus of real interest only when some sort of communication is taking place. Errors may occur inside other objects and also inside other errors. Error objects might consist only of a symbol as in the object: error (S ).

Chapter 3
OpenMath Encodings

In this chapter, two encodings are defined that map between OpenMath objects and byte streams. These byte streams constitute a low level representation that can be easily exchanged between processes (via almost any communication method) or stored and retrieved from files.

The first encoding uses ISO 646:1983 characters [] (also known as ASCII characters) and is an XML application. Although the XML markup of the encoding uses only ASCII characters, OpenMath strings may use arbitrary Unicode/ISO 10646:1988 characters [10]. It can be used, for example, to send OpenMath objects via e-mail, news, cut-and-paste, etc. The texts produced by this encoding can be part of XML documents.

The first encoding is a character-based encoding in XML format. In previous versions of the OpenMath Standard this encoding was a restricted subset of the full legal XML syntax. In this version, however, we have removed all these restrictions so that the earlier encoding is a strict subset of the existing one. The XML encoding can be used, for example, to send OpenMath objects via e-mail, cut-and-paste, etc. and to embed OpenMath objects in XML documents or to have OpenMath objects processed by XML-aware applications.

The second encoding is a binary encoding that is meant to be used when the compactness of the encoding is important (inter-process communications over a network is an example).

Note that these two encodings are sufficiently different for auto-detection to be effective: an application reading the bytes can very easily determine which encoding is used.

3.1 The XML Encoding

This encoding has been designed with two main goals in mind:

to provide an encoding that uses common character sets (so that it can easily be included in most documents and transport protocols) and that is both readable and writable by a human.
to provide an encoding that can be included (embedded) in XML documents or processed by XML-aware applications.

3.1.1 A GrammarSchema for the XML Encoding

The XML encoding of an OpenMath object is defined by the Relax NG schema [8] given below. Relax NG has a number of advantages over the older XSD Schema format [11], in particular it allows for tighter control of attributes and has a modular, extensible structure. Although we have made the XML form, which is given in Appendix B, normative, it is generated from the compact syntax given below. It is also very easy to restrict the schema to allow a limited set of OpenMath symbols as described in Appendix C.

Standard tools exist for generating a DTD or an XSD schema from a Relax NG Schema. Examples of such documents are given in Appendix E and Appendix D respectively.

# RELAX NG Schema for OpenMath 2


default namespace om = "http://www.openmath.org/OpenMath"

start = OMOBJ

# OpenMath object constructor
OMOBJ = element OMOBJ { compound.attributes,
                        attribute version { xsd:float }?,
                        omel }


# Elements which can appear inside an OpenMath object
omel = 
  OMS | OMV | OMI | OMB | OMSTR | OMF | OMA | OMBIND | OME | OMATTR |OMR

# things which can be variables
omvar = OMV | attvar

attvar = element OMATTR { common.attributes,(OMATP , (OMV | attvar))}


cdbase = attribute cdbase { xsd:anyURI}?

# attributes common to all elements
common.attributes = (attribute id { xsd:ID })?

# attributes common to all elements that construct compount OM objects.
compound.attributes = common.attributes,cdbase

# symbol
OMS = element OMS { common.attributes,
                    attribute name { xsd:NCName},
                    attribute cd { xsd:NCName},
                    cdbase }

# variable
OMV = element OMV { common.attributes,
                    attribute name { xsd:NCName} }

# integer
OMI = element OMI { common.attributes,
                    xsd:string {pattern = "\s*(-\s?)?[0-9]+(\s[0-9]+)*\s*"}}
# byte array
OMB = element OMB { common.attributes, xsd:base64Binary }

# string
OMSTR = element OMSTR { common.attributes, text }

# IEEE floating point number
OMF = element OMF { common.attributes,
                    ( attribute dec { xsd:double } |
                      attribute hex { xsd:string {pattern = "[0-9A-F]+"}}) }

# apply constructor
OMA = element OMA { compound.attributes, omel+ }

# binding constructor 
OMBIND = element OMBIND { compound.attributes, omel, OMBVAR, omel }

# variables used in binding constructor
OMBVAR = element OMBVAR { common.attributes, omvar+ }

# error constructor
OME = element OME { common.attributes, OMS, (omel|OMFOREIGN)* }

# attribution constructor and attribute pair constructor
OMATTR = element OMATTR { compound.attributes, OMATP, omel }

OMATP = element OMATP { compound.attributes, (OMS, (omel | OMFOREIGN) )+ }

# foreign constructor
OMFOREIGN =  element OMFOREIGN {
    compound.attributes, attribute encoding {xsd:string}?,
   (omel|notom)* }

# Any elements not in the om namespace
# (valid om is allowed as a descendant)
notom =
  (element * - om:* {attribute * { text }*,(omel|notom)*}
   | text)

# reference constructor
OMR = element OMR { common.attributes,
                    attribute href { xsd:anyURI }
                  }

the XML encoding of an OpenMath object is defined by the dtd given in Figure 4.1 below with the following additional rules not implied by the XML DTD.

Comments are permitted only between elements, not within element character data.
Processing Instructions are only allowed before the OMOBJ element.
The content of an OMB element, is a valid base64-encoded text.
The character data forming element content and attribute values matches the regular expressions of para .

DTD for the OpenMath XML encoding of objects.

<!-- DTD for OM Objects - sb 29.10.98 -->
<!-- sb 3.2.99 -->

<!--
     general list of embeddable elements
      : excludes OMATP as this is only embeddable in OMATTR
      : excludes OMBVAR as this is only embeddable in OMBIND
-->

<!ENTITY % omel "OMS | OMV | OMI | OMB | OMSTR
                                | OMF | OMA | OMBIND | OME
                                | OMATTR | ">


<!-- things which can be variables -->

<!ENTITY % omvar "OMV | OMATTR" >



<!-- symbol -->
<!ELEMENT OMS EMPTY>

  <!ATTLIST OMS 
              name CDATA #REQUIRED
              cd CDATA #REQUIRED >

<!-- variable -->
<!ELEMENT OMV EMPTY>
<!ATTLIST OMV  
              name CDATA #REQUIRED >

<!-- integer -->
<!ELEMENT OMI (#PCDATA) >


<!-- byte array -->
<!ELEMENT OMB (#PCDATA) >


<!-- string -->
<!ELEMENT OMSTR (#PCDATA) >


<!-- floating point -->
<!ELEMENT OMF EMPTY>
<!ATTLIST OMF  
              dec CDATA #IMPLIED
               hex CDATA #IMPLIED>

<!-- apply constructor -->
<!ELEMENT OMA (%omel;)+ >



<!-- binding constructor & bound variables -->
<!ELEMENT OMBIND ((%omel;), OMBVAR, (%omel;)) >


<!ELEMENT OMBVAR (%omvar;)+ >


<!-- error -->
<!ELEMENT OME (OMS, (%omel;)* ) >


<!-- attribution constructor & attribute pair constructor -->
<!ELEMENT OMATTR (OMATP, (%omel;)) >


<!ELEMENT OMATP (OMS, (%omel;))+ >




<!-- OM object constructor -->
<!ELEMENT OMOBJ (%omel;) >
<!ATTLIST OMOBJ 
                xlmns:xlink CDATA #FIXED 'http://www.w3.org/1999/xlink'>

In addition, if the XML document encoding the OpenMath object is linearised into the XML concrete syntax, the following further constraints apply, which ensure that the encoding may be read by OpenMath applications that may not include a full XML parser.

The document should use UTF-8 encoding.
A <!DOCTYPE declaration should not be used.
Character references should not be used. As <!DOCTYPE is not used, the only entity references that are allowed are the five predefined entity references: ' ('), " ("), < (<), > (>), & (&).
The XML empty element form <|#8230;/> should always be used to encode elements such as OMF which are specified in the DTD as being EMPTY. It should never be used for elements that may sometimes be empty, such as OMSTR.

Such a linearisation of an XML encoded OpenMath Object would match the match the character based grammar given in para .

The notation used in this section and in para should be quite straightforward (+ meaning "one or more", ? meaning zero or one, and | meaning "or"). The start symbol of the grammar is "start", "space" stands for the space character, "cr" for the carriage return character, "nl" for the line feed character and "tab" for the horizontal tabulation character.

Grammar for the XML encoding of OpenMath objects.

S → (space | tab | cr | nl)+

integer → (- S?)? [0-9]+ (S [0-9]+)* | (- S?)? x S? [0-9A-F]+ (S [0-9A-F]+)*

cdname → [a-z][a-z0-9_]*

symbname → [A-Za-z][A-Za-z0-9_]*

fpdec → (-?)([0-9]+)?(.[0-9]+)?(e([+-]?)[0-9]+)?

fphex → [0-9ABCDEF]+

varname → ([A-Za-z0-9+=(),-./:?!#$%*;@[]^_`{|}])+

base64 → ([A-Za-z0-9 +/=] | S)+

char → XML Character Data

symbnameatt → name S? = S? (" symbname " | ' symbname ')

cdnameatt → cd S? = S? (" cdname " | ' cdname ')

varnameatt → name S? = S? (" varname " | ' varname ')

fpdecatt → dec S? = S? (" fpdec " | ' fpdec ')

fphexatt → hex S? = S? (" fphex " | ' fphex ')

PI → <? char ?>

comment → <!-- char -->

SC → S+ | (comment S)+

start → (SC | PI)* <OMOBJ S?> S? object S? </OMOBJ S?>

symbol → <OMS [[(S symbnameatt) (S cdnameatt) ]] S? />

variable → <OMV varnameatt S? />

| <OMATTRx S?> SC? omatp SC? variable SC? </OMATTR S?>

omatp → <OMATP S?> SC? attrs SC? </#1 S?>

object → symbol

| variable

| <OMI S > S? integer S? </OMI S?>

| <OMF S fpdecatt S?/>

| <OMF S fphexatt S?/>

| <OMSTR S?> char </OMSTR S?>

| <OMB S?> base64 </OMB S?>

| <OMA S?> SC? object SC? objects SC? </OMA S?>

| <OMBIND S?> SC? object SC?

<OMBVAR S?> SC? variables SC? </OMBVAR S?>

SC? object SC? </OMBIND S?>

| <OME S?> SC? symbol SC? objects SC? </OME S?>

| <OMATTR S?> SC? <OMATP S?> SC? attrs SC? </OMBVAR S?>

SC? object SC? </OMATTR S?>

attrs → symbol S? object

| symbol S? object S? attrs

objects → SC?

| object SC? objects

variables → SC?

| variable SC? variables

Note: This schema specifies names as being of the xsd:NCName type. At the time of writing, W3C Schema types are defined in terms of XML 1 [13]. This limits the characters allowed in a name to a subset of the characters available in Unicode 2.0, which is far more restrictive than the definition for an OpenMath name given in Section 2.3. It is expected that W3C Schema types will be augmented to match the new XML 1.1 recommendation [14], but for portability reasons applications should avoid using the new XML 1.1 name characters unless they are absolutely required. The XML 1.1 specification has a useful appendix giving advice on good strategies to use when naming identifiers.

3.1.2 Informal description of the GrammarXML Encoding

An encoded OpenMath object is placed inside an OMOBJ element. This element can contain the elements (and integers) described above. It can take an optional version (XML) attribute which indicates to which version of the OpenMath standard it conforms. In previous versions of this standard this attribute did not exist, so any OpenMath object without such an attribute must conform to version 1 (or equivalently 1.1) of the OpenMath standard. Objects which conform to the description given in this document should have version="2.0".

We briefly discuss the XML encoding for each type of OpenMath object starting from the basic objects.

Integers

are encoded using the OMI element around the sequence of their digits in base 10 or 16 (most significant digit first). White space may be inserted between the characters of the integer representation, this will be ignored. After ignoring white space, integers written in base 10 match the regular expression -?[0-9]+. Integers written in base 16 match -?x[0-9A-F]+. The integer 10 can be thus encoded as <OMI> 10 </OMI> or as <OMI> xA </OMI> but neither <OMI> +10 </OMI> nor <OMI> +xA </OMI> can be used.

The negative integer -120 can be encoded as either as decimal <OMI> -120 </OMI> or as hexadecimal <OMI> -x78 </OMI>.

Symbols

are encoded using the OMS element. This element has two three (XML) attributes cd, name, and cdbase. The value of cd is the name of the Content Dictionary in which the symbol is defined and the value of name is the name of the symbol. The optional cdbase attribute is a URI that can be used to disambiguate between two content dictionaries with the same name. If a symbol does not have an explicit cdbase attribute, then it inherits its cdbase from the first ancestor in the XML tree with one, should such an element exist. In this document we have tended to omit the cdbase for clarity. The name of the Content Dictionary is compulsory, but a future revision of the OpenMath standard might introduce a defaulting mechanism. For example:

<OMS cd="transc" name="sin"/>

<OMS cdbase="http://www.openmath.org/cd" cd="transc1" name="sin"/>

is the encoding of the symbol named sin in the Content Dictionary named transc1, which is part of the collection maintained by the OpenMath Society.

As described in Section 2.3, the three attributes of the OMS can be used to build a URI reference for the symbol, for use in contexts where URI-based referencing mechanisms are used. For example the URI for the above symbol is http://www.openmath.org/cd/transc1#sin.

Note that the role attribute described in Section 2.1.4 is contained in the Content Dictionary and is not part of the encoding of a symbol, also the cdbase attribute need not be explicit on each OMS as it is inherited from any ancestor element.

Variables

are encoded using the OMV element, with only one (XML) attribute, name, whose value is the variable name. The variable name is a subset of the printable ASCII set of characters. In particular, neither spaces nor double-quote " are allowed in variable names. For instance, the encoding of the object representing the variable x is: <OMV name="x"/>

Floating-point numbers

are encoded using the OMF element that has either the (XML) attribute dec or the (XML) attribute hex. The two (XML) attributes cannot be present simultaneously. The value of dec is the floating-point number expressed in base 10, using the common syntax:

(-?)([0-9]+)?("."[0-9]+)?([eE](-?)[0-9]+)?.

or one of the special values: INF, -INF or NaN.

The value of hex is a base 16 representation of the 64 bits of the IEEE Double. Thus the number represents mantissa, exponent, and sign from lowest to highest bits using a least significant byte ordering. This consists of a string of 16 digits 0-9, A-F.

For example, both <OMF dec="1.0e-10"/> and <OMF hex="3DDB7CDFD9D7BDBB"/> are valid representations of the floating point number 1× 10-10.

The symbols INF, -INF and NaN represent positive and negative infinity, and not a number as defined in [6]. Note that while infinities have a unique representation, it is possible for NaNs to contain extra information about how they were generated and if this informations is to be preserved then the hexadecimal representation must be used. For example <OMF hex="FFF8000000000000"/> and <OMF hex="FFF8000000000001"/> are both hexadecimal representations of NaNs.

Character strings

are encoded using the OMSTR element. Its content is a Unicode text (The default encoding is UTF-8[], although XML encoded OpenMath may be embedded in a containing XML document that specifies alternative encoding in the XML declaration. Note that as always in XML the characters < and & need to be represented by the entity references < and & respectively.

Bytearrays

are encoded using the OMB element. Its content is a sequence of characters that is a base64 encoding of the data. The base64 encoding is defined in RFC 1521 [] 2045 [1]. Basically, it represents an arbitrary sequence of octets using 64 "digits" (A through Z, a through z, 0 through 9, + and /, in order of increasing value). Three octets are represented as four digits (the = character is used for padding at the end of the data). All line breaks and carriage return, space, form feed and horizontal tabulation characters are ignored. The reader is referred to [] [1] for more detailed information.

In detail the encoding of an OpenMath object is described below.

Applications

are encoded using the OMA element. The application whose head is the OpenMath object e0 and whose arguments are the OpenMath objects e1, …, en is encoded as <OMA> C0 C1… Cn </OMA> where Ci is the encoding of ei.

For example, application(sin,x ) is encoded as:

<OMA>  
  <OMS cd="transc1" name="sin"/> 
  <OMV name="x"/>  
</OMA>

provided that the symbol sin is defined to be a function symbol in a Content Dictionary named transc1.

Binding

is encoded using the OMBIND element. The binding by the OpenMath object b of the OpenMath variables x1, x2, …, xn in the object c is encoded as <OMBIND> B <OMBVAR> X1 … Xn </OMBVAR> C </OMBIND> where B, C, and Xi are the encodings of b, c and xi, respectively.

For instance the encoding of binding (lambda, x,application (sin, x)) is:

<OMBIND>
  <OMS cd="fns1" name="lambda"/>  
  <OMBVAR><OMV name="x"/></OMBVAR>  
  <OMA>
    <OMS cd="transc1" name="sin"/> 
    <OMV name="x"/>  
  </OMA>
</OMBIND>

Binders are defined in Content Dictionaries, in particular, the symbol lambda is defined in the Content Dictionary fns1 for functions over functions.

Attributions

are encoded using the OMATTR element. If the OpenMath object e is attributed with (s1, e1), …, (sn, en) pairs (where si are the attributes), it is encoded as <OMATTR> <OMATP> S1 C1 … Sn Cn </OMATP> E </OMATTR> where Si is the encoding of the symbol si, Ci of the object ei and E is the encoding of e.

Examples are the use of attribution to decorate a group by its automorphism group:

<OMATTR>    
  <OMATP>
    <OMS cd="groups" name="automorphism_group" />  
    [..group-encoding..] 
  </OMATP>  
  [..group-encoding..] 
</OMATTR>

or to express the type of a variable:

<OMATTR>    
  <OMATP>
    <OMS cd="ecc" name="type" /> 
    <OMS cd="ecc" name="real" />
  </OMATP> 
  <OMV name="x" />
</OMATTR>

A special use of attributions is to associate non-OpenMath data with an OpenMath object. This is done using the OMFOREIGN element. The children of this element must be well-formed XML. For example the attribution of the OpenMath object sinx with its representation in Presentation MathML is:

<OMATTR>
  <OMATP>
    <OMS cd="annotations1" name="presentation-form"/>  
    <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>

Of course not everything has a natural XML encoding in this way and often the contents of a OMFOREIGN will just be data or some kind of encoded string. For example the attribution of the previous object with its LaTeX representation could be achieved as follows:

<OMATTR>
  <OMATP>
    <OMS cd="annotations1" name="presentation-form"/>  
    <OMFOREIGN encoding="text/x-latex">\sin(x)</OMFOREIGN>  
  </OMATP>
  <OMA>
    <OMS cd="transc1" name="sin"/> 
    <OMV name="x"/>  
  </OMA>
</OMATTR>

For a discussion on the use of the encoding attribute see Section 5.2.

Errors

are encoded using the OME element. The error whose symbol is s and whose arguments are the OpenMath objects or OpenMath derived objects e1, …, en is encoded as <OME> Cs C1… Cn </OME> where Cs is the encoding of s and Ci the encoding of ei.

If an aritherror Content Dictionary contained a DivisionByZero symbol, then the object error(DivisionByZero, application (divide, x, 0)) would be encoded as follows:

<OME>
  <OMS cd="aritherror" name="DivisionByZero"/>  
  <OMA>
    <OMS cd="arith1" name="divide" />
    <OMV name="x"/>  
    <OMI> 0 </OMI>
  </OMA> 
 </OME>

If a mathml Content Dictionary contained an unhandled_csymbol symbol, then an OpenMath to MathML translator might return an error such as:

<OME>
  <OMS cd="mathml" name="unhandled_csymbol"/>  
  <OMFOREIGN encoding="MathML-Content">
    <mathml:csymbol xmlns:mathml="http://www.w3.org/1998/Math/MathML/"
                    definitionURL="http://www.nag.co.uk/Airy#A">
      <mathml:mo>Ai</mathml:mo>
    </mathml:csymbol>
  </OMFOREIGN> 
 </OME>

Note that it is possible to embed fragments of valid OpenMath inside an OMFOREIGN element but that it cannot contain invalid OpenMath. In addition, the arguments to an OMERROR must be well-formed XML. If an application wishes to signal that the OpenMath it has received is invalid or is not well-formed then the offending data must be encoded as a string. For example:

<OME>
  <OMS cd="parser" name="invalid_XML"/>  
  <OMSTR>
    &ltOMA&gt; &lt;OMS name="cos" cd="transc1"&gt;
      &lt;OMV name="v"&gt; &lt;/OMA&gt;
  </OMSTR> 
 </OME>

Note that the `<' and `>' characters have been escaped as is usual in an XML document.

References

OpenMath integers, floating point numbers, character strings, bytearrays, applications, binding, attributions can also be encoded as an empty OMR element with an href attribute whose value is the value of a URI referencing an id attribute of an OpenMath object of that type. The OpenMath element represented by this OMR reference is a copy of the OpenMath element referenced href attribute. Note that this copy is structurally equal, but not identical to the element referenced.

For instance, the OpenMath object application ( f , application ( f , application ( f,a,a ) , application ( f,a,a ) ) , application ( f , application ( f,a,a ) , application ( f,a,a ) ) )

can be encoded in the XML encoding as either one of the XML encodings given in Figure 4.1 (and some intermediate versions as well).

<OMOBJ version="2.0">         <OMOBJ version="2.0">
  <OMA>                         <OMA>
    <OMV name="f"/>               <OMV name="f"/> 
    <OMA>                         <OMA id="t1">
      <OMV name="f"/>               <OMV name="f"/>
      <OMA>                         <OMA id="t11">
        <OMV name="f"/>               <OMV name="f"/>
        <OMV name="a"/>               <OMV name="a"/>
        <OMV name="a"/>               <OMV name="a"/>
      </OMA>                        </OMA>
      <OMA>                         <OMR href="#t11"/>
        <OMV name="f"/>
        <OMV name="a"/> 
        <OMV name="a"/>
      </OMA>                                
    </OMA>                      </OMA>
    <OMA>                       <OMR href="#t1"/>
      <OMV name="f"/>
      <OMA>
        <OMV name="f"/>
        <OMV name="a"/>
        <OMV name="a"/>
      </OMA>
      <OMA>
        <OMV name="f"/>
        <OMV name="a"/>
        <OMV name="a"/>
      </OMA>
    </OMA>
  </OMA>
</OMOBJ>                     </OMOBJ>

Figure 4.1 Shared vs. unshared representations

3.1.3 Some Notes on References

We say that an OpenMath element dominates all its children and all elements they dominate. An OMR element dominates its target, i.e. the element that carries the id attribute pointed to by the xref attribute. For instance in the representation in Figure 4.1, the OMA element with id="t1" and also the second OMR dominate the OMA element with id="t11".

3.1.3.1 An Acyclicity Constraint

The occurrences of the OMR element must obey the following global acyclicity constraint: An OpenMath element may not dominate itself.

Consider for instance the following (illegal) XML representation

<OMOBJ version="2.0">
  <OMA id="foo">
    <OMS cd="arith1" name="divide"/>
    <OMI>1</OMI>
    <OMA>
       <OMS cd="arith1" name="plus"/>
       <OMI>1</OMI>
       <OMR xref="foo"/>
    </OMA> 
  </OMA>
</OMOBJ>

Here, the OMA element with id="foo" dominates its third child, which dominates the OMR element, which dominates its target: the element with id="foo". So by transitivity, this element dominates itself, and by the acyclicity constraint, it is not the XML representation of an OpenMath element. Even though it could be given the interpretation of the continued fraction 1 1 + 1 1 + 1... this would correspond to an infinite tree of applications, which is not admitted by the structure of OpenMath objects described in Chapter 2.

Note that the acyclicity constraints is not restricted to such simple cases, as the example in Figure 4.2 shows.

<OMOBJ version="2.0">                   <OMOBJ version="2.0">
  <OMA id="bar">                         <OMA id="baz">
    <OMS cd="arith1" name="plus"/>         <OMS cd="arith1" name="plus"/>
    <OMI>1</OMI>                           <OMI>1</OMI>
    <OMR xref="baz"/>                      <OMR xref="bar"/>
  </OMA>                                 </OMA>
</OMOBJ>                               </OMOBJ>

Figure 4.2 Sharing between OpenMath objects (A cycle of order 2.

Here, the OMA with id="bar" dominates its third child, the OMR with xref="baz", which dominates its target OMA with id="baz", which in turn dominates its third child, the OMR with xref="bar", this finally dominates its target, the original OMA element with id="bar". So this pair of OpenMath objects violates the acyclicity constraint and is not the XML representation of an OpenMath object.

3.1.3.2 Sharing and Bound Variables

Note that the OMR element is a syntactic referencing mechanism: an OMR element stands for the exact XML element it points to. In particular, referencing does not interact with binding in a semantically intuitive way, since it allows for variable capture. Consider for instance the following XML representation:

<OMBIND id="outer">
  <OMS cd="fns1" name="lambda"/>
  <OMBVAR><OMV name="X"/></OMBVAR>
  <OMA>
    <OMV name="f"/>
    <OMBIND id="inner">
      <OMS cd="fns1" name="lambda"/>
      <OMBVAR><OMV name="X"/></OMBVAR>
      <OMR id="copy" href="#orig"/>
    </OMBIND>
    <OMA id="orig"><OMV name="g"/><OMV name="X"/></OMA>
  </OMA>
</OMBIND>

it represents the OpenMath object binding ( λ , X , application ( f , binding ( λ , X , application ( g , X ) ) , application ( g , X ) ) ) ) which has two sub-terms of the form application ( g , X ) , one with id="orig" (the one explicitly represented) and one with id="copy", represented by the OMR element. In the original, the variable X is bound by the outer OMBIND element, and in the copy, the variable X is bound by the inner OMBIND element. We say that the inner OMBIND has captured the variable X.

It is well-known that variable capture does not conserve semantics. For instance, we could use α-conversion to rename the inner occurrence of X into, say, Y arriving at the (same) object binding ( λ , X , application ( f , binding ( λ , Y , application ( g , Y ) ) , application ( g , X ) ) ) ) Using references that capture variables in this way can easily lead to representation errors, and is not recommended.

3.1.4 Embedding OpenMath in XML Documents

The above encoding of XML encoded OpenMath specifies the grammar to be used in files that encode a single OpenMath object, and specifies the character streams that a conforming OpenMath application should be able to accept or produce.

When embedding XML encoded OpenMath objects into a larger XML document one may wish, or need, to use other XML features. For example use of extra XML attributes to specify XML Namespaces [12] or xml:lang attributes to specify the language used in strings [14]. Also, the encoding used in the larger document may not be UTF-8.

In particular, if OpenMath is used with applications that use the XML Namespace Recommendation [12] then they should ensure that OpenMath elements are in the namespace http://www.openmath.org/OpenMath. This is most conveniently achieved by adding the namespace declaration

xmlns="http://www.openmath.org/OpenMath"

as an attribute to each OMOBJ element in the document.

If such XML features are used then the XML application controlling the document must, if passing the OpenMath fragment to an OpenMath application, remove any such extra attributes and must ensure that the fragment is encoded according to the grammar specified above.

Name	→	NameStartChar (NameChar)*
NameStartChar	→	":" \| [A-Z] \| "_" \| [a-z] \| [#xC0-#xD6] \| [#xD8-#xF6] \|
		[#xF8-#x2FF] \| [#x370-#x37D] \| [#x37F-#x1FFF] \|
		[#x200C-#x200D] \| [#x2070-#x218F] \| [#x2C00-#x2FEF] \|
		[#x3001-#xD7FF] \| [#xF900-#xFDCF] \| [#xFDF0-#xFFFD] \|
		[#x10000-#xEFFFF]
NameChar	→	NameStartChar \| "-" \| "." \| [0-9] \| #xB7 \| [#x0300-#x036F] \|
		[#x203F-#x2040]

start	→	[24] object [25]	\|	[24+64] [m] [n] object [25]
object	→	integer
	\|	float
	\|	variable
	\|	symbol
	\|	cdbase
	\|	string
	\|	bytearray
	\|	foreign
	\|	construct
	\|	internal_reference
	\|	external_reference
integer	→	[1] [_]	\|	[1+64] [n] id:n [_]
	\|	[1+32] [_]
	\|	[1+128] {_}	\|	[1+64+128] {n} id:n {_}
	\|	[1+32+128] {_}
	\|	[2] [n] [_] digits:n	\|	[2+64] [n] [m] [_] digits:n id:m
	\|	[2+32] [n] [_] digits:n
	\|	[2+128] {n} [_] digits:n	\|	[2+64+128] {n} {n} [_] digits:n id:n
	\|	[2+32+128] {n} [_] digits:n
float	→	[3] {_}{_}	\|	[3+64] [n] id:n {_}{_}
variable	→	[5] [n] varname:n	\|	[5+64] [n] [m] varname:n id:m
	\|	[5+128] {n} varname:n	\|	[5+64+128] {n} {m} varname:n id:m
symbol	→	[8] [n] [m] cdname:n symbname:m	\|	[8+64] [n] [m] [k] cdname:n symbname:m id:k
	\|	[8+128] {n} {m} cdname:n symbname:m	\|	[8+64+128] {n} {m} {k} cdname:n symbname:

3.1.3.1 An Acyclicity Constraint

3.1.3.2 Sharing and Bound Variables

The OpenMath Standard

Abstract

Change-marked edition notes

Contents

List of Figures

Chapter
OpenMath Movement

.1 History

.2 OpenMath Society

Chapter 1
Introduction to OpenMath

1.1 OpenMath Architecture

1.2 OpenMath Objects and Encodings

1.3 Content Dictionaries

1.4 Additional Files

1.5 Phrasebooks

Chapter 2
OpenMath Objects

2.1 Formal Definition of OpenMath Objects

2.1.1 Basic OpenMath objects

2.1.2 Derived OpenMath Objects

2.1.3 CompoundOpenMath Objects

2.1.4 OpenMath Symbol Roles

2.2 Further Description of OpenMath Objects

2.3 Names

2.4 Summary

Chapter 3
OpenMath Encodings

3.1 The XML Encoding

3.1.1 A GrammarSchema for the XML Encoding

3.1.2 Informal description of the GrammarXML Encoding

3.1.3 Some Notes on References

3.1.4 Embedding OpenMath in XML Documents

3.2 The Binary Encoding

3.2.1 A Grammar for the Binary Encoding

Name	→	(PosixLetter \| '_') (Char)*
Char	→	PosixLetter \| Digit \| '.' \| '-' \| '_'
PosixLetter	→	'a' \| 'b' \| ... \| 'z' \| 'A' \| 'B' \| ... \| 'Z'

S	→	(space \| tab \| cr \| nl)+
integer	→	(`-` S?)? [0-9]+ (S [0-9]+)* \| (`-` S?)? `x` S? [0-9A-F]+ (S [0-9A-F]+)*
cdname	→	[a-z][a-z0-9`_`]*
symbname	→	[A-Za-z][A-Za-z0-9`_`]*
fpdec	→	(`-`?)([0-9]+)?(`.`[0-9]+)?(`e`([+-]?)[0-9]+)?
fphex	→	[0-9ABCDEF]+
varname	→	([A-Za-z0-9+=(),-./:?!#$%*;@[]^_`{\|}])+
base64	→	([A-Za-z0-9 +/=] \| S)+
char	→	XML Character Data

symbnameatt	→	`name` S? = S? (`"` symbname `"` `\|` `'` symbname `'`)
cdnameatt	→	`cd` S? = S? (`"` cdname `"` `\|` `'` cdname `'`)
varnameatt	→	`name` S? = S? (`"` varname `"` `\|` `'` varname `'`)
fpdecatt	→	`dec` S? = S? (`"` fpdec `"` `\|` `'` fpdec `'`)
fphexatt	→	`hex` S? = S? (`"` fphex `"` `\|` `'` fphex `'`)
PI	→	<`?` char `?>`
comment	→	<`!--` char `-->`
SC	→	S+ `\|` (comment S)+
start	→	(SC `\|` PI)* `<OMOBJ` S?`>` S? object S? `</OMOBJ` S?`>`
symbol	→	`<OMS` [[(S symbnameatt) (S cdnameatt) ]] S? `/>`
variable	→	`<OMV` varnameatt S? `/>`
	\|	`<OMATTRx` S?`>` SC? omatp SC? variable SC? `</OMATTR` S?`>`
omatp	→	`<OMATP` S?`>` SC? attrs SC? `</#1` S?`>`
object	→	symbol
	\|	variable
	\|	`<OMI` S `>` S? integer S? `</OMI` S?`>`
	\|	`<OMF` S fpdecatt S?`/>`
	\|	`<OMF` S fphexatt S?`/>`
	\|	`<OMSTR` S?`>` char `</OMSTR` S?`>`
	\|	`<OMB` S?`>` base64 `</OMB` S?`>`
	\|	`<OMA` S?`>` SC? object SC? objects SC? `</OMA` S?`>`
	\|	`<OMBIND` S?`>` SC? object SC?
		`<OMBVAR` S?`>` SC? variables SC? `</OMBVAR` S?`>`
		SC? object SC? `</OMBIND` S?`>`
	\|	`<OME` S?`>` SC? symbol SC? objects SC? `</OME` S?`>`
	\|	`<OMATTR` S?`>` SC? `<OMATP` S?`>` SC? attrs SC? `</OMBVAR` S?`>`
		SC? object SC? `</OMATTR` S?`>`
attrs	→	symbol S? object
	\|	symbol S? object S? attrs
objects	→	SC?
	\|	object SC? objects
variables	→	SC?
	\|	variable SC? variables

The OpenMath Standard

Abstract

Change-marked edition notes

Contents

List of Figures

Chapter OpenMath Movement

.1 History

.2 OpenMath Society

Chapter 1Introduction to OpenMath

1.1 OpenMath Architecture

1.2 OpenMath Objects and Encodings

1.3 Content Dictionaries

1.4 Additional Files

1.5 Phrasebooks

Chapter 2OpenMath Objects

2.1 Formal Definition of OpenMath Objects

2.1.1 Basic OpenMath objects

2.1.2 Derived OpenMath Objects

2.1.3 CompoundOpenMath Objects

2.1.4 OpenMath Symbol Roles

2.2 Further Description of OpenMath Objects

2.3 Names

2.4 Summary

Chapter 3OpenMath Encodings

3.1 The XML Encoding

3.1.1 A GrammarSchema for the XML Encoding

3.1.2 Informal description of the GrammarXML Encoding

3.1.3 Some Notes on References

3.1.3.1 An Acyclicity Constraint

3.1.3.2 Sharing and Bound Variables

3.1.4 Embedding OpenMath in XML Documents

3.2 The Binary Encoding

3.2.1 A Grammar for the Binary Encoding

Chapter
OpenMath Movement

Chapter 1
Introduction to OpenMath

Chapter 2
OpenMath Objects

Chapter 3
OpenMath Encodings