A Better Electronic Catalog

Even though the HTML catalog in the previous chapter may have been acceptable as a way to present information on a page, and its XML transformation may have added some searchability, it can still stand some significant improvement. The main competitor to Joe’s Catalog, Jane’s Catalog, is embarking on this more difficult course. Building a new catalog format from the ground up may cost Jane some effort and adjustment, but it should create a more automatable catalog that is easier to manage.

As long as orders were coming in exclusively over the telephone, Jane was comfortable having a Web catalog that simply recreated her paper catalog. As the costs of her 800-number have risen, she’s begun to wonder whether she shouldn’t revise her system and allow Web users to order over her cheaper Internet connection. At the same time, she’s moving her catalog from the ragtag group of desktop publishing files they’ve used into a new database system capable of holding her items and all their associated data—even pictures! Because Jane doesn’t spend much on advertising, she would like automated tools to be able to understand her catalog easily, making it easier for users to find the items they want. XML sounds like it might give her a boost in that direction, and it should be a good fit for the database systems she’s installing as well. The challenge is to create a catalog application that can present her data attractively to customers while easing the demands on her order-entry department.

Instead of working from the catalog as it is currently presented on the Web, we’ll start by examining Jane’s methods of assembling the catalog and processing orders. When Jane’s computer receives an order (from a telephone operator at the moment), it processes payment, typically a credit card, and prints out a packing slip in the warehouse. Workers in the warehouse find the items and ship them out immediately. The order-entry department would like to see the Web application feed their computer a simple set of information: payment information, shipping information, and the list of products to be ordered (by item number) and quantities. This is a fairly easy set of data to deliver with existing Web tools. On the customer side, eventually, Jane would like the application to display a full invoice to the customer, complete with shipping costs. Part of the motivation for moving to XML has to do with an interest in making the user’s Web browser do as much work as possible, sparing her servers the trouble of processing information that client machines could handle as easily. This saves her expensive bandwidth and processing effort. Even though XML may not be able to achieve this today, several other standards under development will make this much easier soon, as we’ll see later in the chapter.

XML has several drawbacks at this point for Web application development. Adding the necessary links for JavaScript code to read the XML information may complicate the clean structures Jane would like to produce. The DTD must provide support for scripting on some level without becoming too complex. Fortunately, Jane has already planned her application to take advantage of frames, which will allow her to place code in another frame, safely outside the XML document. All the XML document needs to do is pass information about which item the user wants to a script in another frame, which will then store in a shopping basket and handle all the sales infrastructure Jane needs. The fact that Jane’s computers will be generating static XML from a database will also ease the difficulties by allowing some repetitive information to appear in the XML markup.

Jane’s Catalog is currently organized loosely into pages that group related products. The groups are determined informally by the team that builds the paper catalog. The electronic catalog should preserve these groupings, making it easy for customers to flip back and forth between the two versions. All the grouping information is stored in the database as well, making it much easier for a script to churn out pages based on a set of queries. Jane just needs a set of elements that can present the catalog data elegantly, with minimal processing overhead, and that can easily adapt to the upcoming improvements in scripting and document object models while still accommodating the needs of the present.

The top level of this DTD is the group—all members of a group will be presented in the same document.

  <!ELEMENT GROUP (GROUPNAME, ITEM+,LEGALNOTICE)>
  <!ATTLIST GROUP

     GROUPLINK CDATA #IMPLIED>

The GROUPLINK attribute holds a key value that will make it easy for a parser at Jane’s to link to the original database record for troubleshooting or other information gathering. The GROUP element begins with a GROUPNAME element, which is effectively a headline for the page, and ends with a LEGALNOTICE element, which will just contain the usual warnings about typos and pricing. It is probably unlikely that a search engine or agent would look for LEGALNOTICE as an element, but it does make formatting the fine print easier.

  <!ELEMENT GROUPNAME (#PCDATA)>
  <!ELEMENT LEGALNOTICE (#PCDATA)>

Under this headline are catalog ITEM elements. ITEM elements contain a variety of other elements, including ITEM subelements that represent products affiliated with their parent ITEM. Like the GROUP element, the ITEM element may have an attribute that connects it to its database entry.

  <!ELEMENT ITEM (PRODUCTNAME, DESCRIPTION?,PRICING,
  ITEM*)>
  <!ATTLIST ITEM

     ITEMLINK CDATA #IMPLIED>

The PRODUCTNAME element, like the GROUPNAME element, is really just a headline. Because the elements receive different formatting and may need to be addressed differently through scripts, the two elements are created separately.

  <!ELEMENT PRODUCTNAME (#PCDATA)>