To the “candidate” Sinks and Sources

Copyright © 2011 Open Geospatial Consortium 25 It is important to understand that a candidate, using “SAXDriver” will process its operations by directly handling “SAX events”, without seeing the raw XML at all, at least for encode and decode measurements. For the compaction measurement, it depends on the candidate. Some implement a “transcodeTestCase” method which directly works on raw XML without using SAX e.g. Jaxp, some re-use SAX e.g. EXI to benefit from the schema grammar.

5.2.1.5.4 To the “candidate”

As the W3C EXI test bed only reference “candidates” and no “drivers”, we need to specify what is making a candidate. A candidate is a Japex Driver: extending the SAXDriver or the BaseNativeDriver, so some of the Japex calls are directly handled by the “platform” see below using some additional parameters brought by the platform see below linked with a compressiondecompression algorithm that could be in java or native which eventually supports its own post-compression by itself see “document” applicationClass with applicationClass.documentAnalysing.GZIP unset which handles eventually the parsing of schema which simply handles SAX parser for compression and SAX reader for decompression if using the SAXDriver this is very very simplified but gives the idea The following schema show the generic candidate structure for both JNI and java bases algorithms used: Copyright © 2011 Open Geospatial Consortium 26 Compression Decompression C Libs .so ZLib Native C JNI « DRIVER » candidate EXI-TTFMS COMMONS parameters, … Java « DRIVER » candidate EXI-TTFMS JAVA SAX « DRIVER » JAPEX « DRIVER » Compression Decompression Java Lib JARS

5.2.1.5.5 Sinks and Sources

Even if the platform loads input files into memory, and store output also in memory, it will manage input and output of encoding decoding operations directly fromto streams. The input stream is called the datasource and the output stream the datasink. The usage of adaptors on these streams allows to perform additional gzip compression, and to manage it without soliciting the candidate which still sees streams on both sides. For instance the gzip compression alone on a file XML neither candidate is obtained by using xerces to decode SAX events produced by the platform reading input file, then applying a gzip adaptor before the datasink. The following schema explains those transitions: Copyright © 2011 Open Geospatial Consortium 27 DataSink the output, in memory too DataSink Adaptor any transformation AIXM input File DataSource in memory for our benchmark DataSource Adaptor any transformation Candidate operation processing Copyright © 2011 Open Geospatial Consortium 28

5.2.1.6 Flow overview