omstd20.xml

<!DOCTYPE book SYSTEM "omstd20.dtd">
<book xml:space="preserve">
<title>The &OM; Standard</title>
<bookinfo>
<releaseinfo>2.0r2</releaseinfo>
<author><firstname>The &OM; Society</firstname></author>
<editor><firstname>S.</firstname><surname>Buswell</surname></editor>
<editor><firstname>O.</firstname><surname>Caprotti</surname></editor>
<editor><firstname>D.</firstname><othername>P.</othername><surname>Carlisle</surname></editor>
<editor><firstname>M.</firstname><othername>C.</othername><surname>Dewar</surname></editor>
<editor><firstname>M.</firstname><surname>Ga&#235;tano</surname></editor>
<editor><firstname>M.</firstname><surname>Kohlhase</surname></editor>
<editor><firstname>J.</firstname><othername>H.</othername><surname>Davenport (revision 1)</surname></editor>
<editor><firstname>P.</firstname><othername>D.F.</othername><surname>Ion (revision 1)</surname></editor>
<editor revisionflag="added"><firstname>T.</firstname><surname>Wiesing (revision 2)</surname></editor>
<date>July 2019</date>

<copyright>
<year>2000&#8211;2019</year>
<holder>The OpenMath Society</holder>
</copyright>

<abstract>
<para>This document describes <phrase  revisionflag="changed">version 2 revision 2</phrase> of
&OM;: a standard for
the representation and communication of mathematical objects.
This revision clarifies the first &OM; 2.0 
<citation>OM_2.0r0</citation>.
 &OM;
allows the <emphasis>meaning</emphasis> of an object to be encoded
rather than just a visual representation.  It is designed to allow the
free exchange of mathematical objects between software systems and human
beings.  On the worldwide web it is designed to allow mathematical
expressions embedded in web pages to be manipulated and used in computations in
a meaningful and correct way.  It is designed to be machine-generatable
and machine-readable, rather than written by hand.
</para>

<para>The &OM; Standard is the official reference for
the &OM; language and has been approved by the &OM; Society.  It is not
intended as an introductory document or a user's guide, for the latest
available material of this nature, and the latest version of the standard, 
please consult the &OM; web-site at
<ulink url="http://www.openmath.org">http://www.openmath.org</ulink>.</para>

<para>This document includes an overview of the
&OM; architecture, an abstract description of <xref linkend="omobj"/>s and two
mechanisms for producing concrete encodings of such objects.  The first,
in &exml; (either innate or Strict Content MathML), is designed primarily 
for use on the web, in documents, and
for applications which want to mix &OM; as a content representation with
MathML as a presentation format.   The second, a binary format, is
designed for applications which wish to exchange very large objects, or
a lot of data as efficiently as possible.  This document also includes a
description of Content Dictionaries - the mechanism by which the meaning
of a symbol in the &OM; language is encoded, as well as an XML encoding
for them.  Finally it includes guidelines for the development of
&OM;-compliant applications. Further background
on &OM; and guidelines for its use in applications may be found in the
accompanying Primer <citation>OM_primer</citation>.</para>

</abstract>
</bookinfo>
  
<toc/>
<lot><title>List of Figures</title></lot>


<chapter id="cha_int">
<title>Introduction to &OM;</title>


<para>This chapter briefly introduces &OM; concepts and notions that are
referred to in the rest of this document.</para>

<section id="sec_om-arch">
<title>&OM; Architecture</title>


<figure id="fig_om">
    <title>The &OM; Architecture</title>
    <graphic fileref="om-arch" depth="500" width="700"/>
</figure>

<para>The architecture of &OM; is described in <xref
linkend="fig_om"/> and summarizes the interactions among the different
&OM; components.  There are three layers of representation of a
mathematical object. The first is a  private layer that
is the internal representation used by an application.  The second is
an abstract layer that is the representation as an <xref linkend="omobj"/>.
Note that these two layers may, in some cases, be the same.
The third is a communication layer that translates the <xref linkend="omobj"/> representation into
a stream of bytes. An application dependent program manipulates the
mathematical objects using its internal representation, it can convert
them to <xref linkend="omobj"/>s and communicate them by using the byte stream
representation of <xref linkend="omobj"/>s.</para>
<para>
 This standard does not describe the mechanisms by which software systems may offer,
 or make use of, computational services. The currently-suggested mechanism is the 
Symbolic Computation Software Composability Protocol (SCSCP) 
<citation>SCSCP13</citation>.
</para>
</section>

<section id="sec_intro-obj">
<title>&OM; Objects and Encodings</title>

<para><xref linkend="omobj"/>s are representations of mathematical entities that
can be communicated among various software applications in a
meaningful way, that is, preserving their
<quote>semantics</quote>.</para>

<para><xref linkend="omobj"/>s and encodings are described in detail in <xref
linkend="cha_obj"/> and <xref linkend="cha_enco"/>.</para>


<para>The standard endorses two encodings 
in &exml; (an innate one described here, and one in Strict Content 
MathML)<phrase revisionflag="deleted">and</phrase><phrase revisionflag="added">,</phrase> a binary format <phrase revisionflag="added">and a JSON encoding</phrase>.
At the time of writing, these are the encodings
supported by most existing &OM; tools and applications,
however they are not the only possible encodings of &OM;
objects. Users who wish to define their own encoding,
are free to do so provided that there is
a well-defined correspondence
between the new encoding and the abstract model defined in <xref
linkend="cha_obj"/>.
</para>

</section>

<section id="sec_intro-cd">
<title>Content Dictionaries</title>


<para>Content Dictionaries (CDs) are used to assign informal and formal
semantics to all symbols used in the <xref linkend="omobj"/>s. They define the
symbols used to represent concepts arising in a particular area of
mathematics.</para>

<para>The Content Dictionaries are public, they represent the actual
common knowledge among &OM; applications.  Content Dictionaries fix
the <quote>meaning</quote> of objects independently of the
application.  The application receiving the object may then recognize
whether or not, according to the semantics of the symbols defined in
the Content Dictionaries, the object can be transformed to the
corresponding internal representation used by the application.</para>
</section>

<section id="sec_addnfiles">
  <title>Additional Files</title>
  <para>
    Several additional files are related to Content Dictionaries.  Signature Dictionaries contain the signatures of symbols defined in some
    &OM; Content Dictionary and their format is endorsed by this standard.
  </para>

<para>Furthermore, the standard fixes how to define a specific
set of Content Dictionaries as a CDGroup.</para>

<para>Auxiliary files that define presentation and rendering or that
are used for manipulating and processing Content Dictionaries are not
discussed by the standard.</para>

</section>
<section id="sec_phrasebooks">
<title>Phrasebooks</title>

<para>The conversion of an <xref linkend="omobj"/> to/from the internal
representation in a software application is performed by an interface
program called a <term id="phrasebook">Phrasebook</term>. The translation is
governed by the Content Dictionaries and the specifics of the
application. It is envisioned that a software application dealing with
a specific area of mathematics declares which Content Dictionaries it
understands. As a consequence, it is expected that the <xref linkend="phrasebook"/> of
the application is able to translate <xref linkend="omobj"/>s built using symbols
from these Content Dictionaries to/from the internal mathematical
objects of the application.
</para>

 <para><xref linkend="omobj"/>s do not
specify any computational behaviour, they merely represent mathematical
expressions.  Part of the &OM; philosophy is to leave it to the
application to decide what it does with an object once it has received
it.  &OM; is not a query or programming language. Because of this,
&OM; does not prescribe a way of forcing <quote>evaluation</quote> or
<quote>simplification</quote> of objects like
<math><mn>2</mn><mo>+</mo><mn>3</mn></math> or
<math><mi>sin</mi><mo>(</mo><mi>&#960;</mi><mo>)</mo></math>. Thus,
the same object <math><mn>2</mn><mo>+</mo><mn>3</mn></math> could be
transformed to <math><mn>5</mn></math> by a computer algebra system,
or displayed as <math><mn>2</mn><mo>+</mo><mn>3</mn></math> by a
typesetting tool. For such a query/programming language, the OpenMath Society recommends
the Symbolic Computation Software Composability Protocol (SCSCP) 
<citation>SCSCP13</citation>.
</para>
</section>
</chapter>

<chapter id="cha_obj">
<title>&OM; Objects</title>

<para>
  In this chapter we provide a self-contained description of <xref linkend="omobj"/>s. We first do so
  by means of an abstract grammar description (<xref linkend="sec_omabs"/>) and then give
  a more informal description (<xref linkend="sec_omin"/>).
</para>


<section id="sec_omabs">
<title>Formal Definition of &OM; Objects</title>

<para>&OM; represents mathematical objects as terms or as labelled trees that are called
<term id='omobj'>&OM; object</term>s or &OM; expressions. The definition of an abstract
<xref linkend="omobj"/> is then the following.</para>


<section id="sec_basic">
  <title>Basic &OM; objects</title>
  <para>
    The Basic &OM; Objects form the leaves of the &OM; Object tree.  A Basic &OM;
    Object is of one of the following.
  </para>
  <itemizedlist>
    <listitem>
      <para><phrase>(i)</phrase> Integer.</para>
      <para>
	Integers in the mathematical sense, with no predefined range.  They are
	<quote>infinite precision</quote> integers (also called <quote>bignums</quote> in
	computer algebra).
      </para>
    </listitem>
    <listitem>
      <para><phrase>(ii)</phrase> <acronym>ieee</acronym> floating point number.</para>
      <para>Double precision floating-point numbers following the <acronym>ieee</acronym>
      754-1985 standard&#160;<citation>ieee754_85</citation>.</para>

</listitem>
<listitem><para><phrase>(iii)</phrase> Character string.</para>

 <para>A Unicode Character string. This also corresponds to 
 <quote>characters</quote> in
  &exml;.</para>

</listitem>
<listitem><para><phrase>(iv)</phrase> Bytearray.</para>

 <para>A sequence of bytes.</para>

</listitem>
<listitem><para><phrase>(v)</phrase> Symbol.</para>

    <para>A Symbol encodes three fields of information, a <term id="symname">symbol
    name</term>, a <term id="cdname">Content Dictionary name</term>, and (optionally) a
    <term id="cdbase">Content Dictionary base URI</term>, The name of a symbol is a
    sequence of characters matching the regular expression described in <xref
    linkend="sec_names"/>.  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 <xref linkend="sec_names"/>) and, optionally, a unique prefix
    called a <term id="cdbase">cdbase</term> 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 fields but whose values may be obtained by inspecting the
    Content Dictionary specified. These include the symbol definition, formal properties
    and examples and, optionally, a <xref linkend="role"/> which is a restriction on where
    the symbol may appear in an <xref linkend="omobj"/>.  The possible roles are described in <xref
    linkend="sec_roles"/>.
    </para>
</listitem>

<listitem>
  <para>
    <phrase>(vi)</phrase> Variable.
  </para>
<para>A Variable must have a <term id="varname">name</term> which is a sequence of
characters matching a regular expression, as described in <xref linkend="sec_names"/>.
</para>
</listitem>
</itemizedlist>
</section>

<section id="sec_derived">
<title>Derived &OM; Objects</title>

<para>Derived &OM; objects are currently used as a way by which non-&OM; data is embedded
inside an <xref linkend="omobj"/>.  A <term id="derivedobj">derived &OM; object</term> is built as follows:
<itemizedlist>
  <listitem>
    <para><phrase>(i)</phrase> If <math><mi>A</mi></math> is <emphasis>not</emphasis> an
    <xref linkend="omobj"/>, then <math><mi
    mathvariant="bold">foreign</mi><mfenced><mi>A</mi></mfenced></math> is an &OM; <term
    id="foreignobj">foreign object</term>.  An &OM; foreign object may optionally have an
    <term id="encoding">encoding</term> field which describes how its contents should be
    interpreted.</para>
</listitem>
</itemizedlist>
</para>
</section>

<section id="sec_compound">
<title>&OM; Objects</title>
  
<para><xref linkend="omobj"/>s are built recursively as follows.
<itemizedlist>
<listitem><para><phrase>(i)</phrase> Basic &OM; objects are <xref linkend="omobj"/>s.
(Note that <xref linkend="derivedobj"/>s are
<emphasis>not</emphasis> <xref linkend="omobj"/>s, but are used to construct &OM;
objects as described below.)</para>
</listitem>

