Re: HTML/MathML integration

On 4/1/08, Neil Soiffer <Neils@dessci.com> wrote:
> I think that there are two meanings of "syntax" being used, and that is
> causing confusing.  In earlier email, I tried (unsuccessfully) to clear this
> up by saying that there is "user syntax" and "parser/implementor syntax".
> The former is what you tell users they should type.  The latter is what the
> browsers actually implement.  The later is complicated and messy and deals
> with also sorts of "weird" cases like

The HTML group has been treating what you call "user syntax" as "valid
html", and "parser/implementor syntax" as "user agent requirements".

> In user documentation, you would never say:

> > To create a level 1 heading, use the <h1> tag.  Feel free to throw in any
> unknown html element in the heading, it will be ignored.  You only need to
> close the <h1> tag when ...  Etc, etc.

Agreed.

> Getting back to MathML, producing complicated rules to say, this is what
> happens when you omit an end tag in this situation or leave off tagging in
> this situation is a really bad way to present MathML to users.  Obviously,
> in the HTML model, the parser implementors need to be told what should
> happen in those cases, but is it helpful to anyone but an HTML expert?

There is an in-between case.

There isn't any problem with MathML tutorials telling the same story
they do now.  But that story is too complicated for html, and offers
too many different ways to mess up.  With XML saying "tough", that
still works.  With html ... it gets horribly complicated.

The simplifications are to steer people who don't need the full power
towards a narrower path, so that there aren't as many different error
situations to recover from.

> Ian has already assured people that "classic MathML" will work in HTML5.  He
> said using a namespace prefix won't (Ian can you elaborate why you just
> don't ignore the "xxx" <xxx:mi>?), but otherwise, the MathML spec, user
> tutorials, and software can remain unchanged.

ian can answer better, but there are backwards compatibility problems
because of differences between the browsers.

> The open question is what should happen when the MathML has an error in the
> XML parser sense.  David and I both lean to "don't try to guess, because
> you'll likely get it wrong and I won't know" school.  We think the "repair"
> should be to wrap the offending part in an mtext (if it was missing a tag),
> do what it takes to build a valid MathML DOM, and wrap the whole thing in
> <merror> so that the user is informed something went wrong.

That is clearly right for XML.   It may be too draconian for HTML,
which traditionally never shows an error message.

-jJ

Received on Tuesday, 1 April 2008 18:42:36 UTC