CyberTech Rambler

November 7, 2008

Filed under: Uncategorized — ctrambler @ 4:22 pm

Just by reading the title of the blog post on my RSS Reader and before I read Alex Brown post of The Maintenance of ODF, I already decided that it is going to be a post supporting a ISO SC34 “land grab” of ODF maintenance. After reading it, I can confirm that it is a land grab. In fact, it is a land grab for land ceded by JTC1 to OASIS. This is what I expect a lot of pro-ODF people to conclude.

Basic arguments

Before I proceed I must make it clear that any changes to the edition of ODF (ODF 1.0 2nd Edition in Alex Brown’s chart) by OASIS has to be agreed on with ISO. OASIS had opted, in their own free will, to submit that edition to ISO and therefore it must sought ISO’s agreement on any changes to that particular edition and perform all of its duty it agreed with ISO on the maintenance of that edition of ODF.

I must also make clear that I don’t know the exact mechansim of an ISO maintenance regime nor am I likely to. For example, I interpret terms like “withdrawal” the way joe public will, but it can be used as a technical term to mean the replacement of one standard by its successor, even if the successor is simply an updated version.

I am also looking at the whole thing by drawing parallels on software development, which might not be valid in standardization speak.

I am also comparing ODF with OOXML, this is because OOXML is by far the best candidate to compare ODF with. It is not a criticism or comment on OOXML processes, just a comparsion, nothing more.

OK. Now that I think I spelled out all my disclaimers and bottom line, let me express my opinion.

First and foremost, ISO does not, and cannot claim any jurisdiction over other versions of ODFs, except for the edition submitted to it. If OASIS choose not to submit anything to ISO, it is its choice. It is not unreasonable nor is it unexpected, for OASIS to choose to evolve ODF on its own. If it does, then one consequence is the passage for ISO approval of the next evolution of ODF is probably going to be more difficult compared to the case if it got ISO involved. This is, however, the bargain that OASIS choose to make and it just have to live with it. In any case, if my reading of ISO management’s view when rejecting OOXML appeal is correct, it has little to fear from JTC1 or SC34 administration, since ultimately, the true power lies in member countries and it can force things down the administrative part of the two committees.

That big nice time diagram that Alex Brown produced look to me like charting the natural evolution of a standard, any standard, no more, no less.

The purpose of Errata is to correct problems in the original text, or to clarify ambiguities in the text. Normally, an errata for older versions of the standard  is useful for anyone who has to support the older standard. Generally speaking, one will still issue errata for an older version of a standard, especially when the newer version of the standard is incompatible with the older one.

If I assume that ODF 1.0 first edition is radically different from ODF 1.0 second edition, then I cannot qualify Errata for the first edition as a “fork” but a maintenance release. However, this is not the case here. The case is even simpler. Brown himself acknowledged that that issuing this errata is OASIS’s way of incorporating work done in  “ODF 2nd edition”, i.e., ISO ODF, into the first edition. I suppose OASIS could have converted ODF 2nd edition to a “OASIS standard” to prevent the need to call the update to ISO ODF an errata, but I am not sure this will clarify this situation.

As for we having multiple versions of ODF which are not ISO standard, I am not surprised, nor would I see it as a problem. People who do not follow any discussion on ODF, and those unaware of how standard and software are made, might find the multiple versions confusing. Those of us in related fields see it as a norm. One thing that is clear to me, when explaining ODF development process to others, I would use Brown’s brilliant illustration, minus the “fork” box.

ISO development is at a slower pace from what members of OASIS expects and want. Not all OASIS ODF standard need to be ISO. In fact, in a fast-moving field, there is merits in not keep on updating an ISO standard. I don’t think I prefer the idea of multiple OASIS ODF versions, but periodically, have ISO versions that represents the algamation of work done since the last ISO versions. Using software terminology, OASIS ODF versions are the development/milestone/beta versions but ISO ODF is the final release version.

Land grab

Where do I see a “land grab”? In the section “Problems”.  In the paragraph preceding it, Brown says that OASIS believe it has an agreement that “… allows it to maintain ISO/IEC 26300 in a way which exempts it from the maintenance provisions of the JTC 1 Directives.” Paragraph 4 in the section shows that even Brown agrees that OASIS interpetation is correct.  That is what Brown is trying to reverse, by claiming that it is in violation of JTC1 directives.

Let’s make it clear that we are missing one piece of the jigsaw: The reason why JTC1 choose to disregards its own directive and entered into such an agreement with OASIS.

However, simply claiming that the agreement with OASIS violate JTC1 directives is not a carte blanche to get maintenance back to JTC1. Members of JTC1 may complain, but they did sign away the maintenance rights in the first place. Most of the time we cannot wiggle off commitment we latter wish we did not commit, why should JTC1 be allowed to do so?

If the argument actually boils down to the JTC1 directive violation, my only comment is that this shows rules does not mean anything in JTC1 even before OOXML exposed this. People like me, who believe that JTC1 breach their own rules with OOXML, has no symphathy there for Brown’s argument. No support. None. Nada. Complain as much as you like that we broke the rule first. I don’t care. You lost the morale highground as well.


From the point of view of a pro-ODF person, I am glad that OASIS did it. I do not think it is a good idea for  JTC1 or SC 34 to maintain both ODF and OOXML. There is a conflict of interest here and it will be to the detriment of both standards. Right now, we are seeing a renewed sense of excitment in the office application space, mainly the result of rivalry between the two. Consumers are reaping the benefit of this rivalry so why do I want to stop it.

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at

%d bloggers like this: