Xqueeze: Compact XML Alternative

Frequently Asked Questions

General

Questions

Answers

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 performance issues.
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 issue.
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 overheads.
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 :-)

Project Links: