[Archive copy mirrored from the URL: http://www.mcs.net/~dken/xml97.htm; see this canonical version of the document.]

XML Conference 1997
by Dianne Kennedy, SGML Resource Center


(Return to Index)

On March 10, 1997, a small yet impressive band of leading-edge SGML/Web practitioners gathered in San Diego to convene the first XML Conference. As conference chair, Tim Bray of Textuality quipped this conference is introducing either an "Edsel" or "Something really BIG!" The conference began with a half day tutorial by Tim Bray (co-editor of the new XML standard) titled "What is XML? A Top to Bottom Tutorial" The tutorial was designed to bring newcomers up to speed on XML and served as the foundation for the remainder of the conference. For those of you that are new to XML, you can understand it one of three ways:

The afternoon featured presentations were made by vendors currently implementing XML or considering XML implementations. These included Jim Sterkin, President and CEO of ArborText, Bruce Sharp, VP of Product Development of SoftQuad, and Jean Paoli from the Explorer team of MicroSoft. While the SGML vendors presented the expected "XML is a good thing message", the audience most eagerly awaited the Microsoft view / position on XML adoption and implementation. As expected Microsoft was clearly pragmatic and business oriented. Mr. Paoli presented Microsoft's observations and hints as to their future direction.

While many of us may be interested in having a content rich language for the Web or in having the ability to extend HTML for our own purposes, Microsoft shared a vision of "Client-Centered Computing for the Web To quote Jean Paoli, "It's cool, whats happening here!" The reason why Mr. Paoli, of the Microsoft Explorer team believes XML may be cool, is because Microsoft believes that XML may be the Web language that will enable client-centered computing. The Web today is just too slow. Transmission is slow; servers are slow, interactivity is slow, there are too many hits and transactions between client and server; its just too slow. In order to solve this problem something must change. And while a portion of that change may be in the hardware and software, nothing will fundamentally change unless the data changes. What is required is the ability to deliver more content-rich data to the client so that processing can occur on the client side, thus speeding the entire system. Content rich data, with appropriate processes on the desktop means that styles can be dynamically constructed, and objects can be dynamically combined on the fly at the client side without continual "reload" from a server. XML can give Java and new client-side software something to do. HTML provides us data in a document metaphor in a pre-defined user interface framework. We want to be able to incorporate document fragments into a dynamic user interface. SGML could do this, but it is just too hard. XML may be the solution. Microsoft does not want to be in the XML authoring business. Rather it is interested in the client side XML computing environment. Microsoft is currently making the business case for XML within Explorer 5.0. It is trying to find real publishers and corporations/organizations that need something more than HTML. It must understand if users will adopt XML? And what will XML enable them to do. We can help establish that business case by sending our corporate information and Web requirements for XML to Jean Paoli at jeanpa@microsoft.com. Before the end of April.

Real-Life Applications

Novell

The second day of the XML conference focused upon real life applications for SGML and plans for XML. The session began with Jared Sorenson from Novell. He explained that Novell was an SGML pioneer due to its status as an ISO standard, its extensibility, and the desire of Novell to work cross-platform and in a vendor independent environment. SGML was also ideal because it could support the database and multilingual support. SGML also offered on-line viewing across platforms. In addition, Novell had plans to publish in many formats and media from a single data source. And finally SGML enabled better data search and retrieval at a lower cost. Novell utilized DocBook DTD, an industry standard but failed to develop a data model. This, according to Sorenson was a grave mistake. In 1993 Novell began to experiment with SGML. They found that while customers claimed to want books rather than electronic books, very few were willing to pay for books. They also learned that automated SGML translation is not as easy as vendors want us to believe. In fact, even today Novell is not entirely happy with their SGML translation solution. In 1994, Novell realized 8 million dollars in production due to their ability to shift documentation to electronic rather than print products. This was the first year that Novell provided documentation on the Web using DynaWeb. Novell found that customers really like having documents on the Web and have 160,000 in 6 languages on the Web today. But all was not rosy. Publishing groups wanted SGML their way. So over time, the SGML was not "standard" and conversions were required to support a standardized SGML definition. There was tremendous backlash over the use SGML and the difficulties that writers had authoring in SGML. In the meanwhile with the rise of the Web, authors began to wonder if SGML was overkill. Wouldn't HTML do just as well? Problems with SGML include:

  • It just takes too long. We need to ship products

    In 1996 the "Web rules". Intel became the "Intranet Company". Web browsers became the preferred alternative to IntraNet delivery. HTML is a sleek sports car. SGML is a flat bed truck! HTML is great for home pages and advertising. But if you are carrying a heavy load (like documentation) you need the truck!

    In 1997, Novell is still doing SGML and there is still opposition. Novell has the need to bridge the gap between HTML and SGML. Perhaps XML can bridge that gap. The questions remain. Can XML really simplify authoring? Can authoring without a DTD facilitate the authoring process. Will XML facilitate translation? Novell needs this. But adoption of XML will be highly tools related. If tools are ready quickly XML will be adopted. If not, other alternatives will emerge to fit customer requirements.

    Sun Microsystems

    Todd Freter from Sun described "AnswerBook" as an application waiting for XML. Originally AnswerBook was authored in Frame and TROFF. With the success of Novell and other Web documentation, it became clear that Sun needed a new publishing paradigm. Sun wants standard, open-systems based publishing, they want to publish from a single data source as well as content managing, and they wanted to provide fast search and retrieval either on-line or on the Web. SGML was clearly the only option to provide all benefits Sun wished to gain from a new system. But at the same time this decision was made, the Web exploded and HTML was quickly turned to as the best delivery medium. Of course this requires a down translation of SGML into HTML. But in doing this, much of the value of SGML to guide search is lost. And to complicate matters, some writing groups began to author directly in HTML. So Sun took 2 actions. First it developed the concept of structured HTML which requires a hierarchy to guide authoring and retrieval. Also Sun became highly involved in the develop of a new delivery language—XML. Mr. Freter believes that XML will fit the 80/20 rule. In that authoring in XML will give 80% of the benefit of SGML with only 20% of the effort. This statement raised controversy with the listening audience and only implementation and use of XML authoring systems will prove Mr. Freter's point.

    Omnimark Technologies

    Eric Skinner provided a case study about the way Omnimark produces its documentation through simpler documents and 30-year old approaches. Personalization is gradually creeping into the documentation process. This means that each user of the documentation will receive a personal view of the documentation based upon background, requirements, etc. Omnimark began its journey by recognizing that installation steps are much too complex. The existing documentation covered all cases, where the user should really walk a decision tree before the installation process in order to present a tailored view (much simpler and to the point). In studying this, Omnimark found that there are over 600 different pathways to the final installation steps. To provide a new kind of documentation, Omnimark needed to re-think the documentation process. Documentation must begin with the creation of "microdocuments" to be integrated with a custom assembly process. Much of the work in this model is done by the database. For its documentation, Omnimark designed microdocuments which contained 10 elements or less. These elements are delivered by HTML, PDF, or plain text. To install the software, the user is walked through the install decision tree. At the end of the user decisions, the personalized install procedures are compiled from the microdocuments and presented to the user. Each set of completed user documentation is a "virtual document" existing temporarily to guide the user in the installation process. Omnimark believes that this model will be the documentation model of the future. Omnimark is in the process of determining how/if XML can help. Since the microdocuments are so simple, XML would clearly suffice for authoring. But the real issue for Omnimark is whether some benefit can be gained by using XML for delivery.

    The Business Case for XML

    Eric Severson of IBM Global Services presented his vision of the Business Case for XML and SGML on the Web. Eric began by highlighting the types of data that make up the majority of Web publishing; technical documentation, human resources information, marketing communications, corporate libraries, project management documents and other mission critical data. Documents are being put into more structured repositories; sometimes SGML and sometimes structured document management systems. The browser is looked upon as the universal interface to the information. Whatever the browser, today the data that is passed to the client application is typically HTML. The question becomes not one of viewing or even browsing (which can be enabled by the document management systems) but rather one of what packets of information are passed between server and client. Making the business case is always unique. Usually leapfrogging the competition is not enough to create a business case. Rather decreasing costs and increasing value to customer comes into play. Facilitating searches and client use of data is becoming more and more critical to profitability. What about putting structure (XML/SGML) on the Web? Eric believes that both coding schemes apply database concepts to text and focus on content rather than presentation. But in addition, structure provides anchor points for further processing on the client side. If this is the case, a consumer can gather structured data from the Intranet and process it without today's ongoing client/server bottlenecks. The consumer can then create its own processes to gain personalized value from the data. For example, a consumer can take financial data from the Intranet, create its own analysis processes and derive custom benefit. One could go to look at suppliers part data, link that to the purchasing database and immediately assist with purchasing decisions. Or we could link maintenance data with the inventory control database so that we could determine if we have the part to complete the maintenance task or whether an order could be initiated.

    So XML is not just about search but about intelligent end-use of the data by the data consumer. XML data will provide business advantage over HTML data, even both may be rendered the same way. We need to look at how each fits the business requirement of the publisher. XML has the flexibility to support more complex corporate applications. HTML was not meant to provide further use of the data. Rather it was met for linking and display. XML is designed to provide further use of the data and eliminate the bottlenecks which arise when end users try to process over the client/server connection rather than on the client side. Once served in HTML, enrichment cannot be added without human intervention. Java can help, but nothing short of serving structure over the Web can give the end user functionality that will fulfill the business potential of the Web.

    Peter Lamb from Anderson Consulting keyed in on the Business Case for XML. He began with his view of the state of the market. Peter began with the troubling statistics that show that this was a bad year for SGML. Profits and sales are down; so what is happening? Management is stuck evaluating who the "clear winner" will be in the technology wars. They are hesitant to spend dollars when the "clear winner" has not emerged. He further states that there will be no clear standard in the next 3-5 years. Strategies that assume a single business model or technology will fail. Other paradigm shifts that will affect buying decisions will be:

    Peter also predicts that business models, process change and service relationships will be the gating factors much more so than technology and core products in the future:

    Peter sees database enabled web sites as the trend of the future. In surveying 25 Web publishers he found business on the Web to fall into 7 areas:

  • Sell business to business integration (being the middle man for business communication)

    So, how can XML battle its way through and become the "clear winner"? Since HTML is a competing solution with market advantage, XML must make a difference in process and product improvement . Secondly, XML tools must be in place quickly. XML must be able to solve critical business problems that cannot be easily solved in another way. And the business requirement widespread and convincing.

    Questions our community must ask:

    Following Peter Lamb, Wes Hair from INSO shared his views about the place of XML and SGML on the Web. Re-inforcing earlier speakers, Wes stressed that we are determining not just display but end-user functionality of data at the client side. Liora Alchuler, representing Seybold Publications completed the program by sharing her vision, not only for Web data delivery but products to support the promise of the Web. Ms. Alschuler strongly believes that the key will be not just the availability of SGML/XML data on the web, but the richness of that data which is determined by the support of SGML/XML authoring tools. She challenged vendors to shift focus from delivery to enabling the authoring process. For after all, without truly rich content, delivery of SGML or XML is of little value to the end consumer.

    And in Conclusion. . .

    Closing presentations were made by Robert McHenry of Encyclopaedia Britiannacia and Dr. Charles Goldfarb. McHenry stressed the paradigm shift from document to information base that is happening in today's publishing arena. And Dr. Goldfarb stressed that whether SGML or XML the identification of content and the separation of content are critical to the future of the Web. "Style is the dress of thought" said Dr. Goldfarb. Lets not bind our data to one dress which will make it become out of date unnecessairly.
    (Return to XML TOC)
    (Return to Home Page)