What are the next official procedures, in both scenarios ? No matter what the result is, what can we do to ease the OpenDocument Format adoption, as soon as possible, to make it a de facto standard as well ?
From current figures it looks like OOXML has lost round 1: 80 countries voted, 21 abstained. That leaves 69. 51 of those voted in favour of Microsoft, and 18 voted against. (These are our estimates, some figures are not yet released). That means OOXML loses by a single vote.
This fight has three rounds:
- Round 1: does ISO fast-track OOXML? Microsoft won round 1.
- Round 2: ISO vote on OOXML. Microsoft seems to have lost round 2. (But personally I'm still expecting a surprise)
- Round 3: ISO ballot resolution meeting, 25-29 February 2008.
The votes from Round 2 are not final. So we don't have a result, just a position of play. The game goes on…
What is the next official procedure? ISO organises a meeting on the week 25-29 February 2008 and countries come back to the table to come to agreement.
What can we do?
- Continue the work of organising local groups to help governments understand why open standards are good and OOXML is not.
- Continue to promote ODF in government, education, and business.
That means OOXML loses by a single vote.
Good to hear that OOXML failed to attract a 75% majority in the total vote as well, but that is only half of the criterion. There is a recent entry on Andy Updegrove's blog outlining the voting procedure in a kind of flowchart. Here's the gist of it, slightly edited:
1: Count all P votes cast, and determine whether at least 50% of P members have voted.
If yes, then proceed to 2.
If no, then the vote fails.
2: Subtract all abstentions (in other words, throw them out).
3: Determine whether 2/3 of the remaining P votes are to approve.
If no, then the vote fails.
If yes, then go to 4.
4: Determine whether 25% or more of the total votes cast by both P and O members are "No" votes.
If yes, then the vote fails.
If no, then the vote passes.
The OOXML vote failed quite big already on step 3, and would have failed more narrowly at step 4.
After the vote has failed, this is what happens, once again according to Andy Updegrove, with some slight edits by me:
5: The ballots and comments will be sent to the Chair of SC 34, to Ecma and to all JTC1 members.
6: The project editor at Ecma and Microsoft have until January 14 to come up with their suggestions for how to resolve the comments. Those suggestions can be to ignore or to address any given comment, and if the latter, how to address it. The JTC1 members will have about six weeks to review those recommendations before the ballot resolution meeting convenes on February 25.
7: SC 34 reviews the suggestions, and forms its opinion on what should be done with each comment. One task would be to determine whether some issues are "irresolvable."
If yes, then cancel the ballot resolution meeting, and the process ends.
If no, then consider how to resolve issues.
8: The ballot resolution meeting is held. If the initial vote was to approve, then the process completes with the agreement on which comments should be accommodated. If the initial vote was no, then the question is whether enough comments can be resolved to the satisfaction of those that voted no.
9: If necessary, revote. And note: if there is a revote, it will be of all P members at that time, not the P members at the time of the original vote. This is a final loophole in the process that we might see exploited.
The same voting rules apply for the re-vote as for the original vote (steps 1-4 above). Members who are not present at the ballot resolution meeting will keep their vote from the September 2 ballot. Members who voted "no" are obliged to attend, but anyone else is also allowed to show up and cast a new vote. If the second vote fails, the process is terminated and DIS 29500 does not proceed to the next step. If the vote passes, a final draft FDIS 29500 will be prepared and sent out for a brief review and consideration by ISO members. A ballot is then issued for approval of the FDIS, to make the FDIS a formal ISO standard.
Note that any ISO member may change its vote from now until February, including those who abstained this time. The normal procedure is to change a "no" to a "yes" because comments have been resolved, but the opposite is also possible, changing a "yes" to a "no". While this is highly irregular and defeats the purpose of a normal standards process, nothing is impossible in this already highly irregular process. There is a possibility for countries who were tricked into voting "yes with comments" to change their vote to "no" if their comments are not addressed to their satisfaction. This is a compelling reason for ECMA to address even the comments submitted with a "yes" vote, and it adds substantially to the workload of the comment resolution process. Let's see if they can make it, they have a lot of work ahead!
If the vote passes, a final draft FDIS 29500 will be prepared
and sent out for a brief review and consideration by
ISO members. A ballot is then issued for approval of the FDIS,
to make the FDIS a formal ISO standard
That is incorrect. In fasttracking a DIS that is approved is altered based on ballot resolution approved edits and will then be published as an IS. There is no need for a final draft as the approval is on the DIS+approved edits.
DIS => DIS+approved edits (BRM) => IS
Note that step 7 is an important step as well.
By that time a lot of minor issues will be resolved
It is likely that SC34 will then form opinion on quite a lot of the more important remaining issues.
A national body would have a hard time explaining if they vote NO during the ballot resolution meeting because of an issue after an official ISO committee has determined on that it satisfies ISO criteria (for instance the licensing or a perceived conflict with ISO 26300).
A national body would have a hard time explaining if they vote NO during the ballot resolution meeting
National bodies do not have to explain themselves to ISO. They may have to explain themselves to the people in their country, but in the final vote within ISO, they can vote "yes" or "no" for any reason without stating it to ISO. The decision is with the NB committees, and they are not always obliged to publish anything except their final decision: "yes" or "no". It might not be a smart move to keep a lid on your reasons if you want to maintain your credibility, but it is possible. That is one of the fundamental problems with this process. Microsoft can keep stuffing the committees to achieve a crushing majority in countries where the committees are open to new participants, and thus change most "no" votes to a "yes" without any actual changes being made to the standard. I fear this is what is going to happen.
I think we could also see several benevolent but critical "yes" votes being swayed to "no" if the ugly behavior on Microsoft's behalf continues. Perhaps even some of the blind "yes" voters will read up on what they are agreeing to and decide to disagree in February. In fact, I think we should explain to some of the NBs what standards work really means, and have them shape up from following the lead of a strong lobby to become well-informed voters with an opinion of their own.
I certainly think Microsoft can buy their way to an approval in February. They must have counted on that this was not their last chance to force the vote in their favor, otherwise they would have bought more P members to vote "yes" and thrown their weight around even more. Remember, this is ultimately about selling (even forcing) MS Office upgrades on existing customers, and without that Microsoft is in deep trouble. I do not think that they made a fatal miscalculation, just that they tried to save some effort this first time around. February is the real vote. This was just a start, and there is a bumpy road ahead of us still.
The question now, I think, is if MS really wants to be more ugly than it already has been. Given the strongly negative publicity they have been receiving lately, it might hurt them so bad they won't be able to spin their way out of it. While the general public has a very short attention span and is easily fooled by shiny press releases, spin doctors and distractions, there is a factor here which has been at the heart of the problem all along: programmers.
Any software product is built by programmers, but free software is built around programmers in a free and open exchange of ideas and work among developers. Looking from the outside, Microsoft is a large but rather less exciting closed-development environment with products that are starting to slip in terms of performance and quality. Microsoft still needs to recruit a lot of good programmers to function, but they simply must be experiencing some drop in popularity among technically skilled and well informed people as a result of the OOXML scandal. I wonder whether they will be able to recruit any programmers at all if they go ahead with their "ugly" plan. Programmers, unlike the general public, tend to be technically skilled and be able to see through most marketing smoke-screens, and they are prone to follow the free software and open source debates quite closely. Clearly, the current generation of students are much more aware of free software than students from ten years ago. They also tend to be more perceptive of ethics and political standpoints and less focused on making big money. I might be oversensitive to these things because I work at a university, but there is definitely a recent trend to be spotted here.
So, to conclude, for Microsoft's own well being, I hope they have a "nice" plan to go from here, or else we will see a lot more irregularities around the ballot resolution meeting in February, and a possible demise of Microsoft because they can no longer pretend to be anything but evil. I would hate to see the first, but I would not really shed any tears if it came to the second because of that.
Back to my original question, what do you think is to be done to accelerate the ODF adoption and to transform it in a de facto standard ?
For example:
- what significant applications on the market should support ODF to contribute to its wider adoption?
- what can we do to ease ODF usage in Microsoft Office (smooth converters) ?
- can we get a simple procedure & reliable tools to convert thousands of Microsoft files in ODF, in complex directory structures ?
- is it possible to create filters (amavisd-new plugins comes to mind) that will transform Microsoft e-mail attachements, on the fly, in ODF form - at server level ?
On the standardization process, what can we practically do in the "red areas" of the map, until February ? In small countries like Romania, is it possible to aggregate the pro-ODF lobby around IBM or Sun local representatives ?
there isn't a lot we can do to push adoption of odf at the minute apart for pressuring governments into using open document types. the doc format type is king at the minute and there is no 100% way to convert it to odf.
I know it sounds crazy but the best thing we can do at the minute is write software that supports ooxml. [http://blogs.sun.com/GullFOSS/entry/office_open_xml_ooxml_filters]
I think it would indeed be a little crazy to engage in a broad and general effort to write software that supports OOXML right now, for several reasons.
The spec is very likely to change in the upcoming months, which would motivate that we wait and see what happens. Any effort spent on supporting e.g. VML with an independent implementation would possibly be rendered useless if VML is removed from OOXML, as many comments have suggested.
The spec is also currently much too large and under-specified for any useful implementation to be based on it. We would need to look at how MS Office does it, and that is not a sound base for an implementation, as Office 2007 is likely to change soon if the OOXML draft changes to address comments before February.
I think we would be side-tracked by starting to support OOXML before it is even finished. We have better things to do with our time than take shots at a currently moving target with an unknown future.
There is already a reasonable way of converting old .doc files to ODF. Sure, everything is not carried over when you open an MS Word binary file in OpenOffice.org Writer, but we could work on improving that. That would mean a direct upgrade path from a .doc lock-in situation to an open ODF use.
We should take the opportunity to market OpenOffice.org and friends now, when people are about to decide on a purchase of MS Office 2007 and need to retrain to a new user interface and a new document format anyway.
We could also demonstrate the same kind of document-processing applications as have been advertised for OOXML using ODF. Because the ODF format is so much more clean, the effort of doing this kind of XML processing on ODF would actually be easier than to do it using OOXML, even without the assistance of Microsoft's custom APIs to process OOXML data. I think this is the wisest way to go from here in the short term: integrate ODF documents in real work flows to show that it is a contender in professional publishing and document handling systems. It is not enough to show that OpenOffice.org is a good replacement for MS Office on the desktop and that ODF is a way to migrate a million individual MS Word documents stored on a disk. People want to do more with their document base, and MS marketing is currently focusing on that. It would be wise to ride on that wave and increase the usefulness of ODF in the big picture.
ODF is XML. It's meant to be parsed by software and filtered in all sorts of ways. I think we need to do that more!
(I know many people are already doing this, but we are still too few.)
My take is such:
1. Microsoft Office 2000/XP/Vista should able to read and write ODF at some part. Full support is not required, just basic stuff;
2. OpenOffice.org already has AutoPilot who will help you with converting. If some Microsoft Office filter is better, then we can create application on that;
3. It is possible to create such converters, however, their practical value is questionable;
Personally I think that biggest ODF killer point is it's compatiblity with lot of various W3C and ISO stuff. OpenOffice.org is just one application who uses this format. Also companies with ODF support in their products should perfect their compatiblity with other such software.
I think ODF acceptance as ISO format and OOXML strugle to be accepted has given golden opportunity here. Not as recomended format, but as been shown
I personally think that a mapping between ODF, the problematic OOXML and the proprietary binary DOC,XLS, etc formats would be extremely difficult. However, here are some pointers that might ease the (impossible?) process:
1) http://support.microsoft.com/kb/840817/en-us#
Royalty-Free File Format Programs
Microsoft Office Binary File Formats
Microsoft makes its .doc, .xls, and .ppt binary file format specifications available under a royalty-free covenant not to sue to anyone who wishes to implement all or part of these specifications in their products. Implementation includes the ability to use the specification documentation for analysis and forensic reference purposes. Microsoft Office Drawing File Format for 2007 and Visual Basic for Applications (VBA) File Format for 2007 are also available under this program.
The documentation that covers the binary file format specifications is cumulative and covers the most current form of the binary file formats as well as earlier versions. If you want to receive the documentation, contact Microsoft at the following e-mail address to initiate the agreement sign-up process:
moc.tfosorcim|ffeciffo#moc.tfosorcim|ffeciffo (mailto:officeff@microsoft.com)
When you write to Microsoft, provide the following information:
• The specific file format specifications that you are interested in
• Your company or agency name
• Your mailing address
• Your city
• Your state or province
• Your zip code or postal code
• Your country
• A contact name
• A contact title
• A contact telephone number
To view the terms of the Microsoft Office 2007 Binary File Format Documentation Agreement, visit the following Microsoft Web site:
http://download.microsoft.com/download/5/f/7/5f7874d9-8598-467b-8462-9603ec5d4bea/Office Binary Format License Agreement 2007.pdf
—
-
2) from Doug Mahugh, Microsoft (and OOXML) evangelist blogger:
http://blogs.msdn.com/dmahugh/archive/2007/08/30/oh-the-drama-of-it-all.aspx
- Antoin O Lachtnain said on September 1, 2007 2:22 PM:
Is there a mapping between the binary file formats and the OOXML formats? That would be very useful.
- dmahugh said on September 3, 2007 6:18 PM:
@Antoin, I don't know of such a mapping. The concept has been much discussed, but I think an even more useful mapping for the future will be one between Open XML and ODF, as DIN has started organizing a group to work on: http://www.fokus.fraunhofer.de/fokus/fokus/presse/meldungen_fokus/2007/05/DIN-E.pdf
EDIT: This post was misinformed because my information was out of date, and I sincerely apologize for that. I'll leave my bad behavior here for people to see it, but please don't believe what I said here. It's relevant only as a historical note. Sorry.
Unless things have changed for the better lately, the agreement you need to sign with Microsoft to get the documentation for the .doc format includes a clause where you waive your rights to create "competing software" to read and write .doc files. Also, any work performed under that agreement may not be published in any open source context.
This is not what we want, as anyone signing that agreement would no longer be able to work on .doc support in OpenOffice.org, or to release any source code. Microsoft has their back covered to keep a lock-in. All the functionality in OpenOffice.org to read and write .doc files is the result of tedious and difficult reverse engineering efforts. If I remember correctly, some early version of the Office 97 or Office 95 file format specification was openly available from Microsoft without any strings attached, until they changed their mind and retracted it from public view. This was the subject of a famous memo from Bill Gates, stating that "to me, it seems stupid to give out information on our file formats". I forget the exact quote, and I have no link now, but you should be able to find it. It's an old quote, and I am not saying it constitutes any evidence for Microsoft's current business practice, but that is the last we heard of any open documentation on the .doc format.
As a reference top the license agreement is clearly stated in the previous post you are clearly wonrg.
I wonder why you even post your reaction completly opposite to the MS license agreement that is link in the post you are reacting on ?? are you unwilling to open a link and read it or are you just trying to spread FUD ????
Sorry, my bad. I was very sloppy with checking the facts before my response, and I apologize for that. Things have indeed changed for the better recently, it seems. I was indeed spreading FUD all over the place, and you only have my word for it that it was unintentional. I'll try be more attentive and less backward-looking henceforth. (This is the future, I keep forgetting that. But I'm an old fart.)
If the full specification is now available, then I guess we might soon see even more features of .doc files supported by OpenOffice.org. Has anyone here seen this spec and can comment on it? I suppose it is even more huge and difficult to read than ECMA-376, but really, how bad can it be? Interestingly enough, it says in the agreement that the licensee is allowed to make copies free of charge, and it does not seem to limit the distribution of such copies to a third party, even though that third party would not be allowed to make further copies. If I am not seeking patent coverage because I only want to read the spec, not implement it myself, can I find it somewhere?
When one have 3 Microsoft documents or 100, it is possible to convert them using the actual converter included in OpenOffice.org.
But when you have a few thousands, burried in complex directory structures and you want to convert them - without data loss, i.e. excluding the ones that contain VBA or such - the task is not so simple. Or there are Pivot Tables with external data sources, which are hardly usable In OpenOffice.org because of their slowliness. You must exclude then from conversion, too.
So a more flexible and fast tool is needed, usable in command line as well as in GUI. And one don't have to install the full OpenOffice.org suite just to mass-migrate documents. IMHO, basic "pair" utilities like unix2dos and dos2unix are needed.
I also think that a mail-server filter, to convert attachements on the fly, would enormously help.
The *easiest* way is to pass directly from binary formats directly to ODF, just by improving quickly the tools we already have.
Can we do something to address this on a very short term, much shorter than February ?
Regards,
Răzvan
Răzvan, my advice is that you take this suggestion to the good people developing OpenOffice.org. They would probably agree that this is a nice idea, and they would also know their way around the source code well enough to create such a tool in a very short time. If all it takes is a command-line utility that returns an error or OK status depending on whether the conversion encountered unknown or unsupported data chunks, I think this is more or less a no-brainer. I haven't actually looked at the code base for OpenOffice.org, but I assume it is reasonably modular and well written. Then this should be a fairly easy programming task, and the tool could easily be merged with the OpenOffice.org distribution.
EDIT: Such software is already available. Look here for lots of links, I'm sure some of these solve your problem.
http://en.wikipedia.org/wiki/OpenDocument_software#Programmatic_support.2C_filters.2C_converters