[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Microsoft buys the Swedish vote on OOXML?

• From: Len Bullard <len.bullard@u...>
• To: Jonathan Robie <jonathan.robie@r...>
• Date: Tue, 28 Aug 2007 15:08:23 -0500

>You seem to be arguing against the idea of one vote per company, saying 
>that whoever is best able to create large lobbies should win in the 
>standardization process.

I'm saying that is what they do already and always have.  That is what the
ODF effort is doing as well but it is doing it to defeat a candidate.  It
seems to be business as normal but rather ugly in this case.  I'm not sure
we can change that or should, but it I think it in everyone's interest for
it to be a less ugly event.   

I don't think the results of having two standards regardless of their
provenance justifies pummeling ISO into the ground.  I do think ISO should
take a long hard look at this event and question the efficacy of the
processes given the reality of large vested interests being able to game the
systems from all sides.  Realistically, I'm not sure what can change but the
reputations of all engaged in this are taking a beating and as a result, the
'millennials' are stepping up to the plate even more cynically than we were
when we were the young turks.  This can't be good. 

I think about what Christine Amanpour said about the problems of "God's
Warriors" and the Middle East.  Paraphrased, it isn't that one side is more
right or wrong, it is that all sides are killing the middle and the only way
that stops is when real leaders emerge and compromise on their mutual needs
instead of continuing to fight over their differences.  Has it ever been
otherwise in any seemingly intractable and unwinnable fight?

>I honestly don't know whether Red Hat has been voting on this standard 
>at all - I haven't been involved in ODF, OOXML, or ISO standards, but 
>you seem to be implying that the proper remedy is for every other 
>company to try to stuff the ballot box by enlisting their own partners, 
>and whoever does this best should win.

No, I am saying that a bit of honesty here among the chickens is in order.
Stuffing the boxes is becoming an acceptable way to do business but it seems
all sides have only their own interests while telling the customers they
should pay for the differences to reconcile on one solution. Ugly.  

Really, two standards won't hurt and the rest is gerrymandering.   We've
seen this cycle enough times in enough organizations with different players
over the years to know it for what it is.  If OOXML is that terrible, it
will die a death of neglect.  If ODF is that wonderful, it will enjoy a
rapid rise, but we have to let the customers choose according their own
circumstances or we are doing the same dumb thing we did when people
believed one DTD (think 28001) could cover all documents.  It's like sex for
power; it is cruel and evil.

>This is one of the traditional ways to measure whether a standard is 
>implementable - compatibility among multiple independent 
>implementations. That's the approach we take in the W3C, where I've been 
>on standards groups for 10 years. I think Google is implying that there 
>are not multiple independent implementations for OOXML.

Google implies that but Google hasn't even tried and won't try; yet as Rick
points out, they are a big user of VML and I remember people on this list
vilifying VML.  No one else can as long as there is no standard.

>I have no idea what a Red Queen is, but I'm certainly not speaking for 
>Red Hat in anything I say, I don't know what our position is on OOXML, 
>and the quote above comes from Google's position paper, not from me.

See Lewis Carroll.  A world of upside down logic.   I've been watching this
for some time and it doesn't seem to have an outcome of one standard.  It
can have an outcome of punishing the customers with high costs and no
choices but to pay them to the companies that win the bitter butter battle.
As far as I can tell, there is little benefit to the information or the
customers by short term mandate of ODF.   There will be benefits for the
customers if ODF gathers momentum from sales and if that takes longer
because of OOXML, that is the price of preserving the institutions that
enable choice.  The customers don't need a Pyrrhic victory and the companies
insisting on that may be damaging themselves in the long run.   Keep up the
technical review, get to the meetings, and fight the good fight by all
means, but let's drop the charges made with proof, the allegations based on
appearances, and let the chips fall.  

>So should there be a standard for each vendor's proprietary formats, or 
>just for Microsoft's? In an ideal world, there would be one standard 
>format, and all vendors would support it, eliminating the cost of 
>proprietary conversions.

Should there be only one reliable messaging standard?  Should there be only
one hypertext language (kiss of topic containers; HTML is King)?  Should
there be only one query language?  Should there be only one size of condom?

If MS opens it up, it quits being proprietary.  When Sun opened up their
office suite, it became ODF.  Adoption is the key but no can adopt a baby
strangled in the crib, nor will any one adopt one that is still born.  So
let the customers and the implementers choose.

Realistically, these formats are both dodos.   I spend a lot of time working
in databases and that spit out reports.  For me, neither one of these is a
good choice and both are if a customer requires them, but I have to send
them a bill.  Otherwise, I choose HTML tables and PDF both of which can be
imported into a spreadsheet and neither of which punishes my customer for
choosing unwisely.

len
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.