The Explosion of Schemes

Team Fly

Page 481

As you probably guessed, the extensibility of XML is a two-edged sword. Allowing everyone to create their own tag vocabulary (element and attribute names) and data structures has resulted in many thousands of unique, proprietary XML vocabularies.

In the early 80s, an intriguing language named Forth fascinated many programmers. It permitted a crude form of inheritance and polymorphism.

Using Forth was similar to Lego and transformer toys where a robot can be changed into a truck, and a truck can be built up until it becomes a city. Essentially, the Forth language was open and protean: You took the core language and modified it until it transformed into an application. Each Forth application was merely the core language itself, but renovated and expanded until it became functional, specialized, and unique.

The problem was that each application contained many unique statements that only the programmer could understand (if even he or she could figure it out after a few weeks passed). Also, programmers tended to quickly customize the language in other ways, creating their own personal (and incompatible) version of string manipulation, data shorthand, and other language components.

Linux aficionados call this effect forking. By this they mean that an IT department can lose control of a Linux-based project because it's all too easy to create forks in the code base. Precisely because the central source code is open to anyone's fiddling, the fundamental core (code base) of Linux can divide into incompatible code bases which cannot ever be reconciled.

This effect is not accidental or rare. Forking becomes a tree of forks rather rapidly. Indeed, forking always seems to happen to languages such as Forth, and operating systems such as BSD (now we have multiple forks: NetBSD, FreeBSD, OpenBSD and so on). XML (supposedly standardized) itself is forking rapidly into incompatible versions for bankers, bakers, and candlestick makers. Efforts are made to enforce conformity on extensible languages (there are XML standards committees; Linus Torvald's and Alan Cox's attempt to act as a central authority for adding and accessing the Linux kernel, and so on). Nonetheless, these efforts at keeping open source languages and platforms closed are oxymoronic. They have always failed in the past. Despite heavy breathing on the part of the techie crowd, and quite a bit of positive publicity in the press, Forth rapidly disappeared.

Every organization left to build its own set of XML structures and tags generates a new XML language, unique to itself. All these new languages share the XML punctuation and syntax rules (in effect, they share the XML interface), but the actual vocabulary is special to each implementation.

How you navigate unique XML structures, what the tags mean, the hierarchy, the relationships, the diction—all this can differ among the many thousands of versions of XML schema currently being invented by disparate organizations.

Microsoft, and others, have proposed sets of rules, schemata. One such initiative is Microsoft's biztalk, a site that attempts to gather information about XML, XSL and other data models used by all those thousands of organizations. See www.biztalk.org for further details.

Now let's turn our attention to XSD, Microsoft's choice for the building blocks for schemas. As you'll see, XSD is uniquely suited to representing data sets, and to translating database tables into XML and vice versa.

Understanding XSD

Visual Studio.NET focuses on XSD rather than DTD or other alternatives. So we'll take a brief look at what you can do with XSD.

Team Fly