XML Tips

Wireless transmission is becoming more and more common for many document types, and XML is no exception. But XML itself presents a number of challenges to the wireless medium. This article, the first in a two-part series, describes these challenges, and describes techniques that can be used to tailor an XML-aware system to the wireless world.

Wireless bandwidth continues to be at a premium, despite the long-standing promises of 2.5G and 3G networks. XML isn't binary, and while this means that knotty problems like little-endian/big-endian confusion are avoided, it also means that raw XML data isn't ideal for wireless transmission. In fact, design goal No. 10 for XML states that "terseness in XML markup is of minimal importance." This doesn't rule out XML for wireless transmission, but it does mean that compression is a must.

WBXML - Binary XML
The Wireless Application Protocol is a specification for developing applications that operate over wireless communication networks. The development of WAP is overseen by the WAP Forum, an industry consortium that includes Ericsson, IBM, Motorola, and Openwave. The wireless market is growing very quickly and is expanding to reach new customers with new services. To enable network operators and handset manufacturers to meet the challenge of deploying advanced services, WAP defines a set of protocols in transport, session, and application layers.

One component of the WAP specification that has been submitted to the World Wide Web Consortium is a description of Wireless Binary XML (WBXML for short). WBXML defines a compact binary representation of XML. It reduces the transmission size of XML documents, allowing more effective use of XML data on narrowband communication channels. WBXML achieves this by tokenizing XML files to reduce (1) the number of bytes needed to send data over the wireless channel as well as (2) the need for a complex parser by constraining the file format so it can be rapidly parsed in binary form.

To send a WBXML file most efficiently, it's important to provide an initial token mapping for the channel. Some token mappings are specified in the WAP specification - WML, for example. Other XML formats may be used with WBXML without a mapping, but the transmission is more verbose, since the tag names need to be listed in a string list at the start of the transmission.

ASN.1
If all this talk of tokenizing files for binary transmission sounds familiar, it's because it reflects an older standard, Abstract Syntax Notation 1, published jointly by the International Standards Organization, the International Electrotechnical Commission, and the International Telecommunications Union. It hasn't gone away.

Like WBXML, ASN.1 is a collection of techniques and notations for specifying data structures in a machine-independent manner. Token sets defined using ASN.1 can be used in combination with standardized encoding rules such as the Basic Encoding Rules (BER) and the Packed Encoding Rules (PER). ASN.1 is supported by mature tools for encoding and decoding binary information into and out of BER and PER formats, as well as to other proprietary encoding formats.

ASN.1 is widely deployed in the wireless and fixed-line communications industry as an enabling technology for cell phone messages, radio paging, free and premium phone services, and ISDN telephony. In addition, it is used for streaming audio and video over the Internet, and is fundamental to ISO security and messaging standards, including X.509 digital certificates and X.400 e-mail.

If a widely used protocol like ASN.1 already exists and has widespread adoption, then why generate a new protocol like WBXML especially for wireless adoption? This question has been posed in the past for many wireless initiatives, including WTLS (versus SSL), WScript (versus JavaScript), and, of course, WML (versus HTML). One answer in this case is that WBXML is specifically linked to XML and preserves the treelike nature of an XML document, allowing a recipient system to deal selectively with XML tags. ASN.1 and XML do not have congruent data models, and so the translation between them is not a straightforward exercise.

Another possible drawback is the lack of freely available tools for ASN.1. By contrast, the XML world contains many free tools, such as xalan for XSL stylesheets and xerces for Document Object Model processing. However, if ASN.1 were to be recommended for wireless XML processing, free tools would likely come onto the scene quickly.

This incongruity of XML and ASN.1 is being addressed by two ITU/ISO initiatives that map XML to ASN.1 and vice versa. The first, AML (ASN.1 Markup Language), represents ASN.1 data types as XML, and is to be the ITU-T Recommendation X.693 and ISO/IEC 8825-4. The second maps XML Schemas to ASN.1 in such a way as to preserve all the information contained in the XML Schema definition. This will allow data defined as XML to take advantage of ASN.1 tools such as DER (to encrypt and digitally sign data, for example) and PER (to send data over radio, for example). This initiative is to be the ITU-T Recommendation X.694 and ISO/IEC 8825-5. Information about these two initiatives is available at http://asn1.elibel.tm.fr/xml.

The focus on XML Schemas rather than DTDs for these two ITU/ISO initiatives reflects the fact that Schemas are closer to ANS.1 than DTDs are. However, tools are available to map between the two; one example is the ASN.1/XML Translator, which is part of IBM's XML Security Suite (see www.trl.ibm.com/projects/xml/xss4j).

Encoding Techniques
Focusing on document size, let's compare the encoding formats we've discussed so far: ASN.1, WBXML, and plain XML. First, let's use the DTD that follows to define a simple purchase order document.

