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

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

Noz, thanks for the detailed reply. A few brief responses:

> I seem to have confused things by saying 'sections'. My point was if you
> do away with <section> (the element) then users will need to use topics to
> divide up their content into 'sections' (the things). Therefore, <topic> =
> section, because it becomes the element used to logically section up the
> content into blocks. <section> just goes away. Hence at one point I meant
> <topic> but said section.

Right — I've slipped into using "section" on occasion when I meant "topic". I seem to remember Eliot writing that "section" was a poor name choice in retrospect, and I wouldn't disagree.

> About your heading/nav issue, Joe, I think that the map could easily be
> used as the default and the @chunk attribute used for overrides to tell
> processors where to add headings in navigation. If the map points to it,
> it goes in the nav. If it's nested in the topic, then it doesn't, unless
> some clever person overrides it with a @chunk. There's a lot of simplicity
> benefit in just having map=nav in a 1-1 relationship.

Though it might need some creative stylesheet workarounds, I can see that working really well for authors in a specific situation. The map is providing the affordance of representing the navigation — a clear mental model. Of course in other cases (the majority of DITA for Publishers users I would guess), the specialized nested topics would be expected to contribute to the navigational hierarchy, so as ever it comes down to the individual implementation.

> Unless we no longer require titles, then I keep getting stuck on the
> creative workflow problem of creating something that you don't know is
> going to be a topic/section/headed-block until long after you've created
> it.

This is where dealing with larger chunk sizes (i.e. allowing nested topics) can improve usability. Within a given CMS object / file, if you're able to create and remove headings as you need, it's a lot easier than having to create a bunch of separate single-topic storage objects. Of course the tradeoff is that you can't then easily reorder the nested topics to suit a particular output context. For all practical purposes, you're stuck with the order you authored it in originally. Sometimes that's fine; other times more granularity is needed.

> What about having a way to require a title for creator-use only? e.g., You
> can have a title-less topic, but if so, you need to give it some sort of
> description line so that it can appear in searches, allowing you and your
> colleagues to know what that loose content actually is.

Makes sense, and I'm actually doing this in a very specific case for a client at the moment. It's a specialized topic that will be chunked to a parent, and the title will be suppressed in output (including navigation of course).

> I liked this article a lot, which discusses this for HTML5
> (http://www.brucelawson.co.uk/2010/html5-articles-and-sections-whats-the-difference/).
> In it there was an example would map perfectly to a <topic>/<section>
> world, but in a <topic>/<topic> model, then the topic without it's
> subtopics would not be a sensible topic, and topics aren't nesting at the
> bottom*. I think that's something we can safely leave as "their problem".

Yes, agreed. Though as a side point I think they messed things up a bit in HTML5 by allowing a numbered heading (h1, h2, etc) to take on the level of the containing section. I think they should have defined a new, hierarchy-neutral <heading> element for that case.

Joe