Re: TAG input to EXI WG on Efficient XML Interchange and EXI Measurements

Tatu,

  The framework is available for download here [1]. It is based on  
Japex, but it builds another layer on top of it for additional  
functionality like reading from a socket. Writing a new driver for a  
different parser should be straightforward using the JAXP one as a  
sample.

-- Santiago

[1] http://www.w3.org/XML/EXI/#TestingFramework

On Nov 29, 2007, at 8:12 PM, Tatu Saloranta wrote:

>
> One quick question related to one of comments:
>
> On Nov 29, 2007 11:34 AM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
>>
>> Following on from the many useful discussions at group and individual
>> level which took place during the recent TPAC week, the TAG has
>> arrived at the following requests and recommendations for the
>> Efficient XML Interchange Working Group:
> ...
>> Detailed comments on the Measurement documents
>>
>> The 2005 TAG message called for testing to involve "best possible
>> text-based XML 1.x implementations", and the XBC's call for
>> implementations [2] specifically called for only XML parsers, not for
>> the surrounding application or middleware stacks, JDKs or Java  
>> Virtual
>> Machines.  The benchmarks have not been against the best possible
>> text-based XML 1.x implementations.
>
> Given that there are multiple contestants for "best possible
> text-based XML 1.x implementations" (even if not considering more
> integrated approaches), would it be easy to re-run tests using
> alternatives other than JAXP (which I assume means Xerces 2.7.1)?
> Especially if using the same interface (SAX2).
>
> I don't expect working group to have to try out all permutations, it
> would just be interesting for others to try out alternatives, both
> benefiting EXI community and parser implementors. Chosen document set
> could conveivably be used as somewhat less ad hoc collection than what
> is often used when developers run performance tests.
> One example of areas that would likely be affected is handling of
> small files -- document notes that JAXP parser was performing
> relatively poorly for small files. This is consistent with
> measurements of Java SAX parsers that do indicate Xerces to have
> higher per-document overhead than alternatives (i.e. Xerces
> performance relatively poorly amongst it peers for small docs, and
> much better for larger ones). I would be interested in seeing what
> kinds of relative performance profiles would other textual xml parsers
> have.
>
> -+ Tatu +-
>

Received on Friday, 30 November 2007 16:15:38 UTC