Re: Compression

[Jon Cleaver <j.cleaver@eris.dera.gov.uk>]

Or you simply publish the schema first on a public facing server (encrypted if
needs be) and transmit the namespace in which it resides so you can both be
looking at the same one... Net result is that you have unambiguous, compressed
transmission  without having to send large gobs of XML over the wire.

Danny Ayers wrote:

> 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
> <-
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: xml-dev-request@lists.xml.org