Jon,
I've been looking into the status on the note in preparation on mixing
MathML and SVG. It isn't ready to be circulated yet, though your
inquiries have inspired another flurry of effort, and hopefully we
will be able to publish it soon. However, I can give you a short
version.
There are three obvious use cases:
MathML island in SVG
SVG island in MathML
non-hierarchical mixing of both MathML and SVG
The first two cases lend themselves to the existing extension
mechanisms on MathML and SVG. When you have a well-defined,
self-contained block of MathML that you need to include in SVG
(e.g. to label a graph with an equation), the tag is
probably the right way to go. I make no claims that the following
example is technically correct, but this gives the idea:
<?xml version="1.0" standalone="yes"?>
<svg width="4in" height="3in" version="1.1" xmlns='http://www.w3.org/2000/svg'>
<desc>This example uses the 'switch' element to provide a
fallback graphical representation of an paragraph, if
MathML is not supported.</desc>
<!-- The 'switch' element will process the first child element
whose testing attributes evaluate to true
<switch>
<!-- Process the embedded MathML if the requiredExtensions attribute
evaluates to true (i.e., the user agent supports MathML embedded within SVG).
< width="100" height="50"
requiredExtensions="xmlns="">
<!-- MathML content goes here
<math xmlns=">
<mfrac>
<mn1 </mn>
<mrow>
<msup><mix </mi><mn3 </mn></msup>
<mo+ </mo>
<mfrac><mix </mi><mn3 </mn></mfrac>
</mrow>
</mfrac>
</math>
</>
<!-- Else, process the following alternate SVG.
<text font-size="10" font-family="italic">
<tspan x="10" y="10">1/(x^3+(x/3))</tspan>
</text>
</switch>
</svg>
Conversely, when you have a self-contained block of SVG that you want
to incorporate into MathML (e.g. to draw some symbol or something)
then the MathML <semanticselement is probably the best choice.
Again, here is an example, which may not be technically correct:
<math
<semantics>
<csymbol definitionURL="elementary-stats.html#dice-4up"/>
<annotation-xml encoding="SVG1.1">
<svg xmlns="http://www.w3.org/2000/svg" height="137px">
<rect stroke="black" fill="none" rx="5px" width="40px" height="40px"/>
<circle stroke="black" fill="black" cy="30px" cx="30px" r="5px"/>
<circle stroke="black" fill="black" cy="30px" cx="10px" r="5px"/>
<circle stroke="black" fill="black" cy="20px" cx="20px" r="5px"/>
<circle stroke="black" fill="black" cy="10px" cx="30px" r="5px"/>
<circle stroke="black" fill="black" cy="10px" cx="10px" r="5px"/>
</svg>
</annotation-xml>
<annotation encoding="image/jpeg"copy dice4.jpg here </annotation>
<annotation encoding="image/gif" other="dice.gif"/>
</semantics>
</math>
The case where you really want to intermix MathML and SVG
non-hierarchically, e.g. to circle things in one equation and draw
arrows to part of another, is really hard, and we don't have a good
way to handle that worked out in any detail yet.
Anyway, that is what I can report. Hope it helps.
Dr. Robert Miner RobertM (AT) dessci (DOT) com
W3C Math Interest Group co-chair 651-223-2883
Design Science, Inc. "How Science Communicates" www.dessci.com

Dr. Robert Miner wrote:

I've been looking into the status on the note in preparation on mixing
MathML and SVG. It isn't ready to be circulated yet, though your
inquiries have inspired another flurry of effort, and hopefully we
will be able to publish it soon. However, I can give you a short
version.

There are three obvious use cases:

MathML island in SVG
SVG island in MathML
non-hierarchical mixing of both MathML and SVG

The first two cases lend themselves to the existing extension
mechanisms on MathML and SVG. When you have a well-defined,
self-contained block of MathML that you need to include in SVG
(e.g. to label a graph with an equation), the tag is
probably the right way to go. I make no claims that the following
example is technically correct, but this gives the idea:

Thanks, Robert.

With the help of the MathML and SVG mavens, I am slowly coming up to
speed on the global details of their implementation in Reader.

When I first asked how islands (or fragments) of SVG and MathML are
best implemented within XHTML 1.1 documents, I was assuming the simple
case of either a purely SVG fragment, or a purely MathML fragment,
embedded within XHTML. I was not thinking about how SVG may contain
MathML and viceversa (and either hierarchically or mixed), which adds
a lot of complication to matters.

Add to this that fragments of XHTML can also be embedded with SVG (and
I suppose in MathML as well), so things get very interesting.

Thanks again.

Jon Noring
Reader

The recent discussions reminded me an issue that (I think) we have
discussed here before but I thought it would be good to mention now that
version 3 is being considered.

I can't find now the relevant discussion but the issue was that
it would be handy if (presentation) MathML could represent somehow input
elements in order to have MathML fragments with missing parts that the
user could fill (for example, inclusion of (x)form elements -at least
some like input and select- would be ok).

