The OpenMath Standard

3.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 [8].

• (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 three fields of information, a name, a Content Dictionary, and (optionally) a role. The name of a symbol is a sequence of characters matching the regular expression described in Section 3.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 3.3) and, optionally, a unique prefix called a cdbase which is used to disambiguate multiple Content Dictionaries of the same name. The role is a restriction on where the symbol may appear in an OpenMath object. The possible roles are described in Section 3.1.4.

• (vi) Variable.

  A Variable must have a name which is a sequence of characters matching a regular expression, as described in Section 3.3. Where the variable is a member of an enumerated set it also has a child which is an OpenMath object representing its indices.

3.1.2 Derived OpenMath Objects

A derivedOpenMath object is built as follows:

• (i) If A  is not an OpenMath object, then foreignA  is an OpenMath foreign object.

3.1.3 Compound OpenMath Objects

OpenMath objects are built recursively as follows.

• (i) Basic OpenMath objects are OpenMath objects. Derived OpenMath objects are not OpenMath objects.

• (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  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. 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.

• (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, then error (S, A1,…,An) is an OpenMath error object.

3.1.4 OpenMath Symbol Rôles

The rôle of an OpenMath symbol is a restriction on where it can appear in an OpenMath object. A symbol cannot have more than one role. If no role is indicated then the symbol can be used anywhere. Possible roles are:

1. binder The symbol may only appear as the first child of an OpenMath binding object.

2. attribution The symbol may only 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.

3. 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.

4. error The symbol can only appear as the first child of an OpenMath error object.

5. default The symbol can appear anywhere not defined in the previous four cases.

4.1.1 A Schema for the xml Encoding

The xml encoding of an OpenMath object is defined by the Relax NG schema [11] given below. Relax NG has a number of advantages over the older XSD Schema format [15], 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"
namespace xlink = "http://www.w3.org/1999/xlink"

# OM2: allow OMR
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))}

#OM2: common attributes
cdbase = attribute cdbase { xsd:anyURI}?
common.attributes = (attribute id { xsd:ID })?
compound.attributes = common.attributes,cdbase

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

# variable
OMV = element OMV { common.attributes, attlist.OMV,omel?}
attlist.OMV = 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 }

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

# apply constructor
OMA = element OMA { compound.attributes, omel+ }
# binding constructor and variable
OMBIND = element OMBIND { compound.attributes, omel, OMBVAR, omel }
OMBVAR = element OMBVAR { common.attributes, omvar+ }

# error
OME = element OME { common.attributes, OMS, omel* }

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

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

# OM2: OMFOREIGN 
OMFOREIGN =  element OMFOREIGN { compound.attributes, (omel|notom)* }

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

# OM object constructor
OMOBJ = element OMOBJ { compound.attributes, omel }
 attlist.OMOBJ = attribute version { "1.0" | "1.2" | "2.0" }


# OM2: OMR
OMR = element OMR { common.attributes, attlist.OMR }
attlist.OMR = 
        attribute xlink:href { text },
        attribute xlink:type {"simple"},
        attribute xlink:show {"embed"}

start = OMOBJ

4.1.2 Informal description of the xml 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. This would allow an older OpenMath application which, for example, could not parse the full xml syntax, to accept objects with version "1" or "1.1" but reject objects with version "2".

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 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. The cdbase attribute may be used on any ancester element of the current OMS, any OMS elements without an explict cdbase attribute which is a descendent of such an element is taken to encode an OpenMath symbol with this CD base. For example:

<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.

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. This canonical URI reference is constructed as follows:

URI = cdbase-value + '/' + cd-value + '#' + name-value

For example

<OMS name="plus" cd="arith1" cdbase="http://www.openmath.org/cd"/>

gives the URI "http://www.openmath.org/cd/arith1#plus" This would allow us to refer uniquely to an openmath symbol from a MathML document [18].

