Re: MathML-in-HTML5

> So basically, it's the same as tag soup.
Not sure I understand that comment (given that incorrect input is
flagged as an error rather than being silently accepted) but let that
pass.

>  I don't really see an advantage to going down that route (with its
> complexities like namespace prefixes, etc) 

I was only suggesting the "route" in so far as the general idea of an
extension _mechanism_ that allows XML fragments (with a declared
rendering behaviour) rather than a fixed set of extensions, also
(if a fixed set of say html+mathml+svg is to be used) that 
at least the whatwg is aware of the IE approach and should consider
the possibility of defining things such that pages can be written to
work with both mechanisms.Backward compatibility with existing browsers
and existing pages is I know a major issue with html5 and there have
been mathml-in-html pages since IE 5.5 which is a long time.. Of course
in terms of number of pages as a proportion of the html web it's a very
small proportion, but still...

Irrespective of whether there is a general extension mechanism (which
mathml then uses) or whether mathml has a privileged position as a
"built in" extension, it seems there are three possible options

1) each <math>..</math> fragment has to be well formed xml (eg it's
   broken out and parsed by a real non-validating xml parser rather than
   than the html parser)

2) the math element is parsed by the html parser using a specifically
   extended version of the "html 5" parsing algorithm, resulting in
   a DOM that would be the same as if an xhtml+mathml document had been
   parsed by an XML paser.

3) the <math> element syntax in html includes some syntax forms that
   result in a DOM structure that doesn't match that of MathML.

Orthogonal to those three choices is the issue of whether to subset
(profile) mathml: all mathml?, all presentation mathml? a subset of
presentation mathml?, a subset, but including some mathml3 elements
(as yet unspecified, but Roger for example highlighted equation
labelling as something that should be looked at, which might lead to
wanting to add some features in MathML3 that are included in a profile)

Of the three numbered choices I _think_ I have numbered them in order of
preference. I'd be definitely opposed to (3) as that would I think be
specifying a different language that happens to reuse the name mathml
which would be confusing for everyone. 

Currently I place (2), which is I think what is being suggested for mozilla,
as 2nd preference but I  could be persuaded that that is the best
solution, especially if the "html" parser would allow (if not enforce)
_all_ the relevant xml syntax, especially empty element syntax />
(mathml has a lot of empty elements, although mostly that is in content
mathml) and namespace declarations. Even if they are ignored they
shouldn't be an error. pretty much all mathml is generated by tools or
mechanical assistance of some kind, and if those tools are using xml
syntax (as they are) then it won't always be easy for an end user to
"correct" that mechanically generated markup and replace xml idioms by
"html" ones.

Then of course there's the perennial question about what to do with those
entitiy definitions... (I suppose "can I give them to someone else" is
not an allowed answer:-)

David

Received on Wednesday, 4 October 2006 00:02:50 UTC