There is no need to subscribe to a hosted word processor over the Internet. WordPad is free with Windows, and you can save your documents in RTF, which used to be the standard format to interchange documents on different platforms. If you just want simple ASCII text with practically no formatting, Notepad would do nicely.

Separation of data and functions caused a lot of infightings within IT departments, begining in the mid-70s. I have witnessed data centric organizations ignore processes totally. Data models drove everything. In process centric organizations, data management took many forms or shapes. The same data field could be used for multiple purposes in a file or even a database. A Redefine in COBOL, or a new data structure in PL/1, would do the trick. In those days, 90% of the annual IT budget was spent on software maintenance. Dr. Edgar Codd did a good job in publishing his seminal work on the Relational Model by applying Set Theory and Conformal Logic, in order to come up with data normalization for databases and files. Separation of functions and data was practiced in the days when the first ENIAC computer became available for serious numerical computing.

Object orientation came from 2 sources. IBM’s System 38, now AS/400, was based on the concept of objects. Everything in that system is an object, but its native language was RPG! Xerox completed a piece of research work in document management — creation, routing, printing, and archiving of soft documents. Everything was based on the concept of objects, with the characteristics of Abstraction, Encapsulation, Inheritance, and Polymorphism. Smalltalk was the first object-oriented language. The system had a graphical user interface. Mac, X-Window, and Microsoft Windows are the decendants of that graphical interface. Documents were routed over an internal network (i.e. Ethernet). The workstation’s OS was called Star. The mouse, developed by DEC, was also introduced into that research project. That was how we got the WIM (Window, Icon, Mouse) man-machine interface paradigm. From object-oriented programming, we got OO design, and OO analysis, and then UML (Unified Modelling Language).

History repeats itself, similar to the structured movement og the mid-60s — Structured Programming, Structured Design, Structured Analysis with DFD and IDEF. If I recall correctly, C was the first programming language that got objectified by AT&T Lab, thus C++. Ada, Pascal, Basic, and Java followed. Today, we even have object-COBOL, if you want it. The whole point of object-oriented software is that you can call on services without integrating the source code from another piece of software. When you compile a piece of code into a DLL, you can invoke its service(s) by creating an instance of it, pass required parameters, and wait for the DLL to return you the result(s), without knowing what is inside in this piece of code. DLLs can be invoked as in-process calls, or remote procedure calls. Moreover, the call can be synchronous or asychronous if you spawn multiple threads. Mind you, you can still have data stored separately in databases or files. When there are enhancements to the DLL, you don’t need to know about it. When you invoke it, it will take appropriate actions based on your input parameter(s). This is the case when Polymorphism comes into the picture.

If you prefer to integrate all available routines into your program as one monolithic program, by all means do it. I believe that you will have a hard time maintaining it and keeping it up-to-date when new routines become available though. The key advantage of going the object-oriented way is the ability to re-use and share software components!

My point is the following: why would you pay a monthly fee to subscribe to a simple word processing service, when you could do it with WordPad and share your documents with others through e-mails? If you keep a copy of up-to-date documents in your free e-mail account, you can use Windows, Macintosh, or UNIX to work with that document saved in RTF.

The advantage of using XML-based documents is that both humans and machines can read it. RTF is a binary file, it is very difficult to decipher what is inside! If you are an expert at reading memory dumps, it is a different story of course!

Personally, I would not retire my Microsoft Office Suite anytime soon and subscribe to crippled word processing services, even if they are free. I still need OLE capabilities to integrate my documents (e.g. Proposals) and share them with my associates over the Internet to bid on consulting projects. In essence, a proposal must reflect what a potential client stipulated in the RFP. When the client wants to see a GANTT chart of your proposed project, you embed the schedule into your Word document from Microsoft Project. If you need to present a conceptual model, you would embed a Visio diagram into the Word document as well.

I was almost tempted to subscribe to Zoho and ThinkFree. I was going to try them out with my associates in Vancouver, Canada. When I tested them out, they were practically useless for the preparation of proposals! I will stick to my free e-mail account approach in sharing working documents and combining them at the end to form a proposal.

