imageobject mathml, svg, other

<imageobject> and <imagedata> were recently
extended to allow MathML
and SVG children to <imagedata>. In fact, a second
update had to be
made to the content model to remove the restriction that
required
<imagedata> to have a fileref attribute.

Thank you for making this change to allow easy content
selection via
<mediaobject>.

I was wondering if the new locations for MathML and SVG data
felt like
a bending of the DocBook semantics to anyone else? It
appears (to me)
that the XSL stylesheets haven't yet caught up with these
schema
changes, so perhaps it isn't too late to reconsider the new
semantics.

MathML is typically displayed as a some combination of two
dimensional
boxes containing characters. User agents are able to keep
the MathML
baseline at the same level as adjoining text. On some level,
a MathML
expression is more like nicely formatted text than it is
like an
image, which might indicate a need to use <textobject>
instead of
<imageobject>. At least one Internet Explorer add-on
from Design
Science allows a computer to speak embedded MathML to the
user,
meaning it is in that sense an <audioobject>. Of
course, an image is a
good way to visually display mathematics, so
<imageobject> is a good
container as well. Still other applications can directly
consume
MathML as symbolic expressions, perhaps indicating the need
for
<expressionobject>.

Similarly, SVG can contain animation and (easily
recoverable) text, so
it is in some sense a <textobject> and a
<videoobject> content
candidate.

I was wondering if it would just be easier to take care of
these cases
and hedge against future XML by creating elements named
<foreignobject> and <foreigndata> (or something
similar) that could
contain non-DocBook XML, which parallels the same approach
within SVG.

If a particular "type" of <foreigndata>
becomes popular and needs
specialization, perhaps there could be a new specific
<*object>  and
<*data> element pair created for it, such as
<expressionobject> and
<expressiondata> for MathML.

Of course, the current situation is tenable. I only made
this
suggestion to increase modularity and decrease the
special-casing that
might be required in stylesheets.

Thank you for your work on DocBook.

-- 
http://chris.chiasson.nam
e/

------------------------------------------------------------
---------
To unsubscribe, e-mail: docbook-unsubscribelists.oasis-open.org
For additional commands, e-mail: docbook-helplists.oasis-open.org