void life(void)

Received in recent days several documents from JTC1/SC34 reporting the progress at the working group that is trying to fix the OpenXML, and it’s impressive and surreal what one may find in those documents.

The document N1101/N1168 contains for example, several items in which they recognize that there are decisions made in the BRM (BRM resolutions) which were not incorporated into the final published text of the standard. In other words, even taking almost a year after the aproval of the standard to publish the text (yes, approved without reading), there wasn’t time/attention or anything else necessary to assure that the changes were published in the text (most of those changes, “conditioned” the approval). What makes me much more angry about this is that during the BRM I asked about who would be responsible for verifying that all these changes would be part of the final text and the answer was ITTF (kind of joint ISO/IEC secretariat). When I asked if the ITTF would really make this work, I received as a reply the intimidating: “You are doubting the ITTF, kid ?”…

Worse than this, the informations inside this document are sufficient for me to doubt that the approved/recommended corrections where even implemented. If before this document I suspected that the final version of the specification wasn’t what everybody thought, now I’m pretty sure about it and I think that we didn’t find even more severe problems there because most people, like me, refuses to look at those damn 6000 pages again.

On the document N1171, one of the working groups of SC34 announces that they’ve found problems in the OpenXML fonts specification and will submit an error report about it to the group responsible for repairing the standard (looks funny, but until today there are folks finding defects … ).

The document N1183 justifies the subdivision of the already existing parts of the standard to saying that to correct some errors pointed out, new “minor” features need to be added to the specification (and that is really cool, because now that the ISO has already approved the standard, they can write whatever they want , isn’t it?).

I saved the best for the end: document N1187. This one says that OpenXML “as is” contains unintentional errors that may prevent existing documents to be fully represented in this new format.  It is amazing because the legacy support was alleged as  the main reason for OpenXML development and approval at ISO, and also the reason why several countries supported the development and approval of the standard. In this document, they also explain the criteria that will be used to specify the changes that will be developed, so that they can do it all really quickly (in other words, they go trough the breaches of the JTC1 directives to get these changes incorporated into standard already approved without making much noise about it).

Unfortunately I can not put all these documents here, to allow access trough the blog, because they should be restricted SC34 documents (yep, zero transparency), but I believe that sooner or later they will be published somewhere (and of course, NB members should already received those).

Since I was a young boy I’ve learned to not sign blank papers, but I think that this isn’t a valuable lesson in other countries.

I would like to see answered some basic questions:

Brazil, South Africa, India and Venezuela were right or not when appealed (and had their appeals ignored by the ISO)?

Do the same gentleman at the ISO board, that ignored the appeals, are following the development work and documents commented here?

Who is responsible for all this, and how he will pay?

Share/Save/Bookmark

