RE: Compression

[Eugene Kuznetsov <eugene@datapower.com>]

Not to bring this back up, but this can be done using a real
standard that has been in use for a very long time and 
supports much of today's network infrastructure. It allows
flexible encodings, optional fields, constraints and future
extensibility. The more the sender and the receiver know about
the schema, the more efficient is the transmission and decoding.
BTW, it is definitely more efficient than either serialized 
parse trees (however compressed) or text-encoded data.

It's ASN.1.


\\ Eugene Kuznetsov
\\ eugene@datapower.com
\\ DataPower Technology, Inc.
 

> -----Original Message-----
> From: Caroline Clewlow [mailto:cclewlow@eris.dera.gov.uk]
> Sent: Thursday, February 15, 2001 11:32 AM
> 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