Re: MathML-in-HTML5

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

> ... If you use unprefixed elements inside m:math without declaring
> the default namespace to be mathml then that's an error, ...

Yes, but some user agents nonetheless recognize MathML names inside an
instance of <m:math> when it has no default namespace declaration.
This is where we have a current lack of inter-operability with
application/xhtml+xml.

Moreover, <math xmlns="mathml-namespace"> should be workable in
"html5", while any use of prefixed elements in html5 (text/html)
is a non-starter for inter-operability, Mozilla experiments not
withstanding.

About compound documents under NVDL:

>> Might one not have user agent internal security concerns about this
>> unless validation by user agents is mandated? 
>
> Any plugin architecture (or any browser) or any software at all,
> really, has some security implications. I don't see that the issues
> here are any different than any other web page browsing. If I
> install firefox (for example) on my machine then basically I need to
> trust that it, itself, is not malicious.

Of course.  My point was about user-agent-internal-security, e.g.,
browser crashing, rather than user platform security (other than
possible loss of user time or "work" inside the browser).

>> 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
> constrained to work in those environments.

My original suggestions about content in mtext were limited to the
XHTML+MathML document type.

But for that matter, what might "work in those environments" mean for
mtext content in MathML in DocBook beyond surviving an XSLT flow
toward XHTML+MathML or a translation toward PDF via, say, \text{}
inside math in LaTeX?

I think most of us would use \emph{}, \textbf{}, and \href{}{} inside
\text{}.  Maybe a few other things, but not many.  I think it needs to
be controlled to be sane.  How, if at all, should <mtext> content
found in MathML in DocBook relate to CAS systems?  It's certainly not
semantic, but might there be some use?

> If you add mlink to mtext, or css-styled mspan then you have to
> specify what that means in docbook, or maple etc where there is no
> css, and the linking models are rather different.

Is it specified at all in either DocBook or Maple what <mtext> itself
means beyond the obvious point that it's not semantic?

<mspan> as a MathML element could be given various attributes for
the names of up-translations to various host languages.  Also mspan,
which would by boilerplate carry the "class" attribute could carry
also a math utility attribute called "mclass".  For simplicity an
<mspan> without any attribute could be said in the specification to
represent emphasis.

                                    -- Bill

Received on Thursday, 12 October 2006 21:15:09 UTC