Understanding the XML structure inside <menucascade> elements

[chrispitude]

This is just a curiosity, nothing is broken.

I noticed that when you create <menucascade> elements in the Oxygen editor, they are created in an XML block-element structure:

Code: Select all

        <p>Select <menucascade>
                <uicontrol>Foo</uicontrol>
                <uicontrol>Bar</uicontrol>
                <uicontrol>Baz</uicontrol>
            </menucascade> from the menus.</p>

In the DITA-OT's HTML5 processing (xsl/merged2merged/merged-whitespaces.xsl), I see the following template that strips away whitespace text nodes inside <menucascade>:

Code: Select all

    <!--
        Remove whitespaces from element-only inline elements that are formatted by oXygen.
    -->
    <xsl:template match="*[contains(@class, ' ui-d/menucascade ')]">
        <xsl:copy>
            <xsl:copy-of select="@*"/>
            <xsl:apply-templates select="*"/>
        </xsl:copy>
    </xsl:template>

But how does the Oxygen editor suppress this whitespace? If I author

Code: Select all

        <p>ABC<menucascade>
                <uicontrol>123</uicontrol>
            </menucascade>XYZ</p>

it shows up as a solid block of text "ABC123XYZ" in the editor. I looked in the $OXYGEN_HOME/frameworks/dita/css directory for something that might apply to whitespace <menucascade> text nodes in the editor, but I didn't see anything.

[Radu]

Hi,

When Oxygen loads the XML document in the Author page, it removes certain whitespaces. To know what whitespaces it can remove it looks at information from the association DTD/schema and also if the element is specified as space preserve in the CSS.
When the XML is saved on disk white spaces are added in places where again Oxygen knows according to the associated schema or DTD that an element can have only element children.

https://www.oxygenxml.com/doc/versions/ ... dling.html

For example Oxygen asks the associated DTD/schema about the "menucascade" element, it finds out it can only have elements as children (and no text content) so it can add or remove whitespaces between the child elements without influencing the XML semantic meaning.

Regards,
Radu

[chrispitude]

Thanks Radu, that makes sense!

For some reason, I always mentally pictured an inline-containing element (like <p>) as containing inline content all the way down through its descendants, in which whitespace was meaningful and got published. Now with your answer, I realize that indeed there can be "islands" of XML structure where whitespace is not published.

As an experiment, I dumped the content model of a topic and looked for all children of <p> that could contain elements but not text, and I got this:

Code: Select all

data-about
dl
equation-figure
fig
hazardstatement
image
imagemap
menucascade
object
ol
parml
simpletable
sl
syntaxdiagram
table
ul

Now I have corrected my mental model, and the <menucascade> behavior makes more sense!

We have legacy content (converted from binary FrameMaker) that has hardcoded ">" separators in <uicontrol> elements. I wrote a refactoring operation to convert these to a <menucascade> structure, using the indented element structure that Oxygen uses. If anyone is interested in this, let me know!