OpenMath"> xml"> →"> %openmath2; %omcd2; %omcdsig2; ]> The &OM; Standard 2.0 Public Draft 6c (11 May 2004) The &OM; Society S.Buswell O.Caprotti D.P.Carlisle M.C.Dewar M.Gaetano M.Kohlhase May 2004 2000–2004 The OpenMath Society This document proposes &OM; as a standard for the communication of semantically rich mathematical objects. This draft of the &OM; standard comprises the following: a description of &OM; objects, the grammar of &exml; and of the binary encoding of objects, a description of Content Dictionaries and an &exml; document type definition for validating Content Dictionaries. The non-normative of this document briefly overviews the history of &OM;. This document describes version 2 of &OM;: a standard for the representation and communication of mathematical objects. &OM; allows the meaning of an object to be encoded rather than just a visual representation. It is designed to allow the free exchange of mathematical objects between software systems and human beings. On the worldwide web it is designed to allow mathematical expressions embedded in web pages to be manipulated and computed with in a meaningful and correct way. It is designed to be machine-generatable and machine-readable, rather than written by hand. The &OM; Standard is the official reference for the &OM; language and has been approved by the &OM; Society. It is not intended as an introductory document or a user's guide, for the latest available material of this nature please consult the &OM; web-site at http://www.openmath.org. This document includes an overview of the &OM; architecture, an abstract description of &OM; objects and two mechanisms for producing concrete encodings of such objects. The first, in &exml;, is designed primarily for use on the web, in documents, and for applications which want to mix &OM; as a content representation with MathML as a presentation format. The second, a binary format, is designed for applications which wish to exchange very large objects, or a lot of data as efficiently as possible. This document also includes a description of Content Dictionaries - the mechanism by which the meaning of a symbol in the &OM; language is encoded, as well as an XML encoding for them. Finally it includes guidelines for the development of &OM;-compliant applications. List of Figures &OM; Movement 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 has since attracted interest from other areas of scientific computation and from many publishers of electronic documents with a significant mathematical content. There is a strong relationship to the MathML recommendation MathML_2003 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 &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, and by 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 upon and some prototype implementations had come about Dalmas_Gaetano_Watt_97. 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 were to formalise &OM; as a standard and to develop it further through industrial applications; this process led to the OpenMath 1.0 and 1.1 standards which were endorsed at workshops in Tallahassee (November 1998) and Eindhoven (June 1999). In November 1998 the &OM; Society was established to coordinate all &OM; activities. The society is based in Helsinki, Finland and is coordinated by the executive committee whose members are elected by the society. The official web page of the society is http://www.openmath.org. In 2001 the European Union agreed to fund a Thematic Network under its Fifth Framework programme to coordinate further work on &OM; and MathML, and in particular to support a further series of workshops. This document is one outcome of that project, and seeks to update &OM; in the light of recent developments in XML and of the &OM; community's collective experience working with the old standard.
&OM; Society 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. The &OM; Society continues to provide long-term coordination of &OM; activities. Membership is open to anybody who is active in &OM;; for further details see the web-site at http://www.openmath.org/society/index.html.
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. The first is a private layer that is the internal representation used by an application. The second is an abstract layer that is the representation as an &OM; object. Note that these two layers may, in some cases, be the same. The third is a communication layer that translates the &OM; object representation into 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 &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 . The standard endorses two encodings in &exml; and binary formats. At the time of writing, these are the encodings supported by most existing &OM; tools and applications, These are the encodings supported by the official &OM; libraries however they are not the only possible encodings of &OM; objects. Users who wish to define their own encoding using some other specific language (e.g. Lisp) may , are free to do so provided that there is an effective translation from this encoding to an official one a well-defined correspondence between the new encoding and the abstract model defined in .
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 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 a specific set of Content Dictionaries as a CDGroup. Auxiliary files that define presentation and rendering or that are used for manipulating and processing Content Dictionaries are not discussed by the standard.
Phrasebooks The conversion of an &OM; object to/from the internal representation in a software application is performed by an interface program called a 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. &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 or 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 In this chapter we provide a self-contained description of &OM; objects. We first do so by means of an abstract grammar description () and then give a more informal description ().
Formal 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. (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 symbol name, a Content Dictionary name, and (optionally) a Content Dictionary base URI, The name of a symbol is a sequence of characters matching the regular expression described in . 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. There are other properties of the symbol that are not explicit in these fieleds but whose values may be obtained by inspecting the Content Dictionary specified. these include the symbol definition, formal properties and examples and, optionally, a Role which is a restriction on where the symbol may appear in an &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 .
Derived &OM; Objects Derived &OM; objects are currently used as a way by which non-&OM; data is embedded inside an &OM; object. A derived &OM; object is built as follows: (i) If A is not an &OM; object, then foreignA is an &OM; foreign object. An &OM; foreign object may optionally have an encoding field which describes how its contents should be interpreted.
<phrase revisionflag="deleted">Compound</phrase>&OM; Objects &OM; objects are built recursively as follows. (i) Basic &OM; objects are &OM; objects. (Note that derived &OM; objects are not &OM; objects, but are used to construct &OM; objects as described below.) (ii) If A1, …, An (n>0) are &OM; objects, then application(A1, …, An) is an &OM; application object. (iii) If S1, …, Sn are &OM; symbols, and A, A1, …, An, (n>0) are &OM; objects, then A is an &OM; object, and A1, …, An (n>0) are &OM; objects or &OM; derived objects, then attribution (A, S1 A1, … , Sn An) is an &OM; attribution object. and A is the object stripped of attributions. S1, …, Sn are referred to as keys and A1, …, An as their associated values. The operation of recursively applying stripping to the stripped object is called flattening of the attribution. When the stripped object after flattening is a variable, the attributed object is called attributed variable. If, after recursively applying stripping to remove attributions, the resulting un-attributed object is a variable, the original attributed object is called an attributed variable. (iv) If B and C are &OM; objects, and v1, …, vn (n ≥ 0) are &OM; variables or attributed variables, then binding (B, v1, …, vn, C) is an &OM; binding object. (v) If S is an &OM; symbol and A1, …, An (n ≥ 0) are &OM; objects or &OM; derived objects, then error (S, A1,…,An) is an &OM; error object.
&OM; Symbol Roles We say that an &OM; symbol is used to construct an &OM; object if it is the first child of an &OM; application, binding or error object, or an even-indexed child of an &OM; attribution object (i.e. the key in a (key, value) pair). The role of an &OM; symbol is a restriction on how it may be used to construct a compound &OM; object and, in the case of the key in an attribution object, a clarification of how that attribution should be interpreted. Possible roles are: binder The symbol may appear as the first child of an &OM; binding object. attribution The symbol may 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 appear as the first child of an &OM; error object. application The symbol can appear as the first child of an &OM; application object. constant The symbol cannot be used to construct an &OM; compound object. A symbol cannot have more than one role and cannot be used to construct a compound &OM; object in a way which requires a different role (using the definition of construct given earlier in this section). This means that one cannot use a symbol which binds some variables to construct, say, an application object. However it does not prevent the use of that symbol as an argument in an application object (where by argument we mean a child with index greater than 1). If no role is indicated then the symbol can be used anywhere. Note that this is not the same as saying that the symbol's role is constant.
Further Description of &OM; Objects 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 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-commutative set theoretic union in a Content Dictionary set1 but another Content Dictionary, multiset1 might define a symbol union as the union of multi-sets). The name of a symbol can only contain alphanumeric characters and underscores. More precisely, a symbol name matches the following regular expression:
[A-Za-z] [A-Za-z0-9_]*
Notice that these symbol names are case sensitive. &OM; recommends that symbol names should be no longer than 100 characters. Variablesare meant to denote parameters, variables or indeterminate (such as bound variables of function definitions, variables in summations and integrals, independent variables of derivatives). Plain variable names are restricted to use a subset of the printable ASCII characters. Formally the names must match the regular expression:
[A-Za-z0-9=+(),-./:?!#$%*;=@[]^_`{|}]+
Derived &OM; objects are constructed from non-&OM; data. They differ from bytearrays in that they can have any structure. Currently there is only one way of making a 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. They may also appear in &OM; error objects, for example to allow an application to report an error in processing such an object. The four following constructs can be used to make compound &OM; objects out of basic or derived &OM; objects. Applicationconstructs an &OM; object from a sequence of one or more &OM; objects. The first argument of an application is referred to as its head while the remaining objects are called its 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 suitable 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.
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 nth argument object. It is allowed to have no bound variables, but the binder object and the body should be present. Binding can be used to express functions or logical statements. The function λ x.x +2, in which the variable x is bound by λ, corresponds to a binding object having as binder the &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 Ω by binding (B , z , C') where z is a variable not occurring free in C and C' is obtained from C by replacing each free (i.e., not bound by any intermediate binding construct) occurrence of v by z. This operation preserves the semantics of the object Ω. In the above example, a phrasebook is thus allowed to transform the object to, e.g. binding (lambda, v , binding (lambda, z ,application (times,z ,z))). binding(lambda, z , application(plus, z , 2)). Repeated occurrences of the same variable in a binding operator are allowed. An &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; foreign 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, S1 A1,…,Sh Ah), Sh+1 Ah+1, …, Sn An) is semantically equivalent to a single attribution, that is attribution(A, S1 A1, …, Sh Ah, Sh+1 Ah+1, …, Sn An). The operation that produces an object with a single layer of attribution is called flattening. Multiple attributes with the same name are allowed. While the order of the given attributes does not imply any notion of priority, potentially it could be significant. For instance, consider the case in which Sh = Sn (h < n) in the example above. Then, the object is to be interpreted as if the value An overwrites the value Ah. (&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 role attribution, then replacement of the attributed object by the object itself is not harmful and preserves the semantics. When the key has role semantic-attribution then the attributed object is modified by the attribution and cannot be viewed as semantically equivalent to the stripped object. If the attribute lacks the role specification then attribution is acting as adornment annotation. Objects can be decorated in a multitude of ways. In OMD132b, typing of &OM; objects is expressed by using an attribution. An example of the use of an adornment attribution would be to indicate the colour in which an &OM; object should be displayed, for example attribution(A, colour red ). Note that both A and red are &OM; objects. An example of the use of a semantic attribution would be to indicate the type of an object. For example the object attribution(A, type t ) represents the judgment stating that object A has type t. Note that both A and t are &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 ).
Names The names of symbols, variables and content dictionaries must conform to the production Name specified in the following grammar (which is identical to that for &exml; names in XML 1.1, xml_04). Informally speaking, a name is a sequence of Unicode UNICODE characters which begins with a letter and cannot contain certain punctuation and combining characters. The notation #x... represents the hexadecimal value of the encoding of a Unicode character. Some of the character values or code points in the following productions are currently unassigned, but this is likely to change in the future as Unicode evolves We note that in XML 1 the name production explicitly listed the characters that were allowed, so all the characters added in versions of Unicode after 2.0 (which amounted to tens of thousands of characters) were not allowed in names. .
Name ⟶ NameStartChar (NameChar)* NameStartChar ⟶ ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF] NameChar ⟶ NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
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'
Canonical URIs for Symbols To facilitate the use of &OM; within a URI-based framework (such as RDF rdf or OWL owl), we provide the following scheme for constructing a canonical URI for an &OM; Symbol:
URI = cdbase-value + '/' + cd-value + '#' + name-value
So for example the URI for the symbol with cdbase http://www.openmath.org/cd, cd transc1 and name sin is:
http://www.openmath.org/cd/transc1#sin
In particular, this now allows us to refer uniquely to an &OM; symbol from a MathML document MathML_2003: <mathml:csymbol xmlns:mathml="http://www.w3.org/1998/Math/MathML/" definitionURL="http://www.openmath.org/cd/transc1#sin"> <mo> sin </mo> </csymbol>
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 foreign &OM; objects. &OM; objects have the expressive power to cover all areas of computational mathematics. 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 (inter-process communications over a network is an example). Note that these two encodings are sufficiently different for auto-detection to be effective: an application reading the bytes can very easily determine which encoding is used.
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 easily be included in most documents and transport protocols) and that is both readable and writable by a human. to provide an encoding that can be included (embedded) in &exml; documents or processed by &exml;-aware applications.
A <phrase revisionflag="deleted">Grammar</phrase><phrase>Schema</phrase> for the &exml; Encoding 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 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 that the encoding may be read by &OM; applications that may not include a full &exml; parser. The document should use utf-8 encoding. A <!DOCTYPE declaration should not be used. Character references should not be used. As <!DOCTYPE is not used, the only entity references that are allowed are the five predefined entity references: &apos; ('), &quot; ("), &lt; (<), &gt; (>), &amp; (&). The &exml; empty element form <|#8230;/> should always be used to encode elements such as omf which are specified in the dtd as being empty. It should never be used for elements that may sometimes be empty, such as omstr. Such a linearisation of an &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. 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 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 |variable | <OMI S > S? integer S? </OMI S?> | <OMF S fpdecatt S?/> | <OMF S fphexatt S?/> | <OMSTR S?> char </OMSTR S?> | <OMB S?> base64 </OMB S?> | <OMA S?> SC? object SC? objects SC? </OMA S?> | <OMBIND S?> SC? object SC? <OMBVAR S?> SC? variables SC? </OMBVAR S?> SC? object SC? </OMBIND S?> | <OME S?> SC? symbol SC? objects SC? </OME S?> | <OMATTR S?> SC? <OMATP S?> SC? attrs SC? </OMBVAR S?> SC? object SC? </OMATTR S?> attrs ⟶ symbol S? object | symbol S? object S? attrs objects ⟶ SC? | object SC? objects variables ⟶ SC? | variable SC? variables Note: This schema specifies names as being of the xsd:NCName type. At the time of writing, W3C Schema types are defined in terms of XML 1 xml_98. This limits the characters allowed in a name to a subset of the characters available in Unicode 2.0, which is far more restrictive than the definition for an &OM; name given in . It is expected that W3C Schema types will be augmented to match the new XML 1.1 recommendation xml_04, but for portability reasons applications should avoid using the new XML 1.1 name characters unless they are absolutely required. The XML 1.1 specification has a useful appendix giving advice on good strategies to use when naming identifiers.
<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. In previous versions of this standard this attribute did not exist, so any &OM; object without such an attribute must conform to version 1 (or equivalently 1.1) of the &OM; standard. Objects which conform to the description given in this document should have version="2.0". We briefly discuss the &exml; encoding for each type of &OM; object starting from the basic objects. Integers are encoded using the OMI element around the sequence of their digits in base 10 or 16 (most significant digit first). White space may be inserted between the characters of the integer representation, this will be ignored. After ignoring white space, integers written in base 10 match the regular expression -?[0-9]+. Integers written in base 16 match -?x[0-9A-F]+. The integer 10 can be thus encoded as <OMI> 10 </OMI> or as <OMI> xA </OMI> but neither <OMI> +10 </OMI> nor <OMI> +xA </OMI> can be used. The negative integer -120 can be encoded as either as decimal <OMI> -120 </OMI> or as hexadecimal <OMI> -x78 </OMI>. 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. If a symbol does not have an explicit cdbase attribute, then it inherits its cdbase from the first ancestor in the &exml; tree with one, should such an element exist. In this document we have tended to omit the cdbase for clarity. The name of the Content Dictionary is compulsory, but a future revision of the &OM; standard might introduce a defaulting mechanism. For example:
<OMS cd="transc" name="sin"/>
<OMS cdbase="http://www.openmath.org/cd" cd="transc1" name="sin"/>
is the encoding of the symbol named sin in the Content Dictionary named transc1, which is part of the collection maintained by the &OM; Society. As described in , the three attributes of the OMS can be used to build a URI reference for the symbol, for use in contexts where URI-based referencing mechanisms are used. For example the URI for the above symbol is http://www.openmath.org/cd/transc1#sin. Note that the role attribute described in is contained in the Content Dictionary and is not part of the encoding of a symbol, also the cdbase attribute need not be explicit on each OMS as it is inherited from any ancestor element. 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]+)?([eE](-?)[0-9]+)?. or one of the special values: INF, -INF or NaN.
The value of hex is a base 16 representation of the 64 bits of the ieee Double. Thus the number represents mantissa, exponent, and sign from lowest to highest bits using a least significant byte ordering. This consists of a string of 16 digits 0-9, A-F. For example, both <OMF dec="1.0e-10"/> and <OMF hex="3DDB7CDFD9D7BDBB"/> are valid representations of the floating point number 1× 10-10. The symbols INF, -INF and NaN represent positive and negative infinity, and not a number as defined in ieee754_85. Note that while infinities have a unique representation, it is possible for NaNs to contain extra information about how they were generated and if this informations is to be preserved then the hexadecimal representation must be used. For example <OMF hex="FFF8000000000000"/> and <OMF hex="FFF8000000000001"/> are both hexadecimal representations of NaNs. Character 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 &lt; and &amp; 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 2045 rfc2045. Basically, it represents an arbitrary sequence of octets using 64 digits (A through Z, a through z, 0 through 9, + and /, in order of increasing value). Three octets are represented as four digits (the = character is used for padding at the end of the data). All line breaks and carriage return, space, form feed and horizontal tabulation characters are ignored. The reader is referred to rfc1521 rfc2045 for more detailed information. In detail the encoding of an &OM; object is described below. Applicationsare encoded using the OMA element. The application whose head is the &OM; object e0 and whose arguments are the &OM; objects e1, …, en is encoded as <OMA> C0 C1… Cn </OMA> where Ci is the encoding of ei. For example, application(sin,x ) is encoded as: ]]> 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 x1, x2, …, xn in the object c is encoded as <OMBIND> B <OMBVAR> X1 … Xn </OMBVAR> C </OMBIND> where B, C, and Xi are the encodings of b, c and xi, respectively. For instance the encoding of binding (lambda, x,application (sin, x)) is: ]]> 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 (s1, e1), …, (sn, en) pairs (where si are the attributes), it is encoded as <OMATTR> <OMATP> S1 C1 … Sn Cn </OMATP> E </OMATTR> where Si is the encoding of the symbol si, Ci of the object ei and E is the encoding of e. Examples are the use of attribution to decorate a group by its automorphism group: [..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 sinx with its representation in Presentation MathML is: sinx ]]> 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) ]]> For a discussion on the use of the encoding attribute see . Errors are encoded using the OME element. The error whose symbol is s and whose arguments are the &OM; objects or &OM; derived objects e1, …, en is encoded as <OME> Cs C1… Cn </OME> where Cs is the encoding of s and Ci the encoding of ei. If an aritherror Content Dictionary contained a DivisionByZero symbol, then the object error(DivisionByZero, application (divide, x, 0)) would be encoded as follows: 0 ]]> If a mathml Content Dictionary contained an unhandled_csymbol symbol, then an &OM; to MathML translator might return an error such as: Ai ]]> Note that it is possible to embed fragments of valid &OM; inside an OMFOREIGN element but that it cannot contain invalid &OM;. In addition, the arguments to an OMERROR must be well-formed &exml;. If an application wishes to signal that the &OM; it has received is invalid or is not well-formed then the offending data must be encoded as a string. For example: <OMA> <OMS name="cos" cd="transc1"> <OMV name="v"> </OMA> ]]> Note that the `<' and `>' characters have been escaped as is usual in an &exml; document. References &OM; integers, floating point numbers, character strings, bytearrays, applications, binding, attributions can also be encoded as an empty OMR element with an href attribute whose value is the value of a URI referencing an id attribute of an &OM; object of that type. The &OM; element represented by this OMR reference is a copy of the &OM; element referenced href attribute. Note that this copy is structurally equal, but not identical to the element referenced. 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 given in (and some intermediate versions as well).
Shared vs. unshared representations ]]>
Some Notes on References 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 , 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 third child, which dominates the OMR element, which dominates its target: the element with id="foo". So by transitivity, this element dominates itself, and by the acyclicity constraint, it is not the &exml; representation of an &OM; element. Even though it could be given the interpretation of the continued fraction 1 1 + 1 1 + 1... this would correspond to an infinite tree of applications, which is not admitted by the structure of &OM; objects described in . Note that the acyclicity constraints is not restricted to such simple cases, as the example in shows.
Sharing between &OM; objects (A cycle of order <math><mn>2</mn></math>. 1 1 ]]>
Here, the OMA with id="bar" dominates its third child, the OMR with xref="baz", which dominates its target OMA with id="baz", which in turn dominates its third child, the OMR with xref="bar", this finally dominates its target, the original OMA element with id="bar". So this pair of &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 sub-terms of the form application ( g , X ) , one with id="orig" (the one explicitly represented) and one with id="copy", represented by the OMR element. In the original, the variable X is bound by the outer OMBIND element, and in the copy, the variable X is bound by the inner OMBIND element. We say that the inner OMBIND has captured the variable X. It is well-known that variable capture does not conserve semantics. For instance, we could use α-conversion to rename the inner occurrence of X into, say, Y arriving at the (same) object binding ( λ , X , application ( f , binding ( λ , Y , application ( g , Y ) ) , application ( g , X ) ) ) ) Using references that capture variables in this way can easily lead to representation errors, and is not recommended.
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_04. Also, the encoding used in the larger document may not be utf-8. 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
Grammar of the binary encoding of &OM; objects. start ⟶ [24] object [25] | [24+64] [m] [n] object [25] object ⟶ integer | float | variable | symbol | cdbase | string | bytearray | foreign | construct | internal_reference | external_reference integer ⟶ [1] [_] | [1+64] [n] id:n [_] | [1+32] [_] | [1+128] {_} | [1+64+128] {n} id:n {_} | [1+32+128] {_} | [2] [n] [_] digits:n | [2+64] [n] [m] [_] digits:n id:m | [2+32] [n] [_] digits:n | [2+128] {n} [_] digits:n | [2+64+128] {n} {n} [_] digits:n id:n | [2+32+128] {n} [_] digits:n float ⟶ [3] {_}{_} | [3+64] [n] id:n {_}{_} variable ⟶ [5] [n] varname:n | [5+64] [n] [m] varname:n id:m | [5+128] {n} varname:n | [5+64+128] {n} {m} varname:n id:m symbol ⟶ [8] [n] [m] cdname:n symbname:m | [8+64] [n] [m] [k] cdname:n symbname:m id:k | [8+128] {n} {m} cdname:n symbname:m | [8+64+128] {n} {m} {k} cdname:n symbname:m id:k string ⟶ [6] [n] chars bytes:n | [6+64] [n] chars bytes:n | [6+32] [n] bytes:n | [6+128] {n} chars bytes:n | [6+64+128] {n} {m} chars bytes:n id:m | [6+32+128] {n} bytes:n | [7] [n] chars bytes:2n | [7+64] [n] [m] chars bytes:n id:m | [7+32] [n] bytes:2n | [7+128] {n} chars bytes:2n | [7+64+128] {n} {m} chars bytes:2n id:m | [7+32+128] {n} bytes:2n bytearray ⟶ [4] [n] bytes:n | [4+64] [n] [m] bytes:n id:m | [4+32] [n] bytes:n | [4+128] {n} bytes:n | [4+64+128] {n} {m} bytes:n id:m | [4+32+128] {n} bytes:n cdbase ⟶ [9] [n] uri:n object | [9+128] {n} uri:n object foreign ⟶ [12] [n] [m] bytes:n bytes:m | [12+64] [n] [m] [k] bytes:n bytes:m id:k | [12+32] [n] [m] bytes:n bytes:m | [12+128] {n} {m} bytes:n bytes:m | [12+64+128] {n} {m} {k} bytes:n bytes:m id:k | [12+32+128] {n} {m} bytes:n bytes: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
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:2n denotes a sequence of 2n 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 cdname this 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). These are similar to the <OMOBJ> and </OMOBJ> tags of the &exml; encoding. Objects with start token [88] have two additional bytes m and n that characterize the version (m.n) of the encoding directly after the start token. This is similar to <OMOBJ version="m.n"> 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 bytes or characters. The sharing flag indicates that the encoded object may be 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 , then the encoding includes a representation of an identifier that serves as the target of a reference (internal with token identifier 30 or external with token identifier 31). The concept of structure sharing in &OM; encodings and in particular the sharing bit in the binary encoding has been introduced in &OM; 2 (see section for details). The binary encoding in &OM; 2 leaves the tokens with sharing flag 0 unchanged to ensure &OM; 1 compatibility. To make use of functionality like the version attribute on the &OM; object introduced in &OM; 2, the tokens with sharing flag 1 should be used. To facilitate the streaming of &OM; objects, some basic objects (integers, strings, bytearrays, and foreign objects) have variant token identifiers with the fifth bit set. The idea behind this is that these basic objects can be split into packets. If the fifth bit is not set, this packet is the final packet of the basic object. If the bit is set, then more packets of the basic object will follow directly after this one. Note that all packets making up a basic object must have the same token identifier (up to the fifth bit). In we have represented an integer that is split up into three packets. 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 tags (token identifier 1) followed by a single byte that is the value of the integer (interpreted as a signed character). For example 16 is encoded as 0x01 0x10. Integers between -2 31 (-2147483648) and 2 31 - 1 (2147483647) are encoded as the small integer tag with the long flag set followed by the integer encoded in little endian format in 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 or-ed 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 (233) 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. To splice sequences of integer packets into integers, we have to consider three cases: In the case of token identifiers 1, 33, and 65 the sequence of packets is treated as a sequence of integer digits to the base of 27 (most significant first). The case of token identifiers 129, 161, and 193 is analogous with digits of base 231. In the case of token identifiers 2, 34, 66, 130, 162, and 194 the integer is assembled by concatenating the string of decimal digits in the packets in sequence order (which corresponds to most significant first). Note that in all cases only the sequence-initial packet may contain a signed integer. The sign of this packet determines the sign of the overall integer.
Streaming a large Integer in the Binary Encoding. Hex Meaning 22begin streamed big integer tag FF255 digits in packet 2Bsign + ... the 255 digits as characters 22begin streamed big integer tag FF255 digits in packet 2Bsign + (disregarded) ... the 255 digits as characters 2begin final big integer tag 4268 digits in packet 2Bsign + (disregarded) ... the 68 digits as characters
Symbols are encoded as the symbol tags (token identifier 8) with the long flag set if the maximum of the length in bytes in the utf-8 encoding of the Content Dictionary name or 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), 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 tag is followed by the length in bytes in the utf-8 encoding of the Content Dictionary name, the symbol name, and the id (if the shared bit was set) as a byte (if the long flag was not set) or a four byte integer (in network byte order). These are followed by the bytes of the utf-8 encoding of the Content Dictionary name, the symbol name, and the id. Variables are encoded using the variable tags (token identifiers 5) with the long flag set if the number of bytes in the utf-8 encoding of the variable name is greater than or equal to 256. 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 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, the string is encoded in utf-16 or iso-8859-1 (latin-1). In the case of latin-1 it is encoded as the one byte character string tags (token identifier 6) with the long flag set if the number of bytes (characters) in the string is greater than or equal to 256. Then, there is the number of characters as a byte (if the length flag was not set) or a four byte integer (in network byte order), followed by the characters in the string. If the string contains two byte characters, it is encoded as the two byte is encoded in utf-16, it is encoded as the utf-16 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 charactersutf-16 units, which will be the number of characters unless characters in the higher planes of Unicode are used, as a byte (if the long flag was not set) or a four byte integer (in network byte order), followed by the characters (utf-16 encoded Unicode). Sequences of string packets are assumed to have the same encoding for every packet. They are assembled into strings by concatenating the strings in the packets in sequence order. Bytearrays are encoded using the bytearray tags (token identifier 4) with the long flag set if the number 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. Sequences of bytearray packets are assembled into byte arrays by concatenating the bytearrays in the packets in sequence order. Foreign Objects are encoded using the foreign object tags (token identifier 12) with the long flag set if the number of bytes is greater than or equal to 256 and the streaming bit set for dividing it up into packets. Then, there is the number n of bytes used to encode the encoding attribute, and the number m of bytes used to encode the foreign object. n and m are represented as a byte (if the long flag was not set) or a four byte integer (in network byte order). These numbers are followed by an n-byte representation of the encoding attribute and an m byte sequence of bytes encoding the foreign object in their normal order (we call these the payload bytes). The encoding attribute is encoded in utf-8. Sequences of foreign object packets are assembled into foreign objects by concatenating the payload bytes in the packets in sequence order. Note that the foreign object is encoded as a stream of bytes, not a stream of characters. Character based formats (including XML based formats) should be encoded in utf-8 to produce a stream of bytes to use as the payload of the foreign object. cdbase scopes are encoded using the token identifier 9. The purpose of these scoping devices is to associate a cdbase with an object. The start token [9] (or [137] if the long flag is set) is followed by a single-byte (or 4-byte- if the long flag is set) number n and then by a seqence of n bytes that represent the value of the cdbase attribute (a URI) in utf-8 encoding. This is then followed by the binary encoding of a single object: the object over which this cdbase attribute has scope. Applications are encoded using the application tags (token identifiers 16 and 17). More precisely, the application of E0 to E1… En is encoded using the application tags (token identifier 16), the sequence of the encodings of E0 to En and the end application tags (token identifier 17). Bindings are encoded using the binding tags (token identifiers 26 and 27). More precisely, the binding by B of variables V1… Vn in C is encoded as the binding tag (token identifier 26), followed by the encoding of B, followed by the binding variables tags (token identifier 28), followed by the encodings of the variables V1 … Vn, followed by the end binding variables tags (token identifier 29), followed by the encoding of C, followed by the end binding tags (token identifier 27). Attributions are encoded using the attribution tags (token identifiers 18 and 19). More precisely, attribution of the object E with (S1, E1), … (Sn, En) pairs (where Si are the attributes) is encoded as the attributed object tag (token identifier 18), followed by the encoding of the attribute pairs as the attribute pairs tags (token identifier 20), followed by the encoding of each symbol and value, followed by the end attribute pairs tag (token identifier 21), followed by the encoding of E, followed by the end attributed object tag (token identifier 19). Errors are encoded using the error tags (token identifiers 22 and 23). More precisely, S0 applied to E1… En is encoded as the error tag (token identifier 22), the encoding of S0, the sequence of the encodings of E0 to En and the end error tag (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.
Example of Binary Encoding As an a simple example of the binary encoding, we can consider the &OM; object application ( times , application ( plus , x , y ) , application ( plus , x , z ) ) whose &exml; encoding is ]]> It is binary encoded as the sequence of bytes given in .
A Simple example of the &OM; binary encoding. Hex Meaning Hex Meaning 58begin object tag 10begin application tag 2 version 2.0 (major) 48symbol tag (with share bit on) 0 version 2.0 (minor) 01reference to second symbol seen (arith1:plus) 10begin application tag45variable tag (with share bit on) 08symbol tag00reference to first variable seen (x) 06cd length 05variable tag 05name length01name length 61a (cd name begin7az (variable name) 72r .11end application tag 69i .11end application tag 74t .19end object tag 68h . 311 .) 74t (symbol name begin 69i . 6dm . 65e . 73s .) 10begin application tag 08symbol tag 06cd length 04name length 61a (cd name begin 72r . 69i . 74t . 68h . 311 .) 70p (symbol name begin 6cl . 75u . 73s .) 05variable tag 01name length 78x (name) 05variable tag 01name length 79y (variable name) 11end application tag
Sharing &OM; 2 introduced a new sharing mechanism, described below. First however we describe the original &OM; 1 mechanism.
Sharing <phrase revisionflag="added">in Objects beginning with the identifier [24]</phrase> This form of sharing is deprecated but included for backwards compatibility with &OM; 1. It 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 encoded as 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 tag [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, [31] for (short) external references, [31+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 a URI. Identifiers [30+64] and [30+64+128] are not used, since they would encode references that are shared themselves. Chains of references are redundant, and decrease both space and time efficiency, therefore they are not allowed in the &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+1th shared sub-object (one where the shared flag is set) in the current object (counted in the order they are generated in the encoding). For example Ox7E Ox01 references the second shared sub-object. shows the binary encoding of the object in above.
A binary encoding of the &OM; object from <xref linkend="fig_shared_vs_unshared"/>. Hex Meaning 58begin object tag 2 version 2.0 (major) 0 version 2.0 (minor) 10begin application tag 05variable tag 01variable length 66f (variable name) 50begin application tag (shared) 05variable tag 01variable length 66f (variable name) 50begin application tag (shared) 05variable tag 01variable length 66f (variable name) 19end object tag 05variable tag 01variable length 61a (variable name) 05variable tag 01variable length 61a (variable name) 11end application tag 1Eshort reference 00to the first shared object 11end application tag 1Eshort reference 00to the second shared object 11end application 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*2d-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 32d+29 bytes, which is more space efficient starting at depth 9. Note that in the conversion from the &exml; to the binary encoding the identifiers on the objects are not preserved. Moreover, even though the &exml; encoding allows references across objects, as in , the binary encoding does not (the binary encoding has no notion of a multi-object collection, while in the &exml; encoding this would naturally correspond to e.g. the embedding of multiple &OM; objects into a single &exml; document). 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 [30+128] {_}. Note that the application can decide to copy the value or share it among sub-terms as long as it respects the identity conditions given by the tree-nature of the &OM; objects. The implementation must take care to ensure that no variables are captured during this process (see section ), 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.
Relation to the &OM; 1 binary encoding The &OM; 2 binary encoding significantly extends the &OM; 1 binary encoding to accommodate 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 constructed so as to maximise internal sharing (if computationally feasible). Note that since sharing is done only at the encoding level, this does not alter the meaning of an &OM; object, only allows it to be represented more compactly.
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). 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. 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 are 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. 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 FMPs 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. 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 guaranteed to remain unchanged. A version number which consists of a major and minor part (see ). A status, as described in . A CD base which, when combined with the CD name, forms a unique identifier for the Content Dictionary. It may or may not refer to an actual location from which it can be retrieved. A series of one or more 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. A Formal Mathematical Property may be given an optional kind attribute. An author of a Content Dictionary may use this to indicate whether, for example, the property provides an algorithm for evaluation of the concept it is associated with. At present no fixed scheme is mandated for how this information should be encoded or used by an application. 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 XSLT_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 variants to be associated with Content Dictionaries without the Dictionaries themselves being changed. A model for signatures is given in . 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 consists of the collection of core Content Dictionaries that is designed to have the same semantic scope as the content elements of MathML 2 MathML_2003. &OM; objects built from symbols that come from Content Dictionaries in this CDGroup may be expected to be easily transformed between &OM; and MathML encodings. The detailed structure of a CDGroup is described in 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 , &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 , the arith1 Content Dictionary for basic arithmetic functions.
The Relax NG Schema for Content Dictionaries &cdrnc;
The DTD Specification of Content Dictionaries
DTD Specification of Content Dictionaries %omobjectdtd; ]]>
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 information is encoded as the content of the relevant element. 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 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 increase 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 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). CDBaseThe 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 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. 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 . Role The role of a symbol: it must be one of binder, attribution, semantic-attribution, error, application, or constant. Example 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. It may take an optional kind attribute.
Additional Information 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> &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 Dictionary Signature dictionaries have a header which specifies the type system being used and the Content Dictionary containing the symbols for which signatures are being given. Each signature takes the form of an &OM; object in an appropriate encoding. 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 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 (see ) 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 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 Relax NG 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 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 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. For an application to declare that it understands CDGroup G is exactly equivalent to, and interchangeable with, the declaration that it understands Content Dictionaries x1, x2,  …  xn, where x1,  …  xn are the members of CDGroup G.
The Specification of CDGroups CDGroups are &exml; documents, hence a valid CDGroup should be valid according to the DTDschema 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 The notion of being a valid CDGroup implies that the following requirements on the content of the elements described by the DTDschema given in are also met. CDGroup The &exml; element CDGroup is the outermost element in a CDGroup document. CDGroupName 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 is to be taken as member of the CDGroup. This element is optional. In case it is missing, the latest version is the one included in the CDGroup. For the syntactical requirements, see CDVersion in . CDURL 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 .
Content Dictionaries Reviewing Process 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 Applications that meet the requirements specified in this chapter may label themselves as OpenMath compliant. &OM; compliance is defined so as to maximize the potential for interoperability amongst &OM; applications.
Encodings 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.
The XML Encoding
Generating Valid XML All &OM; objects generated by a compliant &OM; application must validate against the Relax NG Schema given in .
Decimal versus Hexadecimal Float Representation In the &exml; encoding, floating-point numbers may be defined using either decimal or hexadecimal notation. For numerical values, plus the two infinities, the two representations may be used interchangeably since there is a one-to-one correspondence between them. The exceptional case is that of not a number (NaN) which is defined in the IEEE standard ieee754_85 to be any number whose exponent has the maximum possible value (in this case the exponent is 11 bits so the maximum value is 2047) and whose mantissa is non-zero. The standard explicitly notes the use of the 52 bits in the mantissa (and also the sign bit) to store information about how the NaN was generated in a system-specific way. Thus in some cases the exact representation of the NaN is significant. The semantics of the &OM; object <OMF dec="NaN"/> is that it represents any NaN, and a phrasebook may substitute any specific NaN value when processing it. The semantics of a NaN in hexadecimal notation however, such as <OMF hex="FFF8000000000001"/>, is that this is a specific NaN, as distinct from all others. If a phrasebook author substitutes another value for the NaN or maps all NaNs to a single object then he or she must recognise that this process is not an identity transformation.
&OM; Foreign Objects An &OM; Foreign Object may be attributed with a string indicating the format of its contents. Although this information is optional, an &OM;-compliant application which generates &OM; Foreign Objects should always include it where possible (see the discussion of MathML conversion below for an example of a situation where it is not always possible). It is recommended that, where the contents of the Foreign Object are in an &exml; dialect, the namespace xmlns of the &exml; dialect is used as the value of the encoding. For example (using the &exml; encoding): E

