In a recent XML-Deviant column, "The Pace of Innovation", I examined the still contentious, often puzzling issue of XML tools support, especially for end users. Even after five long years of XML development, the ideal and ubiquitous "XML editor for humans" seems more rumor than reality. Could it be that we have underestimated the difficulty of building a tool with which ordinary people can easily and simply create XML content?
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 | |
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.
How key is Microsoft Office to the future of XML editing? Share your views on this topic in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Titles Only | Oldest First |
- Generating GUI from XML Schema
2003-04-25 02:39:10 s s [Reply]
Hi all,
we are an XML technology company based in Zurich, Switzerland. We have also heard about Microsoft's new XML strategy.
Our tool called JAXFront has been used in different huge XML projects here in Switzerland for editing XML streams...
Check it out: http://www.jaxfront.com
We are interested in getting any feedback!
Best regards,
Stephan
- So What Did You Expect?
2003-04-25 03:48:37 Kurt Cagle [Reply]
I think that there is a tendency to look at Microsoft's motives and suspect a deliberate attempt at obfuscation on their part. Some of that may be there, but the more I look into Microsoft (and being within a few miles of Redmond campus I am over there a fair amount) the more I think that Word's XML feature can be chalked up more to a world view that wants to see everything, including XML, wrapped up within some form of procedural API. To expose the XML directly violates a major precept in the MS Psyche that proprietary content should be proprietary. Period. To expect them to do anything else is to miss the point that the culture is so strongly indoctrinated against anything even remotely open source/open standard that trying to promote the merits of open standards is about as useful as (well, I can think of any number of religious metaphors here, but I won't go into them).
As to the point about XML being presentable for only Pro and Enterprise ... Pro and Enterprise are both notable for their much tighter integration with web services than the other versions are. The assumption that the XML in question will be from a web service is very strongly promoted.
On the other hand, I'm not so sure I agree with Andrew Watt's geek comments. I've run into any number of small and mid-size shops that are using Open Office for three reasons - it's cheap, it produces workable XML and it has some nicely integrated features to it. They really like the fact that schema is publically available, and many are already building applications around Office as an XML server.
- Kurt Cagle
- At Microsoft's Mercy
2003-04-25 05:56:36 Bill Wade [Reply]
SGML has been available for decades as an open standard for the storage of documents. SGML offers much better support for the storage of content and markup than either XML or HTML. If there was a real demand within the business community for an office suite that uses a fully interchangeable storage format we'd have seen something emerge by this time, and SGML suites simply haven't penetrated the business market. The truth of the matter is that most businesses aren't too concerned that their office suite applications use a proprietary document format.
- effect of including Infopath only in high-end MSOffice
2003-04-29 16:38:41 Jonathan Kajeckas [Reply]
I recently attended a Microsoft marketing session aimed at technical solution providers. The demo used was almost trivial, filling in a form twice and having it's contents appear in a summary document, rather than feeding that to, e.g. an Access database. This tells me the marketing machine isn't fully cranked up.
And it would need to be to sell to this audience. They mostly deal with small businesses and peer-to-peer networks, many build white boxes. If they're going to adopt XML to, for example, automate how a customer fills in a form to request services from a small business, it will be because a larger company that requires it has engineered a solution.
- WordML -> DocBook
2003-12-10 20:24:11 no spam [Reply]
Someone (presumably said XSLT "uber-geek") needs to write an XSL template to convert WordML to DocBook.
Also, see:
http://sourceforge.net/projects/docbook/