I know for sure that there are several people and project that would
second this. For now we silently include input elements and we manage to
get away thanks to Mozilla's tolerance that allows it and render it
fine. In other cases, when converting to paper or for IE we have to
convert the MathML to XHTML first to stop plugins (e.g MathPlayer) from
trying to parse this invalid MathML.

Thanks,

Manolis

This is often important when building interactive test banks.
There needs to be a placeholder for an answer, and the answer
needs to be more than just a number.

Thus, a "blank" in the original display gets replaced by (potentially)
a non-trivial fragment of mathematics that the student has constructed.

Stan Devitt

Mon, May 09, 2005 at 10:59:40PM +0100, Manolis Mavrikis wrote:

The recent discussions reminded me an issue that (I think) we have
discussed here before but I thought it would be good to mention now that
version 3 is being considered.

I can't find now the relevant discussion but the issue was that
it would be handy if (presentation) MathML could represent somehow input
elements in order to have MathML fragments with missing parts that the
user could fill (for example, inclusion of (x)form elements -at least
some like input and select- would be ok).

I know for sure that there are several people and project that would
second this. For now we silently include input elements and we manage to
get away thanks to Mozilla's tolerance that allows it and render it
fine. In other cases, when converting to paper or for IE we have to
convert the MathML to XHTML first to stop plugins (e.g MathPlayer) from
trying to parse this invalid MathML.

Thanks,

Manolis

Manolis,

Thanks for your suggestion. I have long thought that at a minimum,
<mactioncould easily be extended to allow input. There might be a
better solution, but that would be an easy way to implement
something.

Steve Hunt from the first MathML group coined the term "hot spot"
editing to describe this kind of functionality, e.g. making an
equation where just an exponent is an editable field, etc.

The recent discussions reminded me an issue that (I think) we have
discussed here before but I thought it would be good to mention now that
version 3 is being considered.

I can't find now the relevant discussion but the issue was that
it would be handy if (presentation) MathML could represent somehow input
elements in order to have MathML fragments with missing parts that the
user could fill (for example, inclusion of (x)form elements -at least
some like input and select- would be ok).

I know for sure that there are several people and project that would
second this. For now we silently include input elements and we manage to
get away thanks to Mozilla's tolerance that allows it and render it
fine. In other cases, when converting to paper or for IE we have to
convert the MathML to XHTML first to stop plugins (e.g MathPlayer) from
trying to parse this invalid MathML.

Dr. Robert Miner RobertM (AT) dessci (DOT) com
Director of New Product Development 651-223-2883
Design Science, Inc. "How Science Communicates" www.dessci.com

RobertM (AT) dessci (DOT) com wrote:

>Thanks for your suggestion. I have long thought that at a minimum,
><mactioncould easily be extended to allow input. There might be a
>better solution, but that would be an easy way to implement
>something.

deciding on a common approach -even extending maction- would be great.

In order to have a valid document when we have to store it with
this kind of information we were using maction with various actiontypes
to differentiate the kind of input (box, dropdown) but these were adhoc.
The fact that there is no accepted (or recommended) way doesn't help as
renderers don't know what to do (apart from Mozilla where we have to
convert the mactions back to XHTML elements anyway).

>Steve Hunt from the first MathML group coined the term "hot spot"
>editing to describe this kind of functionality, e.g. making an
>equation where just an exponent is an editable field, etc.

yes, that's the kind of think we have as well or dropdown boxes with
values (perhaps stretching it a bit with values such as +, - in the
middle of expressions). As I said we struggle to have them rendered
especially for IE where we convert everything to XHTML which renders our
renderer (nice sentence!) useless.

Cheers,

Manolis

>The recent discussions reminded me an issue that (I think) we have
>>discussed here before but I thought it would be good to mention now that
>>version 3 is being considered.
>>
>I can't find now the relevant discussion but the issue was that
>>it would be handy if (presentation) MathML could represent somehow input
>>elements in order to have MathML fragments with missing parts that the
>>user could fill (for example, inclusion of (x)form elements -at least
>>some like input and select- would be ok).
>
>I know for sure that there are several people and project that would
>>second this. For now we silently include input elements and we manage to
>>get away thanks to Mozilla's tolerance that allows it and render it
>>fine. In other cases, when converting to paper or for IE we have to
>>convert the MathML to XHTML first to stop plugins (e.g MathPlayer) from
>>trying to parse this invalid MathML.
>
>>

Le 24 mai 05, 18:31, Manolis Mavrikis a :
>Thanks for your suggestion. I have long thought that at a minimum,
><mactioncould easily be extended to allow input. There might be a
>better solution, but that would be an easy way to implement
>something.
deciding on a common approach -even extending maction- would be
great.

As a little hint, tiny experience here shows that such elements would
need to be integrated with web-forms in the container language (if any)
as otherwise a communication la DM is needed (and that's fragile and
often unavailable).

I am not sure it is possible in full generality with XForms around, is
there any XForms guru around ?

At least it should be possible with XHTML forms and this element should
be, in ideal situations, submitted as a parameter as well.

paul