OpenOffice.org wouldn’t cut it either. I tried it out by embedding a Visio diagram in a document. When I saved the document as PDF, the diagram was all garbled up. Talk about low-grade compatibility!

One thing I would do as a consultant is that I would only recommend clients to get Microsoft Office Professional Edition for professional staffers, and get OpenOffice.org for workers who do not need to do heavy duty formatting in documents. In terms of documents sharing, Microsoft SharePoint and Exchange can do the job more than adequately for an Intranet. According to AIIM, SharePoint 2007 can interoperate with other ECM products available on the market as well.

I couldn’t agree with you more, it is the right time to end the debate.

Cheers!
 -Francis

I believe we have now hit the root of the issue:

What is office software for? Is a word processor…

a tool for delivering a document

OR

a programming environment for delivery of compound, active, executable objects?

If the latter, then I wholeheartedly agree that object bindings in the form of active components and data should be encapsulated into a single item.

I would argue however that if you took a straw poll of “ordinary business users”, then most (probably an overwhelming majority) would see word processors as a “clever typewriter”, and no more. It is this vast bulk of users that I believe we should be looking for as target user population for Office 2.0. Indeed, many organizations deliberately prevent or discourage usage of macros to prevent a whole class of malware attacks.

My gut sympathies lie with the “uncomplicated” simple document approach.

As for progamming models — I personally favour the UNIX based approach of separating out dedicated components and keeping data well away from executables. If this is old fashioned, then so be it, I just need to wait for a while. And given the way this industry works, it’ll come back in another guise sooner or later.

In the interests of not hijacking the thread into a philosophical discussion about paradigms and pragmatics, I’m planning to let the subject drop and acknowledge differing views.

I believe that you have no idea what object-oriented software is. Abstraction, encapsulation, inheritance, and polymophism are the basic constructs of object orientation. Objects (data) and methods (functions) are encapsulated in the software itself — a form of information hiding. This has nothing to do whether it is done by Microsoft, IBM, or Sun for that mattter. The way you think is like a typical DOS programmer. Whether you are programmer or not, that I don’t really know.

There are two competing object-oriented implementations, Microsoft’s COM with OLE and Sun’s Java that adheres closely to OMG’s CORBA. COM applications can function as clients as well as a servers that can create compound document swith objects from different servers (e.g. AutoCAD, Microsoft Project, CorelDraw, etc.) Java programs have a clear-cut boundary, either as client or server, but not both.

Therefore, an object-oriented program, be it written in Ada, C++, C#, VBA, or Java, always has functions and data encapsulated within.

-Francis

Why do we have this blind assumption that macros need to be in the same file as the document’s content? How has the Microsoft Office approach been burned into our collective psyche so effectively? This is a genuine question, as understanding the answer will help shape the Office 2.0 roadmap.

Now for the views of a heretic…

If we really insist on bundling, why not a composite file (e.g. zip or tar) containing a document’s content file and an associated file for macros? Separating them out would also have the added benefit of being able to build up standardized libraries to be used across an enterprise, rather than running the risk of each employee inventing his/her own variant. These libraries could also be digitally signed, or at least have SHA/MD5 checks to detect tampering.

Taking the next obvious step, it is then possible to publish libraries of macros, with a common set of APIs and multiple implementations (i.e. the library defines the interface, and then there are several implementations in VBA, Java, JavaScript, Perl, Ruby, Python, etc.).

If you receive a file with macro X invoked, then you can open it with your chosen application to view the content; should you wish to run one of the macros, you then pick the set of implementations that are supported for your platform and meet the specified APIs.

If you just want access to the content, you can view it directly, with no risk of running active components and associated dangers from malware. See also earlier comments on how most people use office tools, as means to an end where hard copy output is the real business driver. Of course, it is not in Microsoft’s (or the anti-virus vendors’) interests to do this separation.

One final observation: I use OpenOffice.org on my Linux box at home, and the performance is comparable to Microsoft Office on my company Windows XP machine, which has a similar processor and more RAM. The very first invocation may take a few (~10-15) seconds longer, but this is offset by the fact that I don’t have large chunks pre-loaded at boot time and consuming background resources when not being used.

