Document Object Model

for RuBoard

Thus far we've explored XML from the standpoint of generalizing document formats. But XML's real power comes into play when it is used to structure information.

All XML documents consist of nested sets of elements. Every document is wrapped in a root element, which in turn houses other elements. The structure is a natural treea tree of elements, objects that represent the content of the document. The DOM goes beyond the simple text stream approach and provides a language-neutral means of working with an XML document as a tree of objects.

This object-oriented access to XML documents opens the door to a whole host of other uses for XML. It makes it trivial to incorporate XML as an interprocess or interapplication data interchange mechanism because all you deal with are objects in your programming language of choice. It doesn't matter whether that language is Visual Basic, Java, or C#, you can read, manipulate, and generally process XML documents by calling methods on objects and accessing their properties.

Think of all the possibilities this brings with it. For example, imagine a database system in which the entire database was represented as an XML document. Need a schema of the database? No problem. Extract the XML schema from the DOM and run it through an XSLT transformation and you've got yourself a " browsable " database schema that's always current. Want to write a unified tool that can administer objects on SQL Server, Oracle, DB2, and all the other big players in the DBMS space without having to code to each of the administrative APIs separately? Have them expose their database schemas as DOM trees, and you should be able to build a single tool that works with all of them.

Already, vendors are putting DOM and XML to use in scenarios like the ones I've just described. SQL Server has certainly done its fair share of this, as we'll discuss in the next few chapters.

for RuBoard