W3C home > Mailing lists > Public > public-exi@w3.org > November 2007

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

From: Santiago Pericas-Geertsen <Santiago.Pericasgeertsen@Sun.COM>
Date: Fri, 30 Nov 2007 11:11:49 -0500
To: Tatu Saloranta <tsaloranta@gmail.com>
Cc: public-exi@w3.org
Message-id: <140D284A-EB53-4972-9DC3-354BB267F08E@sun.com>


  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  

-- 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:52:42 UTC