Only fools rush in

by jlundstocholm 28. May 2008 02:24

In the past weeks the OOXML-battleground has been covered with buzz, rumours, and innuendo about the missing IS 29500. Rob kicked it off with him revealing the little secret that he was actually in posession of a preliminary edition of the not-yet published final text.

Today I was told that ITTF was frantically (my interpretation) rushing to get the text done and have it published.

That scares me a bit.

When ITTF/IEC publishes IS29500 - that will be the IS29500 we will use in the foreseeable future. Yes, there will likely be an errata-sheet, but that is the edtion we're gonna use. Rushing to finish it could impose errors in the text (yes, I am aware of the irony).

So dear ITTF, please take your time to finish putting the spec together - there is no rush. ODF was approved on May 8th 2006 and was not published until November 30th the same year. That is more than 6 months from approval to publication. Granted, there are differences between the ODF-case and the OOXML-case. ODF was not changed during the approval-phase of ISO whereas substantial changes were made to OOXML. Never the less, I would much rather wait another month to have it done right.

At least we are all equal here - it is to the advantage of no single perty to have publication delayed ... so shouldn't we wait until it is ready? 

Comments

5/28/2008 4:03:20 AM #

Luc Bollen

Jesper, the version due by ITTF since 29-Mar-08 (yes, nearly 2 months late yet) is not the version to be published.  It is the text submitted by Ecma in Dec-06, with the editorial instructions of the BRM being applied.  This text is to be distributed to the NBs only.

Once this "draft" version will be available, ITTF will have something like 6 additional months (as it was the case for ISO 26300) for preparing the version to be published and made available to the general public.

There is indeed no reason to rush the second version.  But the first one should be distributed ASAP to the NBs, in its current state, as mandated by the JTC1 directives.

Unless the text provided to ITTF on 29-Mar-08 by the project editor is so bad, due to the huge size of the document and the poor job done during the BRM to have clear and coherent editing instructions, that it is not worth to distribute it...  But if this is the case, I see no way out, except maybe to take the opportunity of the South African appeal to cancel the whole project ?

Luc Bollen Belgium |

5/28/2008 4:13:39 AM #

orlando_ombzzz

"Today I was told that ITTF was frantically (my interpretation) rushing to get the text done and have it published. "

translating: ITTF == Brian Jones

you are welcome

orlando

orlando_ombzzz United States |

5/28/2008 5:08:03 AM #

jlundstocholm

Hi Luc,

Thanks for your comment,

My point of this post was not to discuss the directives nor the lateness of the text from ITTF. I think we all agree that we want the text released ASAP (ASAP is not the same as "now").

However - I am worried that ITTF will be under so much political pressure to release the preliminary text that errors will be made. This is why I'd prefer not to rush in but to do the job properly - the first time.

Smile

jlundstocholm Denmark |

5/28/2008 6:08:32 AM #

jlundstocholm

Luc,

One other thing: you said:

the version due by ITTF since 29-Mar-08 (yes, nearly 2 months late yet) is not the version to be published. It is the text submitted by Ecma in Dec-06, with the editorial instructions of the BRM being applied. This text is to be distributed to the NBs only.

Which part of the JTC1-directives are you referring to? As I scrolled through the directives myself, I didn't immediately find it.

Thanks,

Smile

/Jesper

jlundstocholm Denmark |

5/28/2008 6:28:38 AM #

Jirka Kosek

After my recent communication with ITTF I think the problem is that ITTF interprets JTC1 directives in the different way then at least some NBs. In section 13.12 there is written:

"The time period for post ballot activities by the respective responsible parties shall be as follows: ... In not more than one month after the ballot resolution group meeting the SC Secretariat shall distribute the final report of the meeting and final DIS text in case of acceptance."

and in section 13.9 there is:

"If, after the deliberations of this ballot resolution group, the requirements of 9.6 are met, the Project Editor shall prepare the revised DIS (or DAM) and send it to the SC Secretariat who shall forward it to the ITTF for publication as an IS."

