The text formatting language HTML and its interface, the web browser, are familiar tools to many scientists. HTML was originally designed to display plain text on a computer screen, with markup 'tags' (formally known as elements) primarily supporting the formatting of textual objects (paragraphs, tables, headings, lists, etc.). Inter-document linking is achieved by hyperlinking (via the anchor, applet, embed or object elements) which also allows content in the form of bitmapped images (normally .gif, .jpg and .png), and traditional chemical data files to be transcluded.

HTML documents rely significantly on human processing for chemical content interpretation and error detection, since the language syntax is too flexible to be reliably interpreted by machines, especially the early versions of hypertext markup language (1.0, 2.0, 3.2, 4.0 and their commonly used non-standard derivatives, collectively referred to in this article as 'HTML'). No mechanisms exist in these versions of HTML to allow them to be validated with respect to the document integrity and there is very little markup of context (to indicate the meaning and relevance of each information component). Non-textual data normally requires the use of browser 'plugins' (small, platform-specific helper programs) or Java 'applets' (non-platform-specific programs that run on a 'virtual machine' on top of the web browser). As an example, a present day online chemical paper might consist of HTML text, static bit-map images and diagrams and molecular structures transcluded from an external 'legacy', data file, e.g. MDL Molfile or the Brookhaven Protein Databank (PDB) formats, which are intended to be visualised using an appropriate plugin (supplementary Fig. 1). The syntax of these external files is heavily implied and requires specialist knowledge to interpret. This severely limits the re-usability of the rapidly growing amount of high-quality chemical information available on web pages and a significant amount of time and, more importantly, information can be wasted converting between these files.

Since HTML was not originally designed to support non-textual data, there is no built in mechanism to allow molecular structures to be shared between a plugin and the parent document. As a result, the external data files become isolated from the text and from each other. This reduces inter-operability and makes it significantly harder to identify information within these files, while at the same time retaining their context. Browsing through HTML pages using a conventional search engine requires significant human interaction in order to identity useful chemical information. If the information was labelled by context, far more could be handled automatically, e.g. filtering and ignoring identical data from different sources. The main problems with existing HTML/file transclusion solutions include: (i) the lack of a clear separation of content from the formatting or presentation in the HTML document. For example, HTML defines a superscript element - [sup] - which can ambiguously be used to either define a cited reference or footnote, or in a molecular formula as an isotope, charge, unpaired electron, oxidation state, state symmetry or multiplicity. Or it can be used simply for stylistic effect. Similarly, chemical content and meaning can often be expressed using Greek characters, which in HTML are considered a stylistic attribute best expressed using a formal stylesheet declaration. This means that a molecular formula or constitution marked up using HTML is effectively lost as far as machine readability is concerned. (ii) the use of legacy formats with implied syntax and the resulting multiplicity of standards. A single, human-readable format is required, combining both textual and non-textual information within a single document. Additional considerations include: scalability, validation, platform independence (particularly relevant online), portability and flexibility. With the present cost of computer hardware and improvements in communication bandwidths, file size is significantly less of a concern, but many legacy formats were designed, in the era of expensive computer memory, to be extremely terse and, therefore, have a large amount of implied, and hence essentially unavailable, syntax.

In February 1998, the World Wide Web Consortium (W3C) published their recommendations for extensible markup language (XML) as a successor to HTML. XML is not a markup language in its own right, instead it is a series of rules and conventions defining how to build discipline-specific markup languages (a so-called 'meta-markup language'). XML is designed to allow the description of any structured data by the use of a user-defined set of tags, or elements in XML nomenclature, and support precise declarations of the content of a document and context using explicit syntax. A defined set of elements is called an XML language and these languages are far more flexible than HTML, since they can be tuned to a particular subject.

All XML-compliant languages use the same syntax and can be manipulated using any XML-compliant tools or applications. Information marked up using different languages can be easily combined into a single document and manipulated at the same time. These different languages, e.g. MathML, CML, SVG (scalable vector graphics), are identified within the document by the use of discrete namespaces (vide infra) and are often concatenated using XHTML (HTML following XML rules). An online XML article might consist of XHTML text combined with e.g. SVG diagrams and CML structures or spectra.

