[
Lists Home |
Date Index |
Thread Index
]
The purpose of WBXML was to:
1. Squeeze an XML document (WML) of <500 bytes into an SMS of 140 bytes.
Other compression methods such as zlib are not good at so small sizes (the
compressed version may even be larger than the source).
2. Remove the need for a full XML parser on the mobile phone.
Today, (2) is irrelevant because all WAP 2.0 phones have XML parsers (minus
DTDs) for XHTML and WML. There are still a few cases when (1) is relevant;
e.g. when WAP Push is used over SMS (still only 140 bytes).
--
Peter Stark
----- Original Message -----
From: "Nicolas Lehuen" <nicolas.lehuen@ubicco.com>
To: "Mike Champion" <mc@xegesis.org>; <xml-dev@lists.xml.org>
Sent: Monday, March 11, 2002 10:46 PM
Subject: RE: [xml-dev] What happened to WAP
> AFAIK, there is no support for hardward or software compression of WAP
data.
> Obviously, the hardware can handle compression of voice data, but it looks
> like the WAP forum supposed that the only compression algorithm to use
> should be WBXML.
>
> What about WBXML ? Well, it just works !
>
> For most WAP developers, WBXML is never seen. The WML -> WBXML transcoding
> takes place at the WAP gateway ; for you and for me, serving some WAP
> content is just done by responding a WML document with mimetype
> text/vnd.wap.wml over HTTP. For most content providers, WBXML is therefore
> an pretty abstract thing that never gets in the way.
>
> Now, for the sake of completeness, we had to write a WBXML encoder in
order
> to support WAP Push. WAP Push on the GSM bearer is done by sending special
> binary SMS containing WDP packets (WAP rough equivalent of UDP) with a
WBXML
> (not WML) payload. At short or mid-term, the mechanics of building those
> weird SMS will be assumed by a push-oriented complement of the WAP
gateways,
> named PPG for Push Proxy Gateway. But for now, as PPGs are not publicly
> deployed by operators, we had to write our own PPG code.
>
> Implementing WBXML encoding/decoding is pretty straightforward. Each
element
> and attribute maps to a code in a code page, with bit masks for elements
> with no content or elements with no attributes. Closing tags are
represented
> by a single byte (WF documents shouldn't need to specify the closing tags
> names !). Attributes values have many mappings allowing a short encoding
of
> often used attribute values prefixes (like href="http://www.";). String
> encoding is done in the encoding you fancy, just like in XML, though
> iso-8859-1 and UTF8 are the only encoding required.
>
> We implemented WBXML encoding/decoding in a generic way as a SAX filter,
> and we can plugin various code pages to support various input/output DTDs
> like WML of course, but also SI, SL and CO, which are short notification
or
> cache manipulation messages. WBXML is not restricted to WML, it can handle
> any XML content whose schema is fully known beforehand, provided that you
> write a bytecode mapping for ite.
>
> What we didn't do is compare the efficiency of WBXML vs. gzip or other
> compression schemes. That may be an interesting thing to do since we
already
> have the code to do both (thanks to the
java.util.zip.GZIP[In|Out]putStream
> classes). We haven't done it yet because we just had to support WBXML, no
> question about it :).
>
> What I find interesting is that a WBXML document can easily be manipulated
> in serial or random access mode ; once a schema is hardwired, there is no
> need to manipulate full-length strings, a simple switch statement over an
> integer value can be used by a renderer to discover the content of a
> document. I suppose this allows the rendering code to be much more
> lightweight than a full XML + gzip compression scheme, where the code
would
> have to handle gzip decompression as well as full-length string comparison
> for element and attribute names. Likewise, WML is said to be designed to
> allow a one-pass rendering of a document, that's why tables have a
mandatory
> "cols" attribute, for example.
>
> The WAP Forum has not focused only on bandwidth, they took care of the
ease
> and compacity of implementations. This allows WAP browsers to run on
cheaper
> and more energy-saving hardware. The less Mhz the CPU require, the longer
> the battery will last. This may seem a foolish point but energy saving is
a
> very important point for mobile manufacturers. The fun thing with WAP is
> that it mixes XML and the Web with embedded design concerns.
>
> I agree, though, that some design choices in WAP were rather strange. For
> example, they designed a brand new image format, with absolutely no
> advantage over existing ones. This was a pain in the ass in the early days
> when imaging tools didn't have support for the WBMP format, forcing us to
> write convertors ourselves (which we used for on-the-fly image conversion
> anyway). Some people were baffled by the way the WAP Forum scorned the XBM
> format to build a new one, not quite the same but very near, with
absolutely
> no added value.
>
> WAP 2.0 [1] will change a lot of all this. WAP 2.0 indeed keeps all the
> "legacy" of WML 1.2 (i.e. all the WAP specific network layers) but will
also
> support the plain old Internet network layers : TCP/IP and HTTP, GIFs and
> PNGs, and JPEGs, without requiring a WAP gateway to be deployed.
>
> The need for a WAP gateway has been criticized a lot, especially in the
> short lapse of time where mobile operators tried to prevent users from
> changing their WAP gateway by distributing WAP-locked phones (with which
you
> were bound to use the operators' WAP gateway). The fact that all WAP data
> exchange must go through a central server controlled by the mobile
operator
> was seen as an attempt by the mobile operator to lock the market.
>
> But the truth is that a WAP gateway can be useful, or even required.
>
> It can be useful due to its capacity to cache content, even if large scale
> caching is doubtfully efficient. The compression brought by WBXML is also
> interesting, and the fact that a gateway was is providing the required
logic
> for WML to WBXML translation allows people to produce WAP services easily.
> Those are technical reasons, though, and in the euphory of early 2000,
when
> people thought that 2 Mbps bandwidth would be reached in the next year,
the
> "they-want-to-own-us" paranoia was de rigueur.
>
> Anyway, it can, and maybe will, be required to have a central access
point
> when revenue sharing is implemented. As the mobile operator is the entity
> that charges the users, it must have a way to log the usage of pay-per-use
> services to be able to charge them and share revenues with the proper
> service provider.
>
> I really think revenue sharing is the best way to see the birth of
> high-quality mobile services and killer apps. Revenue sharing is like the
> universal micro-payment solution that the Internet has been missing until
> now. But revenue sharing is necessarely centralised by the different
mobile
> operators ; the fact that we're in not mobile phone market, not the
> Internet, makes it feasable. Introducing revenue sharing at the ISP level
> would shock a lot of people, I guess.
>
> Regards,
> Nicolas
>
> -----Message d'origine-----
> De : Mike Champion [mailto:mc@xegesis.org]
> Envoyé : lundi 11 mars 2002 19:16
> À : xml-dev@lists.xml.org
> Objet : Re: RE: [xml-dev] What happened to WAP
>
>
> 3/11/2002 10:50:32 AM, Nicolas LEHUEN <nicolas.lehuen@ubicco.com> wrote:
>
> >To conclude, we should not look at pure technical reasons to explain the
> >demise of WAP. The problem is mainly rooted in the dynamics of the mobile
> >phone market.
>
> Thanks for the great summary of WAP technology/business!
>
> I'm still unclear on my question in the other thread,
> though: Do WAP phones have any hardware-level or OS-level
> data compression? I'd also like to hear Nicolas'
> take on the significance of WBXML in the context of the
> WAP reality today.
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
|
