ISO/IEC JTC1/SC18/WG8 **N770**

**Title:**

Liaison to WGs 1, 3, and 5 on request for support from Euromath group

**Source:**

WG8

**Project:**

All WG8 projects

**Status of document:**

Approved liaision statement

**Date**

89-01-26

**Distribution:**

WG8 and liaisons

**Liaision statement on Euromath**

WG8 is delighted to respond to the request for information on the
processing of mathematical formulae. Several of our members are
mathematical and scientific publishers, and we have been involved in the
development of mathematical processing systems, including SGML
applications such as the American Association of Publishers (AAP) system
(being standardized in TC46) and the later and more conceptually
oriented system outlined in ISO TR 9573.

We concur with the Euromath Executive Director that layout is quite
secondary to the capture of semantic information in the processing and
interchange of mathematical (and other similar scientific and
engineering) information. Scientists think more in abstract concepts
than in terms of formatted equations and printed material. Furthermore,
there are often multiple ways of rendering a given concept. The
stylistic conventions that vary from publisher to publisher or from
nation to nation are of far less significance than the ideas for which
they are, at best, inadequate surrogates.

To say that layout is secondary is not to deny its complexity or
importance. The development of specialized systems for rendering
mathematics has been among the high points of the rise of computerized
text management. We think particularly of the Bell Laboratories
processor *eqn*, originally attached to the formatter *troff* but more
recently adapted to such commercial products as *Interleaf* and *Ventura
Publisher*, and of Donald Knuth\'s composition system T~E~X. The
formatting power and flexibility required for adequate presentation of
formulae greatly exceed the capabilities of escape-code driven
formatters such as the Character Content Architecture of ISO 8613.
Processing *eqn* and T~E~X, however, is widely understood in the
scientific community, and if the interchange of files for presentation
were all that were required, some application of those languages would
be sufficient.

What is needed, though, is a way of exchanging concepts independent of
layout; whatever presentation is desired by the recipient can be applied
according to stylistic requirements of the local application. To
illustrate: The concept ¬vector║ is sometimes rendered by placing an
arrow over a normal variable (which would be set in italics); at other
times it is rendered by a line over the character or by setting the
variable in bold (but not italics). The choice of rendering, which is
frequently as much a function of someone\'s aesthetics as anything else,
does not change the meaning conveyed. The selection of a rendering may
also be conditioned by what other constructs must be notated in the same
document. Most mathematicians are all too familiar with the problems of
devising notations for new concepts and of balancing among available
notations. A system that is based on layout will do poorly in
interchange because it does not truly capture the originator\'s semantic
intent for the recipient to display as needed but rather simply imposes
the originator\'s formatting on the recipient. A system based on
capturing logical concepts, however will do well in interchange; it is
almost trivial to alter the formatting associated with a vector in
T~E~X.

In some cases, rendering may even be variable within a single document.
In North American typography, the limits on a summation are frequently
placed above and below the summation sign for displayed equations but
after the sign for equations embedded in text. The concept rendered, of
course, does not change. The interchange representation should also be
invariant, with the layout being adapted automatically according to the
context without having any explicit indication in the interchanged data
stream.

The paucity of options available for rendition often means that a single
layout function is forced to represent many different concepts. A
mathematician, seeing a subscript, might suspect it to be an index,
showing the position of an object in a series. A chemist, in contrast,
might consider it an indication of how many of the object appeared in a
compound. A superscript might indicate the power to which a variable is
raised, the charge on an ion, or something unrelated to expressing
formulae, such as the presence of a footnote. If the information
exchanged is to be used in its correct context, it is necessary to
capture concepts, not layout, to interchange an author\'s intent
accurately. (This is an area in which both *eqn* and T~E~X in their
basic forms are both weak, as each has only generalized subscript and
superscript functions that are called upon not only to provide real
subscripts and superscripts for a variety of purposes but to place the
limits on certain functions as well. However, with a language-based,
programmable system like either, it is possible to implement
individualized superscript functions that are specific to particular
concepts to be represented. The same could be said of extending the AAP
application of SGML, though it is optimized for book publishing even
more than these two composition systems.)

