From: Bruce Miller <bruce.miller@nist.gov>

Date: Sun, 30 Mar 2008 21:42:34 -0400

To: Ian Hickson <ian@hixie.ch>

Cc: David Carlisle <davidc@nag.co.uk>, public-html@w3.org, www-math@w3.org

Message-id: <47F0418A.9090900@nist.gov>

Date: Sun, 30 Mar 2008 21:42:34 -0400

To: Ian Hickson <ian@hixie.ch>

Cc: David Carlisle <davidc@nag.co.uk>, public-html@w3.org, www-math@w3.org

Message-id: <47F0418A.9090900@nist.gov>

Ian Hickson wrote: > On Sun, 30 Mar 2008, David Carlisle wrote: >> Unlike the html case where you can try to specify full application >> behaviour even in error situations, mathml is intended primarily to be >> hosted by some other language (most mathematical expressions live in >> some wider context) and the application behaviour of xyz+mathml has to >> be mainly influenced by the application behaviour of the host language >> xyz. > > Oh, wow. That makes the job of integrating MathML into HTML orders of > magnitude more complicated. _Really_? It would seem to make it simpler; HTML5 can define the handling to be consistent with its own approach to errors.... Except that what makes it orders of magnitude more complicated is an (apparent) insistence that any sequence of characters is meaningful, or even, displayable math. Isn't this something we can get MathML3 to > define? What are the error handling rules for standalone MathML? MathML specifies an Error is an Error; Applications should do whatever is appropriate. exit 255 ? Status 500 ? Return to sender? Pop up a window with blinking red text? Perhaps we can specify rules, but I suspect there's a communication block about what you're looking for as "rules". Wouldn't > they want to be the same as for MathML in HTML? How do you get > interoperability in error conditions if you don't have rules for them? Well, I dunno; since interoperability with valid MathML seems to have such a low priority, interoperability with invalid MathML is even less a concern... >> In an HTML5 context you are not going to want (the equivalent of) a >> validity error on parsing which kills the entire document, that is >> clear. But the fixup should only be, that an implied merror (or mtext, >> perhaps) is inserted >> >> <math>1+2</math> >> >> couuld perhaps parse as (preferably) >> >> <math><merror><mtext>1+2</mtext></merror></math> >> >> rendering typically as 1+2 in a red border >> >> or perhaps we could consider whether it should parse as >> >> <math><mtext>1+2</mtext></math> >> >> redering as 1+2 with no mathematical spacing refinements. > > That doesn't seem to provide the optimum use for authors. You mean the latter example (without <merror>) is not optimum? If so, absolutely agreed. I would imagine that an appropriate error handling for MathML in HTML5 would (at least) involve inserting a virtual <merror> around the offending subexpression. Obviously, the further up the chain closer to the authoring stage that such errors can be caught & reported to the author, the better. >> But html5 should definitely not try to turn math into some kind of >> private html microformat that implies character-by-character >> tokenization and parsing of the character data resulting in >> >> <math><mn>1</mn><mo>+</mo><mn>2</mn></math> >> >> As Neil said, if you go that route why not add wiki syntax to html so >> that authors don't need to use <h*> markup for headings but can just use >> some ascii punctuation syntax? > > Well to some extent we are, e.g. with making <h1> the generic header > element and using <section> instead, and with making the outline algorithm > automatically infer "anonymous" sections based on header hierarchy, and so > forth. OK, but this is dramatically simpler than parsing math into anything useful. I suspect you're underestimating the difficulty in developing a non-trivial math parser and/or overestimating the usefulness of the results. -- bruce.miller@nist.gov http://math.nist.gov/~BMiller/Received on Monday, 31 March 2008 01:43:51 UTC

*
This archive was generated by hypermail 2.4.0
: Saturday, 9 October 2021 18:44:27 UTC
*