ITTF thinks that "final DIS text" is the same as international standard for publication, while me (and many other people) thinks that "final DIS text" is text send by editor to ITTF for publication as international standard.

I agree with you that it is usual and reasonable to spent several months by preparing for publication, but I strongly disagree with ITTF that there is no text to distribute to NB before standard is finaly prepared for publication.

I don't expect that ISO/IEC 29500 will be published before autumn this year. But how then maintenance should be performed if NBs do not have access to the text of standard (note that ITTF can't change anything substantial during publication process, they can do just basic copy-edit)?

Jirka

Jirka Kosek |

5/28/2008 10:27:02 AM #

Luc Bollen

Jesper,  Jirka provides the references from the JTC1 Directives in his comment above.  I have the same reading as him: within one month after the BRM, the project editor must send the modified text to the SC secretariat, who distributes it to the NBs for information, and send it to ITTF who will spend a few months to put it in the correct format for publication.

During the time needed to technically prepare and format the text for publication, the NBs can check if the project editor correctly incorporated the instructions from the BRM, and have the text corrected if errors made by the project editor are found.

It seems very unusual that the project editor's modified text is not distributed to the NBs before publication.  Many people suspect, as Rob Weir and SABS commented, that the delay is due to the fact that the Fast Track process is not meant for texts that are 6000 pages long, with some 1000 editorial changes to be implemented.

I would say that only fools rush such an immature 6000 pages text through a Fast Track process.  Since Dec-06, I saw Microsoft frantically rushing to get the text approved by ISO and have it published, and it scared me a lot.  Many people recommended that Microsoft takes his time to finish putting the spec together because there was no rush... It is unfortunate that some people understand the problem so late in the process.

So, Microsoft, Ecma and ITTF decided that they wanted to have the Fast Track rules applied to OOXML, until they understood that it was not possible.  And then ITTF had to change on the fly many of the Fast Track rules so that the process can continue in a hurry (see the SABS appeal for details).  Sigh...

Luc Bollen Belgium |

5/28/2008 5:17:00 PM #

jlundstocholm

Jirka,

Did ITTF indicate if they were preparing a initial text for the NSBs or if they were working on the final IS already?

jlundstocholm Denmark |

5/28/2008 6:06:32 PM #

Jirka Kosek

ITTF is working on the final IS already. ECMA sent amended DIS to ITTF around end of March. Please find below quotation from email from ITTF:

"...The text which is to be delivered
to the subcommittee, as I have explained, is intended for the
subcommittee's maintenance responsibility, and is the text of the standard
as it will be published.  When that is available it will be provided..."

Jirka Kosek |

5/28/2008 6:28:35 PM #

jlundstocholm

Hi Jirka,

Thank you ... Smile

jlundstocholm Denmark |

5/28/2008 7:38:16 PM #

Rick Jelliffe

Don't forget that according to JTC1 Directives, clause 1.2, procedures such as time limits can be varied with permission of the Secretaries-General.  

If there are reasonable production reasons ITTF, I would expect the Secretaries-General to allow any variations.  I expect every NB that voted "accept" would also demand it. The purpose of these time limits are to make sure a standard gets produced, not to prevent its production.

Rick Jelliffe Australia |

5/28/2008 8:44:19 PM #

Luc Bollen

@Jesper: "Did ITTF indicate if they were preparing a initial text for the NSBs or if they were working on the final IS already?"
According to the JTC1 Directives, it is not the task of ITTF to prepare the initial text for the NBs.  This is the task of the project editor.  So it is logical that ITTF is working on the text as it will be published.  What is unusual is that the initial text produced by the project editor is not distributed.  This initial text IS available, otherwise ITTF could not work currently.  It would be interesting that ITTF explains why they don't want it to be distributed to the NBs.

@Rick: I agree with you about the time limits.  The decision (of the Secretaries-General ?) to impose a time limit of 5 days for the BRM made more harm than good, so it is surely good to allow enough time for preparing the final text.   However, it is ironic that you comment that applying the normal Fast Track time limits would prevent the production of ISO 29500.

