In the context of HTML5 the term "tag soup" is meaningless,
since there is no UA-defined handling anymore
Error handling comes naturally and developers are not supposed to
put all resources into area that provides no real functionality.
It is UA defined and I don't know how HTML5 is suupposed to
change it if the UA that defines error handling today does not
participate in the process and due to its share faces no error
handling problems in the way others face them.
In the case of HTML5 (like in CSS, for that matter), error handling is
*not* UA-defined -- it is strictly defined by the specification
Well, following your definition of HTML5 (= everything that is served as text/html) it is clear that HTML5 UA is everything that processes text/html And how text/html is processes by UAs we all know.
But this is actually offtopic issue because we don't discuss here whether HTML5 is better then XHTML5 or HTML4 is better then XHTML2, or whether IS HTML is better then XHTML 1.1 etc.
What we say is that having two versions of MathML will not help us to consolidate efforts, instead it will dissipate already small resources that we have today. For example your proposal breaks compatibility with MSIE/MathPlayer, compatibility which was achived only recently, it took several years for them to recognize application/xhtml+xml and give people opportunity to serve the same markup to Mozilla and MSIE. There are tools that process XML only and not HTML. But the problem is not just compatibility. The kind of differences between HTML(always add 5 if you'd like) and XHTML(5) that you use to promote MathML in HTML are minor, they are to small to justify having two versions of MathML. While fundamental differences, such as being part of extensible framework, being able to reuse other standards that are primary targeted to XML and not HTML that W3C basically abandoned several years ago, being able to easily extend/revise/depricate some parts of MathML without affecting parsers and many other issues incline us to think that we should stick to one MathML and that MathML should remain to be XML based.
If all do their own thing today then how HTML5 parsing rules
could could be compatible with the way how browsers handle
incorrect ("tag soup") documents today.
I did a lot of extensive research before documenting the HTML5 parsing
rules, to ensure that the common aspects, which documents depend on, were
carried forward, while the more unique aspects, which documents did not
depend on, were simplified and unified.
Well we don't have this kind of problems in MathML. Stuff like <mfrac><mi>1<msup><MN>5</mfrAC>+3</mrow></msup></MN></miis not present in current MathML documents as wellformadness restriction eliminates them automatically (it does not ensure that markup is valid, but wellformadness is enough to ensure that you have the same DM across browsers). In addition it forces authoring tools and convertors to pay attention to what they produce, because if they will make mistake that leads to non-wellformed output it will immidiately break the page and they will have to ensure that markup that they produce is well formed by design. It is not the case for HTML authoring tools where problem can be just ignored (and is often ignored).
And once again let me note that MathML community does not have tagsoup
parsing problems today
If we go with the HTML5 route, it will continue not having such problems,
This is theory that I would not follow and it is far from reality.
since HTML5 strictly defines how all content is parsed.
SGML defined it a long long time ago (either you follow DTD or get error message), no one followed it when implementing HTML.
at the moment I see only one UA that wants to go in this way,
I don't think that others will follow it, in case of MathML tag
soup at least. HTML tag soup as such may be different issue as
here browsers have motivation coming from the large amount of
legacy content so if HTML5 will reverse engineer MSIE error
handling and document it others may find it useful, but once gain
this is not an issue for MathML implementations where we lack
implementations in browsers (so even absolutely valid markup is
not treated properly) and are talking about specifying
comprehensive error handling that people are supposed to devote
time and resources to.
The parsing (and error handling) rules for the proposed math-in-HTML5 is a
_subset_ of the general HTML5 parsing (and error handling) rules,
We don't want to inherit HTML legacy through parsing rules or otherwise.
We managed to avoid it for a price that appeared to be quite high, but it is payed already and is not refundable. Today you can serve the same XHTML+MathML to MSIE and Mozilla and use a lot of XML tools, following your proposal we will loose this and gain nothing valuable instead (more tag soup).
such
that any browser that implements HTML5 parsing automatically is compatible
with HTML5+Math parsing.
We already use the same parsing rules for MathML and all other XML applications (I assume including XHTML5 unless you will invent something new).
(The only requirement then is that the UA also
implement MathML itself, so that the resulting DM is handled per MathML
rules.)
Yep once one implements tagsoup parser then he/she can also start implementing MathML itself. Thanks for permission. Some would go other way round and provide functionality first and then maybe error handling (and maybe not, who cares?).

Fri, 6 2006, White Lynx wrote:

What we say is that having two versions of MathML will not help us to
consolidate efforts, instead it will dissipate already small resources
that we have today.

The proposal doesn't create a new version of MathML, it just provides a
new way of serialising MathML content, and generating a DM from that
content (deserialising it). The MathML language is left intact -- the DM
is the same, the rules for processing the DM are the same, and the
semantics for such a DM are the same.

For example your proposal breaks compatibility with MSIE/MathPlayer,
compatibility which was achived only recently, it took several years for
them to recognize application/xhtml+xml and give people opportunity to
serve the same markup to Mozilla and MSIE.

That will continue to work and continue to be just as conformant. The
proposal just seems to be adding a new serialisation/deserialisation
format, it doesn't stop people from using XHTML.

Anyway, I'm not the one you have to convince. If you don't want Roger to
experiment, convince him, not me. I'm just looking for implementation
experience so that, going forward, I can make educated decisions.

Wed, 11 2006, Roger B. Sidje wrote:

Hence, either I go off and add support for the plain <math></math>, which
will only work in Mozilla out-of-the-box and wouldn't be quite an overture to
IE+MathPlayer (without yet again content negotiation or some JS trickeries by
authors),

(Though there's no reason MathPlayer in a future version couldn't support
this themselves.)

or to get seamless interoperability, HTML5 may need a provision for
prefixed tags (at least in the case of MathML),

Note that this wouldn't get us interoperability just like that. We'd have
to reverse engineer the entire IE extension mechanism and specify a
compatible version. From what people have said so far, it sounds to me
like that would be a lot of work.

Given how little the namespace-prefix syntax has taken off, and the number
of people who are confused by namespace syntax of any kind, and the large
amount of content on the Web that uses namespace-like syntax in a way that
would break renderings if it was interpreted according to namespace-like
parsing rules, however, I would strongly recommend against any sort of
namespace-based parsing extensions to HTML. As I mentioned before, I've
worked with an implementor in the past who tried to do this, and they
ended up wasting months of intense work trying to be compatible with the
large amounts of legacy content before eventually backing out the whole
thing and ignoring namespaces in text/html content.

David Carlisle wrote:
It doesn't matter if they are prefied or not, just what namespace they
are in.

<m:math
xmlns:m=""
xmlns=""
xmlns:math="">
<m:mn>1</m:mn>
<mo>+</mo>
<math:mi>a</math:mi>
</m:math>

But David, you're _assuming_ XML rules for interpretting
namespaces! :course, you have to assume at least
some subset of XML rules for current IE to work.

Part of this discussion seems to be what, if any, namespace
rules will apply to HTML5. If I've correctly followed
the discussion, there seems to be 3 alternatives:
(1) XML Rules
There seems to be some resistance to this.
(2) Namespaces are meaningless/ignored in HTML5,
but are necessary for IE's xml islands.
There are two subcases:
(a) <math xmlns="">, with HTML5 ignoring the
"xmlns" attribute.
(b) MathML names are defined by HTML5 as "m:math", etc.
(or whatever pseudo-prefix you like)
<m:math xmlns:m=""
with HTML5 ignoring the "xmlns:m" attribute.
In either case, "portable" HTML5+MathML would be
invalid HTML5, having unknown attributes.
And both would require MathML tools to generate
only a very specific form of XML, hurting interoperability
(3) Any other special interpretation seems to
assume that an IE8 will come out soon and implement it.
Moreover, if namespaces confuses authors now, just imagine!

[]
>So let's go with <mspan(for pcdata, allowed only in <mtext>) for
>text styling via CSS and <mlink(attribute href, content pcdata,
>allowed only in <mtext>) for "web page anchors" with text/html
>compatibility.

But is that really an improvement over the status quo for say mathml in
docbook? If we are going to open up mtext (and I'm not sure we should at
all) I still think I'd rather allow some (or all) of the "host language"
elements into mtext so that the result is explictly contstrained to work
in those environments.

While I certainly sympathize with Bill on wanting to
have such nesting possibilities, I'm not fond of adding
in little bits here & there. I'd much rather push for
a proper solution at the level of compound documents.

David Carlisle wrote:
>But David, you're _assuming_ XML rules for interpretting
>namespaces! :

yes but I was answering Bill Hammond's question about

course, I understood. I was just taking the opportunity
to tease, and also the opportunity to summarize
(as I understand it) that we currently seem wedged
between a desire to simplify (and avoid namespaces)
and a desire for IE to work as is (w/o waiting \infty for IE8).

I guess I'll take that as a further opportunity
to reiterate that point :>

In application/xhtml+xml there seems to be more than one understanding
so xml is implied here (despite the subject line)

>While I certainly sympathize with Bill on wanting to
>have such nesting possibilities, I'm not fond of adding
>in little bits here & there. I'd much rather push for
>a proper solution at the level of compound documents.

We're in total agreement here, although whether that's because we've
independently come to a naturally correct conclusion or if it's just
that we've both been fully absorbed into the collective group-think of
the working group, it's hard to tell

A third possibility is that I've simply come under the
sway of your overwhelmingly domineering personality

(sorry, I'm in a kind of jokey mood today).