Will XML Win the Open Format Wars?

Standards organizations and software vendors back various contenders.

Last week was an interesting time for XML as an open format. A standards organization known as Ecma International approved Microsoft's Open XML, the default document format in Office 2007, as an international data standard -- despite objections from IBM. Ecma, a nonprofit industry association of technology developers, vendors and users, is responsible for future development of Open XML.

In approving the specification, Ecma's General Assembly meeting in Geneva also agreed to submit the standard for adoption by the ISO (International Organization for Standardization). ISO approval would greatly increase the new standard's use by a myriad of organizations.

Theoretically, standardizing Open XML will aid interoperability between Office and other competing software, such as Corel's WordPerfect and OpenOffice, an open source suite. Approval of the specification, however, was not unanimous. IBM voted against Open XML, saying OpenDocument (having already earned ISO approval), which is the default format in OpenOffice, is a "vastly superior" format, and another standard was unnecessary. IBM, not surprisingly, was the only Ecma member to vote against Open XML's approval. Sounds like this could devolve into a battle of dueling document standards -- and XML could be the basis on which the battle is fought.

Obviously, like document format standards, CAD standards matter a great deal financially, because they influence which software products companies choose to buy. And, although there are many so-called open standards bandied about, such as IGES, STEP, JT Open (proposed by UGS) and 3D XML (proposed by Dassault Systemes), there is currently no such thing as a universally accepted standard for data exchange. Again, like document standards, the existence of multiple standards exposes the intertwined nature of technology standards and politics. Much like political parties taking sides on a pivotal issue, factions with company-specific and/or alliance interests continue to align themselves to their respective best advantage. However, XML might be the common ground that ultimately wins.

Why Standardize?

A strong case can be made for XML-based feature mechanical CAD models, because XML has the ability to abstract a design and the language of a given discipline (in this case, mechanical design and engineering) from the application that generates it. It effectively makes any type of data a relational database that can integrate with other applications, in CAD and beyond.

Vendors who continue to think that proprietary file formats secure their market share forget that very few supply chains, for a number of reasons, don't standardize on a single design software package. While there are certainly instances where a supplier or customer dictates the use of a specific design application, given the choice, most customers purchase software that fulfills their needs, and data format is probably not high on the list for ultimately making the "buy" decision.

Then there’s the problem of "dumb" files as software companies provide their content in neutral formats -- those stripped of original design intent, mating relations and part instancing. Whoever downloads part files, for example, then has to reconstruct them with attribute data, such as materials specifications, voltage requirements and part numbers.

Simply put, proprietary file formats contribute to wasted time in design development and errors introduced during rework. For example, to a new user, it might seem advantageous that he or she can import an IGES file that an OEM has published on its Web site. However, IGES describes models only as surfaces, so, while transforming it into a usable part, the user might inadvertently change critical information about surface topology, and then put in information like draft angles, screw threads, fits and drill sizes. It's a process that can involve a lot of guesswork, and it's no secret what that can lead to!

On the other hand, an XML standard for describing and attributing design data is the only real alternative to vendors writing massive numbers of file importers, exporters and translators -- all with widely varying levels of success and data integrity. I would guess that most users would opt for software based on its capacity to represent and preserve design intent.

An open standard, such as XML, could improve every participating vendor's ability to focus and compete based on their software's core functionality and performance. The biggest hurdle would likely be the fact that several CAD vendors would have to work together to provide input and insight for a common goal (and how likely is that?). In the end, though, customers would benefit because they could create designs in any participating package that they wanted to, knowing that their data would have absolute integrity if and when it was used in another package (yes, a competing package).

The XML part of the equation must be transparent so that software developers inside and outside CAD can query, analyze and report on that data without dealing with heaps of encrypted junk. This would require that the designers, not the software vendor, be the owners of the data. It really shouldn't be up to a vendor to determine what's revealed in a design and what's kept locked up -- but that's not a can of worms we're going to open here.

Open Format Wars

For all this to work, a standard incorporating XML must be overseen and audited by a truly neutral entity or standards body to ensure that it meets the benchmarks and requirements of an open standard. Remember that an open standard is one that is made available under the auspices of ISO or another standards organization.

I realize that an XML standard may be far-fetched; we can't forget that other vendors have their own so-called "open" formats that perform a similar function, at least according to them. For example, UGS has its JT format, 3DXML is XML-based, Dassault has stated that it will be a "pervasive 3D open standard for PLM," and so on. However, none of them can be a truly regarded as open standards because they have been developed by vendors specifically for use in a particular product set.

Although it would require cooperation and effort on a huge scale, an XML-based MCAD data format could become a de facto standard in the future if it’s adopted by enough vendors who are able to develop XML applications with it. For the time being, though, the best we can hope for is a standard put forth by the various vendors with their customers in mind. Will it ever move beyond today's file format hodgepodge? Ultimately it will, but not in the short term; there is still too much at stake in the "open" format wars for most vendors to give up.