The MathDox standard combines several different XML-based languages into one new format. Each language is used in the field where its strengths are. The combination of these strengths forms the MathDox specification. MathDox also offers the use of web-services. See section Web-services for more details. The parts of MathDox are:

Since all these parts work together, it is quite important for an author to know at least a bit about each of these XML languages. The functionality of these languages within MathDox will now be briefly discussed.

DocBook is used as a structural format for MathDox. DocBook, standardized by OASIS, is both an open standard and XML-based. It offers the document markup for MathDox and is therefore responsible for the structure of the text in a MathDox document, such as paragraphs, enumerations, tables and more. MathDox is an extension of DocBook version 5.0. Existing DocBook tools also help translating MathDox documents to LaTeX, PDF, HTML or other formats. Interactivity is, however, not or only partially supported in LaTeX or PDF. Documentation and tutorials about DocBook can be found at docbook.org and "DocBook The Definitive Guide".

Ambiguity is undesired in any interaction with a user, especially in mathematics. That is why a non-ambiguous representation of the mathematics is needed. But it is not just the user who needs to be able to understand the mathematics, the computer needs to understand it also. In most cases the user might still be able to grasp the meaning from the loosely defined context, but computer software will have a much bigger problem in this respect. LaTeX and MathML presentation are often used formats to represent mathematics, but these formats do not hold the semantic meaning of the mathematics as required. Although MathDox supports both LaTeX and MathML, it is this reason, why we prefer to use OpenMath for the representation of mathematics.

OpenMath has been developed in a series of projects that began in 1993. OpenMath gives a meaning to mathematics instead of just telling how to present the mathematics. OpenMath is also extendable with new Content Dictionaries (CDs). These CDs are library files which define new symbols and their correlation to other OpenMath entities. This makes it possible to let OpenMath evolve in new directions when needed. However in most cases an author should have enough with the standard content dictionaries. An overview of the standard OpenMath CD's and the symbols that they contain can be found at the OpenMath website .

Although OpenMath is not designed to render mathematics on the screen, it can still be used to do so. An OpenMath expression which needs to be presented on the screen will be translated by the MathDox system first into MathML and then to LaTeX. The LaTeX expressions will then be rendered onto the screen using either the browser fonts or images. This latest step is performed by JsMath, a software package specialized in rendering LaTeX expressions in web pages. This also implies that as long as the goal is just to present the mathematics, without performing any computations on the mathematics, both LaTeX and MathML can be used as well.

Computations are normally done with the use of OpenMath queries and through an OpenMath Phrasebook. OpenMath Phrasebooks translate OpenMath expressions to a Computer Algebra System specific language, send it off to the CAS, and translate the result back to OpenMath. Even though each OpenMath Phrasebook targets a specific CAS, all OpenMath Phrasebooks communicate in OpenMath, making it relatively easy for a MathDox document author to switch from one OpenMath Phrasebook to another. At the moment Mathematica, Maple , GAP , Maxima and Wiris have a (partially implemented) OpenMath Phrasebook. More information about OpenMath can be found at the OpenMath website.

The MONET project was a two-year investigation into mathematical web services funded by the European Commission. One of its goals was to construct a broker architecture for Computer Algebra Systems. The MONET project made a specification of such a broker. The MathDox Player has made an implementation of this broker and offers its use for Computer Algebra System queries.

With a MONET query it is possible to call a Computer Algebra System (CAS) from the MathDox Player. At the moment the supported CAS systems are GAP, Mathematica, Maxima and WIRIS. If the CAS is not set up or configured properly an error is given.

It is possible to indicate whether to use the “native” language of the CAS or to use OpenMath. This can be selected for both input and output. Below are some examples. Note that WIRIS does only support OpenMath mode.

It is also possible to show or update a GeoGebra applet with a MONET query.

More information on how to use of Monet quiries can be found about in the examples.

Any interactive system needs input from its users to base its reaction back to the user upon. The MathDox Player is not different, it needs user input to determine the reaction of the system. Information entered by the user can, for instance, be used for adapting explanations, answering exercises or start queries. Changing values will allow readers to observe the results of the (on-screen) calculations for different values.

