Re: Technical reasons for some options taken on design of MathML

While this discussion has brought out that much of the concern lies over the
verbosity and structures used to represent the presentation of mathematics
it began with some serious questions about the choices in content MathML.

I have elected at this point to summarize.some key points that have emerged
as answers related to content for ease of future reference.

1.  Why the use of an apply "container" instead of defining each operator
such as divide as a "container".
Answers:
   a)  easy to locate the operator in the XML structure
   b)  support for arbitrarily complex operators  (e.g. another apply,
and/or with elaborate presentations)
   c)  ease of extending mathml to use other symbols with associations  to
more formal definitions.
   d)  support use and discussion about the operators outside of the context
of applying them to arguments.

2.  Why the introduction of  operators and symbols as elements?
Answers:
   a)  clearly identifieable role from the rest of the document content
(Try searching a long string or document for meaningful occurrences of "E".)
   b)  elements provide an anchor for definitionURL and attributes
controlling display.

3.  Why not more complete support for semantic specification such as in
openmath?
Answers:
   a) Concern about complexity / scope of first release of MathML
   b) definitionURL already makes the essential leap of allowing an author
to warn the consumer that a special meaning is in use and provides a
mechanism to experiment with mechanisms for more complete specifications -
much in the spirit of namespaces in XML.  This is way more than ever existed
before.
   c) A desire for more practical experience in this arena before
standardizing a more elaborate scheme.

4.  Why not use infix operators?
Answers:
    a) importance of being able to identify the operator programatically.
    b) consideration for nullary and n-ary operators.

This list is not intended to be all inclusive.  Nor does it address the
issues regarding presentation, but they are all points to keep in mind when
attempting to consume mathematical markup by machine.

Stan Devitt