How NOT to write structured documentation

King Oranges has an interesting blog post about How to dig 21 holes in a Structured Document. It's a good list, but it's not really specific to structured documents - the problems his Majesty highlights apply to any document, structured or no.

It did, however, inspire me to come up with this list that applies specifically to structured documentation.

HOW TO MAKE A CREATIVE STRUCTURED DOCUMENT (that is also a huge mess):

• Don't even think about creating a shared writing style, let alone a style guide that all content creators can refer to. Everyone has their own style. Let loose your creativity!
• On a related note, don't use the same format in all headings. If your H2 is a noun phrase and your H3 a verb phrase, so what if your H3 becomes a verb phrase H2 in a different configuration?
• ...or just change it, only for your content configuration. No one will notice, surely.
• Never use variables. Good old-fashioned text will do fine. If your product name changes, just do a global search-replace.
• For efficient reuse, use copy-paste instead of a shared repository of modules. If you edit your modules, upstream content can take care of itself.
• Use lots of 'br' elements to get the PDF pages to look nice.
• If you can't figure out what to do with an element, just leave it empty. Empty tags don't show up in the output anyway.
• Don't agree on a subset of DITA elements your documents will consistently use, just slap any old element in there if its tag name suggests it describes this particular sentence.
• Use formatting tags like 'bold' and 'em' instead of element tags. It looks the same in the output, doesn't it?
• Use lots of different element types for the same kind of content.
• Use the same element type for lots of different content types.
• As long as it looks good in PDF, just ignore the hierarchical structure.