RE: Microsoft buys the Swedish vote on OOXML?
>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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format