There was indeed a simple, less controversial way to provide enough time to make sure a (good) standard gets produced : go via the normal path rather than via the Fast Track.  What you and Jesper are saying now is exactly what several NBs (and many other people) said 18 months ago: the normal time limits of the Fast Track process does not allow to correctly handle such a long text.

This said, note that there is nowhere in the JTC1 Directives a time limit imposed on ITTF for doing its job.  And it was said several time, by several people, that the project editor performed his work and delivered his text within the time limit of one month.  So the variation allowed here is not about a time limit.  It is about not distributing the available project editor's text to the NBs.

My deduction is that this is because the project editor's text was of an unacceptably low quality.  So, ITTF is currently helping the project editor to improve the quality of its text.   Do you have a better explanation?

Luc Bollen Belgium |

5/28/2008 9:02:40 PM #

jlundstocholm

Luc,

go via the normal path rather than via the Fast Track.

I don't see that as a viable solution. There is good reason that ODF and OOXML both went through the speed-aisles of JTC1 - the specs would have been obsolete the time they appeared on the other side.

Also, when I wrote this article, I knew that someone would yell "hypocricy" and "This is what we have been saying all along". However, I see no implicit correlation between me saying "please don't rush" while saying that the Fast-track procedure of JTC1 provided enough time to examine the text.

this is because the project editor's text was of an unacceptably low quality. So, ITTF is currently helping the project editor to improve the quality of its text. Do you have a better explanation?

I don't know if it is better, but a reason could simply be this:

Combine the size of the text with an angry, trigger-happy blog-mob just waiting to point out errors in the text and use these to further beat on ISO/IEC.

I'd personally make sure, that I got it right the first time.

Smile

jlundstocholm Denmark |

5/28/2008 11:09:23 PM #

Luc Bollen

Jesper, please note that I've not at all yelled "hypocrisy", and I don't intent to do it.  I just noticed that you now agree with one thing that other people said before: if you want to do things correctly, you need to have enough time.

About your explanation for the delay: if it is as simple as this, ISO/IEC should have made an announcement to the NBs stating this a long time ago.  It would have avoided angry, trigger-happy blog-mob members like me to scratch their head trying to invent horror stories.

Luc Bollen |

5/28/2008 11:30:30 PM #

jlundstocholm

Luc,

Jesper, please note that I've not at all yelled "hypocrisy", and I don't intent to do it.

No offense taken, my comment was not directed at you Smile

It would have avoided angry, trigger-happy blog-mob members like me to scratch their head trying to invent horror stories.

Well, I was simply guessing at the reason for the delay. One of the things that differ in OOXML with respect to ODF-comparison, is that ITTF was asked at the BRM (as far as I remember) to make sure that all modal verbs in the specification were on-par with the ISO-standard way of doing it. It's the "should, shall, must, may"-controversy revisited. This is actually not a requirement for Fast-Track nor PAS-submissions. It is generally considered "ok" to wait until next revision of the submitted standard to be brought into "ISO-format conformance". According to the odf-tc mail list, the guys at OASIS ODF TC are struggling with this as we speak. That task alone should take quite a while for a 6000 pages specification. Note that this has nothing to do with the quality of OOXML but with a requirement posed upon ITTF that was normally not due until next revised edition of OOXML.

(I may remember wrongly about the verb-requirement, so please let me know, if I should have paid more attention at that moment in Geneva)

Smile

jlundstocholm Denmark |

5/29/2008 12:09:58 AM #

Luc Bollen

@Jesper: "There is good reason that ODF and OOXML both went through the speed-aisles of JTC1"

As we agree that time is needed to do things right, I would like to come back to this: was an accelerated path the right choice for both ODF and OOXML ?

The ODF text (some 600 pages) spent 3 years at OASIS (Nov-02 to Sep-05) before being submitted to ISO, and there was no controversy around it at this time.  So an accelerated path (PAS) was indeed an obvious choice.  As a result, ISO approval was received in 6 months (Mar-06).