For dealing with user input the MathDox system uses XForms. XForms is a next generation of HTML forms. It is XML based and can do everything HTML forms can do and more without the need for the author to know JavaScript. This makes creating interactivity within MathDox documents easier, especially because JavaScript is subjected to many different dialects on the available browsers.

XForms uses the Model-View-Controller pattern. This separates the data (the model), the presentation (the view) and the conditions and restrictions (the controller) in separate components. The set of conditions and restrictions tell web browsers how to react to entered data, effectively implementing interactivity into web pages generated by MathDox documents. Data entered in the web page will be collected into an XML document and will be sent as such to the server on a possible submit action. However the data can also be used on the web page itself without any submit.

At the moment XForms is not yet properly supported by all browsers. However XForms is included into the XHTML 2.0 specifications and work towards inclusion of XForms in web-browsers is being done. For now the used XForms in MathDox are translated by the MathDox Player into HTML forms supplemented with some JavaScript. More information about XForms can be found at http://www.w3.org/MarkUp/Forms/.

Examples of the use of XForms are given.

For specifying and fine-tuning the reactions of the MathDox system to user input, an author needs programming constructs. MathDox includes Jelly for this purpose. Jelly is a JSP-like XML-language, and has been developed as an Apache project. Jelly can be used for conditional statements, loops, variables, calls to Java objects and calls to web-services.

The main Jelly page is the Apache Jelly page. On that site is also more about the jelly:core tags (c:-tags), more about the other tags (one of which is xml) and more about JEXL, the Java Expression Language.

MathDox Documents do not need to be a single big file. There are cases in which it is advantageous to split documents into smaller parts. The resulting set of parts will increase possiblities for reuse and support maintainability. XInclude is used to include and group together XML components which are kept in different files. XInclude is a W3C standard.

It is possible to invoke web-services from MathDox documents. In this way MathDox documents can be enriched with features otherwise not implemented in the MathDox Player. One example is the use of Computer Algebra Systems. Another example from the WebALT project is to use it for natural language translation. Of course other third party services may be used in a similar way. Web-services can be called with a Jelly expression.

In this section a brief explanation is given on how the MathDox system works. The software running on the server, which makes MathDox documents accessible over the web is called the MathDox Player. Similarly to to way in which a web-server ensures that HTML documents stored on disk can be browsed using a web-browser, the MathDox Player ensures that MathDox documents can be browsed. Because web-browsers do not understand the MathDox XML format, the MathDox Player needs to do some additional work; translate the MathDox document into browser-understandable HTML.

Overview of the MathDox Player.

MathDox documents are converted to interactive web pages by means of multiple translations within the MathDox Player. Each translation handles a part of the MathDox language. For instance there is a step that translates the DocBook structure into an HTML structure, and another step will translate the XForms elements into HTML and JavaScript. An overview of all these steps is presented in Figure

Translation steps in the MathDox Player.

Translation steps in the MathDox Player.

MONET queries are handled by the MathDox Player by transforming them into Jelly code first.

For instance, when a MONET query is encountered that requests evaluation of the expression a*a=a^2 by a Computer Algebra System, then the generated Jelly code will contain the statements for calling a specific Computer Algebra System that is configured for use with the MathDox Player, and that can handle the evaluation. The actual translation of MONET into Jelly is handled by an XSLT transformation. XSLT is a language especially suited for describing transformation of one XML format into the other, and it is used extensively by the MathDox Player.

After the MONET queries have been translated into Jelly code, all Jelly code is executed. This includes also the Jelly code that was already present in the MathDox document. Next in line is the DocBook conversion. DocBook is translated into HTML, again with the use of XSLT. Also OpenMath is translated with the help of XSLT. It is first translated into MathML and next to LaTeX. Subsequently, a JavaScript program jsMath is used for the final translation to either a suitable font installed in the user's browser, or to images with the same appearance if the font is not present at the user's browser. The final step is converting XForms to HTML. This step is executed by Orbeon Forms. It translates XForms to JavaScript and HTML.

It is important to keep this chain of events in mind when one is writing a MathDox document. Communication and cooperation between different XML-based languages can sometimes be a bit difficult or even impossible. For instance Jelly is executed before XForms; for this reason it is possible to insert Jelly variables into XForms but not the other way around.