Microsoft and the move Toward Web Documents

I recently attended a seminar on enhancements in Office 2000. I found Microsoft's first steps into collaborative documents very intersting. In their applications, you have the option to save your document as 'HTML' (more accurately, MS-XML). While the base data is visible in just about any web browser, to see things as you would see them in the application, you need Internet Explorer 5.

What is more interesting is that if you have a server supporting Office Extensions, IE 5, and Office 2000 applications, you can actually manipulate and change these documents on the web site. Questions of proprietary locking and security aside, this is a major selling point for Office 2000, at least according to their marketing people. Presumably, Microsoft wants this trend to continue, and will continue enhancing this feature.

We (Open Source or Free Software proponents) talk about harnessing the power of the Internet with our software, but mostly to improve our software. Look at things from a business perspective. Suppose my job is to coordinate the integration of thirty different components into one widget at five different manufacturing plants across the globe. I could be dealing with at least half a dozen component providers and representatives from each manufacturing plant, along with logistics planners and marketing wizards to regulate the production line, not to mention engineers developing new products or testing the components. Assuming that I kept all of the data for each particular widget in a spreadsheet, much of my job would be spent entering and integrating data from each of the various locations and job functions into that spreadsheet, just so my equations would balance and we could meet production demand and reduce inventory costs.

Now suppose that each manufacturing center had access to specific areas of my document where they could update their inventories and integration capabilities. Each supplier could have access to fields where they could update their delivery numbers and schedules. Marketing might have the ability to update their forecasts. My job would suddenly be easier, because I would not have to integrate data from e-mails or cut and paste it from spreadsheets into my tool. Everyone would have access to the appropriate area of my particular document.

From a business standpoint, that's a pretty tempting idea. Questions of vendor lock and security aside (for the moment), that could save a great deal of time and money, for a small investment.

The Network and the Computer

Another interesting idea is the thought of thin-client or network computing. Each person may have a small computer (something more than a dumb-terminal but less than a full-blown workstation) which has the ability to run applications from a server. It may not have much more power -- you'd never think of recompiling your kernel on it, as it does little more than act as a remote keyboard, mouse, and display for the big iron server Sun wants to sell you. Files and user settings are stored on the server.

