There’s been a long thread on the xml-doc list about XML tools and workflows. I’ve kept my mouth shut, because my experience is only partly relevant—tech documentation is similar to but different from the kind of publishing experience I have.
I had to grin, though, when somebody popped up to ask if anyone had considered designating a person to do tagging, as opposed to assuming it’ll get done by other parties in the workflow.
Been there, done that, yeah; think it’s the best solution, personally, but am perfectly aware it’s got issues. Let’s talk about this a minute, because it illustrates some of the markup-workflow problems I everlastingly whinge about.
I’ve already mentioned why depending on authors to get all their own markup right is a bad idea. There are other reasons, of course, ranging from “unless your author is writing about markup, s/he is being paid to be an expert on something else!” to “what, you mean authors can type?”
In nine cases out of ten, though, it is cheaper and more efficient to keep author keystrokes. It’s not smart to blow off the nine cases and insist on rekeying everything merely because of the tenth. So to make those keystrokes usable you have to have a file-cleanup artist, and if you’re using markup, your file-cleanup artist is a tagger.
(Oh, man, I’m about to get umpteen Google hits on searches for graffiti, aren’t I?)
But, see, here’s the catch-22. You have this tagger, this person who understands markup well enough to apply it consistently and correctly. Your tagger marks everything up, parses files, corrects ’em, makes several passes through to nail finicky inline things like table/figure references and bibliographic links, parses again, and passes clean files on to the next person in line. If s/he is any damn good, s/he writes a lot of macros or regular expressions or little text-munging programs (or all of the above) to get work off his/her desk faster.
Pretty smart person, this tagger must be. Why are you wasting him/her on the dull, routine drudgework of cleaning up manuscripts? Markup and text-munging expertise isn’t exactly so thin on the ground that one cares to fritter it away.
Now, I’ve been this tagger. I’m damned good at it, if I do say so myself, and what’s more I happen to have just the right balance of enjoying routine tasks and enjoying automating them away to make a go of it. But I don’t know anybody else like me in that respect. I honestly don’t. The markup people I know get bored batty with the repetititiveness of tagging work, even if you can manage to convince them the work’s not somehow “beneath them,” and the manuscript-cleanup people I know don’t readily get their heads around markup.
So what to do?
One solution I’ve seen tried again and again is getting at the markup indirectly, by having authors and/or manuscript-cleanup people apply word-processing styles. It works, up to a point. It does (or can, at least) create files clean enough that the text can be extracted without issues, and most markup can be created programmatically. But, oh, the programming headaches of getting usable text out of Microsoft Word while retaining style information! Trust me, you don’t want to do this just to indulge your manuscript-cleanup people.
(That doesn’t mean you don’t want to do it… I’ll get back to that.)
What’s more, if you think this lets you out of hiring a tagger, you’re certifiable. The heartbreaking text-crunching problems of extracting your text from Word aside, your manuscript-cleanup people are not perfect (and your authors are vastly less so), and most word-processing programs all right, all right, Microsoft Word exacerbates human imperfections, especially with its ungodly cumbersome style-creation and -application interfaces. Any automation you try is going to have lapses and unanticipated edge cases that only a human tagger can fix.
What’s even worse, since the programmer creating the automation is neither a manuscript-cleanup person nor a tagger, the automation is liable to be brittle, unforgiving, incomplete—and difficult or impossible to fix. Yay. Why’d you do this again?
(I exaggerate, but only slightly. The one situation in which I saw this solution work reasonably smoothly involved a programmer who was himself a typesetter, did his own file prep, and worked closely with editors to boot. Bring in a clueless outside programmer and you’re only begging and pleading for trouble.)
Wow, what an impossible situation. To get this markup stuff done right, you need somebody who handles manuscripts with an eagle’s eye for accuracy, a viciously smart and capable somebody who nonetheless doesn’t mind getting down-and-dirty with manuscript after manuscript after manuscript for days, months, years on end.
Oh. Wait a minute. These people exist. They’re called “production editors,” “copy editors,” and “proofreaders.” And in my experience the best of them are quite capable of managing markup, though the less-capable do tend to kick and scream. Have I finally made sufficiently clear my strong and unyielding belief that if markup people don’t co-opt the editors, and that eftsoons and right speedily, markup in publishing is doomed? Have I?
The obvious way to co-opt them is to make working with markup easier than working with paper manuscripts. From what I have seen of electronic editing, this is eminently possible; editing on paper is a massive mess of kludges, red ink, and weird symbols. The editors I know who use Word simply fell in love with change tracking—it saves them ever so much hassle and brainspace. Change tracking. Name me three XML editors with change tracking. Jeez, markup people, get on the frickin’ ball already!
As it is, switching editors to electronic editing is adequate reason to implement a workflow through Microsoft Word that eventually leads to markup. Editors are that important; it’s worth hiring cleanup people and taggers to work around them.
I said earlier, in fact, that I thought hiring taggers was the best solution to markup integration in workflows. How can I think that, given the problems I’ve outlined? Well, how can I not? Publishing workflows are changing; markup is being added to them at several places in the cycle. How do you add a major technology to a workflow without also adding people who understand it?
Anybody with a viable answer to that one, contact me; I want to invest.
