XML for Analysis Decoded

The XML for Analysis API has snared widespread support. But will the big fish slip through the .Net in favor of Java and proprietary APIs?

By Seth Grimes

Now computing technologies typically bring forth a torrent of buzzwords, acronyms, and jargon. Extensible markup language (XML) is now: It has been hyped as a data-interchange panacea and is a key component in industry battles for "Web services" ascendancy. One of its dialects, XML for Analysis, is the subject of this column. Brace yourself.

XML is a great tool for applying structure to data and for publishing structured data. It distinguishes content from presentation and from context: what things are from how they appear and how they are related. And XML can handle tabular and multidimensional data as well as composite data types - compound types comprising several fields of different atomic types - so relational and object database schemas map readily to XML.

Sounds great, right?

It does to several analytic software vendors, particularly to those looking to deliver business intelligence (BI) capabilities via Web browsers and other "thin" clients, which is just about all of them. Products using XML for output formatting have been shipping for a couple of years now.

Enter Microsoft, whose OLE DB for OLAP is perhaps the leading analytic interface, a de facto online analytic processing (OLAP) market standard. (As a standard, it competes with the OLAP Council's Multi-Dimensional query API.) OLE DB for OLAP is an example of a call interface, a set of functions invoked by a client computer program in a LAN environment. It is complemented by Microsoft's proprietary multidimensional expressions (MDX) language, just as call interfaces from other leading OLAP server vendors - Hyperion Solutions and Oracle in particular - are complemented by proprietary query and data management command languages.

Object linking and embedding (OLE) is a mechanism for software-component interoperability within Microsoft's proprietary COM. OLE DB for OLAP is tied to the COM platform, which even Microsoft admits is ill-suited to distributed object computing over the Internet. Microsoft is replacing COM with the .Net Web-services strategy; XML for Analysis is .Net's interface for analytic services.

Hyperion joined Microsoft's initiative soon after the release of the beta specification last fall and cosponsored the recently issued 1.0 release. Twenty-two other software vendors endorsed the specification. Notably absent were BI heavyweights IBM, Oracle, and SAS Institute and metadata master Informatica.

WHAT'S IT ALL ABOUT?

XML for Analysis is more than a set of press releases, but it's also far from shipping in commercial client tools or analytic databases. Microsoft has released a software development kit (SDK) for the Visual Studio.Net development environment, which itself is slated to ship later this year, but it's likely that an XML for Analysis enabled database won't ship before next year and that few third-party client tools will ship before mid-2002.

XML for Analysis has been hyped as providing a single API for querying multiple data sources, a dream that is far from reality. Although the specification's Discover method seems to be a fairly well articulated way to find out about data sources and how to query them, the Execute method is currently little more than a channel for passing MDX commands to a data source.

Hyperion doesn't currently support MDX, and in the opinion of the product-management director at one tool vendor, "As XML for Analysis is very closely based on the existing Microsoft interface, Hyperion [will] face a significantly harder task in supporting the common standard." Donald MacCormick, product-marketing director at CrystalDecisions, told me that, similarly, "our language [in hybrid-OLAP product Holos] for manipulating OLAP data is rather different from MDX as it has to act as both a query language (like MDX) and as a data-manipulation and cube-building language." Oracle and SAS Institute are other, prominent OLAP vendors that don't support MDX and would have a hard time shoe-horning their own languages into the narrow capabilities of an MDX-based language.

A new multidimensional-expression language, mdXML, will eventually supercede MDX. Although mdXML would be extendable to take advantage of special features of different analysis servers, Microsoft will control development and delivery is years away. So given language differences, I don't see that client-side developers planning multiserver access could even contemplate avoiding programming to multiple APIs for years. Structures that describe command-language vocabulary and grammar, essentially mapping each language to a canonical analytic manipulation and query language, could help bridge the language differences. I hope to see advances in query language representations that will overcome the stuntedness of XML for Analysis's Execute method, but I don't believe that specification sponsors have discussed such a project yet.

An industry analyst quoted in the Microsoft-Hyperion press release announcing the specification apparently bought the single-interface hype when he wrote that the jointly supported API "will clearly benefit users because client-side, Web-based applications will be able to readily access ... the servers of ... vendors that adopt the specification without having to program for multiple APIs." The specification does provide uniform data structures, but vendors will still have to program each individual data source's data manipulation and query language.

Many vendors have endorsed the Microsoft-Hyperion specification, but are they adopting it? Check out the quotations provided by vendors that support the specification (www.essbase.com/main.asp?Webpagekey=347). Only two out of eight stated clearly that they intend to implement an XML for Analysis API. To gauge the real level of support, I contacted several vendors. Close Microsoft allies have concrete plans to implement the new API: ProClarity (formerly Knosys), which marches "in lockstep with Microsoft"; Panorama Software, which sold Microsoft its original OLAP server software; and CrystalDecisions, which has Crystal Analysis, a client tool that supports MDX. By contrast, AlphaBlox, which endorsed the specification, is not actively developing an XML for Analysis implementation. Marketing executives Len D'Amico and Andre Bakken told me that customers have asked about support for the API but that the company has metadata-mapping work to do and is waiting for a usable textual representation for queries.

And what about Hyperion? It expects to ship an XML for Analysis API in its Essbase analytic database by the end of the year, according to product general manager Robert Gersten. This API will support thin clients and be especially attractive for wireless access and small data volumes, although a performance slowdown due to XML translation and transmission overhead is a concern. But whether for this reason or some other, such as lack of market demand, Hyperion has no plans to write XML for Analysis into any of its client tools, such as Analyzer (formerly Wired for OLAP) and Hyperion's financial, budgeting, and Web-analysis tools.