imageobject mathml, svg, other

["Chris Chiasson" <chris@chiasson.name>]

<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.name/