Cart
[Home] [By Thread] [By Date] [Recent Entries]
"Simon St.Laurent" wrote: > Any thoughts? I like the fact that XML is verbose when I'm editing and > processing, but it's not so good in transmission. I'd like to think that > there's a good _general_ solution that will let us have the best of both > worlds. HTTP supports compression via Accept-Encoding and Content-Encoding. The types of compression encodings currently registered are compress, gzip, and deflate (in increasing order of use, AFAIK); http://www.isi.edu/in-notes/iana/assignments/http-parameters You're right though, it does impact content-type, per HTTP 1.1; 19.4.3 Introduction of Content-Encoding MIME does not include any concept equivalent to HTTP/1.1's Content- Encoding header field. Since this acts as a modifier on the media type, proxies and gateways from HTTP to MIME-compliant protocols MUST either change the value of the Content-Type header field or decode the entity-body before forwarding the message. (Some experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" to perform an equivalent function as Content-Encoding. However, this parameter is not part of MIME.) I could see a generic XML-specific compression mechanism being developed; one that understands what "<" and ">" mean. But you don't have to wait for that to compress your XML today. MB -- Friends don't let friends do RPC *************************************************************************** This is xml-dev, the mailing list for XML developers. To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ ***************************************************************************
|