With centralized storage (and questions of vendor lock and security still set aside), you might be able to access your documents anywhere you have access to a thin client or network computer. Want to telecommute? No problem. Need to travel to a supplier or a customer site and make a presentation? No problem. (Want to authenticate your identity beyond a shadow of a doubt? That's another essay altogether.)

The selling points there include standardized hardware (if your machine breaks, swap it with another -- no need to transfer user settings or documents or reinstall your operating system), a centralized point of upgrades (add a new hard drive to the server, or another network card, or another CPU) and easy access to data (relatively speaking). Drawbacks definitely include likely proprietary hardware and software and a central point of failure (if the network is the computer, what happens when the network goes down?). Besides that, given the proliferation of decent, fairly inexpensive workstation prices today, the total costs may be less to pay a couple of hundred dollars more for a full-blown computer than a bunch of thin clients and a massive server -- even if your hardware platform, OS, and application suites of choice will cost more to administer.

Still, the benefits are worth looking into.

Where We're Going With This

The question we ought to be asking is, "How can we develop a framework of computing that allows users to collaborate and to share data from divergent places, while being concerned about security and open standards?" In the language of business, we might ask, "What is the best way to improve the managing of information from different sources if our values are cost, convenience, and performance?"

We will assume that it is generally cheaper to use the existing Internet infrastructure than to create a dedicated network between our collaborators, even if that means leasing a new T1. (These are probably already present in many larger businesses.) This has the additional benefit of allowing access from new places, such as a new supplier or customer -- provided they already have Internet access.

What Should Our Applications Look Like?

I intimated earlier that Microsoft's view of things is becoming web-centric. That is, a web browser (indeed, *their* web browser) is the primary interface to these documents. While this has the benefits of an interface relatively familiar to many business users, it has many drawbacks.

The primary drawback is appropriateness. Can you imagine writing an Engineering Requirements Document in a web browser? How about in a Java applet or an ActiveX program? How about editing mathematical formulas, or drawing an organization chart? Just because something is easy to use (or familiar) for one purpose does not make it the appropriate tool for other jobs. (If you're confused by the Jargon, just imagine trying to write your resume with a white crayon on wax paper. No offense to the Java folks.)

Another weakness of web browsers is stability. Displaying static pages is relatively easy, but with dynamic content and technologies such as JavaScript, Java, ActiveX, Dynamic HTML and so forth, each in different stages of implementation in various browsers, hordes of bugs are present. If you're surfing the web looking for eye candy and your browser crashes, that's one thing. Now imagine your blood pressure rating if your browser crashes while trying to calculate the average of a column of numbers in a spreadsheet.

The final concern is that of security. This is especially important with regard to trade secrets or confidential financial information. While the benefits of Internet-based collaboration outweigh other options for sharing files, the public nature of the Internet makes encryption necessary. Web browsers do support this, but the default security allowed for international use is built around 40-bit keys. (40-bits is a bicycle padlock. 56-bits is a bicycle padlock and a "Warning! ACME Security Systems!" sign. 128-bits is a pit bull, a deadbolt, and a Neighborhood Watch program.) In general, the less bits per key, the less secure the encryption. Besides key length, browsers are notorious for their security exploits, especially when one adds active content such as JavaScript and ActiveX.

One company I know of (Instinctive Technologies) supplies a product called eRoom. This is a web-based service which lets users access eRooms (basically user directories prentending to be embedded in web pages), modify documents in the rooms, participate in discussions, and track changes. It supports version control and file locking.

It's not a perfect product, but it does illustrate some of the issues which will have to be addressed. First, access is limited to users who have a correct login name and password -- this is encrypted by the web browser and sent to the eRoom server. Next, access to specific eRooms and directories (or folders) within the rooms is granted by means of an access list. Users are given specific rights to specific areas. Administrators can even create groups of people, assigning rights to groups (aligned along business function or task lines).

Another feature is that of version control. Suppose I were to create the first draft of this document and allow other people to make changes to it. Worse yet, I spread my work by e-mailing the document to everyone who might like to read or to change it. After two or three days, there may be dozens of incomplete or incompatible versions floating around. Version control attempts to manage this by only allowing one person access to make changes at a time and by tracking all of the changes made. This is nothing new -- source code control systems such as CVS have had this for a long time. (Programmer's note: would binary versions of diff and patch be appropriate here for non-text documents?)

Who Decides Your Document Type?

In theory, the eRoom system should work with any document type (there being two -- pure and unadulterated text, viewable by just about any program on any platform, and some binary format, possibly viewable in only one specific application on one specific platform). In practice, I have only seen it used to store Microsoft Office documents -- Word, Excel, and PowerPoint.

To put it bluntly, this is a bad business decision. This is also purely my analysis. Imagine, if you will, that your company enters into a contract with another company. Your company agrees to deliver certain items according to certain specifications. To read and edit those specifications, you must use a certain program (we'll say Microsoft Word 2000) on a certain platform (Windows 9x or NT) running on certain hardware (x86 PC architecture). If you did not normally use this program, platform, or hardware, you would have a few options.

You could set up one specific machine just for this contract, and have one person coordinate the changes. That would involve converting the file FROM that format TO a format your employees could edit, editing the file, and converting it BACK to that format for transfer to the other company. Big Grins for Bill Gates, Big Yawns for that poor employee. (There are ways to automate this, but consider this. If your company were in Quebec, and you set up a business deal with a company in Mexico City, would you rely on French->Spanish and Spanish->French translations every time you wanted to communicate? Or would you look for a common ground lingua franca, perhaps English? (Okay, bad pun. But the point remains.))

You could convert all of your users who will be working on that specific contract to the new hardware, platform, and software. This would involve retraining and possibly converting existing documents and converting to new software on the new platform on the new hardware -- a significant investment indeed.

You could object to the whole dilemma, arguing that there are existing document standards not tied to a specific platform or application or hardware, but you probably wouldn't get the contract.

That's the problem.

Yes, it is good and even necessary to adapt to your customers or clients or associates. However, should they have the right to dictate your business practices? Do you have the right to dictate theirs? Proprietary document standards do just that.

Let me give another example. I have seen the relationship between a manufacturing center and a group of engineers testing designs and components for products which have not yet gone into full production. The manufacturing center upgraded its project timeline software. The new version of the software used a different document format than the previous version. Thus, any of the engineers who wished to be able to read the new timelines from the manufacturer had no choice but to upgrade their software as well. Unfortunately, their company was in the middle of negotiating a license agreement with the software manufacturer, and the software was not available. (The software had to be purchased at a local retailer and installed on one machine. The user of that machine then had the task of opening and printing all of those timelines because he was the only person who could).

Please note that both the manufacturing center and the engineers were using the same product from the same software company on the same platforms. In fact, they were using roughly the same timelines altogether! However, because of the proprietary document format which changed between versions, the two groups were unable to communicate as they had done before. Shame on the software company for being unable (or, more likely, unwilling) to maintain compatibility with *its own product*. Once one company upgrades, other companies feel the need to upgrade to maintain file format compatibilities. This is only good for the software companies who use proprietary document formats.

Still don't believe me? Try to buy a new business computer these days without the latest and greatest versions of software on them. Are their document formats compatible with the previous versions? Maybe... but not all of them. And you may have to search the menus and boxes and widgets to find out how to become compatible.

Where are We Going?

What can be done? How do all of these anecdotes tie together?

What if business could share information with other businesses? What if people could edit their documents from just about any other computer in the world? What if sharing data with other people didn't mean having to buy new software or new hardware?

For those of us involved in Open Source and Free Software, what if we could provide businesses with the tools they needed to accomplish those goals?

The first thing we would need is some medium which businesses and users can use to share information. We've already discussed the Internet in general. E-mail is a possibility -- but that introduces various risks. First, it was never really designed to be an efficient medium to transfer binary information. Text is just fine, but your document format isn't likely to be text. It is easy to use, though.

How about the web? Microsoft, Instinctive, and other companies are using their web servers as a central repository for documents. Indeed, they are putting more security measures in place and are writing more software to handle other document types. Still, we've talked about limitations of web browsers.

Perhaps what would be best is some sort of hybrid -- accessible via a web-like interface or address, but opening in a separate program. (The Unix philosophy of lots of small programs each doing one thing well, able to be linked together for more power and flexibility, applies.) The program would need to have security built in from the ground up (using PGP or SSH or some other method of ensuring privacy and encrypting data).

One weakness in this idea is that users must ensure their identities if they are to work from different locations. While a username and password would fulfill this requirement, it wouldn't fulfill it as well as a 128-bit encryption key (or part of a key pair). Perhaps users could use a credit card sized device which generates a unique number based on a memorizable PIN and a hard-coded algorithm would do the trick.

Larger companies could set up their own secure servers for their own organization and business contacts, while smaller companies might be in the business of providing server space and hosting for other smaller companies. It's a service. (The most forward thinking would put server farms in different geographic areas ... the Superhighway metaphor is only valid once you start to realize that there are a lot of people living right off of dirt roads and goat tracks.)

What about document formats? Is there a way to ensure that your company doesn't have to play the upgrade game every time you work with a new supplier or a new customer?

Fanfare, please. Consider XML (Extensible Markup Language). Without getting into terribly specific details, XML provides a way to classify data. For example, you could create a document type for a business address:

<business-address>
     <contact>Paul Jones</contact>
     <business>Metacreative Fizzles</business>
     <mailing>
          <street>1595 W. 14th</street>
          <mailstop>MS 410</mailstop>
          <city>Baton Rouge</city>
          <state>Louisiana</state>
     </mailing>
</business-address>

Any application which implements a valid XML parser should be able to handle this, provided it is correct XML. (If that worries you, consider that you expect your business applications to be able to handle their native document formats correctly anyway.) Also, since the data itself is marked up (that's what the keywords between the greater-than and less-than signs are for), the applications can manipulate the data.

Read that again if you don't see the benefit right away.

What this all means is that if you and your business contacts agree on XML, it doesn't matter which XML-aware application you use! It doesn't matter which hardware you use, or which platform you use. (Which application matters -- not all of them support XML yet. But we're in a position to change that.)

If the document format isn't tied to particular software or hardware or platform any more, and if you are authorized by the security measures, you can access, display, and manipulate your documents anywhere that has Internet access. Moreover, so can anyone else you choose.

You can create a document in Alaska on a Pentium II machine running Windows 2000, and your Malaysian manufacturing team can update their inventory lists in it from their SPARC stations, while your embedded software guru updates the codes from his PowerPC running Linux. You can display only the relevant parts of the document to each group.

Now to achieve this goal programmatically, you'll need some software. You'll need software to store the documents. You'll need software to serve the documents, put the proper security on the files, manage changes, and lock access to files which are being modified. You'll need software to read and understand and modify your documents on the servers.

Another thing you'll definitely need is a DTD. That's a Document Type Definition which tells your XML Parser exactly what it should expect. Without getting into hairy definitions (which is basically what a DTD is), it describes the kinds of tags (stuff between the < and > brackets) to expect in what order. It does not tell you what the tags mean and what to do with the information -- that is a job for something else (an XSL enabled processor, perhaps, or an application program). XML is merely a way of marking up data, of describing the data in logical -- and easily parsable -- ways.

How Do We Get There?

Don't worry too much about that. Those of us who have the ability to write software like this have lots of good tools. We have programming languages like C and Perl and Java, which can build good software which run on a variety of platforms with various amounts of ease. We have lots and lots of standards already in place which we can leverage for what is good and what works. We have lots of programs which are already working which solve some of the problems I've already mentioned. Most of all, we have the skills and the desire to tackle some of the things which haven't already be done. It's what we like to do.

The one thing to watch out for is subversion of the standard. If you like the idea of being able to exchange information between users and between companies without having to convert it from one proprietary format into another, help us fight to make it a reality. Some software companies have made lots of money off of fragmenting the world, of making sure that people have to buy new software every couple of years just to read memos and columns of numbers. Those companies stand to lose a lot if, all of a sudden, information is unconstrained by proprietary file formats. The rest of us stand to gain tremendously if we can win back our freedom.

Give us some time and some support, and we'll amaze you. Just let us know what you want and give us a chance to do it. We'll do it. Even better, we'll do it for the right reasons -- not because we want you to be locked in to our software and our solutions, but because we think that helping people communicate is a really good thing.

For the most recent version of this document, please visit:
http://snafu.wgz.org/chromatic/essays/

Please send suggestions and corrections to chromatic@snafu.wgz.org

This work may be redistributed in whole, provided that this notice remains intact. This work may also be modified in whole or part, provided that the original copyright notice is preserved and the original is provided, or a link to the original is preserved, and provided that the derivative is clearly labeled as a derivative work, with all responsibility for changes upon the person or persons who have made those changes.