`
`
`
`
`
`Merrill Communications LLC
`d/b/a Merrill Corporation
`Exhibit 1006 pt. 3
`
`

`

`

`

`

`

`

`

`

`

`

`

`

`

`196
`
`CHAPTER 14 I HITACHI SEMICONDUCTOR
`14.1 1 Phase 1: Creating a single source
`file
`
`The main drawback of the original process was that Hitachi Semiconductor
`could not render PDF files from the SGML source, and had to render them
`from the RTF file instead. "Without a single source file, we could not have
`a high confidence level that we were producing PDF files from the same
`version as the SGML file," says Tabone. "That was unacceptable from a
`quality standpoint."
`
`In addition, the company had to manually add bookmarks and links to
`the PDF files that were created from RTF, a process that required an average
`of five hours per documem. At 40 documents per month, this meant the
`company spent 200 person-hours recreating information that already
`existed in another format. Long publishing lead times left the company
`with out-of-date documen ts: approximately 30 percent of published pieces
`became obsolete whi le on the company's shelves.
`
`use of Adobe
`the
`adopted
`When Hitachi Semiconductor
`FrameMaker+SGML software in late 1996, the company became able to
`maintain a single source file and to shorten lead times. The product has
`since become one of the most important tools in Hitachi Semiconductor's
`publishing suite.
`
`Hitachi Semiconductor can now produce PDF files from the SGML
`source, simply by choosing the "Save As PDF" command (see Figure 14-2).
`By saving the hyperl inks from the SGML file and automatically creating
`bookmarks FrameMaker+SGML eliminates a labor-intensive process. Hita(cid:173)
`chi Semiconductor is able to provide print vendors with production-ready
`files because FrameMaker+SGML handles composition and pagination of
`the data sheers and auromatically generates indexes and tables of contents.
`
`Hitachi Semiconductor wrote a Perl script to automate the check-in pro(cid:173)
`cess into the document management system. The script validates the
`SGML files, notifying their creators if any errors are present, and converts
`EPS files to GIF files. This automated process give
`the company confi(cid:173)
`dence it is using the correct source file and also dramatically reduces the
`time required for editing, proofing, and publishing (see Figure 14-3).
`
`©19 9 8 T HE XML H A NDB OO K™
`
`

`

`

`

`198
`
`CHAPTER 14 j HITACHI SEMICONDUCTOR
`
`ple, there is nothing today that wiU enable our customers to search our
`document set for all chips with performance in a certain range." The answer
`to these problems came in the form ofXML.
`"XML provides the scructure of GML without its complexity," says
`Tabone. An added benefit for the com pany, whose authors are in Japan, is
`that XML accepts only integrated double-byte character supporc.
`
`14.5 1 "Publishing on steroids"
`
`When the eXtensible Style Language (XSL) specification (see Chapter 35,
`"Extensible Style Language (XSL)", on page 516) is complete, Hitachi
`Semiconductor will use itt automate data transformations - for example,
`specifying the location and appearance of an element of type 'author."
`"XSL will enable us to specifY the production process as well as the con(cid:173)
`tent- in the same markup language," says Tabone. "We'll acquire a sure,
`solid methodology for automating the processes throughout the production
`environment, from input to delivery. No longer will we need special filters
`and dedicated people to run the transformations. It's publishing on ste(cid:173)
`roids". (See Figure 14-4.)
`Adobe recently added the capability to save FrameMaker+SGML files as
`XML. Prior to this availability, Hitachi set up a process, using commer(cid:173)
`cially-available parsers, to adapt its SGML documents for use with XML.
`Around 80 percent of the parsing happens without any manual interven(cid:173)
`tion, so Hitachi expects that the adaptation process will take four months
`or less.
`
`14.6 1 Facilitation of Web-based
`searching
`
`XML not only improves the production process, it also will benefit Web site
`visitors by enabling them to search for products by type and significant
`characteristics. Hitachi Semiconductor will tag the searchable characteris(cid:173)
`tics during the RTF-to-SGML conversion process. The tags will retained
`when the file is exported as XML. As soon as developers introduce the
`appropriate tools, Hitachi Semiconductor plans to add the tags automati-
`
`©1 9 98 THE XML HANDBOOKTM
`
`

