Compression

[Danny Ayers <danny@panlanka.net>]

Hi,
Just a thought - presumably not original.
Ok, big arguments against of transmitting XML in a compressed binary form is
that we lose the standardization, and with it the ease of interpretation. So
what about making a negotiated dialog of the transfer :

Scenario 1 :

A tells B (in straight XML) that it has some data for it, and it knows how
to compress in the format specified at URI http://zip
B replies fine, I know know that format
A zips the XML and sends it
B unzips the file and uses the data

Scenario 2 :

A tells B (in straight XML) that it has some data for it, and it knows how
to compress in the format specified at URI http://zip
B replies sorry, I don't know that format
A sends plain XML

Now lets say that at URI http://zip there is a pointer to a place that holds
the decompression algorithm, or a ready-compiled converter (or converters
for different platforms)

Scenario 3 :

A tells B (in straight XML) that it has some data for it, and it knows how
to compress in the format specified at URI http://zip
B replies - please wait
B goes to the URL pointed to at http://zip, downloads and installs the
converter
B tells A, I'm ready
A sends binary...

Some of this negotiation could probably be tucked into PIs.

A harder (but quite interesting) alternative would be to have a pointer on
http://zip  to a document specifying the (de)compression algorithm, from
which B could build its own native converter.

I find the idea of compressed XML a bit lumpy, but a system like this could
at least make it more transparent. Obviously the conversation needs a bit of
extra bandwidth than a straight send, but this would by offset in a big way
if there was a lot of data.

I'm sure there are a lot of other situations outside compression where such
a system could be used, which is why I presume the idea isn't original ;-)

Cheers,
Danny.

---
Danny Ayers
http://www.isacat.net