24.5.3 Fixing up interpolated ancestries

Creating DITA structure from formats necessarily involves some trial and error. When you see unexpected interpolation of inappropriate parent elements in your output, it is usually because you have not specified parents for a particular format-to-element mapping. For example, suppose you map paragraph format Ref to <p>, and use a Ref paragraph at the top level of each reference topic, where <p> is not valid. On encountering a Ref paragraph in this situation, with no parents specified for the Ref format, DITA2Go would go through the list of valid parents for <p> in a reference topic, and interpolate the first set that works; which might be <codeblock><draft-comment>.

The remedy is to figure out what would be a more appropriate lineage for the element in question. You could specify that lineage for the format in [DITAParents] if it applies generally, or insert a DITAParent PI marker in the paragraph for an isolated instance. In this example, the following mapping would produce better results:

[DITAParents]
Ref = refbody section

The DITA2Go search algorithm finds the shortest path, but that is not always the only shortest path, or the best path.

See also:

§24.4.3.4 Omitting invalid tags for default DITA block elements

§24.5.6 Avoiding invalid ancestries

Previous Topic:  24.5.2 Designating DITA ancestor elements

Next Topic:  24.5.4 Deciding when to fully specify ancestry

Parent Topic:  24.5 Nesting DITA block elements

Sibling Topics:

24.5.1 Understanding how DITA2Go determines element nesting

24.5.2 Designating DITA ancestor elements

24.5.4 Deciding when to fully specify ancestry

24.5.5 Specifying alternate ancestries for the same element

24.5.6 Avoiding invalid ancestries

24.5.7 Specifying first-child status for nested elements

24.5.8 Configuring nested lists

24.5.9 Closing DITA ancestor elements

24.5.10 Opening DITA ancestor elements

24.5.11 Configuring multi-paragraph list items

24.5.12 Specifying DITA element levels