- Why Edit If You Can Write?
- One Editor's Experience
- The Perfect Job for You?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
One Editor's Experience
After writing my book, I remained in touch with my acquisitions editor. In one of our email correspondences, she offered me an option to work as a technical editor of XML Primer Plus. After reviewing the tentative table of contents, I agreed instantly to join the team. I had no doubt that this was going to be an interesting project. As a fledging language, XML is constantly evolving. (And, as you'll see, writing a book on a language that's changing rapidly was certainly an adventure.) Secondly, I knew that we couldn't rely on XML coverage in the book to be exclusive, because XML-based applications still need a "hosting language" such as C++ or Java under the hood. The combination of XML and other languages seemed enticing, although it did present a challenge for us, as you'll shortly see.
Tech editing is a laborious and demanding task. A typical chapter in XML Primer Plus contained 40 pages (written and edited in Microsoft Word), with 15–30 code listings and dozens of figures. My duty was to check the technical accuracy of the book's content. This means, among other things, ensuring the use of correct and consistent terminology, verifying that all references to figures were correct, and of course testing the code.
Code testing isn't just a matter of copying text to an IDE and running it. In many cases, I needed to embed it in a driver program to make it compile. The reason is that a valid XML document must contain a heading with the standard declarations of the character encoding used (just like a valid C/C++ program must contain main(), for example). To avoid unnecessary and distracting repetitions in the printed book, these declarations were omitted from some of the code listings. In order to test these code snippets, I had to insert them into a template XML document, compile them, and report any error messages that my web browser would issue. As annoying as it may seem, there's really no other alternative method to ensure that the document is well-formed.
Fortunately, my duties weren't limited to this drudgery. As part of a team, I was involved in important design decisions—the hosting language conundrum, for example. The author, Nick Chase, decided to use Java as a hosting language for two reasons: its readability and his fluency in the language. However, in order to demonstrate the language-neutral nature of XML, we thought it would be best to include examples in C++, VB, and Perl in some chapters. How considerate of us! To accomplish this benevolent venture, the acquisitions editor hired additional programmers familiar with these languages to write the additional code and test it.
This decision exacted a toll. Due to the quadrupling of code listings, we had exceeded our target page count for the book, and had to waste precious time determining how to cut back on the material we had just added! As a compromise, we decided eventually to limit the code quadrupling to a few chapters where that was most useful, and stick to Java in all the rest.
Another dilemma that we faced had to do with DOM Level 3 Abstract Schemas. Nick hesitated to discuss this feature in his XML Schema chapter. In this case, a "wait and see" policy paid off. While we were busy focusing on other chapters, the W3C consortium dropped abstract schemas from the language. Timely resolution!
My job as a tech editor of XML Primer Plus was rather rewarding. Although it couldn't be compared to the excitement and verve of writing my own book, it certainly met most of my expectations. I did learn a lot about XML, and got better insights on why things are the way they are in the XML realm. Furthermore, the feeling of an intimate team working together toward a common goal under strict time restrictions has always brought out the best in me. Those of you who perform best under pressure know the feeling—torrents of adrenaline that fill you with energy and motivation to produce the best results, even if your job is to spot the tiniest nits.