As per Relevance of the word representation, we have this rfc below:
Network Working Group D.
Request for Comments: 1019 Xerox
September 1987
Report of the Workshop on Environments for Computational
July 30, 1987
ACM SIGGRAPH
Anaheim Convention Center, Anaheim,
Status of This
This memo is a report on the discussion of the representation
equations in a workshop at the ACM SIGGRAPH Conference held
Anaheim, California on 30 July 1987. Distribution of this memo
unlimited
Since the 1950's, many researchers have worked to realize the
of natural and powerful computer systems for interactive
work. Nowadays this vision can be expressed as the goal of
integrated system for symbolic, numerical, graphical,
documentational mathematical work. Recently the development
personal computers (with high resolution screens, window systems,
mice), high-speed networks, electronic mail, and
publishing, have created a technological base that is more
adequate for the realization of such systems. However, the growth
separate Mathematical Typesetting, Multimedia Electronic Mail
Numerical Computation, and Computer Algebra communities, each
its own conventions, threatens to prevent these systems from
built
To be specific, little thought has been given to unifying
different expression representations currently used in the
communities. This must take place if there is to be interchange
mathematical expressions among Document, Display, and
systems. Also, tools that are wanted in several communities (e.g.,
WYSIWYG mathematical expression editors), are being
independently by each, with little awareness of the duplication
effort that thereby occurs. Worst of all, the ample
for cross-fertilization among the different communities are not
exploited. For example, some Computer Algebra systems
associate a type with a mathematical expression (e.g., 3 x 3
of polynomials with complex number coefficients), which could
automated math proofreaders, analogous to spelling checkers
The goal of the Workshop on Environments for
Mathematics was to open a dialogue among representatives of
Arnon [Page 1]
RFC 1019 September 1987
Computer Algebra, Numerical Computation, Multimedia Electronic Mail
and Mathematical Typesetting communities. In July 1986, during
Computers and Mathematics Conference at Stanford University, a
of this year's participants met at Xerox PARC to discuss
Interfaces for Computer Algebra Systems. This group agreed to
future meetings, of which the present Workshop is the first.
Katz's recent essay, "Issues in Defining an Equations
Standard", RFC-1003, DDN Network Information Center, March 1987
(reprinted in the ACM SIGSAM Bulletin May 1987, pp. 19-24),
influenced the discussion at the Workshop, especially since
discusses the interchange of mathematical expressions
This report does not aim to be a transcript of the Workshop,
rather tries to extract the major points upon which (in the Editor'
view) rough consensus was reached. It is the Editor's view that
Workshop discussion can be summarized in the form of a
architecture for "Standard Mathematical Systems", presented
Section II below. Meeting participants seemed to agree that: (1)
existing mathematical systems should be augmented or modified
conform to this architecture, and (2) future systems should be
in accordance with it
The Talks and Panel-Audience discussions at the Workshop
videotaped. Currently, these tapes are being edited for
to the SIGGRAPH Video Review, to form a "Video Proceedings".
accepted by SIGGRAPH, the Video Proceedings will be
available for a nominal distribution charge
One aspect of the mathematical systems vision that we explicitly
out of this Workshop is the question of "intelligence"
mathematical systems. This has been a powerful motivation to
builders since the early days. Despite its importance, we do
expect intelligent behavior in mathematical systems to be realized
the short term, and so we leave it aside. Computer
Instruction for mathematics also lies beyond the scope of
Workshop. And although it might have been appropriate to
representatives of the Spreadsheets and Graphics communities, we
not. Many of those who were at the Workshop have given
thought to Spreadsheets and Graphics in mathematical systems
Financial support from the Xerox Corporation for
equipment rental at SIGGRAPH is gratefully acknowledged. Thanks
due to Kevin McIsaac for serving as chief cameraman,
critical comments on this report, and contributing in diverse
ways to the Workshop. Thanks also to Richard Fateman,
Spivak, and Neil Soiffer for critical comments on this report
Subhana Menis and Erin Foley have helped with logistics
documentation at several points along the way
Information on the Video Proceedings, and any other aspect of
Workshop can be obtained from the author of this report
Arnon [Page 2]
RFC 1019 September 1987
I. Particulars of the
The Workshop had four parts: (1) Talks, (2) Panel Discussion, (3)
Panel and Audience discussion, (4) and Live demos. Only a few of
systems presented in the talks were demonstrated live. However,
of the talks contained videotapes of the systems being discussed
The talks, each 15 minutes in length, were
1. "The MathCad System: a Graphical Interface for
Mathematics", Richard Smaby, MathSOFT Inc
2. "MATLAB - an Interactive Matrix Laboratory", Cleve Moler
MathWorks Inc
3. "Milo: A Macintosh System for Students", Ron Avitzur, Free
Developer, Palo Alto, CA
4. "MathScribe: A User Interface for Computer Algebra systems",
Soiffer, Tektronix Labs
5. "INFOR: an Interactive WYSIWYG System for Technical Text",
William Schelter, University of Texas
6. "Iris User Interface for Computer Algebra Systems", Benton Leong
University of Waterloo
7. "CaminoReal: A Direct Manipulation Style User Interface
Mathematical Software", Dennis Arnon, Xerox PARC
8. "Domain-Driven Expression Display in Scratchpad II",
Watt, IBM Yorktown Heights
9. "Internal and External Representations of Valid
Reasoning", Tryg Ager, Stanford University
10. "Presentation and Interchange of Mathematical Expressions in
Andrew System", Maria Wadlow, Carnegie-Mellon University
The Panel discussion lasted 45 minutes. The panelists were
Richard Fateman, University of California at
Richard Jenks, IBM Yorktown
Michael Spivak, Personal
Ronald Whitney, American Mathematical
Arnon [Page 3]
RFC 1019 September 1987
The panelists were asked to consider the following issues in
their presentations
1. Should we try to build integrated documentation/
systems
2. WYSIWYG editing of mathematical expressions
3. Interchange representation of mathematics
4. User interface design for integrated documentation/
systems
5. Coping with large mathematical expressions
A Panel-Audience discussion lasted another 45 minutes, and the
lasted about one hour
Other Workshop participants, besides those named above, included
S. Kamal Abdali, Tektronix
George Allen, Design
Alan Katz, Information Sciences
J. Robert Cooke, Cornell University and Cooke
Larry Lesser, Inference
Tom Libert, University of
Kevin McIsaac, Xerox PARC and University of Western
Elizabeth Ralston, Inference
II. Standard Mathematical Systems - a Proposed
We postulate that there is an "Abstract Syntax" for any
expression. A piece of Abstract Syntax consists of an Operator
an (ordered) list of Arguments, where each Argument is (recursively
a piece of Abstract Syntax. Functional Notation, Lisp SExpressions
Directed Acyclic Graphs, and N-ary Trees are
representations of Abstract Syntax, in the sense of being
expressive, although one or another might be considered
from the standpoint of computation and algorithms. For example,
functional expression "Plus[Times[a,b],c]" represents the
Syntax of an expression that would commonly be written "a*b+c".
A "Standard Mathematical Component" (abbreviated SMC) is a
of software and hardware modules, with a single function, which if
reads mathematical expressions, reads them as Abstract Syntax, and
it writes mathematical expressions, writes them as Abstract Syntax
A "Standard Mathematical System" (abbreviated SMS) is a collection
SMC's which are used together, and which communicate with each
in Abstract Syntax
We identify at least four possible types of components in an SMS
Arnon [Page 4]
RFC 1019 September 1987
Any particular SMS may have zero, one, or several instances of
component type. The connection between two particular components
an SMS, of whatever type, is via Abstract Syntax passed over a "wire
joining them
1) EDs - Math
These edit Abstract Syntax to Abstract Syntax. A particular
may have editors that work on some other representations
mathematics (e.g., bitmaps, or particular formatting languages),
however they do not qualify as an ED components of a SMS. An ED
be WYSIWYG or language-oriented
2) DISPs - Math
These are suites of software packages, device drivers, and
devices that take in an expr in Abstract Syntax and render it.
example, (1) the combination of an Abstract Syntax->TeX translator
TeX itself, and a printer, or (2) a plotting package plus a
device. A DISP component may or may not support "pointing" (i.e.,
selection), within an expression it has displayed, fix a
probably doesn't, but terminal screen may. If pointing is supported
then a DISP component must be able to pass back the
subexpression(s) in Abstract Syntax. We are not attempting here
foresee, or limit, the selection mechanisms that different DISPs
offer, but only to require that a DISP be able to communicate
selections in Abstract Syntax
3) COMPs - Computation
Examples are Numerical Libraries and Computer Algebra systems.
are questions as to the state of a COMP component at the time
receives an expression. For example, what global flags are set,
what previous expressions have been computed that the
expression may refer to. However, we don't delve into these
issues at this time
4) DOCs - Document
These are what would typically called "text editors", "
editors", or "electronic mail systems". We are interested in
handling of math expressions. In reality, they manage other
constituents as well (e.g., text and graphics). The design of
user interface for the interaction of math, text, and graphics is
nontrivial problem, and will doubtless be the subject of
research
A typical SMS will have an ED and a DISP that are much more
coupled than is suggested here. For example, the ED's
representation of Abstract Syntax, and the DISP's
representation (e.g., a tree of boxes), may have pointers back
Arnon [Page 5]
RFC 1019 September 1987
forth, or perhaps may even share a common data structure. This
acceptable, but it should always be possible to access the
components in the canonical, decoupled way. For example, the
should be able to receive a standard Abstract Syntax
for an expression, plus an editing command in Abstract Syntax (e.g.,
Edit[expr, cmd]), and return an Abstract Syntax representation
the result. Similarly, the DISP should be able to receive
Syntax over the wire and display it, and if it supports pointing,
able to return selected subexpressions in Abstract Syntax
The boundaries between the component types are not hard and fast.
example, an ED might support simple computations (e.g.,
simplification, rearrangement of subexpressions, arithmetic), or
DOC might contain a facility for displaying mathematical expressions
The key thing for a given module to qualify as an SMC is its
to read and write Abstract Syntax
III. Recommendations and
1. It is our hypothesis that it will be feasible to encode a
variety of other languages in Abstract Syntax, for example
programming constructs. Thus we intend it to be possible
pass such things as Lisp formatting programs, plot programs
TeX macros, etc. over the wire in Abstract Syntax. We
hypothesize that it will be possible to encode all present
future mathematical notations in Abstract Syntax (e.g.,
commutative diagrams in two or three dimensions).
example, the 3 x 3 identify matrix might be encoded as
Matrix[ [1,0,0], [0,1,0], [0,0,1] ]
while the Abstract Syntax expression
Matrix[5, 5, DiagonalRow[1, ThreeDots[], 1],
BelowDiagonalTriangle[FlexZero[]],
AboveDiagonalTriangle[FlexZero[]]]
might encode a 5 x 5 matrix which is to be displayed with
"1" in the (1,1) position, a "1" in the (5,5) position,
dots between them on the diagonal, a big fat zero in the
triangle indicating the presence of zeros there, and a big
zero in the upper triangle indicating zeros
2. We assume the use of the ASCII character set for Abstract
expressions. Greek letters, for example, would need to
encoded with expressions like Greek[alpha], or Alpha[].
Similarly, font encoding is achieved by the use of
Syntax such as the following for 12pt bold Times Roman
Font[timesRoman, 12, bold, <expression>] Two SMCs are free
communicate in a larger character set, or pass
specifications in other ways, but they should always be able
Arnon [Page 6]
RFC 1019 September 1987
express themselves in standard Abstract Syntax
3. COMPs (e.g., Computer Algebra systems), should be able
communicate in Abstract Syntax. Existing systems
have translators to/from Abstract Syntax added to them.
addition, if we can establish a collection of standard names
argument lists for common functions, and get all COMP's to
and write them, then any Computer Algebra system will be able
talk to any other. Some examples of possible standard names
argument lists for common functions
Plus[a,b,...]
Minus[a
Minus[a,b
Times[a,b,...]
Divide[, ]
Power[, <exponent>]
PartialDerivative[, ]
Integral[, , ,] (limits optional
Summation[<, , ] (limits optional
A particular algebra system may read and write
Abstract Syntax. For example
Polynomial[Variables[x, y, z], List[Term[coeff, xExp, yExp, zExp],
...
but, it should be able to translate this to an equivalent
representation. For example
Plus[Times[coeff, Power[x, xExp], ...
4. A DOC must store the Abstract Syntax representations of
expressions it contains. Thus it's easy for it to pass
expressions to EDs, COMPs, or DISPs. A DOC is free to
additional expression representations. For example, a tree
Boxes, a bitmap, or a TeX description
5. DISPs will typically have local databases of
information. To actually render the Abstract Syntax, the
checks for display rules in its database. If none are found
it paints the Abstract Syntax in some standard way.
formatting databases can be overridden by formatting rules
over the wire, expressed in Abstract Syntax. It is
databases that store knowledge of particular
environments (for e.g., "typesetting for Journal X").
The paradigm we wish to follow is that of the genetic code:
mathematical expression is like a particular instance of DNA,
upon receiving it a DISP consults the appropriate
database to see if it understands it. If not, the DISP
Arnon [Page 7]
RFC 1019 September 1987
"passed it through unchanged". The expression sent over the
may be accompanied by directives or explanatory information
which again may or may not be meaningful to a particular DISP.
reality, formatting databases may need to contain
System-level sophistication to be able to produce
quality typesetting results, but we believe that useful
can be achieved even without such sophistication
6. With the use of the SMC's specified above, it becomes easy to
any DOC as a logging facility for a session with a COMP. Therefore
improvements in DOCs (e.g., browsers, level structuring,
documents, audit trails), will automatically give us
logging mechanisms for sessions with algebra systems
7. Note that Abstract Syntax is human-readable. Thus any
editor can be used as an ED. Of course, in a typical SMS,
should have no need to look at the Abstract Syntax
through the internal "wires" if they don't care to. Many
want to interact only with mathematics that has a textbook-
appearance, and they should be able to do so
8. Alan Katz's RFC (cited above) distinguishes the form (i.e.,
appearance) of a mathematical expression from its content (i.e.,
meaning, value). We do not agree that such a distinction can
made. We claim that Abstract Syntax can convey form, meaning
or both, and that its interpretation is strictly in the
of the beholder(s). Meaning is just a handshake between
and recipient
9. Help and status queries, the replies to help and status queries
and error messages should be read and written by SMC's
Abstract Syntax
10. In general, it is permissible for two SMC's to use
protocols for communication. Our example of a tightly coupled
and DISP above is one example. Two instances of a Macsyma
would be another; they might agree to pass Macsyma
representations back and forth. To qualify as SMC's, however
they should be able to translate all such exchanges
equivalent exchanges in Abstract Syntax
Arnon [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
