MathML- Content markup, Modules, eXtensibility, and more thoughts.

Hey, I'm finally reading up on the Content-Markup section of the Spec
(MathML2.0, Chapter 4) now.  This trek through the spec is hard to follow, as my
mind is racing at 88mph, while my eyes can only go at nearly 3mph.  Oh well. :)

One thing I don't like about MathML-Content (MMLC) is that there are a great
many of built-in operators and constants.  I don't like this since it limits the
extensibility.  Therefore, taking a page from HTML, why can't MathML be
modularized as well?

Before I answer why, here's how I think MathML should be modularized:

1) Modules should be "declared" into the spec through namespaces.  Furthermore,
a "prefix:" namespace scheme should be used (what is this called again?).  This
prevents conflicts between modules (for instance, so that the <plus/> operator
of a algebra module can be differentiated from the <plus/> of a vector module,
as in the example prefixes <a:plus/> vs. <v:plus/>).

2) Each module should have a style-sheet (CSS or XSL or some type of
Math-Style-Sheet-Language) that specifies how to transform the content markup
into presentation markup for a specific media, language, culture, user, user
agent (UA) and etcetera.  There can also be a style sheets to transform the
content markup of one module into content markup of another, already content
module that known by the processor.  However, as a security precaution, a custom
module can only be transformed using the standard modules (see standard set of
modules below).  This prevents recursion of two modules being translated into
each other (causing an infinite loop in the processor).

3) Each module should have documentation, which may be accessed by the UA, to
provide a meaning for each element.

4) There should be a core module which contains the root element,
MathML-Presentation elements, MathML-Content elements of tokens, basic content
elements and semantic elements.  There can be a "strict" version (of MathML-2.0
non-depreciated elements), a "transitional" version (of MathML-2.0 + older
depreciated MathML-1.01 elements) and whatnot.  These modules should not be
declared with a prefix (unless embedded in another document, though).

5) There should be a standard set of modules that the W3C (or another
self-appointed body ;-) creates (containing the rest of MathML-2.0, for
instance).  These UAs should accept a public identifier for the namespace's URI
for these modules and the standard versions as well as an URL or other generic
URI (the choice of a public identifier or URI should be up to the author of the
MathML document).  These modules can be periodically extended by the W3C or
another standards-body.

Here are the advantages of using this scheme:

1) Authors can use those parts of MathML that they need.  Examples: An
elementary-level teacher might markup documents using an "arithmetic module."  A
professor of Vector Calculus may use both that module in addition to a trig
module and a vector module.  A philosophy teacher would probably use a
sets-and-logic module.  And so on...

2) This scheme is extensible.  People who need their own modules can create them
from scratch without using "heavy markup" or waiting for the W3C to approve
their submission for recommendation to the MathML standard.  In a practical
example a CS (computer science) major could create a logic-gate markup for his
senior project.  In another example, an electronics-analysis software package
could create an electronics-mathematics markup to analyze electrical circuits
(this markup is then transferred to a MathML processor for analysis).

3) This method is compatible with other mathematics language initiatives.  I
don't know much about OpenMath except that it is either an SGML or XML
application.  OpenMath markup could be implemented in MathML as external
modules.  Another standard that could be implemented is MathSpeak.  I am unsure
if TeX can be translated (surely there is an XML or SGML version of TeX or
LaTex) since I never used it.

You like?

---
Jimmy Cerra

Received on Tuesday, 16 April 2002 23:40:18 UTC