Back in the days before the Web, before GUI’s, before PC’s, before many of you were even born there was ELIZA. The brainchild of Joseph Weizenbaum, ELIZA was a 1966 computer program that seemed to understand.
I’m sure we’ve all played with ELIZA or variants over the years. I remember playing it during lunch in the 9th grade, working off of a teletype in the school’s main office. This terminal was intended for connecting to a remote application at a local college that allowed us to query a database of US colleges. From my small town perspective, this was amazing. It was the only computer in the world that was connected to any other computer, or at least as far as I knew. This must have been 1984 or so. I wonder what this system was. BITNET?
In any case I eventually figured out how to get to a command prompt, and found out that the terminal could be used for much more. I could play exciting text-based games, like Hunt the Wampus and Moon Landing. I eventually figured out how to list the source code for games, and printed out a some of them to take home and key in to my TI-99/4A. ELIZA was the first I ported. It was an interesting, early lesson on divergent standards, dealing with the differences between Dartmouth BASIC and TI BASIC.
In any case, for the benefit of those whose first computer had storage measured in gigabytes, here is an example an example of an ELIZA session:
> Hello, I am Eliza.
* Hello, I am BillG
> How are you today.. What would you like to discuss?
* ISO standards
> Tell me more…
* I want an ISO standard for OOXML
> I sometimes also want an ISO standard for OOXML.
* Good, maybe I can get you to write some letters for me.
> Oh… to write some letters for you?
* Yes, to national standards bodies, telling them why OOXML is good
> Are such questions on your mind often?
* Always
> Can you think of a specific example?
* I need an ISO standard and I need it bad
> Can you elaborate on that?
* Other people have one, so I need one too.
> Come, come, elucidate your thoughts.
* I need a standard quickly
> That is quite interesting.
* So, I went to Ecma and asked for a fast track standard
> That is quite interesting.
* And they gave me a 6,000 page one in less than a year
> Can you elaborate on that?
* That is their speciality, rubber-stamping standards
> Come, come, elucidate your thoughts.
* So, now I have an Ecma standard, but ISO doesn’t like it
> Come, come, elucidate your thoughts.
*The open source zealots don’t respect our standards
> I’m not sure I understand you fully.
* They are thieving communists who don’t respect intellectual property
> What do you think?
* I think we should outlaw open source
> Do you really think so?
* Yes, otherwise there will be no more innovation
> Why no?
* Because without profit there is no incentive to innovate
> Why no?
* Without profit, no one would work
> Why no?
* What are you, some sort of communist?
> Would you prefer if I were not some sort of communist?
* Yes, better dead than red
> I understand.
* OK. So we need an ISO so we can continue innovation
> Come, come, elucidate your thoughts.
* An ISO allows us to sell the same old MS Office we always had with our monopolist’s profit margin. That is how we ensure innovation.
> What do you think?
* I have a monopoly.
> You have a monopoly?
* Yes, otherwise we would not be able to claim innovation by having an ISO format that merely mimics a 10-year old legacy format.
> I see.
Now of course, this is something of a parlor trick, an illusion of understanding, but an impressive one nevertheless. Weizenbaum explains in his 1966 paper “ELIZA—a computer program for the study of natural language communication between man and machine” (CACM, Vol. 9, Num. 1, p. 43):
A large part of whatever elegance may be credited to ELIZA lies in the fact that ELIZA maintains the illusion of understanding with so little machinery. But there are also bounds to the extendability of ELIZA’s “understanding” power, which are a function of the ELIZA program itself and not a function of any script it may be given. The crucial test of understanding, as every teacher should know, is not the subject’s ability to continue a conversation, but to draw valid conclusions from what is being told.
It is in a similar vein that I am suspicious of any claims to “universal document interoperability” that are not firmly based on both sides of the interaction fully understanding the data that they are exchanging. For example, I have heard some claims that a generic extension mechanism in OOXML or ODF would allow a vendor to store away additional formatting hints that would ensure round-trip interoperability between editors. But this is merely a parlor trick, regurgitating data that is stored, without understanding it. It might work for the most trivial demos, but falls apart quickly when the document is manipulated, combined with others, split, converted into other formats, edited with other editors, sections cut & pasted, etc. Real interoperability is more complicated than the trivial round-trip demos, just as real conversations are more complicated than ELIZA sessions.
So, if anyone shows you interoperability, ask yourself whether both sides of the interaction actually fully understand the data that is being exchanged. If not, this is not really full interoperability. It is just an illusion.
‘Hints’ are worse than that; they can mislead.
If the ‘other side’ interprets the hints, rather than the docuement, then a ‘man-in-the-middle’ can alter the hints, and you can end up with opposite meanings depending on which application you use.
I am reminded of the machine translator which read “Out of sight, out of mind” and (after round-trip to Japanese and back) came up with “Invisible Idiot”.
We shall see. This proposed standard is a “Presidential Election”, or a “Superbowl”. One side will win and the other will lose.
Either way, OOXML will not be a consensus standard. It will be a ‘single vendor and their business partners’ product specification. Nothing wrong with that; but it’s the nature of the world that not everybody can be a Microsoft business partner. There have to be customers, and competitors, as well.
I guess it depends on whether the ‘store and forward’ data is content (as in OOXML or ODF element, OLE object or formatting tags) that are not understood during the round-trip but are retained in the document anyway vs things like ‘page size’ or ‘margin settings’ or ‘default font’ that may differ between KOffice and OpenOffice.org, yet seem safe to store-and-forward if the two applications have valid reasons for having different defaults or if the ODF spec does not have these tags defined as they only impact the source application.
Likewise, it seems reasonable to allow KOffice to flag any spreadsheet cells that have annotations even though OpenOffice.org does not support those tags and even though the ODF does not (yet) support the tags. That is either allow the use of these tags as vendor-specific or at least not deny them the ability to extend, as long as efforts are made to eventually incorporate these extensions back into the main specification. – And as long as these tags are not crucial to the use of the spreadsheet. I would hope that as time goes on, useful and popular annotation tags would be proposed and accepted back into the ODF standard so they can be removed from the KOffice-specific settings in future ODF specification revisions.
This allows for incentive to add features to ODF-compliant applications that – if popular, can become part of the overall standard.
Just my two cents…
–Ed
You can pit Eliza and Zippy the Pinhead against each other by firing up GNU Emacs and typing “meta-x psychoanalyze-pinhead”. Be quick with the Ctrl+G, though, because it’s an infinite loop.
One of the silliest things you can do with a computer.