“
Any effort to standardize a document format needs to consider long-term document storage and retrieval. For this, the standard needs to be fully self-documented. It must be possible to decipher documents 10, 100, or 1000 years in the future without reference to the source code of an existing software implementation.

Alternatively, perhaps a copy of Office 2007 could be chiselled into rock to become a kind of Rosetta Stone for future generations.”

trully insightful IMHO

That is why you have versioning.
Ecma could just bring out a 1.1 version similar to ODF has done.

Microsoft can stay on OOXML version 1.0 until their first service pack.

I think it is probably commitment to making such changes in future versions that ISO national bodies would want to see in Ecma !!!

Now ECMA has ratified the ECMA 376 file format as being necessarily, by definition, compatible with MS Office 2k7′s MS Office Open XML file format.

And Microsoft has released the MS Office 2k7 to the public, so Microsoft is not in fact in any position to change anything dramatically. Nor is ECMA, as a result.

This constitutes a logic bomb of truly interesting – as in the benison/curse “May you live in interesting times” – dimensions. If ECMA TC45 were to bend to public demands, and alter the ECMA 376 standard to answer the criticisms, it would no longer be operating according to its charter. It would be making its standard incompatible with MS Office 2k7′s file format.

And Microsoft it seems, is not interested in correcting its Office 2k7 to conform with a revised ECMA 376.

And some of those JTC objections are truly showstoppers.

Ever seen a car upside down, wheels spinning helplessly? Remember that while you watch Microsoft doing battle with the international standardization organization. In operating system studies the situation is what is called a race condition.

Dobra chut, Microsoft! Bon appetite!

Wesley Parish

Warren Buffett had a nice story he told, about trying to predict the winner of a beauty contest. (He was really talking about picking stocks, of course, using this as an analogy) The trick, he said, was not to spend all your time looking at the pretty girls and trying to determine which one was the best looking. The trick to predicting a winner was to look at the judges. Are they all middle age men, nuns from the local Catholic school, frat boys, etc? Knowing the preferences and inclinations of the judges is more important that knowing your own personal preferences.

The point of this post was to point out that the judges in this beauty contest have demonstrated that they do not like it when their contradiction arguments are ignored.

What need especially? A format for new Office documents, but thats ODF too. A conversion format for legacy documents, but ACME376 can do that all 100%, round trip.

Can OOXML2007 do 100% round trip fidelity with older formats? Difficult to say, as OOXML leaves crucial information unspecified. Can anyone outside MS do 100% round trip fidelity between older Office documents and OOXML. Certainly NOT.

But this last fact is the real point. OOXML is MS’ format, and MS alone can really use it.

“I think there is room for two formats. ODF still has a lot to prove.”

Like in Austria, where they experimented during the war with driving simultaneously on the left side of the road (Austrian civilians) and on the right side of the road (German tanks). Free choice of standards indeed.

And ODF should prove what? That it is usable and has real world applications?

OOXML should first prove that it can be implemented at all, instead of evolving once out of a gigantic mountain of software.

Rob

But I guess it might still come to some solution on that particular point because it seems fairly easy if that issue were the big hurdle for ISO at the end of the Fasttrack process to then have Ecma alter the date issue in an amendment or in a future version and make this leap year format obsolete from then on.

These (minor) issues are all resolvable if needed.
The only real issue that might stay is whether ISO should standardize this format next to the OpenDocument format. I think they should approve the OOXML format because OOXML supports a different need than ODF. A different market requirement as Rick Jelliffe calls it.

I think there is room for two formats. ODF still has a lot to prove. That is not a format for now but mayby for the future. For now the market would like compatibility an reliability which just seems more likely to come from OOXML with it’s likely huge marketbase.

There are people who believe that crop circles are messages from aliens, that the earth is flat and that man never landed on the moon. But I have never heard even the most deluded person maintain that the year 1900 was a leap year.

Microsoft can get this right in their product while preserving interoperability with legacy documents. I and others have given several ways in which this could be done. They have smart engineers. I’m sure they can think of other ways of getting this right as well. Will it required writing some code? Yes. Will it take some processor cycles. Yes, probably an “if” statement. But compared to all the code and CPU cycles Microsoft has wasted giving us eye candy like the translucent 3D windows in Vista, this will be minuscule.

But instead of working on a solution they expect everyone else in the world to adapt their code to Excel’s bug.

“I do not think that the national bodies have done much research yet. It seems mostly they copied a lot of the raised issues from here or Groklaw.”

Well, there are at least three counter-points to that, so I don’t think it makes the case you want it to:

A) That means this shouldn’t even be on the fast-track to begin with because no one could properly review a 6,000 page standard in that amount of time.

B) Even with limited amounts of time, they all came up with many of the same obvious objections. Contrary to what you say, I sincerely doubt they’re copying things from here or Groklaw. Rather, it speaks volumes if that many people in that little time all agree that a few specific issues are real problems.

C) Now suppose they _did_ copy the objections from Groklaw or another source (I don’t buy that, but just for the sake of argument). If they copied it, they agreed that it was, in fact, a problem. Otherwise, why object? Microsoft has a lot to lose here, but what do these bureaucrats have to gain, exactly? Do you picture them saying “Yay! We just pissed off Microsoft! I bet that’ll go over great during our next BSA licensing audit!” or what?

However I still would like to see how ODF is going to handle ISO dates in spreadsheet formulas. Things like timezones and duration which make ISO dates different from a numerical date format are not commenly used in spreadsheets nowadays and I wonder how that will work out in it’s implementations. That is not straightforward.

