From: David Carlisle <davidc@nag.co.uk>

Date: Wed, 4 Oct 2006 01:02:40 +0100

Message-Id: <200610040002.k9402egI010123@edinburgh.nag.co.uk>

To: ian@hixie.ch

Cc: www-math@w3.org, dev-tech-mathml@lists.mozilla.org

Date: Wed, 4 Oct 2006 01:02:40 +0100

Message-Id: <200610040002.k9402egI010123@edinburgh.nag.co.uk>

To: ian@hixie.ch

Cc: www-math@w3.org, dev-tech-mathml@lists.mozilla.org

> 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:-) DavidReceived on Wednesday, 4 October 2006 00:02:50 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Saturday, 20 February 2010 06:12:59 GMT
*