The OOXML text (some 6000 pages) spent 1 year (Dec-05 to Dec-06) at Ecma before being submitted to ISO, amid a lot of controversy around the OOXML text itself, the decision to submit it to ISO and the choice of the Fast Track path.  One and a half year later, ISO approval is not yet granted (it is under appeal).  Yes, OOXML spent more time waiting Fast Track approval at ISO than being prepared at Ecma !

Should OOXML had matured 3 years at Ecma (i.e. until Dec-08), the text would have been massaged, structured in several parts, split in a Transitional and a Strict version.  A lot of errors and ambiguity would have been ironed out.  A common, consensual OpenFormula specification could have been produced and included in both ODF and OOXML.  Then, a Fast Track process would have been justified for OOXML, but note that the same result could have been achieved by submitting OOXML to the normal path at ISO in Dec-06.  Quality takes time...

So, what is the "good reason" that justify the choice of the Fast Track process for OOXML?  The only one I see is a simple matter of Microsoft commercial interests (expected short term marketing ammunitions).  But this backfired and resulted instead in a lot of bad press for Microsoft.

"The specs would have been obsolete the time they appeared on the other side".  The ISO version of OOXML will be incorporated into MS Office 14 around the end of 2009 (or later).  The normal path at ISO would have lead to the final approval being granted around the same period of time.  So, your argument is not valid, unless you claim that MS Office 14 will be obsolete at the time it will be available.

Luc Bollen |

5/29/2008 12:19:48 AM #

Luc Bollen

"ITTF was asked at the BRM (as far as I remember) to make sure that all modal verbs in the specification were on-par with the ISO-standard way of doing it."

You are right about the request, but the request was made to the project editor, not to ITTF.  Under the JTC1 directive, ITTF is not allowed to make any change to the text itself (and rightly so).

Once again we hit the Fast Track time limit wall: it is likely not possible for the project editor to make such a change in 6000 pages in 1 month.  But is is possible to an Ecma TC or an ISO SC to do it in 3 years...

Luc Bollen |

5/29/2008 12:53:10 AM #

jlundstocholm

Luc,

The ODF text (some 600 pages) spent 3 years at OASIS (Nov-02 to Sep-05) before being submitted to ISO, and there was no controversy around it at this time. So an accelerated path (PAS) was indeed an obvious choice. As a result, ISO approval was received in 6 months (Mar-06).

That there was no controversy over ODF at approval-time is not the same as the NBs being happy with it. The reasoning could just as well have been that - as is my opinion - "ISO (i.e. "we") is better off with ODF in ISO than with ODF outside ISO. Let's fix any problems as we go along". I think the same counts for OOXML.

Also, if you think that time-factor is not relevant here - could you please tell me why you think ODF TC submitted ODF to ISO? There are clear holes, unspecified parts and ambiguities in the version submitted by ISO. If ODF TC took "the high road" - shouldn't they have waited to get the job done first?

You keep talking about time as being essential ... and I completely agree. This is the very reason that JTC1 has the speed-lanes FT and PAS.

jlundstocholm Denmark |

5/29/2008 2:07:30 AM #

Luc Bollen

"if you think that time-factor is not relevant here - could you please tell me why you think ODF TC submitted ODF to ISO?"

Here is my analysis.  Please note that I'm not part of OASIS nor any company or group active in OASIS, so this represents only my own understanding of what happened.

I agree that the time-factor WAS relevant for ODF.  There was little interest at that time (back in Sep-05) about a de-jure standard format for documents.  Nearly everybody's view was that the real, de-facto standard was the Microsoft binary format.  Hey, they owned a near-monopoly, with 90-95% of the market for more than 10 years!

Keeping ODF at OASIS level would have perpetuated this.  So, it was a clever move to create an international standard and propose ODF to ISO, with the hope to attract more interest and more backers for the format.  And this worked perfectly well, probably above the most optimistic expectations of the OASIS TC people at that time.  Such a move (going to ISO) was likely the only way to attract interest, threaten the monopoly of Microsoft, and allow alternative applications to exist.  They took Microsoft by surprise, who hurries since then to try to catch-up.  So, indeed, timing and time-to-market were both relevant in the ODF move.

