RE: Compression

[Andrew Morrow <amorrow@crcg.edu>]

With respect to the compression aspect, you may be interested in looking at
Millau, at http://www9.org/w9cdrom/154/154.html. Millau was designed as a
binary XML compression method that is schema aware, and therefor can achieve
superior  compression over ZIP compression for XML documents less than 5k.
Their paper also demonstrates parsing performance improvements, and they
experimented with an XML-RPC server exchanging Millau encoded XML.


							-Andrew



-----Original Message-----
From: Danny Ayers [mailto:danny@panlanka.net]
Sent: Thursday, February 15, 2001 11:58 AM
To: Xml-Dev
Subject: RE: Compression


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
<-


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: xml-dev-request@lists.xml.org