<listitem>
  <para>
    <phrase>(ii)</phrase> If
    <math><msub><mi>A</mi><mn>1</mn></msub></math>,
    <phrase>&#8230;</phrase>,
    <math><msub><mi>A</mi><mi>n</mi></msub></math>
    <math><mo>(</mo><mi>n</mi><mo>&gt;</mo><mn>0</mn><mo>)</mo></math>
    are <xref linkend="omobj"/>s, then
  <math display="block">
  <mi mathvariant="bold">application</mi><mo>(</mo><msub><mi>A</mi><mn>1</mn></msub><mo>,</mo> <mi>&#8230;</mi><mo>,</mo> <msub><mi>A</mi><mi>n</mi></msub><mo>)</mo>
  </math>
  is an <term id="applobj">&OM; application object</term>. We call
  <math><msub><mi>A</mi><mn>1</mn></msub></math> the <term id="function">function</term>
  and  <math><msub><mi>A</mi><mn>2</mn></msub></math> to
  <math><msub><mi>A</mi><mn>1</mn></msub></math> the <term
  id="argument">argument</term>s.</para>
    
 </listitem> <listitem><para><phrase>(iii)</phrase> If
  <math><msub><mi>S</mi><mn>1</mn></msub><mo>,</mo>
  <mi>&#8230;</mi><mo>,</mo> <msub><mi>S</mi><mi>n</mi></msub></math>
  are &OM; symbols, and
<math><mi>A</mi></math> is an <xref linkend="omobj"/>, and
<math><msub><mi>A</mi><mn>1</mn></msub></math>, <phrase>&#8230;</phrase>,
<math><msub><mi>A</mi><mi>n</mi></msub></math>
<math><mo>(</mo><mi>n</mi><mo>&gt;</mo><mn>0</mn><mo>)</mo></math> are <xref linkend="omobj"/>s or
<xref linkend="derivedobj"/>s, then
  <math display="block"><mi mathvariant="bold">attribution</mi>
  <mo>(</mo><mi>A</mi><mo>,</mo> <msub><mi>S</mi><mn>1</mn></msub>
  <mspace width=".3em"/> <msub><mi>A</mi><mn>1</mn></msub><mo>,</mo>
  <mspace width=".3em"/> <mi>&#8230;</mi> <mspace width=".3em"/>
  <mo>,</mo> <msub><mi>S</mi><mi>n</mi></msub> <mspace width=".3em"/>
  <msub><mi>A</mi><mi>n</mi></msub><mo>)</mo></math> is an &OM; <term
  id="attrobj">attribution object</term>. We call
  <math><mi>A</mi></math> the <term id="attobj">attributed object</term>, the
  <math><msub><mi>S</mi><mi>i</mi></msub></math> the <term id="key">keys</term>, and the
  <math><msub><mi>A</mi><mi>i</mi></msub></math> the <term id="attval">attribute
  value</term>s.
  </para> 

  <para>
    If the <xref linkend="attobj"/> is a  variable, the original attribution is called an
    <term id="attvar">attributed  variable</term>.
  </para>
</listitem>

<listitem>
  <para>
    <phrase>(iv)</phrase> If <math><mi>B</mi></math> and
  <math><mi>C</mi></math> are <xref linkend="omobj"/>s, and
  <math><msub><mi>v</mi><mn>1</mn></msub></math>,
  <math><mi>&#8230;</mi></math>,
  <math><msub><mi>v</mi><mi>n</mi></msub></math>
  <math><mo>(</mo><mi>n</mi> <mo>&#8805;</mo>
  <mn>0</mn><mo>)</mo></math> are &OM; variables or <xref linkend="attvar"/>s, then 
  <math display="block">
  <mi mathvariant="bold">binding</mi> <mo>(</mo><mi>B</mi><mo>,</mo> <msub><mi>v</mi><mn>1</mn></msub><mo>,</mo> <mi>&#8230;</mi><mo>,</mo> <msub><mi>v</mi><mi>n</mi></msub><mo>,</mo> <mi>C</mi><mo>)</mo>
  </math>
  is an &OM; <term id="bindingobj">binding object</term>.
    <math><mi>B</mi></math> is called the <term id="binder">binder</term>,  
    <math><msub><mi>v</mi><mn>1</mn></msub></math>,
    <math><mi>&#8230;</mi></math>,
    <math><msub><mi>v</mi><mi>n</mi></msub></math>
    are called <term id="varbindings">variable binding</term>s,
    and <math><mi>C</mi></math> is called the
    <term id="body">body</term> of the binding object above.
    To distinguish the two different ways how variable objects are used, any variable object
    that is not a variable binding is called a <term id="varreference">variable reference</term>.
</para>
</listitem>

<listitem><para><phrase>(v)</phrase> If <math><mi>S</mi></math> is an
&OM; symbol and <math><msub><mi>A</mi><mn>1</mn></msub></math>,
<phrase>&#8230;</phrase>,
<math><msub><mi>A</mi><mi>n</mi></msub></math>
<math><mo>(</mo><mi>n</mi> <mo>&#8805;</mo>
<mn>0</mn><mo>)</mo></math> are <xref linkend="omobj"/>s 
 or <xref linkend="derivedobj"/>s, then <math
display="block"><mi mathvariant="bold">error</mi>
<mo>(</mo><mi>S</mi><mo>,</mo>
<msub><mi>A</mi><mn>1</mn></msub><mo>,</mo><mi>&#8230;</mi><mo>,</mo><msub><mi>A</mi><mi>n</mi></msub><mo>)</mo>
  </math>
  is an &OM; <term id="errorobj">error object</term>.</para>
</listitem>
</itemizedlist>
 <xref linkend="omobj"/>s that are constructed via rules (ii)
   to (v) are jointly called <term id="compoundobj">compound &OM; object</term>s.
</para>
</section>

<section id="sec_roles">
<title>&OM; Symbol Roles</title>

<para>
We say that an &OM; symbol is used to <emphasis>construct</emphasis> an <xref linkend="omobj"/> if it
is the first child of an <xref linkend="applobj"/>, <xref linkend="bindingobj"/> or <xref
linkend="errorobj"/>, or an even-indexed child of an &OM; <xref linkend="attrobj"/>
(i.e. the <xref linkend="key"/> in a <emphasis>(key, value)</emphasis> pair).  The <term
id="role">role</term> of an &OM; symbol is a restriction on how it may be used to
construct a <xref linkend="compoundobj"/> and, in the case of the key in an <xref linkend="attrobj"/>, a
clarification of how that attribution should be interpreted.  The possible roles are:
<orderedlist numeration="lowerroman">
  <listitem>
    <para><term id="binderrole">binder</term> The symbol may 
    appear as the first child of an &OM; binding object.
    </para>
  </listitem>

  <listitem>
    <para><term id="attributionrole">attribution</term>
    The symbol may 
    be used as key in an &OM; <xref linkend="attrobj"/>, 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 &OM; object.
    </para>
  </listitem> 

  <listitem>
    <para>
      <term id="semantic-attribution-role">semantic-attribution</term> This is the same as
      <xref linkend="attributionrole"/> except that it modifies the meaning of the
      attributed &OM; object and thus cannot be ignored by an application, without
      changing the meaning.
    </para>
  </listitem>

  <listitem>
    <para>
      <term id="errorrole">error</term> The symbol may appear as the first child of an
      &OM; <xref linkend="errorobj"/>.
    </para>
  </listitem>

  <listitem>
    <para>
      <term id="applicationrole">application</term> The symbol may appear as the first
      child of an &OM; <xref linkend="applobj"/>.
    </para>
  </listitem>

  <listitem>
    <para>
      <term id="constantrole">constant</term> The symbol cannot be used to construct an
     <xref linkend="compoundobj"/>.
    </para>
  </listitem>
</orderedlist>

A symbol cannot have more than one role and cannot be used to construct a <xref
linkend="compoundobj"/> 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 <xref linkend="applobj"/>.  However it does not
prevent the use of that symbol as an <xref linkend="argument"/> in an <xref
linkend="applobj"/>.
</para>

<para> 
  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 <xref linkend="constantrole"/>.
</para>
</section>
</section>

<section id="sec_omin">
<title>Further Description of &OM; Objects</title>

<para>
  Informally, an &OM; <phrase role="sl">object</phrase> can be viewed as a tree and is
  also referred to as a term.  The objects at the leaves of &OM; trees are called <phrase
  role="sl">basic objects</phrase>.  The basic objects supported by &OM; are:
  <variablelist>
    <varlistentry>
      <term>Integer</term>
      <listitem>
	<para>Arbitrary Precision integers.</para>
      </listitem>
    </varlistentry>

    <varlistentry>
      <term>Float</term>
      <listitem>
	<para>
	  &OM; floats are <acronym>ieee</acronym> 754 Double precision floating-point
	numbers. Other types of floating point number may be encoded in &OM; by the use of
	suitable content dictionaries.
	</para>
      </listitem>
    </varlistentry>

    <varlistentry>
      <term>Character strings</term>
      <listitem>
	<para>are sequences of characters. These characters come from the Unicode
	standard&#160;<citation>UNICODE</citation>.
	</para>
      </listitem>
    </varlistentry>

    <varlistentry>
      <term>Bytearrays</term>
      <listitem>
	<para>are sequences of bytes. There is no <quote>byte</quote> in &OM; 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 &OM; errors to provide information to,
	for example, a debugger; they could also contain intermediate results of
	calculations, or <quote>handles</quote> into computations or databases.</para>
      </listitem>
    </varlistentry>

    <varlistentry>
      <term>Symbols</term>
      <listitem>
	<para>
	  are uniquely defined by the Content Dictionary in which they occur and by a
	  name.  The form of these definitions is explained in <xref linkend="cha_cd"/>.
	  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 <systemitem>union</systemitem> is defined as
	  associative-commutative set theoretic union in a Content Dictionary
	  <systemitem>set1</systemitem> but another Content Dictionary,
	  <systemitem>multiset1</systemitem> might define a symbol
	  <systemitem>union</systemitem> as the union of multi-sets).
	</para>
      </listitem>
    </varlistentry>
    
    <varlistentry>
      <term>Variables</term>
      <listitem>
	<para>are meant to denote parameters, variables or indeterminates (such as bound
	variables of function definitions, variables in summations and integrals, independent
	variables of derivatives).
	</para>
      </listitem>
    </varlistentry>
  </variablelist>
</para>
<para>
	Although foreign objects can come with a standarized encoding 
	field, their interpretation is an issue beyond the &OM; 
	standard. In particular, a foreign object is primarily data 
	that has been encoded in some format, and there is no 
	promise that foreign objects encountered within one encoding 
	of &OM; can be faithfully represented in another.
</para>

<para>
  Derived &OM; objects are constructed from non-&OM; data.  They differ from bytearrays in
  that they can have any structure.  Currently there is only one way of making a <xref
  linkend="derivedobj"/>.
</para>

<variablelist>
  <varlistentry>
    <term>Foreign</term>
    <listitem>
      <para>
	is used to import a non-&OM; object into an &OM; 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 &OM; <xref linkend="errorobj"/>s, for example to allow an
	application to report an error in processing such an object.
      </para>
    </listitem>
  </varlistentry>
</variablelist>

<para>
  The four following constructs can be used to make <xref linkend="compoundobj"/> out of
  basic or <xref linkend="derivedobj"/>s.
</para>
<variablelist>
  <varlistentry>
    <term>Application</term>
    <listitem>
      <para>
	constructs an &OM; object from a sequence of one or more &OM; objects. The first
	child of an application is referred to as its
	<quote>head</quote> while the remaining objects are called its
	<quote>arguments</quote>.  An &OM; <xref linkend="applobj"/> can be used to convey
	the mathematical notion of application of a <xref linkend="function"/> to a set of
	<xref linkend="argument"/>.  For instance, suppose that the &OM; symbol
	<math><mi>sin</mi></math> is defined in a suitable Content
	Dictionary, then <math><mi
	mathvariant="bold">application</mi><mo>(</mo><mi>sin</mi><mo>,</mo>
	<mi>x</mi> <mo>)</mo></math> is the abstract &OM; object
	corresponding to <math><mi>sin</mi> <mo>(</mo><mi>x</mi>
	<mo>)</mo></math>.  More generally, an &OM; <xref linkend="applobj"/> 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
	<math><mn>1</mn><mo>/</mo><mn>2</mn></math>, is represented by the
	&OM; <xref linkend="applobj"/> <math><mi
	mathvariant="bold">application</mi><mo>(</mo><mi>Rational</mi><mo>,</mo>
	<mn>1</mn><mo>,</mo> <mn>2</mn><mo>)</mo></math>. The symbol
	<math><mi>Rational</mi></math> must be defined, by a Content
      Dictionary, as a constructor symbol for the rational numbers.</para>
      
      <figure id="fig_obj">
	<title>The &OM; application and binding objects for
	<math><mi>sin</mi> <mo>(</mo><mi>x</mi> <mo>)</mo></math> and
	<math><mi>&#955;</mi> <mi>x</mi><mo>.</mo><mi>x</mi> <mo>+</mo>
	<mn>2</mn></math> in tree-like notation.</title>  <graphic fileref="lambda"
	width="600" depth="190"/>
      </figure>
    </listitem>
  </varlistentry>
  
<varlistentry>
  <term>Binding</term>
  <listitem>
    <para>objects are of the form
    <math>
      <mi mathvariant="bold">binding</mi>
      <mo>(</mo>
      <mi>B</mi>
      <mo>,</mo>
      <msub><mi>v</mi><mn>1</mn></msub>
      <mo>,</mo>
      <mi>&#8230;</mi>
      <mo>,</mo>
      <msub><mi>v</mi><mi>n</mi></msub>
      <mo>,</mo>
      <mi>C</mi>
      <mo>)</mo>
      <mtext>.</mtext>
    </math>
    The <term id="scope">scope</term> of a variable binding
    <math><msub><mi>v</mi><mi>i</mi></msub></math>
    (<math><mn>1</mn><mo>&#8804;</mo><mi>i</mi><mo>&#8804;</mo><mi>n</mi></math>)
    is constituted by the <xref linkend="body"/>
    <math><mi>C</mi></math> together with the attribute values of subsequent variable
    bindings <math><msub><mi>v</mi><mi>j</mi></msub></math> with
    <math><mi>i</mi><mo>&lt;</mo><mi>j</mi><mo>&#8804;</mo><mi>n</mi></math>.
    A variable reference <math><mi>R</mi></math> is <quote>bound</quote> by the variable
    binding <math><mi>B</mi></math>, if <math><mi>B</mi></math> is the
    closest variable binding for the same name that has
    <math><mi>R</mi></math> in its scope. A variable reference that is not bound by any
    variable binding is called a <quote>free variable</quote>. Note that the binder itself
    is not part of the scope of any of its bound variables. In particular, no 
    variable references in <math><mi>B</mi></math> can be bound by any of the variable bindings <math><msub><mi>v</mi><mi>i</mi></msub></math>.
    Binding objects are allowed to have no bound variables, but the binder object and the
    body should be present.
    </para>
    <para> Binding can be used to express functions or logical statements.  The function
    <math>
      <mi>&#955;</mi>
      <mi>x</mi>
      <mo>.</mo>
      <mi>x</mi>
      <mo>+</mo>
      <mn>2</mn>
      </math>, in which
      the variable <math><mi>x</mi></math> is bound by
      <math><mi>&#955;</mi></math>, corresponds to a binding object having
      as binder the &OM; symbol <math><mi>lambda</mi></math>:
      <math display="block">
	<mi mathvariant="bold">binding</mi>
	<mo>(</mo>
	<mi>lambda</mi>
	<mo>,</mo>
	<mi>x</mi>
	<mo>,</mo>
	<mi mathvariant="bold">application</mi>
	<mo>(</mo>
	<mi>plus</mi>
	<mo>,</mo>
	<mi>x</mi>
	<mo>,</mo>
	<mn>2</mn>
	<mo>)</mo>
	<mo>)</mo>
	<mtext>.</mtext>
      </math>
    </para>

    <para><xref linkend="phrasebook"/>s are allowed to use <term id="alphaconversion"><math><mi>&#945;</mi></math>-conversion</term>
    (also called <term id="alpharenaming">alphabetic
    renaming</term>)
    in order to avoid clashes of variable names:  the variable in a variable binding
    can be replaced by a
    <term id="newvar">new variable</term>, i.e. one that does not occur anywhere in
    the scope of the binding, if all variable references it binds are replaced accordingly:
    Suppose <math><mi>&#937;</mi></math> contains an occurrence of the
    object
    <math>
      <mi mathvariant="bold">binding</mi>
      <mo>(</mo>
      <mi>B</mi>
      <mo>,</mo>
      <mover>
	<mi>v</mi>
	<mo>&#x2192;</mo>
      </mover>
      <mo>,</mo>
      <mi>x</mi>
      <mo>,</mo>
      <mover>
	<mi>w</mi>
	<mo>&#x2192;</mo>
      </mover>
      <mo>,</mo>
      <mi>C</mi>
      <mo>)</mo>
    </math>
    where
    <math>
      <mover>
	<mi>v</mi>
	<mo>&#x2192;</mo>
      </mover>
  </math>
  and 
  <math>
    <mover>
      <mi>w</mi>
      <mo>&#x2192;</mo>
    </mover>
  </math>
  are (possibly empty)
  sequences of bound, possibly attributed variables and <math><mi>x</mi></math> is a
  variable. 
  This object
  <math>
    <mi mathvariant="bold">binding</mi>
    <mo>(</mo>
    <mi>B</mi>
    <mo>,</mo>
    <mover>
      <mi>v</mi>
      <mo>&#x2192;</mo>
    </mover>
    <mo>,</mo>
    <mi>x</mi>
    <mo>,</mo>
    <mover>
      <mi>w</mi>
      <mo>&#x2192;</mo>
    </mover>
    <mo>,</mo>
    <mi>C</mi>
    <mo>)</mo>
  </math>
can be replaced
in <math><mi>&#937;</mi></math> by
<math>
  <mi  mathvariant="bold">binding</mi>
  <mo>(</mo>
  <mi>B</mi>
  <mo>,</mo>
    <mover>
      <mi>v</mi>
      <mo>&#x2192;</mo>
    </mover>
  <mo>,</mo>
  <mi>y</mi>
  <mo>,</mo>
    <mover>
      <mi>w'</mi>
      <mo>&#x2192;</mo>
    </mover>
    <mo>,</mo>
  <mi>C'</mi>
  <mo>)</mo>
</math>
where <math><mi>y</mi></math> is a <xref linkend="newvar"/>, i.e. one that does not occur anywhere in <math><mover><mi>w</mi><mo>&#x2192;</mo></mover>
</math> or <math><mi>C</mi></math>
    and 
  <math>
    <mover>
      <mi>w'</mi>
      <mo>&#x2192;</mo>
    </mover>
  </math>
  and
  <math><mi>C'</mi></math>
  are  obtained  from
  <math>
    <mover>
      <mi>w</mi>
      <mo>&#x2192;</mo>
    </mover>
  </math>
  and 
  <math><mi>C</mi></math>,
  by replacing each free occurrence
  of <math><mi>x</mi></math> by <math><mi>y</mi></math>.
    If instead of 
    <math><mi>x</mi></math> in   <math><mi>&#937;</mi></math>,  we have an attributed
    variable 
  <math>
    <mi mathvariant="bold">attribution</mi>
    <mo>(</mo>
    <mi>x</mi>
    <mo>,</mo>
    <mover>
      <mi>a</mi>
      <mo>&#x2192;</mo>
    </mover>
    <mo>)</mo>
    </math>, then instead of <math><mi>y</mi></math> we
    must have
    <math>
      <mi mathvariant="bold">attribution</mi>
      <mo>(</mo>
      <mi>y</mi>
      <mo>,</mo>
      <mover>
	<mi>a</mi>
	<mo>&#x2192;</mo>
      </mover>
      <mo>)</mo>
    </math>
  This operation preserves the semantics of the object
  <math><mi>&#937;</mi></math>. In the above example, a phrasebook is
  thus allowed to transform the object to, e.g. 
  <math  display="block">
    <mi mathvariant="bold">binding</mi>
    <mo>(</mo>
    <mi>lambda</mi>
    <mo>,</mo>
    <mi>z</mi>
    <mo>,</mo>
    <mi mathvariant="bold">application</mi>
    <mo>(</mo>
    <mi>plus</mi>
    <mo>,</mo>
    <mi>z</mi>
    <mo>,</mo>
    <mn>2</mn>
    <mo>)</mo>
    <mo>)</mo>
    <mtext>.</mtext>
  </math>
</para>
<para>
 Note that repeated variable bindings of the same
  variable in a binding object are allowed, but make little sense semantically and are
  therefore discouraged: the first binding binds only references in the subsequent
  bindings up to and including the next binding for the same name. 
  Therefore, an &OM; application may choose to <math><mi>&#945;</mi></math>-convert all
  but the last binding to <xref linkend="newvar"/>s. Concretely, the following replacement is carried
  out until there are no more  bound variable duplications:
  <math display="block">
    <mrow>
      <mi mathvariant="bold">binding</mi>
      <mo>(</mo>
      <mi>B</mi>
      <mo>,</mo>
      <mover>
	<mi>u</mi>
	<mo>&#x2192;</mo>
      </mover>
      <mo>,</mo>
      <mi>x</mi>
      <mo>,</mo>
      <mover>
	<mi>v</mi>
	<mo>&#x2192;</mo>
      </mover>
      <mo>,</mo>
      <mi>y</mi>
      <mo>,</mo>
      <mover>
	<mi>w</mi>
	<mo>&#x2192;</mo>
      </mover>
      <mo>,</mo>
      <mi>C</mi>
      <mo>)</mo>
    </mrow>
    <mo>&#x27F6;</mo>
    <mrow>
      <mi mathvariant="bold">binding</mi>
      <mo>(</mo>
      <mi>B</mi>
      <mo>,</mo>
      <mover>
	<mi>u</mi>
	<mo>&#x2192;</mo>
      </mover>
      <mo>,</mo>
      <mi>x'</mi>
      <mo>,</mo>
      <mover>
	<mi>v'</mi>
	<mo>&#x2192;</mo>
      </mover>
      <mo>,</mo>
      <mi>y'</mi>
      <mo>,</mo>
      <mover>
	<mi>w</mi>
	<mo>&#x2192;</mo>
      </mover>
      <mo>,</mo>
      <mi>C</mi>
      <mo>)</mo>
    </mrow>
  </math>
  where <math><mi>x</mi></math> and <math><mi>y</mi></math> are (possibly attributed)
  variables with the same head <math><mi>z</mi></math>, the heads of bound (attributed)
  variables in <math><mover><mi>u</mi><mo>&#x2192;</mo></mover></math> are all different
  from <math><mi>z</mi></math>, and <math><mi>x'</mi></math>,
  <math><mi>y'</mi></math>, and 
  <math><mover><mi>v'</mi><mo>&#x2192;</mo></mover></math> are obtained from
  <math><mi>x</mi></math>,   <math><mi>y</mi></math>, and 
  <math><mover><mi>v</mi><mo>&#x2192;</mo></mover></math>
  by replacing <math><mi>z</mi></math> with a variable
  <math><mi>z'</mi></math> that does not occur in <math><mi>x</mi></math>,
  <math><mi>y</mi></math>, <math><mover><mi>u</mi><mo>&#x2192;</mo></mover></math>,
  <math><mover><mi>v</mi><mo>&#x2192;</mo></mover></math>,
  <math><mover><mi>w</mi><mo>&#x2192;</mo></mover></math>, and <math><mi>C</mi></math>.
</para>
</listitem>
</varlistentry>
<varlistentry>
  <term>Attribution</term>
  <listitem>
    <para>
      decorates an object (called the <quote>syntactic
      head</quote> of the attribution) with a sequence of one or more pairs made
      up of an &OM; symbol, the <quote>attribute</quote>, and an associated object, the
      <quote>value of the attribute</quote>.  The value of the attribute can be an &OM; <xref linkend="attrobj"/> itself. As an example of this, consider the
      &OM; objects representing groups, automorphism groups, and group dimensions. It is
      then possible to attribute an &OM; object representing a group by its automorphism
      group, itself attributed by its dimension.
    </para>
    <para>
      &OM; objects can be attributed with &OM; <xref linkend="foreignobj"/>, which are
      containers for non-&OM; structures.  For example a mathematical expression could be
      attributed with its spoken or visual rendering.
    </para>

<para>Composition of attributions, as in
  <math display="block">
<mi mathvariant="bold">attribution</mi><mo>(</mo><mi
  mathvariant="bold">attribution</mi><mo>(</mo><mi>A</mi><mo>,</mo>
  <msub><mi>S</mi><mn>1</mn></msub> <mspace width=".3em"/>
  <msub><mi>A</mi><mn>1</mn></msub><mo>,</mo><mi>&#8230;</mi><mo>,</mo><msub><mi>S</mi><mi>h</mi></msub>
  <mspace width=".3em"/>
  <msub><mi>A</mi><mi>h</mi></msub><mo>)</mo><mo>,</mo>
  <msub><mi>S</mi><mrow><mi>h</mi><mo>+</mo><mn>1</mn></mrow></msub>
  <mspace width=".3em"/>
  <msub><mi>A</mi><mrow><mi>h</mi><mo>+</mo><mn>1</mn></mrow></msub><mo>,</mo>
  <mi>&#8230;</mi><mo>,</mo> <msub><mi>S</mi><mi>n</mi></msub> <mspace
  width=".3em"/> <msub><mi>A</mi><mi>n</mi></msub><mo>)</mo></math> is
  semantically equivalent to a single attribution, that is <math
  display="block"><mi
  mathvariant="bold">attribution</mi><mo>(</mo><mi>A</mi><mo>,</mo>
  <msub><mi>S</mi><mn>1</mn></msub> <mspace width=".3em"/>
  <msub><mi>A</mi><mn>1</mn></msub><mo>,</mo>
  <mi>&#8230;</mi><mo>,</mo> <msub><mi>S</mi><mi>h</mi></msub> <mspace
  width=".3em"/> <msub><mi>A</mi><mi>h</mi></msub><mo>,</mo>
  <msub><mi>S</mi><mrow><mi>h</mi><mo>+</mo><mn>1</mn></mrow></msub>
  <mspace width=".3em"/>
  <msub><mi>A</mi><mrow><mi>h</mi><mo>+</mo><mn>1</mn></mrow></msub><mo>,</mo>
  <mi>&#8230;</mi><mo>,</mo> <msub><mi>S</mi><mi>n</mi></msub> <mspace
  width=".3em"/>
  <msub><mi>A</mi><mi>n</mi></msub><mo>)</mo><mtext>.</mtext></math>
  The operation that produces an object with a single layer of
  attribution is called <term id="flattening">flattening</term>. The
  <quote>head</quote> of an attribution is the syntactic head of the fully (recursively)
  flattened version.
</para>

<para>
  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 <math><msub><mi>S</mi><mi>h</mi></msub> <mo>=</mo>
  <msub><mi>S</mi><mi>n</mi></msub></math> (<math><mi>h</mi>
  <mo>&lt;</mo> <mi>n</mi></math>) in the example above. Then, the object is to be
  interpreted as if the value <math><msub><mi>A</mi><mi>n</mi></msub></math> overwrites
  the value <math><msub><mi>A</mi><mi>h</mi></msub></math>.  (&OM; however does not
  mandate that an application preserves the attributes or their order.)
</para>

  <para>
    Attribution acts as either adornment annotation or as semantical annotation. When the
    key has role <xref linkend="attributionrole"/>, then replacement of the attributed
    object by the object itself is not harmful and preserves the semantics. When the key
    has role <xref linkend="semantic-attribution-role"/> 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.
  </para>


<para>Objects can be decorated in a multitude of ways.
An example of the use of an adornment attribution
would be to indicate the colour in which an &OM; object should be
displayed, for example <math><mi
mathvariant="bold">attribution</mi><mo>(</mo><mi>A</mi><mo>,</mo>
<mi>colour</mi> <mspace width=".3em"/> <mi>red</mi> <mo>)</mo></math>.  Note that both
<math><mi>A</mi></math> and <math><mi>red</mi></math> are arbitrary &OM; objects whereas <math><mi>colour</mi></math> is a symbol.  An example of
the use of a semantic attribution would be to indicate the type of an object.  For
example the object <math><mi
mathvariant="bold">attribution</mi><mo>(</mo><mi>A</mi><mo>,</mo>
<mi>type</mi> <mspace width=".3em"/> <mi>t</mi> <mo>)</mo></math>
represents the judgment stating that object <math><mi>A</mi></math>
has type <math><mi>t</mi></math>. Note that both
<math><mi>A</mi></math> and <math><mi>t</mi></math> are arbitrary &OM;
objects whereas <math><mi>type</mi></math> is
a symbol.</para>


</listitem>
</varlistentry>
<varlistentry><term>Error</term><listitem><para>is made up of an &OM;
  symbol and a sequence of zero or more &OM; objects. This object has
  no direct mathematical meaning.  Errors occur as the result of some
  treatment on an &OM; 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.  <xref linkend="errorobj"/>s might
  consist only of a symbol as in the object: <math><mi
  mathvariant="bold">error</mi> <mo>(</mo><mi>S</mi>
  <mo>)</mo></math>.</para> 
</listitem>
</varlistentry>
</variablelist> 
</section>

<section id="sec_names">
<title>Names</title>

<para>
  The names of symbols, variables and content dictionaries must conform to the production
  <systemitem>Name</systemitem> specified in the following grammar (which is identical to
  that for &exml; names in XML 1.1, <citation>xml_04</citation>). Informally speaking, a
  name is a sequence of Unicode <citation>UNICODE</citation> characters which begins with
  a letter and cannot contain certain punctuation and combining characters.  The notation
  <systemitem>#x...</systemitem> represents the hexadecimal value of the encoding of a
  Unicode character.  Some of the character values or <emphasis>code points</emphasis> in
  the following productions are currently unassigned, but this is likely to change in the
  future as Unicode evolves<footnote id="xml1">
  <para>
    We note that in XML 1 the name production explicitly listed the characters that were
    allowed, so all the characters added in versions of Unicode after 2.0 (which amounted
    to tens of thousands of characters) were not allowed in names.
  </para>
  </footnote>.
</para>

<blockquote>
<informaltable>
<tgroup cols="3">
<tbody>
<row>
<entry>Name </entry>
<entry> <math><mo>&longrightarrow;</mo></math> </entry>
<entry> NameStartChar (NameChar)* </entry>
</row>
<row>
<entry>NameStartChar</entry>
<entry> <math><mo>&longrightarrow;</mo></math> </entry>
<entry>  ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] |</entry></row>
<row><entry/><entry/><entry>[#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] |</entry></row>
<row><entry/><entry/><entry>[#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] |</entry></row>
<row><entry/><entry/><entry>[#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] |</entry></row>
<row><entry/><entry/><entry>[#x10000-#xEFFFF] 
</entry>
</row>
<row>
<entry>NameChar</entry>
<entry> <math><mo>&longrightarrow;</mo></math> </entry>
<entry>  NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] |</entry></row>
<row><entry/><entry/><entry>[#x203F-#x2040] </entry>
</row>
</tbody>
</tgroup>
</informaltable>
</blockquote>


<formalpara><title>CD Base</title>

<para>A cdbase is interpreted as an IRI
<citation>IETF3987</citation>, which specifies how strings are encoded and interpreted as URL.
Applications should ignore any white space surrounding the URL.</para>


</formalpara>

<formalpara>
  <title>Note on content dictionary names</title>
  <para>
    It is a common convention to store a Content Dictionary in a file of the same name,
    which can cause difficulties on many file systems.  If this convention is to be
    followed then &OM; <emphasis>recommends</emphasis> that the name be restricted to the
    subset of the above grammar which is a legal POSIX <citation>POSIX</citation>
    filename, namely:
<blockquote>
<informaltable>
<tgroup cols="3">
<tbody>
<row>
<entry>Name </entry>
<entry> <math><mo>&longrightarrow;</mo></math> </entry>
<entry> (PosixLetter | '_') (Char)*
</entry>
</row>
<row>
<entry>Char</entry>
<entry> <math><mo>&longrightarrow;</mo></math> </entry>
<entry> PosixLetter | Digit | '.' | '-' | '_' 
</entry>
</row>
<row>
<entry>PosixLetter</entry>
<entry> <math><mo>&longrightarrow;</mo></math> </entry>
<entry> 
'a' | 'b' | ... | 'z' | 'A' | 'B' | ... | 'Z'
</entry>
</row>
<row>
<entry>Digit</entry>
<entry> <math><mo>&longrightarrow;</mo></math> </entry>
<entry> 
'0' | '1' | ... | '9' 
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</blockquote>
</para>
</formalpara>

<formalpara><title>Canonical URIs for Symbols</title>
<para>
To facilitate the use of &OM; within a URI-based framework (such as RDF
<citation>rdf</citation> or OWL <citation>owl</citation>), we provide the
following scheme for constructing a canonical URI
for an &OM; Symbol:
<blockquote>
  <para><systemitem>URI = cdbase-value + '/' + cd-value + '#' + name-value</systemitem></para>
</blockquote>
So for example the URI for the symbol with cdbase
<systemitem>http://www.openmath.org/cd</systemitem>, cd
<systemitem>transc1</systemitem> and name <systemitem>sin</systemitem>
is:
<blockquote>
  <para><systemitem>http://www.openmath.org/cd/transc1#sin</systemitem></para>
</blockquote>
In particular, this now allows us to refer uniquely to an &OM; symbol from a
MathML-2 document <citation>MathML_2003</citation> (see <citation>MathML_2014</citation> section 4.2.3 for MathML-3):
<literallayout>
&lt;mathml:csymbol xmlns:mathml="http://www.w3.org/1998/Math/MathML/"
                definitionURL="http://www.openmath.org/cd/transc1#sin"&gt;
  &lt;mo&gt; sin &lt;/mo&gt; 
&lt;/mathml:csymbol&gt;
</literallayout>
</para>
</formalpara>

</section>

<section id="sec_summary">
<title>Summary</title>

<itemizedlist>
<listitem> <para>&OM; supports basic objects like integers, symbols,
  floating-point numbers, character strings, bytearrays, and
  variables.</para>
</listitem>
<listitem> <para><xref linkend="compoundobj"/>s are of four kinds: applications, bindings,
errors, and attributions.</para>
</listitem>
<listitem> <para>&OM; objects may be attributed
with non-&OM; objects via the use of foreign &OM; objects.
  </para>
</listitem>
<listitem> <para>&OM; objects have the expressive power to cover all
  areas of computational mathematics.</para>
</listitem>
</itemizedlist>

 <para>Observe that an &OM;
<xref linkend="applobj"/> is viewed as a <quote>tree</quote> by software
applications that do not understand Content Dictionaries, whereas a
<xref linkend="phrasebook"/> that understands the semantics of the symbols, as defined
in the Content Dictionaries, should interpret the object as function
application, constructor, or binding accordingly. Thus, for example,
for some applications, the &OM; object corresponding to
<math><mn>2</mn><mo>+</mo><mn>5</mn></math> may result in a command
that writes <math><mn>7</mn></math>.</para>
</section>
</chapter>

<chapter id="cha_enco">
<title>&OM; Encodings</title>


<para>In this chapter, two encodings are defined 
that map between &OM; 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. In addition, OpenMath can be represented in Strict Content MathML, 
as described in Section 4.1.3 of <citation>MathML_2014</citation>.</para>

<para>The first encoding is the innate character-based
encoding in &exml; format.  In previous versions of the &OM; Standard
this encoding was a restricted subset of the full legal &exml; 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
&exml; encoding can be used, for example, to send &OM; objects via
e-mail, cut-and-paste, etc. and to embed &OM; objects in &exml;
documents or to have &OM; objects processed by &exml;-aware
applications.</para>

<para>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).</para>

<para>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. In the case of the MathML 
encoding, the reading application should already be expecting MathML.</para>

<section id="sec_xml">
<title>The &exml; Encoding</title>

<para>This encoding has been designed with two main goals in mind:
<orderedlist>
<listitem><para>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.</para>
</listitem>
<listitem><para>to provide an encoding that can be included (embedded) in
  &exml; documents or processed by &exml;-aware applications.</para>
</listitem>
</orderedlist> 
</para>

<section id="ssec_xml">
<title>A Schema for the &exml; Encoding</title>

<para>The &exml; encoding of an &OM; object is
defined by the Relax NG schema <citation>RELAX</citation> given below.
Relax NG has a number of advantages over the older XSD Schema format
<citation>XSD</citation>, in particular it allows for tighter control
of attributes and has a modular, extensible structure.  Although we
have made the &exml; form, which is given in <xref
linkend="app_openmath.rng"/>, 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 &OM; symbols as described in <xref
linkend="app_relaxrestricted"/>.  </para>

<para> Standard tools exist for generating a DTD
or an XSD schema from a Relax NG Schema.  Examples of such documents
are given in <xref linkend="app_dtd"/> and <xref linkend="app_xsd"/>,
respectively.</para>

<literallayout role="rnc" file="openmath2.rnc"/>

<para><emphasis role="bold">Note:</emphasis> 
In the original edition of OpenMath 2.0 as published, names are specified
as being of the <systemitem>xsd:NCName</systemitem> type. 
When the original edition of OpenMath 2.0 was published, 
W3C Schema types were defined in terms of XML 1 <citation>xml_98</citation>. 
This limited the characters allowed in a name to a
subset of the characters available in Unicode 2.0, which was far more 
restrictive than the definition for an &OM; name given in <xref linkend="sec_names"/>. 
The situation has changed with the appearance of XML 1.0 5th edition, 
and more specifically erratum NE17 in <citation>erratum_NE17</citation>, 
and there is no known contradiction remaining.
</para>

</section>

<section id="sec_xml-desc">
<title>Informal description of
the &exml; Encoding</title>

<para>An encoded &OM; object is placed inside an <systemitem>OMOBJ</systemitem> element.
This element can contain the elements (and integers) described above.  It can take an
optional <systemitem>version</systemitem> (&exml;) attribute which indicates to which
version of the &OM; standard it conforms.  In previous versions of this standard this
attribute did not exist, so any &OM; object without such an attribute must conform to
version 1 (or equivalently 1.1) of the &OM; standard.  Objects which conform to the
description given in this document should have <systemitem>version="2.0"</systemitem>.
 If the <systemitem>version</systemitem> attribute is not
present, the document format embedding the <systemitem>OMOBJ</systemitem> may provide a
method for determining version information (the XML encoding for &OM; content dictionaries
does, for instance). The <systemitem>OMOBJ</systemitem> element can also take an optional
<systemitem>cdgroup</systemitem> attribute, which specifies a CD group file that acts as a
catalogue of CD bases for locating OpenMath content dictionaries of
<systemitem>OMS</systemitem> elements in this <systemitem>OMOBJ</systemitem> element. When
no <systemitem>cdgroup</systemitem> attribute is explicitly specified, the document format
embedding this <systemitem>OMOBJ</systemitem> element may provide a method for determining
CD bases. Otherwise the system must determine a CD base; in the absence of specific
information <ulink url="http://www.openmath.org/cd">http://www.openmath.org/cd</ulink> is
assumed as the CD base for all <systemitem>OMS</systemitem> elements.
</para>

<para>We briefly discuss the &exml; encoding for each type of &OM; object
starting from the basic objects.</para>

<variablelist>
<varlistentry><term>Integers</term>
<listitem>
 <para>are encoded using the
<systemitem>OMI</systemitem> 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
<systemitem>-?[0-9]+</systemitem>.  Integers written in base 16 match
<systemitem>-?x[0-9A-F]+</systemitem>.  The integer 10 can be thus
encoded as <systemitem>&lt;OMI> 10 &lt;/OMI> </systemitem> or as
<systemitem>&lt;OMI> xA &lt;/OMI> </systemitem> but neither
<systemitem>&lt;OMI> +10 &lt;/OMI></systemitem> nor
<systemitem>&lt;OMI> +xA &lt;/OMI></systemitem> can be used.</para>

<para>
  The negative integer <math><mn>-120</mn></math> can be encoded as either as decimal
  <systemitem>&lt;OMI> -120 &lt;/OMI></systemitem> or as hexadecimal <systemitem>&lt;OMI>
  -x78 &lt;/OMI></systemitem>.
</para>
</listitem>
</varlistentry>
<varlistentry>
  <term>Symbols</term><listitem>
  <para>are encoded using the <systemitem>OMS</systemitem> element. This element has three
  (&exml;) attributes <systemitem>cd</systemitem>, <systemitem>name</systemitem>, and
  <systemitem>cdbase</systemitem>. The value of <systemitem>cd</systemitem> is the name of
  the Content Dictionary in which the symbol is defined and the value of
  <systemitem>name</systemitem> is the name of the symbol.  The optional
  <systemitem>cdbase</systemitem> 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 <systemitem>cdbase</systemitem> attribute, then it inherits its
  <systemitem>cdbase</systemitem> from the first ancestor in the &exml; tree with one,
  should such an element exist. If no CD base can be
  determined in this way, then it is determined by the catalog induced by the CD group
  determined for the <systemitem>OMOBJ</systemitem>. Should this be impossible, the CD
  base defaults to <systemitem>http://www.openmath.org/cd</systemitem>. In this
  document we have tended to omit the <systemitem>cdbase</systemitem> for clarity.  For
  example:
  <blockquote>
    <para>
      <systemitem>&lt;OMS cdbase="http://www.openmath.org/cd" cd="transc1" name="sin"/></systemitem>
    </para>
</blockquote>
  is the encoding of the symbol named <systemitem>sin</systemitem> in the Content
  Dictionary named <systemitem>transc1</systemitem>, which is part of the collection
  maintained by the &OM; Society.</para>

  <para>
    As described in <xref linkend="sec_names"/>, the three attributes of the
    <systemitem>OMS</systemitem> 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
    <systemitem>http://www.openmath.org/cd/transc1#sin</systemitem>.
</para>

<para>
  Note that the role attribute described in <xref linkend="sec_roles"/> is contained in
  the Content Dictionary and is not part of the encoding of a symbol, also the
  <systemitem>cdbase</systemitem> attribute need not be explicit on each
  <systemitem>OMS</systemitem> as it is inherited from any ancestor element.</para>
</listitem>
</varlistentry>
<varlistentry><term>Variables</term><listitem><para>are encoded using
  the <systemitem>OMV</systemitem> element, with only one
  (&exml;) attribute, <systemitem>name</systemitem>, whose value is the
  variable name. For instance, the encoding of the object
  representing the variable <math><mi>x</mi></math> is:
  <systemitem>&lt;OMV name="x"/></systemitem></para>

 
</listitem>
</varlistentry>
<varlistentry><term>Floating-point numbers</term><listitem><para>are
  encoded using the <systemitem>OMF</systemitem> element that has
  either the (&exml;) attribute <systemitem>dec</systemitem> or the
  (&exml;) attribute <systemitem>hex</systemitem>. The two
  (&exml;) attributes cannot be present simultaneously. The value of
  <systemitem>dec</systemitem> is the floating-point number expressed
  in base 10, using the common syntax:</para>
  
  <blockquote><para>
  <systemitem>(-?)([0-9]+)?("."[0-9]+)?([eE](-?)[0-9]+)?</systemitem>.
  </para>
  <para>or one of the special values: INF, -INF or
  NaN.</para>
</blockquote>
  <para>The value of
  <systemitem>hex</systemitem> is a base 16 representation of the 
 64 bits of the <acronym>ieee</acronym> Double.
 Thus the number represents mantissa, exponent, and sign in network byte order.
 This consists of a string of 16 digits <systemitem>0</systemitem>-<systemitem>9</systemitem>, <systemitem>A</systemitem>-<systemitem>F</systemitem>.
  </para>
  <para>For example, both <systemitem>&lt;OMF
    dec="1.0e-10"/&gt;</systemitem> and 
   <systemitem>&lt;OMF hex="3DDB7CDFD9D7BDBB"/&gt;</systemitem>
  are valid representations of the floating point number
  <math><mn>1</mn><mo>&#215;</mo>
<msup><mn>10</mn><mn>-10</mn></msup></math>.</para>
 
 <para> The symbols <systemitem>INF</systemitem>,
<systemitem>-INF</systemitem> and <systemitem>NaN</systemitem> represent
positive and negative infinity, and <emphasis>not a number</emphasis> as
defined in <citation>ieee754_85</citation>.  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
<systemitem>&lt;OMF hex="FFF8000000000000"/&gt;</systemitem> and
<systemitem>&lt;OMF hex="FFF8000000000001"/&gt;</systemitem> are both
hexadecimal representations of NaNs.
</para>


</listitem>
</varlistentry>
<varlistentry><term>Character strings</term><listitem><para>are encoded using the <systemitem>OMSTR</systemitem> element.
  Its content is  a Unicode text. Note that as always in &exml; the
  characters <systemitem>&lt;</systemitem> and <systemitem>&amp;</systemitem>  need to be represented by the
  entity references <systemitem>&amp;lt;</systemitem> and
<systemitem>&amp;amp;</systemitem> respectively.</para>
  
</listitem>
</varlistentry>
<varlistentry><term>Bytearrays</term><listitem><para>are encoded using the <systemitem>OMB</systemitem> element. Its content
  is a sequence of characters that is a base64 encoding of the data.
  The base64 encoding is defined in <acronym>rfc</acronym>
  2045 <citation>rfc2045</citation>.
  Basically, it represents an arbitrary sequence of octets using 64
  <quote>digits</quote> (<systemitem>A</systemitem> through <systemitem>Z</systemitem>, <systemitem>a</systemitem> through <systemitem>z</systemitem>, <systemitem>0</systemitem> through <systemitem>9</systemitem>, <systemitem>+</systemitem> and /, in order of increasing
  value). Three octets are represented as four digits (the <systemitem>=</systemitem>
  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
  <citation>rfc2045</citation>
for more detailed information.</para>

</listitem>
</varlistentry>
</variablelist>
 
<variablelist>
<varlistentry><term>Applications</term><listitem><para>are encoded using the <systemitem>OMA</systemitem> element. The
  application whose head is the &OM; object <math><msub><mi>e</mi><mn>0</mn></msub></math> and whose arguments
  are the &OM; objects <math><msub><mi>e</mi><mn>1</mn></msub></math>, <phrase>&#8230;</phrase>, <math><msub><mi>e</mi><mi>n</mi></msub></math> is encoded as <systemitem>&lt;OMA></systemitem>
  <math><msub><mi>C</mi><mn>0</mn></msub></math> <math><msub><mi>C</mi><mn>1</mn></msub></math><phrase>&#8230;</phrase> <math><msub><mi>C</mi><mi>n</mi></msub></math> <systemitem>&lt;/OMA></systemitem> where <math><msub><mi>C</mi><mi>i</mi></msub></math> is the encoding of
  <math><msub><mi>e</mi><mi>i</mi></msub></math>.</para>

<para>For example, <math><mi mathvariant="bold">application</mi><mo>(</mo><mi>sin</mi><mo>,</mo><mi>x</mi> <mo>)</mo></math> is encoded as:
<literallayout><![CDATA[<OMA>  
  <OMS cd="transc1" name="sin"/> 
  <OMV name="x"/>  
</OMA>]]></literallayout>
  provided that the symbol <systemitem>sin</systemitem> is defined to be a function
  symbol in a Content Dictionary named <systemitem>transc1</systemitem>.
</para>
</listitem>
</varlistentry>
<varlistentry><term>Binding</term><listitem><para>is encoded using the <systemitem>OMBIND</systemitem> element.  The binding
  by the &OM; object <math><mi>b</mi></math> of the &OM; variables <math><msub><mi>x</mi><mn>1</mn></msub></math>, <math><msub><mi>x</mi><mn>2</mn></msub></math>,
  <math><mi>&#8230;</mi></math>, <math><msub><mi>x</mi><mi>n</mi></msub></math> in the object <math><mi>c</mi></math> is encoded as <systemitem>&lt;OMBIND></systemitem> <math><mi>B</mi></math>
  <systemitem>&lt;OMBVAR></systemitem> <math><msub><mi>X</mi><mn>1</mn></msub></math> <math><mi>&#8230;</mi></math> <math><msub><mi>X</mi><mi>n</mi></msub></math> <systemitem>&lt;/OMBVAR></systemitem> <math><mi>C</mi></math> <systemitem>&lt;/OMBIND></systemitem> where <math><mi>B</mi></math>, <math><mi>C</mi></math>, and <math><msub><mi>X</mi><mi>i</mi></msub></math> are the encodings of <math><mi>b</mi></math>, <math><mi>c</mi></math>
  and <math><msub><mi>x</mi><mi>i</mi></msub></math>, respectively.</para>

<para>For instance the encoding of
  <math><mi mathvariant="bold">binding</mi>
       <mo>(</mo><mi>lambda</mi><mo>,</mo>
  <mi>x</mi><mo>,</mo><mi mathvariant="bold">application</mi>
     <mo>(</mo><mi>sin</mi><mo>,</mo> <mi>x</mi><mo>)</mo><mo>)</mo></math> is:
<literallayout><![CDATA[<OMBIND>
  <OMS cd="fns1" name="lambda"/>  
  <OMBVAR><OMV name="x"/></OMBVAR>  
  <OMA>
    <OMS cd="transc1" name="sin"/> 
    <OMV name="x"/>  
  </OMA>
</OMBIND>]]></literallayout></para>
  
<para>Binders are defined in  Content Dictionaries, in particular,
  the symbol <systemitem>lambda</systemitem> is defined in the Content Dictionary
  <systemitem>fns1</systemitem> for functions over functions.</para>
  
</listitem>
</varlistentry>
<varlistentry><term>Attributions</term><listitem><para>are encoded using the <systemitem>OMATTR</systemitem> element.  If
  the &OM; object <math><mi>e</mi></math> is attributed with (<math><msub><mi>s</mi><mn>1</mn></msub></math>, <math><msub><mi>e</mi><mn>1</mn></msub></math>), <phrase>&#8230;</phrase>, 
  (<math><msub><mi>s</mi><mi>n</mi></msub></math>, <math><msub><mi>e</mi><mi>n</mi></msub></math>) pairs (where <math><msub><mi>s</mi><mi>i</mi></msub></math> are the attributes), it is encoded
  as <systemitem>&lt;OMATTR></systemitem> <systemitem>&lt;OMATP></systemitem> <math><msub><mi>S</mi><mn>1</mn></msub></math> <math><msub><mi>C</mi><mn>1</mn></msub></math> <phrase>&#8230;</phrase> <math><msub><mi>S</mi><mi>n</mi></msub></math> <math><msub><mi>C</mi><mi>n</mi></msub></math> <systemitem>&lt;/OMATP></systemitem> <math><mi>E</mi></math> <systemitem>&lt;/OMATTR></systemitem> where <math><msub><mi>S</mi><mi>i</mi></msub></math> is the encoding of the
  symbol <math><msub><mi>s</mi><mi>i</mi></msub></math>, <math><msub><mi>C</mi><mi>i</mi></msub></math> of the object <math><msub><mi>e</mi><mi>i</mi></msub></math> and <math><mi>E</mi></math> is the encoding of
  <math><mi>e</mi></math>.</para>

<para>Examples are the use of attribution to decorate a group by its
  automorphism group:
<literallayout><![CDATA[<OMATTR>    
  <OMATP>
    <OMS cd="groups" name="automorphism_group" />  
    [..group-encoding..] 
  </OMATP>  
  [..group-encoding..] 
</OMATTR>]]></literallayout>
or to express the type of a variable:
<literallayout><![CDATA[<OMATTR>    
  <OMATP>
    <OMS cd="ecc" name="type" /> 
    <OMS cd="ecc" name="real" />
  </OMATP> 
  <OMV name="x" />
</OMATTR>]]></literallayout>
</para>

</listitem>
</varlistentry>
<varlistentry><term>Foreign Objects</term><listitem>
<para>
A special use of attributions is to associate non-&OM; data with an
&OM; object.  This is done using the
<systemitem>OMFOREIGN</systemitem> element.  The children of this
element must be well-formed &exml;.  For example the attribution of the
&OM; object 
  <math>
     <mi>sin</mi><mfenced><mi>x</mi></mfenced></math> with its
representation in Presentation MathML is:
<literallayout><![CDATA[<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>]]></literallayout>
Of course not everything has a natural XML encoding in this way and
often the contents of a <systemitem>OMFOREIGN</systemitem> will just
be data or some kind of encoded string.  For example the attribution
of the previous object with its <phrase>LaTeX</phrase> representation could be achieved
as follows:
<literallayout><![CDATA[<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>]]></literallayout>
For a discussion on the use of the <systemitem>encoding</systemitem>
attribute see <xref linkend="sec_compl_omforeign"/>.
</para>
</listitem>

</varlistentry>

<varlistentry>
 <term>Errors</term> 
 <listitem><para>are encoded using the <systemitem>OME</systemitem> element. The error whose
  symbol is <math><mi>s</mi></math> and whose arguments are the &OM; objects
or <xref linkend="derivedobj"/>
 <math><msub><mi>e</mi><mn>1</mn></msub></math>,
  <phrase>&#8230;</phrase>, <math><msub><mi>e</mi><mi>n</mi></msub></math> is encoded as <systemitem>&lt;OME></systemitem> <math><msub><mi>C</mi><mi>s</mi></msub></math> <math><msub><mi>C</mi><mn>1</mn></msub></math><phrase>&#8230;</phrase> <math><msub><mi>C</mi><mi>n</mi></msub></math> <systemitem>&lt;/OME></systemitem> where <math><msub><mi>C</mi><mi>s</mi></msub></math> is the encoding of <math><mi>s</mi></math> and <math><msub><mi>C</mi><mi>i</mi></msub></math> the encoding
  of <math><msub><mi>e</mi><mi>i</mi></msub></math>.</para>

<para>If an <systemitem>aritherror</systemitem> Content Dictionary contained a
  <systemitem>DivisionByZero</systemitem> symbol, then the object
  <math><mi mathvariant="bold">error</mi><mo>(</mo><mi>DivisionByZero</mi><mo>,</mo> <mi mathvariant="bold">application</mi>
  <mo>(</mo><mi>divide</mi><mo>,</mo> 
  <mi>x</mi><mo>,</mo> <mn>0</mn><mo>)</mo><mo>)</mo></math> would be encoded as follows:

<literallayout><![CDATA[<OME>
  <OMS cd="aritherror" name="DivisionByZero"/>  
  <OMA>
    <OMS cd="arith1" name="divide" />
    <OMV name="x"/>  
    <OMI> 0 </OMI>
  </OMA> 
 </OME>]]></literallayout></para>
  
<para>
If a <systemitem>mathml</systemitem> Content Dictionary contained an
  <systemitem>unhandled_csymbol</systemitem> symbol, then an &OM; to
MathML translator might return an error such as:
<literallayout><![CDATA[<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>]]></literallayout></para>

<para> Note that it is possible to embed fragments
of valid &OM; inside an <systemitem>OMFOREIGN</systemitem> element but that it
cannot contain invalid &OM;.  In addition, the arguments to an
<systemitem>OMERROR</systemitem> must be well-formed &exml;.  If an
application wishes to signal that the &OM; it has received is invalid or
is not well-formed then the offending data must be encoded as a string.
For example:
<literallayout><![CDATA[<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>]]></literallayout>
Note that the <quote>&lt;</quote> and <quote>&gt;</quote> characters have been escaped as is usual in
an &exml; document.
</para>

</listitem>
</varlistentry>

<varlistentry>
 <term>References</term>
 <listitem>
   <para>
     &OM; integers, symbols, variables, floating
     point numbers, character strings, bytearrays, applications, binding, attributions,
     error, and <xref linkend="foreignobj"/>s can
     also be encoded as an empty <systemitem>OMR</systemitem> element with an
     <systemitem>href</systemitem> attribute whose value is the value of a URI referencing
     an id attribute of an &OM; object of that type.  The &OM; element represented by this
     <systemitem>OMR</systemitem> reference is a copy of the &OM; element referenced
     <systemitem>href</systemitem> attribute. Note that this copy is
     <emphasis>structurally equal</emphasis>, but not identical to the element
     referenced. These URI references will often be relative, in
     which case they are resolved using the base URI of the document containing the
     &OM;.
   </para>

 <para>For instance, the &OM; object

 <math id="nestedap" display="block">
   <mrow>
     <mi mathvariant="bold">application</mi>
     <mrow>
       <mo fence="true">(</mo>
       <mrow>
         <mi>f</mi>
         <mo separator="true">,</mo>
         <mi mathvariant="bold">application</mi>
         <mrow>
           <mo fence="true">(</mo>
           <mrow>
             <mi>f</mi>
             <mo separator="true">,</mo>
             <mi mathvariant="bold">application</mi>
             <mrow>
               <mo fence="true">(</mo>
               <mrow><mi>f</mi><mo separator="true">,</mo><mi>a</mi><mo separator="true">,</mo><mi>a</mi></mrow>
               <mo fence="true">)</mo>
             </mrow>
             <mo separator="true">,</mo>
             <mi mathvariant="bold">application</mi>
             <mrow>
               <mo fence="true">(</mo>
               <mrow><mi>f</mi><mo separator="true">,</mo><mi>a</mi><mo separator="true">,</mo><mi>a</mi></mrow>
               <mo fence="true">)</mo>
             </mrow>
             <mo fence="true">)</mo>
           </mrow>
           <mo separator="true">,</mo>
           <mi mathvariant="bold">application</mi>
           <mrow>
             <mo fence="true">(</mo>
             <mrow>
               <mi>f</mi>
               <mo separator="true">,</mo>
               <mi mathvariant="bold">application</mi>
               <mrow>
                 <mo fence="true">(</mo>
                 <mrow><mi>f</mi><mo separator="true">,</mo><mi>a</mi><mo separator="true">,</mo><mi>a</mi></mrow>
                 <mo fence="true">)</mo>
               </mrow>
               <mo separator="true">,</mo>
               <mi mathvariant="bold">application</mi>
               <mrow>
                 <mo fence="true">(</mo>
                 <mrow><mi>f</mi><mo separator="true">,</mo><mi>a</mi><mo separator="true">,</mo><mi>a</mi></mrow>
                 <mo fence="true">)</mo>
               </mrow>
               <mo fence="true">)</mo>
             </mrow>
           </mrow>
           <mo fence="true">)</mo>
         </mrow>
       </mrow>
     </mrow>
   </mrow>
 </math>
</para>
<para>can be encoded in the &exml; encoding as either one of the
&exml; encodings given in <xref linkend="fig_shared_vs_unshared"/>
(and some intermediate versions as well).</para>
</listitem> </varlistentry> </variablelist>

<figure id="fig_shared_vs_unshared">
    <title>Shared vs. unshared representations</title>
    
 <literallayout><![CDATA[<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>                        </OMA>
</OMOBJ>                     </OMOBJ>]]>
</literallayout>
</figure>
</section>

<section id="sec_references">
<title>Some Notes on References</title>

<para>We say that an &OM; element dominates all its children and all elements
they dominate. An <systemitem>OMR</systemitem> element dominates its target,
i.e. the element that carries the <systemitem>id</systemitem> attribute pointed to
by the <systemitem>href</systemitem> attribute. For instance in the representation
in <xref linkend="fig_shared_vs_unshared"/>, the
<systemitem>OMA</systemitem> element with <systemitem>id="t1"</systemitem> and
also the second <systemitem>OMR</systemitem> dominate the
<systemitem>OMA</systemitem> element with <systemitem>id="t11"</systemitem>.
</para>

<section id="sec_acyclicity">
<title>An Acyclicity Constraint</title>

<para>The occurrences of the <systemitem>OMR</systemitem> element must obey the following global
<term id="acyc-constraint">acyclicity constraint</term>: An &OM; element may not dominate itself.</para>

<para>Consider for instance the following (illegal) &exml; representation
<literallayout><![CDATA[<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 href="#foo"/>
    </OMA> 
  </OMA>
</OMOBJ>]]>
</literallayout>
</para>

<para>Here, the <systemitem>OMA</systemitem> element with
<systemitem>id="foo"</systemitem> dominates its third child, which dominates the
<systemitem>OMR</systemitem> element, which dominates its target: the element with
<systemitem>id="foo"</systemitem>. So by transitivity, this element dominates itself, and
by the acyclicity constraint, it is not the &exml; representation of an &OM;
element. Even though it could be given the interpretation of the continued fraction
<math display="block">
 <mfrac>
   <mn>1</mn>
   <mrow>
     <mn>1</mn>
     <mo>+</mo>
     <mfrac>
       <mn>1</mn>
       <mrow>
         <mn>1</mn>
         <mo>+</mo>
         <mfrac><mn>1</mn><mi>...</mi></mfrac>
       </mrow>
     </mfrac>
   </mrow>
 </mfrac>
</math> this would correspond to an infinite tree of applications,
which is not admitted by the structure of &OM; objects described
in <xref linkend="cha_obj"/>.</para>

<para>Note that the acyclicity constraints is not restricted
to such simple cases, as the example in <xref linkend="fig_sharing_between"/>
shows.</para>

<figure id="fig_sharing_between">
    <title>Sharing between &OM; objects (A cycle of order <math><mn>2</mn></math>).</title>
<literallayout><![CDATA[<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 href="#baz"/>                     <OMR href="#bar"/>
  </OMA>                                 </OMA>
</OMOBJ>                               </OMOBJ>]]>
</literallayout></figure>

<para> Here, the <systemitem>OMA</systemitem> with
<systemitem>id="bar"</systemitem> dominates its third child, the
<systemitem>OMR</systemitem> with <systemitem>href="#baz"</systemitem>,
which dominates its target <systemitem>OMA</systemitem> with
<systemitem>id="baz"</systemitem>, which in turn dominates its third
child, the <systemitem>OMR</systemitem> with
<systemitem>href="#bar"</systemitem>, this finally dominates its
target, the original <systemitem>OMA</systemitem> element with
<systemitem>id="bar"</systemitem>. So this pair of &OM; objects
violates the acyclicity constraint and is not the &exml;
representation of an &OM; object.</para>
</section>


<section id="sec_sharing_bvars">
<title>Sharing and Bound Variables</title>

<para>Note that the <systemitem>OMR</systemitem> element is a
<term id="omr-syntactic">syntactic</term> referencing mechanism: an
<systemitem>OMR</systemitem> element stands for the exact &exml;
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 &exml;
representation: <literallayout><![CDATA[<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>]]>
</literallayout>
it represents the &OM; object
<math display="block">
  <mi mathvariant="bold">binding</mi>
  <mrow>
    <mo fence="true">(</mo>
    <mo>&#x003BB;</mo>
      <mo separator="true">,</mo>
    <mi>X</mi>
    <mo separator="true">,</mo>
    <mrow>
      <mi mathvariant="bold">application</mi>
      <mo fence="true">(</mo>
      <mi>f</mi>
      <mo separator="true">,</mo>
      <mi mathvariant="bold">binding</mi>
      <mrow>
        <mo fence="true">(</mo>
        <mo>&#x003BB;</mo>
        <mo separator="true">,</mo>
        <mi>X</mi>
        <mo separator="true">,</mo>
        <mrow>
          <mi mathvariant="bold">application</mi>
          <mo fence="true">(</mo>
          <mi>g</mi>
          <mo separator="true">,</mo>
          <mi>X</mi>
          <mo fence="true">)</mo>
        </mrow>
        <mo fence="true">)</mo>
      </mrow>
      <mo separator="true">,</mo>
      <mrow>
        <mi mathvariant="bold">application</mi>
        <mo fence="true">(</mo>
        <mi>g</mi>
        <mo separator="true">,</mo>
        <mi>X</mi>
        <mo fence="true">)</mo>
      </mrow>
      <mo fence="true">)</mo>
    </mrow>
    <mo fence="true"></mo>
  </mrow>
  </math> which has two sub-terms of the form
<math>
  <mi mathvariant="bold">application</mi>
  <mo fence="true">(</mo>
  <mi>g</mi>
  <mo separator="true">,</mo>
  <mi>X</mi>
  <mo fence="true">)
  </mo> </math>, one with <systemitem>id="orig"</systemitem> (the one explicitly
represented) and one with <systemitem>id="copy"</systemitem>, represented by the
<systemitem>OMR</systemitem> element. In the original, the variable
<math><mi>X</mi></math> is bound by the <emphasis>outer</emphasis>
<systemitem>OMBIND</systemitem> element, and in the copy, the variable
<math><mi>X</mi></math> is bound by the <emphasis>inner</emphasis>
<systemitem>OMBIND</systemitem> element. We say that the inner
<systemitem>OMBIND</systemitem> has captured the variable <math><mi>X</mi></math>.
</para>

<para>It is well-known that variable capture does not conserve semantics. For
  instance, we could use <math><mi>&#x003B1;</mi></math>-conversion to rename the inner occurrence of
  <math><mi>X</mi></math> into, say, 
  <math><mi>Y</mi></math> arriving at the (same) object
<math display="block">
  <mi mathvariant="bold">binding</mi>
  <mrow>
    <mo fence="true">(</mo>
    <mo>&#x003BB;</mo>
      <mo separator="true">,</mo>
    <mi>X</mi>
    <mo separator="true">,</mo>
    <mrow>
      <mi mathvariant="bold">application</mi>
      <mo fence="true">(</mo>
      <mi>f</mi>
      <mo separator="true">,</mo>
      <mi mathvariant="bold">binding</mi>
      <mrow>
        <mo fence="true">(</mo>
        <mo>&#x003BB;</mo>
        <mo separator="true">,</mo>
        <mi mathcolor="red">Y</mi>
        <mo separator="true">,</mo>
        <mrow>
          <mi mathvariant="bold">application</mi>
          <mo fence="true">(</mo>
          <mi>g</mi>
          <mo separator="true">,</mo>
          <mi mathcolor="red">Y</mi>
          <mo fence="true">)</mo>
        </mrow>
        <mo fence="true">)</mo>
      </mrow>
      <mo separator="true">,</mo>
      <mrow>
        <mi mathvariant="bold">application</mi>
        <mo fence="true">(</mo>
        <mi>g</mi>
        <mo separator="true">,</mo>
        <mi>X</mi>
        <mo fence="true">)</mo>
      </mrow>
      <mo fence="true">)</mo>
    </mrow>
    <mo fence="true">)</mo>
  </mrow>
  </math>
 Using references that
capture variables in this way can easily lead to representation errors, and is not
  recommended.
</para>
</section>
</section>

<section id="xmldoc">
<title>Embedding &OM; in &exml; Documents</title>

     
<para>The above encoding of &exml; encoded &OM; specifies the grammar to be
used in files that encode a single &OM; object, and specifies the
character streams that a conforming &OM; application should be able
to accept or produce.</para>

<para>When embedding &exml; encoded &OM; objects into a larger &exml; document
one may wish, or need, to use other &exml; features. For example use of
extra &exml; attributes to specify &exml; Namespaces&#160;<citation>xmlns</citation>
or <systemitem>xml:lang</systemitem> attributes to specify the language used in
strings&#160;<citation>xml_04</citation>. 
</para>

<para>If such &exml; features are used then the &exml; application controlling the
document must, if passing the &OM; fragment to an &OM; application,
remove any such extra attributes and must ensure that the
fragment is encoded according to the schema specified above.</para>
</section>
</section>

<section id="sec_binary">
<title>The Binary Encoding</title>

<para>The binary encoding was essentially designed to be more compact than
the &exml; encodings, so that it can be more efficient if large
amounts of data are involved. For the current encoding, we tried to
keep the right balance between compactness, speed of encoding and
decoding and simplicity (to allow a simple specification and easy
implementations).</para>

<section id="sec_binary_grammar">
<title>A Grammar for the Binary Encoding</title>

     

<figure id="fig_bin-enc">
    <title>Grammar of the binary encoding of &OM; objects.</title>
    
    <informaltable>
      <tgroup cols="6">
        <tbody>
          <row>
            <entry>start </entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [24] object [25] </entry>
            <entry>|</entry>
            <entry>
	      [24+64]
	      [<math><mi>m</mi></math>]
              [<math><mi>n</mi></math>]
	      object [25]</entry>
          </row>
          
          <row>
            <entry>object </entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> basic </entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> compound</entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry>cdbase</entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry>foreign</entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry>reference</entry>
          </row>
          
          <row>
            <entry>basic</entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> integer </entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> float</entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> variable</entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> symbol</entry>
          </row>

          <row>
            <entry/>
            <entry>|</entry>
            <entry> string</entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> bytearray</entry>
          </row>
          
          <row>
            <entry>integer </entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [1] [_] </entry>
            <entry>|</entry>
            <entry> [1+64]
              [<math><mi>n</mi></math>]
              id:<math><mi>n</mi></math>
              [_]
            </entry>
          </row>

          <row>
            <entry/>
            <entry><math><mo>|</mo></math></entry>
            <entry> [1+32] [_] </entry>
            <entry/>
            <entry/>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [1+128] {_} </entry>
            <entry>|</entry>
            <entry> [1+64+128]
              {<math><mi>n</mi></math>}
              id:<math><mi>n</mi></math>
              {_}
            </entry>
          </row>

          <row>
            <entry/>
            <entry>|</entry>
            <entry> [1+32+128] {_} </entry>
            <entry/>
            <entry/>
          </row>

          <row>
            <entry/>
            <entry>|</entry>
            <entry> [2]
              [<math><mi>n</mi></math>]
              [_] digits:<math><mi>n</mi></math>
            </entry>
            <entry>|</entry>
            <entry> [2+64]
              [<math><mi>n</mi></math>]
              [<math><mi>m</mi></math>]
              [_] digits:<math><mi>n</mi></math>
              id:<math><mi>m</mi></math>
            </entry>
          </row>

          <row>
            <entry/>
            <entry>|</entry>
            <entry> [2+32]
              [<math><mi>n</mi></math>]
              [_] digits:<math><mi>n</mi></math>
            </entry>
            <entry/>
            <entry/>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [2+128]
              {<math><mi>n</mi></math>}
              [_] digits:<math><mi>n</mi></math>
            </entry>
            <entry>|</entry>
            <entry> [2+64+128]
              {<math><mi>n</mi></math>}
              {<math><mi>n</mi></math>}
              [_]
              digits:<math><mi>n</mi></math>
              id:<math><mi>n</mi></math>
            </entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [2+32+128]
              {<math><mi>n</mi></math>}
              [_] digits:<math><mi>n</mi></math>
            </entry>
            <entry/>
            <entry/>
          </row>
          
          <row>
            <entry>float </entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [3] {_}{_} </entry>
            <entry>|</entry>
            <entry> [3+64]
              [<math><mi>n</mi></math>]
              id:<math><mi>n</mi></math>
              {_}{_}</entry>
          </row>
          
          <row>
            <entry/>
            <entry/>
            <entry/>
            <entry>|</entry>
            <entry> [3+64+128]
              {<math><mi>n</mi></math>}
              id:<math><mi>n</mi></math>
              {_}{_}</entry>
          </row>
          
          <row>
            <entry>variable </entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [5]
              [<math><mi>n</mi></math>]
              varname:<math><mi>n</mi></math>
            </entry>
            <entry>|</entry>
            <entry> [5+64]
              [<math><mi>n</mi></math>]
              [<math><mi>m</mi></math>]
              varname:<math><mi>n</mi></math>
              id:<math><mi>m</mi></math>
            </entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [5+128]
              {<math><mi>n</mi></math>}
              varname:<math><mi>n</mi></math>
            </entry>
            <entry>|</entry>
            <entry> [5+64+128]
              {<math><mi>n</mi></math>}
              {<math><mi>m</mi></math>}
              varname:<math><mi>n</mi></math>
              id:<math><mi>m</mi></math>
            </entry>
          </row>
          
          <row>
            <entry>symbol</entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [8]
              [<math><mi>n</mi></math>]
              [<math><mi>m</mi></math>]
              cdname:<math><mi>n</mi></math>
              symbname:<math><mi>m</mi></math>
            </entry>
            <entry>|</entry>
            <entry> [8+64]
              [<math><mi>n</mi></math>]
              [<math><mi>m</mi></math>]
              [<math><mi>k</mi></math>]
              cdname:<math><mi>n</mi></math>
              symbname:<math><mi>m</mi></math>
              id:<math><mi>k</mi></math>
            </entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [8+128]
              {<math><mi>n</mi></math>}
              {<math><mi>m</mi></math>}
              cdname:<math><mi>n</mi></math>
              symbname:<math><mi>m</mi></math>
            </entry>
            <entry>|</entry>
            <entry> [8+64+128]
              {<math><mi>n</mi></math>}
              {<math><mi>m</mi></math>}
              {<math><mi>k</mi></math>}
              cdname:<math><mi>n</mi></math>
              symbname:<math><mi>m</mi></math>
              id:<math><mi>k</mi></math></entry>
          </row>
          
          <row>
            <entry>string </entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [6]
              [<math><mi>n</mi></math>]
              <phrase>bytes</phrase>:<math><mi>n</mi></math>
            </entry>
            <entry>|</entry>
            <entry> [6+64]
              [<math><mi>n</mi></math>]
              <phrase>bytes</phrase>:<math><mi>n</mi></math>
            </entry>
          </row>
          
          <row>
            <entry/>
            <entry><math><mo>|</mo></math></entry>
            <entry> [6+32]
              [<math><mi>n</mi></math>]
              <phrase>bytes</phrase>:<math><mi>n</mi></math>
            </entry>
            <entry/>
            <entry/>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [6+128]
              {<math><mi>n</mi></math>}
              <phrase>bytes</phrase>:<math><mi>n</mi></math>
            </entry>
            <entry>|</entry>
            <entry> [6+64+128]
              {<math><mi>n</mi></math>}
              {<math><mi>m</mi></math>}
              <phrase>bytes</phrase>:<math><mi>n</mi></math>
              id:<math><mi>m</mi></math>
            </entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [6+32+128]
              {<math><mi>n</mi></math>}
              <phrase>bytes</phrase>:<math><mi>n</mi></math>
            </entry>
            <entry/>
            <entry/>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [7]
              [<math><mi>n</mi></math>]
              <phrase>bytes</phrase>:<math><mn>2</mn><mi>n</mi></math>
            </entry>
            <entry>|</entry>
            <entry> [7+64]
              [<math><mi>n</mi></math>]
              [<math><mi>m</mi></math>]
              <phrase>bytes</phrase>:<math><mn></mn><mi>n</mi></math>
              id:<math><mi>m</mi></math>
            </entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [7+32]
              [<math><mi>n</mi></math>]
              <phrase>bytes</phrase>:<math><mn>2</mn><mi>n</mi></math>
            </entry>
            <entry/>
            <entry/>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [7+128]
              {<math><mi>n</mi></math>}
              <phrase>bytes</phrase>:<math><mn>2</mn><mi>n</mi></math>
            </entry>
            <entry>|</entry>
            <entry> [7+64+128]
              {<math><mi>n</mi></math>}
              {<math><mi>m</mi></math>}
              <phrase>bytes</phrase>:<math><mn>2</mn><mi>n</mi></math>
              id:<math><mi>m</mi></math>
            </entry>
          </row>
          
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [7+32+128]
              {<math><mi>n</mi></math>}
              <phrase>bytes</phrase>:<math><mn>2</mn><mi>n</mi></math>
            </entry>
            <entry/>
            <entry/>
          </row>
          
          <row>
            <entry>bytearray </entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [4]
              [<math><mi>n</mi></math>]
              bytes:<math><mi>n</mi></math>
            </entry>
            <entry>|</entry>
            <entry> [4+64]
              [<math><mi>n</mi></math>]
              [<math><mi>m</mi></math>]
              bytes:<math><mi>n</mi></math>
              id:<math><mi>m</mi></math>
            </entry>
          </row>
          
          <row>
            <entry/>
            <entry><math><mo>|</mo></math></entry>
            <entry> [4+32]
              [<math><mi>n</mi></math>]
              bytes:<math><mi>n</mi></math>
            </entry>
            <entry/>
            <entry/>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [4+128]
              {<math><mi>n</mi></math>}
              bytes:<math><mi>n</mi></math>
            </entry>
            <entry>|</entry>
            <entry> [4+64+128]
              {<math><mi>n</mi></math>}
              {<math><mi>m</mi></math>}
              bytes:<math><mi>n</mi></math>
              id:<math><mi>m</mi></math>
            </entry>
          </row>
          
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [4+32+128]
              {<math><mi>n</mi></math>}
              bytes:<math><mi>n</mi></math>
            </entry>
            <entry/>
            <entry/>
          </row>
          
          <row>
            <entry>cdbase</entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [9]
              [<math><mi>n</mi></math>]
              uri:<math><mi>n</mi></math>
	      object
            </entry>
	  </row>

	  <row>
            <entry/>
            <entry>|</entry>
            <entry> [9+128]
              {<math><mi>n</mi></math>}
              uri:<math><mi>n</mi></math>
	      object
            </entry>
          </row>

          <row>
            <entry>foreign</entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [12]
              [<math><mi>n</mi></math>]
              [<math><mi>m</mi></math>]
              bytes:<math><mi>n</mi></math>
              bytes:<math><mi>m</mi></math>
            </entry>
            <entry>|</entry>
            <entry> [12+64]
              [<math><mi>n</mi></math>]
              [<math><mi>m</mi></math>]
              [<math><mi>k</mi></math>]
              bytes:<math><mi>n</mi></math>
              bytes:<math><mi>m</mi></math>
              id:<math><mi>k</mi></math>
            </entry>
          </row>
          
          <row>
            <entry/>
            <entry><math><mo>|</mo></math></entry>
            <entry> [12+32]
              [<math><mi>n</mi></math>]
              [<math><mi>m</mi></math>]
              bytes:<math><mi>n</mi></math>
              bytes:<math><mi>m</mi></math>
            </entry>
            <entry/>
            <entry/>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [12+128]
              {<math><mi>n</mi></math>}
              {<math><mi>m</mi></math>}
              bytes:<math><mi>n</mi></math>
              bytes:<math><mi>m</mi></math>
            </entry>
            <entry>|</entry>
            <entry> [12+64+128]
              {<math><mi>n</mi></math>}
              {<math><mi>m</mi></math>}
              {<math><mi>k</mi></math>}
              bytes:<math><mi>n</mi></math>
              bytes:<math><mi>m</mi></math>
              id:<math><mi>k</mi></math>
            </entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [12+32+128]
              {<math><mi>n</mi></math>}
              {<math><mi>m</mi></math>}
              bytes:<math><mi>n</mi></math>
              bytes:<math><mi>m</mi></math>
            </entry>
            <entry/>
            <entry/>
          </row>
          
          <row>
            <entry>compound</entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry>application</entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry>binding</entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry>attribution</entry>
          </row>

          <row>
            <entry/>
            <entry>|</entry>
            <entry>error</entry>
          </row>
          
          <row>
            <entry>application</entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [16] object objects [17] </entry>
            <entry>|</entry>
            <entry> [16+64]
              [<math><mi>m</mi></math>]
              id:<math><mi>m</mi></math>
              object objects [17]
            </entry>
          </row>
          
          <row>
            <entry/>
            <entry/>
            <entry/>
            <entry>|</entry>
            <entry> [16+64+128]
              {<math><mi>m</mi></math>}
              id:<math><mi>m</mi></math>
              object objects [17]
            </entry>
          </row>
          
          <row>
	    <entry>binding</entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [26] object bvars object [27] </entry>
            <entry>|</entry>
            <entry> [26+64]
              [<math><mi>m</mi></math>]
              id:<math><mi>m</mi></math>
              object bvars object [27]
            </entry>
          </row>
          
          <row>
	    <entry/>
            <entry/>
            <entry/>
            <entry>|</entry>
            <entry> [26+64+128]
              {<math><mi>m</mi></math>}
              id:<math><mi>m</mi></math>
              object bvars object [27]
            </entry>
          </row>
          
          <row>
	    <entry>attribution</entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [18] attrpairs object [19] </entry>
            <entry>|</entry>
            <entry> [18+64]
              [<math><mi>m</mi></math>]
              id:<math><mi>m</mi></math>
              attrpairs object [19]
            </entry>
          </row>
          
          <row>
	    <entry/>
            <entry/>
            <entry/>
            <entry>|</entry>
            <entry> [18+64+128]
              {<math><mi>m</mi></math>}
              id:<math><mi>m</mi></math>
              attrpairs object [19]
            </entry>
          </row>
          
          <row>
	    <entry>error</entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [22] symbol objects [23] </entry>
            <entry>|</entry>
            <entry> [22+64]
              [<math><mi>m</mi></math>]
              id:<math><mi>m</mi></math>
              symbol objects [23]</entry>
          </row>
          
          <row>
	    <entry/>
            <entry/>
            <entry/>
            <entry>|</entry>
            <entry> [22+64+128]
              {<math><mi>m</mi></math>}
              id:<math><mi>m</mi></math>
              symbol objects [23]</entry>
          </row>
          
          <row>
            <entry>attrpairs </entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [20] pairs [21] </entry>
            <entry>|</entry>
            <entry> [20+64]
              [<math><mi>m</mi></math>]
              id:<math><mi>m</mi></math>
              pairs [21]
            </entry>
          </row>
          
          <row>
            <entry/>
            <entry/>
            <entry/>
            <entry>|</entry>
            <entry> [20+64+128]
              {<math><mi>m</mi></math>}
              id:<math><mi>m</mi></math>
              pairs [21]
            </entry>
          </row>
          
          <row>
            <entry>pairs </entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> symbol object</entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> symbol object pairs</entry>
          </row>
          
          <row>
            <entry>bvars </entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [28] vars [29] </entry>
            <entry>|</entry>
            <entry> [28+64]
              [<math><mi>m</mi></math>]
              id:<math><mi>m</mi></math>
              vars [29]
            </entry>
          </row>
          
          <row>
            <entry/>
            <entry/>
            <entry/>
            <entry>|</entry>
            <entry> [28+64+128]
              {<math><mi>m</mi></math>}
              id:<math><mi>m</mi></math>
              vars [29]
            </entry>
          </row>
          
          <row>
            <entry>vars </entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry>
	      <emphasis>empty</emphasis>
	    </entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> attrvar vars</entry>
          </row>
          
          <row>
            <entry>attrvar </entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> variable</entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [18] attrpairs attrvar [19] </entry>
            <entry>|</entry>
            <entry> [18+64]
              [<math><mi>m</mi></math>]
              id:<math><mi>m</mi></math>
              attrpairs attrvar [19]
            </entry>
          </row>
          
          <row>
            <entry/>
            <entry/>
            <entry/>
            <entry>|</entry>
            <entry> [18+64+128]
              {<math><mi>m</mi></math>}
              id:<math><mi>m</mi></math>
              attrpairs attrvar [19]
            </entry>
          </row>
          
          <row>
            <entry>objects </entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> <emphasis>empty</emphasis> </entry>
          </row>

          <row>
            <entry/>
            <entry>|</entry>
            <entry> object objects</entry>
          </row>
          
          <row>
	    <entry>reference</entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry>internal_reference</entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry>external_reference</entry>
          </row>
          
          <row>
            <entry>internal_reference </entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [30] [_] </entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [30+128] {_}</entry>
          </row>
          
          <row>
            <entry>external_reference </entry>
            <entry><math><mo>&longrightarrow;</mo></math></entry>
            <entry> [31]
              [<math><mi>n</mi></math>]
              uri:<math><mi>n</mi></math>
            </entry>
          </row>
          
          <row>
            <entry/>
            <entry>|</entry>
            <entry> [31+128]
              {<math><mi>n</mi></math>}
              uri:<math><mi>n</mi></math>
            </entry>
          </row>
        </tbody>
      </tgroup>
    </informaltable>
  </figure>
  
  <para><xref linkend="fig_bin-enc"/> gives a grammar for the binary
    encoding  (<quote>start</quote> is the start
      symbol).</para>
  <para>The following conventions are used in this section:
    [<math><mi>n</mi></math>] denotes a byte whose value is the integer
    <math><mi>n</mi></math> (<math><mi>n</mi></math> can range from 0 to 255),
    {<math><mi>m</mi></math>} denotes four bytes representing the (unsigned) integer
    <math><mi>m</mi></math> in network byte order, [_] denotes an arbitrary byte, {_}
    denotes an arbitrary sequence of four bytes.
    Finally,
    <emphasis>empty</emphasis> stands for the empty list of tokens.
  </para>
  
  <para><emphasis>xxxx</emphasis>:<math><mi>n</mi></math>, where <emphasis>xxxx</emphasis>
  is one of <emphasis>symbname</emphasis>, <emphasis>cdname</emphasis>,
  <emphasis>varname</emphasis>, <emphasis>uri</emphasis>, <emphasis>id</emphasis>,
  <emphasis>digits</emphasis>, or <emphasis>bytes</emphasis> denotes a sequence of
  <math><mi>n</mi></math> bytes that conforms to the constraints on
  <emphasis>xxxx</emphasis> strings. For instance, for <emphasis>symbname</emphasis>,
  <emphasis>varname</emphasis>, or <emphasis>cdname</emphasis> this is the regular
  expression described in <xref linkend="sec_names"/>, for
  <emphasis>uri</emphasis> it is the grammar for IRIs in
  <citation>IETF3987</citation>.
  </para>
</section>

<section id="sec_bin-desc">
  <title>Description of the Grammar</title>
  
<para>An &OM; 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&#160;25). These are similar to
the <systemitem>&lt;OMOBJ></systemitem> and <systemitem>&lt;/OMOBJ></systemitem> tags of
the &exml; encoding. Objects with start token [88]
  have two additional bytes <math><mi>m</mi></math> and <math><mi>n</mi></math>
that characterize the version
(<math><mrow><mi>m</mi><mo>.</mo><mi>n</mi></mrow></math>) of the encoding
directly after the start token. This is similar to <systemitem>&lt;OMOBJ
  version="m.n"></systemitem></para> 

<para>The encoding of each kind of &OM; object begins with a tag that is a single byte,
holding a <phrase role="sl">token identifier</phrase>  that describes the kind of object, 
two flags, and a status bit.
The identifier is stored in the first five
  bits (1 to 5). Bit 6 is used as a 
  <phrase role="sl">status bit</phrase> which is currently only used for managing
  streaming of some basic objects. Bits 7 and 8 are the <phrase role="sl">sharing
    flag</phrase> and the <phrase role="sl">long flag</phrase>. The sharing flag
  indicates that the encoded object may be shared in another (part of an) object
  somewhere else (see <xref linkend="sec_sharing_references"/>). Note that if the sharing
  flag is set (in the right column of the grammar in 
  <xref linkend="fig_bin-enc"/>, then the encoding includes a representation of
  an identifier that serves as the target of a reference (internal with token
  identifier 30 or external with token identifier 31). If the long
  flag is set, this signifies that  the names, strings, and data fields in the
  encoded &OM; object are longer than 255 bytes or characters.
</para>

<para>The concept of structure sharing in &OM; encodings and
  in particular the sharing bit in the binary encoding has been
  introduced in &OM;&#160;2 (see section <xref linkend="sec_sharing_references"/> for
  details). The binary encoding in &OM;&#160;2 leaves the tokens with sharing flag 0
  unchanged to ensure &OM;&#160;1 compatibility. To make use of functionality like
  the version attribute on the &OM; object
  introduced in &OM;&#160;2, the tokens with sharing flag 1 should be used.</para>

<para>To facilitate the streaming of &OM; objects, some basic objects (integers, strings,
bytearrays, and <xref linkend="foreignobj"/>s) 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). In <xref linkend="fig_bin-enc_stream"/> we have
represented an integer that is split up into three packets.  </para>

<para>Here is a description of the binary encodings of every kind of &OM; object:

<variablelist>
<varlistentry>
  <term>Integers</term><listitem><para>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 <systemitem>0x01 0x10</systemitem>.  Integers between
      <math>
	<msup>
          <mn>-2</mn>
          <mn>31</mn>
        </msup>
      </math>
      (<math><mn>-2147483648</mn></math>) and
      <math>
        <msup>
          <mn>2</mn>
          <mn>31</mn>
        </msup>
        <mo>-</mo>
        <mn>1</mn>
      </math>
      (<math><mn>2147483647</mn></math>) are encoded as
      the small integer tag with the long flag set followed by the integer
      encoded in four bytes (network byte order:
      the most significant byte comes first). For example, 128 is encoded
      as <systemitem>0x81</systemitem> <systemitem>0x00000080</systemitem>.  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 <systemitem>+</systemitem>
      (<systemitem>0x2B</systemitem>) or <systemitem>-</systemitem>
      (<systemitem>0x2D</systemitem>) for the sign or-ed with the base mask bits
      that can be <systemitem>0</systemitem> for base 10 
      or <systemitem>0x40</systemitem> for base 16 or
	<systemitem>0x80</systemitem> for <quote>base 256</quote>.  It is
      followed by the sequence of digits (as 
      characters for bases 10 and 16 as in the &exml;
	encoding, and as bytes for base 256) in their natural
      order.  For example, the decimal number 8589934592
      (<math><msup><mn>2</mn><mn>33</mn></msup></math>) is encoded  as
      <systemitem>0x02 
        0x0A 0x2B 0x38 0x35 0x38 0x39 0x39 0x33 0x34 0x35 0x39 0x32</systemitem>
      and the
      hexadecimal number
      <systemitem>xf&zsp;f&zsp;f&zsp;f&zsp;f&zsp;f&zsp;f1</systemitem> is 
      encoded as <systemitem>0x02 0x08
	0x6b 0x66 0x66 0x66 0x66 0x66 0x66 0x66 0x31</systemitem>
       in the base 16
      character encoding and as <systemitem>0x02 0x04 0xab 
	0xFF 0xFF 0xFF 0xF1</systemitem> in the byte encoding (base 256).</para>
    <para> Note that it is    
      permitted to encode a <quote>small</quote> integer in any <quote>bigger</quote>
      format.</para>
    <para>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 <math><msup><mn>2</mn><mn>7</mn></msup></math> (most
      significant first). The case of token identifiers 129, 161, and 193 is analogous
      with digits of base <math><msup><mn>2</mn><mn>31</mn></msup></math>. 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.</para>

    <figure id="fig_bin-enc_stream">
      <title>Streaming a large Integer in the Binary Encoding.</title>

      <informaltable>
	<tgroup cols="7">
	  <thead>
	    <row>
	      <entry>Byte</entry><entry>Hex</entry><entry>Meaning</entry>
              <entry>&#160;&#160;&#160;</entry>
	      <entry>Byte</entry><entry>Hex</entry><entry>Meaning</entry>
	    </row>
	  </thead>
	  <tbody>
	    <row>
	      <entry>1</entry><entry>22</entry><entry>begin streamed big integer tag</entry>
              <entry>&#160;&#160;&#160;</entry>
	      <entry>7</entry><entry>2B</entry><entry>sign + (disregarded)</entry>
	    </row>
	    <row>
	      <entry>2</entry><entry>FF</entry><entry>255 digits in packet</entry>
              <entry>&#160;&#160;&#160;</entry>
	      <entry>8</entry><entry>...</entry><entry> the 255 digits as characters</entry>
	    </row>
	    <row>
	      <entry>3</entry><entry>2B</entry><entry>sign +</entry>
              <entry>&#160;&#160;&#160;</entry>
	      <entry>9</entry><entry>2</entry><entry>begin final big integer tag</entry>
	    </row>
	    <row>
	      <entry>4</entry><entry>...</entry><entry> the 255 digits as characters</entry>
              <entry>&#160;&#160;&#160;</entry>
	      <entry>10</entry><entry>42</entry><entry>68 digits in packet</entry>
	    </row>
	    <row>
	      <entry>5</entry><entry>22</entry><entry>begin streamed big integer tag</entry>
              <entry>&#160;&#160;&#160;</entry>
	      <entry>11</entry><entry>2B</entry><entry>sign + (disregarded)</entry>
	    </row>
	    <row>
	      <entry>6</entry><entry>FF</entry><entry>255 digits in packet</entry>
              <entry>&#160;&#160;&#160;</entry>
	      <entry>12</entry><entry>...</entry><entry> the 68 digits as characters</entry>
	    </row>
	  </tbody>
	</tgroup>
      </informaltable>
    </figure>
</listitem>
</varlistentry>

<varlistentry>
<term>Symbols</term>
<listitem><para>are encoded as the symbol tags
    (token identifier 8) with the long flag
    set if the maximum of the length in bytes in the <acronym>utf-8</acronym> encoding of the Content Dictionary name
    or the symbol name is greater than or equal to 256. The symbol tag is  followed by the
  length in bytes in the <acronym>utf-8</acronym> encoding of the Content Dictionary name, the symbol
  name, and the <systemitem>id</systemitem> (if the shared bit was set) as a byte
  (if the long flag was not set) or a four byte integer (in network byte
  order). These are followed by the bytes of the <acronym>utf-8</acronym> encoding of the Content
  Dictionary name, the symbol name, and the <systemitem>id</systemitem>.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term>Variables</term>
<listitem><para>are encoded using the variable tags
    (token identifiers 5) with the long
  flag set if the number of bytes in the <acronym>utf-8</acronym> encoding of the variable name is
  greater than or equal to 256.  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 <systemitem>0x05
    0x01 0x78</systemitem>.</para>
</listitem>
</varlistentry>

<varlistentry>
<term>Floating-point number</term>
<listitem><para>are encoded using the floating-point
  number tags (token identifier 3) followed by eight bytes that are the IEEE 754
  representation&#160;<citation>ieee754_85</citation>, most significant bytes first.
For example, 
  <math><mn>1</mn><mo>&#215;</mo>
	  <msup><mn>10</mn><mn>-10</mn></msup></math>
  is encoded as <systemitem>0x03 3ddb7cdfd9d7bdbb</systemitem>.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term>Character string</term>
<listitem><para>are encoded in two ways depending on whether
  the string is encoded in
  <acronym>utf-16</acronym> or <acronym>iso-8859-1</acronym>
  (<acronym>latin-1</acronym>).
  In the case of <acronym>latin-1</acronym> 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
  <acronym>utf-16</acronym>, it is encoded as the <acronym>utf-16</acronym> 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
  <acronym>utf-16</acronym> 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
  (<acronym>utf-16</acronym> encoded  Unicode).</para>

<para>Sequences of string packets are assumed to have the
  same encoding for every packet. They are assembled into strings by 
      concatenating the strings in the packets in sequence order.</para>

</listitem>
</varlistentry>

<varlistentry>
  <term>Bytearrays</term>
  <listitem><para>are encoded using the bytearray 
  tags (token identifier 4) with the
      long flag set if the number of 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.</para>

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

  </listitem>
</varlistentry>

<varlistentry>
  <term>Foreign Objects</term>
  <listitem>
    <para>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 and the
      streaming bit set for dividing it up into packets. Then, there is the number
      <math><mi>n</mi></math> of bytes used to encode the encoding, and the
      number <math><mi>m</mi></math> of bytes used to encode the foreign
      object. <math><mi>n</mi></math> and <math><mi>m</mi></math> are represented as a
      byte (if the long flag was not set) or a four byte integer (in network byte
      order). These numbers are followed by an <math><mi>n</mi></math>-byte
      representation of the encoding attribute and an <math><mi>m</mi></math> byte
      sequence of bytes encoding the foreign object in their normal order (we call these
      the payload bytes). The encoding attribute is encoded in <acronym>utf-8</acronym>.</para>
    <para>Sequences of foreign object
      packets are assembled into foreign objects by concatenating the payload bytes in
      the packets in sequence order.</para>
     <para>Note that the foreign object is encoded as a stream of
      bytes, not a stream of characters. Character based formats
  (including XML based formats) should be encoded in <acronym>utf-8</acronym> to produce
  a stream of bytes to use as the payload of the foreign object.</para>
  </listitem>
</varlistentry>

<varlistentry>
  <term>cdbase scopes</term>
  <listitem>
    <para>are encoded using the token identifier 9. The purpose of these
      scoping devices is to associate a <systemitem>cdbase</systemitem> with an
      object. The start token [9] (or [137] if the long flag is set) is followed
      by a single-byte (or 4-byte- if the long flag is set) number
      <math><mi>n</mi></math> and then by a sequence of <math><mi>n</mi></math>
      bytes that represent the value of the <systemitem>cdbase</systemitem>
      attribute (a URI) in <acronym>utf-8</acronym> encoding. This is then followed by the binary
      encoding of a single object: the object over which this
  <systemitem>cdbase</systemitem> attribute has scope. </para>
  </listitem>
</varlistentry>


<varlistentry>
  <term>Applications</term>
  <listitem><para>are encoded using the application tags (token identifiers 16 and 17). More
  precisely, the application of <math><msub><mi>E</mi><mn>0</mn></msub></math> to
  <math><msub><mi>E</mi><mn>1</mn></msub></math><phrase>&#8230;</phrase>
  <math><msub><mi>E</mi><mi>n</mi></msub></math> is encoded
  using the application tags (token identifier 16), the sequence of the encodings of 
  <math><msub><mi>E</mi><mn>0</mn></msub></math> to
  <math><msub><mi>E</mi><mi>n</mi></msub></math> and the end application tags
  (token identifier 17).</para> 
</listitem>
</varlistentry>

<varlistentry> 
  <term>Bindings</term>
  <listitem><para>are encoded using the binding
 tags (token identifiers 26 and 27). More precisely,
 the binding by <math><mi>B</mi></math> of variables
 <math><msub><mi>V</mi><mn>1</mn></msub></math><phrase>&#8230;</phrase>
 <math><msub><mi>V</mi><mi>n</mi></msub></math> in <math><mi>C</mi></math> is
 encoded as the binding tag (token
 identifier 26), followed by the encoding of <math><mi>B</mi></math>,
 followed by the binding variables tags (token
 identifier 28), followed by the encodings of the variables
 <math><msub><mi>V</mi><mn>1</mn></msub></math> <phrase>&#8230;</phrase>
 <math><msub><mi>V</mi><mi>n</mi></msub></math>, followed by the end binding
 variables tags (token identifier 29),
 followed by the encoding of <math><mi>C</mi></math>, followed by the end binding
 tags (token identifier 27).</para>
 </listitem> </varlistentry>

<varlistentry>
 <term>Attributions</term>
 <listitem><para>are encoded using the attribution
     tags (token identifiers 18 and 19). More
     precisely, attribution of the object <math><mi>E</mi></math> with
     (<math><msub><mi>S</mi><mn>1</mn></msub></math>,
     <math><msub><mi>E</mi><mn>1</mn></msub></math>),
     <math><mi>&#8230;</mi></math>
     (<math><msub><mi>S</mi><mi>n</mi></msub></math>,
     <math><msub><mi>E</mi><mi>n</mi></msub></math>) pairs (where
     <math><msub><mi>S</mi><mi>i</mi></msub></math> are the attributes) is 
     encoded as the attributed object tag (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 tag (token identifier 21),
     followed by the encoding of <math><mi>E</mi></math>, followed by the end 
     attributed object tag (token identifier 19).</para>
 </listitem>
</varlistentry>

<varlistentry>
  <term>Errors</term>
  <listitem><para>are encoded using the error tags
      (token identifiers 22 and 23). More precisely, 
  <math><msub><mi>S</mi><mn>0</mn></msub></math> applied to
  <math><msub><mi>E</mi><mn>1</mn></msub></math><phrase>&#8230;</phrase>
  <math><msub><mi>E</mi><mi>n</mi></msub></math> is encoded as the error tag
  (token identifier 22), 
  the encoding of <math><msub><mi>S</mi><mn>0</mn></msub></math>, the sequence of
  the encodings of <math><msub><mi>E</mi><mn>0</mn></msub></math> to
  <math><msub><mi>E</mi><mi>n</mi></msub></math> and the end error tag
  (token identifier 23).</para> 
</listitem>
</varlistentry>

<varlistentry>
<term>Internal References</term>
<listitem>
  <para>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 &OM;
  binary encoding) with long flag set if the number of &OM; sub-objects in the
  encoded &OM; is
  greater than or equal to 256. Then, there is the ordinal number of the
  referenced &OM; object as a byte (if the long flag was not set) or a four byte integer
  (in network byte order).</para>
</listitem>
</varlistentry>

<varlistentry>
<term>External References</term>
<listitem>
  <para>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 &OM;
  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.</para>
</listitem>
</varlistentry>

</variablelist> 
</para>

</section>

<section id="sec_bin_example">
<title>Example of Binary Encoding</title>

<para>As a simple example of the binary encoding, we can consider the &OM; object
<math display="block">
  <mi mathvariant="bold">application</mi>
  <mo fence="true">(</mo>
  <mi>times</mi>
  <mo separator="true">,</mo>
  <mrow>
    <mi mathvariant="bold">application</mi>
    <mo fence="true">(</mo>
    <mi>plus</mi>
    <mo separator="true">,</mo>
    <mi>x</mi>
    <mo separator="true">,</mo>
    <mi>y</mi>
    <mo fence="true">)</mo>
  </mrow>
  <mo separator="true">,</mo>
  <mrow>
    <mi mathvariant="bold">application</mi>
    <mo fence="true">(</mo>
    <mi>plus</mi>
    <mo separator="true">,</mo>
    <mi>x</mi>
    <mo separator="true">,</mo>
    <mi>z</mi>
    <mo fence="true">)</mo>
  </mrow>
  <mo fence="true">)</mo>
</math>
It is binary encoded as the sequence of bytes given in <xref linkend="fig_bin-enc_ex"/>.</para>

<figure id="fig_bin-enc_ex">
    <title>A Simple example of the &OM; binary encoding.</title>

    <informaltable>
      <tgroup cols="9">
	<thead>
	  <row>
	    <entry>Byte</entry><entry>Hex</entry><entry>Meaning</entry>
	    <entry>Byte</entry><entry>Hex</entry><entry>Meaning</entry>
	    <entry>Byte</entry><entry>Hex</entry><entry>Meaning</entry>
	  </row>
	</thead>
	<tbody>
	  <row>
	    <entry>1</entry><entry>58</entry><entry>begin object tag</entry>
	    <entry>19</entry><entry>10</entry><entry>begin application tag</entry>
	    <entry>40</entry><entry>10</entry><entry>begin application tag </entry>
	  </row>
	  <row>
	    <entry>2</entry><entry>2</entry><entry> version 2.0 (major)</entry>
	    <entry>20</entry><entry>08</entry><entry>symbol tag</entry>
	    <entry>41</entry><entry>48</entry><entry>symbol tag (with share bit on) </entry>
	  </row>
	  <row>
	    <entry>3</entry><entry>0</entry><entry> version 2.0 (minor)</entry>
	    <entry>21</entry><entry>06</entry><entry>cd length</entry>
	    <entry>42</entry><entry>01</entry><entry>reference to second symbol seen (arith1:plus)</entry>
	  </row>
	  <row>
	    <entry>4</entry><entry>10</entry><entry>begin application tag</entry>
	    <entry>22</entry><entry>04</entry><entry>name length</entry>
	    <entry>43</entry><entry>45</entry><entry>variable tag (with share bit on) </entry>
	  </row>
	  <row>
	    <entry>5</entry><entry>08</entry><entry>symbol tag</entry>
	    <entry>23</entry><entry>61</entry><entry>a (cd name begin</entry>
	    <entry>44</entry><entry>00</entry><entry>reference to first variable seen (x) </entry>
	  </row>
	  <row>
	    <entry>6</entry><entry>06</entry><entry>cd length </entry>
	    <entry>24</entry><entry>72</entry><entry>r  .</entry>
	    <entry>45</entry><entry>05</entry><entry>variable tag </entry>
	  </row>
	  <row>
	    <entry>7</entry><entry>05</entry><entry>name length</entry>
	    <entry>25</entry><entry>69</entry><entry>i  .</entry>
	    <entry>46</entry><entry>01</entry><entry>name length </entry>
	  </row>
	  <row>
	    <entry>8</entry><entry>61</entry><entry>a (cd name begin</entry>
	    <entry>26</entry><entry>74</entry><entry>t  .</entry>
	    <entry>47</entry><entry>7a</entry><entry>z (variable name) </entry>
	  </row>
	  <row>
	    <entry>9</entry><entry>72</entry><entry>r  .</entry>
	    <entry>27</entry><entry>68</entry><entry>h  .</entry>
	    <entry>48</entry><entry>11</entry><entry>end application tag </entry>
	  </row>
	  <row>
	    <entry>10</entry><entry>69</entry><entry>i  .</entry>
	    <entry>28</entry><entry>31</entry><entry>1  .)</entry>
	    <entry>49</entry><entry>11</entry><entry>end application tag </entry>
	  </row>
	  <row>
	    <entry>11</entry><entry>74</entry><entry>t  .</entry>
	    <entry>29</entry><entry>70</entry><entry>p (symbol name begin</entry>
	    <entry>50</entry><entry>19</entry><entry>end object tag </entry>
	  </row>
	  <row>
	    <entry>12</entry><entry>68</entry><entry>h  .</entry>
	    <entry>30</entry><entry>6c</entry><entry>l  .</entry>
	    <entry/><entry/><entry/>
	  </row>
	  <row>
	    <entry>13</entry><entry>31</entry><entry>1  .)</entry>
	    <entry>31</entry><entry>75</entry><entry>u  . </entry>
	    <entry/><entry/><entry/>
	  </row>
	  <row>
	    <entry>14</entry><entry>74</entry><entry>t (symbol name begin</entry>
	    <entry>32</entry><entry>73</entry><entry>s  .) </entry>
	    <entry/><entry/><entry/>
	  </row>
	  <row>
	    <entry>15</entry><entry>69</entry><entry>i  .</entry>
	    <entry>33</entry><entry>05</entry><entry>variable tag</entry>
	    <entry/><entry/><entry/>
	  </row>
	  <row>
	    <entry>16</entry><entry>6d</entry><entry>m  .</entry>
	    <entry>34</entry><entry>01</entry><entry>name length </entry>
	    <entry/><entry/><entry/>
	  </row>
	  <row>
	    <entry>17</entry><entry>65</entry><entry>e  .</entry>
	    <entry>35</entry><entry>78</entry><entry>x (name) </entry>
	    <entry/><entry/><entry/>
	  </row>
	  <row>
	    <entry>18</entry><entry>73</entry><entry>s  .)</entry>
	    <entry>36</entry><entry>05</entry><entry>variable tag </entry>
	    <entry/><entry/><entry/>
	  </row>
	  <row>
	    <entry/><entry/><entry/>
	    <entry>37</entry><entry>01</entry><entry>name length </entry>
	    <entry/><entry/><entry/>
	  </row>
	  <row>
	    <entry/><entry/><entry/>
	    <entry>38</entry><entry>79</entry><entry>y (variable name) </entry>
	    <entry/><entry/><entry/>
	  </row>
	  <row>
	    <entry/><entry/><entry/>
	    <entry>39</entry><entry>11</entry><entry>end application tag </entry>
	    <entry/><entry/><entry/>
	  </row>
	</tbody>
      </tgroup>
    </informaltable> 
  </figure>
  
</section>

<section id="sec_both_sharing">
  <title>Sharing</title>
  
  <para>
    &OM;&#160;2 introduced a new sharing mechanism, described below.  First however
    we describe the original &OM;&#160;1 mechanism.
  </para>
  
  <section id="sec_sharing">
    <title>Sharing in Objects beginning with the identifier [24]</title>
    
    <para>This form of sharing is deprecated but included for
	backwards compatibility with &OM;&#160;1.  It
      supports the sharing of symbols, variables and strings
      (up to a certain length for strings) within one object. That is, sharing between
      objects is not supported.  A reference to a shared symbol, variable or string is
      encoded as the corresponding tag with the long flag not set and the shared flag
      set, followed by a positive integer <math><mi>n</mi></math> encoded as one byte (0
      to 255). This integer references the <math><mi>n</mi> <mo>+</mo>
	<mn>1</mn></math>-th such sharable sub-object (symbol, variable or string up to
      255 characters) in the current &OM; object (counted in the order they are
      generated by the encoding).  For example, <systemitem>0x48 0x01</systemitem>
      references a symbol that is identical to the second symbol that was found in the
      current object.  Strings with 8 bit characters and strings with 16 bit characters
      are two different kinds of objects for this sharing. Only strings containing less
      than 256 characters can be shared (i.e. only strings up to 255 characters).</para>
  </section>
  
  <section id="sec_sharing_references">
    <title>Sharing with References (beginning with [24+64])</title>
    
    <para>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 tag [88].</para>
    
    <para>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 <systemitem>id</systemitem>
      attribute is set
      in the &exml; encoding. On the object identifier (where sharing does not
      make sense), the shared flag signifies the encoding described here
      ([88]=[24+64]).
    </para>
    
    <para>Otherwise integers, floats, variables, symbols, strings, bytearrays, and constructs
      are treated exactly as in the binary encoding described in the last section.</para>
    
    <para>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 <xref
										linkend="fig_bin-enc2"/> for an example) by referencing their position; external
      references allow to reference &OM; objects in other documents by a URI.</para>
    
    <para>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
      &OM; binary encoding.</para>
    
    <para>References consist of the identifier [30] ([30+128] for long references)
      followed by a positive integer <math><mi>n</mi></math> coded on one byte (4 bytes for long
      references). This integer references the
      <math><mrow><mi>n</mi><mo>+</mo><mn>1</mn></mrow></math>th 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 <systemitem>Ox7E Ox01</systemitem> references the
      second shared sub-object. <xref linkend="fig_bin-enc2"/> shows the binary
      encoding of the object in <xref linkend="fig_shared_vs_unshared"/>
      above.</para>
    
    <figure id="fig_bin-enc2">
      <title>A binary encoding of the &OM; object from <xref linkend="fig_shared_vs_unshared"/>.</title>
      <informaltable>
	<tgroup cols="9">
	  <thead>
	    <row>
	      <entry>Byte</entry><entry>Hex</entry><entry>Meaning</entry>
	      <entry>Byte</entry><entry>Hex</entry><entry>Meaning</entry>
	      <entry>Byte</entry><entry>Hex</entry><entry>Meaning</entry>
	    </row>
	  </thead>
	  <tbody>
	    <row>
	      <entry>1</entry><entry>58</entry><entry>begin object tag</entry>
	      <entry>12</entry><entry>50</entry><entry>begin application tag (shared)</entry>
	      <entry>23</entry><entry>1E</entry><entry>short reference</entry>
	    </row>
	    <row>
	      <entry>2</entry><entry>2</entry><entry> version 2.0 (major)</entry>
	      <entry>13</entry><entry>05</entry><entry>variable tag</entry>
	      <entry>24</entry><entry>00</entry><entry>to the first shared object</entry>
	    </row>
	    <row>
	      <entry>3</entry><entry>0</entry><entry> version 2.0 (minor)</entry>
	      <entry>14</entry><entry>01</entry><entry>variable length</entry>
	      <entry>25</entry><entry>11</entry><entry>end application tag</entry>
	    </row>
	    <row>
	      <entry>4</entry><entry>10</entry><entry>begin application tag</entry>
	      <entry>15</entry><entry>66</entry><entry>f  (variable name)</entry>
	      <entry>26</entry><entry>1E</entry><entry>short reference</entry>
	    </row>
	    <row>
	      <entry>5</entry><entry>05</entry><entry>variable tag</entry>
	      <entry>16</entry><entry>05</entry><entry>variable tag</entry>
	      <entry>27</entry><entry>00</entry><entry>to the second shared object</entry>
	    </row>
	    <row>
	      <entry>6</entry><entry>01</entry><entry>variable length</entry>
	      <entry>17</entry><entry>01</entry><entry>variable length</entry>
	      <entry>28</entry><entry>11</entry><entry>end application tag</entry>
	    </row>
	    <row>
	      <entry>7</entry><entry>66</entry><entry>f  (variable name)</entry>
	      <entry>18</entry><entry>61</entry><entry>a  (variable name)</entry>
	      <entry/>
	    </row>
	    <row>
	      <entry>8</entry><entry>50</entry><entry>begin application tag (shared)</entry>
	      <entry>19</entry><entry>05</entry><entry>variable tag</entry>
	      <entry/>
	    </row>
	    <row>
	      <entry>9</entry><entry>05</entry><entry>variable tag</entry>
	      <entry>20</entry><entry>01</entry><entry>variable length</entry>
	      <entry/>
	    </row>
	    <row>
	      <entry>10</entry><entry>01</entry><entry>variable length</entry>
	      <entry>21</entry><entry>61</entry><entry>a  (variable name)</entry>
	      <entry/>
	    </row>
	    <row>
	      <entry>11</entry><entry>66</entry><entry>f  (variable name)</entry>
	      <entry>22</entry><entry>11</entry><entry>end application tag</entry>
	      <entry/>
	    </row>
	  </tbody>
	</tgroup>
      </informaltable>
    </figure>
    
    <para>It is easy to see that in this binary encoding, the size of the encoding is
      <math><mn>13</mn><mo>+</mo><mn>7</mn>
	<mo fence="true">(</mo><mi>d</mi><mo>-</mo><mn>1</mn><mo fence="true">)</mo></math> bytes,
      where <math><mi>d</mi></math> is the depth of the tree, while a totally unshared encoding
      is <math><mn>8</mn><mo>*</mo><msup><mn>2</mn><mi>d</mi></msup><mo>-</mo><mn>8</mn></math>
      bytes (sharing variables saves up to 256 bytes for trees up to depth 8 and wastes space
      for greater depths). The shared &exml; encoding only uses
      <math><mn>32</mn><mi>d</mi><mo>+</mo><mn>29</mn></math> bytes, which is more space
      efficient starting at depth 9.</para>
    
    <para>Note that in the conversion from the &exml; to the
      binary encoding the identifiers on the
      objects are not preserved. Moreover, even though the &exml; encoding
      allows references across objects, as in <xref linkend="fig_sharing_between"/>, the binary
      encoding does not (the binary encoding has no notion of a multi-object
      collection, while in the &exml; encoding this would naturally correspond to
      e.g.&#160;the embedding of multiple &OM; objects into a single &exml;
      document).</para>
    
    <para>Note that objects need not be fully shared (or shared at all) in the
      binary encoding with sharing.</para>
  </section>
</section>

<section id="sec_impl_note">
  <title>Implementation Note</title>
  
  <para>A typical implementation of the binary encoding comes in two parts. The
    first part deals with the unshared encodings, i.e. objects starting with the
    identifier <systemitem>[24]</systemitem>.</para>
  
  <para>This part uses four tables, each of 256 entries, for symbol, variables, 8
    bit character strings whose lengths are less than 256 characters and 16 bit
    character strings whose lengths are less than 256 characters.  When an object is
    read, all the tables are first flushed. Each time a sharable sub-object is read,
    it is entered in the corresponding table if it is not full. When a reference to
    the shared <math><mi>i</mi></math>-th object of a given type is read, it stands
    for the <math><mi>i</mi></math>-th entry in the corresponding table. It is an
    encoding error if the <math><mi>i</mi></math>-th position in the table has not
    already been assigned (i.e. forward references are not allowed).  Sharing is not
    mandatory, there may be duplicate entries in the tables (if the application that
    wrote the object chose not to share optimally).
  </para>
  
  <para>
    The part for the shared representations of &OM; objects uses an unbounded
    array for storing shared sub-objects. Whenever an object has the shared flag
    set, then it is read and a pointer to the generated data structure is stored at
    the next position of the array. Whenever a reference of the form 
    <systemitem>[30] [_]</systemitem> is
    encountered, the array is queried for the value at <systemitem>[_]</systemitem>
    and analogously for <systemitem>[30+128] {_}</systemitem>. Note that the
    application can decide to copy the value or share it among sub-terms as long as
    it respects the identity conditions given by the tree-nature of the &OM;
    objects.  The implementation must take care to ensure that no variables
    are captured during this process (see section
    <xref linkend="sec_sharing_bvars"/>), and possibly have methods for recovering
    from cyclic dependency relations (this can be done by standard loop-checking
    methods).
  </para>
  
  <para>Writing an object is simple. The tables are first flushed. Each time a
    sharable sub-object is encountered (in the natural order of output given by the
    encoding), it is either entered in the corresponding table (if it is not full) and
    output in the normal way or replaced by the right reference if it is already
    present in the table.</para>
</section>


<section id="sec_relation_OM1_binary">
  <title>Relation to the &OM;&#160;1 binary encoding</title>
  <para>The &OM;&#160;2 binary encoding significantly extends the
    &OM;&#160;1 binary encoding to accommodate the new features and in particular sharing of
    sub-objects. The tags and structure of the  &OM;&#160;1 binary encoding are still
    present in the current &OM; binary encoding, so that binary encoded &OM;&#160;1 objects
    are still valid in the &OM;&#160;2 binary encoding and correspond to the same abstract
    &OM; objects. In some cases, the binary encoding tags without the shared flag
    can still be used as more compact representations of the objects (which are
    not shared, and do not have an identifier).
  </para>
  <para>As the binary encoding is geared towards compactness, &OM; objects
    should be constructed so as to maximise internal sharing
    (if computationally feasible). Note that since
    sharing is done only at the
    encoding level, this does not alter the meaning of an &OM; object, only
    allows it to be represented more compactly.
  </para>
</section>
</section>

<section id="sec_json-the-json-encoding" revisionflag="added">
  <title>The JSON encoding</title>
  <!-- TODO: Citation of one of the JSON standards -->
  <para>
    JSON <citation>url_JSON</citation> is a lightweight data format natively supported by many
    programming languages, in particular JavaScript and other web-based languages. 
    The JSON encoding aims to ensure that &OM; objects can be represented as JSON objects 
    with human-readable attribute names thus making &OM; more interoperable with the web. 
    Furthermore, it aims to make translation from XML to JSON schema easily possible. It uses
    JSON-native types where possible, and avoid XML peculiarities like
    pseudo elements.
  </para>
  <para>
    JSON Schema <citation>handrewsjsonschema</citation> is a format that allows structural verification of JSON objects. 
    This format is difficult to edit, hence the normative schema is authored as a TypeScript <citation>url_typescript</citation> definition file which can be found in <xref linkend="app_dts" />. 
    A non-normative JSON Schema is then generated from this definition files. 
    It can be found in <xref linkend="app_json" />. 
  </para>
  <section id="sec_json-general-structure">
    <title>General Structure</title>
    <para>
      In general, each &OM; object is represented as a JSON
      structure. For example:
    </para>
    <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMV&quot;,
    &quot;id&quot;: &quot;something&quot;,
    &quot;name&quot;: &quot;x&quot;
}
</programlisting>
    <para>
      This already shows two attributes that can be used with any &OM; Element:
    </para>
    <orderedlist numeration="arabic">
      <listitem>
<para>
The <systemitem>kind</systemitem> attribute, which defines the kind of &OM; object in question.
This has to be present on every &OM; JSON object, and the values are the corresponding &OM; XML element name. It can be used to easily distinguish between the different types of objects.
In TypeScript terms, this is called a <emphasis>TypeGuard</emphasis>.
</para>
      </listitem>
      <listitem>
<para>
The <systemitem>id</systemitem> attribute, which can be used for Structure sharing.
This works similar to the XML encoding, but more on this later.
</para>
      </listitem>
    </orderedlist>
    <para>
      In the TypeScript schema, this is expressed using the following two types:
    </para>
    <itemizedlist>
      <listitem>
        <para>
          The <systemitem>element</systemitem> type is used by any &OM; 
          (or &OM;-related) element, and only enforces that <systemitem>kind</systemitem> is a string.
        </para>
      </listitem>
      <listitem>
        <para>
          The <systemitem>referencable</systemitem> type is any &OM; element
          that can optionally be given an <systemitem>id</systemitem>.
        </para>
      </listitem>
    </itemizedlist>
    <para>
      Note that for simplicity, the <systemitem>id</systemitem>
      attribute is omitted in any of the below. 
    </para>
  </section>
  <section id="sec_json-omobj-om-object-constructor">
    <title>The Object Constructor</title>
    <para>
      We can use the <systemitem>OMOBJ</systemitem> type to create a new
      &OM; object.
    </para>
    <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMOBJ&quot;,

    /** optional version of openmath being used */
    &quot;openmath&quot;: &quot;2.0&quot;,

    /** the actual object */
    &quot;object&quot;: omel /* any element, see below */
}
</programlisting>
    <para>
      For example, the integer <systemitem>3</systemitem>:
    </para>
    <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMOBJ&quot;,
    &quot;openmath&quot;: &quot;2.0&quot;,
    &quot;object&quot;: {
        &quot;kind&quot;: &quot;OMI&quot;, 
        &quot;integer&quot;: 3
    }
}
</programlisting>
    <para>
      The object can be any &OM; element, as expressed by the
      <systemitem>omel</systemitem> type.
    </para>
  </section>
  <section id="sec_json-oms---symbol">
    <title>OpenMath Symbols</title>
    <para>
      A symbol is represented using the <systemitem>OMS</systemitem> type.
    </para>
    <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMS&quot;,

    /** the base for the cd, optional */
    &quot;cdbase&quot;: uri, 

    /** content dictonary the symbol is in, any name */
    &quot;cd&quot;: name,

    /** name of the symbol */
    &quot;name&quot;: name
}
</programlisting>
    <para>
      For example the <systemitem>sin</systemitem> symbol from the
      <systemitem>transc1</systemitem> content dictionary:
    </para>
    <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMS&quot;,

    &quot;cd&quot;: &quot;transc1&quot;,
    &quot;name&quot;: &quot;sin&quot;
}
</programlisting>
  </section>
  <section id="sec_json-omv---variable">
    <title>Variables</title>
    <para>
      A variable is represented using the <systemitem>OMV</systemitem> type.
    </para>
    <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMV&quot;,

    /** name of the variable */
    &quot;name&quot;: name
}
</programlisting>
    <para>
      For example, the variable <systemitem>x</systemitem>:
    </para>
    <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMV&quot;,
    &quot;name&quot;: &quot;x&quot;
}
</programlisting>
  </section>
  <section id="sec_json-omi---integers">
    <title>Integers</title>
    <para>
      Integers can be represented in three different ways, to both make
      use of json and enable easy translation from the XML encoding.
    </para>
    <section id="sec_json-json-integers">
      <title>JSON Integers</title>
      <para>
        Integers can be represented as a native JSON Integer, using an
        <systemitem>integer</systemitem> property.
      </para>
      <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMI&quot;,

    /** integer value */
    &quot;integer&quot;: integer
}
</programlisting>
      <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMI&quot;,
    &quot;integer&quot;: -120
}
</programlisting>
    </section>
    <section id="sec_json-decimal-integers">
      <title>Decimal Integers</title>
      <para>
        Integers can be represented using their decimal encoding, using
        the <systemitem>decimal</systemitem> property:
      </para>
      <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMI&quot;, 

    /** decimal value */
    &quot;decimal&quot;: decimalInteger
}
</programlisting>
      <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMI&quot;,
    &quot;decimal&quot;: &quot;-120&quot;
}
</programlisting>
    </section>
    <section id="sec_json-hexadecimal-integers">
      <title>Hexadecimal Integers</title>
      <para>
        Integers can be represented using their hexadecimal encoding,
        using the <systemitem>hexadecimal</systemitem> property:
      </para>
      <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMI&quot;,

    /** hexadecimal value */
    &quot;hexadecimal&quot;: hexInteger
}
</programlisting>
      <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMI&quot;,
    &quot;hexadecimal&quot;: &quot;-x78&quot;
}
</programlisting>
    </section>
  </section>
  <section id="sec_json-omf---floats">
    <title>Floats</title>
    <para>
      Floats, like integers, can be represented in three different ways.
    </para>
    <section id="sec_json-json-floats">
      <title>JSON Floats</title>
      <para>
        Floats can be represented as a native JSON Numbers, using a
        <systemitem>float</systemitem> property.
      </para>
      <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMF&quot;,

    /** float value */
    &quot;float&quot;: float
}
</programlisting>
      <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMF&quot;,
    &quot;float&quot;: 1e-10
}
</programlisting>
    </section>
    <section id="sec_json-decimal-floating-point-numbers">
      <title>Decimal Floating Point Numbers</title>
      <para>
        Integers can be represented using their decimal encoding, using
        the <systemitem>decimal</systemitem> property:
      </para>
      <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMF&quot;,

    /** decimal value */
    &quot;decimal&quot;: decimalFloat
}
</programlisting>
      <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMF&quot;,
    &quot;decimal&quot;: &quot;1.0e-10&quot;
}
</programlisting>
    </section>
    <section id="sec_json-hexadecimal-floats">
      <title>Hexadecimal Floats</title>
      <para>
        Floats can be represented using their hexadecimal encoding,
        using the <systemitem>hexadecimal</systemitem> property:
      </para>
      <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMF&quot;,

    /** hexadecimal value */
    &quot;hexadecimal&quot;: hexFloat
}
</programlisting>
      <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMF&quot;,
    &quot;hexaecimal&quot;: &quot;3DDB7CDFD9D7BDBB&quot;
}
</programlisting>
    </section>
  </section>
  <section id="sec_json-omb---bytes">
    <title>Bytes</title>
    <para>
      Byte Arrays can be represented using two ways, as a native array
      of JSON integers, or base64-encoded as a string.
    </para>
    <section id="sec_json-json-byte-arrays">
      <title>JSON Byte Arrays</title>
      <para>
        Bytes can be represented as a native JSON Byte Array, using a
        <systemitem>bytes</systemitem> property.
      </para>
      <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMB&quot;,

    /** an array of bytes */
    &quot;bytes&quot;: byte[]
}
</programlisting>
      <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMB&quot;,
    &quot;bytes&quot;: [104, 101, 108, 108, 111, 32, 119, 111, 114, 108, 100]
}
</programlisting>
    </section>
    <section id="sec_json-base64-encoded-bytes">
      <title>Base64-encoded bytes</title>
      <para>
        Bytes can also be encoded as a base64 encoded string.
      </para>
      <programlisting language="javascript">
{
    &quot;kind&quot;: &quot;OMB&quot;,

    /** a base64 encoded string */
    &quot;base64&quot;: base64string
}
</programlisting>
      <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMB&quot;,
    &quot;base64&quot;: &quot;aGVsbG8gd29ybGQ=&quot;
}
</programlisting>
    </section>
  </section>
  <section id="sec_json-oms-strings">
    <title>Strings</title>
    <para>
      Strings can be represented using normal JSON strings and the
      <systemitem>OMS</systemitem> type.
    </para>
    <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMSTR&quot;, 

    /** the string */
    &quot;string&quot;: string
}
</programlisting>
    <para>
      For example:
    </para>
    <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMSTR&quot;, 
    &quot;string&quot;: &quot;Hello world&quot;
}
</programlisting>
  </section>
  <section id="sec_json-oma-application">
    <title>Applications</title>
    <para>
      Applications can be represented using the <systemitem>OMA</systemitem>
      type.
    </para>
    <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMA&quot;, 

    /** the base for the cd, optional */
    &quot;cdbase&quot;: uri, 

    /** the term that is being applied */
    &quot;applicant&quot;: omel, 

    /** the arguments that the applicant is being applied to, optional */
    &quot;arguments&quot;?: omel[]
}
</programlisting>
    <para>
      For example:
    </para>
    <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMA&quot;,

    &quot;applicant&quot;: {
        &quot;kind&quot;: &quot;OMS&quot;,

        &quot;cd&quot;: &quot;transc1&quot;,
        &quot;name&quot;: &quot;sin&quot;
    },

    &quot;arguments&quot;: [{
            &quot;kind&quot;: &quot;OMV&quot;,
            &quot;name&quot;: &quot;x&quot;
    }]
}
</programlisting>
  </section>
  <section id="sec_json-oma-attribution">
    <title>Attribution</title>
    <para>
      Attribution can be represented using the <systemitem>OMB</systemitem>
      type.
    </para>
    <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMATTR&quot;, 

    /** the base for the cd, optional */
    &quot;cdbase&quot;: uri, 

    /** attributes attributed to this object, non-empty */
    &quot;attributes&quot;: ([
        OMS, omel|OMFOREIGN
    ])[]

    /** object that is being attributed */
    &quot;object&quot;: omel
}
</programlisting>
    <para>
      Here the attributes are being encoded as an array of pairs. Each
      pair consists of a symbol (the attribute name) and a value (an
      element or foreign element).
    </para>
    <para>
      For example:
    </para>
    <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMATTR&quot;,
    &quot;attributes&quot;: [
        [
            {
                &quot;kind&quot;: &quot;OMS&quot;,
                &quot;cd&quot;: &quot;ecc&quot;,
                &quot;name&quot;: &quot;type&quot;
            },
            {
                &quot;kind&quot;: &quot;OMS&quot;,
                &quot;cd&quot;: &quot;ecc&quot;,
                &quot;name&quot;: &quot;real&quot;
            }
        ]
    ],
    &quot;object&quot;: {
        &quot;kind&quot;: &quot;OMV&quot;,
        &quot;name&quot;: &quot;x&quot;
    }
}
</programlisting>
  </section>
  <section id="sec_json-omb---binding">
    <title>Binding</title>
    <para>
      Binding can be represented using the <systemitem>OMB</systemitem> type.
    </para>
    <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMBIND&quot;, 

    /** the base for the cd, optional */
    &quot;cdbase&quot;: uri, 

    /** the binder being used */
    &quot;binder&quot;: omel

    /** the variables being bound, non-empty */
    &quot;variables&quot;: (OMV | attvar)[]

    /** the object that is being bound */
    &quot;object&quot;: omel
}
</programlisting>
    <para>
      Here, the variables can be a list of variables or attributed
      variables. Attributed variables are represented using the
      <systemitem>attvar</systemitem> type. This is any
      <systemitem>OMATTR</systemitem> element (see above), where the
      <systemitem>object</systemitem> being attributed is an
      <systemitem>OMV</systemitem> instance.
    </para>
    <para>
      For example:
    </para>
    <programlisting language="json">
{  
    &quot;kind&quot;: &quot;OMBIND&quot;,
    &quot;binder&quot;:{  
        &quot;kind&quot;: &quot;OMS&quot;,
        &quot;cd&quot;: &quot;fns1&quot;,
        &quot;name&quot;: &quot;lambda&quot;
    },
    &quot;variables&quot;:[  
        {  
            &quot;kind&quot;: &quot;OMV&quot;,
            &quot;name&quot;: &quot;x&quot;
        }
    ],
    &quot;object&quot;: {  
        &quot;kind&quot;: &quot;OMA&quot;,
        &quot;applicant&quot;: {  
            &quot;kind&quot;: &quot;OMS&quot;,
            &quot;cd&quot;: &quot;transc1&quot;,
            &quot;name&quot;:&quot;sin&quot;
        },
        &quot;arguments&quot;: [  
            {  
                &quot;kind&quot;:&quot;OMV&quot;,
                &quot;name&quot;:&quot;x&quot;
            }
        ]
    }
}
</programlisting>
  </section>
  <section id="sec_json-ome---errors">
    <title>Errors</title>
    <para>
      Errors can be represented using the <systemitem>OME</systemitem> object:
    </para>
    <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OME&quot;, 

    /** the error that has occured */
    &quot;error&quot;: OMS,

    /** arguments to the error, optional  */
    &quot;arguments&quot;: (omel|OMFOREIGN)[]
}
</programlisting>
    <para>
      Here, the variables can be a list of elements or foreign objects.
    </para>
    <para>
      For example:
    </para>
    <programlisting language="json">
{
    &quot;kind&quot;: &quot;OME&quot;,
    &quot;error&quot;: {
        &quot;kind&quot;: &quot;OMS&quot;,
        &quot;cd&quot;: &quot;aritherror&quot;,
        &quot;name&quot;: &quot;DivisionByZero&quot;
    },
    &quot;arguments&quot;: [
        {
            &quot;kind&quot;: &quot;OMA&quot;,
            &quot;applicant&quot;: {
                &quot;kind&quot;: &quot;OMS&quot;,
                &quot;cd&quot;: &quot;arith1&quot;,
                &quot;name&quot;: &quot;divide&quot;
            },
            &quot;arguments&quot;: [
                {
                    &quot;kind&quot;: &quot;OMV&quot;,
                    &quot;name&quot;: &quot;x&quot;
                },
                {
                    &quot;kind&quot;: &quot;OMI&quot;,
                    &quot;integer&quot;: 0
                }
            ]
        }
    ]
}
</programlisting>
  </section>
  <section id="sec_json-omrs-and-structure-sharing">
    <title>References and Structure Sharing</title>
    <para>
      Just like in the XML encoding, the <systemitem>OMR</systemitem> type can
      be used for structure sharing. This can use an
      <systemitem>href</systemitem> property.
    </para>
    <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMR&quot;

    /** element that is being referenced */
    &quot;href&quot;: uri
}
</programlisting>
    <para>
      For example:
    </para>
    <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMOBJ&quot;,
    &quot;object&quot;: {
        &quot;kind&quot;: &quot;OMA&quot;,
        &quot;applicant&quot;: {
            &quot;kind&quot;: &quot;OMV&quot;,
            &quot;name&quot;: &quot;f&quot;
        },
        &quot;arguments&quot;: [
            {
                &quot;kind&quot;: &quot;OMA&quot;,
                &quot;id&quot;: &quot;t1&quot;,
                &quot;applicant&quot;: {
                    &quot;kind&quot;: &quot;OMV&quot;,
                    &quot;name&quot;: &quot;f&quot;
                },
                &quot;arguments&quot;: [
                    {
                        &quot;kind&quot;: &quot;OMA&quot;,
                        &quot;id&quot;: &quot;t11&quot;,
                        &quot;applicant&quot;: {
                            &quot;kind&quot;: &quot;OMV&quot;,
                            &quot;name&quot;: &quot;f&quot;
                        },
                        &quot;arguments&quot;: [
                            {
                                &quot;kind&quot;: &quot;OMV&quot;,
                                &quot;name&quot;: &quot;a&quot;
                            },
                            {
                                &quot;kind&quot;: &quot;OMV&quot;,
                                &quot;name&quot;: &quot;a&quot;
                            }
                        ]
                    },
                    {
                        &quot;kind&quot;: &quot;OMR&quot;,
                        &quot;href&quot;: &quot;#t11&quot;
                    }
                ]
            },
            {
                &quot;kind&quot;: &quot;OMR&quot;,
                &quot;href&quot;: &quot;#t1&quot;
            }
        ]
    }
}
</programlisting>
  </section>
  <section id="sec_json-omforeign---foreign-objects">
    <title>Foreign Objects</title>
    <para>
      Just like in the XML encoding, the <systemitem>OMFOREIGN</systemitem>
      type can be used for foreign objects. This can use an
      <systemitem>href</systemitem> property.
    </para>
    <programlisting language="typescript">
{
    &quot;kind&quot;: &quot;OMFOREIGN&quot;

    /** encoding of the foreign object */
    &quot;encoding&quot;?: string

    /** the foreign object */
    &quot;foreign&quot;: any
}
</programlisting>
    <para>
      For example:
    </para>
    <programlisting language="json">
{
    &quot;kind&quot;: &quot;OMFOREIGN&quot;,
    &quot;encoding&quot;: &quot;text/latex&quot;,
    &quot;foreign&quot;: &quot;$x=\frac{1+y}{1+2z^2}$&quot;
}
</programlisting>
  </section>
