With a little help from Simple Object Access Protocol (SOAP), XML, Extensible Style Language (XSL), Wireless Markup Language (WML), and Active Server Pages (ASP), the Wireless Access Protocol (WAP) traffic application is ready! That's right—no more getting up early to watch various news broadcasts with the hopes of catching the traffic update. From your Web-enabled phone or other WAP device, you can now receive up-to-the minute traffic reports (currently, San Diego is the only city available).
To pull this off, I had to find data that exists in a format that would let me extract it and combine it with WML to produce output suitable for a WAP device. Terry Givens described a Web service he created using the SOAP Toolkit in the November 28 XML UPDATE Commentary, and I decided to use that to get the XML data file for the traffic application.
I used the Remote Object Proxy Engine (ROPE) to call the Web service methods that return the XML data. Once I had the string, I needed a way to query the XML document. But first, I had to determine the type of XML document I was dealing with. Here's the document that I was testing with:
I'm leading to an example that shows you what to expect when you're dealing with SOAP and the XML string that it returned for this particular application. Here's an example, called a RowSchema:
The following code illustrates how I found out what the XML string looked like in my ASP page:
Response.ContentType = "text/xml"
I could see the data, but I still had to figure out how to get to it and present it. For this, I created a couple of XMLDOMDocument objects. I used the same ASP page for both the Web browser and WAP browser versions; I detected the different user agents and called different XSL style sheets accordingly:
Set XSLdocument = Server.CreateObject("MSXML2.DOMDocument")
Response.ContentType = "text/vnd.wap.wml"
xslfile = "../XSL/stateWml.xsl"
XSLdocument.async = false
At this point, I ran into difficulties creating the style sheets to transform the XML data into WML output. Also, I wondered what means to use to refer to the elements and attributes in the source tree. One problem was that I didn't understand the XSL namespace declarations, as the following code illustrates:
Using this declaration, the WML Parser kept producing errors that referred to the DOCTYPE and other elements in the declaration. I knew that some type of transformation was occurring because "Yeh Baby" (which I included for debugging purposes) kept appearing in the emulator information box. As I read up on XSL declarations and namespaces, it occurred to me that a lot of this declaration was unnecessary for my purposes. Finally, on MSDN I found an example that helped:
Voila! My data! The problem with the previous declaration—at least for my application—was the way the WML Document Type Definition (DTD) was wrapped in the CDATA section. The MSDN example used the XSL namespace to define a DOCTYPE element and used the WML DTD as the element's value.
If you remember in the RowSchema example, the actual data was not a value of the element tag per se (
To get to this point, I used XPATH, which lets you get the exact information you want by way of XPATH expressions. You specify a starting point (context node) and a location path (xml/rs:data/z:row), and from there, you specify the following to get the data:
You can access my WAP traffic application on the Interknowlogy Web site. Many thanks to Gail Fitzmaurice, Terry Givens, Bruce Russell, Clyde Revilee, and Randy Broderdorf.