`

`

`

`200
`
`CHAPTER 14 I HITACHI SEMICONDUCTOR
`14.7 1 Quantifiable savings
`
`When Hitachi Semiconductor began using FrameMaker+SGML and
`gained the ability to create PDF files directly from the SGML source docu(cid:173)
`ments, the company reduced print costs 40 percent and reduced its print
`cycle 66 percenc-from three months to one month. "With shrinking prod(cid:173)
`uct design cycles, faster time-to-marker is not just a nice benefit for our cus(cid:173)
`tomers, it's a business imperative," says Tabone. Customers download an
`average of 19,000 product data sheets as PDF files each month, saving the
`company $19,000 in postage costs.
`
`Tabone expects that XML will augment those gains. He calculates that
`XML will reduce printing costs another 15 percent, and shave another two
`weeks from lead time for a 50 percent gain.
`
`Hitachi Semiconductor also benefits from the ability to create all its
`deliverables - paper, PDF, and XML - from a single source. That is, the
`company can manage a larger volume of information more reliably and
`accurately. The publication process is more automated, freeing employees
`with high-level publishing skills to apply their talents to other projects.
`
`14.8 1 Conclusion: A new dimension of
`automation
`
`Tabone views XML as an important publishing technology for the next
`decade. "Three things will matter in the 21st century: information, infor(cid:173)
`mation, and information. If you can't deliver information on time, cor(cid:173)
`rectly, reliably, and in the format the customer wants, you're out of business.
`By providing structure and rich information about the document, XML lets
`companies better serve their consumers' information requirements."
`
`The use of XML also positions Hitachi Semiconductor to meet antici(cid:173)
`pated recommendations from the Elecuo nic Component Wormation
`Exchange (ECIX) Project, an association of eight leading semiconductor
`manufacturers, including Hitachi Semiconductor, seeking to srandardize
`me way semiconductor product information is presented to consumers.
`
`© 1 9 9 8 T H E XM L H ANDBOOKTM
`
`

`

`

`

`

`

`

