RE: Compression

[Danny Ayers <danny@panlanka.net>]

Nice idea, as long as you can arrange for the schema to be at the receiving
end. Now if you sent the schema first...

Cheers,
Danny.

<- -----Original Message-----
<- From: Caroline Clewlow [mailto:cclewlow@eris.dera.gov.uk]
<- Sent: 15 February 2001 22:32
<- To: Jeff Rafter
<- Cc: Danny Ayers; xml-dev@lists.xml.org
<- Subject: Re: Compression
<-
<-
<- As regards compression - one option that *we* have looked at is
<- that of the
<- schema being known at both the receiving and transmitting end of the
<- communication.  In that case a method can be used whereby the
<- transmission of
<- the tags themselves are not required.  A single bit can be used
<- to indicate the
<- presence or otherwise of an optional item, repeated items can
<- also be indicated
<- by 0 or 1 depending on whether they are repeated or not.  Then
<- it's just a case
<- of encoding the actual content between the tags.
<-
<- The XML document can be rebuilt at the receiving end by stepping
<- through the
<- schema checking the data for the content that is present.
<-
<- Hope the above description makes some sense !
<-
<- Regards
<-
<- Caroline
<-
<-
<- Jeff Rafter wrote:
<-
<- > > 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 don't know if it would be recreating the wheel-- or rather if this
<- > compression system would be re-using the wheel-- but it seems that
<- > encryption (public key/private key) fits very well in this
<- model.  This is
<- > plain in scenario three:
<- >
<- > Scenario 3 :
<- >
<- >  A tells B (in straight XML) that it has some data for it, and
<- it wants to
<- > encrypt it in the format found at URI http://encrypt with the
<- decryption key
<- > found at http://a/decrypt
<- > B replies - please wait
<- > B goes to the URL pointed to at http://encrypt, downloads and
<- installs the
<- > decryption algorithim (if not already present) and then
<- downloads the public
<- > key from http://a/decrypt
<- > B tells A, I'm ready
<- > A sends encrypted binary...
<- >
<- > Jeff Rafter
<- >
<- > ------------------------------------------------------------------
<- > To unsubscribe from this elist send a message with the single word
<- > "unsubscribe" in the body to: xml-dev-request@lists.xml.org
<-