Interresting paper on the subject.<br><br><a href="http://xml.coverpages.org/AugeriExpCS-2007.pdf">http://xml.coverpages.org/AugeriExpCS-2007.pdf</a><br><br clear="all">_____________________________<br>Luc Boudreau<br>
<br><br><div class="gmail_quote">On Fri, Aug 7, 2009 at 1:00 PM, Julian Hyde <span dir="ltr">&lt;<a href="mailto:jhyde@pentaho.com">jhyde@pentaho.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">





<div><div class="im">
<div><font color="#000080" face="Lucida Sans" size="2"></font> </div><font color="#000080" face="Lucida Sans" size="2"></font><font color="#000080" face="Lucida Sans" size="2"></font><br>
<blockquote style="border-left: 2px solid rgb(0, 0, 128); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
  <div><span><font color="#000080" face="Lucida Sans" size="2"> Matt Campbell wrote:</font></span></div>
  <div><span><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
  <div>Regarding compression:  Analysis Services 2005+ uses a compressed 
  binary representation of their XMLA as the default mechanism, but their binary 
  protocol is proprietary.  Without an open standard we&#39;d have no way to 
  compress the XMLA in a way that clients could understand.</div></blockquote>
</div><div><span><font color="#000080" face="Lucida Sans" size="2">Matt,</font></span></div>
<div><span><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2">I tend to think the same way as you on matters of standards 
compliance. <span><font color="#000080" face="Lucida Sans" size="2">I think that by defining a very verbose standard, and then 
making compression a non-standard extension, Microsoft sent us all down the 
river and kept the only paddle.</font></span></font></span></div>
<div><span><font color="#000080" face="Lucida Sans" size="2"><span></span></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2"><span></span>XML compression is the 
obvious solution here. The compression rate should be so high, and so easy, that 
it will improve CPU utilization as well as bandwidth. Absent an open standard, 
if we were to use a widely used, open source XML compression algorithm, I think 
it would be easy to incorporate into any client that wants 
it.</font></span></div>
<div><span><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span></span><span><font color="#000080" face="Lucida Sans" size="2">Specifically, could you incorporate it 
into your client? I&#39;m thinking that we&#39;d have an HTTP header in the request and 
response describing the compression algorithm to use, and you&#39;d have to 
interject a compressor/decompressor.</font></span></div>
<div><span><font color="#000080" face="Lucida Sans" size="2"></font></span> </div>
<div><span><font color="#000080" face="Lucida Sans" size="2">Assuming you could add a compressor/decompressor to your 
client, let&#39;s continue to consider that as an option. Does anyone know of any 
candidate compression algorithms? I suspect that it would be a compression 
algorithm targeted at XML specifically -- because of the characteristic 
problems/opportunities in XML data -- but we could consider 
others.</font></span></div>
<div><span><font color="#000080" face="Lucida Sans" size="2"></font></span> </div><font color="#888888">
<div><span><font color="#000080" face="Lucida Sans" size="2">Julian</font></span></div></font></div>
<br>_______________________________________________<br>
Mondrian mailing list<br>
<a href="mailto:Mondrian@pentaho.org">Mondrian@pentaho.org</a><br>
<a href="http://lists.pentaho.org/mailman/listinfo/mondrian" target="_blank">http://lists.pentaho.org/mailman/listinfo/mondrian</a><br>
<br></blockquote></div><br>