The &OM; Standard

List of Figures &OM; Movement Changed title This chapter is a historical account of &OM; and should be regarded as non-normative. &OM; is a standard for representing mathematical objects, allowing them to be exchanged between computer programs, stored in databases, or published on the worldwide web. While the original designers were mainly developers of computer algebra systems, it is now attracting interest from other areas of scientific computation and from many publishers of electronic documents with a significant mathematical content. There is a strong relationship to the MathML recommendation MathML_2000 from the Worldwide Web Consortium, and a large overlap between the two developer communities. MathML deals principally with the presentation of mathematical objects, while &OM; is solely concerned with their semantic meaning or content. While MathML does have some limited facilities for dealing with content, it also allows semantic information encoded in &OM; to be embedded inside a MathML structure. Thus the two technologies may be seen as highly complementary.

History Reword to reflect birth of&OM;Society &OM; was originally developed through a series of workshops held in Zurich (1993 and 1996), Oxford (1994), Amsterdam (1995), Copenhagen (1995), Bath (1996), Dublin (1996), Nice (1997), Yorktown Heights (1997), Berlin (1998), and Tallahassee (1998). The participants in these workshops formed a global &OM; community which was coordinated by a Steering Committee and operated through electronic mailing groups and ad-hoc working parties. This loose arrangement has been formalised through the establishment of an &OM; Society. Up until the end of 1996 much of the work of the community was funded through a grant from the Human Capital and Mobility program of the European Union, the contributions of several institutions and individuals. A document outlining the objectives and basic design of &OM; was produced (later published as Abbott_Leeuwen_Strotmann_98). By the end of 1996 a simplified specification had been agreed on and some prototype implementations have come about Dalmas_Gaetano_Watt_97. Extend History slightly In 1996 a group of European participants in &OM; decided to bid for funding under the European Union's Fourth Framework Programme for strategic research in information technology. This bid was successful and the project started in late 1997. The principal aims of the project are to formalise &OM; as a standard and to develop it further through industrial applications; this document is a product of that process and draws heavily on the previous work described earlier. &OM; participants from all over the world continue to meet regularly and cooperate on areas of mutual interest, and recent workshops in Tallahassee (November 1998) and Eindhoven (June 1999) endorsed drafts of this document as the current &OM; standard. Final conclusion paragraph removed

&OM; Society New section In November 1998 the &OM; Society has been established to coordinate all &OM; activities. The society is based in Helsinki, Finland and is steered by the executive committee whose members are elected by the society. The official web page of the society is http://www.openmath.org.

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

&OM; Architecture

The &OM; Architecture The architecture of &OM; is described in and summarizes the interactions among the different &OM; components. There are three layers of representation of a mathematical object OM_98. A private layer that is the internal representation used by an application. An abstract layer that is the representation as an &OM; object. Third is a communication layer that translates the &OM; object representation to a stream of bytes. An application dependent program manipulates the mathematical objects using its internal representation, it can convert them to &OM; objects and communicate them by using the byte stream representation of &OM; objects.

&OM; Objects and Encodings Moved this section up, to mirror chapter sequence &OM; objects are representations of mathematical entities that can be communicated among various software applications in a meaningful way, that is, preserving their semantics. &OM; objects and encodings are described in detail in and . Note on encodings and possibility of other encodings The standard endorses encodings in &exml; and binary format. These are the encodings supported by the official &OM; libraries. However they are not the only possible encodings of &OM; objects. Users that wish to define their own encoding using some other specific language (e.g. Lisp) may do so provided there is an effective translation of this encoding to an official one.

Content Dictionaries Content Dictionaries (CDs) are used to assign informal and formal semantics to all symbols used in the &OM; objects. They define the symbols used to represent concepts arising in a particular area of mathematics. The Content Dictionaries are public, they represent the actual common knowledge among &OM; applications. Content Dictionaries fix the meaning 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.

Additional Files This is new Several additional files are related to Content Dictionaries. Signature files contain the signatures of symbols defined in some &OM; Content Dictionary and their format is endorsed by this standard. Furthermore, the standard fixes how to define as a CDGroup a specific set of Content Dictionaries. Auxiliary files that define presentation and rendering or that are used for manipulating and processing Content Dictionaries are not discussed by the standard. Removed mention to DefMP files

Phrasebooks The conversion of an &OM; object to/from the internal representation in a software application is performed by an interface program called Phrasebook. 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 Phrasebook of the application is able to translate &OM; objects built using symbols from these Content Dictionaries to/from the internal mathematical objects of the application. Reword &OM; objects 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 evaluation or simplification of objects like

2 + 3

\sin (π)

. Thus, the same object

2 + 3

could be transformed to

5

by a computer algebra system, or displayed as

2 + 3

by a typesetting tool.

&OM; Objects Reshuffled the sections on &OM; Objects In this chapter we provide a self-contained description of &OM; objects. We first do so at an informal level () and next by means of an abstract grammar description ().

Formal Definition of &OM; Objects Restructure the definition of &OM; Objects &OM; represents mathematical objects as terms or as labelled trees that are called &OM; objects or &OM; expressions. The definition of an abstract &OM; object is then the following.

Basic &OM; objects The Basic &OM; Objects form the leaves of the &OM; Object tree. A Basic &OM; Object is of one of the following. Expand descriptions of basic objects (i) Integer. Integers in the mathematical sense, with no predefined range. They are infinite precision integers (also called bignums in computer algebra). (ii) IEEE floating point number. Double precision floating-point numbers following the ieee 754-1985 standard ieee754_85. (iii) Character string. A Unicode Character string. This also corresponds to `characters' in &exml;. (iv) Bytearray. A sequence of bytes. (v) Symbol. A Symbol encodes two fields of information, a name and a Content Dictionary. Each is a sequence of characters matching a regular expression, as described below. A Symbol encodes three fields of information, a name, a Content Dictionary, and (optionally) a role. The name of a symbol is a sequence of characters matching the regular expression described in . 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 ) and, optionally, a unique prefix called a cdbase which is used to disambiguate multiple Content Dictionaries of the same name. The role is a restriction on where the symbol may appear in an &OM; object. The possible roles are described in . (vi) Variable. A Variable consists of must have a name which is a sequence of characters matching a regular expression, as described in . Where the variable is a member of an enumerated set it also has a child which is an &OM; object representing its indices.

Derived &OM; Objects A derived &OM; object is built as follows: (i) If

A

is not an &OM; object, then

foreign (A)

is an &OM; foreign object.

Compound &OM; Objects &OM; objects are built recursively as follows. (i) Basic &OM; objects are &OM; objects. Derived &OM; objects are not &OM; objects. (ii) If

A_{1}

, …,

A_{n}

(n > 0)

are &OM; objects, then

application (A_{1}, \dots, A_{n})

is an &OM; application object. Cleaned up Attribution (iii) If

S_{1}, \dots, S_{n}

are &OM; symbols, and

A

A_{1}

, …,

A_{n}

(n > 0)

are &OM; objects, then

A

is an &OM; object, and

A_{1}

, …,

A_{n}

(n > 0)

are &OM; objects or &OM; derived objects, then

attribution (A, S_{1} A_{1}, \dots, S_{n} A_{n})

is an &OM; attribution object. and

A

is the object stripped of attributions.

S_{1}, \dots, S_{n}

are referred to as keys and

A_{1}

, …,

A_{n}

as their associated values. The operation of recursively applying stripping to the stripped object is called flattening of the attribution. When the stripped object after flattening is a variable, the attributed object is called attributed variable. (iv) If

B

and

C

are &OM; objects, and

v_{1}

\dots

v_{n}

(n \geq 0)

are &OM; variables or attributed variables, then

binding (B, v_{1}, \dots, v_{n}, C)

is an &OM; binding object. (v) If

S

is an &OM; symbol and

A_{1}

, …,

A_{n}

(n \geq 0)

are &OM; objects, then

error (S, A_{1}, \dots, A_{n})

is an &OM; error object.

&OM; Symbol Rôles The rôle of an &OM; symbol is a restriction on where it can appear in an &OM; object. A symbol cannot have more than one role. If no role is indicated then the symbol can be used anywhere. Possible roles are: binder The symbol may only appear as the first child of an &OM; binding object. attribution The symbol may only be used as key in an &OM; attribution object, i.e. as the first element of a key-value pair, or in an equivalent context (for example to refer to the value of an attribution). This form of attribution may be ignored by an application, so should be used for information which does not change the meaning of the attributed &OM; object. semantic-attribution This is the same as attribution except that it modifies the meaning of the attributed &OM; object and thus cannot be ignored by an application. error The symbol can only appear as the first child of an &OM; error object. default The symbol can appear anywhere not defined in the previous four cases.

Further Description of &OM; Objects Condensed Informal and Notes Add integer and float Informally, an &OM; object can be viewed as a tree and is also referred to as a term. The objects at the leaves of &OM; trees are called basic objects. The basic objects supported by &OM; are: IntegerArbitrary Precision integers. Float &OM; floats are ieee 754 Double precision floating-point numbers. Other types of floating point number may be encoded in &OM; by the use of suitable content dictionaries. Character stringsare sequences of characters. These characters come from the Unicode standard UNICODE. Bytearraysare sequences of bytes. There is no byte 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 `handles' into computations or databases. Symbols Change Example Remove ' from regexp are uniquely defined by the Content Dictionary in which they occur and by a name. In definition in we have left this information implicit. However, it should be kept in mind that all symbols appearing in an &OM; object are defined in a Content Dictionary. The form of these definitions is explained in . Each symbol has no more than one definition in a Content Dictionary. Many Content Dictionaries may define differently a symbol with the same name (e.g. the symbol union is defined as associative-commutativeset theoretic union in a Content Dictionary set1 but another Content Dictionary, multiset1 might define a symbol union as the union of multi-sets). The name of a symbol can only contain alphanumeric characters and underscores. More precisely, a symbol name matches the following regular expression:

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

Notice that these symbol names are case sensitive. &OM; recommends that symbol names should be no longer than 100 characters. Removed suggestion to utf7 hint variable names Variablesare meant to denote parameters, variables or indeterminates (such as bound variables of function definitions, variables in summations and integrals, independent variables of derivatives). Plain variable names are restricted to use a subset of the printable ASCII characters. Formally the names must match the regular expression:

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

A variable may have one or more children which are themselves &OM; objects and are treated as scripts. Thus it is possible to create a variable with cardinality such as

x_{1}

x_{i}

. Currently there is one way of making a derived &OM; object. Foreignis 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. The four following constructs can be used to make compound &OM; objects. Applicationconstructs an &OM; object from a sequence of one or more &OM; objects. The first argument of application is referred to as head while the remaining objects are called arguments. An &OM; application object can be used to convey the mathematical notion of application of a function to a set of arguments. For instance, suppose that the &OM; symbol

\sin

is defined in a Content Dictionary for trigonometry, then

application (\sin, x)

is the abstract &OM; object corresponding to

\sin (x)

. More generally, an &OM; application object can be used as a constructor to convey a mathematical object built from other objects such as a polynomial constructed from a set of monomials. Constructors build inhabitants of some symbolic type, for instance the type of rational numbers or the type of polynomials. The rational number, usually denoted as

1 / 2

, is represented by the &OM; application object

application (Rational, 1, 2)

. The symbol

Rational

must be defined, by a Content Dictionary, as a constructor symbol for the rational numbers.

The &OM; application and binding objects for <math><mi>sin</mi> <mo>(</mo><mi>x</mi> <mo>)</mo></math> and <math><mi>λ</mi> <mi>x</mi><mo>.</mo><mi>x</mi> <mo>+</mo> <mn>2</mn></math> in tree-like notation. New tree figure, suggested by Andreas Strotmann Bindingobjects are constructed from an &OM; object, and from a sequence of zero or more variables followed by another &OM; object. The first &OM; object is the binder object. Arguments 2 to

n - 1

are always variables to be bound in the body which is the

n^{th}

argument object. It is allowed to have no bound variables, but the binder object and the body should be present. Binding can be used to express functions or logical statements. The function

λ x . x + 2

, in which the variable

x

is bound by

λ

, corresponds to a binding object having as binder the &OM; symbol

lambda

binding (lambda, x, application (plus, x, 2)) .

Phrasebooks are allowed to use

α

conversion in order to avoid clashes of variable names. Suppose an object

Ω

contains an occurrence of the object

binding (B, v, C)

. This object

binding (B, v, C)

can be replaced in

Ω

