Now, assuming that you've kept your content in an abstract form, you need to figure out how to programmatically and transparently convert it into various formats for all the different devices (web, Wap, PDA, Toothbrush, etc...) that might knock on your front door. For most applications, it's not as daunting as it sounds, but it is a perfect application for using XML with a SQL database. One approach is to use two transformations applied in parallel. The first transformation addresses the device class and the second addresses finer-grain device or browser-specific features.
The first step is to determine which devices you're really interested in and concentrate on those. For instance, if you're developing content for a specific mobile carrier, you might only be interested in the devices that work on that carrier's network.
Next, subdivide your population of devices into generic device classes, such as these:
- Small screen black-and-white
- Small screen color
- Widescreen black-and-white
- Widescreen color
Based on this device class, pass your basic content through a first level of transformation. This transformation should take your abstract content and turn it into device-specific content (WML, for example), but still leave some room for further transformation depending on device-specific features. For instance, your first transformation might determine the version of an image to use in a particular piece of content (large GIF, small GIF, small WBMP, large WBMP), and apply other style elements such as bold and italic text. The second XSLT transformation applies device-specific transformations such as taking advantage of a particular WMLScript feature on a particular handset (see Figure 1).
Figure 1 The chain of transformation. Content is transformed once into an intermediate format and then transformed again to incorporate specific device features.
To pull this off, you need good intelligence about which browsers fit into which device classes. You then need to apply XSLT style sheets based on this information. One way to accomplish this is to store all your device profile information in a SQL database. Then, when a user first accesses your site (initiates a session), do a simple query based on the user agent string and have the database return two XSLT style sheets, or the URIs to two XSLT style sheets. A rough ERD for this would look something like Figure 2.
Figure 2 A rough schema design for associating XSLT transforms with device classes and specific user agents.
Why worry about device classes at all, if you're going to keep a separate XSLT style sheet for every user agent anyway? The answer is that the bulk of your transformations will probably to be according to device classes, not specific device characteristics. If you design your XSLT transformations well, you should only end up with a few device-specific transformations in the deviceXSLT table to deal with quirky devices or special cases (for instance, that phone that the CEO of your company refuses to stop using.) The challenge is keeping this database up to date as new devices hit the market.