Continue 
Back 
PCLT During the late 1960's, mainframe computers were already being used to format printed documents. The first tools developed for this purpose allowed the author to embed commands in the text to "center the next line" or "underscore the next phrase." However, when the same document had to be printed on a different device, or was resubmitted to a different publication with different format rules, then going back to change all these commands was difficult.
An IBM researcher developed the next idea, a Generalized Markup Language (GML). The idea was to add commands that identified the use of each section of text, but not how it was formatted. The source would be divided into chapters, sections, and subsections. There would be ordinary paragraphs, examples, figures, and footnotes. If "The Lord of the Rings" was marked as a reference to a book, then it would be printed in Italics on devices that supported multiple fonts, and underlined on devices that did not have that capability.
The idea of Markup Languages was examined by international standards groups. They came up with Standardized GML or SGML. An international standard had to support markup in any foreign language. There are also different document structures to a novel, a legal brief, and a Help file. So SGML did not describe a single markup language, but rather an extensible family. All shared a common base structure and could be processed by a single tool. Different members of the family would handle different types of content with different requirements. The Web today is based on HTML, a member of the larger SGML family.
The most instructive early use of SGML was IBM's Dialog Tag Language (DTL). Developed during 1989 as part of the larger SAA project, DTL was, at least for applications, a more powerful version of HTML. Input fields, for example, could be associated in DTL with hint text, a help panel, and input validation rules. Options could be enabled or disabled, and selecting a value in one field could change the defaults or possible options of another field.
However, DTL could not provide general event handling or participate in drag-and-drop operations. From what we know today about modern Web development, we realize that IBM was missing Java (or at least JavaScript or Visual Basic Script). Without some type of Object Oriented scripting environment to supplement the static definition of input fields, any user interface is limited. IBM could not find the missing ingredient, and rather than appreciate what it did have, IBM killed DTL and, implictly, SAA. If it had stuck it out, IBM would have had a five year lead on everyone else in World Wide Web technology.
The widespread use of word processors eliminated the need for markup languages. They might have died off entirely, had HTML not achieved such a phenomenal success.
The first word processors handled simple text documents, with perhaps a few inserted pictures. Spreadsheet programs calculated numbers, but they could also generate charts. Databases held large quantities of data. Users could manually move information from one program to the next using Cut and Paste. So it became common to run a database query, paste the results of the query into a spreadsheet, then paste the chart generated by the spreadsheet into a Word document. Office Automation allows such sequences to occur automatically.
Visual Basic was originally designed to be a simple programming language for the Windows. Purists may argue whether it is really "object oriented", but the VB programmer works in an environment of Objects that represent elements of the user interface: Window objects, Checkbox objects, Button objects, Menu objects, and so on. Each object has properties (values that can be retrieved or set), methods (functions that can be called), and events (where a VB function is called when the user interacts with the object).
In most programming, there is an application program acting as the client calling some system or database service. However, when Word, Excel, and Access interact, they often take turns acting as the client and the server. It is now generally accepted that this type of programming is easier if it is organized around Objects, Methods, and Events. For example, Microsoft examined Excel and created a system of objects. Excel itself is an Application Object. It loads files that are Workbook Objects. Each Workbook has spreadsheet and chart Objects. The spreadsheet has cell Objects. Word can act as the client and extract a chart to add it to a document, or it can act as server providing a report generation function for some Excel application.
To allow different programs to exchange requests and data in an Object Oriented framework, Microsoft created OLE. OLE provides a common binary level standard that operates between programs, even when they are written by different vendors, potentially in different languages. To allow Windows users to reuse their existing skills to create new applications, Microsoft extended this OLE linkage to Visual Basic.
Natively Visual Basic has things like Menu Objects and Button Objects. When connected to Excel, Visual Basic also has Workbook objects and Cell Objects. The Excel Objects look the same and work the same as native VB elements. A VB program can tell Excel to load an XLS file, plug some numbers into selected cells, recalculate the spreadsheet, and pick up the results.
Word handles compound documents containing formatted text and embedded pictures. So does a Web Browser. Excel, Access, and Visual Basic can provide basic data entry panels in which the user types a few numbers to trigger a query or a calculation. So, with HTML forms, does a Web Browser. Just as Microsoft Office needed an automation language, and chose Visual Basic, so Netscape realized that the Web needed some light weight automation language, and chose JavaScript. What is the difference? JavaScript statements all end in a semicolon, while VB statements don't (there are a few more differences, but they are even less important).
Netscape also looked at the way that Microsoft created Objects for its Office applications, and decided to do the same thing with its Browser. Navigator creates one or more Window Objects. Each Window has one or more Frame Objects. Each Frame has a Document Object. Each Document may have one or more Form Objects. Each Form has the usual Input, Checkbox, and Button objects. All these Web Document objects appear as native JavaScript Objects, with Methods and Events that are nearly identical to the corresponding Visual Basic elements in Office.
It is extremely dangerous to copy Microsoft. If the software giant becomes interested in what you are doing, you have given it a blueprint for its product. That happened early in 1996 when Microsoft suddenly became very interested in Internet and the Web. It simply accepted the collection of Objects designed originally by Netscape. Of course, Microsoft made them OLE objects so they would integrate with the existing Excel, Access, and Word objects. Internet Explorer Web Browser became, essentially, just another element of the Office suite. An Excel spreadsheet could contain a URL to launch a Web document, and the Web Document could contain data that was fed back to the spreadsheet for recalculation. Automation could be programmed in Visual Basic, Delphi, Perl, Rexx, or any other OLE enabled language. Since it had a standard to connect the Web to external programs, Microsoft also proposed a technique to embed what it called "ActiveX" objects in a Web document. ActiveX looks like a Java applet, but it can be coded in another language and can use the support of other Microsoft tools.
Despite the bitter debate, Microsoft and Netscape have largely agreed on a common application development framework. Netscape is committed to open standards and cross-platform development. Microsoft is committed to integrate new technologies as extensions of its existing desktop environment. So they end up doing the same thing for different reasons, and argue about motives.
Copyright 1996 PC Lube and Tune -- Distributed Applications and the Web H. Gilbert