Ditabook and ditafile organization

Question

Other than the xref issue discussed in another thread, the map to ditabook functions not badly. Except, as also mentioned in yet another thread, all the fm-ditabook and fm-ditafile elements being red, so invalid, which doesn't really seem to inhibit book making.
However, my book map has, as chapters, other ditamaps. The top chapter topic comes in and is formatted properly by my edd/template. Sub-topicrefs, those within the chapter topicref, however, come in wrapped in their own fm-ditafile element, at the same level as the parent topic, and end up promoted. That is, whereas I'd intended them to be Heading2 entries, they are shown as Heading1.
Currently, I'm handling this my hand rearranging those contained fm-ditafile elements to fall under the parent topic. If I do that, I can also unwrap them, since the wrapper element now does nothing.
To those with more experience, is that a normal way of working?
I've not tried this, but it occurs to me that I might be able to edit the edd/topic files to accommodate fm-ditafile, to recognize it as a context to consider in deciding what style to apply. Would this be a better way to go? Can I even do it, given that the application regards these elements as invalid?
This whole area could use considerably more documentation than I'm seeing.
Presumably, the Leximation solution makes it all good, but I'm not looking forward to asking for even another $185 from my company atm.
Thanks
Bruce

Answer 1

Thanks, Scott. I'll look at the Lex stuff today or tomorrow. (Alas, my company has a history of not understanding the kind of higher math you suggest. ;) But I will make the appeal if I decide to go that way.)
I think I correctly understand the relations of ditamaps and hierarchy, but could always be mistaken in my beliefs. I did, however, just test my understanding against how dita-ot generates html from the same ditamap, and the hierarchy produced is as I expected. So, I expect it's an issue with FM's ditabook generator. So far so good.
A little more graphic detail, for the record. The top ditamap has:
map
..topicref
....[fm-topicreflabel]Collections.ditamap
collection.ditamap has:
map
..topicref
....[fm-topicreflabel]Collections.xml
....topicref
......[fm-topicreflabel]CollectionClass.xml
....topicref
......[fm-topicreflabel]CollectionCreate.xml
etc.
HTML output is as expected, with the topic from Collections.xml as H1, and the topics from CollectionClass.xml and CollectionCreate.xml as H2.
The structure in the ditafile becomes:
[fm-ditafile] href=Collections.ditamap
..[fm-ditafile] href=Collections.xml
....[topic] Collections
....[fm-ditafile] href=CollectionClasses.xml
......[topic] Collection Classes
....[fm-ditafile] CollectionCreate.xml
......[topic] Creating a Class
etc.
The structure appears ok, and one might think that the heading levels would be appropriate. But, the top level headings of all three files are being formatted as the equivalent of H1.
I see two possibilities.
One is that the second and third fm-ditafile elements should *not* be at the same level as the topic, but nested under it. If that's true, then FM is at fault, and editing of the appropriate xslt file is necessary (or, continue with my current hand-edit process).
The other is that this structure is correct, and I really should accommodate it by editing the edd to treat the fm-ditafile elements as contexts for applying styles. (Assuming the illegitimate (red) elements are accepted at all as contexts, which I've not tried.)
I could go either way. My real issue is that I don't have enough information on how Adobe intends these fm-ditafile elements to function in order to determine the better course. There's something wrong somewhere in what Adobe provides, but I don't know if this particular effect is their error or mine.
Bruce