Sample Chapter: Early Adopter VoiceXML - System Architecture (contd.)
(Page 4 of 9 )
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.
<order_history
customer_id="1">
<order id="1">
<customer_address address_type="Ship To Address"
customer_id="1"/>
<order_date
sayas="May 18, 2001 at 16 17 hours">
2001-05-18T16:17:16
</order_date>
<order_status>Processing</order_status>
<tax>0.09</tax>
<shipping_charge>0.4</shipping_charge>
<total_charge>2.48</total_charge>
<product
id="1" quantity="3"/>
<product
id="3" quantity="1"/>
</order>
</order_history>Finally, to provide the user with detailed order information, the full product name and description must be available. This will also allow the user to ask for a product list, and eventually we can perhaps extend the interface to enable products to be ordered by voice. Note that the <product_list> is not associated with any particular <customer_record>.
Also note that, ideally, the <product_list> wouldn't actually be in the same document as the customer data. However, we'll keep everything in one file here to avoid the issue of linking between documents. It might amuse us to picture the harried developers reaching the same conclusion to save time and give themselves some chance of meeting their beloved boss's deadline. Later on, they will no doubt want to refine the process and generate smaller XML documents that can be processed more quickly.
</customer_record>
<product_list>
<product id="1" name="MIXED1000"
price="1.99">
Mixed Bag of 1000 Rubber Bands</product>
<product id="2"
name="MIXED5000" price="4.09">
Mixed Bag of 5000 Rubber Bands</product>
<product id="3"
name="RED1000" price="2.19">
Bag of 1000 Red Rubber Bands</product>
<product id="4"
name="RED10000" price="17.49">
Bag of 10000 Red Rubber Bands</product>
<product id="5"
name="BLUE1000" price="0.99">
Bag of 1000 Blue Rubber Bands</product>
<product id="6"
name="BLUE10000" price="8.99">
Bag of 10000 Blue Rubber Bands</product>
</product_list>
</myrubberbands>This example is formatted to fit the space above, and for readability, adds quite a bit of whitespace between <product></product> tags that would probably not occur in a real document.
Next: Generating MyRubberbandsML >>
More XML Articles
More By Tim Pabst