binding (B, z, C')

where

z

is a variable not occurring free in

C

and

C'

is obtained from

C

by replacing each free (i.e., not bound by any intermediate binding construct) occurrence of

v

z

. This operation preserves the semantics of the object

Ω

. In the above example, a phrasebook is thus allowed to transform the object to, e.g.

binding (lambda, v, binding (lambda, z, application (times, z, z))) .

binding (lambda, z, application (plus, z, 2)) .

Repeated occurrences of the same variable in a binding operator are allowed. An &OM; application should treat a binding with multiple occurrences of the same variable as equivalent to the binding in which all but the last occurrence of each variable is replaced by a new variable which does not occur free in the body of the binding.

binding (lambda, v, v, application (times, v, v))

is semantically equivalent to:

binding (lambda, v^{'}, v, application (times, v, v))

so that the resulting function is actually a constant in its first argument (

v^{'}

does not occur free in the body

application (times, v, v))

). Attributiondecorates an object with a sequence of one or more pairs made up of an &OM; symbol, the attribute, and an associated &OM; object, the value of the attribute. The value of the attribute can be an &OM; attribution object 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. &OM; objects can be attributed with &OM; derived objects, which are containers for non-&OM; structures. For example a mathematical expression could be attributed with its spoken or visual rendering. Composition of attributions, as in

attribution (attribution (A, S_{1} A_{1}, \dots, S_{h} A_{h}), S_{h + 1} A_{h + 1}, \dots, S_{n} A_{n})

is semantically equivalent to a single attribution, that is

attribution (A, S_{1} A_{1}, \dots, S_{h} A_{h}, S_{h + 1} A_{h + 1}, \dots, S_{n} A_{n}) .

The operation that produces an object with a single layer of attribution is called flattening. Multiple attributes with the same name are allowed. While the order of the given attributes does not imply any notion of priority, potentially it could be significant. For instance, consider the case in which

S_{h} = S_{n}

(

h < n

) in the example above. Then, the object is to be interpreted as if the value

A_{n}

overwrites the value

A_{h}

. (&OM; however does not mandate that an application preserves the attributes or their order.) Attribution acts as either adornment annotation or as semantical annotation. When the key has rôle attribution, then replacement of the attributed object by the object itself is not harmful and preserves the semantics. When the key has rôle semantic-attribution then the attributed object is modified by the attribution and cannot be viewed as semantically equivalent to the stripped object. If the attribute lacks the rôle specification then attribution is acting as adornment annotation. Removed reference to syntactic class of an attributed variable Objects can be decorated in a multitude of ways. In OM_D131b, typing of &OM; objects is expressed by using an attribution. The object

attribution (A, type t)

represents the judgment stating that object

A

has type

t

. Note that both

A

and

t

are &OM; objects. Attribution can act as either annotation, in the sense of adornment, or as modifier. In the former case, replacement of the adorned object by the object itself is probably not harmful (preserves the semantics). In the latter case however, it may very well be. Therefore, attribution in general should by default be treated as a construct rather than as adornment. Only when the CD definitions of the attributes make it clear that they are adornments, can the attributed object be viewed as semantically equivalent to the stripped object. Erroris 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. Error objects might consist only of a symbol as in the object:

error (S)

. Remove classification of suggested error types, does not fit current CD scheme

Names The names of symbols, variables and content dictionaries must conform to the following rules, which are designed to be compatible with standards such as Unicode and XML. These standards group individual characters into letters, digits, combining characters and extenders. Informally, these are defined as follows: Letters are elements of an alphabet such as latin, cyrillic, kanji etc. Digits are atomic numbers, from which compound numbers can be constructed (for example `1' is a digit but `11' is not). Combining Characters are used to combine several characters to produce a new one, for example an accented character. Extenders are characters which are neither letters nor combining characters but modify the appearance of other characters in some way. Formally, we use the precise definitions given in the Unicode standard UNICODE. Then a legal &OM; name is defined by the following grammar:

Name $⟶$ (Letter | '_') (Char)* Char $⟶$ Letter | Digit | '.' | '-' | '_' | CombiningChar | Extender

CD Base A cdbase must conform to the grammar for URIs described in IETF2396. Note that if non-ASCII characters are used in a CD or symbol name then when a URI for that symbol is constructed it will be necessary to map the non-ASCII characters to a sequence of octets. The precise mechanism for doing this depends on the URI scheme. Note on content dictionary names 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; recommends that the name be restricted to the subset of the above grammar which is a legal POSIX POSIX filename, namely:

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

Summary &OM; supports basic objects like integers, symbols, floating-point numbers, character strings, bytearrays, and variables. &OM; compound objects are of four kinds: applications, bindings, errors, and attributions. &OM; objects may be attributed with non-&OM; objects via the use of derived &OM; objects. &OM; objects have the expressive power to cover all areas of computational mathematics. Paragraph moved from previous section Observe that an &OM; application object is viewed as a tree by software applications that do not understand Content Dictionaries, whereas a Phrasebook that understands the semantics of the symbols, as defined in the Content Dictionaries, should interpret the object as functional application, constructor, or binding accordingly. Thus, for example, for some applications, the &OM; object corresponding to

2 + 5

may result in a command that writes

7

&OM; Encodings 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. The first encoding uses ISO 646:1983 characters iso646_83 (also known as ascii characters) and is an &exml; application. Although the &exml; markup of the encoding uses only ascii characters, &OM; strings may use arbitrary Unicode/ISO 10646:1988 characters UNICODE. It can be used, for example, to send &OM; objects via e-mail, news, cut-and-paste, etc. The texts produced by this encoding can be part of &exml; documents. The first encoding is a 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. The second encoding is a binary encoding that is meant to be used when the compactness of the encoding is important (interprocess communications over a network is an example). Note that these two encodings are sufficiently different for autodetection to be effective: an application reading the bytes can very easily determine which encoding is used.

The &exml; Encoding This encoding has been designed with two main goals in mind: to provide an encoding that uses common character sets (so that it can be easily included in most documents and transport protocols) and that is both readable and writable by a human. to provide an encoding that can be included (embedded) in &exml; documents or processed by &exml;-aware applications.

A <phrase revisionflag="deleted">Grammar</phrase><phrase>Schema</phrase> for the &exml; Encoding Modify description of &exml; encoding to make dtd normative, and other changes to increase portability to &exml; applications. The &exml; encoding of an &OM; object is defined by the Relax NG schema RELAX given below. Relax NG has a number of advantages over the older XSD Schema format XSD, 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 normative, it is generated from the using 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 . Standard tools exist for generating a DTD or an XSD schema from a Relax NG Schema. Examples of such documents are given in and respectively. &omrnc; the &exml; encoding of an &OM; object is defined by the dtd given in Figure 4.1 below with the following additional rules not implied by the &exml; dtd. Comments are permitted only between elements, not within element character data. Processing Instructions are only allowed before the OMOBJ element. The content of an OMB element, is a valid base64-encoded text. The character data forming element content and attribute values matches the regular expressions of . DTD for the &OM; &exml; encoding of objects. ]]> ]]> ]]> ]]> ]]> ]]> ]]> ]]> ]]> ]]> ]]> In addition, if the &exml; document encoding the &OM; object is linearised into the &exml; concrete syntax, the following further constraints apply, which ensure thet the encoding may be read by &OM; applications that may not include a full &exml; parser. Restrictions on not using foo='xxxx' dropped The document should use utf-8 encoding. A <!DOCTYPE declaration should not be used. Character references should not be used. As <!DOCTYPE is not used, the only entity references that are allowed are the five predefined entity references: ' ('), " ("), < (<), > (>), & (&). Restrict empty element syntax The &exml; empty element form <|…/> should always be used to encode elements such as omf which are specified in the dtd as being empty. It should never be used for elements that may sometimes be empty, such as omstr. Such a linearisation of an &exml; encoded &OM; Object would match the match the character based grammar given in . The notation used in this section and in should be quite straightforward (+ meaning one or more, ? meaning zero or one, and | meaning or). The start symbol of the grammar is start, space stands for the space character, cr for the carriage return character, nl for the line feed character and tab for the horizontal tabulation character. Grammar for the &exml; encoding of &OM; objects. White space allowed in integer strings S

⟶

(space | tab | cr | nl)+ integer

⟶

(- S?)? [&digits;]+ (S [&digits;]+)* | (- S?)? x S? [&exadigits;]+ (S [&exadigits;]+)* cdname

⟶

[&lcalpha;][&lcalpha;&digits;_]* symbname

⟶

[&ucalpha;&lcalpha;][&ucalpha;&lcalpha;&digits;_]* fpdec

⟶

(-?)([&digits;]+)?(.[&digits;]+)?(e(&sign;?)[&digits;]+)? fphex

⟶

[&digits;ABCDEF]+ varname

⟶

([&ucalpha;&lcalpha;&digits;&varnamechar;])+ base64

⟶

([&ucalpha;&lcalpha;&digits; +/=] | S)+ char

⟶

&exml; Character Data removed ' from varname symbnameatt

⟶

name S? = S? (" symbname " | ' symbname ') cdnameatt

⟶

cd S? = S? (" cdname " | ' cdname ') varnameatt

⟶

name S? = S? (" varname " | ' varname ') fpdecatt

⟶

dec S? = S? (" fpdec " | ' fpdec ') fphexatt

⟶

hex S? = S? (" fphex " | ' fphex ') PI

⟶

<? char ?> comment

⟶

<!-&zsp;- char -&zsp;-> SC

⟶

S+ | (comment S)+ start

⟶

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

⟶

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

⟶

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

⟶

<OMATP S?> SC? attrs SC? </#1 S?> object

⟶

⟶

symbol S? object | symbol S? object S? attrs objects

⟶

SC? | object SC? objects variables

⟶

SC? | variable SC? variables

<phrase revisionflag="added">Informal</phrase> description of the <phrase revisionflag="deleted">Grammar</phrase><phrase revisionflag="added">&exml; Encoding</phrase> An encoded &OM; object is placed inside an OMOBJ element. This element can contain the elements (and integers) described above. It can take an optional version &exml;-attribute which indicates to which version of the &OM; standard it conforms. This would allow an older &OM; application which, for example, could not parse the full &exml; syntax, to accept objects with version "1" or "1.1" but reject objects with version "2". We briefly discuss the &exml; encoding for each type of &OM; object starting from the basic objects. Integers White space allowed in integer strings are encoded using the OMI element around the sequence of their digits in base 10 or 16 (most significant digit first). White space may be inserted between the characters of the integer representation, this will be ignored. After ignoring white space, integers written in base 10 match the regular expression -?[0-9]+. Integers written in base 16 match -?x[0-9A-F]+. The integer 10 can be thus encoded as <OMI> 10 </OMI> or as <OMI> xA </OMI> but neither <OMI> +10 </OMI> nor <OMI> +xA </OMI> can be used. The negative integer

-120

can be encoded as either as decimal <OMI> -120 </OMI> or as hexadecimal <OMI> -x78 </OMI>. Symbolsare encoded using the OMS element. This element has two three &exml;-attributes cd, name, and cdbase. The value of cd is the name of the Content Dictionary in which the symbol is defined and the value of name is the name of the symbol. The optional cdbase attribute is a URI that can be used to disambiguate between two content dictionaries with the same name. The name of the Content Dictionary is compulsory, but a future revision of the &OM; standard might introduce a defaulting mechanism.w For example:

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

is the encoding of the symbol named sin in the Content Dictionary named transc, which is part of the collection maintained by the &OM; Society. The three attributes of the OMS can be used to build a URI reference for the symbol, for use in contexts where URI-based referencing mechanisms are used. This canonical URI reference is constructed as follows:

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

For example

]]>

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

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

Note that the role attribute described in is contained in the Content Dictionary and is not part of the encoding of a symbol. Variablesare encoded using the OMV element, with only one &exml;-attribute, name, whose value is the variable name. The variable name is a subset of the printable ascii set of characters. In particular, neither spaces nor double-quote " are allowed in variable names. For instance, the encoding of the object representing the variable

x

is: <OMV name="x"/> For an enumerated variable the index or indices of the variable are encoded as a child. So for example the encoding of the object representing the variable

x_{i + 1}

is: 1 ]]> Floating-point numbersare encoded using the OMF element that has either the &exml;-attribute dec or the &exml;-attribute hex. The two &exml;-attributes cannot be present simultaneously. The value of dec is the floating-point number expressed in base 10, using the common syntax:

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

