Re: Exploring new vocabularies for HTML

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