Re: Exploring new vocabularies for HTML

> 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:51 UTC