The value of hex is the digits of the floating-point number expressed in base 16, with digits 0-9, A-F (mantissa, exponent, and sign from lowest to highest bits) using a least significant byte ordering. For example, <OMF dec="1.0e-10"/> is a valid floating-point number. Character stringsare encoded using the OMSTR element. Its content is a Unicode text (The default encoding is utf-8utf8, although &exml; encoded &OM; may be embedded in a containing &exml; document that specifies alternative encoding in the &exml; declaration. Note that as always in &exml; the characters < and & need to be represented by the entity references < and & respectively. Bytearraysare encoded using the OMB element. Its content is a sequence of characters that is a base64 encoding of the data. The base64 encoding is defined in rfc 1521 rfc1521. Basically, it represents an arbitrary sequence of octets using 64 digits (A through Z, a through z, 0 through 9, + and /, in order of increasing value). Three octets are represented as four digits (the = character for padding to the right at the end of the data). All line breaks and carriage return, space, form feed and horizontal tabulation characters are ignored. The reader is refered to rfc1521 for more detailed information. In detail the encoding of an &OM; object is described below. Applicationsare encoded using the OMA element. The application whose root is the &OM; object

e_{0}

and whose arguments are the &OM; objects

e_{1}

, …,

e_{n}

is encoded as <OMA>

C_{0}

C_{1}

…

C_{n}

</OMA> where

C_{i}

is the encoding of

e_{i}

. For example,

application (\sin, x)

is encoded as: ]]> provided that the symbol sin is defined to be a function symbol in a Content Dictionary named transc1. Bindingis encoded using the OMBIND element. The binding by the &OM; object

b

of the &OM; variables

x_{1}

x_{2}

\dots

x_{n}

in the object

c

is encoded as <OMBIND>

B

X_{1}

\dots

X_{n}

</OMBVAR>

C

</OMBIND> where

B

C

, and

X_{i}

are the encodings of

b

c

and

x_{i}

, respectively. For instance the encoding of

binding (lambda, x, application (\sin, x))

is: ]]> Binders are defined in Content Dictionaries, in particular, the symbol lambda is defined in the Content Dictionary fns1 for functions over functions. Attributionsare encoded using the OMATTR element. If the &OM; object

e

is attributed with (

s_{1}

e_{1}

), …, (

s_{n}

e_{n}

) pairs (where

s_{i}

are the attributes), it is encoded as <OMATTR> <OMATP>

S_{1}

C_{1}

…

S_{n}

C_{n}

</OMATP>

E

</OMATTR> where

S_{i}

is the encoding of the symbol

s_{i}

C_{i}

of the object

e_{i}

and

E

is the encoding of

e

. Examples are the use of attribution to decorate a group by its automorphism group: [..group-encoding..] [..group-encoding..] ]]> or to express the type of a variable: ]]> A special use of attributions is to associate non-&OM; data with an &OM; object. This is done using the OMFOREIGN element. The children of this element must be well-formed &exml;. For example the attribution of the &OM; object

\sin (x)

with its representation in Presentation MathML is:

\sin (x)

]]> Of course not everything has a natural XML encoding in this way and often the contents of a OMFOREIGN will just be data or some kind of encoded string. For example the attribution of the previous object with its LaTeX representation could be achieved as follows: sin\,(x) ]]> Errors are encoded using the OME element. The error whose symbol is

s

and whose arguments are the &OM; objects

e_{1}

, …,

e_{n}

is encoded as <OME>

C_{s}

C_{1}

…

C_{n}

</OME> where

C_{s}

is the encoding of

s

and

C_{i}

the encoding of

e_{i}

. If an aritherror Content Dictionary contained a DivisionByZero symbol, then the object

error (DivisionByZero, application (divide, x, 0))

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

application (f, application (f, application (f, a, a), application (f, a, a)), application (f, application (f, a, a), application (f, a, a)))

can be encoded in the &exml; encoding as either one of the &exml; encodings below (and some intermedidate versions as well).

Shared vs. unshared representations ]]> We say that an &OM; element dominates all its children and all elements they dominate. An OMR element dominates its target, i.e. the element that carries the id attribute pointed to by the xref attribute. For instance in the representation in Figure , the OMA element with id="t1" and also the second OMR dominate the OMA element with id="t11".

An Acyclicity Constraint The occurrences of the OMR element must obey the following global acyclicity constraint: An &OM; element may not dominate itself. Consider for instance the following (illegal) &exml; representation 1 1 ]]> Here, the OMA element with id="foo" dominates its second child, which dominates the OMR element, which dominates its target: the element with id="foo". So by transitivity, this element dominates itself, and by the acyclicity constraint, it is not the &exml; representation of an &OM; element. Even though it could be given the interpretation of the continued fraction

\frac{1}{1 + \frac{1}{1 + \frac{1}{...}}}

this would correspond to an infinite tree of applications, which is not admitted by the structure of &OM; objects described in section 3. Note that the acyclicity constraints is not restricted to such simple cases, as the following example shows. 1 1 ]]> Here, the OMA with id="bar" dominates its second child, the OMR with xref="baz", which dominates its target OMA with id="baz", which in turn dominates its second child, the OMR with xref="bar", this finally dominates its target, the original OMA element with id="bar". So this pair of &OM; objects violates the acyclicity constraint and is not the &exml; representation of an &OM; object.

Sharing and Bound Variables Note that the OMR element is a syntactic referencing mechanism: an OMR 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: ]]> it represents the &OM; object

binding (λ, X, application (f, binding (λ, X, application (g, X)), application (g, X))))

which has two subterms of the form

application (g, X)

, one with id="orig" (the one explicitly represented) and one with id="copy", represented by the OMR element. In the original, the variable

X

is bound by the outer OMBIND element, and in the copy, the variable

X

is bound by the inner OMBIND element. We say that the inner OMBIND has captured the variable

X

. It is well-known that variable capture does not conserve semantics. For instance, we could use

α

-conversion to rename the inner occurrence of

x

into - say -

y

arriving at the (same) object

binding (λ, X, application (f, binding (λ, Y, application (g, Y)), application (g, X))))

Using references that capture variables in this way can easily lead to representation errors, and is not recommended.

Embedding &OM; in &exml; Documents New section on embedding &OM; in &exml; documents 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. 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 xmlns or xml:lang attributes to specify the language used in strings xml. Also, the encoding used in the larger document may not be utf-8. Namespace URI, as discussed on&OM;Soc list In particular, if &OM; is used with applications that use the &exml; Namespace Recommendation xmlns then they should ensure that &OM; elements are in the namespace http://www.openmath.org/OpenMath. This is most conveniently achieved by adding the namespace declaration xmlns="http://www.openmath.org/OpenMath" as an attribute to each OMOBJ element in the document. If such &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 grammar specified above.

The Binary Encoding 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).

A Grammar for the Binary Encoding New attrvar production

Grammar of the binary encoding of &OM; objects. start

⟶

[24] object [25] | [24+64] object [25] object

⟶

⟶

[1] [_] | [1+64] [

n

] id:

n

[_] | [1+128] {_} | [1+64+128] {

n

} id:

n

{_} | [2] [

n

] [_] digits:

n

| [2+64] [

n

] [

m

] [_] digits:

n

id:

m

| [2+128] {

n

} [_] digits:

n

| [2+64+128] {

n

} {

n

} [_] digits:

n

id:

n

float

⟶

[3] {_}{_} | [3+64] [

n

] id:

n

{_}{_} variable

⟶

[5] [

n

] varname:

n

| [5+64] [

n

] [

m

] varname:

n

id:

m

| [5+128] {

n

} varname:

n

| [5+64+128] {

n

} {

m

} varname:

n

id:

m

indexed_variable

⟶

[10] [

n

] varname:

n

object [11]

|

[10+64] [

n

] [

m

] varname:

n

id:

m

object [11]

|

[10+128] {

n

} varname:

n

object [11]

|

[10+64+128] {

n

} {

m

} varname:

n

id:

m

object [11] symbol

⟶

[8] [

n

] [

m

] cdname:

n

symbname:

m

| [8+64] [

n

] [

m

] [

k

] cdname:

n

symbname:

m

id:

k

| [8+128] {

n

} {

m

} cdname:

n

symbname:

m

| [8+64+128] {

n

} {

m

} {

k

} cdname:

n

symbname:

m

id:

k

| [9] [

n

] [

m

] [

k

] cdname:

n

symbname:

m

uri:

k

| [9+64] [

n

] [

m

] [

k

] [

l

] cdname:

n

symbname:

m

uri:

k

id:

l

| [9+128] {

n

} {

m

} {

k

} cdname:

n

symbname:

m

uri:

k

| [9+64+128] {

n

} {

m

} {

k

} {

l

} cdname:

n

symbname:

m

uri:

k

id:

l

string

⟶

[6] [

n

] chars bytes:

n

| [6+64] [

n

] chars bytes:

n

| [6+128] {

n

} chars bytes:

n

| [6+64+128] {

n

} {

m

} chars bytes:

n

id:

m

| [7] [

n

] chars bytes:

2 n

| [7+64] [

n

] [

m

] chars bytes:

n

id:

m

| [7+128] {

n

} chars bytes:

2 n

| [7+64+128] {

n

} {

m

} chars bytes:

2 n

id:

m

bytearray

⟶

[4] [

n

] bytes:

n

| [4+64] [

n

] [

m

] bytes:

n

id:

m

| [4+128] {

n

} bytes:

n

| [4+64+128] {

n

} {

m

} bytes:

n

id:

m

derived

⟶

[12] [

n

] bytes:

n

| [12+64] [

n

] [

m

] bytes:

n

id:

m

| [12+128] {

n

} bytes:

n

| [12+64+128] {

n

} {

m

} bytes:

n

id:

m

construct

⟶

[16] object objects [17] | [16+64] {

m

} id:

m

object objects [17] | [22] symbol objects [23] | [22+64] {

m

} id:

m

symbol objects [23] | [18] attrpairs object [19] | [18+64] {

m

} id:

m

attrpairs object [19] | [26] object bvars object [27] | [26+64] {

m

} id:

m

object bvars object [27] attrpairs

⟶

[20] pairs [21] | [20+64] {

m

} id:

m

pairs [21] pairs

⟶

symbol object | symbol object pairs bvars

⟶

[28] vars [29] | [28+64] {

m

} id:

m

vars [29] vars

⟶

attrvar | attrvar vars attrvar

⟶

variable | [18] attrpairs attrvar [19] | [18+64] {

m

} id:

m

attrpairs attrvar [19] objects

⟶

object objects internal_reference

⟶

[30] [_] | [30+128] {_} external_reference

⟶

[31] [

n

] uri:

n

| [31+128] {

n

} uri:

n

Figure gives a grammar for the binary encoding (start is the start symbol).. The following conventions are used in this section: [

n

] denotes a byte whose value is the integer

n

(

n

can range from 0 to 255), {

m

} denotes four bytes representing the (unsigned) integer

m

in network byte order, [_] denotes an arbitrary byte, {_} denotes an arbitrary sequence of four bytes. name:

n

denotes a sequence of

n

bytes named name. name:2

n

denotes a sequence of

2 n

bytes. start is the start symbol of the grammar. xxxx:

n

, where xxxx is one of symbname, cdname, varname, uri, id, digits, or bytes denotes a sequence of

n

bytes that conforms to the constraints on xxxx strings. For instance, for symbname, varname, or cdnamethis is the regular expression described in , for uri it is the grammar for URIs in IETF2396.

