[Prev][Next][Index][Thread]
notes on teleconference, 9 sep

To: w3cmatherb@w3.org

Subject: notes on teleconference, 9 sep

From: Ron Whitney <RFW@MATH.AMS.ORG>

Date: Tue, 10 Sep 1996 14:25:06 0400 (EDT)

From w3cmatherbrequest@www10.w3.org Tue Sep 10 14: 25:35 1996

Mailsystemversion: <MultiNetMM(369)+TOPSLIB(158)+PMDF(5.0)@MATH.AMS.ORG>

Messageid: <842379906.552078.RFW@MATH.AMS.ORG>
Notes on HTMLMath 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 K14 (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
handheld, 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 wrapup we spoke briefly about what the prioritization in a
list such as Robert's might mean. Everyone is concerned that issues
regarding HTMLMath 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.