From: Bruce Miller <bruce.miller@nist.gov>

Date: Thu, 12 Oct 2006 11:17:57 -0400

Message-ID: <452E5CA5.7030205@nist.gov>

To: www-math@w3.org

Date: Thu, 12 Oct 2006 11:17:57 -0400

Message-ID: <452E5CA5.7030205@nist.gov>

To: www-math@w3.org

David Carlisle wrote: > It doesn't matter if they are prefied or not, just what namespace they > are in. > > <m:math > xmlns:m="http://www.w3.org/1998/math/MathML" > xmlns="http://www.w3.org/1998/math/MathML" > xmlns:math="http://www.w3.org/1998/math/MathML"> > <m:mn>1</m:mn> > <mo>+</mo> > <math:mi>a</math:mi> > </m:math> But David, you're _assuming_ XML rules for interpretting namespaces! :> Of 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. -- bruce.miller@nist.gov http://math.nist.gov/~BMiller/Received on Thursday, 12 October 2006 15:32:14 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:38 UTC
*