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


Help: OASIS Mailing Lists Help | MarkMail Help



   [xml-dev] XML / HTML Transport size

[ Lists Home | Date Index | Thread Index ]
  • To: <xml-dev@lists.xml.org>
  • Subject: [xml-dev] XML / HTML Transport size
  • From: "Gerben Rampaart (Casnet Mechelen)" <Gerben@Casnet.net>
  • Date: Mon, 18 Nov 2002 12:47:52 +0100
  • Importance: Normal

Hi XML'ers,

Hope you all had a good weekend.

I have this thing I have been thinking about lately. Now, I am going to put
this on the list, though, I know I am taking a risk of this being a newbie
question. But here goes:

Isn't it a fact that the transport of both HTML and XML (especially XML)
over HTTP is a bandwidth-absorbing thing? Big XML files that come from (for
example) web services or simply B2B or B2C data transfer over the Internet
take allot of time to send and receive, which makes connections and overall
communications slower. This could be considered a problem, right? XML is not
designed for a slow Internet. Is this correct?

Compression has been around a long time with things like pkunzip, arj,
WinZip, gzip, rar ... and so on. For each platform there are numerous ways
to compress and decompress files. It takes no Computer Scientist to know
that one of the things that is most effectively compressed are text

Which brings me to XML (let's not include HTML now, since the HTML
transferred over the Internet (like a Web Page) is usually not so large) ...
Since bandwidth is a way more precious 'good' than CPU cycles, can W3C come
with a standard that compresses XML files before sending and decompresses
when arriving. This will cost more CPU cycles but (much) less bandwidth.
Obviously the standard (specification) should contain a platform independent
way of compression.

Now, before everyone jumps on me. Yes, I know this will run into problems
with Security, because what would the compressed file contain? Will it be
XML or a malicious script? I am sure that there are things to control this,
although I don't have the answers now. What about a Firewall? XML is text
based and can travel over HTTP, if compressed, will firewalls still accept
this? There are a lot of questions I cannot answer, but maybe you can.

This was just a thought, maybe an impossible one, but I was wondering what
the technical reasons are for this not to exist. Again, this could be a
newbie question, but I hope you can explain me.


Gerben Rampaart.


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

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