Re: small samples

Dave writes:

> There is no "Raggett:" representation as such since the whole
> point of the approach I am recommending is that the surface
> syntax is malleable and that the linked rule base defines
> how to map this to the display schema and clipboard formats.

I do recognize this, and also acknowledge Ping's remarks on
malleability.  Wolfram's surface level notation is also malleable;
TeX's, too.  SGML is only written in its standard reference
syntax.  20th century model theory showed that objects such as
Peano arithmetic and real analysis also lack unique referents.

If others wish, I can cease and desist on this little effort to
make matters concrete.  I recognize that we are attempting to build
in transformability to our notation.  I myself find value is speaking
of concrete notations and then indicating what transformations are
possible.  In some fashion, we will have to indicate what is and isn't
possible at some point, and we should also (I think) provide a
"reference concrete syntax" ourselves so that people can get a feel
for "the" language, even in its abstract nature.  Dave is working on
something which allows surface-level syntax other than what Wolfram
and Ping allow.  Insofar as this is true, we should get a feel for
its merits.

I will mention that TeX's macro ability has caused AMS (and I think
Elsevier) a fair amount of difficulty.  Malleability does have to be
clearly understood.  OpenMath is concerned that applications be able
to speak to one another, and this is certainly part of our concern as
well.  Malleability can sometime entail that applications don't speak
to themselves, let alone other applications.

We take as goals that notations be (a) renderable to sensory media
and (b) transformable to other classes of notations.  How can we
best carry on a conversation about what we have in hand?  The
abstractions we've discussed to date have so much latitude that
I don't have confidence where they will work and where they will
fail.  For me to know what we have, I feel I must know what it
is and what it isn't.  We can't go on saying that everything is

Suggestions as to a mode of discussion on how, e.g., we can evaluate
"targets" for translation of TeX data into HTML-Math are welcome.  I
only pose this problem, not because I think it is paramount, but
because I think it is something which will have to be accomplished
down the line and it gives us something to focus on.  Presumably
TeX notation itself cannot be a "target" as an HTML-Math form.