Report from XML World in Ottawa

September 22, 1999

David Sims

Microsoft's XML evangelist, Dave Turner, was preaching to the converted when he told the crowd at Interdoc's XML World last week, "the investment made by major companies in XML ensures that this is real, and that it will become a major part of how we build our systems."

The 350 people who came to Ottawa's Chateau Laurier for four days of tutorials and sessions already knew that. What was on many of their minds was how to build the systems, and what they should include.

If there was a theme, it was probably that XML was the tool to take the web from a presentation platform to a system of services. Most of these services will center around e-commerce, and many are in the same space that EDI occupies (though many are not). Hot discussions included how to gather effective repositories and whose schemas should be adopted. Occasionally, one could spot the EDI veterans rolling their eyes or shaking their heads in the back of their room, as if they had heard many of these promises before.

David Megginson, a consultant and chair of the W3C's XML Information Set Working Group, gave a helpful overview of the progress of various XML standards working their way through the W3C. Then, as he noted later, he had to spend the rest of that session watching the subsequent speakers tear the standards process apart.

David Webber, who helped start the XML-EDI working group, called e-business applications the "killer app for XML" and accused the W3C of losing its focus. Webber said that elements to enhance XML for business -- better linking, data types, enveloping or packaging -- need to be addressed first, to ensure XML's success. Further refinements, he suggested, should come later. "We need xlinks and xpointers to facilitate EDI-type transactions. I don't care as much about bidirectional pointers."

Keynote speaker Dave Thomas, founder of Object Technology International, gave an informative overview and history of knowledge management in corporations, then drew upon some proven techniques that still work within an XML-based paradigm, including:

  • reward sharing, discourage hoarding (administratively or, more effectively, through the corporate culture),
  • adopt tools and practices that already incorporate your best practices, rather than trying to invent new best practices that match available tools,
  • use decision trees and tables, powerful tools that are often ignored in computer science because they're not sexy, and
  • give away your nonessential knowledge to others ("It may be the cheapest way to maintain it.").

XML graphics

Chris Lilly, who chairs the W3C's working group on XML and graphics, took us through a tour of scalable vector graphics, the XML-based graphic format which includes features that make it a better format for some web applications. SVG is currently a proposed Recommendation at the W3C in a Last Call for member votes.

  • Its vector format makes it easier to zoom in on details without a loss in quality, and since many graphic applications create images in vector, they don't have to be converted to a raster format like GIFs or JPEGs.
  • Since graphics are described in text, simple graphical edits can be achieved using any text editor. (Changing the lettering across a flow chart, for example. Or changing the chart graphics from rectangles to ovals, or adding arrows to the right side of all the lines, or changing the arrow style - these are the kinds of changes that could be made by hand).
  • Text within graphics would be easier to search and catalog, unlike text in GIFs, for example, which relies on the page designer including ALT text in order for it to be searchable.

One type of application that could benefit from this format would be schematics that often rely on multiple instances of a single graphic -- a spoke graphic within a schematic of a bicycle, for example. Such a schematic could be viewed as a hierarchy of graphics, and editing any one graphic would affect every instance of its appearance in the complete graphic, similar to style sheets.

So graphics represented in XML not only enable interoperability among graphics programs but the SVG format also provides a unified solution for printable graphics that are also light-weight and viewable within a web page.

Under the Hood

But, just as many designers who export their graphics to the SVG format won't know all the capabilities under the hood, it seemed clear that many people creating XML documents would not need to know XML to create them.

Derek Burney, Corel's EVP of Engineering, said that for XML to succeed on the scale that HTML has, it will have to work below the level where most people work, and be as easy for nontechnical authors to use as HTML is today. The simplicity of HTML made it instantly popular among a technical audience. But it wasn't until the widespread growth of HTML editors (beginning in 1995) that web publishing exploded among a larger, mainstream consumer and business audience. Corel's interest, he explained, lies in making sure the output from its word processing (WordPerfect) and graphics (CorelDraw) applications flow seamlessly into the exploding array of display devices. "The future's going to have all kinds of smart machines, and you're not going to want to reformat the data for each of those." Burney included cell phones, PDAs and the often-referenced-though-rarely-seen toaster with a browser.

SoftQuad president and CEO Roberto Drassinower sees this opportunity clearly, as he pointed out in a session that promoted XMetaL, one of the first XML authoring tools. Even so, it seems that any XML authoring tool will need to better integrate into existing content management systems before it is truly successful. Unlike HTML authors, who may be posting flat pages, it seems unlikely that most XML pages will be static, but rather they will be part of dynamically generated systems.

The Skeptics' Table

I sat at the Skeptics table at lunch before the final presentation, and this issue of hiding complexity came up as a necessary component of XML's success. The economics of most jobs don't afford workers the time to learn XML any more than they allow them to become programmers. They rely on IT departments for support, and will continue to do so in an XML-based environment.

Another big criticism was that the politics (among companies and standards bodies) delaying XML were among the most likely culprits to doom it. Another possible enemy of XML was the drive to make it increasingly complex. Several speakers had noted that part of what would make XML successful was its simplicity, shortly before diving into presentations about extensions that would make the language more complex and less easy to work with.

Some of us agreed that the space where XML has the best chance of succeeding was in the EDI space, primarily because it's a niche where the infrastructure to support that level of complexity already exists. To put it another way, it's already in the job description to deal with many of the problems that XML attempts to solve. XML becomes just another tool to work with -- and one which ERP vendors are adding to their systems in hopes of gaining some competitive advantage.

David Sims is editorial director of Songline Studios in Sebastopol, Calif.