</section>

<section id="sec_enc_summary">
  <title>Summary</title>
  
  <para>The key points of this chapter are:
    <itemizedlist>
      <listitem><para>The &exml; encoding for &OM; objects uses most common
	  character sets.</para>
      </listitem>
      <listitem><para>The &exml; encoding is readable, writable and can be
	  embedded in most documents and transport protocols.</para>
      </listitem>
      <listitem><para>The binary encoding for &OM; objects should be used when
	  efficiency is a key issue. It is compact yet simple enough to allow
	  fast encoding and decoding of objects.</para>
      </listitem>
      <listitem revisionflag="added"><para>
      JSON is a widely used standard, with implementations in most programming 
      languages, in particular JavaScript and other languages used on the web. 
      The JSON encoding thus makes &OM; objects web-interoparable. </para>
      </listitem>
    </itemizedlist>
  </para>
</section>
</chapter>

<chapter id="cha_cd">
  <title>Content Dictionaries</title>
  
  
  <para>In this chapter we give a brief overview of Content Dictionaries
    before explicitly stating their functionality and encoding.</para>
  <section id="sec_cd_summary">
    <title>Introduction</title>
    
    <para>Content Dictionaries (CDs) are central to the &OM; philosophy of
      transmitting mathematical information. It is the &OM; Content
      Dictionaries which actually hold the meanings of the objects being
      transmitted.</para>
    
    <para>For example if application <math><mi>A</mi></math> is talking to
      application <math><mi>B</mi></math>, and sends, say, an equation
      involving multiplication of matrices, then <math><mi>A</mi></math> and
      <math><mi>B</mi></math> must agree on what a matrix is, and on what
      matrix multiplication is, and even on what constitutes an
      equation. All this information is held within some Content
      Dictionaries which both applications agree upon.</para>
    
    <para>A <term id="cd"> Content Dictionary</term> holds the meanings of
      (various) mathematical <quote>words</quote>. These words are &OM;
      basic objects referred to as <emphasis>symbols</emphasis> in
      <xref linkend="sec_omabs"/>.</para>
    
    <para>With a set of symbol definitions (perhaps from several Content
      Dictionaries), <math><mi>A</mi></math> and <math><mi>B</mi></math> can
      now talk in a common <quote>language</quote>.</para>
    
    <para>It is important to stress that it is not Content Dictionaries
      themselves which are being transmitted, but some <quote>mathematics</quote>
      whose definitions are held within the Content Dictionaries. This means
      that the applications must have already agreed on a set of Content
      Dictionaries which they <quote>understand</quote> (i.e., can cope with
      to some degree).</para>
    
    <para>In many cases, the Content
      Dictionaries that an application understands will be constant, and be
      intrinsic to the application's mathematical use. However the above
      approach can also be used for applications which can handle every
      Content Dictionary (such as an &OM; parser, or perhaps a typesetting
      system), or alternatively for applications which understand a
      changeable number of Content Dictionaries (perhaps after being sent
      Content Dictionaries in some way).</para>
    
    <para>The primary use of Content Dictionaries is thought to be for
      designers of <xref linkend="phrasebook"/>s, the programs which translate between the &OM;
      mathematical object and the corresponding (often internal) structure
      of the particular application in question. For such a use the Content
      Dictionaries have themselves been designed to be as readable and
      precise as possible.</para>
    
    <para>Another possible use for &OM; Content Dictionaries could rely on
      their automatic comprehension by a machine (e.g., when given
      definitions of objects defined in terms of previously understood
      ones), in which case Content Dictionaries may have to be passed as
      data. Towards this end, a Content Dictionary has been written which
      contains a set of symbols sufficient to represent any other Content
      Dictionary. This means that Content Dictionaries may be passed in the
      same way as other (&OM;) mathematical data.</para>
    
    <para>Finally, the syntax of the reference encoding for
      Content Dictionaries has been designed to be relatively easy to learn
      and to write, and also free from the need for any specialist
      software. This is because it is acknowledged that there is an enormous
      amount of mathematical information to represent, and so most 
      Content Dictionaries are written by <quote>ordinary</quote>
      mathematicians, encoding their particular fields of expertise.  A
      further reason is that the mathematics conveyed by a specific Content
      Dictionary should be understandable independently of any
      application.</para>
    
    <para>The key points from this section are:
      <itemizedlist>
	<listitem><para>Content Dictionaries should be readable and precise to help
	    <xref linkend="phrasebook"/> designers,</para>
	</listitem>
	<listitem><para>Content Dictionaries should be readily write-able to encourage
	    widespread use,</para>
	</listitem>
	<listitem><para>It ought to be possible for a machine to understand a Content
	    Dictionary to some degree.</para>
	</listitem>
      </itemizedlist>
    </para>
  </section>
  
  <section id="sect_func">
    <title>Abstract Content Dictionaries</title>
    
    <para>In this section we define the abstract structure of Content Dictionaries.</para>
    
    
    <para>A Content Dictionary consists of the
      following mandatory pieces of information:
      <orderedlist>
	<listitem>
	  <para>A <term id="cdname">name</term> corresponding to the rules described in <xref
	  linkend="sec_names"/>.</para>
	</listitem>
	<listitem><para>A <term id="cddescription">description</term> of the Content
	Dictionary.
	  </para>
	</listitem>
	<listitem><para>A <term id="cdrevisiondate">revision date</term>, the date of the
	    last change to the Content Dictionary.  Dates should be stored in the
	    ISO-compliant format YYYY-MM-DD, e.g. 1966-02-03. 
	  </para>
	</listitem>
	<listitem><para>A <term id="cdreviewdate">review date</term>, a date until which
	    the content dictionary is guaranteed to remain unchanged. 
	  </para>
	</listitem>
	<listitem><para>A <term id="cdversion">version number</term> which consists
	    of a major and minor part (see <xref linkend="sec_version"/>). 
	  </para>
	</listitem>
	<listitem><para>A <term id="cdstatus">status</term>, as described in <xref
									     linkend="sec_status"/>. 
	  </para>
	</listitem>
	<listitem><para>A <term id="cdcdbase">CD base</term> which, when combined
	    with the CD name, forms a unique
	    identifier for the Content Dictionary. It may or may not refer to an
	    actual location from which it can be retrieved.   
	  </para>
	</listitem>
	<listitem><para>A series of one or more <term id="cdsymdef">symbol
	definitions</term> as described below.
	  </para>
	</listitem>
      </orderedlist>
    </para>
    
    <para>A symbol definition consists of the
      following pieces of information:
      <orderedlist>
	<listitem><para>A mandatory <term id="symdefname">name</term> corresponding to the
	rules described in <xref linkend="sec_names"/>.</para>
	</listitem>
	<listitem><para>A mandatory <term id="symdefdescription">description</term> of the symbol,
	    which can be as formal or informal as the author likes.
	  </para>
	</listitem>
	<listitem><para>An optional <term id="symdefrole">role</term> as described in
	    <xref linkend="sec_roles"/>.
	  </para>
	</listitem>
	<listitem><para>Zero or more <term id="symdefCMP">commented mathematical
	      properties</term> which are mathematical properties of the symbol
	    expressed in a mechanism other than &OM;.
	  </para>
	</listitem>
	<listitem><para>Zero or more <term id="symdefFMP">formal mathematical
	      properties</term> which are mathematical properties of the symbol
	    expressed in &OM;.  Note that it is common for commented and formal
	    mathematical properties to be introduced in pairs, with the former
	    describing the latter.
	  </para>
	  
	  <para>A Formal Mathematical Property may be given an optional
	    <term id="symdefkind">kind</term> attribute.  An author of a Content Dictionary
	    may use this to indicate whether, for example, the property provides an
	    algorithm for evaluation of the concept it is associated with.  At
	    present no fixed scheme is mandated for how this information should be
	    encoded or used by an application.
	  </para>
	  
	</listitem>
	<listitem><para>Zero or more <term id="symdefexamples">examples</term> which are
	    intended to demonstrate the use of the symbol within an &OM; object.
	  </para>
	</listitem>
      </orderedlist>
    </para>
        
    <para>
      Some pieces of information which might logically be thought to be part of a Content
      Dictionary, such as the types or signatures of symbols, are better represented
      externally.  This allows for new variants to be associated with Content Dictionaries
      without the Dictionaries themselves being changed.  A model for signatures is given
      in <xref linkend="sigfiles"/>.
    </para>
    
    
    <para>
      Content Dictionaries may be grouped into <term id="cdgroup">CD Group</term>s. These
      groups allow applications to easily refer to collections of Content
      Dictionaries. One particular CDGroup of interest is the <quote>MathML
      CDGroup</quote>. This group consists of the collection of core Content Dictionaries
      that is designed to have the same semantic scope as the content elements of MathML
      <citation>MathML_2014</citation>.  &OM; objects built from symbols that come from
      Content Dictionaries in this CDGroup may be expected to be easily transformed
      between &OM; and MathML encodings.  The detailed structure of a CDGroup is described
      in <xref linkend="ssec_cdgroups"/> below.
    </para>
    
    <section  id="sec_status">
      <title>Content Dictionary Status</title>
      
      <para>The status of a Content Dictionary can be either
	<itemizedlist>
	  <listitem><para>
	      <systemitem>official</systemitem>: approved by the &OM; Society
	      according to the procedure outlined in <xref linkend="cdapprove"/>;
	    </para></listitem>
	  
	  <listitem><para>
	      <systemitem>experimental</systemitem>: under development and thus
	      liable to change;
	    </para></listitem>
	  <listitem><para>
	      <systemitem>private</systemitem>: used by a private group of &OM;
	      users;
	    </para></listitem>
	  <listitem><para>
	      <systemitem>obsolete</systemitem>: an obsolete Content
	      Dictionary kept only for archival purposes.
	    </para></listitem>
	</itemizedlist>
      </para>
    </section>
    
    <section  id="sec_version">
      <title>Content Dictionary Version Numbers</title>
      
      <para>A version number must consist of two parts, a major version and
	a revision, both of which should be non-negative integers.  In CDs
	that do not have status <systemitem>experimental</systemitem>, the version
	number should be a positive integer.</para>
      
      <para>Unless a CD has status <systemitem>experimental</systemitem>,
	no changes should ever be
	introduced that invalidate objects built with previous versions.
	Any change that influences phrasebook compliance, like adding a new
	symbol to a Content Dictionary, is considered a major change
	and should be reflected by an increase in the major version number. Other
	changes, like adding an example or correcting a description, are
	considered minor changes. For minor changes the version number is not
	changed, but an increase should be made to the revision number.
	Note that a change such as removing a symbol should
	not be made unless the CD has status
	<systemitem>experimental</systemitem>.
	Should this be required then a new CD with a different name should be
	produced so as not to invalidate existing objects.</para>
      
      <para>
	When the major version number
	is increased, the revision number is normally reset to zero.</para>
      
      <para>As detailed in <xref linkend="cha_comp"/>, &OM;
	compliant applications state which versions of which CDs they support.
      </para>
      
    </section>
    
  </section>
  
  <section id="sec_xml_cd">
    <title>The Reference Encoding for Content Dictionaries</title>    
    
    <para>The reference encoding of
      Content Dictionaries are as &exml; documents.  A valid Content Dictionary
      document should conform to the Relax NG Schema for
	Content Dictionaries given in <xref linkend="sec_cd_schema"/>.
    </para>
    
    <para>An example of a complete Content Dictionary is given in
      Appendix&#160;<xref linkend="app_cdcd"/>, which is the
      <systemitem>Meta</systemitem> Content Dictionary for describing
      Content Dictionaries themselves. A more typical Content Dictionary is
      given in <xref linkend="arith1.ocd"/>, the
      <systemitem>arith1</systemitem> Content Dictionary for basic
      arithmetic functions.</para>
    
    <section id="sec_cd_schema">
      <title>The Relax NG Schema for Content Dictionaries</title>
      <literallayout role="rnc" file="omcd2.rnc"/>
    </section>

    <section id="sect_pcdata">