Description of the Grammar An &OM; object is encoded as a sequence of bytes starting with the begin object tag (value 24 values 24 and 88) and ending with the end object tag (value 25 values 25 and 89). These are similar to the <OMOBJ> and </OMOBJ> tags of the &exml; encoding. The encoding of each kind of &OM; object begins with a tag that is a single byte, holding a token identifier that describes the kind of object and two flags, the long flag and the shared flag. The identifier is stored in the first 6 bits (1 to 6). The long flag is the eighth bit and the shared flag is the seventh bit. If the long flag is set, this signifies that the names, strings, and data fields in the encoded &OM; object are longer than 255 byte or characters. The sharing flag indicates that the encoded object is shared in another (part of an) object somewhere else (see ). Note that if the sharing flag is set (in the right column of the grammar in Figure , then the encoding includes a representation of the identifier. Here is a description of the binary encodings of every kind of &OM; object: Integersare encoded depending on how large they are. There are four possible formats. Integers between -128 and 127 are encoded as the small integer (token identifier 1) followed by a single byte that is the value of the integer (interpreted as a signed character). For example 16 is encoded as 0x01 0x10. Integers between

{-2}^{31}

(

-2147483648

) and

2^{31} - 1

(

2147483647

) are encoded as the small integer tag with the long flag set followed by the integer encoded in little endian format on four bytes (network byte order: the most significant byte comes first). For example, 128 is encoded as 0x81 0x00000080. The most general encoding begins with the big integer tag (token identifier 2) with the long flag set if the number of bytes in the encoding of the digits is greater or equal than 256. It is followed by the length (in bytes) of the sequence of digits, encoded on one byte (0 to 255, if the long flag was not set) or four bytes (network byte order, if the long flag was set). It is then followed by a byte describing the sign and the base. This 'sign/base' byte is + (0x2B) or - (0x2D) for the sign ored with the base mask bits that can be 0 for base 10 or 0x40 for base 16. It is followed by the strings of digits (as characters) in their natural order (as in the &exml; encoding). For example, 8589934592 (

2^{33}

) is encoded 0x02 0x0A 0x2B 0x38353839393334353932 and xf&zsp;f&zsp;f&zsp;f&zsp;f&zsp;f&zsp;f1 is encoded as 0x02 0x08 0x6b 0x6666666666666631. Note that it is permitted to encode a small integer in any bigger format. Symbols are encoded as the symbol tags (token identifier 8) with the long flag set if the maximum of the length of the Content Dictionary name, and the symbol name or the CD base is greater than or equal to 256 (note that this should never be the case if the rules on symbols and Content Dictionary names are applied), followed by the length of the Content Dictionary name as a byte (if the long flag was not set) or a four byte integer (in network byte order) followed by the length of the symbol name 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 Content Dictionary name, followed by the characters of the symbol name. . The symbol tags [8] and [8+128] are deprecated in &OM;2 since symbols now have an optional role field, but are kept for backwards compatibility. The symbol tag is followed by the length of the Content Dictionary name, the symbol name, and the CD base as a byte (if the long flag was not set) or a four byte integers (in network byte order). These are followed by the characters of the Content Dictionary name, the symbol name, and the CD base. Variables are encoded using the variable tags (token identifiers 5) with the long flag set if the number of bytes (characters) in the variable name is greater than or equal to 256 (this should never happen if the rules on variables are followed). Then, there is the number of characters as a byte (if the long flag was not set) or a four byte integer (in network byte order), followed by the characters of the name of the variable. For example, the variable x is encoded as 0x05 0x01 0x78. Indexed Variables are encoded using the indexed variable tags (token identifiers 10 and 11) as begin and end tags. The long flag set on the begin tag if the number of bytes (characters) in the variable name is greater than or equal to 256 (this should never happen if the rules on variables are followed). The start tag is followed by 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. This is followed by the encoding of an &OM; object and the end tag [11]. Floating-point number are encoded using the floating-point number tags (token identifier 3) followed by eight bytes that are the IEEE 754 representation ieee754_85, most significant bytes first. For example, 0.1 is encoded as 0x03 0x000000000000f03f. Character string are encoded in two ways depending on whether the string contains utf-16 characters or not. If the string contains only 8 bit characters, 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 contains two byte characters, it is encoded as the two byte character string tags (token identifier 7) with the long flag set if the number of characters in the string is greater or equal to 256. Then, there is the number of characters as a byte (if the long flag was not set) or a four byte integer (in network byte order), followed by the characters (utf-16 encoded Unicode). Bytearrays are encoded using the bytearray tags (token identifier 4) with the long flag set if the number of bytes in 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. Derived Objects are encoded using the derived object tags (token identifier 12) with the long flag set if the number of bytes is greater than or equal to 256. Then, there is the number of elements, as a byte (if the long flag was not set) or a four byte integer (in network byte order), followed by the elements of the arrays in their normal order. Applications are encoded using the application tags (token identifier 16). More precisely, the application of

E_{0}

E_{1}

…

E_{n}

is encoded using the application tags (token identifier 16), the sequence of the encodings of

E_{0}

E_{n}

and the end application tags (token identifier 17). Bindings are encoded using the binding tags (token identifier 26). More precisely, the binding by

B

of variables

V_{1}

…

V_{n}

C

is encoded as the binding tags (token identifier 26), followed by the encoding of

B

, followed by the binding variables tags (token identifier 28), followed by the encodings of the variables

V_{1}

…

V_{n}

, followed by the end binding variables tags (token identifier 29), followed by the encoding of

C

, followed by the end binding tags (token identifier 27). Attribution are encoded using the attribution tags (token identifier 18). More precisely, attribution of the object

E

with (

S_{1}

E_{1}

\dots

(

S_{n}

E_{n}

) pairs (where

S_{i}

are the attributes) is encoded as the attributed object tags (token identifier 18), followed by the encoding of the attribute pairs as the attribute pairs tags (token identifier 20), followed by the encoding of each symbol and value, followed by the end attribute pairs tags (token identifier 21), followed by the encoding of

E

, followed by the end attributed object tags (token identifier 19). Error are encoded using the error tags (token identifier 22). More precisely,

S_{0}

applied to

E_{1}

…

E_{n}

is encoded as the error tags (token identifier 22), the encoding of

S_{0}

, the sequence of the encodings of

E_{0}

E_{n}

and the end error tags (token identifier 23). Internal References are encoded using the internal reference tags [30] and [30+128] (the sharing flag cannot be set on this tag, since chains of references are not allowed in the &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). External References are encoded using the external reference tags [31] and [31+128] (the sharing flag cannot be set on this tag, since chains of references are not allowed in the &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.

Sharing <phrase revisionflag="added">in Objects begining with the identifier [24]</phrase> This binary encoding 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

n

coded on one byte (0 to 255). This integer references the

n + 1

-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, 0x48 0x01 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).

Sharing with References (beginning with [24+64]) In the binary encoding specified in the last section (which we keep for compatibility reasons, but deprecate in favor of the more efficient binary encoding specified in this section) only symbols, variables, and short strings could be shared. In this section, we will present a second binary encoding, which shares most of the identifiers with the one in the last one, but handles sharing differently. This encoding is signaled by the shared object tags [88]. The main difference is the interpretation of the sharing flag (bit 7), which can be set on all objects that allow it. Instead of encoding a reference to a previous occurrence of an object of the same type, it indicates whether an object will be referenced later in the encoding. This corresponds to the information, whether an id attribute is set in the &exml; encoding. On the object identifier (where sharing does not make sense), the shared flag signifies the encoding described here ([88]=[24+64]). Otherwise integers, floats, variables, symbols, strings, bytearrays, and constructs are treated exactly as in the binary encoding described in the last section. The binary encoding with references uses the additional reference tags [30] for (short) internal references, [30+128] for long internal references, [30] for (short) external references, [30+128] for long external references. Internal references are used to share sub-objects in the encoded object (see for an example) by referencing their position; external references allow to reference &OM; objects in other documents by an URI. Identifiers [30+64] and [30+64+128] are not used, since they would encode references that are shared themselves. Chains of references are redundant, and decrease both space and time efficiency, therefore they are not allowed in the &OM; binary encoding. References consist of the identifier [30] ([30+128] for long references) followed by a positive integer

n

coded on one byte (4 bytes for long references). This integer references the

n + 1

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 Ox7E Ox01 references the second shared sub-object. Figure shows the binary encoding of the object in figure above.

A binary encoding of the &OM; object from figure <xref linkend="fig_shared_vs_unshared"/>. Hex Meaning Hex Meaning 58begin object tag 05variable tag 10begin application tag 01variable length 05variable tag 61a (variable name) 01variable length 05variable tag 66f (variable name) 01variable length 50begin application tag (shared) 61a (variable name) 05variable tag 11end application tag 01variable length 1Eshort reference 66f (variable name) 00to the first shared object 50begin application tag (shared) 11end application tag 05variable tag 1Eshort reference 01variable length 00to the second shared object 66f (variable name) 11end application tag 19end object tag It is easy to see that in this binary encoding, the size of the encoding is

13 + 7 (d - 1)

bytes, where

d

is the depth of the tree, while a totally unshared encoding is

8 * 2^{d} - 8

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

32 d + 29

bytes, which is more space efficient starting at depth 9. Note that in conversion to binary encoding the identifiers on the objects are not preserved. Morever, even though the &exml; encoding allows references across objects, as in figure ???, the binary encoding does not (the binary encoding has no notion of a multi-object collection, which is implicit by embedding &OM; objects into &exml; documents in the &exml; encoding.). Note that objects need not be fully shared (or shared at all) in the binary encoding with sharing.

Implementation Note 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 [24]. 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

i

-th object of a given type is read, it stands for the

i

-th entry in the corresponding table. It is an encoding error if the

i

-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). 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 [30] [_] is encountered, the array is queried for the value at [_] and analogously for or [30+128] {_}. Note that the application can decide to copy the value or share it among subterms 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 ), and possibly have methods for recovering from cyclic dependency relations (this can be done by standard loop-checking methods). 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.

Example of Binary Encoding As an example of this binary encoding, we can consider the &OM; object whose &exml; encoding is ]]> It is binary encoded as the sequence of bytes given by the following table. Hex Meaning Hex Meaning 18begin object tag 68h .) 10 begin application tag 311 .) 08symbol tag 70p (symbol name begin 06cd length 6c l . 05 name length 75 u . 61 a (cd name begin 73 s .) 72 r . 05 variable tag 69 i . 01 name length 74 t . 78 x (name) 68 h . 05 variable tag 31 1 .) 01 name length 74 t (symbol name begin 79 y (variable name) 69 i . 11 end application tag 6d m . 10 begin application tag 65 e . 48 symbol tag (with share bit on) 73 s .) 01reference to second symbol seen (arith1:plus) 10 begin application tag 45 variable tag (with share bit on) 08 symbol tag 00 reference to first variable seen (x) 06 cd length 05 variable tag 04 name length 01 name length 61 a (cd name begin 7a z (variable name) 72 r . 11 end application tag 69 i . 11 end application tag 74 t . 19 end object tag

Relation to the &OM;1 binary encoding The &OM;2 binary encoding significantly extends the &OM;1 binary encoding to accomodate the new features and in particular sharing of sub-objects. The tags and structure of the &OM;1 binary encoding are still present in the current &OM; binary encoding, so that binary encoded &OM;1 objects are still valid in the &OM;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). As the binary encoding is geared towards compactness, &OM; objects should be maximally internally shared (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 allow to represent it more compactly.

Summary The key points of this chapter are: The &exml; encoding for &OM; objects uses most common character sets. The &exml; encoding is readable, writable and can be embedded in most documents and transport protocols. 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.

Content Dictionaries In this chapter we give a brief overview of Content Dictionaries before explicitly stating their functionality and encoding.

Introduction 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. For example if application

A

is talking to application

B

, and sends, say, an equation involving multiplication of matrices, then

A

and

B

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. A Content Dictionary holds the meanings of (various) mathematical words. These words are &OM; basic objects referred to as symbols in . With a set of symbol definitions (perhaps from several Content Dictionaries),

A

and

B

can now talk in a common language. It is important to stress that it is not Content Dictionaries themselves which are being transmitted, but some mathematics 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 understand (i.e., can cope with to some degree). Rephrase slightly 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). The primary use of Content Dictionaries is thought to be for designers of Phrasebooks,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. 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. More motivation on design of CDs 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 of the Content Dictionaries will be written by ordinary 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. The key points from this section are: Content Dictionaries should be readable and precise to help Phrasebook designers, Content Dictionaries should be readily write-able to encourage widespread use, It ought to be possible for a machine to understand a Content Dictionary to some degree.