`

`204
`
`CHAPTER 15 I THE WASHINGTON POST
`
`• 5.2 1 Job searching online
`]obCanopy enables the Post to access job listings from any type of data
`source, including newspaper feeds, employer Web sites, text files, a variety
`of databases, and publi hing systems. The listings from these diverse sources
`are integrated imo relational database tables that can be accessed through
`the supplied user inrerface. Job seel<ers can then conduct highly targeted
`queries into a ri h database of job information.
`For the job seeker, the system provides a one-stop search interface, with
`powerful, tightly-targeted search options, and a uniform, easy-to-compare
`result format.
`For the employer ir offers "do nothing' access ro a lru:ge pool of qualified
`candidates. Without having to subm it or re-format job listing in any way,
`the employer's jobs can be seen in high-o·affic destination sites like (Career(cid:173)
`Post) by job candidates who have narrowed down their searches.
`The value of online recruiting through this technology becomes even
`more apparent when we examine how you would go about searching for a
`job at two individual employer sites in the absence of an aggregated database.
`Consider two sites, Andersen Consulting and CACI International. The
`search method differs slightly, and there are specific limitations for each site.
`
`15.2.1 Andersen Consulting
`
`Figure 15-1 shows the Andersen Consulting site.
`The Andersen site operates on link-based navigation. To search you must
`select an alphabetical range based on the job tide you are looking for.
`Through a subsequent series of links you arrive at a detailed job summary.
`Since link-based navigation sites do not allow keyword searches, you need
`to know the exact job tide for best results from this site.
`
`15.2.2 CACI International
`
`Figure 15-2 shows the CACI International search site.
`This is a form-based site that allows keyword searches in three available
`categories: Region, Job Tide, or Description. Your search is limited to a
`word in either a job title or a description.
`This type of search errs on the side of recall rather than precision. For
`instance, if you enter "MS" in the description field you may get jobs with
`masters degree requirements, or "Microsoft", or "Mississippi".
`
`©1998 THE XML HANDB OOK ™
`
`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`212
`
`CHAPTER 16 I FRANK RUSSELL COMPANY
`
`Russell traditionally viewed its printed "client books" as products. This
`project was the first to begin to stress that the importance of the book is
`really Russell's content, and that the book itself is merely a rendition.
`Russell had been using the "print, then distribute" metaphor for decades.
`But as the newer digital technologies and communication processes were
`taking hold, and the World Wide Web's popularity became undeniable, the
`Russell Advanced Technology Lab began an effort to evangelize, design,
`produce and deliver a new metaphor: "distribute, then print".
`Along with this shift in metaphors come real qualiry co ntrol issues, espe(cid:173)
`cially revolving around color printing. Not on ly were the tradi tional prob(cid:173)
`lems of re-purposing content for different media (i.e. for paper, CD-ROM,
`electronic, FAX, and email) an issue, but also an entirely new set of work(cid:173)
`flow and authoring issues was recognized with respect to the re-use of com(cid:173)
`ponent objects from within the created documents.
`Also, the trend to customizing the content product - moving from
`generic content to a specialized product for an individual information con(cid:173)
`sumer, a "market of one" - was extremely interesting to Russell.
`This chapter chronicles both the team's journey and the Russell solution
`that is currently in production.
`
`• 1.2 1 Project strategy considerations
`
`Russell has steadily been increasing its own awareness that it truly is a large
`publishing concern, producing millions of pages of color and black and
`white output for its clients every year. And as a major financial intellectual
`property publisher, it is also realizing that printing and electronic delivery
`systems play a very strategic role in its continued growth and success.
`There were five principle strategic considerations for the conduct of the
`project:
`
`• Proceeding from a theoretical abstraction to practical
`applications.
`• Phasing deliverables with measurable return on investment.
`• Continuing research in parallel with focused development
`projects.
`• Alignment with overall corporate strategies.
`• Executive sponsorship.
`
`©199 8 T HE XM L HAN DBO OKTM
`
`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`220
`
`CHAPTER 16 j FRANK RUSSELL COMPANY
`
`Russell's management and the Lab team then decided to build and jnre~
`grate a solurion our of commercially available off~ the~shelf (C TS) prod~
`ucts. The team decided to break the deliverables into differem phases that
`would be integrated upon completion.
`
`16.5 1 Implement applications
`
`Our inidal choice for an appLication was the Qttatterfy Investment Review.
`T he QIR is repres ntacive of many of our publications because it consists of
`a combination of generic, proprietary; customer~spec ific, and reusable com~
`ponents.
`
`16.5. 1 Real-world design issues
`
`In order to apply the theoretical architecture to specific application designs
`for the QIR publications, we had to come to grips with real~world issues of
`imernetworking and document representation (file formats) standards, to
`name a few.
`
`16.5.1.1
`
`lnternetworking
`
`The 'WWW family of technologies was chosen for its popularity. Its open~
`standard nature met our basic t chnical requiremems for global electronic
`delivery, easy access, cheap per~seat licensing costs, cross~platform availabil~
`ity, and security.
`The extranet model best served our clients in this application. That is,
`'WWW technologies connected, via public and/ or private networks, to a
`restricted Web site.
`
`16.5.1 Document representation
`
`Our team is very firmly attached to the notion that document representa~
`tion is the key to an organization's success with knowledge management. In
`the SGML Buyers Guide (1998), the authors clearly express this point:
`
`© 19 98 T HE X M L HA N OBOOK TM
`
`

`

`

`

`222
`
`CHAPTER 16 I FRANK RUSSELL COMPANY
`
`of text, that is not what we mean by archiving. To be compliant, from our
`archive we must be able to retrieve exactly what the client printed originally.
`
`We made the choice to use PDF because it m t the r ndered image
`requirement for both text and graph ics, was widely used across many plat(cid:173)
`forms, had a publ icly ·pecified format, and supported a larg set of the
`world's languages. We were also attracted to its usability in for email distri(cid:173)
`bution and n-screen display.
`
`PDF supports full text search, linki ng, and page by page loading. It has a
`development kit available, a compressed file size, interactive forms, cheap
`searsJ and also prints e>..'tremely well.
`
`16.5.i Phased implementation plan
`
`We also did some parallel processing, with secondary teams doing research
`and advanced studies on upcoming phases. The implementation teams,
`however, focused on the deliverables.
`
`One team was assigned to create archiving requirements for the corpora(cid:173)
`tion. Another team worked on object databases and SGML abstractions.
`
`A third team worked on graphical design. Its goal was to constrain the
`number of presentation layouts in order to optimize for batch processing.
`Finally, a fourth team had the task of tracking and understanding key stan(cid:173)
`dards like SGML, XML, Hytime, and various related W3C activities.
`
`16.5.3.1
`
`Phase 1: Records management business
`study
`
`The technical work on this phase was deferred. Our main candidate for an
`archiving product was in the middle of an acquisition, which created an
`unacceptable business risk.
`
`However, Russell did conduct a two-year study on document archiving
`requirements for its Investment Management Business. Once the business
`case for records management was made, Russell hired a full-time profes(cid:173)
`sional archivist to champion the deployment of the technology.
`
`© 199 8 TH E XML HA N DBO OK ™
`
`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`234
`
`CHAPTER 17 I AGENT DISCOVERY
`
`Web Automation technology from webMemods was employed to deliver a
`solution that enables Agent Discovery to exchange data automatically and
`simultaneously with differem photo agencies' Web sites.
`Before Agent Discovery, the company's worldwide design group had no
`alternative but browser-based manually intensive online searches.
`Using web Methods' Web Automation Server and tbe Web Interface Def(cid:173)
`inition Language (WIDL), a working system was built in only eigh t day . It
`immediately enabled DCI to realize huge savings in the amount of time
`designers spend searching fo r and purchasing images over the Web.
`Here are the basic steps that were taken to build the image search and
`procurement functionality of Agent Discovery:
`
`1. The target photo agencies' Web sites were identified.
`2. The functionality of target Web sites was cataloged.
`3. A matrix of functions provided by all photo agencies was cre(cid:173)
`ated.
`4. An aggregate interface of all Agent Discovery functions was
`defined in WIDL.
`5. A separate WIDL was developed for each Web site, imple(cid:173)
`menting functions provided by each site and defining condi(cid:173)
`tions for successful invocation.
`6. A Java servlet was developed to dynamically invoke the ser(cid:173)
`vices defined in each WIDL implementing the Agent Discov(cid:173)
`try interface.
`
`Now picture yourself as a designer who might need these functions. Fig(cid:173)
`ure 17-1
`
`11.2 1 Picture this
`
`Imagine you're a designer of a Web site, magazine, or corporate branding
`campaign, tasked with procuring a large number of compelling images to
`convey messages of "efficiency" and "innovation". Thanks to the Web, you
`are able to access the image databases of dozens of on-line photo agencies,
`retrieving images that match your search criteria.
`
`© 199 8 TH E X ML H ANDB O OK ™
`
`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`

`
`
`Major
`Corporation
`
`I Telecommunications equipment industry
`
`I Database publishing
`
`I Migrating from program code to XML
`
`I SQL access from XML documents
`
`I Middle-tier XML application
`
`@1998 THE XML HANDBOOKm
`
`

`

`"‘fig data-Rom multiple sources is-fljg es'sfil'ca:
`M "
`dfiiuddle.-ti¢'r_Web "
`"
`.d'
`'
`in‘
`
`I
`
`for yearsinprfntpu can
`sdevcilfiflridisbmenséful-an
`
`'
`
`
`0 ur Major Corporation client1 transformed its product and
`
`price publications from paper to electronic media. In doing
`so,
`it radically improved its ability to control document
`quality and reduce information time—to—market.
`Traditionally, the company produced catalogs by manually entering data
`into large product documents. Data entry errors and constantly shifting page
`layout created a vicious cycle of self-generated re—work and expanding sched-
`ules. Information in the publication was not accurate, timely, or useful.
`Now, the catalogs are produced directly from a database using XML with
`embedded SQL statements. Both the source and the resultant documents
`are true XML documents and are created without any changes to the legacy
`database. Replacing the existing database structure was not an option
`because it would have required re—engineering all of the existing processes
`that use the database.
`Using the Internet, marketing and production engineers, sales support
`staff, distribution managers, and external distributors and customers can
`
`
`1. “Major Corporation” is a generic identifier, but this case study really hap—
`pened. SGML was used, but only features that are included in XML, so the
`text refers to it as KXML".
`
`@1998 THE XML HANDBOOK!“
`
`243
`
`

`

`
`
`244
`
`CHAPTER 18 | MAJOR CORPORATION
`
`immediately access accurate product and price information. Users can log
`in and generate live reports dynamically.
`Product adjustments are introduced for approval via this Internet service.
`Once approved, changes to product and price databases become instanta—
`neously available for use. Although paper publishing is still required, we
`have already seen substantial savings in time, labor, and cost by using XML
`in this way.
`
`Let’s look at how these results were accom lished.
`P
`
`I8.l
`
`| Background
`
`When the migration process started. two publishing specialists were respon—
`sible for publication of a single product line twice a year. They worked
`closely with the organization that was responsible for maintaining pricing
`information in the product database on a mainframe.
`
`Product descriptions and page layout were maintained by manually edit—
`ing desktop publishing documents that consisted Of multiple files and
`pages. To publish the catalog, the document was manually updated with
`price information extracted from the product database (Figure 18—1).
`
`MoinFrome
`
`,_
`
`.
`
`'Producii
`
`it
`
`til
`..-'._
`Ilik-“Biliiflpi
`III.- __'
`.4»! ”.._—1 .
`
`_-
`
`.-
`
`.._-E-
`
`Repons Illl _
`
`- .._
`
`-
`
`I
`
`-- I III
`
`1/
`
`s"
`
`f.
`
`‘
`
`\.
`
`. —-._,_.
`.
`5““
`ff Publishing
`,
`Specialist
`.
`:.
`3131/
`._ -.
`‘=“ ..
`K Monuoiijoiogy
`.
`limit???
`
`I
`I
`nlI
`Pr
`cape”may
`mils.hi”99—~'""”I
`.
`"
`il
`:-‘
`\ M
`Product Managers \/
`
`Figure 18-1 Original publishing process.
`
`©1998 THE XML HANDBOOK‘M
`
`

`

`
`
`
`
`18.2 | FIRST GENERATION: CLIENT/SERVER
`
`245
`
`The Precess was conducted. over a two—week period of excessive overtime,
`due :0 the cyclical nature of the worlt. since publicatron was the last step in
`a long chain (ii-events, it did not begin until Information was available From
`other departments. It was dependent on, among other things. proofing the
`induct database to ensure price accuracy. Once price information was
`available, the publishing department took over, literally working night and
`day until the catalog was published.
`The migration From a manual to an electronic publication process was
`executed in the interval between publications by our consulting team. We
`augmented the client's publishing specialists by providing knowledge of
`database technology and programming skills. The publishing specialists, in
`turn, provided corporate business, product knowledge. and publishing
`skills.
`The team initially explored many different ways to publish the price cat—
`alog, some of which did not include XML. Ultimately, XML won out as the
`best method For publishing the catalogs electronically. However, integration
`with a nomXML data source, specifically the parts and prices database, pro—
`vided a significant challenge. Solving it required the development of a mid-
`dle-tier data integration tool named Sle.
`
`Is.) | First generation: Client/server
`
`We first conducted several experiments using desktop publishing systems.
`These led to a working prototype that accessed the database directly,
`thereby eliminating the need to copy the data manually. Now the workload
`could be leveled, as proofing oi: the database could begin immediately after
`the previous publication was complete.
`The first implementation ofthe database publishing system was built on
`the concepts proven by the prototype system. A data Feed taken From the
`mainframe product database placed parts price information in a local data-
`base on a desktop machine. The mainframe was eventually retired by mov—
`ing the database structure, intact, onto a UNIX SQL system.
`Programs written in C generated documents in a proprietary desktop
`publishing Format. These documents were subsequently imported into a
`template document. The template contained Format definitions, such as
`font, table, and layout definitions.
`
`©1998 THE XML HANDBOOKTM
`
`

`

`
`
`246
`
`CHAPTER 18 | MAJOR CORPORATION
`
`These firsr generation C applications were not elegant. SQL statements
`that performed data filtering were embedded into the source files along
`with document structure and format information. As a result, format or
`content changes to any document required programming skills to edit the
`C source documents (Figure 18—2).
`
`Product
`CD-ROMs & Catalogs
`
`
`
`
`
`Fifi
`
`Wmll
`
`
`.
`as..__.
`
`_a
`
`rProgram‘
`
`
`#N i
`.
`
`Programmers
`
` Product
`
`-—lr Managers
`
`Figure 18-2
`
`First generation database publishing.
`
`In the beginning, there were only four or five documents, each requiring
`only one simple C program. However, when news spread about the speed
`and flexibility of the new publication process, an overwhelming demand for
`new documents resulted.
`
`Suddenly, a multitude of derivative documents were created to satisfy
`demand. The company began migrating other product lines onto the sys—
`tem. Within a matter of months, approximately 100 different documents
`were published, each requiring a unique program. Many of the source files
`differed by only a few characters. The team found itself with a serious con—
`figuration management problem On its hands.
`Two main issues surfaced that required taking the system back to the
`drawing board:
`
`I Only programmers could create new documents or modify
`existing ones. Moreover, many documents were derivatives of
`a parent document, which meant that changes to a parent
`might also require changes to its children. Although many of
`
`@1998 THE XML HANDBOOKTM
`
`
`
`
`
`

`

`
`
`18.3 L SECOND GENERATION: THREE—TIER
`
`247
`
`I
`
`the department’s specialists knew SQL (they worked with the
`SQL database several hours a day), they were not C
`programmers.
`It was the nearly impossible to ensure that all documents in a
`family were kept consistent with changes in the parent. As the
`requirements for new or one—off documents increased, a
`document’s family tree appeared to grow exponentially,
`making managing changes more difficult.
`
`On top of all this, the company recognized the cost—saving advantages of
`CD-ROM over paper publications, and the need to make the product cata—
`log accessible via World Wide Web technology. A new system was needed
`to solve the problems and satisfy the new requirements.
`
`l8.3 | Second generation: Three-tier
`
`For the new system, we recognized the following requirements:
`
`I There must be a single document representation that is
`useable for paper, CD—ROM, and the World Wide Web.
`I Publishing specialists must be able to edit and maintain the
`document source without the help of programmers.
`I Database information must be extractable using SQL queries.
`
`XML, of course, was the basis for our solution, but the extraction of
`database information using SQL queries posed a challenge because XML
`did not support it natively. IF Special programs had to be written, it might
`jeopardize the ability of publishing specialists to maintain source docu—
`ments without programmers.
`We needed a tool that met three requirements:
`
`It should work within a standard XML editor.
`We did not have the time to build an editor. Devising a solution
`where the source document must be edited in a plain—text editor
`and validated separately was a step backwards and would be more
`difficult to use than the non—XML implementation. We wanted a
`
`@1998 THE XML HANDBOOKTM
`
`

