Re: [xml-dev] SVG and MathML in HTML5

[rjelliffe <rjelliffe@allette.com.au>]

 On Sat, 28 May 2011 11:58:02 +0100, David Carlisle <davidc@nag.co.uk> 
 wrote:
> On 28/05/2011 09:58, Jesper Tverskov wrote:
>> As we can read in the HTML5 spec, we can nest SVG and MathML inside
>> not well-formed HTML5 served with mimetype "text/html". We can also
>> read that SVG and MathML don't need to be well-formed:

 As soon as they are nested in some other format, they *cannot* be 
 well-formed XML anyway. XML starts at the entity level: the physical 
 structure: bits at the start of a representation.

 That you have to alter the notation seems to me to be no more sinister 
 than that in Java you might have to encode an XML document as
    "<p a=\"fred\">" + "hello</p>"

 XML inside HTML is HTML not XML.

 I have long held the view that it would be more suitable for there to 
 have been an XML-slack which would allow HTML idioms of error-recovery, 
 for use for XML vocabularies encoded as foreign HTML elements in HTML. 
 So, depending on whether the HTML5 people have taken any liberties, it 
 sounds pretty useful.  (Although XML insude HTML is HTML, but it would 
 be good if it were XML-ish and XML-able and XML-leaning and XML-friendly 
 HTML.)

 The public is best served by moderate plurality emerging from real 
 usage patterns: sloppy people can use MathML vocabulary in sloppy HTML 
 syntax in pure HTML documents, gung ho people can use draconian XML 
 syntax in well-formed XML documents, the JSON people can make up a JSON 
 binding, etc, and the tools to translate in between them will crop up. 
 The idea that there should only be one notation for anything is, of 
 course, not Stalinist, but just not the way the world works: standards 
 always have to fit in with that.

 Indeed, I think it is mixing of notations higgedly piggedly (ie islands 
 of XML) not to mention willy nilly that is more dangerous and burdensome 
 on developers than keeping the notations clear and distinct. An XML 
 parser will not parse all HTML; an HTML parser will not parse all XML; 
 the intersection of them (trying to be XML and HTML at the same time, or 
 having islands of XML) may be more trouble than it is worth.

 Cheers
 Rick