Re: Compression

[Caroline Clewlow <cclewlow@eris.dera.gov.uk>]

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