|
||||
| DCLab.com | About DCL | Tech Info | Press Info | Contact Us | DCLNews | Partners | Wiki | Client Area | ||||
|
"Who
in their right mind wouldn't want XML?"
During a quiet moment in his busy schedule, DCLnews asked Bob how XML is changing STM publishing? Bob Hecht: "Things have begun to take on a slightly different spin in electronic publishing over the last couple of years. Basically, it's not just about product anymore; it's about process. We've found that most of the top-end journal compositors are now using composition engines that can interact directly with markup, keeping any localized formatting instructions encapsulated to avoid impacting SGML or XML source files. That brings an interesting twist to the picture in that our compositors are finding that it makes a lot more sense for them to tag their content up front. They're saying that their process supports an SGML or XML workflow and that's how they're managing publisher content to begin with." DCLnews: That would be very attractive to producers of electronic journals...
Bob Hecht: "Sure. Who in their right mind wouldn't want to take advantage of that? Once you realize that a tagged file is a by-product of the process, why wouldn't you want to make that part of the compositor's deliverable? Compositors are tagging the material up front before it gets to the point of actually composing a page. They're not doing the conversion on the tail end -- unless, of course, they're using a generic DTD internally and then transforming it to a publisher-specific DTD on the output side. Personally, I would prefer to have my content tagged directly to the final specification on the first pass." DCLnews: So tagging drives their systems? Bob Hecht: "Correct, however, the publisher's tag set must be robust enough to support the output specification. Otherwise the compositor has to continually tweak the content during the formatting stage and that undermines the validity of the source files because those tweaks rarely make it back into the markup." DCLnews: How does your particular electronic publishing process work? Bob Hecht: "Dekker is in the process of automating many of our current production routines. At the moment we have implemented several steps that are preparatory to a more complete approach. We take approved content from the editorial process and provide electronic and print components to the compositors. We're not doing any of the production work in-house. Once the compositor gets the files they immediately put it into their XML workflow. What I'm addressing in this discussion is that, regardless of whether the publisher requests markup as a deliverable, many composition houses push manuscript through an SGML workflow because it saves time and money. " DCLnews: Is this sort of thing common with compositors? Bob Hecht: "The majority of compositors still work in Miles, Penta, or XyVision systems. However, those systems are evolving as the system vendors are being forced to support an XML-in workflow in their tools to stay competitive. I'm confident that once the benefits of this type of workflow become apparent, any supplier with the capability will hop on the band-wagon." DCLnews: Have you considered using XML as part of your own internal workflows? Bob Hecht: "Of course. Workflow is a huge issue for publishers right now. Dekker is looking at how best to implement a re-engineered workflow, either in pieces or on a larger scale. During the publishing process there are many rounds of revisions. We get the accepted manuscript from the editor, get it tagged, then run a first proof, and send it back to the author for revisions. From there somebody marks it up and sends it back and yet more is done to it. In short, things are added, revised, and removed all the time, which increases the chances of errors being introduced - especially if it is all being done manually. How many people are in the middle determines how screwed up it gets. To prevent deterioration, information needs to be captured during the entire process in a controlled and verifiable way. XML looks like the best solution for this -- and the question of where it fits into the workflow needs to be addressed by STM publishers." DCLnews: Can XML increase profits as well as improve quality? Bob Hecht: "Having your content in electronic form gives you the opportunity to build new products and embrace major changes in the industry -- such as making content available on handheld or wireless devices. This has been proven repeatedly. But production groups like Dekker's have realized for some time that an XML workflow can cut down production costs if implemented properly. It's not top line growth, but if you can cut the operational costs of your organization you're looking at making an impact to bottom line growth. Again, it's seeing XML as part of the process and not just as a product enabler." DCLnews: What do you consider to be the key strength of XML as we move into the future? Bob Hecht: "Information loses its value as it ages. So it's critical to publish things quickly. Nature magazine recently initiated a program titled AOP (Advance Online Publication) where they post extremely time sensitive material to the web on a weekly basis, significantly ahead of the print publication without compromising the quality or accuracy of the content. For now I believe this only applies to selected articles, but it is an example of what can be done with an efficient production model. September 11th had a big impact on the need to publish information fast. One of the things recognized by emergency crews was, it's not necessarily what you know that is important, but when you know it. There were numerous occasions when fire crews had to enter buildings with hazardous materials inside. They needed to have information immediately about things like what happens when specific chemicals are exposed to 800 degrees of heat. XML is an enabling technology that makes it possible to get information to people quickly." 13/8/2002
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Data Conversion Laboratory, Inc. 61-18 190th St., 2nd Floor, Fresh Meadows, NY 11365 718-357-8700 convert@dclab.com Copyright © 1997-2008 Data Conversion Laboratory, Inc. All rights reserved. |