Also, have a do1900LikeExcel setting, similar to the other backwards compatibility options OOXML has. Set it to true for spreadsheets which are converted to OOXML from legacy XSL files. Microsoft could continue to set it to true for new Excel documents as well if they wanted. But other implementations could set it to false.

Although I think it is bad practice to load up a standard with backwards compatibility options that consider a single vendor’s needs only (what if 1-2-3 or Quattro Pro have other backwards compatibility needs?), it is a further insult to require that other vendors adopt the same bugs that Excel has.

Let Excel do what Excel needs to do, but also let other vendors do it right. Welcome to the 16th Century, Microsoft. We calculate leap years differently now.

Contrary to what you imply, “[i]nsisting on limiting spreadsheet dates to post 1899″ or some other recent date is not grounds for objection. It is NECESSARY.

Why? Because the human calendar itself is full of workarounds bizarre tinkering, including:
- leap years
- leap seconds
- daylight savings time (which varies according to locality and year)
- missing days; see http://www.genealogytoday.com/columns/everyday/030902.html and http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates

ECMA rejected each and every comment. The overlap with ODF and the uncertainties about the IP are already each reasons to reject ECMA376. ISO guidelines specifically state that ALL known patents relevant to a standard should be disclosed. MS have disclosed NO patents at all (at least not publically). But MS have always insisted that there are such patents (but they might not sue, maybe, see the

Open Malaysia blog, MS’ legal councel couldn’t tell)

Especially the refusal to do anything about the Excel date horror is a howler. If MS would just say to switch to a Julian day calendar and add a conversion in Office 2007, they would have shown the world that they want to listen, without any fundamental changes.

Insisting on limiting spreadsheet dates to post 1899 AND standardizing an incorrect day count + two other date formats (post 1904 and the Word format) is such an easy target.

But I remember that you had a VERY long argument on Groklaw about this.
(see

EOXML unanswered questions thread, you are hAl, aren’t you?). You admitted to not being a programmer, however you ignored every counter-argument brought forward by people who DID have experience in programming.

Also, saying that the world lobbies for ODF and MS for ECMA376 should make you realize how the world views ODF vs. ECMA376. Or not? Or has the world a duty to give MS their own standard?

Winter

I think the national bodies should probably look at the specs a bit better and also verify the answers given by Ecma with serious experts.

I can see only some of the issues raised by you and others stay on the table. These however might not be considered important enough to raise issue with the format as a whole. Also I think Ecma can if needed show some commitment in improving areas that might worry the ISO national bodies. Ecma could promise a 1.1 version before the end of the year to address left over issues. That would be simular to ODF addressing several issues in it’s spec after standardization.

Things I think can improve is deprecating the leftover bitmasks and removing VML from the spec. Also improving certain explanations for deprecated features in section 2.15 and mayby state that on those elements for full confomance it is enough to inform the consumer that original rendering might not be available.

I don’t think it is necessary for Microsoft to get an outright majority in an NB to influence the vote. It is more complex than that. Most NB’s work on some sort of consensus voting procedure, where 2/3 or maybe even a 90% vote is required to recommend a position. Increasing Microsoft’s participation in a NB could possibly turn a “No” vote into an “Abstain” by preventing a consensus, even if a clear majority supported a “No” vote. That is my understanding of what happened in several NB’s during the contradiction period.

Of course, this works both ways. Lack of consensus can prevent a majority supporting OOXML from registering a “Yes” vote, and instead abstaining. But every NB that abstains increases the chance of OOXML failing for lacking a 50% participation rate among JTC1 P-Members. So you really need to persuade your opponents to agree with you, not just deadlock them and force them to abstain.

So I think that this will end up like this: NB’s without a consensus will abstain, and only those P-Members with strong (> 2/3) opinions one way or the other will cast votes. That is why I see OOXML’s odds as very slim at this point.

To win they need:

1) 50% or more of P-Members must vote. So if too many abstain for lack of consensus, then OOXML fails.

2) 2/3 of voting P-Members(those who did not abstain) must vote “Yes”. As mentioned earlier, this often requires a 2/3 consensus in the individual NB’s.

3) No more than 25% of all votes cast can be negative. This includes possible votes from the entire community of 150 or so ISO nations. Note that no number of “Yes” votes from the general membership can cause OOXML to pass. Only the P-Member vote can pass the ballot. But the general membership has effective veto power over the P-Members if a sufficient number of the general membership votes against OOXML.

I’m not saying it is impossible for OOXML to pass. But when I look at the numbers, and look at the lack of enthusiasm for this standard, as indicated by the NB contradiction arguments, and look at recent history, then I am unable to find a winning play for Microsoft here. Although they can increase participation in NB’s, I think that only helps them get abstains, but that is a double-edged sword because of the 50% participation requirement.

I’d be interesting to hear if anyone sees this in a more optimistic way. What reasonable prospects do they have of getting a consensus “Yes” vote out of 2/3 of JTC1 P-Members?

Winters suggestion that MS employees could influence the ISO committee seem therefor very far fetched. If anything it could be the other way.

“
Results about the study of Open Document exchange formats:

Conformance testing and document validation possibilities
*are needed* -> in order to facilitate mapping / conversion;
“

[1] http://www.openforumeurope.org/index.php?option=com_content&task=view&id=937&Itemid=1