MathML, namespaces, and DO(O)Ms

Neil Soiffer said:

> I have been reading the discussion and at times I am perplexed.  Being a
> user and implementer of MathML software, the key point to me is that
> HTML5 accept valid MathML.  Without trying to restart the argument,
> MathML tools produce text, not DOM trees, so it is crucial for
> compatibility that HTML5 accepts (ie, does not reject/error on) MathML
> syntax.

On [http://annevankesteren.nl/2006/10/html-wg]:

<blockquote>
Juan R., try learning something about the DOM and perhaps about the web as
well. The web relies on HTML so defining how it works and upgrading it a
bit is a very good step in the right direction.
</blockquote>

Fortunately, Anne van Kesteren and others explained me how the web works.
A simplified outline is as follow.

<begin-irony/>

You write a XML/HTML document using a text editor or some specific tool
(including the hundred of MathML tools listed here and XSLTs converting
from other formats as OMML). That file is a DOM.

Next, you upload to the server. The server stores that DOM in disk.

When client solicits a page, the server sends the DOM by the wire.

Once at the client, the browser parsers the DOM and construct a HTML (or
XML) serialization of the DOM. This serialization is *not* permanent and
stored in physical memory.

Maybe the user want a local copy of the web page. Then by just clicking on
the save button a copy of the DOM -not the temporary serialization in
physical memory- is stored in local disk.

This local copy (is a DOM) can be used by off-line tools as editors, CAS
software, conversors to other formats as SVG or LaTeX, etc. For instance,
I could copy a MathML formula from a Web page in a scientific library and
copy it into Mathematica for some computation. Next the result is output
as MathML and stored at server XY. User J dowload file (a DOM) and at
client side transforms it to LaTeX or to XSL-FO (another DOM) for
printing.

P.S: Comments at http://annevankesteren.nl/2006/10/html-wg were closed
just before my sincere aknowledge for the learning provided.

<end-irony/>


> 1.  Namespaces.  As I suggested before, ignoring the declaration for
> namespaces doesn't break anything that I know of in MathML.  This is
> particularly true since apparently the MathML tags would go into a
> MathML namespace in a DOM.

I already read to one responsible of mathematical markup from Microsoft
(also MathML guy) recommending usage of prefix m:

<blockquote>
The reason is that these XMLs are useful in many contexts, not just in
HTML(5) and using namespace prefixes allows the XML parser to delegate to
the appropriate tag-set owner.
</blockquote>

Ignoring the declaration does not work in all browsers (a 60% of the
browsers got broken) and generate incompatibilities. Both <mrow> and
<m:mrow> are valid XML elements. <m:mrow> would generate error in a HTML5
UA. Whereas HTML5 <mrow> would generate errors with some XML tools.

> This could
> either be solved by adding them as known to HTML5 or simply saying that
> an HTML profile of MathML requires numeric entities.

This will break the web also. HTML5 does not introduce MathML entities,
therefore several tools (and hundred of legacy docs) automatically are
HTML5 invalid. Moreover, readability of docs relies on non-numeric
entitities.

If we are ready to break compatibility with legacy MathML then we would be
ready to follow steps i sugested many many time ago introducing radical
changes in MathML correcting current design mistakes (then i was said by
Miner and others that breaking backwrd compatibility was a non-issue).

Breaking backward compatibility maintaining design mistakes sound strange.

> 3.  Empty tag syntax.  I suspect that this is more problematic for
> HTML5, although I think a "repair" mechanism/specification or a minor
> syntax addition to HTML5 could be specified.

In above link i argued for a mixture of HTML and XML with XML-like empty
syntax. Read the reply from one of WhatWG collaborators. They are against
XML and want to do everything á la HTML way.

What is a "repair" mechanism/specification? An internal pre-parsing layer?

Received on Tuesday, 7 November 2006 09:07:56 UTC