`

`
`
`248
`
`CHAPTER 18 | MAJOR CORPORATION
`
`true document mark-up solution and resisted the temptation to
`fall back on programmer support to maintain documents.
`
`It must work with the existing database.
`
`XML databases are available, but the company had already made a
`sizable investment in the existing product databases and tools and
`was not yet ready for a radical departure.
`
`It should not require programming skills outside of some SQL
`experience.
`
`The use of SQL seemed unavoidable. Even with all of its
`detractors, it is still a standard and the publishing department was
`already familiar with it. The team wanted to be sure that the tool
`did not require additional programming expertise to be operated
`successfully.
`
`l8.3.l Data extraction
`
`Our solution was Sle, which Agave Software Design developed for this
`project and now offers as a commercial tool.
`
`Example 18-1. Embedded SQL in an XML document.
`<TITLE>Price Book</TITL 3>
`
`<SQLCONNECT USER=”user" PASSWORD="passwd”/>
`<BODY>
`
`
`
`<SQLCJRSOR r1EXT=”select product_line, product_line_desc
`into :prodline,
`:prodlinedesc
`from product_line"
`<PRODLINE>&prodline;</PRODLINE>
`
`
`<PRODLINTDTSC>&prodlinedesc;</PRODLINEDESC>
`<SQLCJRSOR TEXT="select product_name, product_desc
`into :prodname,
`:proddesc
`from product
`
`
`
`:prodline"
`where product.product_line =
`<PRODNAME>&prodname;</PRODNAME>
`<PRODDESC>&prOddeSC;</PRODDESC>
`</SQLCURSOR>
`</SQLCURSOR>
`</BODY>
`_________________________________________________________________
`
`@1998 THE XML HANDBOOKTM
`
`

`

