[SCL] XML syntax options

[Murray Altheim]

John F. Sowa wrote:
> Pat and Murray,
> 
> MathML has no semantics.  It is a formatter for
> mathematical formulas, which must be processed
> by some other software:

Bzzt. No. Every markup language has semantics. It's
whatever is the definition behind the markup. In MathML,
MathML in particular includes both presentational and
what they call "content" markup, but even the presenta-
tional markup has meaning. There is no such thing as
semantic-free markup. Even <b> in HTML means "bold". In
MathML, <forall> is defined as the "forall" of FOL.

  "As has been noted in the introductory section of this
   report, mathematics can be distinguished by its use of
   a (relatively) formal language, mathematical notation.
   However, mathematics and its presentation should not be
   viewed as one and the same thing. Mathematical sums or
   products exist and are meaningful to many applications
   completely without regard to how they are rendered
   aurally or visually. The intent of the content markup
   in Mathematical Markup Language is to provide an explicit
   encoding of the _underlying_mathematical_structure of an
   expression, rather than any particular rendering for the
   expression."
   http://www.w3.org/1999/07/REC-MathML-19990707/chap4_1.html

I'd also recommend reading

   4.2.6 Syntax and Semantics
    http://www.w3.org/1999/07/REC-MathML-19990707/chap4_1.html#sec4.2.6

   4.2.7 Semantic Mappings
    http://www.w3.org/1999/07/REC-MathML-19990707/chap4_1.html#sec4.2.7

   4.2.8 MathML element types
    http://www.w3.org/1999/07/REC-MathML-19990707/chap4_1.html#sec4.2.8

My point in this is that we *can* use MathML if our definitions of
the things we'd use in MathML are defined identically, otherwise
we can't. Now, there is to my eyes some naivete in the approach that
MathML has taken to definitions, in that they assume a mathematical
knowledge without providing *explicit* definitions. For things like
plus and minus this might be completely clear (hell, there might even
be subtleties about that for all I know), but I would guess based on
reading SCL drafts that the definitions of various things in SCL are
perhaps different in subtle but profound ways from this naive view of
math. Would somebody coming upon a MathML-encoded SCL document ever
be surprised by a definition? I certainly can't answer that. But you
all will have to figure that one out. But you can't wave your hands
in the air and claim that MathML has no semantics. It is completely
full of math semantics.

> MA> Just to be clear about my earlier reply, I think
>  > we simply can't use MathML unless the semantics are
>  > identical. Now... that doesn't mean that an *approach*
>  > to syntax similar to MathML isn't possible, i.e.,
>  > using an element-heavy approach.
> 
> Therefore, it would be possible to adopt the MathML
> syntax, and let the SCL processors interpret it
> according to the SCL semantics.

Not unless the MathML semantics and the SCL semantics are
identical. The MathML <forall> may indeed be defined the
same as 'forall' in SCL, but in each and every case where we'd
use a MathML element, we'd have to be sure that the definition
is the same. If SCL processors would process MathML different
than normal MathML processors, there'd be a problem.

Now, we could *steal* MathML and call it CLML or something and
declare that we aren't using MathML semantics, we're using these
semantics right here on page five of our specification, yes,
right there, past the coffee stain, no, move your hand... yes,
right there, where you see "by this we mean that".

> But I must admit that I was very disappointed when
> I first saw MathML.  I had expected something like
> the math formatting facilities developed by Bell Labs,
> which were cloned by many other groups, including
> LaTeX and the IBM GML processor I was using.

That's because MathML's purpose is not to supplant formatting
languages, it's to express mathematical formulae for both processing
and presentation. Typesetting markup doesn't capture any meaning,
just the font size, relative positioning, etc. In MathML, you
explicitly say things like "x is equal to negative b plus or minus
the square root of b squared minus 4 times a times c, divided by 2
times a":

   http://www.w3.org/1999/07/REC-MathML-19990707/chapter2.html#sec2.2.2

> Today, I just type the HTML symbols, such as &forall;
> &exist; &and; and &or.  Those are easy to type, easy
> to remember, and adequate for representing predicate
> calculus in HTML.  (It's also trivial to write a
> parser in Java or even Javascript to parse that
> notation.  No need for no f***king XSLT.)

f***king XSLT wasn't designed to solve that problem. For what
it was designed for, it is a lifesaver. It's a complex tool to
solve a very complex problem, and actually is quite well-designed.
(And you know praise for W3C products doesn't come easily to my
lips.) The solution you suggest only works in web browsers that
are hardwired to understand those specific HTML character entities
*and* have the necessary font support. We need something that
operates outside of the confines of a browser, so &forall; won't
do for us. In fact, absent a processor that each time reads a DTD
that declares what &forall; stands for, character entities aren't
even a very good solution for anything. Unfortunately, the W3C's
dislike of anything SGML-ish has almost left them without any
adequate alternative. Completely dropped the ball. So while we
now have XML Schema, you *still* need DTDs to declare character
entities. Duh.

Murray

......................................................................
Murray Altheim                    http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

   Now the Pentagon tells Bush: climate change will destroy us
   http://www.guardian.co.uk/climatechange/story/0,12374,1153530,00.html