From: David Carlisle <davidc@nag.co.uk>

Date: Wed, 11 Oct 2006 17:08:40 +0100

Message-Id: <200610111608.k9BG8eCV013750@edinburgh.nag.co.uk>

To: hammond@math.albany.edu

Cc: www-math@w3.org

Date: Wed, 11 Oct 2006 17:08:40 +0100

Message-Id: <200610111608.k9BG8eCV013750@edinburgh.nag.co.uk>

To: hammond@math.albany.edu

Cc: www-math@w3.org

> In application/xhtml+xml there seems to be more than one understanding > among current user agents on the question (given the use of namespace > prefixing) of whether or not inside an "m:math" element unprefixed > subelements (at all depths) are mathml. As far as the specification goes (which is, I think what Mozilla does) the situation is clear: Elements in the MathML namespace (whether prefixed or not) are MathML, elements that are not in the MathML namespace (whether prefixed or not) are not MathML. Mozilla actually implements a compound document format where mathml, xhtml (and probably svg) can be nested in ways that are not individually sanctioned by the respective specs but in ways that could be sanctioned by schema languages designed for the purpose, such as ISO/IEC 19757-4 NVDL (Namespace-based Validation Dispatching Language) http://www.nvdl.org/ This doesn't work in IE+MathPlayer (and the Math expression, once extracted, would not work in any other MathML application, as it is MathML+XHTML, not just MathML). This difference in behaviour though is due to implementing (or not) a compound document format that allows the various languages to be extended, it isn't a difference in understanding which elements are mathml. I think actually that that is the way it should be. Rather than start adding html-like elements such as <b> <i> to <mtext> which might look natural in mathml-in-xhtml but would look distinctly odd in mathml-in-xslfo or mathml-in-docbook, I think we should keep the leaf elements in "pure" mathml as more or less just pcdata, but encourage larger fromats to use nvdl (or the W3C's CDI compound document by Inclusion format's once that has been specified) to allow richer markup at mtext and perhaps other token elements. This then makes it clear that the richer markup is not "mathml" and there is no obligation on CA systmems, etc to implement it, yet it does allow (at least the specification of) documents with commutative diagrams marked up as xhtml (for the document) containing svg (for the diagram arcs) containing mathml (for the diagram nodes) containing xhtml (for marked up text in the formulae) DavidReceived on Wednesday, 11 October 2006 16:09:06 UTC

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