Re: A reply to Bruce Miller proposal for online math

Bruce Miller wrote:
>
> OK, sure; set up a 3-way comparison between a CSS approach and
> a MathML both with & without fonts installed; fine with me.

Since fonts are now disabled, I will continue submiting some screenshots
without the special MathML fonts (including MathML test suite examples).
Once finished, the roundmap will be repeated now with special MathML fonts
installed in Mozilla.

>> It can be directly _duplicated_ as
>>
>> [::mrow
>>   [::mrow
>>     [::mi a]
>>     [::mo +]
>>     [::mn 3]]
>>   [::mo =]
>>   [::mi β]]
>
> That's interesting; it really isn't so much about MathML, but
> an alternative shorthand syntax for XML itself, and would work
> for _any_ xml format.

CanonML is now a superset of XML [*]. Therefore you can _duplicate_ any
XML that you want: OpenMath, MathML, SVG, XSL-FO, XHTML...

> I often use such syntax & structures
> for preparing data for XML serialization.
>
> Some would compare it to Lisp.

Indeed, it was derived from a modification of s-expr.

> And some feel the redundancy of
> close tags (as opposed to a balancing "]" or ")") isn't necessary
> for well-formed-ness; They'd say that's what emacs is for :>

There exist technical requirements for the elimination of closing tags
beyond verbosity and overheads of files size [*].

> Two questions: Why the "::" ? Is it a stand-in for namespaces?

It is a notation. Details discussed at [*], including namespaces,
"prefixes", multimarkup, and non-hierarchies.

> Secondly: what do you do when you need attributes?
> I'd suggest allowing an option something like
>   [mi {mathvariant=normal} a]

You are proposing a direct copy of the XML attribute model. The
limitations of the w3c XML attribute model and the new improved
"attribute" (annotation) model were througly discussed on [*]. You can
copy the XML attribute model for duplication of MathML fragments, but i
prefer a more general, powerfull and elegant model for annotations based
in ideas from SXML, ConciseXML, and liminal.

CanonML is a highly personalizable model and even its syntax is. You can
define something like above syntax if you like or others variant you can
imagine

[mi [:: [mathvariant normal]] a]

[mi [@mathvariant=normal] a]

[mi [@ [mathvariant normal]] a]

Even you could define a special MathML environment and write something like

[mrow
  [mrow
    [mi a]
    [mo +]
    [mn 3]]
  [mo =]
  [mi β]]

or more simple still

[mrow [mrow a + 3] = β]

using macros

a ==> [mi a]; + ==> [mo +]; 3 ==> [mn 3]

However, I am defining a special environment for mathematics and science
called CanonFormal (a kind of descendant of the original CanonMath
discussed here, remember?). For instance, the content MathML

<math xmlns:mml="http://www.w3.org/1998/Math/MathML">
  <mml:apply>
    <mml:eq/>
    <mml:ci>E</mml:ci>
    <mml:apply>
      <mml:times/>
      <mml:ci>m</mml:ci>
      <mml:apply>
        <mml:power/>
        <mml:ci>c</mml:ci>
        <mml:cn>2</mml:cn>
      </mml:apply>
    </mml:apply>
  </mml:apply>
</math>

is entered like [$$ E = [m * [c ^ 2] ]]

whereas the OpenMath code

<OMOBJ>
  <OMA>
    <OMS cd="calculus1" name="int"/>
    <OMBIND>
      <OMS cd="fns1" name="lambda"/>
      <OMBVAR> <OMV name="x"/> </OMBVAR>
      <OMA>
        <OMS name="sin" cd="transc1"/>
        <OMV name="x"/>
      </OMA>
    </OMBIND>
  </OMA>
</OMOBJ>

is [$$ integral [sin x] [diff x]].

There exists another version, a bit more verbose, using the :: notation,
but most of people is prefering the new $$ environment by now.

> Of course, while this form is a lot more typeable than
> straight xml syntax, you're still using the MathML "language"
> with whatever flaws it might have.

Exact! If you decide to encode MathML in a CanonML format, you recover the
redundancies, ultraverbosity (specially in parallel markup), base
interference in scripts and limitations on availability of structures,
fences’ formating semantics, DOM and CSS difficulties, problems with
entities, lack of compositionality [**], and rest of trouble. That was
main reason for the development of a special environment for mathematics
and science: CanonFormal.

The posibility to introduce a CanonML representation of MathML or OpenMath
XML data models is interesting just by backward compatibility, letting
individual users and bussiness (including publishers cited by R. Miner)
_the reuse of their current technical resources and databases_.

I do ***not*** plan to offer either MathML or OpenMath environment for
CanonML now. If a future MathML 3, 4, or 5 gots merit and gain popularity
then a special MathML environment could be officially developed, but I see
it unlikely.

> I'm personally prefer lisp-like syntaxes to ones where
> whitespace is significant, but the popularity of Python
> puts me seemingly in a minority.

WS rules are personalizable in CanonML approach and a Python-like
indentation can be defined by users and implemented in specific
environments. For instance, the SOX community could prefer something like
next

mrow>
    mrow>
        mi> a
        mo> +
        mn> 3
    mo> =
    mi> &beta;

for duplicating above MathML fragment, even if you dislike so one!

>
> I can't quite understand all your "modifications";
> you seem to be saying that when you make the conversion
> from your new input syntax to MathML that you want to
> generate badly structured MathML.  I would have thought
> that you would want to take the opportunity to generate
> good MathML, but whatever --- you can do it that way, if you like.
>
> In any case, I wouldn't think those modifications would apply
> to the input syntax itself (unless it is just a mapping of MathML),
> nor to the conversion to non-MathML formats.

I added two <warnings> in previous message but a <irony> would be more
effective, after reading you above.

> --
> bruce.miller@nist.gov
> http://math.nist.gov/~BMiller/

[*] Technical details and rationale for design options are contained in
Canonical Science Today [http://canonicalscience.blogspot.com/]. More
recent postings supersed old ones and even information here exposed.

[**] Strotmann, Andreas. Compositionality: A Content Markup Language
Design Principle. 2001
[http://www.uni-koeln.de/~a0047/publications/GKSC01.ppt]


Juan R.

Center for CANONICAL |SCIENCE)

Received on Friday, 21 July 2006 09:47:03 UTC