<!ELEMENT PurchaseOrder (LineItem+)>
<!ELEMENT LineItem (Description, Quantity)>
<!ELEMENT Description (#PCDATA)>
<!ELEMENT Quantity (#PCDATA)>
<!ATTLIST LineItem
Department ( Food | Hardware | Pharmacy) #REQUIRED>

The next code snippet is an example of an XML document that conforms to this DTD.

<?xml version="1.0" ?>
<!DOCTYPE PurchaseOrder SYSTEM "PO.dtd">
<PurchaseOrder>
<LineItem Department="Food">
<Description>Cookies</Description>
<Quantity>5</Quantity>
</LineItem>
<LineItem Department="Hardware">
<Description>Hammers</Description>
<Quantity>10</Quantity>
</LineItem>
</PurchaseOrder>

Now let's look at an ANS.1 specification for the same simple purchase order document. In the following code you can see that we're using the SEQUENCE, INTEGER, and ENUMERATED ASN.1 data types. Information about the full range of ASN.1 data types is available at http://asn1.elibel.tm.fr/xml.

PurchaseOrder ::= SEQUENCE OF LineItems
LineItem ::= SEQUENCE {
Description VisibleString,
Quantity INTEGER,
department Department }
Department::= ENUMERATED {
Food(0), Hardware(1), Pharmacy(2) }

Using BER encoding, we see that the document is considerably smaller than the plain XML document in the second code snippet. Note that PER encoding is optimized for radio transmission and compresses the document still further:

10 18
1A 07 'C' 'o' 'o' 'k' 'i' 'e' 's'
02 02 05
0A 00 00
0A 01 01
1A 07 'H' 'a' 'm' 'm' 'e' 'r' 's'
02 02 0A
0A 01 01
0A 01 01

Now we come to the WBXML specification for the same document. WBXML caters specifically to XML, so we define tokens to represent XML elements and XML attributes, as follows:

Tag code space (Tag Name : Token ) :

PurchaseOrder : 5
LineItem : 6
Description : 7
Quantity : 8

Attribute start tokens:
(Attribute: Attribute Value Prefix : Token)
Department : Food : 5

The following shows the purchase order data represented in WBXML encoding, using the tokens we defined above. WBXML uses string tables to list strings used in the XML document, and following this string table we see that all the data takes the form of tokens.

01 01 03
10 'C' 'o' 'o' 'k' 'i' 'e' 's' 00 'H' 'a' 'm' 'm' 'e' 'r' 's' 00
45 C5 07 83 00 05 05 01
45 C5 07 83 09 06 0A 01
01

So Many Wireless Devices, So Little Time
The limited display capabilities of mobile handsets has led to the need to optimize data views/formats for display on these devices. While these new developments have benefited the mobile user experience and have increased uptake of mobile applications, they have added greater complexity to the role of content providers. With the increasing numbers of different devices available for retrieval and display of information over the Internet comes the added headache of customizing the display of the data on each device. Content providers who don't offer easy access to their information across multiple devices risk losing customers. What's suitable for one device may be unacceptable for another. However, the problem is that re-creating and customizing data outputs for different media and on different devices is very resource-intensive and may eventually become unmanageable.

Sun Translets: Two Steps Instead of Three
XSLT is a standard that addresses the problem of transformations between the many proprietary and industry-vertical XML vocabularies. It can also be used to format documents for output to different display devices (phone handsets, PDAs) when using XML as a base data storage format.

XSL Transformations are executed using an XSLT engine, which typically tends to be a large and complex program. It reads in an XML file, reads in an XSL stylesheet, loads the XSLT logic into memory, and then applies the XSLT logic to the XML document. This three-step process is often a bottleneck for wireless deployment to multiple devices, losing valuable time for content delivery.

Sun's XSLT compiler simplifies the transformation process. First, a Java class known as a translet is produced from an XSLT stylesheet. This translet is then applied to the XML files that use the original XSL stylesheet. This technique has important advantages of speed and size over the traditional three-step method of applying stylesheets. The speed advantage is that step 1 - compiling the stylesheet into a Java class - only has to be performed once. The compiled translet can then be applied to multiple XML documents.

The size advantage is that only the XSL logic used by the stylesheet is compiled into the translet. The rest of the XSL language logic isn't needed. For most stylesheets this reduces the size of the application logic considerably. XSLT engines weigh in at 700 to 800KB - translets may be only 10 to 50KB. Sun has donated their translet engine to the open-source community, with the result that the xalan XSLT engine now incorporates translet logic. The speed gains from using translets make XSL more palatable as a technology choice to address the problem of content deployment to multiple wireless devices.

The smaller size of translets, compared to using a full XSLT engine, means that this is suitable for wireless devices that incorporate J2ME (Java 2 Micro Edition) implementations. Sun's J2ME specification defines a Connected Limited Device Configuration (CLDC) that can be implemented by a handheld wireless device. A CLDC device may well have a processor of limited prowess (in comparison to a desktop system) and a memory footprint of between 128 and 512KB. This means that running a full XSLT engine is out of the question. However, a translet is much smaller and can run in the tight memory confines of a CLDC device.

The Downside of XSL
Notwithstanding the efficiency gained when using translets, XSL can be an unappealing development tool because of the complexity inherent in creating and maintaining XSL stylesheets. XSL is a templatic (template-based) language that can confound software developers who are used to the logic in their programs being executed in a top-to-bottom sequence. The fact that the templates in an XSL stylesheet can be jumbled up into a different order, yet the stylesheet still produces the same output, is counterintuitive.

The complexity of the XSL language can result in solutions that are difficult to maintain. Adding to this problem is that although XSL doesn't mix presentation with data, it does mix presentation with logic. As mentioned above, logic expressed in XSL can be complex. XSL skills are required by a Web designer who wishes to change the graphical output of a transformation. Technologies such as JSP (JavaServer Pages) or ASP (Active Server Pages) are more similar to traditional programming languages and as such may be more suitable for ongoing maintenance and code reuse.

Summary
In this article I've discussed the compression techniques for XML that are essential for the wireless transmission of XML documents. I also covered the use of XSL, with and without translet technology, to tailor XML base data for multiple wireless devices. In Part 2 I'll discuss other technologies for wireless XML, such as VoiceXML, WAP and WML, and HDML, as well as wireless techniques for signing and encrypting XML documents.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...