Abstract Content Dictionaries In this section we define the overallabstract structure of Content Dictionaries. New paragraph to reflect recent changes Other than Content Dictionary comments (which have no real semantics), Content Dictionaries have been designed to hold two types of information: that which is pertinent to the whole Content Dictionary, and that which is restricted to a particular symbol definition. Specific information pertaining to the symbols like the signature and the defining mathematical properties is conveyed in additional files associated to Content Dictionaries. Information that is pertinent to the whole Content Dictionary includes: The name of the Content Dictionary. A description of the Content Dictionary. A date when the Content Dictionary is next planned to be reviewed. A date on which the Content Dictionary was last edited. The current version and revision numbers of the Content Dictionary. The status of the Content Dictionary. An optional URL for this Content Dictionary. An optional list of Content Dictionaries on which this Content Dictionary depends. That is, those named in Examples and FMP in this Content Dictionary. An optional comment, possibly containing the author's name. Information that is restricted to a particular symbol includes: The name of the symbol. A description of this symbol. An optional comment. Optional properties that this symbol should obey. Optional examples of the use of this symbol. removed refs to old changes new paragraph Defmp added Rephrase slightly A Content Dictionary consists of the following mandatory pieces of information: A name corresponding to the rules described in . A description of the Content Dictionary. A revision date, 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. A review date, a date until which the content dictionary is guarenteed to remain unchanged. A version number which consists of a major and minor part (see ). A status, as described in . A CD base which is a unique identifier for the Content Dictionary, and may or may not refer to an actual location from which it can be retrieved. A series of symbol definitions as described below. A symbol definition consists of the following pieces of information: A mandatory name corresponding to the rules described in . A mandatory description of the symbol, which can be as formal or informal as the author likes. An optional role as described in . Zero or more commented mathematical properties which are mathematical properties of the symbol expressed in a mechanism other than &OM;. Zero or more formal mathematical properties 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. Zero or more examples which are intended to demonstrate the use of the symbol within an &OM; object. As mentioned earlier, certain kinds of data pertaining to symbols may be conveyed in files other than a Content Dictionary. In particular, information on signatures according to a type system may be described in Signature Files whose format is given in . Other information such as presentation forms, extra defining mathematical properties may be associated with Content Dictionaries using files whose format is not specified by this standard. It is expected that a common method of defining the presentation for &OM; symbols is via xsl XSL_99 stylesheets giving transformations to MathML. 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 varients to be associated with Content Dictionaries without the Dictionaries themselves being changed. A model for signatures is given in . MathML 2 Content Dictionaries may be grouped into CD Groups. These groups allow applications to easily refer to collections of Content Dictionaries. One particular CDGroup of interest is the MathML CDGroup. This group expresses the collection of the core Content Dictionaries that is designed to have the same semantic scope as the content elements of MathML 2 MathML_2000. &OM; objects built from symbols that come from Content Dictionaries in this CDGroup may be expected to be eaily transformed between &OM; and MathML encodings. The detailed structure of a CDGroup is described in below.

Content Dictionary Status The status of a Content Dictionary can be either official: approved by the &OM; Society according to the procedure outlined in ; experimental: under development and thus liable to change; private: used by a private group of &OM; users; obsolete: an obsolete Content Dictionary kept only for archival purposes.

Content Dictionary Version Numbers 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 experimental, the version number should be a positive integer. Unless a CD has status experimental, 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 experimental. Should this be required then a new CD with a different name should be produced so as not to invalidate existing objects. When the major version number is increased, the revision number is normally reset to zero. As detailed in chapter , &OM; compliant applications state which versions of which CDs they support.

The <phrase revisionflag="deleted">&exml;</phrase><phrase revisionflag="added">Reference</phrase> Encoding for Content Dictionaries The reference encoding of Content Dictionaries are as &exml; documents. A valid Content Dictionary document should be valid according to the DTD given in , adhere to the extra conditions on the content of the elements given in . conform to the Relax NG Schema for Content Dictionaries given in . An example of a complete Content Dictionary is given in Appendix , which is the Meta Content Dictionary for describing Content Dictionaries themselves. A more typical Content Dictionary is given in Appendix , the arith1 Content Dictionary for basic arithmetic functions.

The RelaxNG Schema for Content Dictionaries &cdrnc;

The DTD Specification of Content Dictionaries

DTD Specification of Content Dictionaries ]]> The &exml; DTD for Content Dictionaries is given in . The allowed elements are further described in the following section.

Further <phrase revisionflag="deleted">Requirements of an &OM; Content Dictionary</phrase><phrase revisionflag="added">Description of the CD Schema</phrase> The notion of being a valid Content Dictionary is stronger than merely being successfully parsed by the DTD. This is because the content of the elements, referred to in as PCDATA and CDATA, must actually make sense to, say, a Phrasebook designer. In this section we define exactly the format of the elements used in Content Dictionaries. We now describe the elements used in the above schema in terms of the abstract description of CDs in . Unless stated otherwise the information is encoded as the content of the element. now we have this numbering mechanism, should it be documented? CDNameThe text occurring in the CDName element corresponds to the name of the Content Dictionary. Description The text occurring in the Description 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. CDReviewDateThe text occurring in the CDReviewDate element corresponds to the earliest possible review date of the Content Dictionary. The date formats should be ISO-compliant in the form YYYY-MM-DD, e.g. 1953-09-26. CDDateThe text occurring in the CDDate element corresponds to the revision date of this version of the Content Dictionary. The date formats should be ISO-compliant in the form YYYY-MM-DD, e.g. 1953-09-26. CDVersion new paragraph Now just an integre The major version number of the CD. The text occurring in the CDVersion element corresponds to the version number of the current version of a Content Dictionary. It should be a non negative integer. In CDs that do not have status experimental, CD version numbering should adhere to the following. The version number should be a positive integer. No changes can 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 this 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 increas should be made to the revision number, as described below. A change such as removing a symbol should not be made, instead a new CD, with a different name should be produced, so as not to invalidate existing objects. As detailed in chapter , &OM; compliant applications state which versions of which CDs they support. Experimental CDs may expect to have changes such as adding or removing symbols as they are developed, without requiring the name of the CD to be changed. CDRevision New field, formally `.y' of version number The text occurring in the CDRevision element corresponds to the revision, or `minor version number' of the current version of a Content Dictionary. It should be a non negative integer. Minor changes to a CD that do not warrant the release of a CD with an increased version number should be marked by increasing the revision number specified in this field. When the Cd Version number is increased, the Revision number is normally reset to zero. The minor version number of the CD. CDStatusThe text occurring in the CDStatus element corresponds to the status of the Content Dictionary. , and can be either official (approved by the &OM; Society according to the procedure outlined in ), experimental (currently being tested), private (used by a private group of &OM; users) or obsolete (an obsolete Content Dictionary kept only for archival purposes). CDCDBASEThe CD base of the CD. CDURLThe text occurring in the CDURL 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 iso9660. CDUses new wording The content of this element should be a series of CDName elements, each naming a Content Dictionary used in the Example and FMPs of the current Content Dictionary. This element is optional and deprecated since the information can easily be extracted automatically. CDCommentThe 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. Due to lack of inspiration, I added only these few lines CDDefinitionThe element which contains the definition of an individual symbol. NameThe text occurring in the Name element corresponds to the name of a symbol. , and is specified as in . Example new description The text occurring in the Example 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 OMOBJ elements. Note that Examples must be with respect to some symbol and cannot be loose in the Content Dictionary. CMP The text occurring in the CMP element corresponds to a property of the symbol. An application which says it understands a Content Dictionary symbol need not understand a commented property of the symbol. A Commented Mathematical Property. FMP The content of the FMP element also corresponds to a propertyIt corresponds to a theorem of a theory in some formal system. of the symbol, however the content of this element must be a valid &OM; object in the &exml; encoding. An application which says it understands a Content Dictionary symbol need not understand a formal property of the symbol. A Formal Mathematical Property.

Additional Information Introduction to splitting-up in files Rephrase slightly Content Dictionaries contain just one part of the information that can be associated to a symbol in order to stepwise define its meaning and its functionality. &OM; Signature filesdictionaries, CDGroups, and possibly filescollections of extra mathematical properties, are used to convey the different aspects that as a whole make up a mathematical definition.

Signature <phrase revisionflag="deleted">Files</phrase><phrase revisionflag="added">Dictionaries</phrase> Introduced Signature Files. Early drafts of the &OM; standard specified that Content Dictionaries had a Signature element in which the signature of the symbol was defined. The disadvantage of this approach is that the signature would need to reference a specific type system. Signature Files allow for more generality. &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; attribution constructor. A Small Type System, called STS, has been designed to give semi-formal signatures to &OM; symbols and is documented in OM_D132c. The signature file given in is based on this formalism. Using the same mechanism, OMD132b shows how pure type systems can also be employed to assign types to &OM; symbols.

The DTD Specification of Signature Files Signature Files are &exml; documents, hence a valid Signature File should be valid according to the dtd given in , adhere to the extra conditions on the content of the elements given in . Signature files have a header which specifies the Content Dictionary and determines the type system being used, and the Content Dictionary which contains the symbols for which the signatures are being given. Each signature takes the form of an &exml; encoded &OM; object.

DTD Specification of Signature Files %omobjectdtd; ]]>

<phrase revisionflag="deleted">Further Requirements </phrase> <phrase revisionflag="added"> Abstract Specification</phrase> of a Signature File Added PCDATA for Additional Files Signature files have a header which specifies the type system being used, and the Content Dictionary which contains the symbols for which the signatures are being given. Each signature takes the form of an &OM; object in an appropriate encoding. The notion of being a valid Signature File is stronger than merely being successfully parsed by the dtd in . In this section we define exactly the format of the elements used in Signature Files. Several of the requirements are the same as those on elements of Contents Dictionaries. CDSignaturesThe outermost element of the Signature File is characterized by two required attributes that identify the type system and the Content Dictionary whose signatures are defined. The value of the &exml; attribute type is the name of the Content Dictionary or of the CDGroup (cfg. ) that represents the type system. The value of the &exml; attribute cd is the name of the Content Dictionary whose symbols are assigned signatures in this Signature File. Both values are of the form specified in . CDSCommentSee CDComment in . CDSreviewDateThe text occurring in the CDSReviewDate element corresponds to the earliest possible revision date of the Signature File. The date formats should be ISO-compliant in the form YYYY-MM-DD, e.g. 2000-02-29. CDSStatusThe text occurring in the CDSStatus element corresponds to the status of the Signature File, and can be either official (approved by the &OM; Society according to the procedure outlined in ), experimental (currently being tested), private (used by a private group of &OM; users) or obsolete (an obsolete Signature File kept only for archival purposes). Signature This notion might be too strict, it also need CDUses possibly The content of the Signature element has to be a valid &OM; object in &exml; encoding as specified in . Additionally, the object must represent a valid type in the type system identified by the &exml; attribute type of the CDSignature element. See for examples. A type definition: the name of the Content Dictionary or of the CDGroup (cfg. ) that represents the type system being used. A CD name: the name of the CD for which signatures are being defined. A review date as defined in . A status: as defined in . A series of signatures which are &OM; objects in some encoding. The objects must represent types as defined by the type definition.

A RelaxNG Schema for a Signature File The following is a reference encoding of a signature dictionary, designed to be used with Content Dictionaries in the &exml; encoding. &sigrnc;

Examples arith1.sts is not valid wrt DTD An example of a signature file for the type system STS and the arith1 Content Dictionary is given in . Each signature entry is similar to the following one for the &OM; symbol <OMS cd="arith1" name="plus"/>: ]]>

CDGroups All new, partly taken from SB paper Rephrase slightly The CD Group mechanism is a convenience mechanism for identifying collections of CDs. 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. Note that CD Groups do not affect the &OM; objects themselves. Symbols in an object always refer to content dictionaries, not groups. Does this go to compliancy? For an application to declare that it understands CDGroup G is exactly equivalent to, and interchangable with, the declaration that it understands Content Dictionaries

x_{1}

x_{2}

, …

x_{n}

, where

x_{1}

, …

x_{n}

are the members of CDGroup G.

The DTD Specification of CDGroups CDGroups are &exml; documents, hence a valid CDGroup should be valid according to the DTD given in , adhere to the extra conditions on the content of the elements given in . Apart from some header information such as CDGroupName and CDGroup version, a CDGroup is simply an unordered list of CDs, identified by name and optionally version number and URL.

<phrase revisionflag="deleted">DTD</phrase><phrase revisionflag="added">Relax NG</phrase>Specification of CDGroups &cdgrouprnc;

Further Requirements of a CDGroup Added PCDATA for CDGroup The notion of being a valid CDGroup implies that the following requirements on the content of the elements described by the DTD in are also met. CDGroup The &exml; element CDGroup is the outermost element in a CDGroup document. CDGroupName For consistency, CDGName would be better The text occurring in the CDGroupName element corresponds to the name of the CDGroup. For the syntactical requirements, see CDName in . CDGroupVersion CDGroupRevision The text occurring in these elements contains the major and minor version numbers of the CDGroup. CDGroupURL The text occurring in the CDGroupURL element identifies the location of the CDGroup file, not necessarily of the member Content Dictionaries. For the syntactical requirements, see CDURL in . CDGroupDescription The text occurring in the CDGroupDescription element describes the mathematical area of the CDGroup. CDGroupMember The &exml; element CDGroupMember encloses the data identifying each member of the CDGroup. CDNameThe text occurring in the CDName element corresponds to the name of a Content Dictionary in the CDGroup. For the syntactical requirements, see CDName in . CDVersionThe text occurring in the CDVersion element identifies which version of the Content Dictionary isto 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 CDVersion in . CDURL Or the official CD repository? The text occurring in the CDURL 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 CDGroupURL is assumed. For the syntactical requirements, see CDURL in . CDCommentSee CDComment in . Delete subsec: Note on Symbols, CDs and CDGroups Delete examples (MathML CDGroup is in appendix, core CDGroup no longer exists This section to be added Delete subsec: DefMP Files and XSL

Content Dictionaries Reviewing Process Rephrase slightly 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 CDStatus) and/or the version number (see CDVersion ) of a Content Dictionary may change as a result of this review process.