`18.3 | SECOND GENERATION: THREE—TIER
`
`249
`
`Like other data aggregation notations we have seen in this book, Sle
`provides some command—like tags that are interspersed in the markup of
`the source document. These tags don’t appear in the generated XML docu-
`ment. Instead, they are interpreted by the Sle middle—tier server, which
`causes appropriately tagged database data to appear.
`In Example 18—1, the SQLCONNECT tag opens a database. Each SQL—
`CURSOR tag issues an SQL query to that database and iterates on the
`returned data. The indentions in the example show where the iteration
`occurs.
`
`The first (outer) SQLCURSOR tag generates one PRODLINE and one
`PRODLINEDESC element for each product line in the database. For each
`product line, the second (inner) SQLCURSOR tag generates one PROD—
`NAME and one PRODDESC element for each product in that product
`line.
`
`Note that there is no explicit “loop” command, as in scripting languages.
`The iteration is built into the data source query. And the data sources aren’t
`restricted to SQL: plain—text files, object databases, and XML documents
`are also supported.
`
`I8.3.I Database maintenance
`
`The new system allowed individual product organizations to control their
`own portions of the product database. Product and price changes could be
`generated directly by product managers and their staffs, who could immedi—
`ately generate a copy of the product catalog as it would appear with the
`changes: As a direct result, the quality of the product catalogs increased
`because the product information was maintained by those closest to the
`products themselves (Figure 18—3).
`Making product information the responsibility of the product managers
`helped to eliminate re-authoring of vital information. Now, because all
`source information necessary to publish the product catalog was resident in
`the product database, publishing a product catalog was reduced to a three—
`step process:
`
`1. Create or modify the XML source document, including inser-
`tion of Sle elements.
`
`@1998 THE XML HANDBOOKTM
`
`

