AANLkTikmbNpM0m_hOTTQJYXYzNCxdfzZE2h18hS0uvXq@mail.gmail.com" type="cite"> Two use cases 1) The binary encoded XML format used was designed explicitly for extremly efficient parsing. The particular schema is a document-oriented, semi-display specialized schema which works very well at fast rendering of marked up documents (things like font changes, tables , indentation , bullets.. Think HTML-extremely-light). Its *fast*, very fast. On older mobile devices (think palm, 8MB devices) it was fast enough to render interactively with no visible delay. ASN.1 hasnt vanished, but XML really is a great fit for this technology. Just not "text serialized xml". 2) The original source data was in XML. (before being converted to the format in #1), in a more data-centric format. Big, and ugly. An (abandoned) project was an attempt to do thiings "the server way" and just copy over the XML and do XSLT processing in a browser window to produce HTML on the fly. This saved a huge amount of work on the server side (where debugging things and XML tools are really easy to use) an d instead moved the work to the device (in this case an iPhone). As I predicted, while the concept 'worked' it performed like hell and had 10x the data transfer overhead and the rendering speed even on high-performance iPhones was diskmal. #abandoned But in both cases, the XML data model is really a good and appropriate model to use.' ASN.1 isnt really a data model, and not particularly better or even as good as using XML. Of course there are a zillion ways 'it could be done'. Most of them perform horribly. -- David A. Lee dlee@calldei.com http://www.xmlsh.org |