15.5.1 Understanding how Mif2Go determines element nesting
For each element, Mif2Go considers whether that element can go inside the current parent element. If not, Mif2Go uses heuristic methods based on the possible parents, level limitations, and current context. To provide a parent element Mif2Go selects, in alphabetical order, the first wrapper element that can validly fit and that is permitted by your settings. Mif2Go does not interpret the DTD to determine element nesting.
For example, in the absence of project configuration settings that designate valid parent elements, you might find that most of your content ends up nested in <abstract>, because “abstract” is near the beginning of the alphabet.
As another example, suppose your document uses a sequential structure for steps in a procedure: paragraph format Step1 for the first step, followed by several StepNext paragraphs, all containing both commands and informational text. To convert this structure to a hierarchical DITA structure, with paragraphs in both formats becoming <step> children of a <steps> element, you would specify just one setting (see §15.4.3 Mapping paragraph formats to DITA block elements):
The first paragraph in the group forces creation of <steps>, because DITA requires <steps> or <steps-unordered> as the parent of <step>, and of the two valid candidate parents, <steps> comes first alphabetically. As soon as Mif2Go encounters a paragraph format mapped to an element that is not valid in <steps>, the parent tag is closed.
For problem cases, you can use a DITALevel marker to explicitly set the level for an element; see §15.5.13 Specifying DITA element levels. However, for nested lists, use a different approach; see §15.5.5 Specifying alternate ancestries for the same element.
> 15 Converting to DITA XML > 15.5 Nesting DITA block elements > 15.5.1 Understanding how Mif2Go determines element nesting