Re: [dita-lightweight-dita] Full DITA compatibility

[Joe Pairman <joe.pairman@mekon.com>]

Cheers Noz. Just two quick clarifications before I need to leave the thread for now:

> I think that having users set whether a title is a title for nav or not is
> a simple work-around. Although that doesn't really fit well semantically
> into @chunk (not that @chunks is particularly clear or straight-forward at
> the moment. @chunk=to-self could turn on titles in nav? I'm just riffing
> here).

Where there were a need for authors to manually switch on/off navigation for specific nodes, something along those lines makes sense. As a general point, though, it's always been up to implementors how to define these kinds of navigational / presentational rules, and Lightweight DITA doesn't attempt to constrain that side of things further (at least if I've understood the initiative correctly).

(I'd started talking about navigation as an illustration of the intent of <section>. While you *could* get section titles into navigation, it seems like going against the grain, and you'd still be prevented from nesting sections.)

>> Of course the tradeoff is that you can't then easily reorder the nested
>> topics to suit a particular output context...

> There's no problem with reordering nested topics provided the parent topic
> content doesn't move...

Right. I just wanted to point out that the tradeoff of keeping child topics in the same storage object is that you have to edit the CMS object / file to reorder them. If you're doing it for a specific output context only (re-ordering for a particular audience segment or product, perhaps), it means duplicating the object in some way. When each topic is a separate storage object, you can re-order topics in a specific map for that output context.