At Microsoft's Mercy

What troubles me even more, however, was the conclusion I reached in that column, namely, that the XML creation facilities in the next major release of Microsoft Office are the best, realistic hope for the future of the documents side of XML, at least in terms of mass market success. No other entity in the industry (in any industry, for that matter) is as able to swing mass numbers of computers users toward or away from specific technological solutions.

That conclusion troubled me then and troubles me today not only because of Microsoft's spotted history, but also because, if it's at all correct, it's not an enviable position for XML to occupy. A significant part of the robust vision of XML's success is the documents part of the XML application spectrum. The potential of XML will not be maximized unless or until it is used to exchange documents, freeing people and organizations from an inappropriate reliance on proprietary document-creation infrastructure and tools. But relying on one company to create ubiquitous end-user tools is no more a good position to occupy than is the one in which the people and organizations rely on a single vendor for proprietary access to their documents and data.

In other words, XML is important as a document exchange format insofar as it prevents (or, at least, mitigates) proprietary vendor lock-in, for both people and organizations. The XML industry must seek to avoid finding itself in a similar position, namely, one in which it relies upon Microsoft to make XML creation tools for end users ubiquitous. Of course, there are many smaller vendors which are building XML creation tools, many of which are very well designed and engineered. But smaller vendors can only do so much to influence or to oppose the juggernaut.

All of this is relevant again because of some conversations which have been taking place recently on XML-DEV, including news that the XML tools in the next version of Microsoft Office may not be as useful as was previously believed by the XML development community.

As John Cowan pointed out, the XML facilities of Office 2003 will be limited in some substantial ways. According to a CNET report, of the six (six!) different versions of Office 2003, only Office Enterprise and Office Professional will permit the creation of user-defined XML schemas. Daniel Veillard's reaction to the news, that this move by Microsoft allows the OpenOffice developers time to deploy their own XML-rich and standards-compliant Office suite, simply highlights the degree to which XML plays or is perceived to play a strategic role in the future of the application suites.

Mike Champion offered an interesting gloss on Veillard's claim, saying that OpenOffice is preferable to MS Word, if only because the XML which MS Word creates is so terrible:

One might argue that it creates a window of opportunity for OpenOffice because the XML it generates is so much more practical for downstream applications to work with than WordML, I guess. I honestly don't see why they bother with WordML; what is the point of storing data in XML if the schema is so hideous and proprietary than no one can use it without proprietary API support? What advantages does WordML have over the HTML-like stuff that current versions of Word generate on request? At least you can tidy.exe the HTML-like stuff into standard XML, but what can you do with WordML except load it into Word...unless of course you are an XSLT uber-geek?

Some reactions were more cynical, though it's hard to see that cynicism as unfounded. Uche Ogbuji, for example, suggested that it isn't in Microsoft's best interests to make Office data genuinely interchangeable via XML. Rather, it is in Microsoft's best interests for it to seem that Office data is interchangeable. "I have always been skeptical about Microsoft's ability to pull this off," Uche said, "...Microsoft has hired some really sharp people in the XML space lately...But I've always been skeptical that Microsoft has it in [its] DNA to make the fundamental changes in outlook required to truly open up XML to...Office users. Even the slickest UI cannot overcome a mismatch between the interests of a vendor and its customers..." (emphasis added).

Rick Jelliffe suggested a different explanation of the move. In his view, creating and manipulating structured documents falls outside the range of desired functionality for non-Professional, non-Enterprise Office users: "I think Corel's experience (and to a lesser extent Adobe's) gives us a big hint that being able to produce structured documents is simply not an important feature in the SOHO market".

Turning from explicit discussion of Microsoft's move, the XML-DEV conversation took up the question of the ideal role of XML in a business application suite. Andrew Watt was the first person to ask this question, answering it in a way which might have surprised some in the XML development community:

it seems to me that some of the pleas for fully open XML in office suites is simply thinly veiled special pleading for the XML geek lobby. Making a fully open XML in an office suite empowers not the user but the XML geek. So, in effect, the plea for fully open XML is, in some respects at least, a selfish request. One might even suggest that it would increase the power and revenue earning potential of XML geeks (at the expense of the office suite vendors). Moving power or data ownership from proprietary vendors to our own XML geekdom may be less altruistic than it at first appears.

The most obvious retort to Watt's point is to point out, as Seairth Jacobs did, that people and organizations have an interest in avoiding reliance on proprietary vendor tools; insofar as real XML interchange blunts that reliance, that's in the best interests of users, even if it's also in the best (but different) interests of XML geeks too:

Yes, but it's usually us geeks who create the tools the average users use. As a result, the benefit does still get passed along to the average user. I agree that many users will care little about the angle brackets. But by giving it to the geeks, we get to create a whole new set of abilities...that the users can take advantage of (and still not know the first thing about XML). Trying to do this same thing with proprietary file formats is simply out of the question, especially for the third-party geeks.

More to the point, I think, real (as opposed to only apparent) XML interchange in business application suites would mean that people and organizations could rely more fully on their own resources -- whether these are homegrown or outsourced isn't really at issue -- in order to manipulate and manage their own data in ways which are not dependent on any vendor. Which is a point John Cowan made with his usual wit:

Open data is like open source. The business proposition (from the user's standpoint) for open source is not that they get to tinker with the code themselves. It's that they are free to hire third parties, who have no axe to grind, to make such improvements. Similarly, if your data is trapped in Word, you can only do with it what Microsoft currently lets you do, and if you want more, you have no choice except to plead with Microsoft to do it...

Also in XML-Deviant

The More Things Change

Agile XML

Composition

Apple Watch

Life After Ajax?

Andrew Watt seemed largely unconvinced by these arguments, falling back to the view that all of this talk of utility and value is interest-relative and context-specific: "Whether it is better or worse for the user, or whether it is relevant for the user depends on circumstances. For some uses XML is irrelevant. For others the proprietary vendor package might be better than the XML geek one. Circumstances vary and so does the added value, if any, of 'open data':.

I have come to the provisional conclusion that Microsoft's decision to offer the really interesting XML bits of the new Office only in its high-end versions is likely not to be as harmful to as many relevant parties as it might first appear, though it does reaffirm the prudential wisdom of assuming the worst about Microsoft and waiting to be pleasantly surprised by the unexpected. For very large organizations, the kind which use the Professional and Enterprise versions of Office already, the interesting XML schema creation bits will be available, and that can only be a good thing in the long run. For smaller organizations and for individuals, if real XML interchange is important, they must either pony up for the more expensive versions of Office or, perhaps, explore alternatives like OpenOffice. And for those organizations and individuals who either do not understand the problems of proprietary vendor data capture or, understanding them, do not care, there's not a lot the XML development community can do for them anyway.