- From: David Carlisle <davidc@nag.co.uk>
- Date: Sun, 30 Mar 2008 23:42:11 +0100
- To: ian@hixie.ch
- Cc: public-html@w3.org, www-math@w3.org

> So there is no normative conformance requirement applicable to error > handling in MathML? That's unfortunate. Not none, but they are worded to take account of the embedded nature of MathML. For MathML2 they are: http://www.w3.org/TR/MathML2/chapter7.html#interf.error But as I said before that assumes that the error condition reaches the mathml system at all, which is not the case for a validating xml parser. > What are the error handling rules for standalone MathML? Wouldn't > they want to be the same as for MathML in HTML? Well first we need to make sure that "MathML in HTML" bears some resemblance to MathML, which is something that you seem to be suggesting is most definitely not the case. If the Markup language is unrecognisable as MathML it makes no sense to ask if the error behaviour is the same. But assuming that the final markup is recognisably MathML, you may still want different error behaviour. In particular the case of embeded html elements. If you stick an html element in the middle of a mathml expression, that clearly is an error condition in a pure mathml application. However you may (or may not) want to make this a defined non-error behaviour in html+mathml. Now from our point of view html is an important use case but not the only one, so it would be nice if there was a general mechism that defined how mixed languages were suppsosed to work, including specifying error behaviours and application behaviours such as event propagation etc. You indicated earlier in the thread that you didn't see that as necessary for html and html5 could just, if necessary, specify the entire html+mathml+svg story. html is an important enough case that this is probably workable and other cases (docbook, tei, ooxml, ODF, xsl:fo,..that also need to embed mathml (and svg) can perhaps work by example, or perhaps a general mixing mechanism can be abstracted out of the html case after the event. We'll see... > That doesn't seem to provide the optimum use for authors. Not arbitrarily and incorrectly "fixing up" expressions to be syntactically correct but probably wrong is beneficial to authors and readers alike. > Well to some extent we are, No you are not, as you know. You are slightly modifying the element structure for headings, but the way of marking up headings is to use element syntax, you are not introducing simple inline wiki markup for headings (and links and image inclusion and lists....) If you think <math> 1 + 2</math> should produce a fixed up mathml dom why not make <ul></li> optional and just say people can do * aaa * bbb as implemented in many wikis. The same arguments would appear to apply, it has some initial appeal to simplicity, it is obviously implementable. I don't think you should abandon html syntax for lists in favour of a wiki syntax, and I don't think you should do that for math either. There has been a lot of press recently on the desirability of reusing existing standards. You seem to be suggesting that the W3C of all organisations just abandons its 10+ year investment in devising a markup for mathematics that is now supported by a large range of mathematical and general editing software as well as web browsers, and replace it by something completely different, There are many useful discussions we could be having about the exact nature of the profile of mathml that could be included in html, and how nesting of html, mathml and svg in each other ought to work, but I can't see how contemplating throwing out mathml completely in favour of a system that requires the element content to be parsed and tokenised is helpful at all. David ________________________________________________________________________ The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. ________________________________________________________________________

Received on Sunday, 30 March 2008 22:42:53 UTC