I would not call JSON a standard, but a potential candidate for light weight XML. I don’t know whether XSLT would be able to handle JSON or not. If it doesn’t, we need an equivalent of XLST for JSON! IETF is the wrong place to submit JSON for accreditation, it should go to W3C instead. We have 3 file structure standards to work with: ISO’s OpenDoc, ECMA’s OpenXML, and China’s Uniformed Office Language. Do we need another one? I don’t see how JSON would help in developing scripts or macros in ThinkFree and Zoho. The scripting language will most likely be based on ECMA’s JScript (JavaScript). Moreover, I don’t see why ThinkFree and Zoho would invest to support more than 3 file structures, when they need to deal with OpenDoc, OpenXML, and UOL to support partial compatibility! Full compatibility is defined as an application that also supports Microsoft Office’s OLE!

Based on what you speculated earlier, my understanding is that ThinkFree or Zoho can open a Word file, but it will not preserve the file integrity after a document is changed and saved. Don’t forget, for an updated file to work within Microsoft Office again, all macros must be in VBA, not JavaScript or anything else. Otherwise, ThinkFree and Zoho will be one-way compatible with Microsoft Office! In essence, there will be no interoperability between applications. This contradicts what a good Office 2.0 application should be, isn’t it?

Best regards,
 -Francis

You’re right, JSON is not a de jure standard. Yet it’s one of the specifications for structured data sharing over the Web that has the most potential in my opinion. I do not really know what to call it then.

Best regards
 -Ismael

Are you sure that JSON is really a standard yet? It is not listed in the IETF standards list. JSON is only an informational memo filed as RFC as follows:

Network Working Group
Request for Comments: 4627
Category: Informational


The application/json Media Type for JavaScript Object Notation (JSON)

Status of This Memo: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

I am not sure that JSON will become a de jure standard anytime soon. It may go to the same route as Java, which is not a de jure standard, and still under Sun’s control! Java will never be used by the DoD, except embedded Java, because it is compiled and burnt in firmware. In one of the embedded Java meetings, Sun raised objections to a proposal for modification to the embedded Java, because this would infringe its intellectual property. This is how open Java is!

Best regards,
 -Francis

I do not want to speak for ThinkFree or Zoho, but I doubt that they will try to re-implement the macro language found in Microsoft Office, and I’m pretty sure they won’t try to support OLE either. Instead, I must believe that they will implement a new macro language that will offer some level of compatibility with existing Microsoft Office macros. What this means is that you would be able to migrate simple existing macros, and build complex new ones from scratch. I would also expect better support for Web services and emerging standards such as JSON.

Best regards
 -Ismael

It is interesting to know that ThinkFree and Zoho are working on the macro support. It would be a big challenge for both of them. Each has to write a transformation routine to map VBA objects, methods, and exception handlings to their Java counterparts. I wonder how the performance will be.

Starting from Office 2003, Microsoft Office runs under a compiled .Net environment. As the JVM always runs in interpretive mode, it will take ages for a ThinkFree or Zoho application to load, translate, and execute the byte codes. OpenOffice.org is a good baseline to project the performance of Java-based applications. It takes 3 to 20 times as long as Microsoft Office to load a Word document in the same workstation. Also, the response is always slow! Moreover, it would be extremely difficult, if not totally impossible, to support OLE on non-Windows platforms.

Corel was the first commercial software vendor that was brave enough in attempting to move WordPerfect onto the Java platform. After wasting millions of dollars and 3 years, Corel had to abandon the Java project. It almost went into non-recoverable bankruptcy. Many WordPerfect users have switched to Microsoft Office Suite since then. These include both the Canadian and U.S. Governments!

It will be interesting to see if ThinkFree and Zoho can really deliver the “full macro support including OLE” within a year or less!

-Francis

I like your plan!

-Ismael

I had posted something like this in December but it appears not to have made it to the stream… I agree that macros and the like are desirable, but for most practical uses they are not essential — as a very unscientific guess, I’d say that fewer than 15% of people use them regularly.

What people need generally is a means of producing hard copy output, formatted to their needs. When it comes to the crunch, lawyers, commercial managers, judges all refer to the paper document — not to electronic media. There is a whole other thread on digital signatures to be explored here!

