Xqueeze: Compact XML Alternative
Frequently Asked Questions
- What is wrong with XML?
- What is the big deal with
- What kind of compaction factors are you
able to achieve?
- Why don't you implement an XML <=
=> xqML converter?
The problem with XML when used in the context
of heavy-duty applications that require large volumes of data to be
exchanged is it's verbosity. The low information to size ratio leads
to unnecessary wastage of computing power, bandwidth resources and
This wastage is entirely avoidable because in
those heavy-duty applications, XML is generated and consumed by
software that does not require the verbosity of XML to understand
it. Here is a detailed write up on this
We know very well that the problem with XML is it's
verbosity. Xqueeze simply tries to do away with this verbosity by
replacing the long and descriptive identifiers that are described in
XML grammar specifications (DTD, Schema etc.) with small
bit-squences or symbols.
What's more, through Xqueeze we want to
make this substitution very practical and easy to use without
breaking the semantics, flexibility or applicability of XML,
especially where software XML generators and consumers are
used. More details can be found on the Xqueeze Concept page.
We have been able to achieve compaction factors
from as low as 1.85 to as high as about 10. The reason for this
variation is that the compaction depends a lot on the ratio of
markup information to the whole data in an XML file. Average case
compaction is about 3 - 4, which is quite good for some applications
like XML based Instant Messaging Protocols that can expect almost
the same factor of improvement in performance under heavy loads due
to lesser traffic at the server and insignificant processing
The level of compaction you achieve depends on your
particular instance of XML but it is hoped that if your application
can derive any benefit out of compact XML, you would find it
feasible to use Xqueeze.
That's because using xqML as an intermediate
carrier loses a lot of it's benefits. Rather than a performance gain
in direct generation and parsing of xqML, there would be additional
overhead of two-way conversion. If this overhead is affordable,
perhaps you can do better with compression! That said, I'd be glad
if someone develops such a converter :-)
© 2002 - 2004 All content on
this page released under . This page last modified on
01 February, 2003.