I think you're absolutely right, it's compatibility with Excel pivot tables that's driving this. But that only means that everyone's XMLA is compatible where it matters for Excel, and that's not all XMLA. I still think it would be great to see the XMLA council resurrected for the reasons I gave in the blog post you link to - it would make the client tools vendors lives much easier, and it would mean consultants like me and developers would be able to move between platforms more easily without having to remember so many platform-specific tricks and quirks.

The major problem with the MDX/XMLA connectivity with Excel is that Excel does not support XMLA but requires an ODBO link, hence the requirement to buy a ODBO/XMLA "driver" and plug-it as a a data source in Excel.

This is rather odd as Analysis Server supports both ODBO and XMLA.

What is microsoft plan to support XMLA natively in Excel ?

I mean XMLA in the widest sense, which includes MDX. Excel is certainly the client tool that 'everyone' or at least the vast majority of people want to use, but Excel doesn't know and doesn't care about vast areas of MDX functionality - for example the MDX you use when you're writing calculated members. It's the cross-platform compatibility of that type of MDX that I'm referring to.

And to go back to XMLA, even if it were true to say that (for example)

* Excel can connect to Analysis Services

* Excel can connect to PALO

* Third-party client tool can connect to Analysis Services

It wouldn't follow that

* Third-party client tool can connect to PALO

For that to always be the case, the third party tool would have to use XMLA in exactly the same way as Excel does, and that's very unlikely isn't it?

I'm not being clear - I know Excel knows about how to create a calculated member, but it doesn't (and probably never will) know how to define a calculated member. Could I take the same cube definition and the same calculated member, and be sure that calculated member would behave in exactly the same way and give the same results on two different platforms? I don't think so. More advanced client tools will want to be able to create their own calculated members (for example, for Pareto analysis) but can't guarantee that these calculated members will work consistently across platforms.

And anyway, whoever said it had to be a choice between the free market and committee control? Why can't we have both? Excel and the XMLA Council? Surely both is better than just one.

Thanks for your answer. I can understand your point of view.

So it seems the best alternative for an OLAP server is to offer both protocols ODBO and XMLA if we want to avoid deploying client side protocol converters.  

Where can we find the specifications of the ODBO protocol ?

Thanks