15.5.4 Deciding when to fully specify ancestry
You do not need to map paragraphs in [DITAParents] for elements that can have only one possible ancestry, or for cases where Mif2Go can determine heuristically which of the possible ancestors fits the context best. Specify ancestry in [DITAParents] when more than one lineage is possible in the context of use.
Include as many ancestors as necessary to fully specify ancestry for the element to which a paragraph format is mapped in [DITAParaTags]. If your document includes actual instances of different ancestries for the same element, use sets of ancestors to specify the alternatives; see §15.5.5 Specifying alternate ancestries for the same element. In some cases you might have to include all ancestors up to the topic level, and you might have to determine this necessity by trial and error; that is, list them all whenever not including all ancestors causes unwanted nesting.
When Mif2Go encounters a set of ancestors specified either in [DITAParents] or in a DITAParent marker, Mif2Go tries to nest the ancestor hierarchy in the current element. If the entire hierarchy is valid in that position, that is where it stays. This means that if your source document uses paragraph format Body (for example) for all text that is not nested in a list, and you map Body to DITA element <p>, you must also specify non-list parents for Body, because <p> can nest in <li>; in fact, in almost any block element. Unless you can make sure every block element that could precede a Body paragraph gets closed (see §15.5.9 Closing DITA ancestor elements), the Body <p> is likely to be nested in the preceding element.
> 15 Converting to DITA XML > 15.5 Nesting DITA block elements > 15.5.4 Deciding when to fully specify ancestry