OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: standard compressed XML format?

[ Lists Home | Date Index | Thread Index ]
  • From: "Simon St.Laurent" <simonstl@simonstl.com>
  • To: <xml-dev@xml.org>
  • Date: Thu, 16 Mar 2000 17:51:32 -0500

I don't think I was clear enough about what I was asking for earlier.
While these various tools for compressing XML are interesting, and use a
wide variety of  promising strategies, none of them are currently set up to
be built into a compress-before-transmission/decompress-on-receipt
framework that's invisible to the user.

The WAP approach is probably the closest to what I'm thinking about, but
the WAP forum has control over the entire transmission cycle.  Building
support for this binary encoding into WAP devices is easy.

Making compression/decompression work across existing Internet frameworks
is a lot harder.  While HTTP offers some headers that might be useful,
they're rarely implemented in an interoperable manner.  MIME content types
don't provide any information about possible compression, except for
formats that are expressly compressed data, content unknown.

While graphics formats - notably GIF, JPEG, and PNG - have
compression/decompression built in, XML has no such thing.  Combined with
XML's lack of concern about verbosity (which, in general, I approve of),
this gives XML a serious disadvantage compared to binary formats.  

The main complaint I've seen about SVG, for instance, is that the files are
big.  When markup documents are a small core referencing larger pieces that
are themselves compressed (as with HTML or SMIL), this isn't much of a
disadvantage. As we push XML forward as a container for more and more
information itself, however, verbosity starts to matter.

I'd like to think there's a way to remedy this at the general
infrastructure level, rather than requiring either user intervention or
application-by-application implementation.  It seems like we could save a
lot of needless network traffic while strengthening the case for using XML.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth

This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS