semantics, extensibility

[was: Re: Implementation Question -- SL(2,C)]

At 8:16 AM 7/5/96, Ron Whitney wrote:
>This is in followup to Patrick and Ping's postings in regard
>to naming classical objects.
>
>It's unclear to me whether we have a strong(ish?) disagreement here.
>I'm certainly not in favor of *requiring* that authors name the
>well-known objects of their papers... ([if we did], where do we stop?)
>
>I do want to define an HTML-Math wherein authors are able to specify
>such things if they wish.  My view of the project to date has been
>that we are trying to define a language which will (a) render to the
>various sensory media in such a way that a "knowlegeable" human can
>interpret the notation properly, and (b) allow for paths by which
>authors or other third parties may upgrade the notation to one
>with fuller semantical attributes....
>
>But do we differ in this?  Maybe not.  Ping's statement
>
>> It makes the most sense for the conceptual entity "the complex numbers"
>> to be represented by a separate named entity.  It is certainly *not* a
>> variable named "C" in any sense -- and you would need it to be distinguished
>> for it to be properly rendered to speech.
>
>is much stronger than I would have said myself.  There actually is a
>good sense (a formalist or nominalist sense) in which "the complex
>numbers" are adequately represented by "C", and I'm fairly certain
>that Raman reliably distinguishes this "C", as do those who read the
>"C", by context.


Although I am very sympathetic to specifying semantics, I agree
wholeheartedly with Ron's comments above.

I think we have already agreed that HTML-Math will specify a mapping
from an HTML-Math source expression to an expression's "appearance
in a logical sense" -- specifically, the sense captured by a nested
structure of "layout schema" -- and that at some point there will be
the possibility for authors to define macros (i.e. expansion rules),
and to state (informally, or at least not in a way whose formal aspects
are specified by the standard) the semantics intended to be associated
with various source forms, and for users of renderers ("readers") to
specify alternative expansion rules which follow their own preferred
conventions (e.g. for instances of a "set of complex numbers" macro
being represented by a bold or by a double-struck C).

I have made sure, in constructing the Wolfram proposal, to place
no obstacles in the way of adding author-extensibility which can be
used to express semantics in the way just described. This is achieved
by making sure that any HTML-Math source text corresponds to a well-
defined expression tree (suitable to serve as the input to pattern-
matching transformation rules) and that there's a well-specified set
of layout schema which must be renderable. To my knowledge, no one has
pointed out any failing of that scheme to provide for extensibility,
once suitable specifications for transformation rules and their
scope and order of application (etc) are specified,
or even said that they think one exists.

I have also argued for putting off discussions of extensibility
until the rest is finished, except for the question mentioned above
of whether we are putting any obstacles in its way. This is a more
controversial position.

Raman has expressed the fear (if I understood correctly)
that we can't be sure the obstacles aren't there
without actually implementing and using an extensibility method.
I don't agree -- I think the properties I named above absolutely
guarantee that a transformation rule based scheme can work well,
and in my letter outlining the proposal I showed something about
how such transformation rules could be represented, without
discussing them in detail.
I suggest that the burden of proof fall on the other side --
someone should show how some feature of the present proposal
prevents proper extensibility from being possible or adequately
convenient, if they believe it does that.

(Note that the present proposal does have one admitted failing
of eventual extensibility of a different kind (that is, not directly
related to semantics, but rather to the kinds of "logical notational
forms" that are renderable), namely, the lack of a way to use a
"non-standard layout schema". This was discussed in one of the
conference calls (probably the one whose minutes I have not yet
written up), where we agreed that it would be a good thing
to add a way of representing individual instances of non-standard
layout schemas. This is an example of the kind of issue which does
have to be worked out now in order to make extensibility possible later.)

And some people have, I think, said that extensibility is so valuable
that it's worth putting it into the first version of HTML-Math --
or to put it another way, refraining from releasing the first version
until we have succeeded in working out and agreeing upon the full details
of a scheme for author-extensibility. I agree with extensibility's value
and eventual necessity, but I think it's hard enough that there's a danger
that it will end up significantly delaying the release of the standard as a
whole, if we insist that it be present in the first version (rather
than just that it be able to be upwardly compatibly addable).
(What I think is so hard about it is not necessarily just proposing
a way of handling it, but for all of us to come to agreement on that
proposal.) Again, I suggest that the burden of proof be on those
who say this is sufficiently easy to do -- propose, if you will, a
fully specified design for a system of author-extensibility to be added
onto the current proposal, if you think it is easy enough to do this,
and likely enough that we'll be able to agree on it (or on how to
modify it) in a reasonable time.