xPML: The Secret Sauce Powering SMS.ac
Because you provide content to SMS.ac subscribers via templates, you needn't interact directly with SMS.ac servers for information such as subscriber information or SMS short codes for a specific service. Instead, specific information flows to your application server via the URLs provided by the SMS.ac service when invoking your application, and you permit the SMS.ac servers to embed their data in your response content through templates. All of this is carried out using xPML, the XHTML-based markup language invented by SMS.ac.
When SMS.ac requests a page from your application server, it includes several URL-encoded data members for you to use, including the IsWap field, which is set to '1' if the user is viewing the content through a handset browser. Other members include the unique ID of the subscriber and their gender. Table 1 shows the entities in a URL passed to your application server, which might look like this:
Of course, you can also handle additional form data from information provided by the user in the typical way as additional data members in the URL. All forms within pods use the GET method for FORM tags, and the user’s client will encode the fields of your form; when the SMS.ac Web site passes the URL with the form data on to your application server, the URL your server receives will include both the form data and the SMS.ac specific data.
Table 1. URL-encoded data members in SMS.ac-provided URLs
||Set to 1 (true) if user is viewing pod thru a handset
||0 (false) / 1 (true)
||Size of Pod
||1 or 2
||Unique ID of pod owner
||Age of pod owner
||Sex of pod owner
||Male / Female
||Location of pod subscriber
||City, State, Country
||Unique ID of pod viewer
||Age of pod viewer
||Sex of pod viewer
||Location of Pod viewer
||City, State, Country
An obvious use of the unique ID of the pod viewerthe smsac_vid elementis as a key in your database for the preferences for that subscriber (for example, to store a town of interest for a weather application). Interestingly, the server sends two unique IDs to your application server in the URLs: the user ID of the person viewing the pod, and the unique ID of the person owning the pod. Thus, you can create two separate views of your pod, one tailored to the needs of general users, and one tailored to the pod owner or administrator. In fact, if the user browsing your pod is not a registered SMS.ac subscriber, the unique user ID will be zero, so you can actually provide three views of your content: one for the pod owner/administrator, one for registered SMS.ac users, and one for non-subscribers browsing the SMS.ac Web site. In PHP, you might write this:
$view_mode = MODE_BROWSE;
if ( $smsac_oid == $smsac_vid )
$view_mode = MODE_PRIVATE;
else if ( $smsac_vid != 0 )
$view_mode = MODE_REG_USER;
Your responses to the SMS.ac service should be in xPML, which looks strikingly like HTML. Drawn from the SMS.ac Web site, here's a simple example:
<div class="p_text_sm" style="padding:0px">
<(PodTitle text="Hello Mobile World!" link="http://www.sms.ac")>
<h1>Welcome Pod Developer</h1>
<p>Hello! This pod is being shown to <(FirstName)> <(LastName)></p>
xPML markup is contained in the <(
brackets, and can consist of the following:
- Keywords, such as FirstName, which are recognized by the SMS.ac service and converted to their appropriate value before returning the page to the end user. These keywords let you access user-specific information (such as the same demographic information provided in the URLs the SMS.ac Web site sends to you) as well as things such as PodTitle, which lets you set the title of your pod as it's displayed to the user.
- Assignments, which assign values to specific keywords recognized by the SMS.ac service. This lets you override things such as the title of your pod.
- Directives, such as the Msg directive, which sends an SMS message to the current user of your pod.
In addition to providing template substitution on your behalf, the SMS.ac service also recognizes the following xPML tags:
- The podlink tag permits you to link from one page to another within your pod. By default, the HTML anchor tag will always generate a new page, letting you easily code escapes from your pod to full-size Web pages. If instead you want to keep the user within the bounds of the podgenerally the case if you want to present the appearance of a stand-alone action&151;you should always use the podlink tag. Its syntax is the same as the anchor tag.
- The connect tag, which permits superdistribution of your content. Content enclosed within a connect tag is user-selectable; when the user selects the content, they are prompted to provide an address and a message to accompany the content, which will be sent to the indicated address.
You can use these anywhere you’d use conventional HTML markup:
<podlink href="page2.html">Next page</podlink>
description="Here's the map to my place">
One issue I have with xPML is that it's not fully XML-compliant. In the interests of making xPML easy to understand and use, the architects at SMS.ac have introduced the <(
nomenclature to denote a template substitution. Unfortunately, this isn't XML-compliant, and a number of XML-based tools are likely to have problems managing content destined for SMS.ac applications. If you're using an XML-based environment such as XSLT to produce your mobile output, expect to spend a bit of extra time using the facilities of your environment to produce this XML-like output.