But OASIS knew that quality takes time, and the formula specification was not close to have the required quality.  They could have taken the existing documentation of OOo Calc and simply add it to the format (like Microsoft did), but they preferred to delay this part until the right level of quality was achieved.  So OASIS decided to submit the parts that were mature, and to continue working on the other parts.

"I think the same counts for OOXML."  I don't agree.  OASIS had a quite mature text (even if not of the highest possible quality), implemented by both OpenOffice and KOffice when they decided to submit it to ISO.  So, the timing and the PAS choice was making sense for them.

The same is not true for OOXML.  Microsoft, took by surprise, created a heap of some 3000 pages of existing OOXML technical documentation, put some glue around it, and looked for the fastest possible way to have it stamped by ISO.  So 3 months after ODF was submitted to ISO, they sent the first draft of OOXML to Ecma, added some 3000 pages of existing technical documentation (including the Excel formula on-line help, with minimal editing), avoided any serious, in-depth review, and in just one year managed to have this stamped by Ecma and submitted to ISO.  All this before the first implementation (Office 2007) was officially released. Quite an impressive achievement, but not the best way to achieve quality...

That's why the Fast Track choice was not an obvious choice for OOXML, but purely a political one.  Only fools and lacking-foresight competitors rush in...

Luc Bollen Belgium |

5/29/2008 2:50:59 AM #

jlundstocholm

Luc,

...They took Microsoft by surprise, who hurries since then to try to catch-up. So, indeed, timing and time-to-market were both relevant in the ODF move.

Just wanted to note that I agree with everything above this sentence.

So OASIS decided to submit the parts that were mature, and to continue working on the other parts.


But, Luc, that doesn't make any sense. To tout a document format as being suitable to replace the Microsoft Office file formats - while leaving key element either completely out or unspecified is not a wise move. It also doesn't make any sense to "submit the parts that were mature". A document format is "a whole" and it doesn't make sense to leave thing out simply because they are not done.

Also, I believe it was a tactical dissaster to leave formulas out and turn their backs on backwards-compatibility with "the rest of the world". It created a place on the field for Microsoft because the missing parts of ODF turned out to be quite important to a lot of people. If ODF had ensured backwards compatibility and fixed the holes in the spec, I believe the "sell" would have been much harder for Microsoft.

OASIS had a quite mature text (even if not of the highest possible quality), implemented by both OpenOffice and KOffice when they decided to submit it to ISO.

Please, I am surprised you would mention this. The ODF-implementation by OpenOffice.org and KOffice were not even near complete in 2005 and not then - nor now - are they interoperable. I really don't understand why people keep using that argument. Using this argument is almost as silly as saying that the XSLT ODF-Converter from SourceForge converts documents in near 100% quality.

Smile

Oooh - it suddenly occurs to me: The reason no one provided real feedback on ODF in ISO is propably the same reason that nobody provided feedback on OOXML when it was sitting with ECMA.

