11
2006 Epocrates, Inc. All rights reserved.Slide | 11 Background Why XML on the device ? A brief history Proprietary RTF Like markup hit a dead end... Grew too complicated to parse No one could understand the code No one could understand the markup Extremely difficult to extend XML was reconsidered !!! Extensible Well defined Maybe there was a way to optimize for mobile devices?

13
2006 Epocrates, Inc. All rights reserved.Slide | 13 Architecture Focus on Parsing, not creating Only Use Case is when XML is created on server Device parses XML only Does not need to create XML –Adding creation may be simple if schema is simple

16
2006 Epocrates, Inc. All rights reserved.Slide | 16 Architecture Efficient SAX Encoding Use a SAX Parser to parse the XML into a stream of simple events and data Encode each event and data using a simple encoding scheme and a Dictionary Produces a stream which is very efficient to decode.

17
2006 Epocrates, Inc. All rights reserved.Slide | 17 Architecture Optional compression If Space is more important then speed, optionally compress. Open source GZIP compression works reasonably well on the encoded SAX stream. Decompression is costly (CPU) on the device so should be used sparingly Most compression algorithms work well only when given data > a few kb. (not good on small messages).

18
2006 Epocrates, Inc. All rights reserved.Slide | 18 Architecture Pack for transport Device databases usually have hard limits of record sizes (palm = 64k) Start, End markers and checksums may be useful Packing multiple streams into a larger record (before or after compression) for more efficient use of small documents