W3C home > Mailing lists > Public > www-math@w3.org > November 2006

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

From: Neil Soiffer <neils@dessci.com>
Date: Mon, 6 Nov 2006 22:04:50 -0800
Message-ID: <D1EFB337111B674B8F1BE155B01C6DD601533F81@franklin.corp.dessci>
To: "Ian Hickson" <ian@hixie.ch>
Cc: <www-math@w3.org>, <whatwg@whatwg.org>

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

If HTML5 ignores the MathML namespace declaration (as it apparently does
with other namespace uses), that is fine.  Similarly, if, because the
HTML5 parser doesn't *require* end tags or other soup-like things, it
doesn't matter as long as it accepts the end tags.  Same for quoting
attributes or other XML requirements.  As long as it isn't an error,
then you maintain compatibility with MathML tools.

Good MathML tools will try to tolerate some level of errors (and
typically report them to users).  If HTML5 accepts some MathML that is
in error, I don't have a problem with that.  It would be nice if it
indicated the error, but it isn't essential.

I hope I'm not missing something key in the difference between HTML5 and
XML.  I think it would be good to focus on the places where an HTML5
parser would potentially *not accept* MathML and try and resolve those.
Here's a very short list, with some work arounds that still allow valid
MathML to be used.

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.

Quibblers might point out that namespace-qualified attributes are
something that is broken, but if in that case the whole attribute name
were put in the DOM (eg,
myNonMathMLAttribute:substituteChar="&#0x2020;"), there wouldn't be a
collision with MathML attributes.  In any case, their use is very rare
and could be forbidden in a HTML5 MathML profile (the MathML spec may
not even mention using other namespaces for non-standard attributes).

2.  DTD declaration.  I don't know enough about HTML5 to know whether a
standard XHTML DocType declaration causes problems in HTML5.  If so,
again, I suggest HTML5 do what it typically does -- ignore it.  The main
down side would be the loss of the named character entities.  This could
either be solved by adding them as known to HTML5 or simply saying that
an HTML profile of MathML requires numeric entities.

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.

I'm sure others can come up with other areas, and I encourage a full
listing/discussion of them.

I hope I'm not missing something -- this seems like a relatively simple
way to move forward,

Neil Soiffer
Senior Scientist
Design Science, Inc.
~ Makers of Equation Editor, MathType, MathPlayer and MathFlow ~

-----Original Message-----
From: www-math-request@w3.org [mailto:www-math-request@w3.org] On Behalf
Of Ian Hickson
Sent: Monday, November 06, 2006 3:37 PM

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.

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,
preferably with proof-of-concepts or experimental implementations. It is
clear that not everyone will be pleased with whatever solution we end up
using, since the requirements put forward by the various contributors so
far are at best quite different and at worst contradictory. However, if
we have actual implementations to play with, we can at least try to base
our decisions on experience rather than guesses and opinions.
Received on Tuesday, 7 November 2006 06:05:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:42:12 UTC