&OM; Compliance New chapter, after discussions at Esprit &OM; meeting in Bath Applications that meet the requirements specified in this chapter may label themselves as &OM; compliant. &OM; compliancy is defined so as to maximize the potential for interoperability amongst &OM; applications.

Encoding This standard defines two reference encodings for &OM;, the binary encoding and &exml; encoding, defined in . As a minimum, an &OM; compliant application, which accepts or generates &OM; objects, must be capable of doing so using the &exml; encoding. The ability to use other encodings is optional.

Content Dictionaries An &OM; compliant application must be able to support the error Content Dictionary defined in . A compliant application must declare the names and version numbers of the Content Dictionaries that it supports. Equivalently it may declare the Content Dictionary Group (or groups) and major version number (not revision number), rather than listing individual Content Dictionaries. Applications that support all Content Dictionaries (e.g. renderers) should refer to the implicit CD Group all. If a compliant application supports a Content Dictionary then it must explicitly declare any symbols in the Content Dictionaries that are not supported. Phrasebooks are encouraged to support every symbol in the Content Dictionaries. Symbols which are not listed as unsupported are supported by the application. The meaning of supported will depend on the application domain. For example an &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 phrasebooks for supported Content Dictionaries will be constructed such that propertes of the symbol expressed in the Content Dictionary are respected as far as possible for the given application domain. However &OM; compliance does not imply any guarantee by the &OM; Society on the accuracy of these representations. Content Dictionaries available from the official &OM; repository at www.openmath.org need only be referenced by name, other Content Dictionaries should be referenced by the URL declared in the CDURL field of the Dictionary. This URL may be used to retrieve the Content Dictionary. using the CDBASE and the CDName. When receiving an &OM; symbol, e.g.

s

, that is not supported from a supported Content Dictionary, a compliant application will act as if it had received the &OM; object

error (Unhandled_Symbol, s)

where Unhandled_Symbol is the symbol from the error Content Dictionary. Similarly if it receives a symbol, e.g.

s

, from an unsupported Content Dictionary, it will act as if it had received the &OM; object

error (Unsupported_CD, s)

Finally if the compliant application receives a symbol from a supported Content Dictionary but with an unknown name, then this must either be an incorrect object, or possibly the object has been built using a later version of the Content Dictionary. In either case, the application will act as if it had received the &OM; object

error (Unexpected_Symbol, s)

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

Conclusion The goal of this document is to define the &OM; standard. The things are addressed by the &OM; standard are: Informal and formal definition of the &OM; objects. Informal and formal definition of the notion of Content Dictionaries. To do this, &OM; objects are precisely defined and two encodings are described to represent these objects using xml and binary code. Furthermore, the Document Type Definition for validating Content Dictionaries and &OM; objects is given. CD Files

The <filename>meta</filename> Content Dictionary meta This is a content dictionary to represent content dictionaries, so that they may be passed between &OM; compliant application in a similar way to mathematical objects. It is acknowledged that this is not the only way to do this, but it seems a natural way. This can be viewed as updating the previous Meta-CD. The information written here is taken from "The &OM; Standard". This document is a slightly stronger statement than "the following symbols are defined as in the DTD at http://www.nag.co.uk/projects/OpenMath/omstd/dtds/cd.dtd", since the DTD often only says that the information inside the elements is PCDATA without saying what this actually corresponds to. However this is the only way this document is better than the DTD, and thus this is the only extra information we give here. Author: N. Howgrave-Graham 1998-10-01 experimental http://www.nag.co.uk/projects/OpenMath/omstd/cds/meta.ocd This is how one uses comments. This whole document must be valid &exml; which means that we cannot have sub-elements inside elements where we are expecting PCDATA. For this reason it is suggested that one use the unicode characters when clashes occur. For example < and > for less than and more than. CD The DTD fully specifies the use of the CD tag CDDescription The DTD fully specifies the use of the CDDescription tag For those that do not have access to the DTD, the tagged entries are the following (in no particular order): <CD> <CDName> </CDName> <Description> </Description> <CDReviewDate> </CDReviewDate> <CDStatus> </CDStatus> <CDURL>? </CDURL> <CDUses>? <CDUses> <CDDefinition>* <Name> </Name> <Description> </Description> <Signature>? </Signature> <Example>* </Example> <FMP>* </FMP> <CMP>* </CMP> <Presentation>? </Presentation> </CDDefinition> where an asterisk (?) denotes it can repeated 0 or 1 times, and a star (*) denotes 0 or more times. CDName A tag which contains PCDATA corresponding to the name of the CD. CDURL An optional tag which contains PCDATA corresponding to the URL where the CD is stored. Example A tag which contains PCDATA to give an example of the enclosing symbol definition. CDReviewDate A tag which contains PCDATA to give an expiry date of the CD. It should be in the form of ISO-8601, i.e. YYYY-MM-DD CDStatus A tag which contains PCDATA to give information on the status of the CD. This can be either official (approved by the &OM; steering committee), experimental (currently being tested), private (used by a private group of &OM; users) or obsolete (an obsolete CD kept only for archival purposes). CDUses A tag which contains zero or more CDNames which correspond to the CD's that this CD depends on. This makes an inheritance structure for CD's. If the CD is dependent on any other CD's they must be present here. CDTypeUses A tag which contains zero or more CDNames which correspond to the CD's that hold type information that this CD depends on. This makes an inheritance type structure for CD's. If the CD types are dependent on any other CD's they must be present here. For application that do not respect types, this symbol can be ignored. Description A tag which contains PCDATA corresponding to the description of either the CD or the symbol (depending on which is the enclosing element). Name A tag which contains PCDATA corresponding to the name of the symbol being defined. Signature An optional tag which contains PCDATA corresponding to the type of the symbol being defined. This type information will be an &OM; type object as defined in chapter 5 of "First Draft of the &OM; Standard". Presentation An optional tag (which may be repeated many times) which contains PCDATA corresponding to a way of presenting the symbol being defined. CMP An optional tag (which may be repeated many times) which contains PCDATA corresponding to a property of the symbol being defined. FMP An optional tag (which may be repeated many times) which contains PCDATA corresponding to a property of the symbol being defined. This property must be a valid &OM; object. ]]>

The <filename>arith1</filename> Content Dictionary File arith1 http://www.openmath.org/cd/arith1.ocd 2003-04-01 official 2001-03-12 2 0 This CD defines symbols for common arithmetic functions. lcm The symbol to represent the n-ary function to return the least common multiple of its arguments. lcm(a,b) = a*b/gcd(a,b) for all integers a,b | There does not exist a c>0 such that c/a is an Integer and c/b is an Integer and lcm(a,b) > c. 0 gcd The symbol to represent the n-ary function to return the gcd (greatest common divisor) of its arguments. for all integers a,b | There does not exist a c such that a/c is an Integer and b/c is an Integer and c > gcd(a,b). Note that this implies that gcd(a,b) > 0 gcd(6,9) = 3 6 9 3 plus The symbol representing an n-ary commutative function plus. for all a,b | a + b = b + a unary_minus This symbol denotes unary minus, i.e. the additive inverse. for all a | a + (-a) = 0 minus The symbol representing a binary minus function. This is equivalent to adding the additive inverse. for all a,b | a - b = a + (-b) times The symbol representing an n-ary multiplication function. 1 2 3 4 5 6 7 8 19 20 43 50 for all a,b | a * 0 = 0 and a * b = a * (b - 1) + a for all a,b,c | a*(b+c) = a*b + a*c divide This symbol represents a (binary) division function denoting the first argument right-divided by the second, i.e. divide(a,b)=a*inverse(b). It is the inverse of the multiplication function defined by the symbol times in this CD. whenever not(a=0) then a/a = 1 power This symbol represents a power function. The first argument is raised to the power of the second argument. When the second argument is not an integer, powering is defined in terms of exponentials and logarithms for the complex and real numbers. This operator can represent general powering. x\in C implies x^a = exp(a ln x) if n is an integer then x^0 = 1, x^n = x * x^(n-1) 0 1 1 2 3 4 3 37 54 81 118 abs A unary operator which represents the absolute value of its argument. The argument should be numerically valued. In the complex case this is often referred to as the modulus. for all x,y | abs(x) + abs(y) >= abs(x+y) root A binary operator which represents its first argument "lowered" to its n'th root where n is the second argument. This is the inverse of the operation represented by the power symbol defined in this CD. Care should be taken as to the precise meaning of this operator, in particular which root is represented, however it is here to represent the general notion of taking n'th roots. As inferred by the signature relevant to this symbol, the function represented by this symbol is the single valued function, the specific root returned is the one indicated by the first CMP. Note also that the converse of the second CMP is not valid in general. x\in C implies root(x,n) = exp(ln(x)/n) for all a,n | power(root(a,n),n) = a (if the root exists!) sum An operator taking two arguments, the first being the range of summation, e.g. an integral interval, the second being the function to be summed. Note that the sum may be over an infinite interval. This represents the summation of the reciprocals of all the integers between 1 and 10 inclusive. 1 10 1 product An operator taking two arguments, the first being the range of multiplication e.g. an integral interval, the second being the function to be multiplied. Note that the product may be over an infinite interval. This represents the statement that the factorial of n is equal to the product of all the integers between 1 and n inclusive. 1 ]]>

The <filename>arith1</filename> STS Signature File ADD arith1 signature file Date: 1999-11-26 Author: David Carlisle ]]>

The <filename>MathML</filename> CDGroup ADD MathML CDGroup mathml 2 0 http://www.openmath.org/cdfiles/cdgroups/mathml.ocd MathML compatibility CD Group This is the first version of the Core CD group. It was created by D Carlisle based on MathML CD Group. Algebra alg1 http://www.openmath.org/cd/alg1.ocd Arithmetic arith1 http://www.openmath.org/cd/arith1.ocd Constructor for Floating Point Numbers bigfloat1 http://www.openmath.org/cd/bigfloat1.ocd Calculus calculus1 http://www.openmath.org/cd/calculus1.ocd Operations on and constructors for complex numbers complex1 http://www.openmath.org/cd/complex1.ocd Functions on functions fns1 http://www.openmath.org/cd/fns1.ocd Integer arithmetic integer1 http://www.openmath.org/cd/integer1.ocd Intervals interval1 http://www.openmath.org/cd/interval1.ocd Linear Algebra - vector & matrix constructors, those symbols which are independant of orientation, but in MathML linalg1 http://www.openmath.org/cd/linalg1.ocd Linear Algebra - vector & matrix constructors, those symbols which are dependant of orientation, and in MathML linalg2 http://www.openmath.org/cd/linalg2.ocd Limits of unary functions limit1 http://www.openmath.org/cd/limit1.ocd List constructors list1 http://www.openmath.org/cd/list1.ocd Basic logical operators logic1 http://www.openmath.org/cd/logic1.ocd MathML Numerical Types mathmltypes http://www.openmath.org/cd/mathmltypes.ocd Minima and maxima minmax1 http://www.openmath.org/cd/minmax1.ocd Multset-theoretic operators and constructors multiset1 http://www.openmath.org/cd/multiset1.ocd Symbols for creating numbers, including some defined constants (which can be seen as nullary constructors) nums1 http://www.openmath.org/cd/nums1.ocd Symbols for creating piecewise definitions piece1 http://www.openmath.org/cd/piece1.ocd The basic quantifiers forall and exists. quant1 http://www.openmath.org/cd/quant1.ocd Common arithmetic relations relation1 http://www.openmath.org/cd/relation1.ocd Number sets setname1 http://www.openmath.org/cd/setname1.ocd Rounding rounding1 http://www.openmath.org/cd/rounding1.ocd Set-theoretic operators and constructors set1 http://www.openmath.org/cd/set1.ocd Basic data orientated statistical operators s_data1 http://www.openmath.org/cd/s_data1.ocd Basic random variable orientated statistical operators s_dist1 http://www.openmath.org/cd/s_dist1.ocd Basic transcendental functions transc1 http://www.openmath.org/cd/transc1.ocd Vector calculus functions veccalc1 http://www.openmath.org/cd/veccalc1.ocd Alternative encoding symbols for compatibility with the MathML Semantic mapping constructs. altenc http://www.openmath.org/cd/altenc.ocd ]]>

