Creating a Markup Language - Page 3

Naturally, our fictional rubber band team already has a database- driven e-commerce web site. Like all legacy databases, it has evolved over time into a hodgepodge of tables, some of which were hastily knocked together to implement poorly-defined requirements. We will assume that the company is operating a traditional Java Server Pages (JSP) site.

Since most of the tables in the database are relevant to the requirements of the various interfaces, the developers plump for a "verbose" approach to their XML. They will dump all of the data from all of the tables into XML form, even though some of it may be unnecessary in the VoiceXML, WML, or HTML contexts.

MyRubberbandsML by Trial and Error

The first thing any XML dialect needs is a top-level element. Since we might want to export all the customers in the database, or only one at a time, let's add an attribute on the top level element to describe what kind of data feed this XML document constitutes.

<myrubberbands export_type="single">

The thing we are most interested is a customer record, because that will be the set of data needed to generate the voice interface for querying order status. Since we might have more than one customer in a file, each individual <customer> and their associated order history will be contained by a <customer_record> element. Note that the time stamps are in XSL's standard format, and won't translate easily for rendering by aTTS engine. The <customer_record> element that starts here is very lengthy, and is not closed until the associated addresses and order history that follows have been given.

<customer_record>
  <customer id="1">
    <firstname>John</firstname>
    <middle>Quincy</middle>
    <lastname>Public</lastname>
    <username_or_email>jqp@foo.foo.com</username_or_email>
    <password_or_pin>bar</password_or_pin>
    <date_joined>2001-05-18T16:17:15</date_joined>
    <date_lastchg>2001-05-18T16:17:15</date_lastchg>
</customer>

As shown in the database schema, a customer can have one or more addresses. The XML representation should preserve the foreign key relationship with the customer table, and this relationship should not be dependent on the position of the elements. In this case, for example, both the customer profile and all associated addresses are nested within the <customer_record> tag. This is why all of the <customer_address> elements carry the customer_id attribute inside: it mirrors the relationship between the customer and customer_address tables in the database schema.

In this case, the database schema allows the customer_address table to store real physical addresses like billing and shipping addresses, or e-mail address for alternate methods of customer contact. Hence, the <customer_address> element can contain the optional <email> element.

  <customer_address address_type="Ship To Address"
          customer_id="1">
    <address1>4321 La Place Ct</address1>
    <address2>Ste 306</address2>
    <city>Carlsbad</city>
    <state_or_prov>CA</state_or_prov>
    <postalcode>92008</postalcode>
    <email></email>
    <phone>7605551212</phone>
  </customer_address>

Since the main objective of the voice application is to allow the user access to their order history and status information, it makes sense to include the history inside the <customer_record> scope. In this case, because we will need to enunciate the order time, and because we'd rather not use XSL's limited text processing capabilities, we'll add the attribute sayas to the <order_date> element. This provides a pronunciation that can be used with the VoiceXML <sayas> tag for TTS. However, the desired pronunciation of the date and time cannot be derived from the database alone, as addressed in the section Generating MyRubberbandsML.

System Architecture - Page 2
Early Adopter VoiceXML
Creating a Markup Language (Con't) - Page 4