<title>Further Description of the CD Schema</title>
<para>
  We now describe the elements used in the above schema in terms of the abstract
  description of CDs in <xref linkend="sect_func"/>.  Unless stated otherwise information
  is encoded as the content of the relevant element.
</para>



<variablelist>
  <varlistentry><term><systemitem>CD</systemitem></term>
  <listitem>
    <para>
      The <systemitem>CD</systemitem> element can take an optional
      <systemitem>version</systemitem> attribute which indicate to which version of the
      &OM; standard it conforms. In previous versions of this standard this attribute did
      not exist, so any &OM; object without such an attribute must conform to version 1
      (or equivalently 1.1) of the &OM; standard.  Objects which conform to the
      description given in this document should have
      <systemitem>version="2.0"</systemitem>. The value of the
      <systemitem>version</systemitem> attribute on the <systemitem>CD</systemitem>
      element determines the default value for all contained
      <systemitem>OMOBJ</systemitem> elements.  Similarly, the value of the optional
      <systemitem>cdgroup</systemitem> attribute determines the default of
      <systemitem>cdgroup</systemitem> contained <systemitem>OMOBJ</systemitem> elements.
    </para>
  </listitem>
  </varlistentry>
  
  <varlistentry><term><systemitem>CDName</systemitem></term><listitem><para>The name of
  the Content Dictionary.
