There are several constructs for aligning mathematics in LaTeX, and common packages. Here we are concerned with the large scale alignments where one or more equations are displayed in a grid, such as eqnarray, in standard LaTeX, and a suite of constructs of the amsmath packages. The arrangements are worth preserving as they often convey important information to the reader by the grouping, or by drawing attention to similarities or differences in the formula. At the same time, the individual fragments within the grid cells often have little ‘meaning’ on their own: it is subsequences of these fragments that represent the logical mathematical objects or formula. Thus, we would also like to recognize those sequences and synthesize complete formula for use in content-oriented services. We therefore have to devise an XML structure to represent this duality, as well as developing strategies for inferring and rearranging the mathematics as it was authored into the desired form.

The needed structure shares some characteristics with XMDual,
which needs to be described,
but needs to resided at the document level, containing several,
possibly numbered, equations each of which provide two views.
Additional objects, such as textual insertions (such as amsmath’s `\intertext`

),
must also be accomodated.

The following XML is used to represent these structures:

<ltx:equationgroup>

<ltx:equation>

<ltx:MathFork>

<ltx:Math>logical math here</ltx:Math>

<ltx:MathBranch>

<ltx:td><ltx:Math>cell math</ltx:Math></ltx:td>…

or

<ltx:tr><ltx:td><ltx:Math>…

</ltx:MathBranch>

</ltx:MathFork>

</ltx:equation>

<ltx:text>inter-text</ltx:text>

…more text or equations

</ltx:equationgroup>

Typically, the contents of the MathBranch will be a sequence of td, each containing an Math, or of tr, each containing sequence of such td. This structure can thus represent both eqnarray where a logical equation consists of one or more complete rows, as well as AMS’ aligned where equations consist of pairs of columns. The XSLT transformation that converts to end formats recognizes which case and lays out appropriately.

In most cases, the material that will yield a MathFork is given as a set of partial math expressions representing rows and/or columnns; these must be concatenated (and parsed) to form the composite logical expression.

Any ID’s within the expressions (and references to them) must be modified to avoid duplicate ids. Moreover, a useful application associates the displayed tokens from the aligned presentation of the MathBranch with the presumably semantic tokens in the logcal content of the main branch of the MathFork. Thus, we desire that the IDs in the two branches to have a known relationship; in particular, those in the branch should have .fork1 appended.