Omni Systems, Inc. Mif2Go User's Guide, Version 55
> 15 Converting to DITA XML > 15.5 Nesting DITA block elements > 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.