</para>

</listitem>
</varlistentry>
<varlistentry>
<term><systemitem>Description</systemitem></term>
<listitem><para>The text occurring in the <systemitem>Description</systemitem>
  element is used to give a description of the enclosing element, which
  could be a symbol or the entire Content Dictionary. The content of
  this element can be any &exml; text.</para>
  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDReviewDate</systemitem></term><listitem><para>The
review date of the Content
  Dictionary. </para>
  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDDate</systemitem></term><listitem><para>The
revision date of this version of the Content Dictionary.
</para>
  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDVersion</systemitem></term><listitem>
   
   

<para>The major version number of the CD.</para>

  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDRevision</systemitem></term><listitem>

<para>The minor version number of the
CD.</para>
  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDStatus</systemitem></term><listitem><para>The
status of the Content Dictionary.
</para>
  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDBase</systemitem></term><listitem><para>The
CD base of the CD.

</para>
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDURL</systemitem></term><listitem><para>The
  text occurring in the <systemitem>CDURL</systemitem> element should
  be a valid URL where the source file for the Content Dictionary
  encoding can be found (if it exists). The filename should conform to
  ISO 9660&#160;<citation>iso9660</citation>.

</para>

</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDUses</systemitem></term><listitem>
    <para>The content of this element should
   be a series of <systemitem>CDName</systemitem> elements, each
   naming a Content Dictionary used in the
   <systemitem>Example</systemitem> and <systemitem>FMP</systemitem>s
   of the current Content Dictionary. This element is optional and deprecated since
the information can easily be extracted automatically.</para>
   
 </listitem>
</varlistentry>
<varlistentry><term><systemitem>CDComment</systemitem></term><listitem><para>The
   content of this element should be text that does not convey any
   crucial information concerning the current Content Dictionary. It
   can be used in the Content Dictionary header to report the author
   of the Content Dictionary and to log change information. In the
   body of the Content Dictionary, it can be used to attach extra
   remarks to certain symbols.</para> 
   
 </listitem>
</varlistentry>
<varlistentry><term><systemitem>CDDefinition</systemitem></term><listitem><para>The
element which contains the definition of an individual symbol.
</para>
  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>Name</systemitem></term><listitem><para>The
name of a symbol.
</para>
  
</listitem>
</varlistentry>

<varlistentry><term><systemitem>Role</systemitem></term>
<listitem>
  <para>The role of a symbol: it must be one of
  <systemitem>binder</systemitem>, 
  <systemitem>attribution</systemitem>, 
  <systemitem>semantic-attribution</systemitem>, 
  <systemitem>error</systemitem>, 
  <systemitem>application</systemitem>, or
  <systemitem>constant</systemitem>. 
</para>
</listitem>
</varlistentry>

<varlistentry><term><systemitem>Example</systemitem></term>
<listitem>
 <para>The text occurring in the
<systemitem>Example</systemitem> element is used to give examples of
the enclosing symbol, and can be any &exml; text. In addition to text
the element may contain examples as &exml; encoded &OM;, inside
<systemitem>OMOBJ</systemitem> elements.  Note that
<systemitem>Examples</systemitem> must be with respect to some symbol
and cannot be <quote>loose</quote> in the Content Dictionary.</para>
  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CMP</systemitem></term>
<listitem><para>

A Commented Mathematical Property.
</para>
  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>FMP</systemitem></term><listitem><para>

A Formal Mathematical Property.  It may take an optional
<systemitem>kind</systemitem> attribute.

</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>


<section id="addfiles">
<title>Additional Information</title>

<para>
  Content Dictionaries contain just one part of the information that can be associated to
  a symbol in order to define its meaning and its functionality. &OM; Signature
  dictionaries, CDGroups, and possibly collections of
  extra mathematical properties, are used to convey the different aspects that as a whole
  make up a mathematical definition.
</para>

<section id="sigfiles">
  <title>Signature Dictionaries</title>

  <para>
    &OM; may be used with any type system. One just needs to produce a Content Dictionary
    which gives the constructors of the type system, and then one may build &OM; objects
    representing types in the given type system. These are typically associated with &OM;
    objects via the &OM; <varname>attribution</varname> constructor.
  </para>

<para>A Small Type System, called STS, has been designed to give semi-formal signatures to
&OM; symbols and is documented in&#160;<citation>OM_D132c</citation>.  The signature file
given in <xref linkend="arith1.sts"/> is based on this formalism. Using the same
mechanism, <citation>OMD132b</citation> shows how pure type systems can also be employed
to assign types to &OM; symbols.</para>

<section id="sect_sigpcdata">
<title>Abstract Specification  of a Signature Dictionary</title>

<para>
  Signature dictionaries have a header which specifies the type system being used and the
  Content Dictionary containing the symbols for which signatures are being given. Each
  signature takes the form of an &OM; object in an appropriate encoding.
</para>

<orderedlist>
  <listitem>
    <para>
      A <term id="typedef">type definition</term>: the name of the Content Dictionary or of the
      CDGroup (cfg. <xref linkend="ssec_cdgroups"/>) that represents the type system being
      used.
    </para>
  </listitem>
  <listitem>
    <para>
      A <emphasis>CD name</emphasis>: the name of the CD for which signatures are being defined.
    </para>
  </listitem>
  <listitem>
    <para>
      A <emphasis>review date</emphasis> as defined in <xref linkend="sect_func"/>.
    </para>
  </listitem>
  <listitem>
    <para>
      A <emphasis>status</emphasis>: as defined in <xref linkend="sect_func"/>.
    </para>
  </listitem>
  <listitem>
    <para>
      A series of <emphasis>signatures</emphasis> which are &OM; objects in some encoding.
      The objects must represent types as defined by the type definition.
    </para>
  </listitem>
</orderedlist>

</section>


<section id="sect_sigschema">
<title>A Relax NG Schema for a Signature Dictionary</title>

<para>
The following is a reference encoding of a signature dictionary,
designed to be used with Content Dictionaries in the &exml; encoding.
</para>

<literallayout role="rnc" file="omcdsig2.rnc"/>

  <para>
    The <systemitem>CDSignatures</systemitem> element specifies which CD the
    <systemitem>Signature</systemitem> elements contained pertain to via the
    <systemitem>cd</systemitem> attribute. The optional <systemitem>cdurl</systemitem> can
    be used to specify the canonical URI of that CD if it is not identifiable by other
    means. The <systemitem>CDSignatures</systemitem> element can take an optional
    <systemitem>version</systemitem> attribute which indicates to which version of the
    &OM; standard it conforms. In previous versions of this standard this attribute did
    not exist, so any &OM; object without such an attribute must conform to version 1 (or
    equivalently 1.1) of the &OM; standard.  Objects which conform to the description
    given in this document should have <systemitem>version="2.0"</systemitem>. The value
    of the <systemitem>version</systemitem> attribute on the
    <systemitem>CDSignatures</systemitem> element determines the default value for all
    contained <systemitem>OMOBJ</systemitem> elements.  Similarly, the value of the
    optional <systemitem>cdgroup</systemitem> attribute determines the default of
    <systemitem>cdgroup</systemitem> contained <systemitem>OMOBJ</systemitem> elements.
  </para>

  <para>
    The contents of the <systemitem>CDSignatures</systemitem> element are made up of
    <systemitem>CDSComment</systemitem>, <systemitem>CDSReviewDate</systemitem>, and
    <systemitem>CDSStatus</systemitem>, which are completely analogous to their CD
    counterparts (see <xref linkend="sect_pcdata"/>) and
    <systemitem>Signature</systemitem> elements, which we will describe by way of an
    example next.
  </para>
</section>


<section id="sect_sigex">
<title>Examples</title>

<para>An example of a signature dictionary for the type system STS and the
<systemitem>arith1</systemitem> Content Dictionary is given in <xref
linkend="arith1.sts"/>. Each signature entry is similar to the
following one for the &OM; symbol <systemitem>&lt;OMS cd="arith1"
name="plus"/></systemitem>: <literallayout><![CDATA[
<Signature name="plus">
<OMOBJ version="2.0">
 <OMA>
  <OMS name="mapsto" cd="sts"/>
  <OMA>
   <OMS name="nassoc" cd="sts"/> 
   <OMV name="AbelianSemiGroup"/>
  </OMA>
  <OMV name="AbelianSemiGroup"/>
 </OMA>
</OMOBJ>
</Signature>
]]></literallayout>
Conceptually, it associates the symbol
<systemitem>plus</systemitem> with an &OM;-encoded type; here an n-ary function from an
Abelian Semigroup to itself.
</para>
</section>
</section>

<section id="ssec_cdgroups">
<title>CDGroups</title>

<para>
  The CD Group mechanism is a convenience mechanism for identifying collections of CDs
  and specifying their location by an URI.  A CD
  Group file is an &exml; document used in the (static or dynamic) negotiation phase where
  communicating applications declare and agree on the Content Dictionaries which they
  process.  It is a complement, or an alternative, to the individual declaration of
  Content Dictionaries understood by an application.  
 >Additionally, a CD Group file can also be used as a catalog for
  defaulting the CD bases of &OM; symbols. Note that CD Groups do
  <emphasis>not</emphasis> affect the &OM; objects themselves.  Symbols in an object
  always refer to content dictionaries, not groups.</para>

 <para>For an application to declare that
it <quote>understands CDGroup G</quote> is exactly equivalent to, and
interchangeable with, the declaration that it <quote>understands
Content Dictionaries <math><msub><mi>x</mi><mn>1</mn></msub></math>,
<math><msub><mi>x</mi><mn>2</mn></msub></math>,&#160;
<phrase>&#8230;</phrase>&#160;
<math><msub><mi>x</mi><mi>n</mi></msub></math></quote>, where
<math><msub><mi>x</mi><mn>1</mn></msub></math>,&#160;
<phrase>&#8230;</phrase>&#160;
<math><msub><mi>x</mi><mi>n</mi></msub></math> are the members of
CDGroup G.</para>


<section id="sec_dtd_cdg">
<title>The Specification of CDGroups</title>


<para>CDGroups are &exml; documents, hence  a valid  CDGroup
 should 
<itemizedlist>
<listitem><para>be valid according to the schema given in
  <xref linkend="fig_cdgroup.dtd"/>,</para>
</listitem>
<listitem><para>adhere to the extra conditions on the content of the elements
  given in <xref linkend="sect_cdgpcdata"/>.</para>
</listitem>
</itemizedlist>
</para>

<para>Apart from some header information such as <systemitem>CDGroupName</systemitem> and
<systemitem>CDGroup</systemitem> version, a CDGroup is simply an unordered list of
CDs, identified by name and optionally version number and URL.</para>


<figure id="fig_cdgroup.dtd">
    <title>Relax NG Specification of CDGroups</title>
    <literallayout role="rnc" file="omcdgroup2.rnc"/>
</figure>

<para>
  The <systemitem>CD</systemitem> element can take optional
  <systemitem>version</systemitem> attribute which indicates to which version of the &OM;
  standard it conforms.  In previous versions of this standard this attribute did not
  exist, so any &OM; object without such an attribute must conform to version 1 (or
  equivalently 1.1) of the &OM; standard.  Objects which conform to the description given
  in this document should have <systemitem>version="2.0"</systemitem>.
</para>
</section>

<section id="sect_cdgpcdata">
<title>Further Requirements of a CDGroup</title>

<para>The notion of being a valid CDGroup implies that the following
requirements on the content of the elements described by the 
schema given in
  <xref linkend="sect_sigschema"/> are also met.</para>


<variablelist>
<varlistentry><term><systemitem>CDGroup</systemitem></term>
<listitem><para>The &exml; element <systemitem>CDGroup</systemitem> is the outermost
  element in a CDGroup document.</para>
  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDGroupName</systemitem></term>
<listitem>

<para>The text occurring in the <systemitem>CDGroupName</systemitem>
  element corresponds to the name of the CDGroup. For the syntactical
  requirements, see <systemitem>CDName</systemitem> in <xref linkend="sect_pcdata"/>.</para>
  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDGroupVersion</systemitem></term>
<term><systemitem>CDGroupRevision</systemitem></term>
<listitem>
<para>The text occurring in these elements contains the major and minor
version numbers of the CDGroup.
</para>
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDGroupURL</systemitem></term>
<listitem><para>The text occurring in the <systemitem>CDGroupURL</systemitem>
  element identifies the location of the CDGroup file, not necessarily
  of the member Content Dictionaries. If the
  <systemitem>CDGroupURL</systemitem> element is missing, it defaults to the URL of
  the current CD group file. For the syntactical
  requirements, see <systemitem>CDURL</systemitem> in <xref linkend="sect_pcdata"/>.</para>
  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDGroupDescription</systemitem></term>