The <filename>error</filename> Content Dictionary error http://www.openmath.org/cd/error.ocd 2003-04-01 official 2001-03-12 2 0 arith1 specfun1 unhandled_symbol This symbol represents the error which is raised when an application reads a symbol which is present in the mentioned content dictionary, but which it has not implemented. When receiving such a symbol, the application should act as if it had received the &OM; error object constructed from unhandled_symbol and the unhandled symbol as in the example below. The application does not implement the Complex numbers: unexpected_symbol This symbol represents the error which is raised when an application reads a symbol which is not present in the mentioned content dictionary. When receiving such a symbol, the application should act as if it had received the &OM; error object constructed from unexpected_symbol and the unexpected symbol as in the example below. The application received a mistyped symbol unsupported_CD This symbol represents the error which is raised when an application reads a symbol where the mentioned content dictionary is not present. When receiving such a symbol, the application should act as if it had received the &OM; error object constructed from unsupported_CD and the symbol from the unsupported Content Dictionary as in the example below. The application does not know about the CD specfun1 ]]>

&OM; Schema in Relax NG XML Syntax (Non-Normative) This is the Relax NG Schema described in expressed according to the Relax NG XML Syntax. &omrng; Restricting the &OM; Schema (Non-Normative) Relax NG allows one to state constraints such as if the cd attribute of OMS is arith1 then the name attribute must be one of lcm, gcd, plus etc. Thus it is easy to use a stylesheet to generate for any given CD, a Relax NG schema that expresses the constraint that an OMS naming that CD must only use symbols defined in the specified dictionary. Similarly it is possible to use the role information contained in the CD to restrict which symbols can be the first child of an OMBIND or the odd-numbered children of an OMATP. 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 OMS attributes by explicit lists of allowed CD names, and for each CD Name, a list of allowed symbol names. For example, a CD-specific Relax NG Schema for the arith1 CD shown in would look like: arith1 lcm gcd plus unary_minus minus times divide power abs root sum product ]]> or, using the Relax NG compact syntax: 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" } To build a schema that allows only symbols from arith1 we just need to include the &OM; schema described in , override the attribute declarations for OMS, and then include the schema for arith1. For example: ]]> or, in the compact syntax: include "openmath.rnc" { attlist.OMS = cd.attlist.OMS} include "arith1.rnc" Using this approach it is possible to include as many files as required. &OM; Schema in XSD Syntax (Non-Normative) This is an XSD Schema generated from the Relax NG Schema described in . &omxsd; &OM; DTD (Non-Normative) This is a DTD generated from the Relax NG Schema described in . Note that we cannot express the fact that the OMFOREIGN element can contain any well-formed XML, so we have simply restricted it to contain any XML defined in the DTD. &omdtd; Changes between &OM; 1.1 and &OM; 2 (Non-Normative) 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 compatibile, in other words all existing &OM; objects and Content Dictionaries are still valid in &OM; 2. On the other hand an existing &OM; 1.1 application may not be able to process &OM; 2 objects.

Changes to the Formal Definition of Objects Additional features of abstract objects have been introduced: &OM; symbols have an optional rôle qualifier which restricts the place where they may occur within compound objects. 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. In addition to their name and cd properties, symbols now have an optional cdbase 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. &OM; variables can be indexed, in which case they carry information about their enumerator. Since &OM; only allows variables and not objects to be bound, it was not possible to produce indexed variables by defining an appropriate symbol in a CD. Also, although it would be possible to produce an indexed variable using the new semantic-attribute role, it was felt that attributes describe or modify an object, whereas in this case we were constructing an atomic object. An &OM; object may be attributed with a non-&OM; object using the new foreignconstructor. 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. the new role property can be used to indicate that a symbol is an attribution, in which case an application may ignore or remove it, or a semantic attribution in which case removing it is no longer guarenteed to produce an equivalent object. restrictions on the names of symbols, variables and content dictionaries have been relaxed to be compatible with XML and to be less Anglo-Saxon.

Changes to the encodings The &OM; version 2 standard still mandantes 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. both encodings have been updated to support the changes to the model of abstract objects described above. encodings support internal and external sharing of objects 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. an optional attribute defining the version of the encoding can be specified for the encoded object

Changes to Content Dictionaries 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. The CDUses 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. A CD may now, optionally, define its cdbase. A CD symbol definition may now, optionally, define its role.

Bibliography IEEE Std 1003.1-2001 (Open Group Technical Standard, Issue 6), Standard for Information Technology-Portable Operating System Interface (POSIX) 2001 IETF RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax August 1998 World Wide Web Consortium XSD Schema Parts 1 & 2 May 2001 OASIS Committee Specification RELAX NG Compact Syntax November 2002 OASIS Committee Specification RELAX NG Specification December 2001 B. W. Char K. O. Geddes G. H. Gonnet S. M. Watt Maple User's Guide 1985 WATCOM Publications Limited 4th http://www.maplesoft.com/home.html M. A. A. van Leeuwen A.M. Cohen B. Lisser LiE: A Package for Lie Group Computations CAN, Amsterdam 1992 http://www.can.nl/SystemsOverview/Special/GroupTheory/LiE/ The MuPAD Group (Benno Fuchssteiner et al.) MuPAD User's Manual - MuPAD Version 1.2.2 John Wiley and sons, Chichester, New York first 1996 march Wiley: 0-471-96716-5, Teubner: 3-519-02114-5 http://www.mupad.de MuPAD, Help Pages, Language Structure, Parallelism R. L. Constable S. F. Allen H. M. Bromley W. R. Cleaveland J. F. Cremer R. W. Harper D. J. Howe T. B. Knoblock N. P. Mendler P. Panangaden J. T. Sasaki S. F. Smith Implementing Mathematics with the Nuprl Proof Development System Prentice Hall 1986 http://simon.cs.cornell.edu/Info/Projects/NuPrl/nuprl.html Kent, Gordon Internet Publishing With Acrobat 1996 Adobe Press Adobe Systems Incorporated Portable Document Format Reference Manual 1996 Adobe Systems Incorporated Knuth, Donald E. The TeXbook 1992 Addison-Wesley, Reading, Massachusetts The Ppml Manual ftp://babar.inria.fr/pub/croap/Docs/ppml.ps The Coq Proof Assistant: The standard library Projet Coq version 6.1 http://www.ens-lyon.fr/LIP/groupes/coq Knuth, Donald E. MetaFont 1986 Addison-Wesley, Reading, Massachusetts Lamport, Leslie LaTeX: A Document Preparation System, (2nd ed.) 1994 Addison-Wesley, Reading, Massachusetts Spivak, M. D. The Joy of TeX — A Gourmet Guide to Typesetting with the AmSTeX macro package 1986 American Mathematical Society, Providence, Rhode Island A. Geist A. Beguelin J. Dongarra W. Jiang R. Manchek V. Sunderam PVM: Parallel Virtual Machine: A Users' Guide and Tutorial for Networked Parallel Computing MIT Press, Scientific and Engineering Computation 1994 Janusz Kowalik J. Abbott Univariate factorization over the integers 1998 preprint CoCoA, a system for doing Computations in Commutative Algebra A. Capani G. Niesi L. Robbiano 1995 ftp://cocoa.dima.unige.it A. Giovini G. Niesi CoCoA: A user-friendly system for commutative algebra 429 Lecture Bibliomiscs in Computer Science 20–29 Design and Implementation of Symbolic Computation Systems – International Symposium DISCO'90 1990 Springer Verlag

Berlin

Paul Dreyfuss CORBA: THEORY AND PRACTICE View Source Magazine http://developer.netscape.com/news/viewsource/ Visigenic Distributed Object Computing in the Internet Age White Paper http://www.visigenic.com/pdf/visibrok.pdf Yael Li-Ron Communicator 4.0 vs. Internet Explorer 4.0: And the Winner Is ... PC World 1997 December http://www.pcworld.com/software/internet_www/articles/dec97/1512p206.html P. Chew R. L. Constable K. Pingali S. Vavasis R. Zippel Collaborative Mathematics Environments Project Summary M.J.C. Gordon T.F. Melham Introduction to HOL: A theorem proving environment for higher order logic Cambridge University Press 1993 John Harrison Pure Mathematics in a Mechanized Logic Proceedings of the Finnish Artificial Intelligence Society Symposium: Logic, Mathematics and the Computer Christoffer Gefwert and Pekka Orponen and Juoko Seppänen Finnish Artificial Intelligence Society Suomen Tekoälyseuran julkaisuja 14 1996 153–169 John Robert Harrison Theorem Proving with the Real Numbers University of Cambridge Computer Laboratory

New Museums Site, Pembroke Street, Cambridge, CB2 3QG, UK

1996 408 Author's PhD thesis http://www.cl.cam.ac.uk/users/jrh/papers/thesis.html J. Harrison L. Théry Extending the HOL Theorem Prover with a Computer Algebra System to Reason About the Reals J. J. Joyce and C.-J. H. Seger 780 Lecture Bibliomiscs in Computer Science 174-184 Higher Order Logic Theorem Proving and its Applications: 6th International Workshop, HUG'93 1993 Springer-Verlag

Vancouver, B.C.

August 11-13 J. Harrison L. Théry Reasoning About the Reals: the marriage of HOL and Maple A. Voronkov 698 Lecture Bibliomiscs in Artificial Intelligence 351-353 Logic Programming and Automated Reasoning: 4th International Conrerence 1993 Springer-Verlag

St. Petersburg

C. Ballarin K. Homann J. Calmet Theorems and Algorithms: An Interface between Isabelle and Maple. A.H.M. Levelt 150-157 Proceedings of International Symposium on Symbolic and Algebraic Computation (ISSAC'95) 1995 ACM Press Jacques Calmet Karsten Homann Classification of Communication and Cooperation Mechanisms for Logical and Symbolic Computation Systems F. Baader and K.U. Schulz Applied Logic Proceedings of First International Workshop "Frontiers of Combining Systems" (FroCoS'96) 1996 Kluwer S. Buswell S. Dalmas J. Davenport N. Howgrave-Graham Emerging Technologies &OM; WP 1.2 Deliverable 1998 John A. Abbott André van Leeuwen A. Strotmann &OM;: Communicating Mathematical Information between Co-operating Agents in a Knowledge Network 1998 http://www.brunel.ac.uk/~hssrjis/issue/index8.html 3/4 Journal of Intelligent Systems Special Issue: "Improving the Design of Intelligent Systems: Outstanding Problems and Some Methods for their Solution." L. Robbiano Gröbner Bases and Statistics Bruno Buchberger and Franz Winkler 251 London Mathematical Society Lecture Bibliomisc Series 179–204 Gröbner Bases and Applications 1998 Cambridge University Press H.M. Möller Gröbner Bases and Numerical Analysis Bruno Buchberger and Franz Winkler 251 London Mathematical Society Lecture Bibliomisc Series 159–179 Gröbner Bases and Applications 1998 Cambridge University Press J.F. Canny D. Manocha Multipolynomial resultant algorithms Journal of Symbolic Computation 1993 15 99–122 D. Arnon R. McIsaac K. Waldspurger CaminoReal: an Interactive Mathematical Bibliomiscbook International Conference on Electronic Publishing, Document Manipulation and Typography 1988 Cambridge University Press

Nice

S. Dalmas M. Gaëtano A. Sausse ASAP: a protocol for symbolic computation systems INRIA 1994 162 J. Abbott S. Dalmas M. Dewar A. Diaz S. Gray S. Sheridan A. Strotmann S. Vorkoetter Report of the &OM; Communications Committee 1995 13 November Z. Luo R. Pollack LEGO Proof Development System: User's Manual Department of Compter Science, University of Edinburgh 1992 Z. Luo An Extended Calculus of Constructions Edinburgh University 1990 U. Martin D. Shand Investigating some Embedded Verification Techniques for Computer Algebra Tools RISC-Linz, Research Institute for Symbolic Computation 1997 No. 97-20

J. Kepler University, Linz (A)

