Would you like fries with that Standard ?

/Would you like fries with that Standard ?

Would you like fries with that Standard ?

Would you like fries with that Standard ?
Ash on 19 June 1998

1. Standards
Standards have got a bad rap with jokes like: The nice thing about standards is that there are so many of them. Then, there is an issue of Open standards, market-defined standards and coffee standards. On a serious note, Standards are blamed for slowing down innovation. This is the time to have a standard for setting Standards.

For example, If I want to design the next generation Holodeck. The Holodeck should accept smart cards, download content from a remote server, access a profile database, talk to another Holodeck, etc. Let’s say the Holodeck want to access data. Let’s use OLEDB, but then a Java holodeck character cannot access it. Using JDBC will prevent COM holodeck characters from accessing the data. If my character uses an Intention based language then tough luck.

2. The Problem
The main problem with setting standards seems to be that designers think it is OK to tightly couple one standard to another. For example, OLEDB depends on COM and JDBC depends on Java. This is bad design. Beside Java and COM, many environments, existing and future require access to data. Why on earth should my fancy new holodeck be tied to COM, Java or CORBA?

Don’t get me wrong, A standard for data access is a good thing. Much better than if every application did it their own way. Tying standards together is the main problem. It is what slows innovation down and it is the real problem.

3. How would de-coupling help ?
Splitting the Data Access standard into two parts: The actual standard and the corresponding Language IDLs. This allows my holodeck designer to plug his Intention based IDL into the Data Access standard. Talk about reuse!   talk   4. Would this model work ?
This model does work. It works in over 100 million computers and is known as web, which uses HTTP, HTML, etc. The best think out HTML and HTTP is that the are not coupled together.  You can use HTTP to get XML, Images, or any other files you want. As a matter of fact, using CGI you can send anything back. HTML does not depend on HTTP. You can send HTML via Email, use it for local files or for your desktop display. Two simple standards, when used together prove that combinations are better than the sum of their parts.

5. That a bad analogy. HTML and HTTP do different things.
Ok, Let’s take the HTML DOM definition. Every web page needs a JavaScript standard, right? That the number one compliant of web designers. Thankfully, the W3C designers are smart. It would have been easy to say “Let’s settle this JavaScript compatibility problem by adding it to HTML4″. Yes it would have solved the problem, and people would have ONE Dynamic HTML standard.

But the W3C designers realized that would be a bad standard. They instead created a DOM group to create a Document Object Model standard. DOM is the good standard.

DOM is document, language, platform, etc. independent. DOM is not linked to HTML. It can be used with XML, CSS and other document formats. DOM is not tied to JavaScript; you can access it using Java, VBScript, COM, Perl, C++, etc. It is not platform dependent. You can use on Windows, Mac, WebTV, etc. In short, DOM is a standard that actually does only what it is supposed to do. Nothing else!

6. How does DOM support multiple languages?
IDL or Interface Definition Language. Each Language defines its IDL to talk to the DOM. To use JavaScript in a document, the browser or application needs to support a JavaScript IDL to talk with the DOM.      7. Isn’t it better to support only a COM IDL? All languages can then use it. Isn’t it better to support only a Java IDL? All platforms can then use it.
That’s what ActiveX scripting does for scripting languages on COM enabled machines and some version of Java will support the DOM. But, why should the designer of the Holodeck be tied to COM or Java technologies. Or why should pager designer have to add COM or Java to his brew to taste the DOM. Defining a standard tied to Java/COM/JavaScript is a ticket to nowhere. Of course, due to current hardware/software, Java and COM compliant software will succeed, as they should. But that does not mean standards should hold back innovation in new technologies.

8. The WDM driver
Operating Systems like OS/2, Linux and Windows NT 3.1/3.5 did not succeed in the PC market, not because of Microsoft’s monopoly or because everyone likes a common OS. One of the main reasons was device support was limited. Device Vendors don’t like to write device drivers for multiple versions of windows, let alone for other operating systems. Windows Device Model (WDM) is an epiphany that occurred to Microsoft. Implemented under Windows 98 as a VxD, it allows a common device driver to be used Win98 and WinNT5. WDM is a really good thing, but it is a short-term fix like solving the JavaScript compatibility problem. A better solution would be a Common Device Model, which would be platform, OS and language independent. Devices are something all operating systems must handle and it high time, the industry came up with a standard way of doing things.

9. The Java API of the month
Java shows great promise as a cross-platform language that can glue diverse systems together. Its VM allows the same byte code to be executed across different platforms, without re-compiling. The problem with Java is that Sun is trying to make it do multiple things. Java Card, JDBC, Java Media, Jsomething, etc. All of them tied to Java. We need open standards, but we don’t need to tie them to one language. What Sun needs to do is to define the Java IDL to a particular open standard. If none exist, then work with the related industry group and define it.

10. Why Microsoft, Sun and others will have to do this
The most popular application on the PC is the browser. The main reason behind this is that it supports true standards, which are not inter-dependent to each other. That way a consistent cross platform implementation can be achieved. Browsers would never become popular if they had to be written only in Java or has to use the Windows API. In fact, the first browser was written on the Next platform using Objective-C. Internet protocols for Email are popular for the same reason. If scheduling protocols were open, we would see a lot more people using online calendars. More people means more revenue for companies. Support for HTML/XML in Word 9.0 will be worth its upgrade price. It is a serious problem for a $200 billion company, if only a minuscule percentage of users upgrade.

11. How does this concern me anyway? I don’t write shrink-wrapped software?
One of the complexities of client-server projects was that business logic and the remote plumbing, was tied together in one standard. This was one of the reasons for failure. One reason for Perl CGI scripts became so popular was that the web server CGI mechanism handled the remote plumbing and the business logic was handled in the Perl scripts. Just separating the two earlier coupled standard into different standards, made web client server a lot simpler and the success rates for projects went up significantly.

12. Conclusion
In the next few years, millions of new devices will come in the market. They need to communicate with each other and the old PCs. Microsoft, Sun and others cannot depend on COM or Java to solve this problem. We need true standards, which are not tied to other standards. Forcing Java or Windows into every Holodeck does not make sense. It makes no sense to make stereos, digital TVs, microwave ovens to talk Java, Windows, XML, etc. No microwave oven vendor is going to support both OLE-DB and JDBC to talk to a user profile database. It is a matter of common sense.

13. Links
The W3C is the organization that sets the Web standards. Microsoft, Intel and Compaq came out with the Virtual Interface (VI) Architecture, which is OS and processor independent. XML vocabularies are a great way to have true standards.

By | 2017-02-05T18:45:54+00:00 August 30th, 2012|Software|47 Comments

About the Author:

Comments are closed.