RE: [DotGNU] Gzipped XML (was: Disadvantages of XML) - BXML

[Barry Fitzgerald]

Actually, this could be quite useful in SEE/the auth projects...
transmitting gzipped XML could be one of the solutions to the bandwidth
problem of programs communicating over networks... however, the tradeoff
is that applying this concept to live network communications increases the
CPU cycles used in operating an app.  This could be a very good trade-off
given the existance of exceedingly fast CPUs out there.

Another advantage of using gzip to compress the XML, as opposed to a
homebrew compression system is that gzip could be easily turned on/off by
an administrator.

        -Barry


On Thu, 3 Jan 2002, Stouf wrote:

> Date: Thu, 3 Jan 2002 20:14:33 +0200
> From: Stouf <address@hidden>
> To: 'Gopal.V ' <address@hidden>,
>      'Dotgnu Mailing List ' <address@hidden>
> Cc: 'Rhys Weatherly ' <address@hidden>
> Subject: RE: [DotGNU] Gzipped XML (was: Disadvantages of XML) - BXML
>
>  Why don't you use the Binary XML Content Format ...
>  see http://www.w3.org/TR/wbxml/
>
> -----Original Message-----
> From: Gopal.V
> To: Dotgnu Mailing List
> Cc: Rhys Weatherly
> Sent: 02/01/2002 16:37
> Subject: Re: [DotGNU] Gzipped XML (was: Disadvantages of XML)
>
> Hi Rhys,
> > Essentially, they chose 1-byte numbers for each tag type,
> > and then replaced the tag structure with those numbers when
> > transmitting the data over the wireless network.  i.e., instead
> > of sending <TABLE>, you would send "3" (or whatever the
> > tag value was).  This compacted the XML quite well.
>       That works very well if you have no attributes for tags. Add
> a huffman encoding and that's optimisation.
> >
> > IMHO, it was a big mistake.  There is a massive version bug in
> > how they did it.  Because version 1 clients don't understand
> > version 2 tag numbers, it creates migration problems when
> > moving to a new version of the standard.  It also lost data:
> > DTD's, comments, stylesheets, and other meta information
> > were stripped from the input, which made it difficult for
> > clients that may want that information.
>       Backward compatibility is not only a good idea, it's a
> requirment.
> > At the end of the day, it is easier to just gzip it and forget about
> > the problem.  No data loss, and roughly the same level of
> > compaction.  Highly redundant data like XML compresses
> > very well.  For example, the 6 Mb All.xml file for the C#
> > library specification compresses to ~630k using gzip: about
> > 10% of the original size.
>       I would have selected Bzip2 if given an option, but it
> does not seem to supported enough on platforms (eg Win32,Mac)
> (All.xml.bz2=416k). I have been using Java's GzipInputStream
> for my Java+XML programs. Also the CRC32 checks built into
> Gzip ensure data integrity.
>
>       Well at the end of the day, I'd rather be sleeping rather
> than coding on a XML compression no one is going to use.
>
>       So we reach the consensus that Gzipped XML is our standard
> and now all that remains is to use that standard somewhere ;-).
>
> Gopal.V
> --
>  The difference between insanity and genius is only measured by success
>  //===<=>===\\
> || GNU RULEZ ||
>  \\===<=>===//
> _______________________________________________
> Developers mailing list
> address@hidden
> http://subscribe.dotgnu.org/mailman/listinfo/developers
> _______________________________________________
> Developers mailing list
> address@hidden
> http://subscribe.dotgnu.org/mailman/listinfo/developers
>

address@hidden
SDF Public Access UNIX System - http://sdf.lonestar.org