Meta Content Framework

Like CDF, MCF uses XML to provide information about HTML documents. The Meta Content Framework began as Project X at Apple’s Advanced Technology Group and is now under development at Netscape. Project X provided a three-dimensional interface to the Web that allowed users to navigate through a site without having to stop at every page. By presenting the layers of links in a projection that users could move around in, Project X created a new way for users to navigate indices and other sets of links. A sample image from Apple’s Web site is shown in Figure 9.3; at one point the entire content of Yahoo was available in MCF.

Figure 9.3  An image from Project X, created using MCF information.

Netscape took Apple’s initial MCF development and moved it from its original file formats to XML. The current MCF model uses XML to create nodes of information describing pages and sites, which may include more nodes. These nodes can link across multiple files, creating a web of metadata that reflects the web of HTML underneath.

The Netscape MCF submission to the W3C is available at http://www.w3.org/TR/NOTE-MCF-XML.html. The original Apple Project X information, programs, and plug-in are available at http://www.atg. apple.com/technology/tech/projectx/.

Open Software Description Format

OSD has a more ambitious project: delivering software and software updates over the Internet, not just Web pages. Millions of programs have already been downloaded and installed via the Web, but OSD promises a much more complete solution. OSD can automatically download and install programs and packages in Java (the reasons behind Marimba’s involvement) and platform-specific code (driving Microsoft’s interest in the project.) OSD provides a set of information that can be used to install the same software on multiple platforms (and versions of those platforms), even when the code to be downloaded will change depending on the platform. OSD files can specify program dependencies, allowing Java programs to download their packages and Windows programs to download necessary DLLs and other files, for example. OSD significantly expands upon the current abilities of the OBJECT and APPLET tags, allowing Web documents to refer to much more complex program structures. OSD is designed to fit with CDF as well—channels that refer to OSD files can be used to update software automatically and regularly. (The security problems this project opens up, especially for platform-specific code, are obviously mammoth.)

The Open Software Description Format submission, including a complete DTD, is available at http://www.w3.org/TR/NOTE-OSD.html.

Web Interface Definition Language

WIDL provides a “service-based architecture over the document-based resources of the World Wide Web.” It provides key information about available Web services to client machines, allowing them to automate many Web-based processes. Programs that use WIDL can take advantage of Web services without running a browser. A shipping clerk who needs to track thousands of FedEx, UPS, and DHL packages can use WIDL to connect their list of tracking numbers to the tracking area of the FedEx Web site, for example. WIDL may not always provide the most efficient interface to services (e.g., FedEx offers other products that can track large numbers of packages without using their Web site), but WIDL makes it easy to connect clients to back-end systems through the Web interfaces that have spread rapidly over the last few years.

WIDL addresses one of the major deficiencies of our light switch DTD; it provides return values that indicate successful completion or provide error messages. These messages can be used to retry services when necessary or give up trying after a number of failures. (The messages need to be generated by a processing application, but WIDL provides a standard way of specifying how the application should deal with them.) Web services are notorious for working the second or third time rather than the first, which may be acceptable to a human user but could break an automated process trying to interpret bad data. It also provides a framework for “reading” HTML pages using their textual information, although the WIDL documents themselves will need to be repaired any time labels on the page are changed.

WIDL offers client-server developers a new tool for connecting and automating their systems, converting light-duty Web applications into more sophisticated interfaces for accessing data. To be effective, WIDL will need considerable API and tool development, which webMethods has promised for C, C++, Java, and Visual Basic. Even though some parts of WIDL may be made obsolete if XML comes into more general use (making it easier for programs to parse Web data without the use of a separate interface), WIDL promises easy access to HTML-based documents in a much shorter timeframe.

Futures

The W3C is actively working on the RDF, a model for metadata applications that could potentially support all the preceding XML applications, except perhaps for WIDL. RDF is an effort to move the W3C ahead of the curve on XML applications and build standards that interoperate more easily. For more information, visit http://www.w3.org/Metadata/RDF/.

XML’s popularity for data applications will depend heavily on how much use developers find for its combination of structure, flexibility, machine-readability, and human-readability. Unlike most documents in the previous chapters, these applications aren’t intended for direct consumption by human users. Readability is maintained to make documents easier to examine and debug, but few of the documents will ever see a style sheet or be presented directly to human readers. Even though XML does incur more overhead than traditional binary files, its verbosity and its emphasis on nested structures give programmers new tools for communications between computers and applications. As XML spreads, we may see more programs based on shared parser architectures, all using a common set of file formats for wildly different projects.