Welcome to Orcmid's Lair, the playground for family connections, pastimes, and scholarly vocation -- the collected professional and recreational work of Dennis E. Hamilton

Recent Items
 
OOX-ODF: Taming the Guerilla Bob Sutor just linked...
 
A World of Identity No, Internet Identity is not ...
 
If You Knew Me, You’d Know This   Read my Vis...
 
OOX-ODF: The ECMA Response to ISO Comments I much ...
 
Hedging the Software Biz Game: Feeling Lucky? Acco...
 
OOX-ODF: The WOES of ODF Emerging Discussion of He...
 
California Won’t Be Outdone: Banning Zip, PDF, Tex...
 
The Future of Microsoft Office? I couldn't help my...
 
At My Age, It’s Time To Get Busy Find inspiration ...
 
Peter Naur: Science for Computer Science Peter Nau...

OOX-ODF: Why Have Peace When You Can Have War?

In some of the harangues about Microsoft’s introduction of Office Open XML format in Office 2007 and then submitting it for the ECMA-376 OOXML specification, it sometimes appears that it is even more objectionable when Microsoft takes steps to cure a situation that has been the subject of previous complaints.  I’ve not found a straightforward way to account for this amusing aspect of human nature at its most frustrating. 

Attending an Office Open XML workshop in Redmond this week, I had the pleasure of meeting some of the developers and technical evangelists.  In casual side conversations, I was surprised to learn the degree of bafflement over the ways OOXML is rebuffed in some quarters.

Microsoft developers: “Why are we beaten up for providing what customers were begging for?”

My shoulder-shrugging speculations have to do with human psychology and the cognitive errors that are blindly made in the heat of adversarial conditions.  Have you ever noticed that when people are in a hot dispute and one party concedes a point, the adversary will often switch positions and continue the argument?  It’s no longer some disagreement about interpretations of facts, it’s about arguing and having the opponent be wrong no matter what.  I don’t know about you, but I’ve done that.  With age and experience, I seem to be better at catching myself.

I’ve already pointed out one pitfall, the willingness to see only what we are looking for in a given situation.  But some of the adversarial statements are more complex than that and it is more difficult to figure what is going on.   Fortunately, security expert Bruce Schneier provides a place to start.

I have a story that is a parable for this.  This is not a mystery and I encourage you to leap to the ending if you want to see the conclusion, returning to the narrative progression as desired.

Heuristics Are Us: Dealing with Perceived Threats

This morning, Bruce Schneier offered up a brief post linking extended materials on real versus perceived risk.  (The comments on Schneier’s brief paragraph are remarkably all over the map.)  Schneier points to Jeffrey Kluger’s November 26 Time article, “How Americans Are Living Dangerously.”  This is a great appraisal of the ways that we are psychologically wired to come up with distorted judgments of risk in modern situations. 

Schneier is intrigued by this topic.  It is important to understand with regard to the ways we deal with perceived threats, dangers, and the trade-offs we make that address the perceptions and feelings rather than the reality.  He explored this behavior in his book, Beyond Fear.  Our credulity with regard to security theater is a related concern, and that ties into the influence of agendas on behaviors and how trade-offs are negotiated (see Beyond Fear, Chapter 3).

Schneier also links to his own February 2007 draft essay on The Psychology of Security.  Near the end of the section “Heuristics that Affect Decisions” I was startled to see this observation:

“People are more likely to notice evidence that supports a previously held position than evidence that discredits it. Even worse, people who support position A sometimes mistakenly believe that anti-A evidence actually supports that position.  There are a lot of experiments that confirm this basic bias and explore its complexities.”

and then,

“This all relates to security because it demonstrates that we are not adept at making rational security trade-offs, especially in the context of a lot of ancillary information designed to persuade us one way or another.” [all emphasis mine]

Although Schneier’s application is to important questions about security, these observations apply to any situation where there are trade-offs and risks to manage. 

Wikipedia Example: Mangling the Ariane 501 Lesson

A few years ago, I researched the Ariane Flight 501 Launch Explosion incident as part of a discussion topic for a software-engineering course.  By going to the investigation reports, I discovered that the received and often-repeated wisdom was incorrect.  It was not a simple programming error — a failure to treat or prevent an overflow condition — that was the failure. 

It is true that there was an uncaught exception in the operation of a part of the system.  But that behavior was not a bug.  The failure was far richer than that.  First, the exception was allowed by design.  Under the specified operating conditions, the exception could not occur.  The design was based on the assumption that if data was so far out of bounds that the conversion failed, a hardware malfunction would be the cause, the uncaught exception would properly lead to shutdown of the failed unit, and the backup unit would take over. 

As a consequence of a remarkable chain of clueless decisions, it happened that his unit was operating when it wasn’t even needed, outside of the agreed operating conditions, where the backup unit would fail exactly the same way (and had before the primary unit failed), and the shutdowns would result in a diagnostic message to the guidance system that was interpreted as guidance data.  The resulting violent maneuvering triggered by the bogus data led to separation of a booster from the main vehicle, breaking of an electro-mechanical safety coupling in the separation, and automatic pyrotechnic destruction of the launcher and its payload.  It blew up.

How does that fit with the theme of today’s post?  In December 2005 I saw an article by a respected authority that attributed the loss of Ariane Flight 501 to one of the 10 worst software bugs ever.  Having previously looked more deeply than that, I posted my rejoinder.  It was brought to my attention that Wikipedia’s articles on the topic reinforced the software bug assertion. 

Digging around in Wikipedia, I discovered an amazing condition.  At one time, the article on the Ada programming language (the language used for the Ariane 501 software in question) provided the nuanced account that I have just summarized.  It did not use the “overflow bug” explanation nor did it use the bogus explanation that the overflow exception was disabled. 