`

`
`
`250
`
`CHAPTER 18 | MAJOR CORPORATION
`
`CIieni/Server
`
`Publishing Speciallst
`
`interns?
`WV} '
`
`Com on
`Inirdiieiy
`
`.
`tiff
`I
`
`Cfiafi
`8‘
`
`
`
`P SQL i
`roduc
`Database
`
`.
`
`.-
`'_
`_
`39ml
`3y Starved
`\H—_—Tj
`
`l- I
`
`__/"
`
`.
`
`_.
`
`|
`
`1 Timing?
`'Fi mm
`
`I
`
`\
`
`\ XML
`
`
`
`'
`
`7
`
`Product
`Mmgers
`
`~.
`
`Publishing Department
`
`2
`
`Figure 18-3 Second generation publishing with XML and SQmi.
`
`2. Generate the XML result document, in which the source doc—
`ument’s embedded SQL queries are replaced by the query
`results.
`
`3.
`
`Format and distribute the document through the selected
`medium: paper, CD-ROM, or the company-wide intranet.
`
`I8.4 | Summary
`
`The cooperative effort of our consulting team and the client’s publishing
`specialists has had measurable positive results. The company now has
`timely access to mission critical product information. Product information
`systems and catalog publishing processes have undergone substantial
`changes that have resulted in higher document quality and usability. These
`improvements also provide benefits in lower maintenance and product
`COStS.
`
`Strategically, the switch to XML was the correct move to make at a criti—
`cal point in the migration process. XML and Sle provide an environ-
`ment
`that bridges the gap between the company’s legacy repository Of
`information and the targeted publishing media.
`
`@1998 THE XML HANDBOOKTM
`
`

`