<mathml:csymbol xmlns:mathml="http://www.w3.org/1998/Math/MathML/"
                definitionURL="http://www.openmath.org/cd/arith1#plus">
  Z
</csymbol>
  

Note that the role attribute described in Section 3.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 explict 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. For instance, the encoding of the object representing the variable x  is: <OMV name="x"/>

For an enumerated variable the index or indices of the variable are encoded as a child. So for example the encoding of the object representing the variable xi+1  is:

<OMV name="x">  
  <OMA>
    <OMS cdbase="http://www.openmath.org/cd" cd="arith1" name="plus"/> 
    <OMV name="i"/>  
    <OMI>1</OMI>
  </OMA>
</OMV>

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]+)?(e(-?)[0-9]+)?.

The value of hex is the digits of the floating-point number expressed in base 16, with digits 0-9, A-F (mantissa, exponent, and sign from lowest to highest bits) using a least significant byte ordering. For example, <OMF dec="1.0e-10"/> is a valid floating-point number.

Character strings

are encoded using the OMSTR element. Its content is a Unicode text . 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 [2]. 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 for padding to the right at the end of the data). All line breaks and carriage return, space, form feed and horizontal tabulation characters are ignored. The reader is refered to [2] 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 cdbase="http://www.openmath.org/cd" 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 cdbase="http://www.openmath.org/cd" cd="fns1" name="lambda"/>  
  <OMBVAR><OMV name="x"/></OMBVAR>  
  <OMA>
    <OMS cdbase="http://www.openmath.org/cd" 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="presentation1" name="mathml"/>  
    <OMFOREIGN>
      <math xmlns="http://www.w3.org/1998/Math/MathML">
        <mi>sin</mi><mfenced><mi>x</mi></mfenced>
      </math>
    </OMFOREIGN>  
  </OMATP>
  <OMA>
   <OMS cdbase="http://www.openmath.org/cd" 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="presentation1" name="latex"/>  
    <OMFOREIGN>sin\,(x)</OMFOREIGN>  
  </OMATP>
  <OMA>
    <OMS cdbase="http://www.openmath.org/cd" cd="transc1" name="sin"/> 
    <OMV name="x"/>  
  </OMA>
</OMATTR>

Errors

are encoded using the OME element. The error whose symbol is s  and whose arguments are the OpenMath 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>

References

OpenMath integers, floating point numbers, character strings, byearrays, applications, binding, attributions can also be encoded as an empty OMR element with an xlink:href attribute whose value is the value of an id attribute of an OpenMath object of that type. The OpenMath element represented by this OMR element is a copy of the OpenMath element pointed to in the xlink:xref attribute. Note that the representation of the OMR element is structurally equal, but not identical to the element it points to.

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 below (and some intermedidate versions as well).

<OMOBJ>                      <OMOBJ>
  <OMA>                         <OMA xmlns:xlink="http://www.w3.org/1999/xlink">
    <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 xlink:href="t11"/>
        <OMV name="f"/>
        <OMV name="a"/> 
        <OMV name="a"/>
      </OMA>                                
    </OMA>                      </OMA>
    <OMA>                       <OMR xlink: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

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 Figure 4.1, the OMA element with id="t1" and also the second OMR dominate the OMA element with id="t11".

<OMOBJ>
  <OMA id="foo">
    <OMS cdbase="http://www.openmath.org/cd" cd="arith1" name="divide"/>
    <OMI>1</OMI>
    <OMA>
       <OMS cdbase="http://www.openmath.org/cd" cd="arith1" name="plus"/>
       <OMI>1</OMI>
       <OMR xref="foo"/>
    </OMA> 
  </OMA>
</OMOBJ>

<OMOBJ>                                <OMOBJ>
  <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>

