Browser services, as defined in this abstract model, are in my mind better suited to a less overgrown environment than Windows, an environment built on a set of standard set of shared and manipulable class libraries rather than a set of APIs. As Jon Bosak of Sun Microsystems has stated in his white paper XML, Java, and the Future of the Web (available at http://sunsite.unc.edu/pub/sun-info/standards/xml/why/xmlapps.htm), “XML gives Java something to do.” Java is already built on a standard set of class libraries, complete with network interfaces that already provide the functionality of the communications engine shown previously. The JavaBeans standard that arrived with Java Developer’s Kit 1.1 provides mechanisms for applications and applets to communicate, providing direct channels of communication between large numbers of objects.

Although not a JavaBean, Microsoft’s validating Java XML parser provides (ironically) an example of how easy it is to create parser components in Java and to make them accessible to other Java programs as well. All the parsing examples demonstrated so far have only called MSXML from the command line and accepted its output as text. Java applications can use MSXML as an all-purpose parser, reading elements through an object structure created by the parser. Despite its lack of interest in following Sun’s direction on Java, Microsoft has produced a parser that Java developers can use as the foundation of an XML toolkit. (As of October 1997, the source code is available and the licensing is not too restrictive.) Perhaps in a few years the Network Computers (NCs) proposed by Sun, Oracle, IBM, and others will still be running Microsoft code—but as a parser, not as an operating system.

XML and the Future of the Browser

The scenario portrayed here is only one of many possibilities for the browser. Centralized browser services may never come to pass because the XML standard is simple enough that the extra work of building (or just including) a parser isn’t that heavy. XML applications and HTML may well stay in their own compartments, occupying different parts of the programming world. HTML may continue to dominate the presentation side of the Web, whereas XML will provide infrastructure for data transfer services only.

Even though many HTML developers might prefer that XML stay in a separate world of Web services (if only to avoid yet another learning curve), it doesn’t seem likely. XML is a drastic change from the HTML model, but it remains close enough to seem familiar. HTML developers who have spent years trying to interpret the latest tags from Netscape and Microsoft can now focus on creating their own tag systems and accompanying style sheets without needing to be as tightly bound to a single set of rules. Client-server developers who have struggled with complex tools but haven’t been able to make the Web do what they need may see XML with the accompanying document object model as their best option. XML, style sheets, and Java all have their own sets of rules (of course), but the additional flexibility they allow should convince several different groups to converge on this new standard for data interchange. With any luck, the new standard in data interchange will drive changes in the tools we use to read, write, process, and share that data as well.