Simon wrote a good one that I’ve been meaning to nod at for a while. One sentence in particular caught my eye: “Distributing the cost of metadata by asking everyone to provide it also tends to annoy users pretty drastically.”
Not just true of users. True of people in a multi-step production process as well. Nor is it just true of metadata, unless we want to expand the notion of metadata to include every conceivable use of markup. People have to be cudgelled to work with markup that only directly benefits somebody else in the process.
Too many publishers think of this as purely an “author problem.” Those dratted authors. Won’t use styles. Won’t use markup. Well, I’ve got news: the problem persists all the way through the chain. Authors, frankly, are the least culpable, because they have the least sense of the whole process, and because they necessarily start with a document that is poorly-structured if it’s structured at all. (At least, I can’t write anything over two typewritten pages without making major changes to the structure at some point or other. I did learn to outline in high school, but it just didn’t stick.) So markup really can present more of a burden to an author than just about anyone else.
Later in the chain, we run into unnecessary expectations. Book designers, for example, have the word-processor’s tendency to see no structure larger than a paragraph, which drives markup people into utter madness. These people could learn new ways of looking at text—but nobody is telling them they should. So their myopia feeds back into the editing process, which is a crying shame because (have I said this before or something?) editors are THE key to getting markup workflows functional.
Pulling back a bit, we have to unlearn a bit of markup zen: that text has One True Structure. Nah. It’s got whatever structures turn out to be useful to us. Whoever “us” is at any given moment. The whole problem with markup in publishing production is that “us” varies. A lot.
It all leads to the question “how compatible are various players’ views of document structure?” My answer, based on some experience, is “fairly, but not entirely.” Which means there’s a lot of opportunity going begging for software that bridges the gaps.
In the meantime, it’s bloody expensive to massage the data for everyone’s needs.