The base of the natural logarithms, approximately 2.71828.

]]> Where the contents of the Foreign Object is a format other than &exml;, it is recommended that its MIME type rfc2046 is used as the value of the encoding. For example (again using the &exml; encoding): \documentclass{article} \begin{document} \title{E} \maketitle The base of the natural logarithms, approximately 2.71828. \end{document} ]]> An exception to the above guidelines occurs when a MathML object is converted to &OM;. MathML also has an encoding attribute which can appear in various places and whose format is a string. Only two values are predefined, MathML-Content and MathML-Presentation, and these may appear in the resulting &OM; object despite the fact that they are not namespaces as recommended above. For example the following MathML expression: x sinx ]]> is equivalent to the &OM; expression: sinx ]]> Since in MathML the encoding attribute is in effect optional (its default value is the empty string), a convertor program may not in fact be able to provide a value for the &OM; encoding attribute. This is unfortunate but unavoidable.
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 properties 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 defined in 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.
&OM; 1 Objects Compliant &OM; 2 documents and Content Dictionary files using the reference &exml; encodings must be valid according to the specified schema, and so will use the namespaces http://www.openmath.org/OpenMath and http://www.openmath.org/OpenMathCD respectively. Similarly CD Group and Signature files will use http://www.openmath.org/OpenMathCDG and http://www.openmath.org/OpenMathCDS. Applications may also support &OM; 1. &exml;-encoded &OM; 1 documents may be in either the http://www.openmath.org/OpenMath namespace or in no-namespace (i.e., do not have any xmlns declarations). An application may accept either of these forms. Note however that &OM; documents that have a version attribute should validate against the schema for &OM; 2 (or later versions) and so should always use the &OM; namespace. &exml;-encoded &OM; 1 CD files, CD Group files and CD Signature files must be in no-namespace. An &OM; 2 application may support these files by implicitly converting the documents to their respective namespace. Apart from this change of namespace (and the addition of a version attribute on OMOBJ) the &OM; 1 documents should conform to the schema specified in this standard. The use of documents in no-namespace should be restricted to reading existing &OM; 1 files. No &OM; 2 application should generate documents in this form.
Conclusion The goal of this document is to define the &OM; 2 standard. The issues addressed by the &OM; 2 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 &metacd;
The <filename>arith1</filename> Content Dictionary File &arith1cd;
The <filename>arith1</filename> STS Signature File &arith1sts;
The <filename>MathML</filename> CDGroup &mathmlcdg;
The <filename>error</filename> Content Dictionary &errorcd;
&OM; Schema in Relax NG XML Syntax (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 compatible, 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 role 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. 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. In addition, an &OM; error object may take as its arguments non-&OM; objects wrapped in the new foreignconstructor. 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 guaranteed 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 mandates two encodings: &exml; and binary. The &exml; encoding in particular has been updated to reflect the latest development of &exml; and is now a full &exml; application. Version 2 encodings are backward compatible with version 1.1 encodings. 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 An optional attribute defining the version of the encoding can be specified for the encoded object 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. The symbolic values INF, -INF and NaN have been added to the decimal attribute of an OMF in the &exml; encoding, and guidelines on the interpretation of NaNs added to the compliance section.
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. An FMP may, optionally, have a kind attribute for use in classifying different kinds of definitions. The details of how this attribute is used are not mandated by the standard.
Bibliography IEEE IEEE and The Open Group Std 1003.1-2001 (Open Group Technical Standard, Issue 6), Standard for Information Technology-Portable Operating System Interface (POSIX) Std 1003.1, 2003 Edition, The Open Group Base Specifications Issue 6 2001 2003 http://www.unix.org/version3/ieee_std.html IETF RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax August 1998 http://www.ietf.org/rfc/rfc2396.txt World Wide Web Consortium XML Schema Part 1: Structures & Part 2: Datatypes May 2001 http://www.w3.org/TR/xmlschema-1 http://www.w3.org/TR/xmlschema-2 OASIS Committee Specification RELAX NG Compact Syntax November 2002 OASIS Committee Specification RELAX NG Specification December 2001 http://www.oasis-open.org/committees/relax-ng/spec-20011203.html 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 Lecture Bibliomiscs in Computer Science 429 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 Conference 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 Franz Baader and Klaus U. Schulz Applied Logic Proceedings of First International Workshop "Frontiers of Combining Systems" (FroCoS'96) 1996 Kluwer Stephen Buswell Stephane Dalmas James Davenport Nick Howgrave-Graham Emerging Technologies &OM; WP 1.2 Deliverable 1998 John A. Abbott André van Leeuwen Andreas 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 Computer 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.0</phrase> Addison-Wesley 2003 ISBN 0-321-18578-1 Online edition available from http://www.unicode.org/versions/Unicode4.0.0 ieee IEEE Standard for binary Floating-Point Arithmetic ANSI/IEEE Standard 754 1985 http://standards.ieee.org/reading/ieee/std_public/description/busarch/754-1985_desc.html 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: Format of Internet Message Bodies RFC: 2045 November 1996 http://www.mhonarc.org/~ehood/MIME/2045/rfc2045.html N. Borenstein N Freed MIME (Multipurpose Internet Mail Extensions) Part Two: Media Types RFC: 2046 November 1996 http://www.mhonarc.org/~ehood/MIME/2046/rfc2046.html 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 January 1999 http://www.w3.org/TR/REC-xml-names 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 http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=17505 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 World Wide Web Consortium Extensible Markup Language (XML) 1.1. W3C Recommendation REC-xml11-20040204 February 2004 http://www.w3.org/TR/2004/REC-xml11-20040204/ &OM; Consortium The &OM; Standard &OM; Deliverable 1.3.1a 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/ http://www.openmath.org/standard/sts.pdf 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 http://www.openmath.org/standard/ecc.pdf 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 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 February 2001 http://www.w3.org/TR/REC-MathML2/ World Wide Web Consortium Mathematical Markup Language (MathML) 2.0 Specification (Second Edition) October 2003 http://www.w3.org/TR/MathML2/ CtCoqmath INRIA
Sophia Antipolis
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 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 Intelligent 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 W3C Recommendation REC-DOM-Level-1-19981001 October 1998 http://www.w3.org/TR/REC-DOM-Level-1/ World Wide Web Consortium OWL Web Ontology Language Overview February 2004 http://www.w3.org/TR/2004/REC-owl-features-20040210/ World Wide Web Consortium Resource Description Framework (RDF): Concepts and Abstract Syntax February 2004 http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ World Wide Web Consortium Extensible Stylesheet Language (XSL) Specification October 2001 http://www.w3.org/TR/xsl/ World Wide Web Consortium XSL Transformations (XSLT) November 1999 http://www.w3.org/TR/xslt/ 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