May 8, 2003
By Pat McGrew, EDP
Welcome to the HVCO Data Management Pavilion of OutputLinks.com!
Last time we met we were talking about the relevance of transform programs. The context was a set of postings on a popular forum by a vendor who proudly announced that print streams should not be converted.
What emerged from discussions on the forum was that the vendor distrusted the parsing routines. He did not believe that they could handle all of the variation that might occur. A response on that forum from Bill McDaniel, EDP, set the record straight on why this technology is so well understood in our industry. He said, ?Stripping print codes, recognizing that a chunk of data is text, positioning it, all these are technologically interesting and challenging, but well understood and doable.? He went on to make the point that the print files in our industry are typically structured in such a manner that parsers work effectively on them for the same reason they print consistently. Our parsing tool kits are full of keyword triggers, pattern recognition techniques, floating field triggers, position detectors and all manner of other techniques that give today's program designer the ability to create robust, enterprise-ready programs that can automate the transform process and the data extraction process.
This is important to understand and recognize because there are many consultants who have areas of expertise in specific industry verticals but who do not have expertise in information delivery based in high volume computing output. Those consultants may understand the legal industry, telecommunications, insurance, banking, manufacturing, or other vertical, but without understanding all that we do daily in our industry they could easily steer an unsuspecting client down an inappropriate path.
Imagine the scenario where you are using many applications to create print output. Because of how the applications have been built over the past 25 years, there are COBOL bridges and other processes that manipulate the data for each account in a print run all of the way up to the point where the final print stream is heading for the print queue. Now there is an initiative afoot to post the print image of all output to the web. The sponsors of the initiative don't care if you use PDF, HTML, XHTML or even .GIF images; they just want it done in the shortest possible time frame.
This is no time to try to go back and re-engineer the systems that produce the print. This is a time to consider a transform utility that can be installed and tested against a known test bucket of files, and integrated with the mechanism needed to drive the output to the web as needed. This is where transform utilities shine!
The vendor who started me down this path ended his white paper by saying that if you really wanted to use a conversion program, the best idea was to write it yourself. Next time we'll look at why this is a really horrible idea!
If this is valuable, drop us a line at pm@outputlinks.com!