Page #96 (Chapter 14 - Whats Next?) | Visual Basic Developer[ap]s Guide to ASP and IIS

	Chapter 14 - What’s Next?
	Visual Basic Developers Guide to ASP and IIS
	A. Russell Jones


	What about XML?


	Speaking of XML, it's hard to describe how important this idea is or how far-reaching its effects will be. If you haven't run across XML technology yet, here it is in a nutshell:


	<person>

<phone>

</phone>

<phone>

</phone>

<name>Waldorf Place</name>

</street>

</address>

</person>


	You can read that file even if you've never seen XML before: John Doe has two telephone numbers and lives at 1535 Waldorf Place, New York, New York, 99284. XML, like HTML, contains both markup and content, but XML has a more consistent (and unfortunately, case-sensitive) syntax. Unlike HTML, each tag must have a terminating tag. Luckily, there are payoffs for the consistent syntax—speed and machine readability. Because XML has a consistent syntax, you can easily teach a computer to read XML files. The revolutionary idea here is that you have a data file where the structure of the data is part of the data file itself. XML files are called documents. Essentially, each XML document is a mini-database.


	Until now, data files and the structure of the data have been separate. Sure, you've seen text files that include field names, but like relational databases, they're rigid. If John Doe had four telephone numbers instead of two, you'd have to either include fields for all four for everyone (a waste of space) or you'd have to tell John that he could have only two phone numbers. As programmers, we've seen both approaches many times. With the XML file, you would simply add two more telephone numbers to John's entry, no problem. The parser would still parse the file correctly. Queries via the XML parser would return John's four telephone numbers without complaint.


	Now take this idea and apply it to programming. What is a programming language, after all, except a data file? Currently, languages produce syntactically specific data files—one or more types for each language. Consider VB. When you produce code, VB stores it in a text file. To the compiler, the text file contains only symbols and white space. The compiler parses the text file and expects to find specific symbols in a specific order. In the absence of other clues, the compiler treats all unrecognized symbols as variables unless Option Specific is in effect; then it treats all unrecognized symbols as errors. C++ and Java have a different syntax, produce different text (code) files, and have different compilers—but each language has nearly identical logical structures.


	If you had an XML compiler instead (and I'm sure someone, somewhere, is already working on this), programming languages as we know them would become obsolete quickly. Instead of a version-specific text file targeted to a specific compiler, you would have a version-resistant text file usable by any XML compiler. Effectively, XML can provide the universal programming language, and your programming environment wouldn't even have to change. You could write and edit in VB—and a different person could write and edit in Java. Both languages would churn out XML code in the background. The next day, you could switch code files and keep working—still in your preferred environment.


	This isn't a radical idea; it's a natural progression for all symbolic languages. Remember, it was only a few years ago that you couldn't transfer word processing files from one word processor to another. The lowest common denominator was the plain text file—but you lost all your formatting. With XML, the lowest common denominator is still a text file, but you get to keep all the formatting as well. Within the next few years, as programmers become comfortable with XML, proprietary file formats will begin to disappear. In the future, XML will become the common format for programming content, because it provides a competitive business advantage of storing code in a manner that won't become obsolete within a couple of years.


	Programming languages are more alike than they are different. If you remove the barrier of syntax, they become nearly identical. For example, pseudocode is the same regardless of the eventual target language. Thus, the XML code generated by a future IDE might look something like this:


	<object>

<classname>CUser</classname>

<phone>

</phone>

<phone>

</phone>

<name>Waldorf Place</name>

</street>

</address>

</public>

</properties>

<returntype>string</returntype>

getlastname + ", " + _

getfirstname

</return>

</concatenate>

</return>

</getname>

</public>

</methods>

</object>


	Does that look familiar? I believe you could translate that into any coding language. XML clearly illustrates the potential for a close relationship between objects, data, and code. Of course, you wouldn't write such code directly, just like you don't write .frm files, .dsr files, or Word files directly today—you use an editor. You'll work in a familiar or appropriate environment and the editor will create the XML output. The XML output is independent of the editor. Similarly, the specifics of translating the editor-generated XML files to machine code are independent of the code itself.


	Until recently, XML has been used primarily for business-to-business data transfers. Office 2000 and Internet Explorer 5 are about to change that. Internet Explorer 5 comes with an XML parser, so it intrinsically "understands" the structure of XML. If you load an XML file into Explorer 5, it displays the file as an expandable tree structure, much like the directory view in Windows Explorer.


	You've probably noticed that XML looks much like HTML. One difference is that XML is extensible, whereas HTML is fixed. You can add your own tags to XML, and they're just as valid as any other tags. XML doesn't contain any keyword tags. In addition, HTML is a layout language. It describes, very generally, how to display data. XML is a content language. It describes the meaning and function of the data, but not the layout. You can combine an XML document with an extensible stylesheet language (XSL) file to achieve fine control over display. The combination of the two is likely to replace HTML over the next few years.


	The installation program for Internet Explorer 5 installs Microsoft's XML parser (msxml.dll) as well—and the XML parser is a COM object. You can use it from VB immediately. The parser exposes properties and methods that you can use to walk the structure of an XML document and to query that document about its content. If you have worked with IE's document object model (DOM) at all, you'll be able to use the parser with very little study.


	You can instantiate an XML parser on the server, combine it with an XSL stylesheet, and deliver HTML to the client. That's similar to the concept behind IIS applications—the server does the work, so the applications are client independent. But you can also instantiate the XML parser on the client, via JScript or VBScript, and process XML files there. That means that you can send an XML document directly from the server, process it, and display the results by using client-side code. If you don't learn anything else this year, plan to learn XML.

Page #96 (Chapter 14 - Whats Next?)