[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Xqueeze: Compact XML Alternative

• To: robin.berjon@e...
• Subject: Re: Xqueeze: Compact XML Alternative
• From: "Alaric B. Snell" <alaric@a...>
• Date: Fri, 7 Feb 2003 10:56:35 +0000
• Cc: xml-dev@l...
• In-reply-to: <3E438FAD.4050401@e...>
• References: <p04330103ba65690e85d6@[192.168.254.4]> <E18h5IK-0000gk-00@c...> <3E438FAD.4050401@e...>

On Friday 07 February 2003 10:51, Robin Berjon wrote:
> Alaric B. Snell wrote:
> > On Friday 07 February 2003 09:24, Robin Berjon wrote:
> >>I certainly hope that future improvements on our binary format will in
> >> fact make it compress badly :) That should happen by making it more
> >> compact than it currently is (while keeping similar speed, which is why
> >> compression is not always an option).
> >
> > Nooo! It's not the compression *ratio* that matters here. It's the
> > eventual size.
>
> To you perhaps. An improved binary infoset removing yet more redundant
> information by itself will be likely to generate less compressible data,
> and the ratio matters in cost/benefit analysis.

But what matters is the end to end result.

The un-gzipped binary or textual format is an intermediate format, right? At 
one end you have your Infoset in memory, at the other end you have a string 
of bytes to go on the wire.

The size of the intermediate formats used only matters with regards to buffer 
consumption - and the intermediate data structures used in gzip and bzip2 are 
pretty large themselves!

> If I have (completely arbitrary numbers):
>    bix            10k
>    bix+gz          8k
>    better-bix    8.5k
>    better-bix+gz 7.8k
>
> Then even though the last one is the smallest, option 3 will be de-encoded
> a *lot* faster. At some point the different between a compressed binfoset
> and an uncompressed one becomes too marginal to be interesting.

Oh, I agree; I'm with you there. I'd rather not gzip at all. My point was 
about people comparing gzipped XML with $binary_format and then saying "See? 
Why bother with the binary format? gzipped XML is smaller!".

My counterthrust being that the non-gzipped binary format will be much less 
resource intensive to process, and not much more resource intensive to 
transmit over the Internet; and if the latter is a real problem then gzipped 
binary will be smaller and easier to process than gzipped xml, if you can 
afford to go around gzipping things.

I think we agree though, from your last statement :-)

ABS

-- 
A city is like a large, complex, rabbit
 - ARP

• Follow-Ups:
  • Re: Xqueeze: Compact XML Alternative
    • From: Robin Berjon <robin.berjon@e...>

• References:
  • Re: Xqueeze: Compact XML Alternative
    • From: Elliotte Rusty Harold <elharo@m...>
  • Re: Xqueeze: Compact XML Alternative
    • From: "Alaric B. Snell" <alaric@a...>
  • Re: Xqueeze: Compact XML Alternative
    • From: Robin Berjon <robin.berjon@e...>

• Prev by Date: Re: SGML->XML->? (was Re: SML: Second Try)
• Next by Date: Re: Xqueeze: Compact XML Alternative
• Previous by thread: Re: Xqueeze: Compact XML Alternative
• Next by thread: Re: Xqueeze: Compact XML Alternative
• Index(es):
  • Date
  • Thread