<listitem><para>The text occurring in the
<systemitem>CDGroupDescription</systemitem> element describes the
mathematical area of the CDGroup.</para>
  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDGroupMember</systemitem></term>
<listitem><para>The &exml; element <systemitem>CDGroupMember</systemitem>
  encloses the data identifying each member of the CDGroup.</para>
  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDGroupInclude</systemitem></term>
<listitem><para>The text content of the
<systemitem>CDGroupInclude</systemitem> identifies an external CD group file whose CDGroup
members are to be included into the current one. Technically: the set of CDs of CD group
given by a CD group file with <systemitem>CDGroupInclude</systemitem> elements is
determined by recursive flattening: The cd group has all the CDs given directly by the
<systemitem>CDGroupMember</systemitem> elements together with those CDs from CD groups
referenced in the <systemitem>CDGroupInclude</systemitem> elements. If this leads to
duplicate <systemitem>CDName</systemitem>s, then directly specified CDs are prioritized,
for duplications between referenced CD groups, the latter one is prioritized.
For the syntactical
  requirements, see <systemitem>CDURL</systemitem> in <xref
  linkend="sect_pcdata"/>.</para>
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDName</systemitem></term>
<listitem>
  <para>The text occurring in the
  <systemitem>CDName</systemitem> element names the referenced Content Dictionary (see
  <systemitem>CDURL</systemitem> below) in this CD group, it must be unique in the CD group. In particular,
  <systemitem>OMS</systemitem> elements in an <systemitem>OMOBJ</systemitem> whose
  <systemitem>cdgroup</systemitem> attribute references the current CD group derive their CD base
  via this <systemitem>CDName</systemitem>. For the syntactical requirements, see
  <systemitem>CDName</systemitem> in <xref linkend="sect_pcdata"/>.</para>
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDVersion</systemitem></term><listitem><para>The
  text occurring in the <systemitem>CDVersion</systemitem> element
  identifies which version of the Content Dictionary is to be taken as
  member of the CDGroup. This element is optional. In case it is
  missing, the latest version is the one included in the CDGroup.  For
  the syntactical requirements, see <systemitem>CDVersion</systemitem>
  in <xref linkend="sect_pcdata"/>.</para>
  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDURL</systemitem></term>
<listitem>

<para>The text occurring in the <systemitem>CDURL</systemitem> element
  identifies the location of the Content Dictionary to be taken as
  member of the CDGroup. This element is optional. In case it is
  missing, the location of the CDGroup identified by the element
  <systemitem>CDGroupURL</systemitem> is assumed.  For the syntactical
  requirements, see <systemitem>CDURL</systemitem> in <xref
  linkend="sect_pcdata"/>.</para>
  
</listitem>
</varlistentry>
<varlistentry><term><systemitem>CDComment</systemitem></term><listitem><para>See
  <systemitem>CDComment</systemitem> in <xref
  linkend="sect_pcdata"/>.</para>



</listitem>
</varlistentry>
</variablelist>

</section>
</section>
</section>

<section id="cdapprove">
<title>Content Dictionaries Reviewing Process</title>

<para>
  The &OM; Society is responsible for implementing a review and referee process to assess
  the accuracy of the mathematical content of Content Dictionaries.  The status (see
  <systemitem>CDStatus</systemitem>) and/or the version number (see
  <systemitem>CDVersion</systemitem> ) of a Content Dictionary may change as a result of
  this review process.
</para>
</section>
</chapter>

<chapter id="cha_comp">
<title>&OM; Compliance</title>

<para>
  Applications that meet the requirements specified in this chapter may label themselves
  as <emphasis>OpenMath compliant</emphasis>. &OM; compliance is defined so as to maximize
  the potential for interoperability amongst &OM; applications.
</para>

<section id="sec_compl_encoding">
<title>Encodings</title>
<para>This standard defines two reference encodings for &OM;, the binary
encoding and &exml; encoding,  defined in <xref linkend="cha_enco"/>.</para>

<para>As a minimum, an &OM; compliant application, which accepts or generates
&OM; objects, <emphasis>must</emphasis> be capable of doing so using  the &exml; encoding.
The ability to use other encodings is optional.</para>

<section id="sec_compl_xml_encoding">
<title>The XML Encoding</title>

<section id="sec_compl_xml_encoding_val">
<title>Generating Valid XML</title>

<para>
  All &OM; objects generated by a compliant &OM; application must validate against the
  Relax NG Schema given in <xref linkend="app_openmath.rng"/>.
</para>

</section>

<section id="sec_compl_xml_encoding_float">
<title>Decimal versus Hexadecimal Float Representation</title>

<para>
In the &exml; 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 <emphasis>not a number</emphasis> (NaN) which is defined in the
IEEE standard <citation>ieee754_85</citation> 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.
</para>

<para>
The semantics of the &OM; object
<systemitem>&lt;OMF dec="NaN"/&gt;</systemitem> is that it represents
<emphasis>any</emphasis> NaN, and a phrasebook may substitute any
specific NaN value when processing it.  The semantics of a NaN in
hexadecimal notation however, such as 
<systemitem>&lt;OMF hex="FFF8000000000001"/&gt;</systemitem>,
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. 
</para>


</section>
</section>

</section>

<section id="sec_compl_omforeign">
<title>&OM; Foreign Objects</title>

<para> An &OM; <xref linkend="foreignobj"/> may be attributed with a string indicating
the format of its contents.  Although this information is optional, an
&OM;-compliant application which generates &OM; <xref linkend="foreignobj"/>s 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 <xref linkend="foreignobj"/> are in an
&exml; dialect, the namespace <citation>xmlns</citation> of the
&exml; dialect is used as the value of the encoding.  For example
(using the &exml; encoding):
<literallayout><![CDATA[<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>]]></literallayout>
Where the contents of the <xref linkend="foreignobj"/> is a format other than &exml;,
it is recommended that its MIME type <citation>rfc2046</citation> is
used as the value of the encoding.
For example (again using the &exml; encoding):
<literallayout><![CDATA[<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>]]></literallayout>
</para>

<para> An exception to the above guidelines occurs when a MathML object
is converted to &OM;.  MathML also has an
<systemitem>encoding</systemitem> attribute which can appear in various
places and whose format is a string.  Only two values are predefined,
<systemitem>MathML-Content</systemitem> and
<systemitem>MathML-Presentation</systemitem>, and these may appear in
the resulting &OM; object despite the fact that they are not namespaces
as recommended above. For example the following MathML expression:
<literallayout><![CDATA[<semantics 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>]]></literallayout>
is equivalent to the &OM; expression:
<literallayout><![CDATA[<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>]]></literallayout>

Since in MathML the <systemitem>encoding</systemitem> 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 &OM;
<systemitem>encoding</systemitem> attribute.  This is unfortunate but
unavoidable.
</para>
</section>

<section id="sec_compl_cd">
<title>Content Dictionaries</title>

<para>
  An &OM; compliant application <emphasis>must</emphasis> be able to support the error
  Content Dictionary defined in <xref linkend="errorcd"/>.
</para>

<para>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 <systemitem>all</systemitem>.</para>

<para>If a compliant application supports a Content Dictionary then it must
explicitly declare any symbols in the Content Dictionaries that are not
supported. <xref linkend="phrasebook"/>s are encouraged to support every symbol in the 
Content Dictionaries.</para>

<para>Symbols which are not listed as unsupported are
<emphasis>supported</emphasis> by the application. The meaning of
<emphasis>supported</emphasis> will depend on the application
domain. For example an &OM; renderer should provide a default display
for any &OM; 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
<emphasis>phrasebooks</emphasis> 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 &OM; compliance does
<emphasis>not</emphasis> imply any guarantee by the &OM; Society on
the accuracy of these representations.</para>


<para>
  Given the inheritance mechanism for CD bases &OM;
  symbols, Content Dictionaries available from the official &OM; repository at
  <systemitem>http://www.openmath.org</systemitem> need only be referenced by name, other
  Content Dictionaries <emphasis>should</emphasis> be referenced using the
  <systemitem>CDBase</systemitem> and the <systemitem>CDName</systemitem>
  or via the CD Group-based CD base inheritance mechanism.
</para>

<para>When receiving an &OM; symbol, e.g.&#160;<math><mi>s</mi></math>,
 that is not defined in a supported Content Dictionary, a
 compliant application will act as if it had received the &OM; object
 <math display="block"><mi
 mathvariant="bold">error</mi><mo>(</mo><mi>unhandled_symbol</mi><mo
 separator="true">,</mo><mi>s</mi><mo>)</mo></math> where
 <systemitem>unhandled_symbol</systemitem> is the symbol from the
 error Content Dictionary.</para>


<para>Similarly if it receives a symbol, e.g. <math><mi>s</mi></math>,
from an unsupported Content Dictionary, it will act as if it had
received the &OM; object <math display="block"><mi
mathvariant="bold">error</mi><mo>(</mo><mi>unsupported_cd</mi><mo
separator="true">,</mo><mi>s</mi><mo>)</mo></math></para>

<para>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 &OM; object <math
display="block"><mi
mathvariant="bold">error</mi><mo>(</mo><mi>unexpected_symbol</mi><mo
separator="true">,</mo><mi>s</mi><mo>)</mo></math></para>
</section>

<section id="sec_comp_lex">
<title>Lexical Errors</title>

<para>The previous section defines the behaviour of a compliant
application upon receiving well formed &OM; objects containing
unexpected symbols.  This standard does not specify any behaviour for
an application upon receiving ill-formed objects.</para>
</section>


<section id="sec_compl_om1">
<title>&OM;&#160;1 Objects</title>
<para>
Compliant &OM;&#160;2 documents and Content Dictionary files using the
reference &exml; encodings must be valid
according to the specified schema, and so will use the namespaces
<systemitem>http://www.openmath.org/OpenMath</systemitem>
and 
<systemitem>http://www.openmath.org/OpenMathCD</systemitem>
respectively. Similarly CD Group and Signature files will use
<systemitem>http://www.openmath.org/OpenMathCDG</systemitem>
and
<systemitem>http://www.openmath.org/OpenMathCDS</systemitem>.
</para>

<para> Applications may also support &OM;&#160;1.
&exml;-encoded &OM;&#160;1 documents may be in either the 
<systemitem>http://www.openmath.org/OpenMath</systemitem>
namespace or in no-namespace (i.e., do not have any xmlns
declarations).
An application may accept either of
these forms. Note however that &OM;  documents that have a version attribute
should validate against the schema for &OM;&#160;2 (or later versions) and
so should always use the &OM; namespace.
&exml;-encoded &OM;&#160;1 CD files, CD Group files and CD Signature
files must be in no-namespace. An &OM;&#160;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 <systemitem>OMOBJ</systemitem>) the &OM;&#160;1
documents should conform to the schema specified in this standard.
</para>

<para>The use of documents in no-namespace should be
restricted to reading existing  &OM;&#160;1 files.
No &OM;&#160;2 application should generate documents in this form.
</para>
</section>

</chapter>

<appendix id="app_cdfiles">
<title>CD Files</title>

<section id="app_cdcd">
<title>The <filename>meta</filename> Content Dictionary</title>

<literallayout role="xml" file="meta.ocd"/>
</section>

<section id="arith1.ocd">
  <title>The  <filename>arith1</filename> Content Dictionary File</title>
  
  
<literallayout role="xml" file="arith1.ocd"/>

</section>

<section id="arith1.sts">
  <title>The  <filename>arith1</filename> STS Signature File</title>
  
  
  
<literallayout role="xml" file="arith1.sts"/>

</section>

<section id="mathml.cdg">
  <title>The  <filename>MathML</filename> CDGroup</title>
  
  
<literallayout role="xml" file="mathml.cdg"/>



</section>

<section id="errorcd">
  <title>The <filename>error</filename> Content Dictionary</title>
  
<literallayout role="xml" file="error.ocd"/>

</section>

</appendix>


<appendix id="app_openmath.rng">
  <title>&OM; Schema in Relax NG XML Syntax (Normative)</title>
  
  <para>This is the Relax NG Schema described in <xref linkend="sec_xml"/>
    expressed according to the Relax NG XML Syntax.
  </para>
  <literallayout role="rng" file="openmath2.rng"/>
</appendix>

<appendix id="app_relaxrestricted">
  <title>Restricting the &OM; Schema (Non-Normative)</title>
  
  <para> Relax NG allows one to state constraints such as <emphasis>
      if the cd attribute of OMS is arith1 then the name attribute must be
      one of lcm, gcd, plus etc.</emphasis> Thus it is easy to use a
    stylesheet to generate for any given CD, a Relax NG schema that
    expresses the constraint that an <systemitem>OMS</systemitem> naming
    that CD must only use symbols defined in the specified dictionary.
    Similarly it is possible to use the <emphasis>role</emphasis>
    information contained in the CD to restrict which symbols can be the
    first child of an <systemitem>OMBIND</systemitem> or the odd-numbered
    children of an <systemitem>OMATP</systemitem>. 
  </para>
  
  <para> The modularisation mechanisms of Relax NG then allow one to
    include these schema for all the CDs that you want to allow and, for
    example, to replace the regexp-based validation of the
    <systemitem>OMS</systemitem> attributes by explicit lists of allowed
    CD names, and for each CD Name, a list of allowed symbol names.
  </para>
  
  <para>
    For example, a CD-specific Relax NG Schema for the arith1 CD shown in
    <xref linkend="arith1.ocd"/> would look like:
    <literallayout>
<![CDATA[<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0" datatypeLibrary="">
  <define name="cd.attlist.OMS" combine="choice">
    <attribute name="cd">
      <value type="string">arith1</value>
    </attribute>
    <attribute name="name">
      <choice>
        <value type="string">lcm</value>
        <value type="string">gcd</value>
        <value type="string">plus</value>
        <value type="string">unary_minus</value>
        <value type="string">minus</value>
        <value type="string">times</value>
        <value type="string">divide</value>
        <value type="string">power</value>
        <value type="string">abs</value>
        <value type="string">root</value>
        <value type="string">sum</value>
        <value type="string">product</value>
      </choice>
    </attribute>
  </define>
</grammar>]]>
</literallayout>
or, using the Relax NG compact syntax:
<literallayout>
  cd.attlist.OMS |= 
  attribute cd {string "arith1" },
  attribute name {
  string "lcm" |
  string "gcd" |
  string "plus" |
  string "unary_minus" |
  string "minus" |
  string "times" |
  string "divide" |
  string "power" |
  string "abs" |
  string "root" |
  string "sum" |
  string "product" }
</literallayout>
</para>

<para> To build a schema that allows only symbols from arith1 we just
  need to include the &OM; schema described in <xref linkend="ssec_xml"/>, override the attribute declarations for
  OMS, and then include the schema for arith1.  For example:
  <literallayout>
    <![CDATA[<?xml version="1.0" encoding="UTF-8"?>
    <grammar xmlns="http://relaxng.org/ns/structure/1.0">
      <include href="openmath.rng">
        <define name="attlist.OMS">
          <ref name="cd.attlist.OMS"/>
        </define>
      </include>
      <include href="arith1.rng"/>
    </grammar>]]>
  </literallayout>
  or, in the compact syntax:
  <literallayout>
    include "openmath.rnc" {
    attlist.OMS = cd.attlist.OMS}
    
    include "arith1.rnc"
  </literallayout>
  Using this approach it is possible to include as many files as
  required.
</para>

</appendix>

<appendix id="app_xsd">
  <title>&OM; Schema in XSD Syntax (Non-Normative)</title>
  
  <para>This is an XSD Schema generated from the Relax NG Schema described in 
    <xref linkend="sec_xml"/>.
  </para>
  <literallayout role="xsd" file="openmath2.xsd"/>
</appendix>

<appendix id="app_dtd">
  <title>&OM; DTD (Non-Normative)</title>
  
  <para>This is a DTD generated from the Relax NG Schema described in 
    <xref linkend="sec_xml"/>.  Note that we cannot express the 
    fact that the <systemitem>OMFOREIGN</systemitem> element can
    contain any well-formed XML, so we have simply restricted it to
    contain any XML defined in the DTD.
  </para>
  <literallayout role="dtd" file="openmath2.dtd"/>
</appendix>


<appendix id="app_dts" revisionflag="added">
  <title>&OM; .d.ts (Normative)</title>
  
  <para>
    JSON Schemas <citation>handrewsjsonschema</citation> define a vocabulary 
    allowing us to validate and annotate JSON documents. 
    Unfortunately, JSON schema is often tedious to read and write for humans. 
    This is especially true when it comes to recursively defined data 
    structures. As OpenMath has many recursive structures, the normative JSON
    encoding is instead authored as a human readable TypeScript <citation>url_typescript</citation> definition file. 
    This file can be found below. 
  </para>

  <literallayout role="dts" file="openmath2.d.ts"/>

  <para>
    While JSON provides many types, sometimes more restrictions than
    the general type is required. The JSON Schema provides several
    facilities for this, for example strings matching a particular
    regular expression.
  </para>
  <para>
    The schema uses the following helper types:
  </para>
  <itemizedlist>
    <listitem>
      <para>
      <systemitem>uri</systemitem> represents any URI encoded as a string.
        This uses the JSONSchema <systemitem>format: uri</systemitem>.
      </para>
    </listitem>
    <listitem>
      <para>
        <systemitem>name</systemitem> represents any valid name. In this schema uses
        any kind of string.
      </para>
    </listitem>
    <listitem>
      <para>
        <systemitem>integer</systemitem>represents an arbitrary precise JSON-native
        integer. Uses JSON numbers as underlying type, and the JSON
        Schema <systemitem>number</systemitem> type.
      </para>
    </listitem>
    <listitem>
      <para>
        <systemitem>decimalInteger</systemitem> represents a string representing the
        decimal expansion of an integer. Uses the regular expression
        <systemitem>^-?[0-9]+$</systemitem>.
      </para>
    </listitem>
    <listitem>
      <para>
        <systemitem>hexInteger</systemitem> represents a string representing the
        heximadecimal expansion of an integer. Uses the regular
        expression <systemitem>^-?x[0-9A-F]+.$</systemitem>.
      </para>
    </listitem>
    <listitem>
      <para>
        <systemitem>float</systemitem> represents any IEEE 32-bit integer, represented
        as a native JSON integer.
      </para>
    </listitem>
    <listitem>
      <para>
        <systemitem>decimalFloat</systemitem> represents a string representing the
        decimal expansion of an IEEE floating point number. Uses the
        regular expression
        <systemitem>^(-?)([0-9]+)?(\.[0-9]+)?([eE](-?)[0-9]+)?</systemitem>.
      </para>
    </listitem>
    <listitem>
      <para>
      <systemitem>hexFloat</systemitem> represents a string representing the hexadecimal expansion of an IEEE floating point number.
Uses the regular expression <systemitem>^([0-9A-F]+)$</systemitem>.
      </para>
    </listitem>
    <listitem>
      <para>
        <systemitem>byte</systemitem> represents a byte of data represented as an
        integer, between <systemitem>0</systemitem> and
        <systemitem>255</systemitem> (inclusive).
      </para>
    </listitem>
    <listitem>
      <para>
        <systemitem>base64string</systemitem> represents a string representing a set
        of bytes encoded as a <systemitem>base64</systemitem> string. Uses
        the regular expression
        <systemitem>^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$</systemitem>.
      </para>
    </listitem>
  </itemizedlist>
    <para>
      The main type in the schema is the <systemitem>omel</systemitem> type. 
      It is defined as any of the following:
    </para>
    <itemizedlist>
      <listitem>
        <para>
          <systemitem>OMS</systemitem>
        </para>
      </listitem>
      <listitem>
        <para>
          <systemitem>OMV</systemitem>
        </para>
      </listitem>
      <listitem>
        <para>
          <systemitem>OMI</systemitem>
        </para>
      </listitem>
      <listitem>
        <para>
          <systemitem>OMB</systemitem>
        </para>
      </listitem>
      <listitem>
        <para>
          <systemitem>OMSTR</systemitem>
        </para>
      </listitem>
      <listitem>
        <para>
          <systemitem>OMF</systemitem>
        </para>
      </listitem>
      <listitem>
        <para>
          <systemitem>OMA</systemitem>
        </para>
      </listitem>
      <listitem>
        <para>
          <systemitem>OMBIND</systemitem>
        </para>
      </listitem>
      <listitem>
        <para>
          <systemitem>OME</systemitem>
        </para>
      </listitem>
      <listitem>
        <para>
          <systemitem>OMATTR</systemitem>
        </para>
      </listitem>
      <listitem>
        <para>
          <systemitem>OMR</systemitem>
        </para>
      </listitem>
    </itemizedlist>
    <para>
      Concrete (non-normative) examples can be found in <xref linkend="sec_json-the-json-encoding" />. 
    </para>
</appendix>

<appendix id="app_json" revisionflag="added">
  <title>&OM; .json Schema (Non-Normative)</title>
  
  <para>
    This section contains the  non-normative JSON Schema
    <citation>handrewsjsonschema</citation> file for the
    &OM; JSON encoding. It is generated using
    <citation>url_vega-ts-jscon-schema-generator</citation> from the TypeScript definition file in <xref linkend="app_json"/>. 
    It can be used to perform machine-validation of JSON-encoded &OM; objects. 
  </para>
  <literallayout role="dts" file="openmath2.json"/>
</appendix>

<appendix  id="app_whats_new">
  <title>Changes between &OM;&#160;1.1 and &OM;&#160;2 (Non-Normative)</title>
  
  
  <para>In this appendix we describe the major changes that occurred
    between version 1.1 and version 2 of the &OM; standard. All changes to
    the encodings and content dictionaries have been designed to be
    backward compatible, in other words all existing &OM; objects and
    Content Dictionaries are still valid in &OM;&#160;2.  On the other hand an
    existing  &OM;&#160;1.1 application may not be able to process &OM;&#160;2
    objects.
  </para>
  
  <section id="chgformal">
    <title>Changes to the Formal Definition of Objects</title>
    
    <para>Additional features of abstract objects have been
      introduced:</para>
    <itemizedlist>
      <listitem>
        <para>&OM; symbols have an optional role qualifier which restricts the
          place where they may occur within <xref linkend="compoundobj"/>
          Although part of the abstract description of a symbol this information
          is intended to be stored in the CD.  In the &exml; encoding it may be
          used to provide a more restricted schema leading to tighter
          validation.
        </para>
      </listitem>
      <listitem>
        <para>
          In addition to their <emphasis>name</emphasis> and
          <emphasis>cd</emphasis> properties, symbols now have an optional
          <emphasis>cdbase</emphasis> property.  This can be used to
          disambiguate between two CDs which are produced independently but have
          the same name, and can also be used to produce a canonical URI for any
          &OM; symbol for use in frameworks such as RDFS or MathML which
          need one.
        </para>
      </listitem>
      <listitem>
        <para>An &OM; object may be attributed with a non-&OM; object
          using the new
          <emphasis>foreign</emphasis> constructor.  This allows an
          &exml;-encoded &OM; object to be attributed with appropriate
          Presentation MathML, for example, or a base-64 encoded MPEG file of
          its aural rendering.
        </para>
      </listitem>
      <listitem>
        <para>In addition, an &OM; <xref linkend="errorobj"/> may take as its
arguments non-&OM; objects wrapped in the new
<emphasis>foreign</emphasis> constructor.
        </para>
      </listitem>
      <listitem>
        <para>The new role property can be used to indicate that a
          symbol is an <emphasis>attribution</emphasis>, in which case an
          application may ignore or remove it, or a <emphasis>semantic
            attribution</emphasis> in which case removing it is no longer
          guaranteed to produce an equivalent object.  
        </para>
      </listitem>
      <listitem>
        <para>Restrictions on the names of symbols, variables and
          content dictionaries have been relaxed to be compatible with XML and
          to be less Anglo-Saxon.
        </para>
      </listitem>
    </itemizedlist>
    
  </section>
  
  <section id="chgenc">
    <title>Changes to the encodings</title>
    
    <para>The &OM; version 2 standard still mandates two encodings:
      &exml; and binary. The &exml; encoding in particular has been
      updated to reflect the latest development of &exml; and is now a
      full &exml; application.  Version 2
      encodings are backward compatible with version 1.1 encodings.
    </para>
    <itemizedlist>
      <listitem>
        <para>Both encodings have been updated to support the
          changes to the model of abstract objects described above.
        </para>
      </listitem>
      <listitem>
        <para>Encodings support internal and external sharing of
          objects</para>
      </listitem>
      <listitem>
        <para>An optional attribute defining the version of the
          encoding can be specified for the encoded object</para>
      </listitem>
      <listitem>
        <para>The &exml; encoding in version 2 is defined by a Relax
          NG schema and the mandated character-based grammar of
          version 1 has been removed, while the DTD has been relegated
          to an Appendix.
        </para>
      </listitem>
      <listitem>
        <para>The symbolic values <systemitem>INF</systemitem>,
<systemitem>-INF</systemitem> and <systemitem>NaN</systemitem> have
been added to the decimal attribute of an <systemitem>OMF</systemitem>
in the &exml; encoding,
and guidelines on the interpretation of <systemitem>NaN</systemitem>s
added to the compliance section.
          </para>
      </listitem>
      <listitem>
        <para>The Binary encoding has been extended to support the streaming
        of objects.</para>
      </listitem>
    </itemizedlist>
    
    
  </section>
  
  
  <section id="chgcd">
    <title>Changes to Content Dictionaries</title>
    
    <itemizedlist>
      <listitem>
        <para>In &OM; version 2 Content Dictionaries are defined in
          terms of 
          the abstract information content that needs
          to be specified for defining &OM; symbols. The current
          implementation is thus just one possible encoding of this abstract model.
        </para>
      </listitem>
      <listitem>
        <para> The <emphasis>CDUses</emphasis> element is not part of this
          information model and has been made optional and deprecated in the reference encoding
          since it is trivial to extract its content automatically from the CD.
        </para>
      </listitem>
      <listitem>
        <para>
          A CD may now, optionally, define its cdbase.
        </para>
      </listitem>
      <listitem>
        <para>
          A CD symbol definition may now, optionally, define its role.
        </para>
      </listitem>
      <listitem>
        <para>
          An FMP may, optionally, have a <systemitem>kind</systemitem>
attribute for use in classifying different kinds of definitions.  The
details of how this attribute is used are not mandated by the standard.
        </para>
      </listitem>
      <listitem>
        <para>The XML encoded Content Dictionaries now use elements from
        the namespace <systemitem>http://www.openmath.org/OpenMathCD</systemitem>.</para>
      </listitem>
    </itemizedlist>
  </section>
</appendix>

