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_98 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 XML 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 compuational 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. (vi) Variable. A Variable consists of a name which is a sequence of characters matching a regular expression, as described below.

Compound &OM; Objects &OM; objects are built recursively as follows. (i) Basic &OM; objects are &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

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

is an &OM; attribution object and

A

is the object stripped of attributions. 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.

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=+(),-./:?!#$%*;=@[]^_`{|}]+

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

Binding of several variables as in:

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

is semantically equivalent to composition of binding of a single variable, namely

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

Rephrase slightly Note that it follows from this that repeated occurences of the same variable in a binding operator are allowed. For example the object

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

is semantically equivalent to:

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

so that the outermost binding is actually a constant function (

v

does not occur free in the body

application (times, v, v))

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

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 attribution object itself. As 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. 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.) 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

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 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, OpenMath 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 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 the most common character set (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.

A Grammar for the &exml; Encoding Modify description of XML encoding to make dtd normative, and other changes to increase portability to &exml; applications. The &exml; encoding of an OpenMath object is defined by the dtd given in 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. Entity and character references should not be used. A <!DOCTYPE declaration should not be used. 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

|

|

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)+ vv char

⟶

XML 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 cdnameatt S symbnameatt S? /> variable

⟶

|

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

⟶

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

⟶

symbol

|

variable

|

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

|

|

|

|

|

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

|

<OMBIND S?> SC? object SC? <OMBVAR S?> SC? variables SC? </#1 S?> SC? object SC? </OMBIND S?>

|

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

|

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

⟶

symbol S? object

|

symbol S? object S? attrs objects

⟶

SC?

|

object SC? objects variables

⟶

SC?

|

variable SC? variables

Description of the Grammar An encoded &OM; object is placed inside an OMOBJ element. This element can contain the elements (and integers) as described above. 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 &exml;-attributes cd and name. 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 name of the Content Dictionary is compulsory, but a future revision of the &OM; standard might introduce a defaulting mechanism. For example, <OMS cd="transc" name="sin"/> is the encoding of the symbol named sin in the Content Dictionary named transc. 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"/> 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 OpenMath 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: ]]> Errorsare 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 ]]>

Embedding OpenMath in XML Documents New section on embedding OM in XML 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 XML document one may wish, or need, to use other XML 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 XML Namespace Recommnedation 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] object

⟶

integer

|

float

|

variable

|

symbol

|

string

|

bytearray

|

construct integer

⟶

[1] [_]

|

[1 + 128] {_}

|

[2] [n] [_] digits:n

|

[2 + 128] {n} [_] digits:n float

⟶

[3] {_} {_} variable

⟶

[5] [n] varname:n

|

[5 + 128] {n} varname:n

|

[5 + 64] [n] symbol

⟶

[8] [n] [m] cdname:n symbname:m

|

[8 + 128] {n} {m} cdname:n symbname:m

|

[8 + 64] [n] string

⟶

[6] [n] chars:n

|

[6 + 128] {n} chars:n

|

[7] [n] chars:2n

|

[7 + 128] {n} chars:2n

|

[7 + 64] [n] bytearray

⟶

[4] [n] bytes:n

|

[4 + 128] {n} bytes:n construct

⟶

[16] object objects [17]

|

[22] symbol objects [23]

|

[18] attrpairs object [19]

|

[26] object bvars object [27] attrpairs

⟶

[20] pairs [21] pairs

⟶

symbol object

|

symbol object pairs bvars

⟶

[28] vars [29] vars

⟶

attrvar

|

attrvar vars attrvar

⟶

variable

|

[18] attrpairs attrvar [19] objects

⟶

|

object objects gives a grammar for the binary encoding. 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.

Description of the Grammar An &OM; object is encoded as a sequence of bytes starting with the begin object tag (value 24) and ending with the end object tag (value 25). 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 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. 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 tag (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. Symbolsare encoded as the symbol tag (8) with the long flag set if the maximum of the length of the Content Dictionary name and the symbol name 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), then 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. Variablesare encoded using the variable tag (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. Floating-point numberare encoded using the floating-point number tag (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 stringare 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 tag (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 tag (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). Bytearraysare encoded using the bytearray tag (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. Applicationsare encoded using the application tag (16). More precisely, the application of

E_{0}

E_{1}

…

E_{n}

is encoded using the application tag (16), the sequence of the encodings of

E_{0}

E_{n}

and the end application tag (17). Bindingsare encoded using the binding tag (26). More precisely, the binding by

B

of variables

V_{1}

…

V_{n}

C

is encoded as the binding tag (26), followed by the encoding of

B

, followed by the binding variables tag (28), followed by the encodings of the variables

V_{1}

…

V_{n}

, followed by the end binding variables tag (29), followed by the encoding of

C

, followed by the end binding tag (27). Attributionare encoded using the attribution tag (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 tag (18), followed by the encoding of the attribute pairs as the attribute pairs tag (20), followed by the encoding of each symbol and value, followed by the end attribute pairs tag (21), followed by the encoding of

E

, followed by the end attributed object tag (19). Errorare encoded using the error tag (22). More precisely,

S_{0}

applied to

E_{1}

…

E_{n}

is encoded as the error tag (22), the encoding of

S_{0}

, the sequence of the encodings of

E_{0}

E_{n}

and the end error tag (23).

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

Implementation Note A typical implementation of the binary encoding 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). 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 18 begin object tag 68 h .) 10 begin application tag 31 1 .) 08 symbol tag 70 p (symbol name begin 06 cd 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 .) 01 reference 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

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

Content Dictionaries In this section we define the overall 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 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. 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 section below.

The XML Encoding for Content Dictionaries Content Dictionaries are XML 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 . 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 DTD Specification of Content Dictionaries

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

Further Requirements of an &OM; Content Dictionary 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. now we have this numbering mechanism, should it be documented? CDNameThe text occurring in the CDName element corresponds to the name of Content Dictionary, and is of the form specified in . 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 XML text. CDReviewDateThe text occurring in the CDReviewDate element corresponds to the earliest possible revision 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 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 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. CDStatusThe text occurring in the CDStatus element corresponds to the status of 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). 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. 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 Example new description The text occurring in the Example element is used to give examples of the enclosing symbol, and can be any XML 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. NameThe text occurring in the Name element corresponds to the name of the symbol, and is specified as in . 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. FMPThe 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 XML encoding. An application which says it understands a Content Dictionary symbol need not understand a formal property of the symbol.

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 files, CDGroups, and possibly files of extra mathematical properties, are used to convey the different aspects that as a whole make up a mathematical definition.

Signature Files 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; ]]>

Further Requirements of a Signature File Added PCDATA for Additional Files 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 XML 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 XML attribute type of the CDSignature element. See for examples.

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

DTD Specification of CDGroups ]]>

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 XML 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 . 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 XML 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 OpenMath meeting in Bath Applications that meet the requirements specified in this chapter may label themselves as OpenMath 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 XML encoding, defined in chapter . As a minimum, an &OM; compliant application, which accepts or generates &OM; objects, must be capable of doing so using the XML 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. 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 OpenMath 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 OpenMath 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