Re: on goals (repost)

At 4:12 PM 7/4/96, Ka-Ping Yee wrote: [excerpted]


>--------------------------------------- two-dimensional representation
>[009] T. V. Raman writes:
>> Renderings in speech need to convey more than a "2D picture" of the
>> expression.
>
>I definitely agree with what Raman says here.
>
>That document at [GENERAL] makes many references to a "2-D
>presentational structure" and a "2-dimensional form of an expression".
>I believe this is *not* what a mathematical or structured-expression
>notation should be based upon, and i disagree with this statement as
>as a design goal [DESIGN].
>
>A two-dimensional model is too limiting and presentation-specific.

In general, the "position papers" you're referring to are obsolete,
although the specific sections you're referring to happen not to be --
rather they are just not very well written, and therefore were widely
misunderstood.

By "logical 2-dimensional structure" I only meant to indicate a certain
"level" of the logical structure of conventional math notation (which
happens to be 2-dimensional). I meant to indicate that expressions were
formed from subexpressions using certain "logical constructors" which
are typically rendered as controlling the relative sizes and positions
of the subexpressions, but which in principle are just arbitrary
distinguishable labels (just as letters are arbitrary distinguishable
symbols) which can be assigned various meanings (often
context-dependent) when used in certain recognized combinations.

I should find a better way to explain the idea without overemphasizing
the reference to the 2-dimensionality of existing conventional
notation. Raman (who most strongly objected to the wording I used) said
he would suggest a better wording, but has not done so -- I imagine he
found it as hard as I did to come up with one.

>The goal should be a language that conveys the semantics and structure
>of an expression.

To me, representing "semantics" and "notational structure" are two
separate goals; any given system can have each of these goals to some
degree, though I think it must choose one of them as the primary basis
of the structure it represents.

The concept of "structure" can of course apply to either one, since
both semantic meanings and notational structures can be well-
represented as recursive applications of compound "constructors" to
"primitive elements".


>[012] Dave Raggett writes:
>> Raman voiced a concern on Bruce's comment on 2D pictures. We agreed
>> however, that a fixed set of "layout" idioms are sufficient for
>> HTML-math.
>
>A fixed set of "layout" idioms for printing and 2-D screen display are
>fine.  We should be able to easily define other rendering idioms for
>other media, though.  MINSE calls these idioms "primitives" (because
>rendering structures are built from them); while there are things like
>@bar, @sup, and @big among the video primitives [GLYPHD], possible
>audio primitives include @pan, @inflect, or @speed.  I'm curious to
>know if ASTeR uses an intermediate output format like this.

One area in which the Wolfram proposal needs to be extended is to have a
way for an author to specify the use of non-built-in layout schema,
which are supported by some renderers and not others. This has been
briefly discussed by phone, just enough to get agreement that it's
desirable. Examples of new layout schema that some renderers might want
to design and support would be for commutative diagrams, mathematical
graphs, other kinds of diagrams such as are used to describe knots and
braidings, or chemical structural formulae.

My emphasis is a bit different than in the examples you give, since the
intent is to support non-built-in medium-independent layout schema
rather than non-built-in medium-dependent rendering constructors; we
are trying not to encourage the use of medium-dependent HTML-Math of
any kind, though we recognize some degree of that is unavoidable.