http://www-theory.dcs.st-and.ac.uk/~ddshand/Papers/pub.html H. Barendregt E. Barendsen Efficient Computations in Formal Proofs To Appear. Computer Algebra in Industry, Wiley Chichester 1993 A. M. Cohen Problem Solving in Practice R. Carey C. Marrin G. Bell The Virtual Reality Modelling Language International Standard ISO/IEC 14772-1:1997 http://www.vrml.org/Specifications/VRML97/ 1997 R. Carey G. Bell The Annotated VRML Reference Manual Addison-Wesley 1997 C. Marrin External Authoring Interface Reference Proposal for a VRML 2.0 Informative Annex http://www.vrml.org/WorkingGroups/vrml-eai/ExternalInterface.html 1997 November John Harrison Formalized Mathematics Turku Centre for Computer Science (TUCS)

Lemminkäisenkatu 14 A, FIN-20520 Turku, Finland

1996 36 http://www.cl.cam.ac.uk/users/jrh/papers/form-math3.html Martin Dunstan Tom Kelsey Steve Linton Ursula Martin Lightweight Formal Methods for Computer Algebra Systems ISSAC'98: International Symposium on Symbolic and Algebraic Computation 1998 O. Gloor

Rostock, Germany

August ACM Press Paul Jackson Enhancing the Nuprl Proof Development System and Applying it to Computational Abstract Algebra Cornell University 1995 TR95-1509 Laurent Théry A Certified Version of Buchberger Algorithm Automated Deduction - CADE 15: 15th International Conference on Automated Deduction 1998 C. Kirchner and H. Kirchner 1421 Lecture Bibliomiscs in Artificial Intelligence

Landau, Germany

July Springer Verlag PolyMath &OM; Development Team Java &OM; Library: Version 0.7c http://pdg.cecm.sfu.ca/openmath/ June 1999 Stephen Buswell STARS Available from Stilo Technologies http://www.stilo.com April 1999 &OM; Society Website www.openmath.org S. Dalmas M. Gaëtano S. Watt An &OM; 1.0 Implementation 241–248 Proceedings of ISSAC 97 1997 ACM Press &OM; Steering Committee &OM; Version 1.0 released 1996 December http://www.openmath.org &OM; Consortium &OM; Version 1 - Draft 1998 June ftp://ftp-sop.inria.fr/safir/OM/v1.ps G. Gonnet M. Seppala S. Watt Semantic Dictionaries for &OM; Presented at the 6th &OM; Workshop, Zürich 1996 July 27-28 http://www.inf.ethz.ch/personal/gonnet/ContDict.html Robert Constable Personal Communication 1998 July O. Caprotti A. M. Cohen H. Elbers H. Geuvers Connecting &OM; to Formal Math Calculemus and Types '98 1998 July Unicode Consortium The Unicode Standard: Version <phrase revisionflag="deleted">2.0</phrase><phrase revisionflag="added">4.0</phrase> Addison-Wesley Developers Press 19962003 ieee IEEE Standard for binary Floating-Point Arithmetic ANSI/IEEE Standard 754 1985 D. Goldsmith M. Davis UTF-7: A Mail Safe Transformation Format of Unicode RFC: 1642 July 1994 N. Borenstein N Freed MIME (Multipurpose Internet Mail Extensions) Part One: Mechanism for Specifying and Describing the Format of Internet Message Bodies RFC: 1521 September 1993 http://www.math-inf.uni-greifswald.de/~teumer/mime/1521/rfc1521ToC.html iso 646 ISO 7-bit coded character set for information interchange ISO 646:1983 1983 D. Goldsmith M. Davis UTF-7: A Mail Safe Transformation Format of Unicode RFC: 2152 May 1997 http://www.cis.ohio-state.edu/htbin/rfc/rfc2152.html World Wide Web Consortium Namespaces in XML REC-xml-names-19990114 January 1999 http://www.w3.org/TR/REC-xml-names World Wide Web Consortium Extensible Markup Language XML 1.0 REC-xml-19980210 February 1998 http://www.w3.org/TR/REC-xml World Wide Web Consortium Associating Style Sheets with XML documents Version 1.0 W3C Recommendation June 1998 http://www.w3.org/TR/xml-stylesheet/ F. Yergeau UTF-8, a transformation format of ISO 10646 RFC 2279 January 1998 Alis Technologies Technical committee / subcommittee: JTC 1 ISO 9660:1988 Information processing – Volume and File Structure of CDROM for Information Interchange ISO 9660 1988 S. Buswell S. Dalmas J. Davenport &OM; task 1.2: Emerging Technologies &OM; Deliverable 1.2.2 September 1998 Confidential World Wide Web Consortium Extensible Markup Language (XML) 1.0. W3C Recommendation REC-xml-19980210 February 1998 http://www.w3.org/TR/1998/REC-xml-19980210 &OM; Consortium The &OM; Standard &OM; Deliverable 1.3.1a September 1998 http://www.nag.co.uk/projects/OpenMath.html O. Caprotti A. M. Cohen A Type System for &OM; &OM; Deliverable 1.3.1b September 1998 http://www.nag.co.uk/projects/OpenMath.html J. Davenport A Small &OM; Type System &OM; Deliverable 1.3.2b April 1999 http://www.nag.co.uk/projects/OpenMath/omstd/ The &OM; Consortium The &OM; Standard &OM; Esprit Consortium 1999 1.3.2a http://www.nag.co.uk/projects/OpenMath.html February O. Caprotti and A. M. Cohen Eds. Olga Caprotti Arjeh M. Cohen A Type System for &OM; &OM; Esprit Consortium 1999 1.3.2b http://www.nag.co.uk/projects/OpenMath.html February Olga Caprotti Arjeh M. Cohen Development of Strong &OM; &OM; Esprit Consortium 1999 1.3.3b http://www.nag.co.uk/projects/OpenMath.html October A. M. Cohen H. Cuypers H. Sterk Algebra Interactive, interactive course material SV 1999 ISBN 3-540-65368-6 Olga Caprotti Arjeh M. Cohen Integrating Computational and Deduction Systems Using &OM; Calculemus'99: Systems for Integrated Computation and Deduction July 11-12 1999

Trento, Italy

B. Buchberger T. Jebelean F. Kriftner M. Marin E. Tomuta D. Vasaru A Survey of the Theorema Project Proceedings of ISSAC'97 1997

Maui, Hawaii

July Association for Computing Machinery E. Clarke X. Zhao Analytica - a theorem prover in Mathematica 11th Conference on Automated Deduction 761–765 1992 D. Kapur 607 Lecture Bibliomiscs in Computer Science Springer Verlag Stephen Buswell Stan Devitt Angel Diaz Nico Poppelier Bruce Smith Neil Soiffer Robert Sutor Stephen Watt Mathematical Markup Language (MathML) 1.0 Specification W3C Recommendation 19980407 April 1998 Available at http://www.w3.org/TR/REC-MathML/ Patrick Ion Robert Miner Stephen Buswell Stan Devitt Angel Diaz Nico Poppelier Bruce Smith Neil Soiffer Robert Sutor Stephen Watt Mathematical Markup Language (MathML[tm]) 1.01 Specification REC-MathML-19980407; revised 19990707 July 1999 http://www.w3.org/TR/REC-MathML/ World Wide Web Consortium Mathematical Markup Language (MathML) 2.0 Specification REC-MathML2-20010221/ February 2001 Available at http://www.w3.org/TR/REC-MathML2/ CtCoqmath INRIA

Sophia Antipolis

Available at http://www-sop.inria.fr/croap/CFC/Ctcoqmath.html L. Pottier L. Théry Certifier Computer Algebra Calculemus and Types '98

Eindhoven

July 1998 http://www-sop.inria.fr/croap/CFC/ The Lego Algebra Group See http://www.cs.man.ac.uk/~petera/LAG/ Anthony Bailey The Machine-Checked Literate Formalisation of Algebra in Type Theory University of Manchester January 15th 1998 January 15 Open Mechanized Reasoning System Project http://www.mrg.dist.unige.it/omrs Fausto Giunchiglia Paolo Pecchiari Carolyn Talcott Reasoning Theories: Towards an Architecture for Open Mechanized Reasoning Systems "Frontiers of Combining Systems - First International Workshop" (FroCoS'96) 157-174 1996 F. Baader and K.U. Schulz Applied Logic Series

Munich, Germany

26-29 March Kluwer P. Bertoli J. Calmet F. Giunchiglia K. Homann Specification and Integration of Theorem Provers and Computer Algebra Systems Artificial Intelligence and Symbolic Computation: International Conference AISC'98 1998 J. Calmet and J. Plaza 1476 Lecture Notes in Artificial Intelligence

Plattsburgh, New York, USA

September Foundation for Intellingent Physical Agents http://www.fipa.org A. Franke S. Hess Ch. Jung M. Kohlhase V. Sorge Agent-Oriented Integration of Distributed Mathematical Services 1999 5 3 156–187 March Journal of Universal Computer Science Special issue on Integration of Deduction System http://medoc.springer.de:8000/jucs_5_3/agent_oriented_integration_of;internal&sk=060C4837 A. Franke S. Hess Ch. Jung M. Kohlhase V. Sorge An Implementation of Distributed Mathematical Services Calculemus and Types 98 1998

Eindhoven

July Yves Bertot Laurent Théry A Generic Approach to Building User Interfaces for Theorem Provers Journal of Symbolic Computation 1998 25 161-194 Z. Luo P. Callaghan Mathematical Vernacular and Conceptual Well-formedness in Mathematical Language Proceedings of the 2nd International Conference on Logical Aspects of Computational Linguistics 97 1997 1582 Lecture Bibliomiscs in Computer Science

Nancy

Tim Finin Yannis Labrou James Mayfield KQML as an agent communication language Software Agents MIT Press 1997 Jeff Bradshaw

Cambridge

Foundation for Intelligent Physical Agents The FIPA '99 Baselines http://www.fipa.org/spec/fipa99.html Steve Linton Andrew Solomon GAP, &OM;, and MCP ISSAC Workshop: Internet Accessible Mathematical Computation July 99 Paul Wang Design and Protocol for Internet Accessible Mathematical Computation ICM/Kent State University 1999 ICM-199901-001 January Vilya Harvey &OM; in Context &OM; Esprit Consortium 1999 http://www.nag.co.uk/projects/OpenMath/papers/context.pdf June Stéphane Dalmas Marc Gaëtano Claude Huchet A Deductive Database for Mathematical formulas Design and Implementation of Symbolic Computation Systems Springer Verlag Jacques Calmet and Carla Limongelli 1128 LNCS 287-296 1996 Document Object Model (DOM) Level 1 Specification REC-DOM-Level-1-19981001 October 1998 http://www.w3.org/TR/REC-DOM-Level-1/ W3C Recommendation World Wide Web Consortium Extensible Stylesheet Language (XSL) Specification W3C Working Draft 21 Apr 1999 http://www.w3.org/TR/WD-xsl/ M. Kohlhase &OM; for knowledge-based automated theorem proving Electronic Proceedings of the 12th &OM; Workshop 1999

Eindhoven, Netherlands

June http://www.riaca.win.tue.nl/projects/OpenMath/workshop Arjeh Cohen Michael Kohlhase Proposal of an Extension to &OM; by Defining Mathematical Properties 12th &OM; Workshop June 1999 http://www.win.tue.nl/~amc/kohlhase.dvi Olga Caprotti &OM;: Accessing and Using Mathematical Information Electronically CFC meeting talk May 1999 Slide presentation available at http://www.riaca.win.tue.nl/~olga/om/CFCom.ps Olga Caprotti &OM; and COQ: Communicating Certified Mathematical Content CFC meeting talk May 1999 http://www.riaca.win.tue.nl/~olga/om/cfcCOCOM.ps Olga Caprotti Interfacing CA and Proof Checkers with &OM; IMACA-ACA 99 June 1999 Olga Caprotti David Carlisle &OM; and MathML: Semantic Mark Up for Mathematics Crossroad 1999 Special Issue on Markup Languages http://www.acm.org/crossroads Olga Caprotti Arjeh Cohen Integrating Computational and Deduction Systems Using &OM; Proceedings of Calculemus 99 1999

Trento

July Olga Caprotti Arjeh Cohen Interactive Mathematics with Strong &OM; Internet Accessible Mathematical Computation 1999

Vancouver, Canada

July 28 http://symbolicnet.mcs.kent.edu/icm/research/iamc99proceedings.html Seminar on &OM; for Industry http://www.riaca.win.tue.nl/projects/OpenMath/convention.html June 1999 12th &OM; Workshop http://www.riaca.win.tue.nl/projects/OpenMath/workshop/ June 15-16 1999