notes on teleconference, 9 sep

Notes on HTML-Math Interest Group Teleconference Call
9 Sep 96
---------------------------------------------------------------------

In attendance:

Ste'phane Dalmas Safir, INRIA
Patrick Ion      Mathematical Reviews
Robert Miner     The Geometry Center
Bruce Smith      Wolfram Research, Inc.
Bob Sutor        IBM
Stephen Watt     Safir, INRIA
Ron Whitney      American Mathematical Society
Ralph Youngen    American Mathematical Society

[Notes prepared by RW.  Corrections welcome.]
---------------------------------------------------------------------

Bruce indicated that he is making progress on the Mathematica parser,
and reduced his estimate to achieving something demonstrable to a
week.  Robert has continued to work on his Java renderer (which reads
code in `Presentation List' form and displays it).

There was little discussion about the Sep30/Oct1 meeting logistics.

We talked about the groupings and priorities posted by Robert in his
note of 3/5 September.  [[For convenience, the list is reproduced here:

    "1. Secondary and undergraduate level math notation with 
        little or no semantic information for generic visual display

    "2. Secondary and undergraduate level math notation with 
        enough semantics for CAS rendering.  To me, it is reasonable
        to expect the author to have a specific CAS in mind.

    "3. Research mathematics notation with little or no semantics
        for visual display.

    "4. Research mathematics notation with enough semantics for CAS, math
        software, or speech rendering.  Again, I would be content with a
        document tagged specifically for Maple or Geomview, etc.  However, 
        speech rendering would need to be possible at the same time.

    "The main consequence of these priorities is that I [RM] think HTML Math
     should be primarily notation based, with semantic information added
     through some combination of annotations and parser heuristics. ... "

]] Bruce said he was hoping to get agreement on some basic principles
regarding extensibility and treatment of semantics so that he could
devote time toward some more immediate goals (such as writing code for
the Mathematica parser).  He called for reaction (if there is any) to
his recent note discussing <mtype> or <mannotation> elements
(e.g. will that cover needs that people foresee?).

Patrick felt he was in agreement with the List as given by Robert, and
Ron said he also was in general agreement, although he was uncertain
as to the volume of material in category 2 and knew that, e.g., AMS
has a large amount of material in category 3.  Robert said that he had
debated the ordering he gave of categories 2 and 3, and thought they
might be called 2a and 2b as parallel components to category 2.  After
further discussion from Bruce and others, the linear order became a partial
order

                   1

                 /   \

         Undergrad   Research level
            CAS         w/o CAS

              \           /

            3 (high semantics,
           sophisticated layout)

wherein we envisioned that the two categories at the second level just
might have different emphases on semantical and presentational
annotations.

Stephen said he felt the ordering of the list was ok, but that the
needs of category 1 might be a rather large chunk to bite off first.
He asked for clarification on what was to be included in category 1
(e.g., an undergraduate course in topology might show notation which
would require fairly sophisticated typesetting capability).  Patrick
said that he took category 1 to comprise notations seen in
standard courses at levels K-14 (i.e. through the first two
undergraduate years).  Robert said he was trying to exclude "highly
decorated operators", and spoke to handling notation which might be
used at the level of the mathematical operators available on a
hand-held, programmable calculator.  After further discussion, there
seemed to be rough agreement on the type of notation to be covered in
category 1, at which point Bruce asked again whether the <mtype> or
<mannotation> elements would satisfy the needs that people envision
for type characteristics throughout the list.  Bob and Stephen
answered "yes" [[but tell me if I lie -- RW]].

Stephen asked for clarification of the handling of "style sheets"
within category 1.  He felt that, with increasing dissemination of
course notes as replacement for standard texts, there is a need to
address the problems of stylistic variation.  He gave the example of a
vector transpose being displayed with a superscripted T or a dagger or
emboldened.  Bruce said that he envisioned style sheets as being
driven via the macro facility of the WP, and that, to achieve
convenient stylistic variation, authors of such course notes would
have to collaborate on macro conventions.  Bob said he felt that, in
addition to being a clearing house for "contexts", OpenMath might
serve as a clearing house for these other sorts of semantical
conventions.  Stephen remarked that he felt this was too great a leap
(i.e. leaping into macros) for something that should be relatively
simple (style sheets).  Robert said he felt that collaborators on
elementary texts ought to be regarded as rather sophisticated users,
more in the category 2 range.

Stephen wondered whether the disparate underlying techniques (macros,
style sheets, semantical annotations) to be used for stylistic
variation could be simplified.  He said he felt there were "too many
concepts doing the same thing" [[*rough* quotation; please correct me
Stephen]].  Bruce fielded this and discussed the need for a couple of
different kinds of macros (those which might be simple shorthand and
which should *not* be alterable by style sheets, and those which dealt
with presentation form and may be so alterable).

[[
There was a fair amount of further discussion, but I feel I cannot
do it justice.  I welcome postings on these matters, most especially
from Bruce and Stephen.
]]

In the wrap-up we spoke briefly about what the prioritization in a
list such as Robert's might mean.  Everyone is concerned that issues
regarding HTML-Math be addressed fairly and completely.  Listing
priorities gives some sense of the path of development and discussion
when we feel we can see adequately "through" all the issues.