(people didn't care)

jlundstocholm Denmark |

5/29/2008 4:17:03 AM #

Luc Bollen

"Just wanted to note that I agree with everything above this sentence."
Thank you. I'm happy to see that, finally, we can agree on many things  Wink

"To tout a document format as being suitable to replace the Microsoft Office file formats - while leaving key element either completely out or unspecified is not a wise move. It also doesn't make any sense to submit the parts that were mature"
Well, I can agree that it was surely not an ideal approach.  But nevertheless they were quite successful with this approach, so it made sense.  You have to remember 2 things here.  First, OpenOffice and KOffice are open source.  So if something is not in the spec, people can find answers in the code, or simply re-use the existing code.  Second, ODF covers 3 main parts: texts, spreadsheets and presentations.  The missing formulas have no impact on text documents, where Open Office has been quite successful with the general public (many private end-users that I know never use spreadsheets).

"I believe it was a tactical disaster to leave formulas out and turn their backs on backwards-compatibility with the rest of the world"
Yes, I agree again that it was sub-optimal.  But for backward-compatibility, I think they had no choice.  Microsoft never published enough information to allow competitors to achieve 100% compatibility (even now in OOXML).  So ODF did as much as they could to ensure *good* compatibility.  This being said, I think it was better to go their own way and develop their own strengths rather than spending too much resources trying to play catch-up on the backward-compatibility side, where Microsoft will always, by definition, remain the numero uno.

"If ODF had ensured backwards compatibility and fixed the holes in the spec, I believe the "sell" would have been much harder for Microsoft."
Indeed, it would have been a disaster for Microsoft.  I suppose they were lacking information and resources, respectively, to achieve this.  This is where OOXML is an indirect help to Microsoft: while the competition is using their time and their resources to digest and implement OOXML, they are not improving their own solution.

"The ODF-implementation by OpenOffice.org and KOffice were not even near complete in 2005 and not then - nor now - are they interoperable."
The point I was making is not that the code is interoperable, but that both validated the ODF specification text and confirmed it was OK for them.  This helps to mature the text and to ensure that it is platform and implementation neutral.  Again, if the world had ignored OOXML and used the distracted resources to improve ODF interoperability, this would be much more advanced by now.  This is an additional hint that 2 "standards" to achieve the same goal only slows the progress and adds costs, not choice (see the New York State report about this).

"nobody provided feedback on OOXML when it was sitting with ECMA. (people didn't care)"
Again, I fully agree.  Only Microsoft had an interest to progress OOXML while it was at Ecma.  Why should anybody else have distracted scarce resources to help create a second standard, when a good one was already there ?  And the people interested in ODF had already provided their feedback during the OASIS reviews.

Luc Bollen Belgium |

5/29/2008 9:06:15 AM #

Luc Bollen

Jesper, forgot the following text above: "Second, ODF covers 3 main parts: texts, spreadsheets and presentations. The missing formulas have no impact on text documents, where Open Office has been quite successful with the general public (many private end-users that I know never use spreadsheets)."

Obviously, it is not relevant here...

Luc Bollen Belgium |

5/29/2008 4:56:03 PM #

hAl

@luc
You have a slight misunderstanding of the historic.

Actually ODF was mainly created between december 2002 when the first TC meeting was held and march 2004 when the final draft was created. So only 16 months actually.
See: http://xml.coverpages.org/ni2004-04-07-a.html
However at that time the EU had released a report that about the new upcoming XML based open document formats like the Open Office XML format and the MS OFfice 2003 XML formats and asked OASIS to submit their Open Office XML format to ISO.
At that time the OASIS TC decided to both rename the format and to liaison with the ISO/IEC so that the format could be adapted for PAS standardization. This also included a major rewrite of the standard draft to include the namechange but mainly to provide the format in an ISO/IEC chosen more formal style/format. So allthough the ODF format took a lot longer to get standardized this was not so much due to developing the standard but a lot of time went in a change of direction, name and goals for the format and adapting the format to suit that change. In that time they could possibly also have provided the formula's but that put that aside to prioritize on ISO standardization.

hAl |

5/29/2008 5:54:01 PM #

jlundstocholm

Luc,

Well, I can agree that it was surely not an ideal approach. But nevertheless they were quite successful with this approach, so it made sense.

Yes - it was a stroke of geniousness to submit ODF to ISO. I could fear that ODF would have had a slow death like ODA if it had not been submitted.

You have to remember 2 things here. First, OpenOffice and KOffice are open source. So if something is not in the spec, people can find answers in the code, or simply re-use the existing code.

I think your comment here is interesting - because it illustrates the, pardon, hypocricy of much of your criticism of OOXML (with "you" I am not referring directly to you, Luc, but use it in a more general way). When criticising OOXML, the argument has always been "pure" in the sense that you (again, generally speaking) have been talking about "principles", "integrity", "do it right the first time", "we should demand perfection" etc. But when we talk about flaws in ODF, the reasoning is much more pragmatic. Then "we'll manage", "it has shown not to be a problem" and "well, OOo is OSS, so you can figure it out by inspecting the source code".

We saw this most recently in the articles from Alex Brown performing a preliminary conformance-test of a few of the XML-files in ODF- and OOXML-documents. The OOXML-document failed because of an attribute having a wrong value. The out-cry was enourmous and Microsoft was again bashed upon with criticism of the lack of quality etc of Microsoft Office 2007 and OOXML. But no one seemed to remember, that OOo has not produced "consistantly valid" ODF until version 2.4 . Still, somehow the world has managed in all those years (three) with an Office-application that not always produced valid ODF ... why shouldn't it be the same result with OOXML?

Again, if the world had ignored OOXML and used the distracted resources to improve ODF interoperability, this would be much more advanced by now.

Again I agree - if IBM had spent all their resources on improving and developing ODF, the specification would have been in much better shape. Sadly, they chose to use their scarce resources on attacking OOXML.

Smile

Btw, thanks for the conversation so far ... it reminds me of Ian Easson saying something on Brian Jones' blog like "Who'd thought that we'd use blogs for instant conversation"

jlundstocholm Denmark |

5/29/2008 8:27:39 PM #

Luc Bollen

@Jesper: "Still, somehow the world has managed in all those years (three) with an Office-application that not always produced valid ODF ... why shouldn't it be the same result with OOXML?"

Again as an external observer, I see 3 things that can explain that attitude (I mean from a human nature point of view here, not from a technological point of view):
- OOXML is coming from the monopoly stakeholder (convicted of abuse in both US and EU), while ODF is coming from challenger players.  And people are always more forgiving to the "small guy" who tries to make his place at the sun than to the rich man that don't care for others.
- The lack of confidence in Microsoft.  So many people have seen nasty play with competitors (either companies or standards) or have been screwed in one way or another by Microsoft that they are wary as soon as a problem (seems to) appear.  
- The fact that ODF is already an ISO standard, and that OOXML arrives second.  A new standard for the same purpose has to be better than the incumbent, otherwise there is no need for it.  It will not work to say "Yes, OOXML has problems, but ODF has problems too".  Two wrongs don't make a good.  OOXML will be accepted if it can show that it has much less problems than ODF, not by saying "ODF is not better than us".

Does that seems unfair?  Well, maybe, but the same human attitude helped Microsoft to grow when it was fighting against the monopoly of IBM...  So it is maybe not unfair, after all.

And I don't think you can qualify this attitude as hypocrisy.  It would be the case if we were on a neutral battle field, and problems accepted on one side are criticised on the other side.  But we are far from a neutral battle field...  

Microsoft knows that a convicted monopoly will be judged by different standards (no pun intended) than the small fry, and has to take this into account.  Instead, they choose to be provocative from the very beginning, already in the name they choose ("Office Open XML" when their main challenger was named  "OpenOffice").

Luc Bollen Belgium |

5/29/2008 8:49:25 PM #

Rick Jelliffe

A couple of comments.

First, on the editing process. The BRM produces Editor's instructions.  The NBs vote on the basis of those instructions. The Editor makes a revised text based on those instructions and submits to ITTF.  The ITTF checks the revised text that it accords with the Editor's instructions and makes any fixes that it sees are required. ITTF then sends these back to the Editor for confirmation. The Editor then sends this back as the "endorsed text". This is then sent to the NBs in case they have comments. If it is a complete showstopper where the resulting text is out of any reasonable discretionary interpretation of the instructions, there might be an appeal, but this is extremely unlikely that the ITTF and editor could get it so wrong that they could not justify their edit against the instruction; NB comments at this stage would probably be funnelled through to the maintenance effort.

Underlying this you would expect a certain amount of ad hoc checking and interaction. In particular between the Editor (who has quite a powerful role in the ISO process, with quite a lot of discretion over wording in practice) and  ITTF.

Second, I don't think no-one is interested in ODF!  I think the trouble was that many NB did not have an SC34 mirror committee set up, so they were unequipped to do much technical review even when they were interested. Consequently, the voting tended to occur at the policy-making committee level without technical input. In at least one case I know about, even where there was an SC434 mirror committee, it only had a chance to review the schemas and not the text.  This is a failing of the NBs to have satisfactory technical committees in place, not of the PAS or fast-track procedures.

But even more than that, it is a failure of people who think these issues are important to get involved ahead of time, to be on top of the issues and procedures enough to be meaningful participants. There is a lot of criticism that there was a wave of anti-OOXML NBs and participants who only joined six months before the final vote, and then a wave of pro-OOXML NBs and participants who only joined three months before the final vote (with the earlier "stacked" people then trying to claim the moral high ground on the later "stacked" people)  but that is all just silly granstanding: they should have all been participating much earlier, if indeed these were important.   But to say "failure" even goes too far: people started to participate as they discovered that they could participate (and in some nations they could not participate directly).

Furthermore, adequate review requires adequate expertise. Adequate expertise requires previous experience and benchmarks from real cases. The intense scrutiny of DIS29500 has produced a lot of good principles and expertise which the ODF people will be applying to ODF (and which undoubtedly SC34 will be applying to future versions of IS26300 and IS29500 and their successors.)  A reviewer of ODF 1.0 once said to me "This isn't a standard, it is the sketch of a standard!"  But it doesn't matter what the shortcomings of ODF 1.0 (or DIS29500) were: what matters is how we can make ODF 1.2 (and IS29500) better.  It is mid 2008, and the battles of 2007 are well and truly over, for better or worse.

Rick Jelliffe Australia |

5/29/2008 9:11:27 PM #

Luc Bollen

"Sadly, they chose to use their scarce resources on attacking OOXML."

Two points of view are possible here: were they attacking OOXML or defending against the OOXML attack ?

At least one thing is sure: it takes much more energy to design 2 good standards and good converters between them, than to design a single good standard.

Luc Bollen |

5/29/2008 9:34:17 PM #

Luc Bollen

@Rick: Thanks for the information about the editing process from an "insider".

I have the feeling that I was not far from your explanation when I said "this is because the project editor's text was of an unacceptably low quality. So, ITTF is currently helping the project editor to improve the quality of its text."

To come back to the start of the discussion, after quite long digressions: it is clear that the process you describe cannot possibly take place in one month, when the text is 6000 pages long and there are 1000 change instructions to apply.

Luc Bollen |

5/31/2008 12:41:58 AM #

hAl

it is clear that the process you describe cannot possibly take place in one month, when the text is 6000 pages long and there are 1000 change instructions to apply.
Actually Microsoft created some some kind of content generating system for the Ecma standard which should be able to generate most of the specification content making edits to the format much easier.

And since of course most edits were as proposed by Ecma before the BRM they could have worked ahead.

hAl |

5/31/2008 12:58:46 AM #

jlundstocholm

hAl,

And since of course most edits were as proposed by Ecma before the BRM they could have worked ahead.

They actually did. About a week or so before the BRM a document was made available to the NBs that contained the modified DIS29500 in case the 1027 changes were all to be incorporated.

That should be a good starting point.

jlundstocholm Denmark |

6/4/2008 7:22:45 AM #

pingback

Pingback from blogs.msdn.com

Doug Mahugh : TechEd Orlando

blogs.msdn.com |

6/4/2008 9:55:07 PM #

Andre

So you regard it as foolish to stick to ISO rules?

Andre Germany |

6/4/2008 10:04:14 PM #

jlundstocholm

Well, thank you for once again showing that is is possible to diminish a problem to almost nothing yet still insisting to being able to derive something clever from these almost non-existant remains.

jlundstocholm Denmark |

6/5/2008 10:30:57 AM #

Mike Brown

[Actually Microsoft created some some kind of content generating system for the Ecma standard

Are they running it on Vista, maybe?  That would sure explain the delays!

Cheers,

- Mike

Mike Brown Australia |

6/6/2008 8:46:40 PM #

hAl

@Mike
I f you had read correctly then you would have seen that the delay is not with Micrsoft or Ecma but within ISO/IEC itself.
The specifcation was completed and handed over to ISO/IEC JTC1/SC34 within a month after the BRM meeting.

hAl |

Comments are closed