| Previous | Table of Contents | Next |
Because XML has the potential to become a standard format for virtually all documents in an organization, many people who never thought about data formats before (and probably don’t want to think about them now) are likely to be affected by XML development. Companies that have standardized on commercial document management (mostly word processing) tools have the opportunity to switch to a far more flexible and indeed customizable solution. Planning for a change of this magnitude will probably take years of consideration and slow conversion from the old ways to the new.
The good old days where the Web development team was a strange group of techies and designers isolated in a former storage room are coming to an end. When the Web moves inside the company, rather than just projecting data outward, the development team can no longer live at the borders of the organization. Intranets have already begun this process. Employees who might not even have computer backgrounds have become grassroots Webmasters, using personal Web servers and other small-scale tools to distribute data. Some corporations have established central Web servers for departments or divisions, giving the smaller organizations responsibility for their own content.
XML has the potential to penetrate enterprises far more deeply than even the latest wave of Intranet applications, becoming a standard format on nearly every desktop. XML is more than just a format for Web and printed documents. XML can provide a database format, a container for control instructions, a generic interchange format, and a variety of other applications that will undoubtedly come along. XML’s extreme flexibility gives it incredible power to reach into nearly every data processing application, not just word processing and Web development.
This reach means that XML developers must talk to many more people inside an organization than Web developers have had to in order to develop standards that meet the organization’s needs. Organizing Web development has been mostly a matter of interface design and content automation—taking content from various sources, converting them to HTML, and presenting them attractively. Organizing XML development requires close examination of content design and workflow automation. Presentation may still be important, but XML allows developers to ask that documents use XML and a standard DTD as their native format, avoiding the costs of conversion and opening up powerful new possibilities for document management. This obviously won’t happen immediately; the process may take years, but it probably won’t happen at all if developers lurch forward with poorly designed document structures that cause more mayhem than they fix.
Avoiding that mayhem requires considerable consultation with users. Even if your Web development efforts have been moved from the computing department to marketing, it’s time to go back to computing and talk about what can be done to ensure compatibility in the long run. Designers who have spent the past few years forcing HTML to present pages precisely the way they want them must talk with database managers whose data are organized in enormous tables and agree on some common solutions. Companies that may have standardized on a particular desktop applications suite to avoid the headaches of constant file conflicts may find that their large investment was merely an interim solution and that the real tools for document interchange are only starting to appear. Convincing users of the need to change will be a difficult process, even if software vendors extend support (as several have promised) for the new tools XML makes available.
| Haven’t I Heard This Before? XML and SGML’s Promises
The promise of a universal file format is hardly new. SGML has been promising similar breakthroughs for the last 15 years, and has very little to show for it except for significant use in mammoth organizations like the IRS, Department of Defense, and IBM. SGML is capable of everything that XML can do and considerably more. Despite its power, though, the only variety of SGML that has caught the public’s interest is HTML, which has very little of SGML’s power. Why should XML be any different? XML has several advantages over SGML. It’s largest advantage is that HTML has paved the way for it. The syntax of nested elements and attributes is now familiar to a very large number of people who had not seen it 5 years ago. HTML developers are also frequently frustrated by the limitations of the blunt tools they have had to use and are looking for significant improvements in their toolsets. XML and CSS seem to offer that, allowing Web developers to create pages to their own specifications rather than those of browser developers. Although XML is much more than a tool for Web development, the Web is probably the doorway by which it will enter the most organizations. XML’s second advantage is that it is considerably simpler than SGML. Even though it will probably sprout extensions and eventually come to resemble its overgrown parent, XML provides developers with much less to learn initially and fewer odd subtleties to master over the long run. Although XML has been developed by a W3C working group that grew out of an SGML group, the XML developers seem determined not to replay SGML’s reputation for mind-boggling complexity. XML promises to remain a markup language standard that ordinary users can comprehend, requiring XML gurus only occasionally. The last significant advantage that XML has is the SGML community, which seems interested in promoting this new descendant. The SGML community is in the process of adjusting a few of the SGML standards to ease XML’s way to full compliance. Although many SGML books remain high-level textbooks, costing $50 and up, SGML knowledge has filtered down to a broader base, including several trade computer books. SGML consultants who know the document management side of the product can offer their services to companies in need of a makeover. It remains to be seen whether the significantly different SGML and HTML communities can work together at this intersection, but the expertise is available. |
| Previous | Table of Contents | Next |