<OMBIND id="outer">
  <OMS cdbase="http://www.openmath.org/cd" cd="fns1" name="lambda"/>
  <OMBVAR><OMV name="X"/></OMBVAR>
  <OMA>
    <OMV name="f"/>
    <OMBIND id="inner">
      <OMS cdbase="http://www.openmath.org/cd" cd="fns1" name="lambda"/>
      <OMBVAR><OMV name="X"/></OMBVAR>
      <OMR id="copy" xlink:href="orig"/>
    </OMBIND>
    <OMA id="orig"><OMV name="g"/><OMV name="X"/></OMA>
  </OMA>
</OMBIND>

4.1.3 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 [16] or xml:lang attributes to specify the language used in strings [17].

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.

4.2.1 A Grammar for the Binary Encoding

Figure Figure 4.2 gives a grammar for the binary encoding ("start" is the start symbol)..

The following conventions are used in this section: [n] denotes a byte whose value is the integer n  (n  can range from 0 to 255), {m} denotes four bytes representing the (unsigned) integer m  in network byte order, [_] denotes an arbitrary byte, {_} denotes an arbitrary sequence of four bytes.

xxxx:n, where xxxx is one of symbname, cdname, varname, uri, id, digits, or bytes denotes a sequence of n  bytes that conforms to the constraints on xxxx strings. For instance, for symbname, varname, or cdnamethis is the regular expression described in Section 3.3, for uri it is the grammar for URIs in [9].

4.2.2 Description of the Grammar

An OpenMath object is encoded as a sequence of bytes starting with the begin object tag ( values 24 and 88) and ending with the end object tag (value 25). These are similar to the <OMOBJ> and </OMOBJ> tags of the xml encoding.

