In terms of #1, I have developed clients against Saiku and Xmla servers and there is a difference in retrieving metadata.<div><br></div><div>In Saiku, to get down to levels, which is generally where you need to be to formulate a query, you need Catalogs, schemas and cubes which come in one convenient HTTP request. Then for each cube you have dimensions and measures each in their own HTTP request. So 1 + (N*2) HTTP requests.</div>
<div><br></div><div>In Xmla, it is more linear.  You need datasources, catalogs and cubes. In this case each with its own HTTP request. 3+(N*4).  In the case of Xmla you need to call dimensions, hierarchies, levels, measures separately.</div>
<div><br></div><div>What I would &quot;like&quot; to see is not in the Xmla standard but one HTTP call to discover all the cubes with associated details for the catalog and not just CATALOG_NAME.  And then one HTTP call to get all the details, outside of members, for each cube. 1+(N*1). Saiku is close, but makes you get measures and dimension data separately although measures are really dimensions.</div>
<div><br></div><div>In terms of #2, the client doing the processing... Javascript Object Notation (JSON) will obviously be more easy in Javascript than XML.  Everyone knows where I stand on XML.  However, Roland&#39;s library has hidden all of the nasty bits away from me.</div>
<div><br></div><div>I don&#39;t like the fact that an Xmla Cellset can have missing cells in the cell list. That makes processing the results a real pain.  Some may not agree, but I would like to see this not happen.  I do realize that that Xmla spec says it can happen.</div>
<div><br></div><div>What would be good is if we could retain the MD portion of the Cellset like full axis positions, etc.. and have the results streamlined.  I don&#39;t think we need a node for each cell that is returned, just have a JSON array of the cells in Axis position order.  Since you cannot have an axis 1 without and axis 0, etc.. this should be fairly easy.  So something in between the tabular results and the MDDataSet results. Maybe something more like what CDA does with a metadata object and then an array of arrays of restuls.  I have done something like this on the client side in olap4js where the number of cells should be the number of axis * number of hierarchies on each axis * number of positions in each hierarchy.</div>
<div><br></div><div>For those who are unaware, the olap4js project bridges both of these 2 backends for the client javascript developer.  Each has its own implementation/drive like olap4j but works in the host environment.  It could be Node/Rhino on the server or xmla, saiku in the browser.  It also includes a client side query model in javascript which neither Xmla or Saiku have at the moment.  Suggestions welcome.</div>
<div><a href="https://github.com/agrohe21/olap4js">https://github.com/agrohe21/olap4js</a>
</div><div><br></div><div><br><br><div class="gmail_quote">On Tue, Sep 18, 2012 at 6:29 PM, Paul Stoellberger <span dir="ltr">&lt;<a href="mailto:p.stoellberger@gmail.com" target="_blank">p.stoellberger@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">One of my biggest concerns over xmla-like communication is the overall overhead in a) number http calls b) processing the results<div>
<br></div><div>With this row (array) based results we will have to build in logic into the client to be able to understand the logic behind catalogs, schemas, cubes and how they correlate and turn those rows into objects instead of returning objects directly, as we do in saiku today. In order to work with this data I need those objects, and this just doesn&#39;t feel right to me. </div>
<div><br></div><div>Furthermore this will have to be processed by the client. Now I know this is probably not something very expensive to do but I would rather keep the necessary logic and processing on the client side to an absolute minimum. Doing the same transformations on server side code will always be faster and therefore deliver a better user experience to the user. The less the browser has to work, the better.</div>
<div><br></div><div>But my major point of concern is the number of server calls needed to retrieve the necessary metadata information. </div><div>I admit I don&#39;t know the details about all xmla calls but what I can tell by looking at olap4j&#39;s xmla driver there are a lot of round trips needed to retrieve all the information necessary. I have plans to understand those calls better in order to improve the xmla driver. Maybe I&#39;m wrong, so feel free to convince me otherwise.</div>
<div><br></div><div>Regarding standards, are there any other OLAP servers that return metadata in a xmla like manner?</div><div>What was good for xml, doesn&#39;t have to be necessarily the best for todays &quot;ways of doing things&quot;. </div>
<div>People were able to consume xmla (like Andy / Roland proved successfully) directly before, however we got great feedback from web developers who confirmed how easy it is to work with our (metadata) API.</div><div>When I look at public API&#39;s like github&#39;s I see rich JSON objects and not row based resultsets.</div>
<div>What are your arguments to keeping the structure completely the same but just switching from xml to json?</div><div><br></div><div>Metadata calls are pretty straightforward and there is not much you can do differently, so I am happy to adapt to a better standard (although having 1 server return the data this way doesn&#39;t make it a standard).</div>
<div><br></div><div>However, the best API and standards don&#39;t make good software. My biggest concern is to make things work. </div><div>If it means I can do stuff more efficient (less http calls, less processing needed) I prefer that over a &quot;clean&quot; API.</div>
<div><br></div><div>But maybe in order to move forward:</div><div>Maybe there is a way how we can turn those xmla like results into something nice thats still mappable to xmla results.</div><div>E.g. the JSON you pasted below:</div>
<div>If &quot;row&quot; becomes &quot;cube&quot; and this cube element (can) contain already hierarchy and/or level information in the same result, but still keep the xmla like result style that would make me already happy.</div>
<div><br></div><div>Andy, Roland ... you two have probably the best insights on this topic so it would be great if you could share your opinion with us as well!</div><span class="HOEnZb"><font color="#888888"><div><br></div>
<div>-Paul</div></font></span><div><div class="h5"><div><br></div><div><br></div><div><br><div><div>On Sep 19, 2012, at 12:44 AM, Julian Hyde wrote:</div><br><blockquote type="cite"><div style="word-wrap:break-word">Paul,<div>
<br></div><div>On IRC yesterday you said there was a more efficient JSON representation of XMLA responses than the one implemented in olap4j-xmlaserver (formerly Mondrian&#39;s XMLA server).</div><div><br></div><div>There are some examples in XmlaBasicTest [ see <a href="https://raw.github.com/pentaho/mondrian/master/testsrc/main/mondrian/xmla/XmlaBasicTest.ref.xml" target="_blank">https://raw.github.com/pentaho/mondrian/master/testsrc/main/mondrian/xmla/XmlaBasicTest.ref.xml</a> and search for &quot;Json&quot; ]. One is</div>
<div><pre style="word-wrap:break-word;white-space:pre-wrap">&quot;cxmla:DiscoverResponse&quot;: {
  &quot;xmlns:cxmla&quot;: &quot;urn:schemas-microsoft-com:xml-analysis&quot;,
  &quot;cxmla:return&quot;: {
    &quot;root&quot;: {
      &quot;xmlns&quot;: &quot;urn:schemas-microsoft-com:xml-analysis:rowset&quot;,
      &quot;xmlns:xsi&quot;: &quot;<a href="http://www.w3.org/2001/XMLSchema-instance" target="_blank">http://www.w3.org/2001/XMLSchema-instance</a>&quot;,
      &quot;xmlns:xsd&quot;: &quot;<a href="http://www.w3.org/2001/XMLSchema" target="_blank">http://www.w3.org/2001/XMLSchema</a>&quot;,
      &quot;xmlns:EX&quot;: &quot;urn:schemas-microsoft-com:xml-analysis:exception&quot;,
      &quot;row&quot;: [
        {
          &quot;CATALOG_NAME&quot;: &quot;FoodMart&quot;,
          &quot;SCHEMA_NAME&quot;: &quot;FoodMart&quot;,
          &quot;CUBE_NAME&quot;: &quot;HR&quot;,
          &quot;CUBE_TYPE&quot;: &quot;CUBE&quot;,
          &quot;LAST_SCHEMA_UPDATE&quot;: &quot;xxxx-xx-xxTxx:xx:xx&quot;,
          &quot;IS_DRILLTHROUGH_ENABLED&quot;: true,
          &quot;IS_WRITE_ENABLED&quot;: false,
          &quot;IS_LINKABLE&quot;: false,
          &quot;IS_SQL_ENABLED&quot;: false,
          &quot;CUBE_CAPTION&quot;: &quot;HR&quot;,
          &quot;DESCRIPTION&quot;: &quot;FoodMart Schema - HR Cube&quot;
        },
        {
          &quot;CATALOG_NAME&quot;: &quot;FoodMart&quot;,
          &quot;SCHEMA_NAME&quot;: &quot;FoodMart&quot;,
          &quot;CUBE_NAME&quot;: &quot;Sales&quot;,
          &quot;CUBE_TYPE&quot;: &quot;CUBE&quot;,
          &quot;LAST_SCHEMA_UPDATE&quot;: &quot;xxxx-xx-xxTxx:xx:xx&quot;,
          &quot;IS_DRILLTHROUGH_ENABLED&quot;: true,
          &quot;IS_WRITE_ENABLED&quot;: false,
          &quot;IS_LINKABLE&quot;: false,
          &quot;IS_SQL_ENABLED&quot;: false,
          &quot;CUBE_CAPTION&quot;: &quot;Sales&quot;,
          &quot;DESCRIPTION&quot;: &quot;FoodMart Schema - Sales Cube&quot;
        },</pre><div>                ...</div></div><div><br></div><div>and there&#39;s another that returns nested metadata (cubes, dimensions, hierarchies, etc.) and another that returns a cell set.</div><div><br></div>
<div>I&#39;m open to making this more concise and &quot;json-like&quot; as long as there is a clear mapping from the XMLA spec. (If we depart from the spec entirely we&#39;re back in the wild west, where clients can only rely on their own server.) If you have some ideas please propose them.</div>
<div><br></div><div>Julian</div><div><br></div><br><br><div>
<div>Julian Hyde</div><div><a href="mailto:jhyde@pentaho.com" target="_blank">jhyde@pentaho.com</a></div><div><br></div><br>

</div>
<br></div></blockquote></div><br></div></div></div></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></div>