Re: [dita] MathML proposal for 1.3 -- early prototype questions

[Eliot Kimber <ekimber@rsicms.com>]

The block/inline distinction can be made on the m:math element itself--that
is why we only defined a single container. Likewise, the <mathml_container>
can itself be contained by elements specialized from <p> or <ph> as you
choose.

For example, in the D4P Math domain, I've provided various "equation"
elements that represent equations semantically, irrespective of their source
forms. Those elements can then distinguish between display and inline
equations. The key bit here is that "equationness" is the semantic separate
from the actual representation of the equation, which could be MathML, an
image, TeX markup, SVG, whatever. So in the general case there needs to be
another level of markup above <mathml_container> that is the semantic
equation. 

That is, <mathml_container> should be seen as parallel to <image>, not
parallel to <fig>.

Our goal with the MathML domain was to keep it as simple as possible, that
is, just provding the integration with the foreign domain and leaving the
larger semantics of equations for use-case-specific specializations.

However, there is obvious utility in having the sort of additional
equation-holding elements as I've defined in D4P and I would be open to
adding something built-in to DITA 1.3, perhaps as part of the Tech Comm
specializations? 

As for a reference--that makes sense to me, although I wonder if <image> is
sufficient since the element doesn't presume a particular format for the
referenced source. But maybe that's too indirect.

In addition, if we did provide a MathML-specific reference I'd want one for
SVG as well, since the MathML and SVG integrations are very much analogous.

So maybe we need a more general "foreign vocabulary reference" element from
which MathML and SVG references can be derived?

Or maybe we just need to clarify that <image> is expected to be used with
foreign vocabularies and processors need to expect it?

Cheers,

E.


On 4/10/13 7:51 AM, "Robert D Anderson" <robander@us.ibm.com> wrote:

> 
> 
> Eliot's been working on a proposal for a MathML domain in DITA 1.3,
> currently approved at stage 3, waiting for full specification write-up.
> Approved stage 2 proposal is here:
> https://www.oasis-open.org/committees/download.php/47115/proposal-13111-mathml
> .html
> 
> We're working on an early version of this in IBM, hoping to stay in line
> with everything that will be coming in DITA 1.3. We've come up with a few
> issues that may impact this proposal, and I was hoping to get some
> feedback / guidance.
> 
> 1. The proposal was approved at stage 2 with a specialization called
> <mathml_container>. That provides a single container for math content. Our
> internal stakeholders need to differentiate between math markup that should
> be treated as a block (for presentation / segmentation) and markup that
> should be treated as inline. Do others have this need? Is there a general
> feeling of which would be better - use 2 elements, use 3 (general and
> specialize for block/inline), or just use some metadata on the container to
> designate block vs inline?
> 
> 2. Our users would also like to store their MathML externally for some
> uses. In that case we'd like something similar to the <coderef> element,
> but keeping the semantic of foreign MathML. Would it make sense to have a
> content model inside the MathML container that allows an option - either a
> reference, or literal markup? For example, something like
> <mathml_container><mathml_ref href="externalMath.xml" format="mathml"/>
> </mathml_container>
> 
> Thanks -
> 
> Robert D Anderson
> IBM Authoring Tools Development
> Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 

-- 
Eliot Kimber
Senior Solutions Architect, RSI Content Solutions
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.rsicms.com
www.rsuitecms.com
Book: DITA For Practitioners, from XML Press,
http://xmlpress.net/publications/dita/practitioners-1/