<appendix  id="om2-revisions">
  <title  revisionflag="added">Revisions to  &OM;&#160;2 (Non-Normative)</title>

  <para revisionflag="added">
    In this appendix we describe the revisions to the &OM; 2  standard. All of these
    revisions are either editorial, clarifications, or additions, so they only change
    the &OM; 2 standard  conservatively. 
  </para>
  
    <section id="chgr1">
    <title>Changes in 2.0 Revision 1 (July 2017) </title>
    
    <itemizedlist>
      <listitem>
	<para>
	    There are now explicitly two XML encodings: the previous one and 
	    the Strict Content MathML one. This necessitated changes to the 
	    preamble and the start of Chapter 3.
        </para>
      </listitem>
      <listitem>
	<para>
		The description of the encoding of <systemitem>xf&zsp;f&zsp;f&zsp;f&zsp;f&zsp;f&zsp;f1</systemitem> in base 256 was corrected (the <systemitem>0xab</systemitem> (base 256/positive) byte was omitted and <systemitem>0xF1</systemitem> had been written <systemitem>0xFI</systemitem>.
        </para>
      </listitem>
      <listitem>
	<para>
	  The phrase <quote>in little endian format</quote> was unhelpfully included in the description of the binary integer encoding, which contradicted the later <quote>network byte order</quote>. Now removed.
        </para>
      </listitem>
      <listitem>
	<para>
		<xref linkend="sec_xml-desc"/> described the OpenMath XML value of <systemitem>hex</systemitem> as <quote>from lowest to highest bits using a  least significant byte ordering</quote>.  Replaced by the current <quote>in network byte order</quote>.
        </para>
      </listitem>
      <listitem>
	<para>
		The example of binary encoding of floats in <xref linkend="sec_bin-desc"/> For example, 0.1 is encoded as <systemitem>0x03 0x000000000000f03f</systemitem>" was wrong, and has been replaced by the same example as the XML encoding.
        </para>
      </listitem>
      <listitem>
	<para>A citation to MathML 3 was added.
        </para>
      </listitem>
      <listitem>
	<para>The <quote>Note on names</quote>, which used to refer to Unicode 2.0, has been upgraded to allow for XML 1.0 5th edition and more specifically erratum NE17 in <citation>erratum_NE17</citation>, so that the current version of Unicode is incorporated.
        </para>
      </listitem>
      <listitem>
	<para>Various included example files (such as <filename>arith1.ocd</filename>) have been updated to match the versions on the OpenMath web site.
        </para>
      </listitem>
    </itemizedlist>
  </section>

    <section id="chgr2">
    <title>Changes in 2.0 Revision 2 (August 2018)</title>
    <itemizedlist>
      <listitem>
	<para>
	 <emphasis>cdbase</emphasis> and <emphasis>cd url</emphasis> are now defined in terms of
	 Internationalized Resource Identifiers (IRIs) <citation>IETF3987</citation>.
        </para>
      </listitem>
      <listitem>
	<para>
	  The notion of the head of an attribution has been introduced to clarify the
	  notion of an attributed variable.
	</para>
	<para>
	  The notion of alphabetic renaming has been clarified. It now specifies what
	  should happen in the presence of attributed bound variables: the variables in
	  the attribute values need to be renamed as well.  
	</para>
	<para>
	  Duplicate bound variables in binders have been deprecated, since they make no
	  sense. The fallback semantics of duplicate variables been clarified for the case
	  of attributed bound variables.
	</para>
      </listitem>
      <listitem>
	<para>
	 The RelaxNG schema has been corrected to allow hexadecimal representation of integers to match 
	 <xref linkend="sec_xml-desc"/>.
        </para>
      </listitem>
      <listitem>
	<para>
	  For a better alignment with MathML3, the <systemitem>OMOBJ</systemitem> element
	  has been extended by a <systemitem>cdgroup</systemitem> attribute that specifies
	  a CDGroup file that acts as a catalog for the CD bases of
	  <systemitem>OMS</systemitem> elements in that
	  <systemitem>OMOBJ</systemitem>.  The inheritance for CD bases of OMS has been
	  clarified. See sections 3.1.2 and 4.4.2.
	</para>
      </listitem>
      <listitem>
	<para>
	  The meaning of <systemitem>CDGroup/CDGroupMember/CDName</systemitem> has been
	  clarified in terms of uniqueness conditions and correspondence to name of the
	  referenced CD.
	</para>
      </listitem>
      <listitem>
	<para>
	  An inclusion mechanism has been introduced to make the
	  <systemitem>cdgroup</systemitem> catalog mechanism in MathML more realistic and
	  manageable.
	</para>
      </listitem>
      <listitem>
	<para>
	  The top level elements of the XML encodings of CDs, CD signatures, and CD groups
	  have been augmented with <systemitem>version</systemitem> attribute and the
	  first two with a <systemitem>cdgroup</systemitem> attribute that give the
	  defaults for the contained <systemitem>OMOBJ</systemitem> elements.
	</para>
      </listitem>
    </itemizedlist>
  </section>

  <section id="chgr3" revisionflag="added">
    <title>Changes in 2.0 Revision 3 (July 2019)</title>
    <itemizedlist>
      <listitem>
        <para>
          A newly endorsed JSON encoding was added. 
          JSON is a standard available in many programming languages, in particular in JavaScript and other languages powering modern web applications. 
          The &OM; JSON enocoding thus makes &OM; web-interoperable. 
          See newly added Section 3.3, Appendix F and Appendix G. 
        </para>
      </listitem>
    </itemizedlist>
  </section>
</appendix>


<bibliography id="bibliography">
  <title>Bibliography</title>
  
  <biblioentry id="POSIX" role="book">
    <author><othername>IEEE and The Open Group</othername></author>
    <title>Std 1003.1, 2003 Edition, The Open Group Base Specifications Issue 6 </title>
    <pubdate>2003</pubdate>
    <bibliomisc>http://www.unix.org/version3/ieee_std.html</bibliomisc>
  </biblioentry>
  
  <biblioentry id="SCSCP13" role="misc">
   <author><firstname>S.</firstname> <surname>Freundt</surname></author>
   <author><firstname>P.</firstname> <surname>Horn</surname></author>
   <author><firstname>A.</firstname> <surname>Konovalov</surname></author>
   <author><firstname>S.</firstname> <surname>Linton</surname></author>
   <author><firstname>D.</firstname> <surname>Roozemond</surname></author>
   <title>Symbolic Computation Software Composability Protocol SCSCP Specification 1.3</title>
    <pubdate>March 22, 2009</pubdate>
    <bibliomisc>https://github.com/OpenMath/scscp/blob/master/revisions/SCSCP_1_3.pdf</bibliomisc>
  </biblioentry>
  
  <biblioentry id="IETF2396" role="misc">
    <author><othername>IETF</othername></author>
    <title>RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax</title>
    <pubdate>August 1998</pubdate>
    <bibliomisc>http://www.ietf.org/rfc/rfc2396.txt</bibliomisc>
  </biblioentry>
  
  <biblioentry id="IETF3987" role="misc">
    <author><othername>IETF</othername></author>
    <title>RFC 3987 - Internationalized Resource Identifiers (IRIs)</title>
    <pubdate>January 2005</pubdate>
    <bibliomisc>http://www.ietf.org/rfc/rfc3987.txt</bibliomisc>
  </biblioentry>
  
  <biblioentry id="XSD" role="book">
    <author><othername>World Wide Web Consortium</othername></author>
    <title>XML Schema Part 1: Structures &amp; Part 2: Datatypes</title>
    <pubdate>May 2001</pubdate>
    <bibliomisc>http://www.w3.org/TR/xmlschema-1/</bibliomisc>
    <bibliomisc>http://www.w3.org/TR/xmlschema-2/</bibliomisc>
  </biblioentry>
  
  <biblioentry id="RELAX-COMPACT" role="book">
    <author><othername>OASIS Committee Specification</othername></author>
    <title>RELAX NG Compact Syntax</title>
    <pubdate>November 2002</pubdate>
  </biblioentry>
  
  <biblioentry id="RELAX" role="book">
    <author><othername>OASIS Committee Specification</othername></author>
    <title>RELAX NG Specification</title>
    <pubdate>December 2001</pubdate>
    <bibliomisc>http://www.oasis-open.org/committees/relax-ng/spec-20011203.html</bibliomisc>
  </biblioentry>
  
  <biblioentry id="MAPLE" role="book">
    <author><firstname>B.</firstname> <othername>W.</othername> <surname>Char</surname></author>
    <author><firstname>K.</firstname> <othername>O.</othername> <surname>Geddes</surname></author>
    <author><firstname>G.</firstname> <othername>H.</othername> <surname>Gonnet</surname></author>
    <author><firstname>S.</firstname> <othername>M.</othername> <surname>Watt</surname></author>
    <title>Maple User's Guide</title>
    <pubdate>1985</pubdate>
    <publisher><publishername>WATCOM Publications Limited</publishername></publisher>
    <edition>4th</edition>
    <bibliomisc>http://www.maplesoft.com/home.html</bibliomisc>
  </biblioentry>
  
  <biblioentry id="LIE" role="book">
    <author><firstname>M.</firstname> <othername>A.</othername> <surname>A. van Leeuwen</surname></author>
    <author><firstname>A.M.</firstname> <surname>Cohen</surname></author>
    <author><firstname>B.</firstname> <surname>Lisser</surname></author>
    <title>LiE: A Package for Lie Group Computations</title>
    <publisher><publishername>CAN, Amsterdam</publishername></publisher>
    <pubdate>1992</pubdate>
    <bibliomisc>http://www.can.nl/SystemsOverview/Special/GroupTheory/LiE/</bibliomisc> 
  </biblioentry>
  
  <biblioentry id="MUPAD" role="book">
    <author><othername>The MuPAD Group (Benno Fuchssteiner et al.)</othername></author>
    <title>MuPAD User's Manual - MuPAD Version 1.2.2</title>
    <publisher><publishername>John Wiley and sons, Chichester, New York</publishername></publisher>
    <edition>first</edition>
    <pubdate>1996</pubdate>
    <pubdate role="month">march</pubdate>
    <isbn>Wiley: 0-471-96716-5, Teubner: 3-519-02114-5</isbn>
    <bibliomisc>http://www.mupad.de</bibliomisc>
    <bibliomisc role="keywords">MuPAD, Help Pages, Language Structure, Parallelism</bibliomisc>
  </biblioentry>
  
  <biblioentry id="NuPRL" role="book">
    <author><firstname>R.</firstname> <othername>L.</othername> <surname>Constable</surname></author>
    <author><firstname>S.</firstname> <othername>F.</othername> <surname>Allen</surname></author>
    <author><firstname>H.</firstname> <othername>M.</othername> <surname>Bromley</surname></author>
    <author><firstname>W.</firstname> <othername>R.</othername> <surname>Cleaveland</surname></author>
    <author><firstname>J.</firstname> <othername>F.</othername> <surname>Cremer</surname></author>
    <author><firstname></firstname> <othername>R.</othername> <surname>W. Harper</surname></author>
    <author><firstname>D.</firstname> <othername>J.</othername> <surname>Howe</surname></author>
    <author><firstname>T.</firstname> <othername>B.</othername> <surname>Knoblock</surname></author>
    <author><firstname></firstname> <othername>N.</othername> <surname>P. Mendler</surname></author>
    <author><firstname>P.</firstname> <surname>Panangaden</surname></author>
    <author><firstname>J.</firstname> <othername>T.</othername> <surname>Sasaki</surname></author>
    <author><firstname>S.</firstname> <othername>F.</othername> <surname>Smith</surname></author>
    <title>Implementing Mathematics with the Nuprl Proof
      Development System</title> 
    <publisher><publishername>Prentice Hall</publishername></publisher>
    <pubdate>1986</pubdate>
    <bibliomisc>http://simon.cs.cornell.edu/Info/Projects/NuPrl/nuprl.html</bibliomisc> 
  </biblioentry>
  
  
  <biblioentry id="Kent-PDFbook" role="book">
    <author><othername>Kent, Gordon</othername></author>
    <title>Internet Publishing With Acrobat</title>
    <pubdate>1996</pubdate>
    <publisher><publishername>Adobe Press</publishername></publisher>
  </biblioentry>
  
  
  <biblioentry id="PDF-Reference-Manual" role="book">
    <author><othername>Adobe Systems Incorporated</othername></author>
    <title>Portable Document Format Reference Manual</title>
    <pubdate>1996</pubdate>
    <publisher><publishername>Adobe Systems Incorporated</publishername></publisher>
  </biblioentry>
  
  <biblioentry id="Knuth-TeXBook" role="book">
    <author><othername>Knuth, Donald E.</othername></author>
    <title>The TeXbook</title>
    <pubdate>1992</pubdate>
    <publisher><publishername>Addison-Wesley, Reading, Massachusetts</publishername></publisher>
  </biblioentry>
  
  
  
  <biblioentry id="PPML" role="Manual">
    <title>The Ppml Manual</title>
    <bibliomisc>ftp://babar.inria.fr/pub/croap/Docs/ppml.ps</bibliomisc> 
  </biblioentry>
  
  
  <biblioentry id="COQ" role="Manual">
    <author><othername>Projet Coq</othername></author>
    <title>The Coq Proof Assistant: The standard library</title>
    <edition>version 6.1</edition>
    <bibliomisc>http://www.ens-lyon.fr/LIP/groupes/coq</bibliomisc>
    
  </biblioentry>
  
  
  <biblioentry id="Knuth-MetaFontBook" role="book">
    <author><othername>Knuth, Donald E.</othername></author>
    <title>MetaFont</title>
    <pubdate>1986</pubdate>
    <publisher><publishername>Addison-Wesley, Reading, Massachusetts</publishername></publisher>
  </biblioentry>
  
  
  <biblioentry id="Lamport-LaTeX2eBook" role="book">
    <author><surname>Lamport</surname><firstname>, Leslie</firstname></author>
    <title>LaTeX: A Document Preparation System, (2nd ed.)</title>
    <pubdate>1994</pubdate>
    <publisher><publishername>Addison-Wesley, Reading, Massachusetts</publishername></publisher>
  </biblioentry>
  
  
  <biblioentry id="Spivak-AMSTeXBook" role="book">
    <author><othername>Spivak, M. D.</othername></author>
    <title>The Joy of TeX &#8212; A Gourmet
      Guide to Typesetting with the AmSTeX macro package</title>
    <pubdate>1986</pubdate>
    <publisher><publishername>American Mathematical Society, Providence, Rhode
        Island</publishername></publisher> 
  </biblioentry>
  
  
  
  <biblioentry id="PVM" role="book">
    <author><firstname>A.</firstname> <surname>Geist</surname></author>
    <author><firstname>A.</firstname> <surname>Beguelin</surname></author>
    <author><firstname>J.</firstname> <surname>Dongarra</surname></author>
    <author><firstname>W.</firstname> <surname>Jiang</surname></author>
    <author><firstname>R.</firstname> <surname>Manchek</surname></author>
    <author><firstname>V.</firstname> <surname>Sunderam</surname></author>
    <title>PVM: Parallel Virtual Machine: A Users' Guide and
      Tutorial for Networked Parallel Computing </title> 
    <publisher><publishername>MIT Press, Scientific and Engineering Computation</publishername></publisher>
    <pubdate>1994</pubdate>
    <editor><othername>Janusz Kowalik</othername></editor>
  </biblioentry>
  
  <biblioentry id="Abbott_98" role="misc">
    <author><firstname>J.</firstname> <surname>Abbott</surname></author>
    <title>Univariate factorization over the integers</title>
    <pubdate>1998</pubdate>
    <bibliomisc>preprint</bibliomisc>
  </biblioentry>
  
  
  
  
  <biblioentry id="COCOA" role="Manual">
    <author><firstname>A.</firstname> <surname>Capani</surname></author>
    <author><firstname>G.</firstname> <surname>Niesi</surname></author>
    <author><firstname>L.</firstname> <surname>Robbiano</surname></author>
    <title>CoCoA, a system for doing Computations in Commutative Algebra</title>
    <pubdate>1995</pubdate>
    <bibliomisc>ftp://cocoa.dima.unige.it</bibliomisc>
  </biblioentry>
  
  
  
  <biblioentry id="Giovini_Niesi_90" role="InProceedings">
    <author><firstname>A.</firstname> <surname>Giovini</surname></author>
    <author><firstname>G.</firstname> <surname>Niesi</surname></author>
    <title>CoCoA: A user-friendly system for commutative
    algebra</title>
    <biblioset relation="series">
    <title>Lecture Bibliomiscs in Computer Science</title>
    </biblioset>
    <biblioset relation="article">
    <volumenum>429</volumenum>
    <pagenums>20&#8211;29</pagenums>
    <title>Design and Implementation of Symbolic Computation Systems &#8211;
      International Symposium DISCO'90</title>
    <pubdate>1990</pubdate>
    </biblioset>
    <publisher><publishername>Springer Verlag</publishername></publisher>
    <address>Berlin</address>
  </biblioentry>
  
  <biblioentry id="Dreyfuss" role="misc">
    <author><firstname>Paul</firstname> <surname>Dreyfuss</surname></author>
    <title>CORBA: THEORY AND PRACTICE </title>
    <bibliomisc>View Source Magazine</bibliomisc>
    <bibliomisc>http://developer.netscape.com/news/viewsource/</bibliomisc>
  </biblioentry>
  
  
  <biblioentry id="CORBA" role="misc">
    <author><othername>Visigenic</othername></author>
    <title>Distributed Object Computing in the Internet Age </title>
    <bibliomisc>White Paper</bibliomisc>
    <bibliomisc>http://www.visigenic.com/pdf/visibrok.pdf</bibliomisc>
  </biblioentry>
  
  
  <biblioentry id="Li-Ron_97" role="misc">
    <author><firstname>Yael</firstname> <surname>Li-Ron</surname></author>
    <title>Communicator 4.0 vs. Internet Explorer 4.0: And the Winner Is ...</title>
    <bibliomisc>PC World</bibliomisc>
    <pubdate>1997</pubdate>
    <pubdate role="month">December</pubdate>
    <bibliomisc>http://www.pcworld.com/software/internet_www/articles/dec97/1512p206.html</bibliomisc>  
  </biblioentry>
  
  
  <biblioentry id="cme" role="misc">
    <author><firstname>P.</firstname> <surname>Chew</surname></author>
    <author><firstname>R.</firstname> <othername>L.</othername> <surname>Constable</surname></author>
    <author><firstname>K.</firstname> <surname>Pingali</surname></author>
    <author><firstname>S.</firstname> <surname>Vavasis</surname></author>
    <author><firstname>R.</firstname> <surname>Zippel</surname></author>
    <title>Collaborative Mathematics Environments</title>
    <bibliomisc>Project Summary</bibliomisc>
  </biblioentry>
  
  <biblioentry id="intro_hol" role="book">
    <author><firstname>M.J.C.</firstname> <surname>Gordon</surname></author>
    <author><firstname>T.F.</firstname> <surname>Melham</surname></author>
    <title>Introduction to HOL: A theorem proving environment
      for higher order logic</title> 
    <publisher><publishername>Cambridge University Press</publishername></publisher>
    <pubdate>1993</pubdate>
  </biblioentry>

  <biblioentry id="harrison-fais" role="InProceedings">
    <author><firstname>John</firstname> <surname>Harrison</surname></author>
    <title>Pure Mathematics in a Mechanized Logic</title>
    <title role="book">Proceedings of the Finnish Artificial Intelligence
      Society Symposium: Logic, Mathematics and the
      Computer</title>
    <editor><othername>Christoffer Gefwert and Pekka Orponen and
        Juoko Sepp&#228;nen</othername></editor>
    <publisher><publishername>Finnish Artificial Intelligence Society</publishername></publisher>
    <bibliomisc role="series">Suomen Teko&#228;lyseuran julkaisuja</bibliomisc>
    <bibliomisc role="volume">14</bibliomisc>
    <pubdate>1996</pubdate>
    <bibliomisc role="pages">153&#8211;169</bibliomisc></biblioentry>
  
  <biblioentry id="harrison-thesis" role="TechReport">
    <author><firstname>John</firstname> <surname>Robert Harrison</surname></author>
    <title>Theorem Proving with the Real Numbers</title>
    <publisher><publishername>University of Cambridge Computer Laboratory</publishername></publisher>
    <address>New Museums Site, Pembroke Street, Cambridge,
      CB2 3QG, UK</address>
    <pubdate>1996</pubdate>
    <bibliomisc role="number">408</bibliomisc>
    <bibliomisc>Author's PhD thesis</bibliomisc>
    <bibliomisc>http://www.cl.cam.ac.uk/users/jrh/papers/thesis.html</bibliomisc>
  </biblioentry>
  
  
  <biblioentry id="Harrison_Thery_94" role="InProceedings">
    <author><firstname>J.</firstname> <surname>Harrison</surname></author>
    <author><firstname>L.</firstname> <surname>Th&#233;ry</surname></author>
    <title>Extending the HOL Theorem Prover with a
      Computer Algebra System to Reason About the Reals</title>
    <title role="book">Higher
      Order Logic Theorem Proving and its Applications: 6th
      International Workshop, HUG'93</title>
    <editor><othername>J. J. Joyce and C.-J. H. Seger</othername></editor>
    <bibliomisc role="volume">780</bibliomisc>
    <bibliomisc role="series">Lecture Bibliomiscs in Computer Science</bibliomisc>
    <bibliomisc role="pages">174-184</bibliomisc>
    <pubdate>1993</pubdate>
    <publisher><publishername>Springer-Verlag</publishername></publisher>
    <address>Vancouver, B.C.</address>
    <pubdate role="month">August 11-13</pubdate>
  </biblioentry>
  
  
  <biblioentry id="Harrison_Thery_93" role="InProceedings">
    <author><firstname>J.</firstname> <surname>Harrison</surname></author>
    <author><firstname>L.</firstname> <surname>Th&#233;ry</surname></author>
    <title>Reasoning About the Reals: the marriage of HOL and
      Maple</title> 
    <title role="book">Logic Programming and Automated
      Reasoning: 4th International Conference</title>
    <editor><othername>A. Voronkov</othername></editor>
    <bibliomisc role="volume">698</bibliomisc>
    <bibliomisc role="series">Lecture Bibliomiscs in Artificial Intelligence</bibliomisc>
    <bibliomisc role="pages">351-353</bibliomisc>
    <pubdate>1993</pubdate>
    <publisher><publishername>Springer-Verlag</publishername></publisher>
    <address>St. Petersburg</address></biblioentry>
  
  
  
  <biblioentry id="Ballarin_Homann_Calmet_95" role="InProceedings">
    <author><firstname>C.</firstname> <surname>Ballarin</surname></author>
    <author><firstname>K.</firstname> <surname>Homann</surname></author>
    <author><firstname>J.</firstname> <surname>Calmet</surname></author>
    <title>Theorems and Algorithms: An Interface between
      Isabelle and Maple.</title> 
    <title role="book">Proceedings of International
      Symposium on Symbolic and Algebraic Computation (ISSAC'95)</title>
    <editor><othername>A.H.M. Levelt </othername></editor>
    <bibliomisc role="pages">150-157</bibliomisc>
    <pubdate>1995</pubdate>
    <publisher><publishername>ACM Press</publishername></publisher>
  </biblioentry>
  
  
  <biblioentry id="Calmet_Homann_96" role="InProceedings">
    <author><firstname>Jacques</firstname> <surname>Calmet</surname></author>
    <author><firstname>Karsten</firstname> <surname>Homann</surname></author>
    <title>Classification of Communication and Cooperation
      Mechanisms for Logical and Symbolic Computation
      Systems</title> 
    <title role="book">Proceedings of First International Workshop
      "Frontiers of Combining Systems" (FroCoS'96)</title> 
    <editor><othername>Franz Baader and Klaus U. Schulz</othername></editor>
    <bibliomisc role="series">Applied Logic</bibliomisc>
    <pubdate>1996</pubdate>
    <publisher><publishername>Kluwer</publishername></publisher>
  </biblioentry>
  
  <biblioentry id="OM1.2" role="misc">
    <author><firstname>Stephen</firstname> <surname>Buswell</surname></author>
    <author><firstname>Stephane</firstname> <surname>Dalmas</surname></author>
    <author><firstname>James</firstname> <surname>Davenport</surname></author>
    <author><firstname>Nick</firstname> <surname>Howgrave-Graham</surname></author>
    <title>Emerging Technologies</title>
    <bibliomisc>&OM; WP 1.2 Deliverable</bibliomisc>
    <pubdate>1998</pubdate>
  </biblioentry>
  
  
  
  
  <biblioentry id="Abbott_Leeuwen_Strotmann_98" role="Article">
    <author><firstname>John</firstname> <othername>A.</othername> <surname>Abbott</surname></author>
    <author><firstname>Andr&#233;</firstname> <surname>van Leeuwen</surname></author>
    <author><firstname>Andreas</firstname> <surname>Strotmann</surname></author>
    <title>&OM;: Communicating Mathematical Information 
      between Co-operating Agents in a Knowledge Network</title>
    <pubdate>1998</pubdate>
    <bibliomisc>http://www.brunel.ac.uk/~hssrjis/issue/index8.html</bibliomisc>
    <bibliomisc role="volume">3/4</bibliomisc>
    <bibliomisc role="journal">Journal of Intelligent Systems</bibliomisc>
    <bibliomisc>Special Issue: "Improving the Design of Intelligent 
      Systems: Outstanding Problems and Some Methods for their Solution."</bibliomisc>
    
  </biblioentry>
  
  <biblioentry id="Robbiano_98" role="InProceedings">
    <author><firstname>L.</firstname> <surname>Robbiano</surname></author>
    <title>Gr&#246;bner Bases and Statistics</title>
    <title role="book">Gr&#246;bner Bases and Applications</title>
    <editor><othername>Bruno Buchberger and Franz Winkler</othername></editor>
    <bibliomisc role="volume">251</bibliomisc>
    <bibliomisc role="series">London Mathematical Society Lecture Bibliomisc Series</bibliomisc>
    <bibliomisc role="pages">179&#8211;204</bibliomisc>
    <pubdate>1998</pubdate>
    <publisher><publishername>Cambridge University Press</publishername></publisher>
  </biblioentry>
  
  <biblioentry id="Moller_98" role="InProceedings">
    <author><firstname>H.M.</firstname> <surname>M&#246;ller</surname></author>
    <title>Gr&#246;bner Bases and Numerical Analysis</title>
    <title role="book">Gr&#246;bner Bases and Applications</title>
    <editor><othername>Bruno Buchberger and Franz Winkler</othername></editor>
    <bibliomisc role="volume">251</bibliomisc>
    <bibliomisc role="series">London Mathematical Society Lecture Bibliomisc Series</bibliomisc>
    <bibliomisc role="pages">159&#8211;179</bibliomisc>
    <pubdate>1998</pubdate>
    <publisher><publishername>Cambridge University Press</publishername></publisher>
  </biblioentry>
  
  <biblioentry id="Canny_Manocha_93" role="Article">
    <author><firstname>J.F.</firstname> <surname>Canny</surname></author>
    <author><firstname>D.</firstname> <surname>Manocha</surname></author>
    <title>Multipolynomial resultant algorithms</title>
    <bibliomisc role="journal">Journal of Symbolic Computation</bibliomisc>
    <pubdate>1993</pubdate>
    <bibliomisc role="volume">15</bibliomisc>
    <bibliomisc role="pages">99&#8211;122</bibliomisc>
  </biblioentry>
  
  
  
  
  <biblioentry id="Arnon_Beach_McIsaac_Waldspurger_88" role="InProceedings">
    <author><firstname>D.</firstname> <surname>Arnon</surname></author>
    <author><firstname>R.</firstname> <surname>McIsaac</surname></author>
    <author><firstname>K.</firstname> <surname>Waldspurger</surname></author>
    <title>CaminoReal: an Interactive Mathematical Bibliomiscbook</title>
    <bibliomisc role="booktitle">International Conference on Electronic Publishing,
      Document Manipulation and Typography</bibliomisc>
    <pubdate>1988</pubdate>
    <publisher><publishername>Cambridge University Press</publishername></publisher>
    <address>Nice</address>
  </biblioentry>
  
  <biblioentry id="Dalmas_Gaetano_Sausse_94a" role="TechReport">
    <author><firstname>S.</firstname> <surname>Dalmas</surname></author>
    <author><firstname>M.</firstname> <surname>Ga&#235;tano</surname></author>
    <author><firstname>A.</firstname> <surname>Sausse</surname></author>
    <title>ASAP: a protocol for symbolic computation systems</title>
    <publisher><publishername>INRIA</publishername></publisher>
    <pubdate>1994</pubdate>
    <bibliomisc role="number">162</bibliomisc>
  </biblioentry>
  
  <biblioentry id="Abbott_Dalmas_Dewar_Diaz_Gray_Sheridan_Strotmann_Vorkoetter_96" role="misc">
    <author><firstname>J.</firstname> <surname>Abbott</surname></author>
    <author><firstname>S.</firstname> <surname>Dalmas</surname></author>
    <author><firstname>M.</firstname> <surname>Dewar</surname></author>
    <author><firstname>A.</firstname> <surname>Diaz</surname></author>
    <author><firstname>S.</firstname> <surname>Gray</surname></author>
    <author><firstname>S.</firstname> <surname>Sheridan</surname></author>
    <author><firstname>A.</firstname> <surname>Strotmann</surname></author>
    <author><firstname>S.</firstname> <surname>Vorkoetter</surname></author>
    <title>Report of the &OM; Communications Committee</title>
    <pubdate>1995</pubdate>
    <pubdate role="month">13 November</pubdate>
  </biblioentry>
  
  <biblioentry id="LEGOmanual" role="Manual">
    <author><firstname>Z.</firstname> <surname>Luo</surname></author>
    <author><firstname>R.</firstname> <surname>Pollack</surname></author>
    <title>LEGO Proof Development System: User's Manual</title>
    <bibliomisc role="organization">Department of Computer Science, University of Edinburgh</bibliomisc>
    <bibliomisc role="year">1992</bibliomisc>
  </biblioentry>
  
  <biblioentry id="luo_thesis" role="PhdThesis"> 
    <author><firstname>Z.</firstname> <surname>Luo</surname></author> 
    <title>An Extended Calculus of Constructions</title> 
    <bibliomisc role="school">Edinburgh University</bibliomisc> 
    <bibliomisc role="year">1990</bibliomisc> 
  </biblioentry>
  
  
  <biblioentry id="Martin_Shand_97" role="TechReport">
    <author><firstname>U.</firstname> <surname>Martin</surname></author>
    <author><firstname>D.</firstname> <surname>Shand</surname></author>
    <title>Investigating some Embedded Verification Techniques
      for Computer Algebra Tools</title>
    <publisher><publishername>RISC-Linz, Research Institute for Symbolic Computation</publishername></publisher>
    <pubdate>1997</pubdate>
    <bibliomisc role="number">No. 97-20</bibliomisc>
    <address>J. Kepler University, Linz (A)</address>
    <bibliomisc>http://www-theory.dcs.st-and.ac.uk/~ddshand/Papers/pub.html</bibliomisc>
  </biblioentry>
  
  <biblioentry id="Barendregt_Barendsen_97" role="misc">
    <author><firstname>H.</firstname> <surname>Barendregt</surname></author>
    <author><firstname>E.</firstname> <surname>Barendsen</surname></author>
    <title>Efficient Computations in Formal Proofs</title>
    <bibliomisc>To Appear.</bibliomisc>
  </biblioentry>
  
  <biblioentry id="CA_industry_93" role="book">
    <title>Computer Algebra in Industry,</title>
    <publisher><publishername>Wiley Chichester</publishername></publisher>
    <pubdate>1993</pubdate>
    <editor><othername>A. M. Cohen</othername></editor>
    <bibliomisc role="series">Problem Solving in Practice</bibliomisc>
  </biblioentry>
  
  
  <biblioentry id="vrmlspec97" role="unpublished">
    <author><firstname>R.</firstname> <surname>Carey</surname></author>
    <author><firstname>C.</firstname> <surname>Marrin</surname></author>
    <author><firstname>G.</firstname> <surname>Bell</surname></author>
    <title>The Virtual Reality Modelling Language</title>
    <bibliomisc>International Standard ISO/IEC 14772-1:1997</bibliomisc>
    <bibliomisc>http://www.vrml.org/Specifications/VRML97/</bibliomisc>
    <bibliomisc role="year">1997</bibliomisc>
  </biblioentry>
  
  <biblioentry id="vrmlarm97" role="book">
    <author><firstname>R.</firstname> <surname>Carey</surname></author>
    <author><firstname>G.</firstname> <surname>Bell</surname></author>
    <title>The Annotated VRML Reference Manual</title>
    <publisher><publishername>Addison-Wesley</publishername></publisher>
    <bibliomisc role="year">1997</bibliomisc>
  </biblioentry>
  
  <biblioentry id="eaispec97" role="unpublished">
    <author><firstname>C.</firstname> <surname>Marrin</surname></author>
    <title>External Authoring Interface Reference</title>
    <bibliomisc>Proposal for a VRML 2.0 Informative Annex</bibliomisc>
    <bibliomisc>http://www.vrml.org/WorkingGroups/vrml-eai/ExternalInterface.html</bibliomisc>
    <pubdate>1997</pubdate>
    <pubdate role="month">November</pubdate>
  </biblioentry>
  
  <biblioentry id="harrison-form" role="TechReport">
    <author><firstname>John</firstname> <surname>Harrison</surname></author>
    <title>Formalized Mathematics</title>
    <publisher><publishername>Turku Centre for Computer Science (TUCS)</publishername></publisher>
    <address>Lemmink&#228;isenkatu 14 A, FIN-20520 Turku,
      Finland</address>
    <pubdate>1996</pubdate>
    <bibliomisc role="number">36</bibliomisc>
    <bibliomisc>http://www.cl.cam.ac.uk/users/jrh/papers/form-math3.html</bibliomisc>
  </biblioentry>
  
  
  
  <biblioentry id="Dunstan_Kelsey_Linton_Martin_98" role="InProceedings">
    <author><firstname>Martin</firstname> <surname>Dunstan</surname></author>
    <author><firstname>Tom</firstname> <surname>Kelsey</surname></author>
    <author><firstname>Steve</firstname> <surname>Linton</surname></author>
    <author><firstname>Ursula</firstname> <surname>Martin</surname></author>
    <title>Lightweight Formal Methods for Computer Algebra Systems</title>
    <title role="book">ISSAC'98: International Symposium on Symbolic and Algebraic Computation</title>
    <pubdate>1998</pubdate>
    <editor><othername>O. Gloor</othername></editor>
    <address>Rostock, Germany</address>
    <pubdate role="month">August</pubdate>
    <publisher><publishername>ACM Press</publishername></publisher>
  </biblioentry>
  
  <biblioentry id="Jackson_95" role="PhdThesis">
    <author><firstname>Paul</firstname> <surname>Jackson</surname></author>
    <title>Enhancing the Nuprl Proof Development System and 
      Applying it to Computational Abstract Algebra</title>
    <bibliomisc role="school">Cornell University</bibliomisc>
    <pubdate>1995</pubdate>
    <bibliomisc role="series">TR95-1509</bibliomisc>
  </biblioentry>
  
  <biblioentry id="Thery_98" role="InProceedings">
    <author><firstname>Laurent</firstname> <surname>Th&#233;ry</surname></author>
    <title>A Certified Version of Buchberger Algorithm</title>
    <title role="book">Automated Deduction - CADE 15: 
      15th International Conference on Automated Deduction</title>
    <pubdate>1998</pubdate>
    <editor><othername>C. Kirchner and H. Kirchner</othername></editor>
    <bibliomisc role="volume">1421</bibliomisc>
    <bibliomisc role="series">Lecture Bibliomiscs in Artificial Intelligence</bibliomisc>
    <address>Landau, Germany</address>
    <pubdate role="month">July</pubdate>
    <publisher><publishername>Springer Verlag</publishername></publisher>
  </biblioentry>
  
  <biblioentry id="PolyMath_JAVA" role="misc">
    <author><othername>PolyMath &OM; Development Team</othername></author>
    <title>Java &OM; Library: Version 0.7c</title>
    <bibliomisc>http://pdg.cecm.sfu.ca/openmath/</bibliomisc>
    <pubdate role="month">June</pubdate>
    <pubdate>1999</pubdate>
  </biblioentry>
  
  <biblioentry id="STARS" role="misc">
    <author><firstname>Stephen</firstname> <surname>Buswell</surname></author>
    <title>STARS</title>
    <bibliomisc>Available from Stilo Technologies</bibliomisc>
    <bibliomisc>http://www.stilo.com</bibliomisc>
    <pubdate role="month">April</pubdate>
    <pubdate>1999</pubdate>
  </biblioentry>
  
  
  <biblioentry id="OMurl" role="misc">
    <author><othername>&OM; Society Website</othername></author>
    <title>www.openmath.org</title>
  </biblioentry>
  
  <biblioentry id="Dalmas_Gaetano_Watt_97" role="InProceedings">
    <author><firstname>S.</firstname> <surname>Dalmas</surname></author>
    <author><firstname>M.</firstname> <surname>Ga&#235;tano</surname></author>
    <author><firstname>S.</firstname> <surname>Watt</surname></author>
    <title>An &OM;&#160;1.0 Implementation</title>
    <pagenums>241&#8211;248</pagenums>
    <bibliomisc role="booktitle">Proceedings of ISSAC 97</bibliomisc>
    <pubdate>1997</pubdate>
    <publisher><publishername>ACM Press</publishername></publisher>
  </biblioentry>
  
  <biblioentry id="OM_96" role="misc">
    <author><othername>&OM; Steering Committee</othername></author>
    <title>&OM; Version 1.0 released</title>
    <pubdate>1996</pubdate>
    <pubdate role="month">December</pubdate>
    <bibliomisc>http://www.openmath.org</bibliomisc>
  </biblioentry>
  
  <biblioentry id="OM_98" role="misc">
    <author><othername>&OM; Consortium</othername></author>
    <title>&OM; Version 1 - Draft</title>
    <pubdate>1998</pubdate>
    <pubdate role="month">June</pubdate>
    <bibliomisc>ftp://ftp-sop.inria.fr/safir/OM/v1.ps</bibliomisc>
  </biblioentry>
  
   <biblioentry id="OM_1.1">
    <author><othername>&OM; Consortium</othername></author>
    <title>&OM; Version 1.1</title>
    <pubdate>2002</pubdate>
    <pubdate role="month">October</pubdate>
    <bibliomisc>http://www.openmath.org/standard/om11/</bibliomisc>
  </biblioentry>

   <biblioentry id="OM_2.0r0">
    <author><othername>&OM; Consortium</othername></author>
    <title>&OM; Version 2.0</title>
    <pubdate>2004</pubdate>
    <pubdate role="month">June</pubdate>
    <bibliomisc>http://www.openmath.org/standard/om20-2004-06-30/</bibliomisc>
  </biblioentry>
  
  
   <biblioentry id="OM_primer">
    <author><othername>&OM; Consortium</othername></author>
    <title>&OM; Primer</title>
    <pubdate>2004</pubdate>
    <pubdate role="month">June</pubdate>
    <bibliomisc>http://www.openmath.org/standard/primer/</bibliomisc>
  </biblioentry>
  
  
  
  
  <biblioentry id="Gonnet_Seppala_Watt_96" role="misc">
    <author><firstname>G.</firstname> <surname>Gonnet</surname></author>
    <author><firstname>M.</firstname> <surname>Seppala</surname></author>
    <author><firstname>S.</firstname> <surname>Watt</surname></author>
    <title>Semantic Dictionaries for &OM;</title>
    <bibliomisc>Presented at the 6th &OM; Workshop, Z&#252;rich</bibliomisc>
    <pubdate>1996</pubdate>
    <pubdate role="month">July 27-28</pubdate>
    <bibliomisc>http://www.inf.ethz.ch/personal/gonnet/ContDict.html</bibliomisc>
  </biblioentry>
  
  <biblioentry id="Constable_98" role="misc">
    <author><firstname>Robert</firstname> <surname>Constable</surname></author>
    <bibliomisc>Personal Communication</bibliomisc>
    <pubdate>1998</pubdate>
    <pubdate role="month">July</pubdate>
  </biblioentry>
  
  
  
  
  
  <biblioentry id="Caprotti_Cohen_Elbers_Geuvers_98" role="misc">
    <author><firstname>O.</firstname> <surname>Caprotti</surname></author>
    <author><firstname>A.</firstname> <othername>M.</othername> <surname>Cohen</surname></author>
    <author><firstname>H.</firstname> <surname>Elbers</surname></author>
    <author><firstname>H.</firstname> <surname>Geuvers</surname></author>
    <title>Connecting &OM; to Formal Math</title>
    <bibliomisc>Calculemus and Types '98</bibliomisc>
    <pubdate>1998</pubdate>
    <pubdate role="month">July</pubdate>
  </biblioentry>
  
  
  <biblioentry id="UNICODE" role="book">
    <author><othername>Unicode Consortium</othername></author>
    <title>The Unicode Standard: Version 4.0.0</title>
    <publisher><publishername>Addison-Wesley</publishername></publisher>
    <pubdate>2003</pubdate>
    <isbn>ISBN 0-321-18578-1</isbn>
    <bibliomisc>Online edition available from http://www.unicode.org/versions/Unicode4.0.0</bibliomisc>
  </biblioentry>
  
  <biblioentry id="ieee754_85" role="misc">
    <title>IEEE Standard for binary Floating-Point Arithmetic</title>
    <subtitle>ANSI/IEEE Standard 754</subtitle>
    <bibliomisc role="key">ieee</bibliomisc>
    <pubdate>1985</pubdate>
    <bibliomisc>http://standards.ieee.org/reading/ieee/std_public/description/busarch/754-1985_desc.html</bibliomisc>
  </biblioentry>
  
  <biblioentry id="rfc1642" role="misc">
    <author><firstname>D.</firstname> <surname>Goldsmith</surname></author>
    <author><firstname>M.</firstname> <surname>Davis</surname></author>
    <title>UTF-7: A Mail Safe Transformation Format of Unicode</title>
    <bibliomisc>RFC: 1642</bibliomisc>
    <pubdate role="month">July</pubdate>
    <pubdate>1994</pubdate>
  </biblioentry>
  
  <biblioentry id="rfc2045" role="misc">
    <author><firstname>N.</firstname> <surname>Borenstein</surname></author>
    <author><firstname>N.</firstname> <surname>Freed</surname></author>
    <title>MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies</title>
    <bibliomisc>RFC: 2045</bibliomisc>
    <pubdate role="month">November</pubdate>
    <pubdate>1996</pubdate>
    <bibliomisc>http://www.ietf.org/rfc/rfc2045.txt</bibliomisc>
  </biblioentry>
  
  <biblioentry id="rfc2046" role="misc">
    <author><firstname>N.</firstname> <surname>Borenstein</surname></author>
    <author><firstname>N.</firstname> <surname>Freed</surname></author>
    <title>MIME (Multipurpose Internet Mail Extensions) Part Two: Media
Types</title>
    <bibliomisc>RFC: 2046</bibliomisc>
    <pubdate role="month">November</pubdate>
    <pubdate>1996</pubdate>
    <bibliomisc>http://www.ietf.org/rfc/rfc2046.txt</bibliomisc>
  </biblioentry>
  
  <biblioentry id="iso646_83" role="misc">
    <title>ISO 7-bit coded character set for information interchange</title>
    <bibliomisc role="key">iso 646</bibliomisc>
    <bibliomisc>ISO 646:1983</bibliomisc>
    <pubdate>1983</pubdate>
  </biblioentry>
  
  <biblioentry id="rfc2152" role="misc">
    <author><firstname>D.</firstname> <surname>Goldsmith</surname></author>
    <author><firstname>M.</firstname> <surname>Davis</surname></author>
    <title>UTF-7: A Mail Safe Transformation Format of Unicode</title>
    <bibliomisc>RFC: 2152</bibliomisc>
    <pubdate role="month">May</pubdate>
    <pubdate>1997</pubdate>
    <bibliomisc>http://www.cis.ohio-state.edu/htbin/rfc/rfc2152.html</bibliomisc>
  </biblioentry>
  
  
  
  <biblioentry id="xmlns" role="misc">
    <author><othername>World Wide Web Consortium</othername></author>
    <title>Namespaces in XML</title>
    <pubdate role="month">January</pubdate>
    <pubdate>1999</pubdate>
    <bibliomisc>http://www.w3.org/TR/REC-xml-names/</bibliomisc>
  </biblioentry>
  
  <biblioentry id="xml-stylesheet" role="misc">
    <author><othername>World Wide Web Consortium</othername></author>
    <title>Associating Style Sheets with XML documents Version 1.0</title>
    <bibliomisc>W3C Recommendation</bibliomisc>
    <pubdate role="month">June</pubdate>
    <pubdate>1998</pubdate>
    <bibliomisc>http://www.w3.org/TR/xml-stylesheet/</bibliomisc>
  </biblioentry>
  
  
  <biblioentry id="utf8" role="misc">
    <author><firstname>F.</firstname> <surname>Yergeau</surname></author>
    <title>UTF-8, a transformation format of ISO 10646</title>
    <bibliomisc>RFC 2279</bibliomisc>
    <pubdate role="month">January</pubdate>
    <pubdate>1998</pubdate>
    <bibliomisc>Alis Technologies</bibliomisc>
  </biblioentry>
  
  <biblioentry id="iso9660" role="misc">
    <author><othername>Technical committee / subcommittee: JTC 1</othername></author>
    <title>ISO 9660:1988 Information processing &#8211; Volume and File Structure of CDROM for Information Interchange</title>
    <bibliomisc>ISO 9660</bibliomisc>
    <pubdate>1988</pubdate>
    <bibliomisc>http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=17505</bibliomisc>
  </biblioentry>
  
  <biblioentry id="OM_D122" role="misc">
    <author><firstname>S.</firstname> <surname>Buswell</surname></author>
    <author><firstname>S.</firstname> <surname>Dalmas</surname></author>
    <author><firstname>J.</firstname> <surname>Davenport</surname></author>
    <title>&OM; task 1.2: Emerging Technologies</title>
    <bibliomisc>&OM; Deliverable 1.2.2</bibliomisc>
    <pubdate role="month">September</pubdate>
    <pubdate>1998</pubdate>
    <bibliomisc>Confidential</bibliomisc>
  </biblioentry>
  
  <biblioentry id="xml_98" role="misc">
    <author><othername>World Wide Web Consortium</othername></author>
    <title>Extensible Markup Language (XML) 1.0.</title>
    <bibliomisc>W3C Recommendation REC-xml-19980210</bibliomisc>
    <pubdate role="month">February</pubdate>
    <pubdate>1998</pubdate>
    <bibliomisc>http://www.w3.org/TR/1998/REC-xml-19980210</bibliomisc>
  </biblioentry>
  
  <biblioentry id="erratum_NE17" role="misc">
    <author><othername>World Wide Web Consortium</othername></author>
    <title>Namespaces in XML 1.0 (Second Edition) Errata</title>
    <pubdate role="month">November</pubdate>
    <pubdate>2008</pubdate>
    <bibliomisc>https://www.w3.org/XML/2006/xml-names-errata</bibliomisc>
  </biblioentry>

  <biblioentry id="xml_04" role="misc">
    <author><othername>World Wide Web Consortium</othername></author>
    <title>Extensible Markup Language (XML) 1.1.</title>
    <subtitle>W3C Recommendation REC-xml11-20040204</subtitle>
    <pubdate role="month">February</pubdate>
    <pubdate>2004</pubdate>
    <bibliomisc>http://www.w3.org/TR/2004/REC-xml11-20040204/</bibliomisc>
  </biblioentry>
  
  <biblioentry id="OM_D131a" role="misc">
    <author><othername>&OM; Consortium</othername></author>
    <title>The &OM; Standard</title>
    <bibliomisc>&OM; Deliverable 1.3.1a</bibliomisc>
    <pubdate role="month">September</pubdate>
    <pubdate>1998</pubdate>
    <bibliomisc>http://www.nag.co.uk/projects/OpenMath.html</bibliomisc>
  </biblioentry>
  
  <biblioentry id="OM_D132c" role="misc">
    <author><firstname>J.</firstname> <surname>Davenport</surname></author>
    <title>A Small &OM; Type System</title>
    <bibliomisc>&OM; Deliverable 1.3.2b</bibliomisc>
    <pubdate role="month">April</pubdate>
    <pubdate>1999</pubdate>
    <bibliomisc>http://www.openmath.org/standard/sts.pdf</bibliomisc>
  </biblioentry>
  
  
  <biblioentry id="OMD132a" role="TechReport">
    <author><othername>The &OM; Consortium</othername></author>
    <title>The &OM; Standard</title>
    <publisher><publishername>&OM; Esprit Consortium</publishername></publisher>
    <pubdate>1999</pubdate>
    <bibliomisc role="number">1.3.2a</bibliomisc>
    <bibliomisc>http://www.nag.co.uk/projects/OpenMath.html</bibliomisc>
    <pubdate role="month">February</pubdate>
    <bibliomisc>O. Caprotti and A. M. Cohen Eds.</bibliomisc>
  </biblioentry>
  
  <biblioentry id="OMD132b" role="TechReport">
    <author><firstname>Olga</firstname> <surname>Caprotti</surname></author>
    <author><firstname>Arjeh</firstname> <othername>M.</othername> <surname>Cohen</surname></author>
    <title>A Type System for &OM;</title>
    <publisher><publishername>&OM; Esprit Consortium</publishername></publisher>
    <pubdate>1999</pubdate>
    <seriesvolnums>1.3.2b</seriesvolnums>
    <bibliomisc>http://www.openmath.org/standard/ecc.pdf</bibliomisc>
    <pubdate role="month">February</pubdate>
  </biblioentry>
  
  <biblioentry id="OM_D133b" role="TechReport">
    <author><firstname>Olga</firstname> <surname>Caprotti</surname></author>
    <author><firstname>Arjeh</firstname> <othername>M.</othername> <surname>Cohen</surname></author>
    <title>Development of Strong &OM;</title>
    <publisher><publishername>&OM; Esprit Consortium</publishername></publisher>
    <pubdate>1999</pubdate>
    <pubdate role="month">October</pubdate>
    <seriesvolnums>1.3.3b</seriesvolnums>
    <bibliomisc>http://www.nag.co.uk/projects/OpenMath.html</bibliomisc>
  </biblioentry>
  
  
  <biblioentry id="ida" role="book">
    <author><firstname>A.</firstname> <othername>M.</othername> <surname>Cohen</surname></author>
    <author><firstname></firstname> <othername>H.</othername> <surname>Cuypers</surname></author>
    <author><firstname>H.</firstname> <surname>Sterk</surname></author>
    <title>Algebra Interactive, interactive course material</title>
    <publisher><publishername>SV</publishername></publisher>
    <pubdate>1999</pubdate>
    <isbn>ISBN 3-540-65368-6</isbn>
  </biblioentry>
  
  <biblioentry id="CaprottiCohen99" role="misc">
    <author><firstname>Olga</firstname> <surname>Caprotti</surname></author>
    <author><firstname>Arjeh</firstname> <othername>M.</othername> <surname>Cohen</surname></author>
    <title>Integrating Computational and Deduction Systems Using &OM;</title>
    <bibliomisc>Calculemus'99: Systems for Integrated Computation and Deduction</bibliomisc>
    <pubdate role="month">July 11-12</pubdate>
    <pubdate>1999</pubdate>
    <address>Trento, Italy</address>
  </biblioentry>
  
  <biblioentry id="Buchberger_Jebelan_Kriftner_Marin_Tomuta_Vasaru_97" role="InProceedings">
    <author><firstname>B.</firstname> <surname>Buchberger</surname></author>
    <author><firstname>T.</firstname> <surname>Jebelean</surname></author>
    <author><firstname>F.</firstname> <surname>Kriftner</surname></author>
    <author><firstname>M.</firstname> <surname>Marin</surname></author>
    <author><firstname>E.</firstname> <surname>Tomuta</surname></author>
    <author><firstname>D.</firstname> <surname>Vasaru</surname></author>
    <title>A Survey of the Theorema Project</title>
    <title role="book">Proceedings of ISSAC'97</title>
    <pubdate>1997</pubdate>
    <address>Maui, Hawaii</address>
    <pubdate role="month">July</pubdate>
    <publisher><publishername>Association for Computing Machinery</publishername></publisher>
  </biblioentry>
  
  
  <biblioentry id="Clarke_Zhao_92" role="InProceedings">
    <author><firstname>E.</firstname> <surname>Clarke</surname></author>
    <author><firstname>X.</firstname> <surname>Zhao</surname></author>
    <title>Analytica - a theorem prover in Mathematica</title>
    <title role="book">11th Conference on Automated Deduction</title>
    <pagenums>761&#8211;765</pagenums>
    <pubdate>1992</pubdate>
    <editor><othername>D. Kapur</othername></editor>
    <bibliomisc role="volume">607</bibliomisc>
    <bibliomisc role="series">Lecture Bibliomiscs in Computer Science</bibliomisc>
    <publisher><publishername>Springer Verlag</publishername></publisher>
  </biblioentry>
  
  
  
  <biblioentry id="MathML_98" role="misc">
    <author><firstname>Stephen</firstname> <surname>Buswell</surname></author>
    <author><firstname>Stan</firstname> <surname>Devitt</surname></author>
    <author><firstname>Angel</firstname> <surname>Diaz</surname></author>
    <author><firstname>Nico</firstname> <surname>Poppelier</surname></author>
    <author><firstname>Bruce</firstname> <surname>Smith</surname></author>
    <author><firstname>Neil</firstname> <surname>Soiffer</surname></author>
    <author><firstname>Robert</firstname> <surname>Sutor</surname></author>
    <author><firstname>Stephen</firstname> <surname>Watt</surname></author>
    <title>Mathematical Markup Language (MathML) 1.0 Specification</title>
    <subtitle>W3C Recommendation 19980407</subtitle>
    <pubdate role="month">April</pubdate>
    <pubdate>1998</pubdate>
    <bibliomisc>http://www.w3.org/TR/REC-MathML/</bibliomisc>
  </biblioentry>
  
  
  
  
  <biblioentry id="MathML_99" role="misc">
    <author><firstname>Patrick</firstname> <surname>Ion</surname></author>
    <author><firstname>Robert</firstname> <surname>Miner</surname></author>
    <author><firstname>Stephen</firstname> <surname>Buswell</surname></author>
    <author><firstname>Stan</firstname> <surname>Devitt</surname></author>
    <author><firstname>Angel</firstname> <surname>Diaz</surname></author>
    <author><firstname>Nico</firstname> <surname>Poppelier</surname></author>
    <author><firstname>Bruce</firstname> <surname>Smith</surname></author>
    <author><firstname>Neil</firstname> <surname>Soiffer</surname></author>
    <author><firstname>Robert</firstname> <surname>Sutor</surname></author>
    <author><firstname>Stephen</firstname> <surname>Watt</surname></author>
    <title>Mathematical Markup Language (MathML[tm]) 1.01 Specification</title>
    <subtitle>REC-MathML-19980407; revised 19990707</subtitle>
    <pubdate role="month">July</pubdate>
    <pubdate>1999</pubdate>
    <bibliomisc>http://www.w3.org/TR/REC-MathML/</bibliomisc>
  </biblioentry>
  
  
  <biblioentry id="MathML_2000" role="misc">
    <author><othername>World Wide Web Consortium</othername></author>
    <title>Mathematical Markup Language (MathML) 2.0 Specification</title>
    <pubdate role="month">February</pubdate>
    <pubdate>2001</pubdate>
    <bibliomisc>http://www.w3.org/TR/REC-MathML2/</bibliomisc>
  </biblioentry>
  

  <biblioentry id="MathML_2003" role="misc">
    <author><othername>World Wide Web Consortium</othername></author>
    <title>Mathematical Markup Language (MathML) 2.0 Specification
    (Second Edition)</title>
    <pubdate role="month">October</pubdate>
    <pubdate>2003</pubdate>
    <bibliomisc>http://www.w3.org/TR/MathML2/</bibliomisc>
  </biblioentry>
   
  <biblioentry id="MathML_2014" role="misc">
    <author><othername>World Wide Web Consortium</othername></author>
    <title>Mathematical Markup Language (MathML) 3.0 Specification
    2nd Edition</title>
    <pubdate role="month">April</pubdate>
    <pubdate>2014</pubdate>
    <bibliomisc>http://www.w3.org/TR/MathML3/</bibliomisc>
  </biblioentry>

  <biblioentry id="CTCOQMATH" role="Manual">
    <title>CtCoqmath</title>
    <bibliomisc role="organization">INRIA</bibliomisc>
    <address>Sophia Antipolis</address>
    <bibliomisc>http://www-sop.inria.fr/croap/CFC/Ctcoqmath.html</bibliomisc>
  </biblioentry>
  
  
  
  <biblioentry id="Pottier_Thery_98" role="InProceedings">
    <author><firstname>L.</firstname> <surname>Pottier</surname></author>
    <author><firstname>L.</firstname> <surname>Th&#233;ry</surname></author>
    <title>Certifier Computer Algebra</title>
    <title role="book">Calculemus and Types '98</title>
    <address>Eindhoven</address>
    <pubdate role="month">July</pubdate>
    <pubdate>1998</pubdate>
    <bibliomisc>http://www-sop.inria.fr/croap/CFC/</bibliomisc>
  </biblioentry>
  
  <biblioentry id="LAG" role="Manual">
    <title>The Lego Algebra Group</title>
    <bibliomisc>http://www.cs.man.ac.uk/~petera/LAG/</bibliomisc>
  </biblioentry>
  
  <biblioentry id="Bailey_98" role="PhdThesis">
    <author><firstname>Anthony</firstname> <surname>Bailey</surname></author>
    <title>The Machine-Checked Literate Formalisation
      of Algebra in Type Theory</title>
    <bibliomisc role="school">University of Manchester</bibliomisc>
    <pubdate>January 15th 1998</pubdate>
    <pubdate role="month">January 15</pubdate>
  </biblioentry>
  
  
  
  <biblioentry id="OMRS" role="misc">
    <author><othername>Open Mechanized Reasoning System Project</othername></author>
    <bibliomisc>http://www.mrg.dist.unige.it/omrs</bibliomisc>
  </biblioentry>
  
  
  <biblioentry id="Giunchiglia_Pecchiari_Talcott_96" role="InProceedings">
    <author><firstname>Fausto</firstname> <surname>Giunchiglia</surname></author>
    <author><firstname>Paolo</firstname> <surname>Pecchiari</surname></author>
    <author><firstname>Carolyn</firstname> <surname>Talcott</surname></author>
    <title>Reasoning Theories: Towards an Architecture for Open
      Mechanized Reasoning Systems</title>
    <title role="book">"Frontiers of Combining Systems - First International Workshop" (FroCoS'96)</title>
    <pagenums>157&#8211;174</pagenums>
    <pubdate>1996</pubdate>
    <editor><othername>F. Baader and K.U. Schulz</othername></editor>
    <bibliomisc role="series">Applied Logic Series</bibliomisc>
    <address>Munich, Germany</address>
    <pubdate role="month">26&#8211;29 March</pubdate>
    <publisher><publishername>Kluwer</publishername></publisher>
  </biblioentry>
  
  
  
  <biblioentry id="Bertoli_Calmet_Giunchiglia_Homann_98" role="InProceedings">
    <author><firstname>P.</firstname> <surname>Bertoli</surname></author>
    <author><firstname>J.</firstname> <surname>Calmet</surname></author>
    <author><firstname>F.</firstname> <surname>Giunchiglia</surname></author>
    <author><firstname>K.</firstname> <surname>Homann</surname></author>
    <title>Specification and Integration of Theorem Provers and Computer Algebra Systems</title>
    <title role="book">Artificial Intelligence and Symbolic Computation: International Conference AISC'98</title>
    <pubdate>1998</pubdate>
    <editor><othername>J. Calmet and J. Plaza</othername></editor>
    <bibliomisc role="volume">1476</bibliomisc>
    <bibliomisc role="series">Lecture Notes in Artificial Intelligence</bibliomisc>
    <address>Plattsburgh, New York, USA</address>
    <pubdate role="month">September</pubdate>
  </biblioentry>
  
  
  
  <biblioentry id="FIPA" role="misc">
    <author><othername>Foundation for Intelligent Physical Agents</othername></author>
    <bibliomisc>http://www.fipa.org</bibliomisc>
  </biblioentry>
  
  
  <biblioentry id="Franke_Hess_Jung_Kohlhase_Sorge_99" role="Article">
    <author><firstname>A.</firstname> <surname>Franke</surname></author>
    <author><firstname>S.</firstname> <surname>Hess</surname></author>
    <author><firstname>Ch.</firstname> <surname>Jung</surname></author>
    <author><firstname>M.</firstname> <surname>Kohlhase</surname></author>
    <author><firstname>V.</firstname> <surname>Sorge</surname></author>
    <title>Agent-Oriented Integration of Distributed Mathematical Services</title>
    <pubdate>1999</pubdate>
    <bibliomisc role="volume">5</bibliomisc>
    <bibliomisc role="number">3</bibliomisc>
    <pagenums>156&#8211;187</pagenums>
    <pubdate role="month">March</pubdate>
    <bibliomisc role="journal">Journal of Universal Computer Science</bibliomisc>
    <bibliomisc>Special issue on Integration of Deduction System</bibliomisc>
    <bibliomisc>http://medoc.springer.de:8000/jucs_5_3/agent_oriented_integration_of;internal&amp;sk=060C4837</bibliomisc>
  </biblioentry>
  
  <biblioentry id="Franke_Hess_Jung_Kohlhase_Sorge_98" role="InProceedings">
    <author><firstname>A.</firstname> <surname>Franke</surname></author>
    <author><firstname>S.</firstname> <surname>Hess</surname></author>
    <author><firstname>Ch.</firstname> <surname>Jung</surname></author>
    <author><firstname>M.</firstname> <surname>Kohlhase</surname></author>
    <author><firstname>V.</firstname> <surname>Sorge</surname></author>
    <title>An Implementation of Distributed Mathematical Services</title>
    <title role="book">Calculemus and Types 98</title>
    <pubdate>1998</pubdate>
    <address>Eindhoven</address>
    <pubdate role="month">July</pubdate>
  </biblioentry>
  
  
  <biblioentry id="Bertot_Thery_98" role="Article">
    <author><firstname>Yves</firstname> <surname>Bertot</surname></author>
    <author><firstname>Laurent</firstname> <surname>Th&#233;ry</surname></author>
    <title>A Generic Approach to Building User Interfaces for Theorem Provers</title>
    <bibliomisc role="journal">Journal of Symbolic Computation</bibliomisc>
    <pubdate>1998</pubdate>
    <bibliomisc role="volume">25</bibliomisc>
    <pagenums>161&#8211;194</pagenums>
  </biblioentry>
  
  <biblioentry id="Luo_Callaghan_97" role="InProceedings">
    <author><firstname>Z.</firstname> <surname>Luo</surname></author>
    <author><firstname>P.</firstname> <surname>Callaghan</surname></author>
    <title>Mathematical Vernacular and Conceptual Well-formedness in Mathematical Language</title>
    <title role="book">Proceedings of the 2nd International Conference on Logical Aspects of Computational Linguistics 97</title>
    <pubdate>1997</pubdate>
    <bibliomisc role="volume">1582</bibliomisc>
    <bibliomisc role="series">Lecture Bibliomiscs in Computer Science</bibliomisc>
    <address>Nancy</address>
  </biblioentry>
  
  
  
  <biblioentry id="Finin_Labrou_Mayfield_97" role="InCollection">
    <author><firstname>Tim</firstname> <surname>Finin</surname></author>
    <author><firstname>Yannis</firstname> <surname>Labrou</surname></author>
    <author><firstname>James</firstname> <surname>Mayfield</surname></author>
    <title>KQML as an agent communication language</title>
    <title role="book">Software Agents</title>
    <publisher><publishername>MIT Press</publishername></publisher>
    <pubdate>1997</pubdate>
    <editor><othername>Jeff Bradshaw</othername></editor>
    <address>Cambridge</address>
  </biblioentry>
  
  <biblioentry id="FIPA_99" role="misc">
    <author><othername>Foundation for Intelligent Physical Agents</othername></author>
    <title>The FIPA '99 Baselines</title>
    <bibliomisc>http://www.fipa.org/spec/fipa99.html</bibliomisc>
  </biblioentry>
  
  <biblioentry id="Linton_Solomon_99" role="misc">
    <author><firstname>Steve</firstname> <surname>Linton</surname></author>
    <author><firstname>Andrew</firstname> <surname>Solomon</surname></author>
    <title>GAP, &OM;, and MCP</title>
    <bibliomisc>ISSAC Workshop: Internet Accessible Mathematical Computation</bibliomisc>
    <pubdate role="month">July</pubdate>
    <pubdate>99</pubdate>
  </biblioentry>
  
  <biblioentry id="IAMC" role="TechReport">
    <author><firstname>Paul</firstname> <surname>Wang</surname></author>
    <title>Design and Protocol for Internet Accessible Mathematical Computation</title>
    <publisher><publishername>ICM/Kent State University</publishername></publisher>
    <pubdate>1999</pubdate>
    <bibliomisc role="number">ICM-199901-001</bibliomisc>
    <pubdate role="month">January</pubdate>
  </biblioentry>
  
  
  <biblioentry id="Harvey_99context" role="TechReport">
    <author><firstname>Vilya</firstname> <surname>Harvey</surname></author>
    <title>&OM; in Context</title>
    <publisher><publishername>&OM; Esprit Consortium</publishername></publisher>
    <pubdate>1999</pubdate>
    <bibliomisc>http://www.nag.co.uk/projects/OpenMath/papers/context.pdf</bibliomisc>
    <pubdate role="month">June</pubdate>
  </biblioentry>
  
  <biblioentry id="SDMGCHDISCO96" role="InCollection">
    <author><firstname>St&#233;phane</firstname> <surname>Dalmas</surname></author>
    <author><firstname>Marc</firstname> <surname>Ga&#235;tano</surname></author>
    <author><firstname>Claude</firstname> <surname>Huchet</surname></author>
    <title>A Deductive Database for Mathematical formulas</title>
    <title role="book">Design and Implementation of Symbolic Computation Systems</title>
    <publisher><publishername>Springer Verlag</publishername></publisher>
    <editor><othername>Jacques Calmet and Carla Limongelli</othername></editor>
    <bibliomisc role="number">1128</bibliomisc>
    <bibliomisc role="series">LNCS</bibliomisc>
    <pagenums>287&#8211;296</pagenums>
    <pubdate>1996</pubdate>
  </biblioentry>
  
  
  
  <biblioentry id="DOM_98" role="misc">
    <title>Document Object Model (DOM) Level 1 Specification</title>
    <subtitle>W3C Recommendation REC-DOM-Level-1-19981001</subtitle>
    <pubdate role="month">October</pubdate>
    <pubdate>1998</pubdate>
    <bibliomisc>http://www.w3.org/TR/REC-DOM-Level-1/</bibliomisc>
  </biblioentry>
  
  
  
  <biblioentry id="owl" role="misc">
    <author><othername>World Wide Web Consortium</othername></author>
    <title> OWL Web Ontology Language Overview </title>
    <pubdate role="month">February</pubdate>
    <pubdate>2004</pubdate>
    <bibliomisc>http://www.w3.org/TR/2004/REC-owl-features-20040210/</bibliomisc>
  </biblioentry>

  <biblioentry id="rdf" role="misc">  
    <author><othername>World Wide Web Consortium</othername></author>
    <title>Resource Description Framework (RDF): Concepts and Abstract Syntax</title>
    <pubdate role="month">February</pubdate>
    <pubdate>2004</pubdate>
    <bibliomisc>http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/</bibliomisc>
  </biblioentry>

  <biblioentry id="XSL_2001" role="misc">
    <author><othername>World Wide Web Consortium</othername></author>
    <title>Extensible Stylesheet Language (XSL) Specification</title>
    <pubdate role="month">October</pubdate>
    <pubdate>2001</pubdate>
    <bibliomisc>http://www.w3.org/TR/xsl/</bibliomisc>
  </biblioentry>

  <biblioentry id="XSLT_99" role="misc">
    <author><othername>World Wide Web Consortium</othername></author>
    <title>XSL Transformations (XSLT)</title>
    <pubdate role="month">November</pubdate>
    <pubdate>1999</pubdate>
    <bibliomisc>http://www.w3.org/TR/xslt</bibliomisc>
  </biblioentry>
  
  <biblioentry id="Kohlhase_99" role="InProceedings">
    <author><firstname>M.</firstname> <surname>Kohlhase</surname></author>
    <title>&OM; for knowledge-based automated theorem proving</title>
    <title role="book">Electronic Proceedings of the 12th &OM; Workshop</title>
    <pubdate>1999</pubdate>
    <address>Eindhoven, Netherlands</address>
    <pubdate role="month">June</pubdate>
    <bibliomisc>http://www.riaca.win.tue.nl/projects/OpenMath/workshop</bibliomisc>
  </biblioentry>
  
  <biblioentry id="Cohen_Kohlhase_99om" role="misc">
    <author><firstname>Arjeh</firstname> <surname>Cohen</surname></author>
    <author><firstname>Michael</firstname> <surname>Kohlhase</surname></author>
    <title>Proposal of an Extension to &OM; by Defining
      Mathematical Properties</title>
    <bibliomisc>12th &OM; Workshop</bibliomisc>
    <pubdate role="month">June</pubdate>
    <pubdate>1999</pubdate>
    <bibliomisc>http://www.win.tue.nl/~amc/kohlhase.dvi</bibliomisc>
  </biblioentry>
  
  
  <biblioentry id="Caprotti_99CFCa" role="misc">
    <author><firstname>Olga</firstname> <surname>Caprotti</surname></author>
    <title>&OM;: Accessing and Using Mathematical Information Electronically</title>
    <bibliomisc>CFC meeting talk</bibliomisc>
    <pubdate role="month">May</pubdate>
    <pubdate>1999</pubdate>
    <bibliomisc>Slide presentation available at http://www.riaca.win.tue.nl/~olga/om/CFCom.ps</bibliomisc>
  </biblioentry>
  
  <biblioentry id="Caprotti_99CFCb" role="misc">
    <author><firstname>Olga</firstname> <surname>Caprotti</surname></author>
    <title>&OM; and COQ: Communicating Certified Mathematical Content</title>
    <bibliomisc>CFC meeting talk</bibliomisc>
    <pubdate role="month">May</pubdate>
    <pubdate>1999</pubdate>
    <bibliomisc>http://www.riaca.win.tue.nl/~olga/om/cfcCOCOM.ps</bibliomisc>
  </biblioentry>
  
  <biblioentry id="Caprotti_99imacs" role="misc">
    <author><firstname>Olga</firstname> <surname>Caprotti</surname></author>
    <title>Interfacing CA and Proof Checkers with &OM;</title>
    <bibliomisc>IMACA-ACA 99</bibliomisc>
    <pubdate role="month">June</pubdate>
    <pubdate>1999</pubdate>
  </biblioentry>
  
  
  <biblioentry id="Caprotti_Carlisle_99" role="Article">
    <author><firstname>Olga</firstname> <surname>Caprotti</surname></author>
    <author><firstname>David</firstname> <surname>Carlisle</surname></author>
    <title>&OM; and MathML: Semantic Mark Up for Mathematics</title>
    <bibliomisc role="journal">Crossroad</bibliomisc>
    <pubdate>1999</pubdate>
    <bibliomisc role="volume">Special Issue on Markup Languages</bibliomisc>
    <bibliomisc>http://www.acm.org/crossroads</bibliomisc>
  </biblioentry>
  
  <biblioentry id="Caprotti_Cohen_99calc" role="InProceedings">
    <author><firstname>Olga</firstname> <surname>Caprotti</surname></author>
    <author><firstname>Arjeh</firstname> <surname>Cohen</surname></author>
    <title>Integrating Computational and Deduction Systems Using &OM;</title>
    <title role="book">Proceedings of Calculemus 99</title>
    <pubdate>1999</pubdate>
    <address>Trento</address>
    <pubdate role="month">July</pubdate>
  </biblioentry>
  
  <biblioentry id="Caprotti_Cohen_99iamc" role="InProceedings">
    <author><firstname>Olga</firstname> <surname>Caprotti</surname></author>
    <author><firstname>Arjeh</firstname> <surname>Cohen</surname></author>
    <title>Interactive Mathematics with Strong &OM;</title>
    <title role="book">Internet Accessible Mathematical Computation</title>
    <pubdate>1999</pubdate>
    <address>Vancouver, Canada</address>
    <pubdate role="month">July 28</pubdate>
    <bibliomisc>http://symbolicnet.mcs.kent.edu/icm/research/iamc99proceedings.html</bibliomisc>
  </biblioentry>
  
  <biblioentry id="url_OMsem99" role="misc">
    <title>Seminar on &OM; for Industry</title>
    <bibliomisc>http://www.riaca.win.tue.nl/projects/OpenMath/convention.html</bibliomisc>
    <pubdate role="month">June</pubdate>
    <pubdate>1999</pubdate>
  </biblioentry>
  
  <biblioentry id="url_OMworkshop12" role="misc">
    <title>12th  &OM; Workshop</title>
    <bibliomisc>http://www.riaca.win.tue.nl/projects/OpenMath/workshop/</bibliomisc>
    <pubdate role="month">June 15&#8211;16</pubdate>
    <pubdate>1999</pubdate>
  </biblioentry>

  <biblioentry id="url_JSON" role="misc" revisionflag="added">
    <title>JSON (JavaScript Object Notation)</title>
    <pubdate role="month">July 5</pubdate>
    <pubdate>2019</pubdate>
    <bibliomisc>http://json.org/</bibliomisc>
  </biblioentry>

  <biblioentry id="handrewsjsonschema" role="misc" revisionflag="added">
    <author><firstname>H.</firstname> <surname>Andrews</surname></author>
    <author><firstname>A.</firstname> <surname>Wright</surname></author>
    <title>JSON Schema: A Media Type for Describing JSON Documents</title>
    <pubdate role="month">March 19</pubdate>
    <pubdate>2018</pubdate>
    <bibliomisc>https://tools.ietf.org/html/draft-handrews-json-schema-01</bibliomisc>
  </biblioentry>
  
  <biblioentry id="url_typescript" role="misc" revisionflag="added">
    <title>TypeScript - JavaScript that scales.</title>
    <pubdate role="month">July 5</pubdate>
    <pubdate>2019</pubdate>
    <bibliomisc>https://www.typescriptlang.org/</bibliomisc>
  </biblioentry>

  <biblioentry id="url_vega-ts-jscon-schema-generator" role="misc" revisionflag="added">
    <author><firstname>Dominik</firstname> <surname>Moritz</surname></author>
    <title>ts-json-schema-generator</title>
    <pubdate role="month">July 5</pubdate>
    <pubdate>2019</pubdate>
    <bibliomisc>https://github.com/vega/ts-json-schema-generator</bibliomisc>
  </biblioentry>
  
</bibliography>
</book>



<!--  LocalWords:  Buswell Caprotti machine-generatable summarizes recognize bignums th
-->
<!--  LocalWords:  cdbase bytearray bytearrays indeterminates rdf transc1 mathml:csymbol
-->
<!--  LocalWords:  xmlns:mathml xsd:NCName rfc aritherror mathml unhandled_csymbol xmlns
-->
<!--  LocalWords:  Acyclicity varname cdname symbname bvars attrpairs attrvar xf 160;the
-->
<!--  LocalWords:  characterize arith1:plus arith1 documentclass maketitle regexp-based
-->
<!--  LocalWords:  openmath.rnc attlist.OMS arith1.rnc arith1.ocd Freundt Roozemond Nuprl
-->
<!--  LocalWords:  Gonnet Fuchssteiner Cleaveland Mendler Panangaden TeXbook Ppml Spivak
-->
<!--  LocalWords:  Beguelin Dongarra Manchek Sunderam factorization Capani Niesi Robbiano
-->
<!--  LocalWords:  Giovini Bibliomiscs Visigenic Pingali Vavasis Zippel Melham Mechanized
-->
<!--  LocalWords:  Gefwert Orponen Voronkov Ballarin Calmet Levelt Howgrave-Graham Andr
-->
<!--  LocalWords:  Strotmann bner Bibliomisc ller Manocha Multipolynomial Waldspurger
-->
<!--  LocalWords:  Sausse Vorkoetter Shand Marrin Formalized Lemmink isenkatu Seppala
-->
<!--  LocalWords:  Geuvers Calculemus Borenstein Yergeau Arjeh Jebelean Kriftner Tomuta
-->
<!--  LocalWords:  Vasaru Analytica Devitt Soiffer Sutor CtCoqmath Pecchiari Talcott
-->
<!--  LocalWords:  Bertot Well-formedness Labrou phane Huchet Limongelli cdgroup 160;the
-->
<!--  LocalWords:  prioritized Internationalized 160;the cdurl n-ary Composability
-->
<!--  LocalWords:  standarized 160;the
-->