A further issue is the essentially seamless nature of mathematical text.
Formulae are not insertions into text: they are part of the text.
Whether an equation is displayed or contained inline is a matter of
typographic taste and convention and has nothing to do with semantic
content. It is thus essential that the mechanism used to capture
information record concepts uniformly, whether they appear in a
mid-sentence fragment, an inline equation, or a large, built-up display.
(It would be wrong, for example, to set an isolated scalar variable just
as an italic character because it normally *looks* like one.)

As the dissemination of scientific information grows away from printed
documents and becomes increasingly a matter of public data bases, it
will become even more important that the interchange and storage forms
for documents reflect semantic content rather than appearance. It would
be impossible to conduct an adequate search of an international
mathematical data base if ideas were stored according to their many
potential personal or local renditions rather than by the conceptual
constructs created by the contributors.

Returning to the original request from the Euromath organization, we
concur that what is needed is an extremely flexible and easily
extensible system for capturing structured semantic information. To be
sure, the great variety of concepts to be captured and the never-ending
need to capture new concepts place heavy demands on implementors. (This
is one reason *eqn* and T~E~X, being systems for typesetting rather than
for information interchange and retrieval, make frequent compromises in
their notation.) Hundreds, if not thousands, of semantic constructs will
need to be included in a fully generalized system. Of course, an
individual researcher will not need to know all of them; a topologist
might have little use for the structural notation of an organic chemist.
Rather than construct limited, closed systems, we need to provide
researchers with tools with which to build notational systems
appropriate to particular applications. Selecting the actual structures
to be included in the systems is a job for the researchers themselves.

Researchers would, no doubt, appreciate structured editors for
manipulating documents. The editors, it goes without saying, will need
easy-to-use tools for creating new structures. The ability to display
formatted equations is also desirable for convenience in scanning
documents and as a check on proper structuring. A well-designed user
interface could simplify (and perhaps largely disguise) the scale of
semantic complexity manipulated by the editor. But the interchange
format should consist primarily of the semantic information, with layout
optional and secondary. If layout information is transmitted, it should
be in a similarly flexible notation, such as that being developed in the
Document Style Semantics and Specification Language (DSSSL) project. (We
draw attention to an example of a modern researcher\'s tool, the
*Mathematica* system, which is designed for manipulation of abstract
concepts but then allows generation of T~E~X code for presentation
output.)

As a final point, we might doubt the wisdom of producing, much less
standardizing, a full-blown system for mathematical use in SC18.
Although SC18 has experts trained in mathematics, physics, and other
disciplines, as well as specialists in scientific typesetting, compiling
the full range of semantic constructs is more appropriate to members of
the research community itself. Such systems as have been devised in SC18
(i.e., that in TR 9573) have been intended as examples, not finished
applications. If applications are standardized, perhaps they should be
handled by organizations closer to the end user, such as TC46 (the AAP
mathematics notation being studied there is quite typographically
oriented, being designed for book production; it was, however, developed
largely by members of the U.S. National Body of SC18).

SGML, being among other things a tool for building logical structures,
is an appropriate basis for creating applications to manage mathematical
information. That two quite different systems, that of the AAP and that
in TR 9573, adapted to different applications, have already been
created, and each has been implemented more than once, is good evidence
of its capabilities.

To summarize, we believe that what is required for mathematical
information interchange is an open-ended, semantics-based system. Many
powerful support tools will be needed, particularly editors and
formatters. But emphasis should be on the capture of intellectual
concepts, with rendering recognized for what it is, a secondary support
function. The members of WG8 would be pleased to offer their support to
the Euromath group on both logical analysis and composition functions in
support of the dissemination of mathematical information.