Subsequently, the text of the analysis was removed from the Ada article and placed in a new article on the Ariane 501 Flight.  When articles are scavenged in this way, it breaks the Wikepedia change history.  There is now no connection of the analysis text with its original place in the Ada article, and any earlier change history seems to have disappeared.  In addition, although the same analysis is quoted, a different conclusion is stated.  This conclusion sustains the conventional wisdom about the cause and currently suggests that the board of inquiry came to the same conclusion (which it did not).

Subsequently (scroll to the bottom of the oldest-history page), David Wheeler (more recently the leader of the OpenFormula project to finally get a spreadsheet-formula specification into ODF) made a valiant effort to set the record straight.  This did not take hold at the time.

Finally, the Wired article that I was informed used the Wikipedia coverage as its source is now cited as a source in the current Ariane 501 account. 

It is also to Wikipedia’s credit that there is now more balance and acknowledgment that some consider this a system-engineering[-management] failure, not a software bug anything like the other 9 of the 10 worst.  Still, head-line level spin and the summary is always to preserve the classification as one of the worst software bugs.  I still don’t know why we love it that way.

So, how about OOX-ODF?

When I saw the portions of Schneier’s essay that I’ve quoted, the Ariane 501 article “corrections” to preserve the software-bug conclusion leapt to mind. 

In the case of OOX-ODF, the situation has to do with what happens if Microsoft (or someone else) offers to provide what is claimed to be the missing key ingredient in the OOX-ODF standoff.

First, of course, there is an automatic assumption, in some quarters, that any move Microsoft makes is bad behavior with a covert bad outcome.  A common counter-maneuver is to up the ante and ask for more.  There are popular examples in the aftermath of Microsoft taking all of the steps it needed to make the Office Open XML formats public and freely usable without fear that Microsoft would enforce any necessary claims of Microsoft patents that might ever apply to implementations based on the specification.  The first up-the-ante was to demand release of source code (under a GPL-friendly license too), another was to require release of the legacy binary formats under the same terms and level of documentation (and, I suppose, reference source code), and the third was to hold implementers harmless from infringement in the use of other referenced (and non-Microsoft) formats that might be used within OOX documents.  Now some of these demands may be from parties that have no intention of implementing OOX under any conditions, and there the game becomes rather ridiculous.

But, suppose Microsoft did the inconceivable and conceded that they would indeed make ODF a native format?  Would that really be welcomed by those who keep throwing up that objection?  There’s room for doubt.

Let’s consider the experience of Gary Edwards in promoting the da Vinci plug-in for making ODF into a peer format of Microsoft Office applications (at least Word, Excel, and PowerPoint, where ODF has provisions).  In his article, “Three Stages of XML Migration and the Challenge to OpenDocument,”  Edwards offers some intriguing experiences.

First, Edwards, and presumably partner Sam Hiser in their OpenDocument Foundation, claims that OpenDocument is a universal file format.  I remain skeptical, but let’s set that aside because it is an article of faith among some OpenDocument Format adherents that ODF is universal enough.  (Aside: Edwards also speaks of ODF and OOX as “conflicting, contradictory and irreconcilable XML file formats,” and I don’t quite see how universality survives descent into such an abyss.)

As you move through toward the end of Edwards’ “Three Stages” article, you’ll see that the Foundation is developing a plug-in for Microsoft Office that will provide peer support of ODF, integrated perfectly alongside the other formats that can be accepted and produced. This da Vinci plug-in, along with availability of some magic XML/RDF sauce in the yet-to-be-completed ODF 1.2 specification, is going to allow full fidelity (or enough fidelity) to use ODF as a good-enough native format for Microsoft Office, Excel, and PowerPoint.  What intrigues me is Edwards’ observation that “the Foundations approach has met with considerable resistance, argument, doubt and continued outrage from the ODF Community at large.”

The OpenDocument Foundation is pursuing a three-pronged approach; that has me wonder about scope creep.  And maybe it isn’t da Vinci that is the target of outrage.  Still, I am left with the sense that there are those who have no desire to see Microsoft Office have full-up support of the OpenDocument Format, even while they claim that is all that Microsoft has to do to satisfy them.

Button, Button, Whose Agenda Trumps Interoperability?

This brings me back to Bruce Schneier and a wonderful statement at the beginning of Beyond Fear chapter 3:

“Most security decisions are complicated, involving multiple players with their own subjective assessments of security.  Moreover, each of these players also has his own agenda, often having nothing to do with security, and some amount of power in relation to the other players.  In analyzing any security situation, we need to assess these agendas and power relationships.  The question isn’t which system provides the optimal security trade-offs—rather, it’s which system provides the optimal security trade-offs for which players.” [my emphasis]

I recommend reading that again with “security” replaced by “interoperability.” 

One should consider Microsoft in this assessment too, but not automatically and thoughtlessly.  Something we’ve been able to count on from Microsoft is that they’re quick learners.  I think their recognition of the importance of open formats in the assured ownership of the public’s documents in civil affairs should be taken at face value along with their granting existence to ODF as one vehicle for that. 

Meanwhile, having digested the Edwards “Three Stages” essay and noticed the ODF Community resistance statement, I made this reckless hallway assertion to Brian Jones after an OOX workshop presentation yesterday [cleaned up as I wish I’d said it]:

“They don’t want you to support ODF, they want you to [resist ODF and to] fail.”

I’m not sure who “they” are, but I do suspect that is someone’s fervent wish.

If we are seeing “interoperability theater,” the public and the publics’ documents will be its hostages.  I don’t want that to happen.  A truce, and an effort to have interoperability that works, would be far more rewarding.  Peaceful coexistence strikes me as a desirable state.

 

posted by orcmid at 3/16/2007 03:22:00 PM