A Look at XML
XML provides a standard way for information providers to add custom markup to information-rich documents, so that complex documents can be rendered (and published) in a dynamic way. Compare this with HTML: although HTML is easy to use, its simplicity significantly constrains how publishers and users can represent and use documents and databases. XML provides the means to publish and receive any information, regardless of format or origin, in any way desired.
With XML, users will be able to manage documents dynamically in a Web browser, allowing the presentation of personalized Web-based information. Content providers will be able to distribute structured databases that users can manipulate at will, due to several features XML (like SGML) provides that are not available in HTML:
- Extensibility: Authors can define new tag names and attribute names for documents by specifying their syntax and semantics.
- Structure: Documents can be containers for other documents, with arbitrary nesting. This allows complex documents to be constructed from simpler documents.
- Validation: If desired, any XML document can contain a description of its grammar so applications can validate that the document conforms to its specified structure. Furthermore, this process of validation can be automated.
The working draft for XML 1.0 provides a complete specification. From this specification, we observe that expressive power, teachability, and ease of implementation, were all major design considerations. And although XML is not backward-compatible with existing HTML documents, we note that documents that are HTML 3.2-compliant can easily be converted to XML, as can documents conforming to ISO 8879 (SGML) and documents generated from databases.
As far as XML acceptance is concerned, Microsoft has embraced XML for future releases of its Internet Explorer, and Netscape is considering doing the same for its browser. XML will most likely gain widespread acceptance once the power of XML-enabled applications is realized. These driving applications will include:
- Applications that require a Web client to mediate between two or more heterogeneous databases.
- Applications that attempt to distribute a significant portion of the processing load from a Web server to a Web client.
- Applications that require a Web client to present different views of the same data to different users.
- Applications in which intelligent Web agents attempt to tailor information discovery to the needs of individual users.
Although scripts embedded in HTML documents may provide some solutions to these problems, XML does not commit authors to individual script languages, authoring tools, and delivery engines. Instead, XML offers an "open standards" solution that is vendor-independent, giving information providers greater control over their content and context.
We note that the current XML draft only addresses syntax, and consequently XML alone can at present only be used for interprocess communication and for the delivery of documents to specialized applications (or plug-ins) that have been configured to interpret a particular XML grammar. However, much more work on XML is on the way.
After writing "Webs of Archived Distributed Computations for Asynchronous Collaboration" for the Journal of Supercomputing with my coauthors in the Caltech Infospheres Project, my discussions with Rohit Khare led to my understanding that XML can provide useful mechanisms for archiving information, denoting machine-readable and person-readable description of document contents, automating services, and mechanizing persistent transactions.
After perusing Rubinsky and Maloney's SGML and the Web, my hunch is even stronger that XML is the ultimate persistence format, simply by tagging everything properly so it fits into the larger schema of the Web. I may decide to use this idea in conjunction with infospheres sessions or elsewhere in the infospheres framework for my PhD work here at Caltech.
As discussed with Mark Baker in an epiphany or maybe two on the dist-obj list, XML can also be used for automation and self-description. Instead of just having Java view objects, business components can negotiate with an XML container for presentation and data exchange. Since any XML document can contain a description of its grammar, applications can use this description to perform structural validation. Plus, XML includes the ability to define new tags so that XML documents can become self-describing containers (so I can tag the data "Adam" as the value of an attribute FIRSTNAME for the tag ). Can you see how this is quite similar to WIDL both in design philosophy and actual implementation?
In short, XML provides a mechanism for streaming self-defining data containers into a browser, from an object... all using a simple document model! Furthermore, this simple document model is useful both to users of the Web, and to users of CORBA-compliant objects... which begs the question, what IS the difference between an "object" and a "document"? Turns out, not a whole lot...
What is a document?
Although most people still do not realize it, both the "Objects" community and the "Web" community share the same vision, including a somewhat similar architecture: Web servers are document factories, and likewise, object-request brokers are object factories. This was the very premise of the joint W3C/OMG workshop on distributed objects and mobile code in 1996, for which we provided a position paper on infospheres. Our paper, like many other papers for that workshop, held the firm belief that objects and Web documents are two sides of the same coin.
Combine this observation with the fact that A DOCUMENT CAN BE ANYTHING -- any bag of bits on the client-side and/or server-side -- from
- a static bunch of text (without or with semantic markup given by XML), to
- image maps, to
- embeddable multimedia types, to
- a semantic and/or syntactic description of interfaces (see WIDL), to
- an object (in the Object community's sense -- see the OBJECT tag), to
- a script (in the scripting community's sense -- see the SCRIPT tag), to
- actual embeddable running executable code (from Java applets to Infospheres, and everything in between) running on the client and/or server side (actually, it's more than just code: it is code, state, and IDENTITY together in a nice package.. identity is probably the most important item that can be shipped...), to
- various container mechanisms for combining/composing other documents within a document (from Java Beans to Active X containers to Infosphere Djinns, and everything in between), to
- linking mechanisms tying a document to any other document,
and you really begin to see the possibilities. Add in a Protocol Extension Protocol for use with the next generation of the hypertext transport protocol HTTP, and Web peers can do content negotiation automatically, on the fly. To that, add an economic model such as kudos, and suddenly technologies like munchkins are feasible!
Let's go a little further in exploring documents and objects. A document is a bag of bits and an explanation of how those bits work. So is an object. A document can have a specified interface. So can an object. A document can have specified behavior for itself and/or its components. So can an object. A document can provide semantic clues to what it does. So can an object. A document can be distributed. So can an object. A document can encapsulate other documents. An object can encapsulate other objects. A document can inherit its type from another document, as can an object. Document types can be polymorhpic, as can object types.
A document can send a message to another document. A document can have a notion of an "active thread of control." A document can invoke a method on another document.