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

RE: XML / HTML Transport size

• To: "John Cowan" <jcowan@r...>,"\"Gerben Rampaart \(Casnet Mechelen\)\"" <Gerben@C...>
• Subject: RE: XML / HTML Transport size
• From: "Danny Ayers" <danny666@v...>
• Date: Mon, 18 Nov 2002 16:44:34 +0100
• Cc: <xml-dev@l...>
• Importance: Normal
• In-reply-to: <200211181217.HAA13976@m...>

>We already have several such platform-independent methods, if by that you
>mean that cross-platform compressors and decompressors exist.  A variety of
>small-scale studies have shown that general-purpose compression is
>generally
>as good as, or better than, some scheme that knows it's compressing XML.
>A scheme for compressing a particular XML document type might be useful
>in extreme cases, but is probably not worth standardizing.

fyi: Scalable Vector Graphics (SVG) [1] allows for the use of the familiar
gzip compression scheme, achieving worthwhile ratios. The Adobe SVG browser
plugin supports this, and all in all it seems a successful approach.

>The fact is that images, audio, and video, which are already compressed,
>constitute the bulk of the traffic on the Internet today.

Although SVG is a graphics format, it has characteristics that make a .svgz
file a lot more interesting than most compressed image formats, through the
XML data and the ability to include interactive/executable code.

[1] http://www.w3.org/2000/svg

• Follow-Ups:
  • RE: XML / HTML Transport size
    • From: David Megginson <david@m...>
  • Re: XML / HTML Transport size
    • From: Robin Berjon <robin.berjon@e...>

• References:
  • Re: XML / HTML Transport size
    • From: John Cowan <jcowan@r...>

• Prev by Date: Re: RDF for unstructured databases, RDF for axiomatic
• Next by Date: Re: XML / HTML Transport size
• Previous by thread: Re: XML / HTML Transport size
• Next by thread: Re: XML / HTML Transport size
• Index(es):
  • Date
  • Thread