`
`
`

`

`City Of
`Providence
`
`I Travel industry
`
`I Repurposing content
`
`I Republishing in multiple electronic media
`
`I Linking static and dynamic Web sites
`
`©199 8 THE XML HANDBOOKTM
`
`

`

`

`

`254
`
`CHAPTER 19 J CITY OF PROVIDENCE
`
`might only have time w sample a couple of restaurants and night spots dur(cid:173)
`ing a busy convention. Of particular interest is the question, "what special
`events are going on during my visit?"
`
`How can a chamber of commerce with a limited marketing budget and
`staff provide dynamic, up-to-date information for a multitude of visitors
`with different interests, and on multiple media? Inso Corporation has pro(cid:173)
`totyped a solution for the city of Providence, Rhode Island, where its Elec(cid:173)
`tronic Publishing Solutions division is located. This solution repurposes
`the same XML content about Providence that can be republished three
`ways:
`
`• A Providence Guide on CD-ROM, viewed with the DynaText
`Browser.
`
`• The same guide served on the Web with Dyna Web, which
`links to ...
`
`• A dynamic Web site with current club listings and on-line
`restaurant reservations, using DynaBase.
`
`In addition, XML support in these products enables contextual search(cid:173)
`ing, hypertext navigation aids, and multiple views that allow different read(cid:173)
`ers to reuse the publications w meet their own specific needs.
`Finally, XML-enabled links b [Ween related content in the different pub(cid:173)
`lications helps draw the user into a caU to action: to visit and spend money
`at Providence's restaurants, clubs, and other attractions.
`
`To make changes to the Providence Guide content in all three forms, the
`author need only update a single source document with a word processor.
`These documents are then converted and the content "rescued" (adding
`XML structure and intelligence) using DynaTag.
`
`Extremely volatile data, such as this week's events, are stored and updated
`in a database and inserted dynamically into the Web pages using Dyna(cid:173)
`Base's built-in scripting language. The city could even allow club promoters
`to enter their own events directly into the database via a Web-based form,
`thus reducing work for city employees even further. The club promoters
`might even be willing to pay an advertising fee for the privilege of listing
`their events on the ci