RE: Compression

[Danny Ayers <danny@panlanka.net>]

Well I never - my first 2 scenarios are covered by http 1.1 and the third
(difficult version) used by public/private key encryption.
(thanks Daniel, Jeff)

Cheers,
Danny.

<- -----Original Message-----
<- From: Danny Ayers [mailto:danny@panlanka.net]
<- Sent: 15 February 2001 17:51
<- To: Xml-Dev
<- Subject: Compression
<-
<-
<- 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
<-
<-
<- ------------------------------------------------------------------
<- To unsubscribe from this elist send a message with the single word
<- "unsubscribe" in the body to: xml-dev-request@lists.xml.org
<-