RE: "industry needs"

I have quietly watched this debate about the ability (advisability) of RIF
to attempt to meet a real need of industry and I suspect that many of the
difficulties are arising because people are losing site of some important
facts about the role of RIF.

I think it is time to say something now, in part as I am seeing this as many
of the same debates arose in the early stages of designing MathML and I
think there is something to be learned.

A) Adopt on and adapt an industry defacto standards of build for the web?
B) Evaluation and evaluation models  (ranging from none to lazy-like or on
special request [i.e., most computer algebra systems] to immediate [most
numerical systems])?
C) Multiple semantics (in effect every math product has its own semantics -
try and get agreement on the domain of arctrig functions or numerical
models), or a definitive one?
D) Muliple purposes - Display (visual/aural), Editing, Computation? How?
D) Desire for the design to be based on a formal model.

We had many existing candidates (Tex, LaTeX, CA systems, OpenMath, SGML base
ISO-12083, numerical systems,MathType embedded in Word) all of which
represented Math in their own way and none of which were adopted directly -
because choosing one of them always meant ruling out an important use.

MathML has achieved wide adoption exceeding our greatest hopes and in spite
of the fact that no commercial product implemented even part of it when we
started.  Some of the following were important part of getting there:

1) We provided infrastructure without attempting to dictate how it was used.
For example, the syntax tree for display is often quite different from that
for evaluation.
2) We did not try to provide a definitive semantics.  Users could decide
that the default MathML semantics was close enough, or flag theirs as
significantly different with specific definitions.
3) We ruled out evaluation within MathML early on.  Inspite of this, just
about every major debate over several several years of development involved
a hidden attempt to evaluate.
4) We did not say that Editing was better/worse than computation - we
focussed on providing a framework where both could co-exist and provided
some additional infrastructure so they could start to work together.

Throughout we had in mind two hypothetical extremes as sample uses.  A) An
editing tool trying to construct either a semantic or visual presentation of
an expression, and B) a computer algebra system trying re-use data found on
a passive web page - possibly the same data.

Our response to one test case or the other failing was to modify the design
- not say it can't or shoudn't be done.

RIF has the potential to do this  again. The lessons for RIF are (I
believe):

1) It must be an enabling technology that facilitates today's systems and
extends them.  What is new about rule exchange on the web that pushes all
the systems?  
2) We need a framework that allows for the different kinds of rule systems.
This means
 a) a way of flagging/identifying the semantics in use and possibly their 
relationships to related systems
 b) an easily extendable syntax that allows each to work naturally and
captures the essentials of rule based systems.
3) We need to accept simple data exchange of all kinds of rule systems as
use cases.  It should be easy to extend to capture existing and yet to be
invented rule systems.
4) We need to provide a mechanism to allow for integration of the systems in
order to provide for infrastructure for new (non-existant) hybrid systems.
5. Never Evaluate.  By all means provide an application that evaluates -
perhaps by farming out rules to appropriate systems together with a context,
but DO NOT evaluate.  This is largely data modelling and data exchange where
the data is rules.

A starting point now is to identify those limiting cases of extreme use and
the current debate may actually have provided some of them.

Stan Devitt

Received on Tuesday, 6 June 2006 13:18:26 UTC