I’ve misplaced my absinthe spoon. But we’ll get to that later.
I’d like to thank Mike for his glowing introduction and the opportunity to write about what’s become the centerpiece of my career, the magic and mystery of XML. To give you an idea where I’m coming from, I’ll establish my bona fides (pronounced in the style of Holly Hunter in O Brother, Where Art Thou).
I majored in computer science in college for exactly 2.5 semesters, at which point I determined that I was not only bad at it, but I didn’t care to spend my life balancing parentheses. So I did what anyone in that position would do: I switched to “Rhetoric”. This does not, as it would seem, entail wearing a toga and debating the great issues of the Republic, but is rather an archaic name for the professional writing program. So basically I have a creative writing degree, and may be one of the few people who also took a year of chemistry and physics on the way to getting it (and I was really bad at physics).
I got into publishing because I thought, and I quote, “If I’m going to be a writer, what better way to get into print than to work for a publisher.” Unfortunately, that’s a really bad strategy, especially when you find yourself working for educational publishing houses and you’re not planning on writing textbooks.
I started my career as a TeX typesetter. TeX, for those of you who haven’t had the pleasure, is a markup language that was created for math and technical typesetting. It’s been around since the ’80s, and at the time I was working with it, you basically typed in text, numbers, and codes to make books. And it works really well. You can make really nice books with it. Our company had developed a rich set of codes to facilitate this work, none of which I could possibly remember now. In fact, if I had to work in TeX now, I’d ask for an early ’90s IBM clone with no mouse, a green screen and a UNIX login. And I wouldn’t know what to do with any of them.
But what the TeX lifestyle introduced me to was the concept of content markup and the non-WYSIWYG publishing model. You had to compile all the code in order to see what the pages would look like. (We actually had to print them out because there was no onscreen viewer available.) So I’m not too worried about looking at a screenful of brackets and codes and expecting a properly-typeset book to come out eventually. It’s like that guy in the Matrix who, rather creepily if you think about it, is checking out “blonde, brunette, and redhead” on his glowy screen of symbols. You eventually get to that point. But not as pervy.
As in any publishing venture, I eventually got moved to an emergency project (i.e. this is really late so throw everybody at it) and had to learn Quark. I spent the next several years getting really, really good at Quark. Lot of good that did me. It’s a totally different way of working, and of looking at content, and of thinking about how pages are built. It has its advantages though. To tweak something, you click it and tweak it and see what’s going on as you do it. But you all know that. In TeX-land, you type in different codes and numbers and print out 50 versions before you get it right. Desktop publishing has made that workflow very unpopular.
After a job change and moving to the production coordination side of things (and the invention of XML which was a critical prerequisite), I eventually ended up, somehow, as the XML guy at my company.
So to recap: creative writing degree, background in typesetting and coordination, somehow given the task to XMLify some of our products.
I can’t offer technical tips and best practices for XML like Mike and Cinnamon do for InDesign. I can’t tell you how to write a DTD or an FO. What I can do is share my experience in how we implemented an XML publishing solution. Think of my as the guy in Office Space whose job was to take customer specs and give them to the engineers (“I’m a people person, dammit!”). In future posts (assuming Mike lets me continue after this rambling nonsense) I’ll lay out the steps you may want to consider taking in going from “Hey, we should be XMLing this” to actually producing things to, you know, sell.
So the absinthe spoon. I always keep it in the same place, and it’s not there. I have no idea where it is, when I moved it, or how to find it. I don’t have a kitchen index. I’m going to have to open every drawer and cabinet and pull everything out until I find it. And I have to do that now because I’m going to a party later where I’ve been asked to bring all my absinthe stuff, and the people there are very excited to try absinthe, and how am I going to show up without a spoon to put the sugar cube on? Ridiculous!
Have you ever had to find something that someone else worked on, years ago, and nobody remembers where it is? You need that Thing from that book that that one guy who quit 7 years ago to become a goat farmer worked on with a freelancer and maybe it’s archived and maybe not and Steve thinks maybe it’s on a Jaz disk that Mary used to keep in a shoebox in her bottom drawer before she moved to Switzerland and that Carol thinks is now on top of one of the cabinets over by Bob’s desk? Who HASN’T had to deal with that? So can XML solve that problem? Um, no, because the Thing is maybe on a theoretical Jaz disk somewhere in the Northern Hemisphere. But the use of XML in conjunction with a publishing system that stores and manipulates said XML could make that problem go away for future Things. That’s the first bit of advice: start by looking forward. Maybe you’ll put your old stuff in later (wanna bet?), but don’t worry about it too much as you begin to develop your solution.