This is a short paper written for the seminar "XML, a New Start for the Web", held Spring 2000 at Hypermedia laboratory, Tampere University of Technology, Finland.
WAP, Wireless Application Protocol, is a suite of specifications for accessing various kinds of information services from mobile devices such as digital mobile phones [WAP]. A core part of WAP is WML, Wireless Markup Language [WML], an XML-based [XML] language for describing the contents of WAP information pages. Due to being an XML language, WML is a very flexible model for content presentation. However, for the same reason, WML is also rather verbose.
For most applications the verbosity of XML is not a problem -- after all, the available memory, storage space and processing power in computers increases every year. Mobile devices, however, are different. A typical mobile phone today has a very limited amount of processing power in its main CPU, has little memory left for its applications to use, and, most importantly, has a very slow communications channel available. Typical GSM phone has only a 9600bps data link, and WAP can be used over even slower transports. Therefore a more compact mechanism for representing the data is needed.
WAP Binary XML Content Format [WBXML] provides such a mechanism. It defines a binary representation for XML, intended to reduce the size of XML documents for transmission and to simplify parsing them. This report gives a short overview on WBXML, its basic structure, capabilities and limitations.
The structure of a WBXML encoded XML document consists of the following main parts, in order:
The encoding used for tags and attributes is described below with more detail.
Tags are normally represented with an eight-bit token. The two most significant bits indicate if the tag contains attributes or content, and the six least significant bits contain the tag number. The numbers corresponding to different tags are not defined in the WBXML specification, but are defined separately for each language that will be encoded. For example, the WML specification [WML] lists the WBXML tag codes that correspond to different WML tags.
Since the six bits available for tag code can only represent 64 tags, there are further 256 different code pages into which the tag (and attribute) codes are divided. This allows a total of 16384 different tags to be represented, which should be sufficient for all applications. In addition, unknown tags can be represented as literal strings (via a reference to the string table), but this obviously defeats the purpose of using a binary encoding in the first place.
If a tag contains attributes (i.e. the most significant bit of its token is 1), the attributes are encoded in the document after the tag token. Each attribute starts with an eight-bit attribute start token, which identifies the attribute name and optionally the beginning of its value. The value can be continued with eight-bit attribute value tokens, strings, opaque data entities, and document-specific extension codes. The value terminates with a new attribute start token (representing the start of the next attribute) or a specific end token.
The attribute encoding mechanism is rather flexible, allowing common parts of attributes to be encoded with a smaller amount of data. For example, the attribute URL="http://www.kala.org/" could be encoded as follows:
TOKEN_URL_HTTP TOKEN_WWW STRING("kala") TOKEN_ORG_SLASH
Where TOKEN_URL represents the attribute start "URL=" with value "http://", TOKEN_WWW value "www.", and TOKEN_ORG_SLASH ".org/". This way the whole attribute can be encoded with five bytes, assuming the string uses a single-byte reference to the string table.
Like tags, attribute codes are also divided into 256 different code pages. The code pages for attributes and tags are separate. The highest bit of attribute tokens differentiates between attribute start and value tokens, leaving room for 32768 different attribute start and attribute value codes.
Tags can contain more tags, strings, character entities, opaque binary data and document-specific extension codes. Strings can be encoded using either a reference to the string table, described above, or as inline literal strings. Character entities are represented by their UCS-4 encoding values, as in the original XML entities. All entities in the original XML document must be reproduced either as strings or as entity tokens.
Opaque binary data is, as its name suggest, plain unprocessed binary data inserted into the document, and can be used for any data. In addition, extension tokens specific for a given document type can be specified.
WAP Binary XML Content Format [WBXML] defines a method for encoding XML documents into a binary format. These binary encoded documents can take considerably less space than their traditional textual versions, and require less processing to parse and use in software. This makes WBXML coding especially attractive for use in low-powered mobile devices.
Even though WBXML has been defined by the WAP Forum (see [WAP]), it is not limited to WML [WML] or any other specific XML language. Instead, it can be used with all XML-based languages by simply defining tag and attribute token values for each language used. WBXML also contains representations for tags and attributes that do not have corresponding tokens and even a mechanism for extending the encoding on a document-specific basis.
However, using WBXML has its drawbacks too. Most obviously, all comments and document meta-information is discarded when it is encoded. In addition, even though the document structure is preserved, the layout of the original XML is lost, making it more difficult to use and edit for humans. Using a binary encoding also defeats several of the design goals set for XML [XML, sect. 1.1], namely backward-compatibility with SGML, need for being human-legible and being easy to create.
Space saving benefits offered by WBXML are also open to debate. Although XML is rather verbose in its textual form, it compresses very well with normal data compression algorithms and algorithms can be further tuned for XML data [XMILL]. Ultimately the choice between normal XML and a binary representation must be done considering the needs of each application separately. If a binary encoding is used, WBXML provides a viable alternative for most purposes.