Unlike HTML, XML elements do not describe the formatting of a document and, hence, a generic browser can only, by default, display the document and element tree structure. Instead, the parser built into the browser uses an external stylesheet, which contains formatting instructions for each element in the XML source. This stylesheet is supplied by either the author or the reader and effectively maps the contents of each element to an output. This would normally be an XHTML page or some other text file but can also be to e.g. an Acrobat file.

The older cascading stylesheets (CSS) is a standard commonly used for formatting HTML, and provides a mechanism for defining the formatting and layout instructions for an entire HTML document collection in a single stylesheet file. CSS works by allowing the author to redefine how an HTML tag will be presented, e.g. [h1] can be defined using a CSS stylesheet as meaning present this heading with, for example, size 11 font and red colour. This is useful when the style of an entire document collection needs to be changed, since it only requires editing one stylesheet rather than each HTML document. Much more sophisticated stylesheets can be written using a powerful formatting, searching and scripting language XSL (extensible stylesheet language). In this article, we will describe the design and implementation of a range of chemically useful stylesheets.

Since any number of stylesheets can be applied to a single XML document, it can be displayed in a wide variety of ways (Fig. 1). The searching and scripting capabilities of XSL mean that element(s) can be picked out and displayed and/or manipulated according to their contents. Other information can be ignored, if necessary, making data searches from large XML documents trivial. An article containing a mixture of text and chemical information can be scanned, e.g. for spectra or numerical information, using such a stylesheet and this information transformed and displayed using, for example, a suitable applet. Alternatively, a different stylesheet might be used to identify molecular structures and potentially calculate their properties.

Stylesheet transformations are performed using software called an XML/XSL parser, which may be a dedicated program or a component built into an existing web browser (as with Internet Explorer version 5 and higher). Stylesheet selections can be defined by a URL (uniform resource locator) from within the document or selected from a local collection using the parser. This allows readers to use their own stylesheets which invoke their own preferences or resources available to them. This flexibility makes stylesheets very powerful and is exemplified by the ChiMeraL demonstration, where sample CML data files containing molecules and spectra can be transformed with a range of XSL stylesheets.

The use of a unified XML format reduces the time wasted in processing legacy files and avoids the risk of serious information loss due to poor semantics. This 'plug-compatible' XML approach guarantees a document to be searchable, sortable, mergeable, and printable with minimal extra cost. Ideally, all future document and publishing systems will use XML languages.

The definition of CML version 1.0 was developed to carry molecules, crystallographic data and reactions using an XML language and, for the first time, offers a universal, platform- and application-independent format for storing and exchanging chemical information. As the first generation of CML, it outlines a variety of general purpose 'data-holder' elements and a smaller number of more specifically chemical elements (e.g. [molecule], [reaction], [crystal]) used to indicate chemical 'objects'. For example, a [molecule] will contain a [list] of [atom]s, which in turn have three [float]s specifying Cartesian coordinates for each atom.

This framework is flexible but leaves many areas open for later evolution. In particular, CML provides no default conventions for labelling data elements and puts few restrictions on element ordering. This is intentional, as CML is designed to be generic and contains minimal preconceptions as to the type of chemical information that will be stored using it. Standardisation and conventions are the concern of the community and will be co-ordinated by publications and projects such as this one.

In the work presented in this article, we have developed rigorous markup procedures for the structures of small- and medium-sized molecules. We have included spectral information using an additional element, [spectrum], which is not part of CML 1.0. Exploratory work has been carried out into [reaction] markup and data linking within a CML/XHTML document. Simply defining such procedures is of limited use and a variety of XSL template 'fragments' have been developed. These allow molecules, spectra and reactions to be displayed using a variety of existing Java applets and can be used for the construction of stylesheets able to format mixed XML documents containing chemical information. These stylesheet fragments and examples are offered as online resources in the form of a fully operational demonstration of CML parsing within a web browser, known as ChiMeraL. This is available via the supplementary information associated with this article, and in more extended form at http://www.xml-cml.org/chimeral/.

The most important rules of XML syntax are listed below. A document that follows these is described as 'well formed'.