>-------------------------------------------------- capturing semantics
>[038] Ron Whitney writes:
>> A full definition isn't
>> required, but we all anticipate that html-math will feed into various
>> processors which manipulate the html data in mathematical ways, and
>> I'd like a somewhat clearer notion of how others here understand the
>> "semantics" we're trying to capture.
>
>Ideally we should be able to get enough meaning into most expressions
>to be able to "render them out" to something which can be directly
>manipulated by Maple or Mathematica, in addition to being represented
>as images, audio, or say TeX.
>
>> A more complicated case lies in the various uses of, say, ^ as a
>> "power" operation.
>[...]
>> The distinguishing
>> force is that these "really are" (say in a computational or other
>> formal sense) different uses of the term (e.g. one wants to say the
>> exponential function *truly* isn't a power at all) and should be
>> distinguished as such.
>
>I perceive the exponentiation of numbers and the composition of
>functions as two different operations, and so while they are
>sometimes written similarly, MINSE has different compounds for both
>('exp and 'composen, respectively).  Different operations are
>always given different compounds, even if they may render the same
>way.  This is crucial to preserving the meaning of the expression. 

We (Wolfram) think: we are only trying to force authors to specify
semantics in order to disambiguate a few crucial cases which cause the
most problems for rendering and for CASs. Thus we don't force most
semantics to be specified; indeed, we think that to do this is both a
very hard problem, and a different one than we're trying to solve.

Furthermore, we think a more fruitful way to specify semantics than
using a different named operator for every operation is to allow a
context to be used which disambiguates the notations; HTML-Math need
not specify the meaning of this context, but only allow a way for its
data to be made available to something which wants to use it to
interpret the meaning of an HTML-Math expression. (We'll definitely add
a way to specify such a context to our proposal, even before we include
any other kind of "extensibility".)

We make exceptions to this in a very small number of very crucial
cases, which are chosen by judgement rather than by any strict policy;
the exceptions include "ⅆ" being different than "d" and certain
other named extended characters having different versions for different
meanings. We do this especially in cases where even the parser needs to
understand the difference in order to function correctly. If something
parses the same way for all its various meanings, we usually figure its
interpretation can safely be left to the context.


>-------------------------------------- the importance of extensibility
>[070] Neil Soiffer writes:
>> I heard from Steve Hunt (at the paris HTML meeting) that Dave Ragget
>> felt it was worth pursuing a two phase approach, with the first phase
>> being the basic syntax as Bruce and I have proposed
>[...]
>> Phase two of the standards is the more iffy part: adding macros/mapping
>> rules/pattern matching or whatever to allow for extensions of the base
>> standard and easier authoring and conversion to other systems.  I imagine
>> this would be another year in the making.
>
>I am wary of this approach.  My past experience (little as it has been,
>probably, compared with most of you -- but anyway) has been that unless
>a system is designed with extensibility at the start, it can get messy
>to try to extend things later on.  I have kept this in mind in the design
>of MINSE by allowing the redefinition of notations [NOTATION] and styles
>[STYLE] right at the outset.  MINSE is already fully extensible.

I'll comment extensively on this issue in another letter.


>-------------------------------------------- about being math-specific
>[089] Bruce Smith writes:
>>       The solutions to the general quadratic equation:
>>       <math mode=inline>
>>       ax^2+bx+c=0
>>       </math>
>
>A number of times on this mailing list now i've seen mention of
>this new <math> tag.  I have some reservations about creating a
>tag called MATH (and, indeed, about naming the entire proposal
>"HTML-Math"), because it is my hope that such a system should not
>limit itself to just mathematics.  I tried to avoid using the
>word "math" in MINSE's name, for instance (though the pathname
>on the site is still "/math/").
>
>MINSE was designed to be extensible at the outset, and can support
>multiple notations and multiple contexts (as soon as i define
>some more).  This is why i think a name like <se> ("structured
>expression") is a better choice.

The main demand for this system is from people who want to render math,
and the main kind of experience that informs our design discussion is
that of math rendering. This is probably why we're naming things based
on this being a "math notation".

I agree with you that what we're really doing (or at least, should be
doing) is much more general in principle. I think we should respond to
this by making sure we don't prevent our work from being used in more
general ways (and that this is quite important in the long run).

What we call the tag is more of a marketing issue; since all our
"customers" are asking for "math, and soon", I prefer to call it
<MATH>.

(Besides, as a big fan of math (including the nature of its notation)
who thinks it's underappreciated by the general public, I wouldn't mind
if a situation eventually developed where if you want to do the coolest
things in HTML for whatever purpose, you have to do them using the MATH
tag!)


>Notation definitions are separated from style definitions,
>because the former come before the semantics and the latter
>come after.  Thus the former are chosen by the author, and
>the latter are selected depending on the target media (perhaps
>with hints from the author and reader).

I think this is the right way to separate these (and a good
way of expressing the reason for the distinction) and I hope
we'll be able to do it in a similar way.

- Bruce