To this end, what I believe matters is the ability to import/export information in an open, easily manipulated format. Open Document XML (as used by OpenOffice.org, KOffice, and others) seems a good way to go. If output only is required, then PDF meets the needs — it is doumented, open, and there are plenty of viewers available (not only from Adobe).

Given that, I’m looking for:

1) Simple tools to synchronise text based (XML) files;

2) A well defined schema for document exchange, with a default XSLT mechanism to translate proprietary extensions to something labeled as “produced by software not complying with XYZ standard,” so that lock-in strategies based on ‘enhancements’ are seen for what they are;

3) A clear, simply worded usage policy — free of patent encumberances.

If we achieve that, then we can truly liberate people to use Office 2.0, and by virtue of using simple file formats, we can open up document management systems (synchronization at first, meta-data tagging later…), and by separating out executable code (macros) from the data stream, we can eliminate a large class of malware. And those that truly need complex macros can still use their proprietary tools — just publish the results in an open format.

Cheers
 -Andrew

I agree with you, support for macros or scripts is required, and both ThinkFree and Zoho are working on it currently. Interoperability and extensibility are required attributes of a good Office 2.0 productivity suite, and I would expect these to start appearing in product offerings sometime this year. But keep in mind that it might take a couple of years for them to mature to a point where they become really usable by third-party developers.

Best regards
 -Ismael

You could only make a claim that Office 2.0 would support most of Office 1.0’s capabilities only if Office 2.0 also supports macro (or script). As far as I know, only Microsoft’s Office and WordPerfect support macro. OpenOffice.org and the like don’t. In the Windows arena, in order to interoperate with office suite, you would use VBA. Examples are AutoCAD, Visio, and MS Project.

One trend is that most IT type of people miss “system interoperability”. They still have a stovepipe mentality! SOA is a good base for implementing interoperability because it supports scripting — an equivalent of macro. Before SOA came along, there were CORBA and COM for interoperability. CORBA is too complex and COM runs on a single platform (i.e. Windows only). With interoperability, it is much easier to locate and consume services. COTS (Commercial Off The Shelf) based systems are one typical example.

In essence, Office 2.0 is still very primitive as compared to MS Office Suite. Apparently, Office 2007 will be able to run in a mixed workstation and Internet mode! One question remains: would it interoperate with other applications like AutoCAD, Visio, and MS Project?

-Francis

As we have only 2 days before 2007, I found an interesting presentation to summarize the big trends in 2006. Cetainly BPM 2.0 and Office 2.0 should be included. But here is another way of picking up the big trends. Check this post. There, I love #12 and #13 the most.

My interpretation of [2006 = Business + Design = MBA + MDA] is:

Model Driven Business Strategy (Modeling and Design) Architecture = MBA

Model Driven IT Model (Design and Development) Architecture = MDA

What’s your take?

Regards

I’m not surprised at all that ThinkFree doesn’t support macro, OLE, COM, and DCOM. I assume that ThinkFree was developed in Java. The VBA (Visual Basic for Application) engine doesn’t run within the JVM, therefore no macro support. By the same token, Java is not capable of supporting dual-role in an application (i.e. an application that can act as a client as well as a server). OLE (Object Linking & Embedding), COM (Component Object Model), and DCOM (Distributed COM) will therefore never exist in ThinkFree.

By the way, OLE was implemented first in the MS Office Suite that ran under OS/2 1.2 LAN environment back in 1991. Office 95 was the first Windows based application that supported OLE and COM. In the project that I managed for Ontario WCB (Worker’s Compensation Board), MS Office Suite was used to do a lot of actuarial computations, documentation, and presentation. ODBC was used to import and export data between Excel and Data Manager (OS/2 version of DB/2). I believe that I was the first one, in the early 1990s, using COTS (Commercial Off The Shelf) packages to develop applications way before SEI and DoD were seriously looking into COTS for application development.

I wonder where you get that 10% figure from! As far as I know, many enterprises have applications developed and run with the MS Office Suite. These applications will not be migrated to Office 2.0 anytime soon, if ever.

-Francis