The encoding of each kind of OpenMath object begins with a tag that is a single byte, holding a token identifier that describes the kind of object and two flags, the long flag and the shared flag. The identifier is stored in the first 6 bits (1 to 6). The long flag is the eighth bit and the shared flag is the seventh bit. If the long flag is set, this signifies that the names, strings, and data fields in the encoded OpenMath object are longer than 255 byte or characters. The sharing flag indicates that the encoded object is shared in another (part of an) object somewhere else (see Section 4.2.3). Note that if the sharing flag is set (in the right column of the grammar in Figure Figure 4.2, then the encoding includes a representation of the identifier.

To facilitate the stremaing OpenMath objects, some basic objects (integers, strings, bytearrays, and foreign objects) have variant token identifiers with the fifth bit set. The idea behind this is that these basic objects can be split into packets. If the fifth bit is not set, this packet is the final packet of the basic object. If the bit is set, then more packets of the basic object will follow directly after this one. Note that all packets making up a basic object must have the same token identifier (up to the fifth bit).

Here is a description of the binary encodings of every kind of OpenMath object:

Integers

are encoded depending on how large they are. There are four possible formats. Integers between -128 and 127 are encoded as the small integer tags (token identifier 1) followed by a single byte that is the value of the integer (interpreted as a signed character). For example 16 is encoded as 0x01 0x10. Integers between -2 31   (-2147483648) and 2 31 - 1   (2147483647) are encoded as the small integer tag with the long flag set followed by the integer encoded in little endian format on four bytes (network byte order: the most significant byte comes first). For example, 128 is encoded as 0x81 0x00000080. The most general encoding begins with the big integer tag (token identifier 2) with the long flag set if the number of bytes in the encoding of the digits is greater or equal than 256. It is followed by the length (in bytes) of the sequence of digits, encoded on one byte (0 to 255, if the long flag was not set) or four bytes (network byte order, if the long flag was set). It is then followed by a byte describing the sign and the base. This 'sign/base' byte is + (0x2B) or - (0x2D) for the sign ored with the base mask bits that can be 0 for base 10 or 0x40 for base 16. It is followed by the strings of digits (as characters) in their natural order (as in the xml encoding). For example, 8589934592 (233) is encoded 0x02 0x0A 0x2B 0x38353839393334353932 and xfffffff1 is encoded as 0x02 0x08 0x6b 0x6666666666666631. Note that it is permitted to encode a "small" integer in any "bigger" format.

To splice sequences of integer packets into integers, we have to consider three cases: In the case of token identifiers 1, 33, and 65 the sequence of packets is treated as a sequence of integer digits to the base of 27  (most significant first). The case of token identifiers 129, 161, and 193 is analogous with digits of base 231. In the case of token identifiers 2, 34, 66, 130, 162, and 194 the integer is assembled by concatenating the string of decimal digits in the packets in sequence order (which corresponds to most significant first). Note that in all cases only the sequence-initial packet may contain a signed integer. The sign of this packet determines the sign of the overall integer.

Symbols

are encoded as the symbol tags (token identifier 8) with the long flag set if the maximum of the length in bytes in the UTF-8 encoding of the Content Dictionary name, the symbol name or the CD base is greater than or equal to 256 . The symbol tags [8] and [8+128] are deprecated in OpenMath2 since symbols now have an optional cdbase field, but are kept for backwards compatibility. The symbol tag is followed by the length in bytes in the UTF-8 encoding of the Content Dictionary name, the symbol name, and the CD base as a byte (if the long flag was not set) or a four byte integers (in network byte order). These are followed by the bytes of the UTF-8 encoding of the Content Dictionary name, the symbol name, and the CD base.

Variables

are encoded using the variable tags (token identifiers 5) with the long flag set if the number of bytes in the UTF-8 encoding of the variable name is greater than or equal to 256 (this should never happen if the rules on variables are followed). Then, there is the number of characters as a byte (if the long flag was not set) or a four byte integer (in network byte order), followed by the characters of the name of the variable. For example, the variable x is encoded as 0x05 0x01 0x78.

Indexed Variables

are encoded using the indexed variable tags (token identifiers 10 and 11) as begin and end tags. The long flag set on the begin tag if the number of bytes (characters) in the variable name is greater than or equal to 256. The start tag is followed by the number of bytes as a byte (if the long flag was not set) or a four byte integer (in network byte order), followed by the bytes of the UTF-8 encoding of the name of the variable. This is followed by the encoding of an OpenMath object and the end tag [11].

Floating-point number

are encoded using the floating-point number tags (token identifier 3) followed by eight bytes that are the IEEE 754 representation [8], most significant bytes first. For example, 0.1 is encoded as 0x03 0x000000000000f03f.

Character string

are encoded in two ways depending on whether , the string is encoded in utf-16 or iso-859-1 (latin-1). In the case of latin-1 it is encoded as the one byte character string tags (token identifier 6) with the long flag set if the number of bytes (characters) in the string is greater than or equal to 256. Then, there is the number of characters as a byte (if the length flag was not set) or a four byte integer (in network byte order), followed by the characters in the string. If the string is encoded in utf-16, it is encoded as the two byte character string tags (token identifier 7) with the long flag set if the number of characters in the string is greater or equal to 256. Then, there is the number of utf-16 units, which will be the number of characters unless characters in the higher planes of Unicode are used, as a byte (if the long flag was not set) or a four byte integer (in network byte order), followed by the characters (utf-16 encoded Unicode).

Sequences of string packets are assembled into strings by concatenating the strings in the packets in sequence order.

Bytearrays

are encoded using the bytearray tags (token identifier 4) with the long flag set if the number elements is greater than or equal to 256. Then, there is the number of elements, as a byte (if the long flag was not set) or a four byte integer (in network byte order), followed by the elements of the arrays in their normal order.

Sequences of bytearray packets are assembled into byte arrays by concatenating the bytearrays in the packets in sequence order.

Foreign Objects

are encoded using the foreign object tags (token identifier 12) with the long flag set if the number of bytes is greater than or equal to 256. Then, there is the number of elements, as a byte (if the long flag was not set) or a four byte integer (in network byte order), followed by the elements of the arrays in their normal order.

Sequences of foreign object packets are assembled into foreign objects by concatenating the bytes in the packets in sequence order.

Applications

are encoded using the application tags (token identifiers 16 and 17). More precisely, the application of E0  to E1… En  is encoded using the application tags (token identifier 16), the sequence of the encodings of E0  to En  and the end application tags (token identifier 17).

Bindings

are encoded using the binding tags (token identifiers 26 and 27). More precisely, the binding by B  of variables V1… Vn  in C  is encoded as the binding tags (token identifier 26), followed by the encoding of B, followed by the binding variables tags (token identifier 28), followed by the encodings of the variables V1  … Vn, followed by the end binding variables tags (token identifier 29), followed by the encoding of C, followed by the end binding tags (token identifier 27).

Attribution

are encoded using the attribution tags (token identifiers 18 and 19). More precisely, attribution of the object E  with (S1, E1), …  (Sn, En) pairs (where Si  are the attributes) is encoded as the attributed object tags (token identifier 18), followed by the encoding of the attribute pairs as the attribute pairs tags (token identifier 20), followed by the encoding of each symbol and value, followed by the end attribute pairs tags (token identifier 21), followed by the encoding of E, followed by the end attributed object tags (token identifier 19).

Error

are encoded using the error tags (token identifiers 22 and 23). More precisely, S0  applied to E1… En  is encoded as the error tags (token identifier 22), the encoding of S0, the sequence of the encodings of E0  to En  and the end error tags (token identifier 23).

Internal References

are encoded using the internal reference tags [30] and [30+128] (the sharing flag cannot be set on this tag, since chains of references are not allowed in the OpenMath binary encoding.) with long flag set if the number of OpenMath sub-objects in the encoded OpenMath is greater than or equal to 256. Then, there is the ordinal number of the referenced OpenMath object as a byte (if the long flag was not set) or a four byte integer (in network byte order).

External References

are encoded using the external reference tags [31] and [31+128] (the sharing flag cannot be set on this tag, since chains of references are not allowed in the OpenMath binary encoding) with the long flag set if the number of bytes in the reference URI is greater than or equal to 256. Then, there is the number of bytes in the URI used for the external reference as a byte (if the long flag was not set) or a four byte integer (in network byte order), followed by the URI.

4.2.3 Sharing with References (beginning with [24+64])

In the binary encoding specified in the last section (which we keep for compatibility reasons, but deprecate in favor of the more efficient binary encoding specified in this section) only symbols, variables, and short strings could be shared. In this section, we will present a second binary encoding, which shares most of the identifiers with the one in the last one, but handles sharing differently. This encoding is signaled by the shared object tags [88].

The main difference is the interpretation of the sharing flag (bit 7), which can be set on all objects that allow it. Instead of encoding a reference to a previous occurrence of an object of the same type, it indicates whether an object will be referenced later in the encoding. This corresponds to the information, whether an id attribute is set in the xml encoding. On the object identifier (where sharing does not make sense), the shared flag signifies the encoding described here ([88]=[24+64]).

Otherwise integers, floats, variables, symbols, strings, bytearrays, and constructs are treated exactly as in the binary encoding described in the last section.

The binary encoding with references uses the additional reference tags [30] for (short) internal references, [30+128] for long internal references, [31] for (short) external references, [31+128] for long external references. Internal references are used to share sub-objects in the encoded object (see Figure 4.3 for an example) by referencing their position; external references allow to reference OpenMath objects in other documents by a URI.

Identifiers [30+64] and [30+64+128] are not used, since they would encode references that are shared themselves. Chains of references are redundant, and decrease both space and time efficiency, therefore they are not allowed in the OpenMath binary encoding.

References consist of the identifier [30] ([30+128] for long references) followed by a positive integer n  coded on one byte (4 bytes for long references). This integer references the n+1th shared sub-object (one where the shared flag is set) in the current object (counted in the order they are generated in the encoding). For example Ox7E Ox01 references the second shared sub-object. Figure Figure 4.3 shows the binary encoding of the object in figure Figure 4.1 above.

It is easy to se