10 Responses to “For the skeptical, the final proof: The OpenXML wasn’t (and isn’t) ready”

  1. Bigpicture

    Clue in here, you can analyze all the technical merits and shortfalls that you want. It never was about technical and public benefit. It’s MS here you know, it’s about corruption and who can be bought.

  2. Next round of ODF vs OOXML… « CyberTech Rambler

    […] the ODF camp, I think this criticism of OOXML is a bit over the top. Mistakes happens. Moreover, every standard has defects so having […]

  3. Microsoft and the Economics of Crime | Boycott Novell

    […] bullied, lied, blackmailed, and bribed to pass OOXML past ISO. it’s all documented. Here is where things stand today: The document N1101/N1168 contains for example, several items in which they recognize that there […]

  4. Spongebob Squarpants

    Why not subbmit the “restricted” documents to wikileaks?

  5. Rick Jelliffe

    Your interpretation of N1183 (which is public, by the way) is odd. In ISO, the Corrigendum process is used for minor errors (e.g. the editor made a mistake and is told to fix it) while the Addendum process is used for technically substantive changes. N1183 is just a bureaucratic document setting the wheels in motion for an Addendum (a new version of IS29500); in particular it is saying that some of the current crop of defect reports are the kind that need national vote, and cannot be dealt with by the editor.

    People who are interested in WG4’s work, see http://www.itscj.ipsj.or.jp/sc34/wg4/ for the defect logs.

    What I don’t understand is this: before and after the BRM people like me said often that there would be a maintenance process for IS29500, and so we did not need any panic (as if the BRM was the only chance to identify problems and negotiate fixes.) And now that this is exactly the situation, why are you surprised? It can take years before a standard is “stabilized” (i.e. national bodies decide to leave the text as it is.) All the BRM did was identify some bottom-line fixes which would move IS29500 into a good-enough position for maintenance to start; no-one has proposed “stabilizing” IS29500 as if it was perfect.

  6. Avi Alkalay

    Mr Jelliffe, you are a well known folk that enjoys making bad facts look nicer that they really are.

    The problem here is the amount and deepness of problems that were pointed and documented way before the voting and the BRM. In the OOXML case they are not small glitches that people didn’t see at that time, they are huge design mistakes very hard to solve, and they were all pointed at that time.

    As an addition, another standard was already there, much cleaner, equally well used etc. I’m talking about ODF, obviously.

    You are wrong again but we also know you won’t come here again to continue an open discussion. This is just so not you.

  7. Rick Jelliffe

    Avi. Thanks for your kind words. IBM of course tried to stop me from attending the BRM, even attempting to go to a government minister, so I am rather surprised that an IBM PR guy would raise the issue of ‘open discussion.’

    If my memory serves me well, after the BRM, you went around claiming that unless all defects, no matter how small, that a National Body had reported had been fixed by the BRM, then that National Body was required to vote against the standard. This was such rubbish, and has never been the way standards voting operates: a sense of proportion is always important. And it was an idea rejected by national bodies when IS29500 was accepted. But it fitted in with IBM’s demonizing campaign of FUD and panic, which was based on a phoney war between ODF and OOXML.

    IS 29500 has two kinds of flaws. One kind is because the document has parts that are wrong and incomplete: these can be fixed by maintenance, just as with any standard before it is “stabilized”. There are at least 165 of these defects being looked at currently by WG4. The other kind is because of flaws in the basic OOXML technology: these are not things that can be fixed much by IS29500, since the purpose of the standard is to reveal the technology not reform it. (That is what ODF is supposed to be for.)

    It seems to me that I have much more faith in ODF than you guys who panic and bluster. I have said from the beginning that I think the drivers for ODF are different from the drivers for OOXML, and a standard for OOXML will not hurt the progress of ODF.

    And, after a year, I have been proven entirely correct, and your panic and FUD has been shown to be wrong-headed (at best) and manipulative (at worst.) IS 29500 has not held up adoption of ODF in the slightest. All that has happened is that people are more realistic about the limitations and timetables of the technologies, and more sceptical about standards, which is good.

    But then the panic about IS29500 was never about technology was it? It was about co-opting the standards process to engage in corporate branding and marketing.

  8. Jomar Silva

    Mr. Jelliffe,

    Please don’t make confusion here between persons and companies. Avi is member of BR’s National Body and worked hard with us during the technical evaluation of OpenXML (He’s not IBM PR as you suggest).

    I must agree with you when you said that “… IS29500 was never about technology …”, because if the technology was a concern there, the standard wouldn’t be approved.

    Just to refresh your memory, OOXML was REJECTED at ISO when the stupid BRM was arranged (stupid because just a fool would think that in 5 days more than 3.000 technical problems would be discussed). Microsoft has used the BRM worldwide saying that “… at the BRM everything was fixed…” and seeing that most countries believed on that, they change their votes (so, the BRM solution to OOXML has a MAJOR role on this approval).

    If you think that OOXML need a time to be “stabilized”, it is to me just a prove that the specification wasn’t ready to be considered a FDIS (or ISO has the practice of “Approve first and write latter ?”).

    Unfortunately I know who you are and if you need another memory update, I was at the BRM as a member of BR’s delegation and I swear to you that I didn’t published 5% of what I saw people doing (and proposing) on that room, so please, stop pretending to be someone that you’re not.

    Talking about the BRM again, if I was a citizen of your country I would contact the president if necessary to avoid you on that room (don’t blame IBM for doing something that anyone would do).

    Best Regards,

    Jomar

  9. jwildeboer's status on Wednesday, 24-Jun-09 16:50:09 UTC - Identi.ca

    […] #UhOhXML is still worthwhile observing: http://homembit.com/2009/04/for-the-skeptical-the-final-proof-the-openxml-wasnt-and-isnt-ready.html […]

  10. Jan Wildeboer · Identi.ca Updates for 2009-06-24

    […] is still worthwhile observing: http://homembit.com/2009/04/for-the-skeptical-the-final-proof-the-openxml-wasnt-and-isnt-ready.html […]

Deixe seu comentário

Proudly powered by WordPress. Theme developed with WordPress Theme Generator.
Creative Commons License