Re: [dita-comment] DITA feedback

[Kristen James Eberlein <kris@eberleinconsulting.com>]

Hi, Ozana. We discussed your e-mail at today's DITA Technical Committee (TC) meeting. Please see my comments below.

Best,
Kris

Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)

On 12/13/2019 6:03 AM, Ozana Dragomir wrote:

Hello,

 

I would like to address some DITA limitations that are getting in the way, hoping they would be considered in the next DITA specification.

 

- <draft-comment> is allowed in <conbody> but not in <refbody> or <taskbody> - can it be made available everywhere?

<kje>The content model of the task topic is tightly controlled. If we were to enable <draft-comment> as a child of <taskbody>, it could only appear in a specific spot, for example, first or last child of <taskbody>. Most TC members on the call suggested that the appropriate place to insert a <draft-comment> that applies to the entire topic is within an abstract element.

We agreed that it would be useful to allow <draft-comment> as a child of <refbody>, but that we wanted also to consider whether the content model of <troubleshooting> might need to be modified before coming to a decision.</kje>

 

- <dl> is not allowed in a "pure" reference topic, unless wrapped in a section; our definition lists are styled like parameter lists (not tables) and we want to keep them like that and they are also reference topics

<kje>We did not understand your point here. Can you clarify? What is problematic about placing a definition list within a section?</kje>

 

- <fn> elements are not allowed in <conbody>, etc so they need to be wrapped in a <div> or <section> (we don't use <fn> inline, only <xref type="fn">) – can  <fn> be allowed in <conbody>, etc. ?

<kje>The <fn> element is an in-line element. Accordingly, we think they need to be contained in a block-level element such as <div> or <section>.</kje>

 

- MathML equations - long (wide) equations need to be treated as images in order to make them fit on the page for PDF format. For example:    

<equation-figure>

<image href="" width="6.5in"/>

</equation-figure>

o   None of the <equation-figure>, <equation-inline>, <equation-block>, <mathml> or <mathmlref> elements support the @width attribute and not even the @scalefit attribute (which we never use because it may lead to images or captions overwriting the footer).

o   <equation-figure> supports the @scale attribute, but using may require a lot of trial and error and if the equation changes, the scaling factor may need to be re-adjusted, so not a good solution for us.

My suggestion would be to allow the @width attribute for either <mathml> or <mathmlref>.

<kje>The MathML elements are specialized from <foreign>. The <foreign> element does not have any of the display attributes that are present on <image>, such as @width. We think that the solution here needs to be be handled in your stylesheets. If need be, you can use the @outputclass attribute to trigger templates.</kje>

 

 

Thank you.

 

Best regards,

Ozana

 

Ozana Dragomir – Information Developer, Automotive Operations

IMG-PVRTechAuthors@imgtec.com

Imagination Technologies Limited

t: +44 1923 260511

www.imgtec.com