The other enormous problem in scripting for XML is addressing the elements to determine their contents. This task will become much easier when the W3C finishes work on the Document Object Model (DOM). For now, the ID solution presented in the preceding DTD will meet the needs of Microsoft’s Internet Explorer Document Object Model. The NAME attribute performs functions similar to ID in Netscape browsers, although ID appears to work in Netscape Navigator and Communicator 4.0. When the DOM is complete, it should allow scripts to access elements through the document structure as well as by NAME or ID. Unfortunately, producing that model will take a very long time—the path is strewn with technical and political landmines. In the meantime, Microsoft and Netscape will no doubt continue to produce functional, but thoroughly incompatible document and event models.

Direct Connections: Business-to-Business Transactions

Electronic commerce over the Internet is only getting started, but it’s rapidly becoming clear that retail sales over the Internet face security hazards and consumer skepticism. Instead of developing enormous systems for processing credit cards and handling customer inquiries, many Internet entrepreneurs have turned to the safer world of business-to-business transactions. Frequently, all parties involved in a deal already know and perhaps even trust each other, avoiding the anonymity issues associated with Internet commerce. Accounting systems already provide sales on credit to known customers, and shipping terms are already established. As we’ll see in the next section, not all transactions are financial, either; many systems out there use similar connections for securely sharing private information.

Electronic data interchange (EDI) systems so far have tended to use structures from the database world—fixed-length or delimited fields ordered neatly into tables for processing. Transmission of this information has improved dramatically—companies used to mail tapes to each other regularly, but they now more frequently connect over data networks—but the form of the information hasn’t yet changed greatly. XML offers businesses more flexibility than their current systems can offer, along with an opportunity to create simple standards that can be extended to cover additional data structures as necessary.

The examples presented in this section provide only a very basic outline of what is necessary to create a full-fledged commercial interchange system. The standards proposed here will probably be superceded by recommendations from standards bodies and industry organizations.

EDI for commercial transactions has been expanding wildly for the last twenty years, and the structures it has created still have much to offer our XML examples. XML is not the answer to every aspect of electronic order placement. The businesses may trust each other enough to ship each other goods, but the orders must still be placed over a secure channel. This could be as simple as encrypting the XML document with public-key encryption tools and sending it via e-mail or as complex as sending it over a specially built private network. XML documents could also be sent on magnetic tape by private courier to companies uninterested in making network connections to their financial systems.

After that channel has been established, the businesses can begin considering the format for their orders. All orders still need ship-to and bill-to information, as well as contact information that can be used reach a human if the computers fail. Dates are also critical, to give the recipient some idea of when the order was created and when it arrived. A priority level for the order might be useful in some situations, although there might be separate priorities for the order as a whole and for parts of the order. A listing of the items to be ordered will follow, concluding with an expected total number of items and total bill. The conclusion is a critical piece for making certain that items haven’t been lost during processing. XML developers should probably look over their shoulder at the older forms of data interchange, if only to make certain that they haven’t left out any key pieces that the older structures provided.

Our initial DTD for XML transactions, which provides a shell for the order, is deliberately abstract. At this level, it doesn’t matter what kinds of items are being ordered—apples, tractors, and concrete beams are all just items to be transferred between companies. The second DTD, which defines the items, will be much more focused on the goods in question.

We’ll start by defining the ORDER element, which encompasses the entire document:

  <!ELEMENT ORDER (BILLTO, SHIPTO, CONTACT, PRIORITY,
  ITEM+,TOTALS)>

The BILLTO and SHIPTO elements have similar contents:

  <!ELEMENT BILLTO (REFERENCE | FULLADDRESS)>
  <!ELEMENT SHIPTO ((REFERENCE |FULLADDRESS), SHIPVIA)>
  <!ELEMENT SHIPVIA (REFERENCE | FULLADDRESS)>
  <!ELEMENT REFERENCE (#PCDATA)>
  <!ELEMENT FULLADDRESS (COMPANY, ADDRESSLINE+, CITY,
  STATE, POSTALCODE, COUNTRY, CONTACT, PHONE, FAX?)>
  <!ELEMENT COMPANY (#PCDATA)>
  <!ELEMENT ADDRESSLINE (#PCDATA)>
  <!ELEMENT CITY (#PCDATA)>
  <!ELEMENT STATE (#PCDATA)>
  <!ELEMENT POSTALCODE (#PCDATA)>
  <!ELEMENT COUNTRY (#PCDATA)>
  <!ELEMENT CONTACT (#PCDATA | REFERENCE)*>
  <!ELEMENT PHONE (#PCDATA)>
  <!ELEMENT FAX (#PCDATA)>
  <!ELEMENT PRIORITY (#PCDATA)>

Most of this information is basic text, although the key REFERENCE element will probably be used for most transactions. By using a REFERENCE, an ordering company is announcing that it already has a record in the recipient’s system. The processing application that receives this data will pass orders that use REFERENCE to the order system immediately—a relationship already exists. (If it’s a bad relationship, because the company ordering doesn’t pay the bills, or doesn’t exist in the system, the order system can still reject the order.) Orders that arrive with full addresses will need further verification. Contacts will be called, credit checks run if necessary, and the new buyer will be entered into the order system and given its own REFERENCE information for future use.