OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Robert,

For what it's worth, when we implemented support for Arbortext's proprietary
equation markup in DITA, we wound up creating both inline and block
specializations of <foreign>: <inlineequation> and <equation>. If you have a
reasonably recent version of Arbortext (I think we added it in 6.0 M010),
look in the application\com.arbortext.dita\entities folder for how we did
it. It might be slightly different from the MathML case in that the
Arbortext equation markup has two root-level tags, also designed for inline
vs. block, so both <inlineequation> and <equation> are *styled* as inline;
it's what they're allowed to contain that dictates the final rendering of
the equation.

Chris

-----Original Message-----
From: Robert D Anderson [mailto:robander@us.ibm.com] 
Sent: Wednesday, April 10, 2013 8:51 AM
To: dita
Subject: [dita] MathML proposal for 1.3 -- early prototype questions


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-math
ml.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 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]