1. All tags must be closed to form an element, e.g. [formula]C8 H10 N4 O2[/formula], and must be correctly nested. This is in contrast to HTML, where incorrect nesting is normally ignored.
2. 'Empty' elements with no children may be written using the shorthand [link/] = [link][/link]
3. All attribute values must be within quotes ("") e.g. [string title="CAS"] (in this article, we use the convention [@title = an attribute named 'title')
4. Element and attribute names are case sensitive and are normally written using lower case to distinguish them from non-XML-compliant HTML.
5. Code comments are of the form [!-- comment --] and are ignored by the parser.

An example of a short XML document is given in which contains both XHTML and CML marked up information. Those familiar with HTML will recognise the syntax but will find the element names unfamiliar. Notice how information can be stored both as an element child and also as the value of an attribute.

The structure of this document is best visualised as a branched tree, similar to the directory structure on a hard-drive. It has a single 'root' (in this case [document]) with a number of sub-elements ([p] and [cml], ignoring the prefix) and sub-sub-elements, defining the logical structure of the document. Each branch in the tree may contain information either as a text child or as attribute values. Each component of information is therefore uniquely described by a list of its ancestors and this provides a convenient method for stylesheets to navigate the XML tree (called pattern matching).

From , we can see that this document contains a chemical formula, CAS number, molecular weight, melting point and three alternate names for caffeine. In addition, there are two processing instruction tags (lines 1 and 2) that use the syntax [?tag_name_here?]. The first, [?xml version="1.0"?] indicates that the document has been written to follow XML rules. The second, [?xml-stylesheet .. ?] gives the URL of the default stylesheet. Unless given overriding instructions (e.g. by a reader who wishes to use their own stylesheet) the parser will automatically obtain this stylesheet and use it to transform (format) the XML document. This transformation can be carried out locally (i.e. using the web browser), remotely on a web server or using a combination of the two.

When writing an XML document, it is usual to collect data of similar types and organise this into a suitably logical structure. For example, the formula for caffeine is stored in branch \document\cml\molecule\formula. shows a simplified CML document tree.

Data holders are generic elements designed to contain the standard data types required by chemistry. These include strings, integers, floating point numbers and a series of array and matrix elements. They do not usually contain sub-elements, only text, and their context is described by the values of their attribute (particularly @title); e.g. [float title="melting point" units="degC"]238.2[/float] contains the melting point data 238.2 degrees C.

The values of these attributes are not defined in the DTD or schema so any data can be contained simply by choosing them appropriately. This avoids the need to define large numbers of specific elements within CML. To include a melting point, an additional element could be defined, [meltPoint], but this would not be recognised and formatted by a generic CML stylesheet. It is possible to build new stylesheets including the new element, but this reduces their compatibility. A better approach is to use the existing [float] and add @title="melting point" to give it a label. A stylesheet can then display this as 'melting point: ...' without having to recognise the attribute value directly ().

Chemical components represent objects of chemical interest, such as molecules, atoms, bonds, etc. and these elements normally contain a number of data holders. CML 1.0 defined the basic components for molecular structure and crystallographic markup, but the extension of CML to other areas of chemistry requires the addition of additional elements. The number of these should be minimised as much as possible and new elements must be described as an extension to CML with their own DTD or schema. In most cases, each chemical component should also be supplied with a unique identity, @id. A molecule containing chemical property information is shown in In order to simplify the figures, processor instructions, [document] tags and namespace declarations have not been included in the following examples.

The CML block in contains only trivial CML property information. A more complex example might contain molecular structures (2D and 3D), spectra (IR, UV/vis, NMR or MS) and possibly a reaction scheme. Techniques for marking up and displaying these more complex components are covered later, but to illustrate how an XSL stylesheet is written, a simple example will be explained in full ().

XSL follows XML rules and therefore requires a namespace declaration in the same way as any other XML document. Internet Explorer recognises 'http://www.w3.org/tr/WD-xsl' as an XSL namespace declaration and the ability to understand this language is built into the parser. XSL uses a limited set of 'commands' (approximately 15) which can be recognised by their xsl: prefix. All text and all elements not part of the XSL namespace are passed directly to the output (in this case, the browser). Two exceptions are: comments ([!-- comment --]), which the parser ignores, and the contents of the [xsl:eval] element, which are used for scripting and calculations within the stylesheet.

The stylesheet contains a series of [xsl:template]s which in turn consist of a mixture of XSL commands and template text/tags. At the simplest level, each template refers to the particular element in the XML source that matches the value of the template @match. Therefore, [xsl:template match="molecule"] marks the start of a template for the [molecule] element. The parser navigates iteratively through the XML document tree, starting at the document root and selecting matching templates at each branching. Navigation through the tree is controlled by the [xsl:apply-templates select=" value and branches can be parsed or ignored as required. Matching and selection of elements is handled by a powerful pattern matching language which refers to the document tree using a Unix-like syntax (a full description of pattern matching can be found on the W3C and MSDN web-sites).

The example shown here () contains three templates. The first template (@match="/" - the document root) starts the parsing process at the first level element in the document ([cml] in this example). A similar template is required for all XSL stylesheets. The second template (@match="cml") builds the start of a skeleton XHTML page and put the values of @title and @id within the [title] tags. [xsl:apply-templates select="molecule"/] instructs the parser to select child element(s) [molecule] and to find a template for it. Once that branch has been completed, the parser returns to the second template and completes the XHTML page: [html]]head[]title[Furan,tetrahydro-mol_thf_1[/title][/head][body][!--results of transforming [molecule] here--[/body][/html]. The third template recognises the chemical properties within [molecule] and formats their values to a simple XHTML table. Note how the alternate names are handled; the contents of [xsl:for-each select="list[@title='alternate names']/string[@title='name']"] is repeated each time the pattern value of @select matches an element in the XML document. The output from the complete stylesheet is shown in .

More complex chemical data cannot be easily displayed using text and a more sophisticated solution is required. A hypothetical CML-aware parser might have this functionality built in, being able to recognise chemical components and display them appropriately. Using existing parsers, the problem is analogous to that encountered with normal HTML pages. Browser plugins and Java applets are used to provide additional display functionality and a wide range of these add-on programs have been developed, some of them very advanced. An efficient solution is to use a combination of stylesheets and applets to display the CML components contained within a mixed XML document. Using existing software is preferable as this allows faster development of a working application and is in the spirit of XML's reusability.

Both plugins and Java applets are primarily intended to read external data files, normally in a legacy format (.mol, .pdb, .dx, etc.) and to embed a graphical display of this data within an HTML page (Fig. 9). In both cases, special tags are required: [embed name="Plugin" src=ldquo;datafile.mol" width="300" height="300"] and lang;applet name="Applet" code="applet.class" width="300" height="300"].

CML is normally embedded into a mixed XML document, and therefore it is not easily accessible by a plugin. Applets are more flexible and can receive data in a wider variety of ways, which makes them significantly more useful for XML display. Stylesheets can be written to recognise CML components and build appropriate [applet] tags to display them. Since all applets are designed to read legacy formats, the data within the components must also be transformed (called a CML to legacy conversion). The transformed data string can then be passed to the applet in two different ways (depending on which type the applet supports). The easiest technique is to place the string within the [param] declaration for an applet.

An alternative technique is to place the transformed string within a hidden [input] element. These are normally used within the (X)HTML [form] element and cannot be seen by the reader. Here, it becomes a convenient holder for the transformed string and JavaScript is then used to call a public function on the applet and pass it the contents of the [input] element. The JavaScript can be triggered by a button or when the page has completely loaded into the browser. This is less direct than using [param]s, but allows more powerful interactions between the page and the applet, since other functions can also be made accessible to JavaScript. This approach is used for the JME applet described in the next section.

A selection of applets have been chosen depending on their suitability for XML integration. It is desirable that the applets be small (faster downloads), flexible, easy to use and open source, since this allows changes to be made to the applet code if required. XSL 'template fragments' have been built for each of these applets and for several common CML to legacy conversions (available from http://www.xml-cml.org/chimeral). By combining these stylesheets with applets and the schema, complete CML applications can be built ().

The Molfile uses a strict new-line delimited structure with a heavily implied syntax. As a result, it is very sensitive to the amount of white (empty) space on each line. This can cause serious problems when converting to and from this format from CML. The format has the advantage of being extremely terse, relevant when it was developed, but much less so now. Other file formats tend to use rather similar syntaxes (e.g. the XYZ format lacks the additional atom columns and the bond data).

CML molecular structures are reminiscent of the Molfile format, but with the data being fully marked up and explicitly defined. Implied syntax is reduced to a minimum and conventions are declared and not assumed. The aim is to make each chemical component (coordinate, atom, bond, etc.) completely separable from the rest of the document, allowing components to be easily added or removed without destroying the document tree. Since an XML document might contain a very large number of molecules (examples containing over 600 molecules have been built), each component requires a unique @id. A large collection of Molfile files can be easily converted to CML and then concatenated to a single XML document. A stylesheet can then pick out a single molecule and display its structure by searching against @id.

As with the Molfile, lists of atoms and bonds are used. Atoms contain either 3 (x3, y3, z3) or 2 (x2, y2) Cartesian coordinates, an atom type and an 'atomID' (Fig. 11). This is a non-unique label referenced by the 'atomRef' values of the bond and are not the same as the atom's unique @id (hence [integer builtin="atomRef"]1[/integer] refers to an atom of [integer builtin="atomId"]1[/integer] not @id="1"). The same applies to 'bondId'. While not optimal, this greatly eases the conversion of CML to and from legacy formats. Coordinate units are no longer implied and, since this molecule was converted from a Molfile file, the bond order convention is 'MDL'.

Additional information (formula, CAS number) is not extracted from the Molfile file, since, although such information might be supplied using comments, it is not automatically identifiable. In our case, it was acquired from various online databases such as ChemFinder. The author may decide to include any information they wish in this way, simply by adding additional elements at appropriate places in the CML document.

The JME (Java Molecular Editor) applet is a simple and small (31K) 2D editor, incorporating a SMILES calculator (a widely used standard for producing text descriptions of molecular structure). Rather than including filters for legacy file formats at the expense of increasing the applet size, JME reads a simple coordinate and bond string. The syntax used is unique to JME and can be a problem for XHTML solutions since there is no way to dynamically calculate it from a standard data file. Using CML, this problem is solved with a trivial stylesheet transformation (Fig. 12). This makes the applet ideally suited for our purposes (supplementary Fig. 4).

The string read by JME uses the syntax n_atoms n_bonds {atomic_symbol x_coord y_coord}per atom {atom1 atom2 bond_order}per bond.

This string is built by the stylesheet and held in the hidden [input] tag labelled with the name 'jmeoutput'. A Java Script 'onLoad' function is also added to the XHTML [body] tag and this is called when the page has been completely loaded into the browser. The script takes the content of 'jmeoutput' and passes it to a public 'readMolecule' function in the applet, which proceeds to display it. Stereoisomers and simple reactions can also be displayed using JME, but have not yet been incorporated into ChiMeraL.

Some additional XSL commands should be explained at this point: [xsl:element] and [xsl:attribute] create new XHTML/XML tags in the output and are used as an alternative to writing the tags directly. For example, [xsl:element name="input"][xsl:attribute name="name"]jmeoutput[/xsl:attribute][/xsl:element] is equivalent to [input name="jmeoutput"/]. They are used to build complex tags that might otherwise cause the stylesheet to become invalid XML.

The [xsl:eval]formatIndex(childNumber(this), "1")[/xsl:eval] command uses Internet Explorer-specific functions to calculate the position of an element with respect to its siblings and return this as a formatted number. It is used in almost all the stylesheet fragments, normally to count the total numbers of atoms and bonds in the molecule. Non-Internet Explorer stylesheets would use different functions depending on the parser they are designed for.

JMol is a stand-alone Java application (not an applet) being developed by the Open Science project. It is designed to read and display molecules using a variety of legacy formats. Its functionality is similar to the Chime plugin, but it is open source and platform independent. An experimental applet has been released and this has been adapted for use in this project. A stylesheet converts the CML [molecule] to a %-delimited .xyz string, which is then stored and transferred to the applet in a manner similar to JME. The '%' delimiters must be added because the converted string cannot replicate the line breaks required in the .xyz format (similar to Molfile). The applet has been slightly rewritten to recognise % as equivalent to a new line.

Problems also occur with white space; both the .xyz and Molfile formats require strict space handling to ensure their data remains in straight columns. Both formats use right aligned text, in contrast to XML/HTML standard left alignment.

In both cases, the stylesheet (Fig. 13) must check each coordinate and add a varying amount of white space depending on its size and sign (+ or -). As with JME, the converted string is contained within a named [INPUT] tag and then passed by onLoad="document.JMolApplet.setModelToRenderFromXYZString(jmoloutput.value,'T')"to the applet (supplementary Fig. 5).

Marvin is a commercial applet produced by Chemaxon and is free to academic users. It is a wire frame 3D viewer able to accept Molfile data using external files, as a [param] or via JavaScript. The applet is configurable and includes a 2D editing function. SDA (Structure Drawing Applet) is a freeware editor developed by ACD Labs and also accepts Molfile data via [param] elements (supplementary Fig. 6).

The JCAMP-DX format (supplementary Fig. 7) defines a series of conventions for the storage and exchange of spectral data. Files using this format are written using ASCII text and contain a series of labelled data records (LDR). Each LDR is delimited by a new line and a double hash: ##LDRname = value.

While having a much simpler structure than XML, these LDRs can be considered as a form of markup with the LDR name (data label) being equivalent to the element name. This is unsurprising, since the two formats share a number of important design criteria, such as extensibility, human/machine readability, flexibility and platform independency. Approximately 25 reserved data labels were originally defined for JCAMP-DX. These are intended to contain:

• (i) Metadata - (e.g. ##ORIGIN, ##OWNER, ##DATE).
• (ii) Header information - (e.g. ##TITLE, ##DATA TYPE, ##BLOCKS, ##END).
• (iii) Required spectral parameters - (e.g. ##XUNITS, ##FIRSTX, ##MAXX).
• (iv) Optional spectral parameters - (e.g. ##RESOLUTION, ##DELTAX).
• (v) Spectral data - (e.g. ##XYDATA, ##XYPOINTS, ##PEAK TABLE, ##PEAK ASSIGNMENTS).
• (v) Equipment - (e.g. ##INSTRUMENT PARAMETERS).
• (vi) Sample information - (e.g. ##CAS NAME, ##MOLFORM, ##MP).

Important LDRs are ##DATA TYPE, which describes the type of spectrum, and ##PEAK TABLE, which contains the data points. A variable list label following ##PEAK TABLE describes how the data is tabulated. Data is grouped into XY or XYZ/XYM coordinates and separated by commas within the group, while groups are separated by semicolons or spaces. Any additional white space is ignored. Common variable lists are:

(XY..XY): grouped XY pairs.

23,102 19,89 15,87 ..

(XYZ..XYZ) or (XYM): grouped XYZ or XYM (can be used to give multiplicity).

23,102,S 19,89,S 15,87,D ..

[X++(Y..Y)]: more complex. Each line starts with an X value, then a series of Y values at equal X spacings, so

12 52 48 46 43 42

22 43 38 36 35 31

is equivalent to

12,52 14,48 16,46 18,43 20,42 22,43 24,38 26,36 28,35 30,31

JCAMP-DX also allows the use of user-defined data labels. These are distinguished by a $ prefix and are specific to a particular instrument, location, user, etc. This effectively means that, although JCAMP is an extensible language, it does not include any procedure for systematically describing the meaning of an LDR. This seriously limits the use of user-defined data labels beyond the original author. A number of JCAMP 'sub-languages' have been defined in an attempt to solve this issue. These contain lists of LDRs intended for particular areas of spectroscopy (e.g. UV/vis, ¹H NMR, MS). Particularly interesting is JCAMP-CS, which allows the addition of limited structural information. These JCAMP files are split into a number of separate blocks, each containing a different type of information (e.g. molecular structure, peak table and peak assignments). This information can be extracted and marked up as CML, and a JCAMP-CS to CML converter has been written for this purpose.

Since a well established (if non-XML-based) markup language already exists, many technical difficulties have already been solved. Rather than develop new conventions for spectral markup, we have chosen to incorporate those used by JCAMP. It is expected that most users will wish to convert CML to and from JCAMP, so this needs to be as easy as possible. Once converted, spectra can incorporated into XML documents and displayed using techniques similar to those used for molecules.

Comparing JCAMP with illustrates the approach used. A new element, [spectrum], is defined as an extension to CML, and this is given a new namespace, chimeral. The contents of the JCAMP labelled data records are then mapped to a [string] or [float] with an appropriate @title value. Reserved LDRs (##TITLE, ##XUNIT, etc.) are directly recognised and given lower case values to comply with XML conventions. User-defined or unrecognised LDRs can either be ignored or, more correctly, given @title="LDRname". This avoids any information loss on converting JCAMP to CML.

The delimiters between data groups and between data within a group are only loosely defined in the JCAMP specifications. As a result, the syntax used for ##XYDATA and ##PEAKTABLE is very variable. In particular, while the [X++(Y..Y)] convention is common, it can be confusing for the non-specialist and is difficult to store using XML elements. It is suggested that CML spectra should only use the (XY..XY) or (XYM)/(XYZ) conventions and each pair or triplet be marked up using [coordinate2] and [coordinate3], respectively. Data within these elements is separated by the use of a comma and a white space (', '). More complex conventions are deconvoluted during the JCAMP to CML conversion process, e.g. (X++(Y..Y)] is expanded to (XY..XY).

Although a large number of LDRs have been defined, we have chosen to include only a small number of generic ones here. If an author wishes to use additional LDRs, these need to be included into the converter and stylesheets.

JSpec is a small open source applet designed to display JCAMP and SPC spectra files. It also incorporates a number of useful features, including zooming, peak finding and integration.

The stylesheet (Fig. 16) is similar to that used for the Marvin applet. CML is converted to a normalised JCAMP text string and incorporated into the applet's [param] declaration. Line delimitation is not required, since JCAMP already has a ## separator, but the applet was slightly adapted to accept comma-separated ##PEAKTABLE and ##XYDATA groups (supplementary Fig. 8).

Chemistry, in common with disciplines such as mathematics, conveys information through formal notation (often machine parsable) and more general graphical objects. In chemistry, these include full and dotted lines, straight and curly arrows with various types of arrowheads, links, braces, containers, specialised glyphs and pictorial objects (e.g. for surfaces, solids, etc.). Chemical schemes and diagrams are common and often consist of a mixture of graphics objects and formal notation. These enable great creativity of expression and several editing tools pay great attention to providing these. They are therefore difficult to capture accurately for machine processing using a markup language. The only current method, line art or pixel maps, loses much of the machine-readable semantics.

XML provides a very powerful graphics language, scalable vector graphics (SVG). Most web-based images use bitmapped formats (.gif, .jpg, .png), which use a grid of coloured pixels to form the picture. In contrast, vector images use Cartesian descriptions of drawing objects (lines, polygons, fills, text) and overlays them onto a blank canvas. Vector formats are most efficient for simple line images and diagrams, where the files they produce will be significantly smaller than the equivalent bitmap. Since the drawing objects are described mathematically, vector images can also be zoomed and resized without pixellating. SVG uses a range of drawing 'primitives' (line, circle, path, etc. with fill, stroke, pattern, etc.) as elements. Being XML, it allows these to contain attributes and other element children, and SVG specifically anticipates that elements from other namespaces will be interspersed with its own information.

The natural use of SVG is for transmission of line art and other semantically rich graphics (2D only) over the web. For example, most of the diagrams in this manuscript have been created directly in SVG and can be viewed with widely available tools. SVG allows local and global rescaling, extraction of sub-components, and searches for text strings. Filters allowing files to be exported as SVG are available for Corel Draw and Adobe Illustrator, and Adobe has released an SVG plugin for Internet Explorer and Netscape Navigator. SVG can also be exported to various outputs, for example Acrobat or Postscript files.

A common use of graphics is to display instrumental output, such as spectra. SVG is a natural medium for this as the data are not corrupted and accurate values can be extracted from the spectrum if required. Moreover, the spectrum can have XML-based links to other elements such as molecules (e.g. in a chromatogram) or atoms (as in molecular spectra).

We can therefore confidently use SVG as a semantically rich tool to co-exist with CML. A typical example is a scheme with several molecules, linked with lines, and surrounded by containers; this could denote reactions, interrelationships, systematisations, etc. The basic framework consists of an SVG element which contains [cml:molecule] elements or, even better, links to [cml:molecule] elements. The graphic elements can contain metadata stating their function (e.g. a 'curly arrow' denotes a 2-electron transfer from its tail to head). If the chemical community can converge on conventions for such metadata, it would allow searches of the documents for constructs such as that in . This portrays the conformational interconversion of molecule 1 to molecule 2 at specific points in the scheme, using a curved line to link them.

CML containing 2- or 3D coordinates can be transformed to SVG with XSLT stylesheets. Since bonds contain references to atoms (atomRefs), it is possible to evaluate where the bonds should be drawn. Atom properties (e.g. calculated charge) can be simulated by spheres or other primitives, so XML/SVG-aware browsers already contain components for a simple molecular renderer.

The examples given in the supplementary materials (supplementary Fig. 9) were produced from CML using the XT parser. SVG promises to be an excellent alternative to applets for the display of static molecules, reactions and spectra.

A reaction is considered as a series of molecular species; potentially including reactants, products, reagents, intermediates, transition states, etc. These species are then grouped into reaction steps with suitable information given at each step such as reaction conditions, yield, reaction name. If the structure of each species is expressed as a CML [molecule] and supplied with a unique @id value, then a reaction step need only contain references to the @id of each species (via [@href="idname"]) and need not contain the entire molecule. This keeps the CML succinct, enhancing human readability. It also enhances the reusability of chemical components; a library of reactions using the same reactive species needs only contain one copy of its structure. An example of a simple CML reaction is given in with the molecular structures omitted. A full description of our reaction markup can be found in the supplementary information.

The attribute names @id and @href are those chosen as linkers for CML. Other languages might use different attributes and the parser needs a definition of which these are. IE uses three data type declarations in the schema for this purpose. An attribute declared as dt:type="id" contains an element's unique identity, dt:type="idref" contains a reference and dt:type="idrefs" may contain one or more references (space separated). The parser is required to ensure all identities contain unique strings and that all references refer to an existing identity.

Formatting objects (FO) is a sub-language of XSL, intended to describe the layout of document components on a printed page. It comprises formatting elements rather similar in concept to XHTML but describing exact positions and font sizes in contrast to relative positioning in XHTML. FOP is a Java application being developed by Apache. When it is combined with a Java XML/XSL parser (e.g. Xalan), it acts as a formatting object parser and can convert an FO file to an Adobe Acrobat .pdf file. Acrobat is a very widely used for exchanging 'ready for print' electronic documents and, being a read-only format, has important legal implications.

Using multiple stylesheets, an XML document can be transformed for browser display or converted to a FO file for printing. Since the stylesheets can optimise the document for each purpose, the results are far superior to printing directly from the browser. A printable version of this article was produced in this way. It is expected that further converters will become available as this technology matures.

Journals and books are currently created for humans to read. Some contain machine-readable supplementary material, but the formats are not usually standardised. Articles in XML/CML have the potential to be entirely machine-processible, which means it would be easy to extract all the [cml:molecule] elements in an article or, indeed, in an entire book, journal, journal collection or publisher's output.

The reader can then ask sophisticated questions of this data, such as: what molecules contain a given functional group? Where do molecules and their spectra co-occur? Identify all molecules which are described as taking part in reactions.

Note that XML/CML allows flexible queries, so that the author of the article(s) need not necessarily anticipate the use that the publication will be put to. For example, given the relative cheapness of evaluating molecular wavefunctions, the orbitals of all molecules specified by criteria such as size could be computed and, from the resulting XML output, those with given energies or properties extracted. Similarly, compounds not in the user's database could be listed for potential synthesis; in time the synthesis could be automatic!

This article is the first with a chemical theme to be expressed completely in XML, which we use here as one model for the future development of chemistry books and journals and which could enable data checking at authorship time, extensive crosslinking of information and normalisation of existing information.

M. W. would like to thank the Chemical Structure Association (CSA) for the award of a bursary and an ExemplarChem prize.