Re: [whatwg] The problems with namespaces in text/html

 
> Please keep your tone moderated and maintain a positive attitude when 
> posting to the WHATWG mailing list. Being sarcastic or abrasive in the 
> context of this community should not be tolerated.

Really? Instead of appealing to unmoderated tone, better answer question that was raised several times, but were ignored. We are talking about serious issues here and there is no point in avoiding direct arguments even if you don't like tone. 
And please keep your *decisions* moderated, and first think what you are doing, what consequences should one expect, how it may affect other parties involved in process before making populistic steps that may damage markup language.


> Focussing on the issue at hand, I would recommend those taking part in the 
> part of this discussion that relates to Math markup to suggest 
> constructive solutions for how to move forward in a text/html world

As it was stated many times converting MathML to tag soup is not a the way to "move forward".
Below is brief summary of steps forward that are about to be made (as a part of constructive solution).

Step forward 1. No more extensibility.
To introduce any new attribute or element you need to wait years for changes on spec level (if you manage to convince those who cook specs to made such a changes), then several years more before changes will be made in tag-soup-parsers (again if you can convince all browser vendors to make such a changes), and the several years to ensure that authoring tools and other software will follow browser vendors.
As there are no namespaces and no extesibility, it is impossible to add semantic layer to presentational markup (currently this is done through OpenMath vocabulary using namespaces, and relying of extesibility of XML, or using content MathML markup which is not the part of WhatWG "proposal"), it is impossible to combine MathML with any other XML vocabulary.
(X)HTML is not the only host language for MathML, many parties including publishers use different DTDs that capture structure of scientific articles better then (X)HTML. After all there are only three block level structural elements "p", "div", "pre", "address", two of them has no semantical value, while another one has broken content model that does not allow other block level elments inside, so we are left with "address", alone it is not sufficient to capture structure of average article that contains something more then address, this is what (X)HTML achived in more the ten years of development. This does not mean that (X)HTML is not important for MathML, it definetely is, but difference between HTML and XHTML is definetely not big enough to tear MathML into pieces espesially taking into account scale of the problems that arise after moving to tagsoup.
	
Step forward 2. No more interoperability.
As it was stated many times, there are no MathML tools that support HTML but lack XHTML support, and a lot of MathML tools that never encountered tagsoup before. Here is incomplete list: OpenOffice (uses XML based format that may include MathML, moving to tag soup is not an option), Microsoft Office 2007 (import/export of MathML relies on XSLT, moving to tagsoup will make conversion less reliable), Mathematica (imports/exports MathML, moving to tagsoup will make conversion less reliable), Maple (the same arguments as for Mathematica), Antenna XSL formatter (one of the few commercial tools that provides decent printing quality crucial for scientific publishing, XML based by design, moving to HTML is not an option), Prince XML formatter (one of the few publishing oriented CSS formatters, primary XML based, moving to tagsoup is undesirable), multiple XML tools (some of which rely on XSLT) to convert MathML to ECMA OMML, LaTeX and other formats, moving to tagsoup makes them less reliable), MathPlayer Plugin for MSIE (can handle tagsoup, but as it was stated many times this can be done in a very particular way in which MSIE passes prefixed elements to plugin, it requires namespace prefixes to be used and Microsoft representative in Math WG stated that Microsoft will not provide alternative mechanism to pass MathML to MathPlayer so this limitation will stay with us in near future, Murray can correct me if I said omething wrong, WhatWG proposal is not compatible with the way MathPlayer operates so interoperability with key plugin is lost, in the same time plugin handles application/xhtml+xml fine without any requirements to use prefixed elements or some MSIE specific declarations needed to trigger plugin), MathType (can import/export MathML, moving to tagsoup will make conversion less reliable), Publicon (the same arguments as in acse of MathType), WebEQ the same arguments as in acse of MathType) etc. In addition there are browser vendors that prefer to deal with MathML in XML framework (because this provides better extesibility, less resources are wasted on handling of ill-formed tagsoup, interopearbility with other MathML implementations is ensured, once markup is well-formed DOM is unambiguosly derived) rather then tagsoup format.

Step forward 3. No more UA independant DOM.
As some stated here DOM is important, no one doubts about this, but it is clear (and people pointed out to this) that wast majority of MathML tools do not operate trough DOM and have nothing to do with DOM so stating that DOM is the only thing that matters in MathML context (or even in "web context") is basically stating that text/html folk do not want to see anything beyound their noses. But once it matters in web framework, let me remind that you have DOM if you have notion of elements and attributes, in XML there is condition that ensures this, it is well-formedness condition (XML document that is not well-formed is not XML document). In tagsoup there is no such a condition.
Consider simple case
<maTH display="block'><mrow<mn2</mN><mo>+</MO><mn>2</MaTH></mn>
what is DOM here? Natural thing to do is to see what current browsers serialize. Here are results:

Original Input

<html>
<head>
<title>Serialization of tag-soup MathML-in-HTML</title>
</head>
<body>
<div> </div>
<div><maTH display="block'><mrow<mn2</mN><mo>+</MO><mn>2</MaTH></mn></div>
</body>
</html>

Firefox 1.5

<html>
<head>
<title>Serialization of tag-soup MathML-in-HTML</title>
</head>
<body>
<div><math display="block'"><mrow><mn2></mn2><mo>+</mo><mn>2</mn></mrow></math></div> 
</body>
</html>+2

MSIE 6.0

<HTML>
<HEAD>
<TITLE>Serialization of tag-soup MathML-in-HTML</TITLE>
</HEAD>
<BODY>
<DIV>&lt;maTH display="block'&gt;<MROW<MN2< mN><MO>+</MO><MN>2</MATH></MN></DIV>
</BODY>
</HTML>+2

Opera 9:

<html>
<head>
<title>Serialization of ill-coded MathML-in-HTML</title>
</head>
<body>
<div>&lt;maTH display="block'><mrow <mn2</mN=""><mo>+</mo><mn>2</mn> </mrow>
</div>
</body>
</html> display="block'>+2


You can try other browsers for fun, but the point is if DOM matters then tag soup is not the most interoperable way to derive DOM from.

Step forward 4. Unpredictable markup

Many people including me complain about some designed decisions made by Math WG at early stages, but one merit that MathML has is that it is stable spec that did not change for a long time, that make it possible to achive some king of interoperability and so there are more MathML tools then users (as markup is not human processable each user comes with its own tools). What we will gain after involving WhatWG in process, is uncertain, unpredicatable markup with vague goals. One can not implement anything because next day WhatWG may turn everything upside down and ask interested party to reimplement it once again, while "implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways".

I hope that this is all that we will gain after "move forward". If there are any plans to spoil something else in addition, please fill free to let us know. Also it is interesting how people that admit that setting up proper content type for XHTML documents is "mission impossible", plan to deal with problems of completely different scale outlined above (as well as mentioned many times by other people on this and other mailing lists and simply ignored many times by Ian and company). 

P.S. My previous message was blocked by moderator of WhatWG mailing list, I suspect this message may be handled in the same way. In any case copy is sent to www-math.

-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

Powered by Outblaze

Received on Tuesday, 7 November 2006 12:28:58 UTC