a 'mooh' point

clearly an IBM drone

Censored by Big Blue-hoo?

Today I posted a comment on Arnaud Lehors'  blog - I wanted to share my thoughts on his article about what JTC1's Fast-Track process was designed for. Arnaud moderated his blog and he has been critized for moderating his blog too rigid and not allowing posts that dissagree with him (check out the comment section of my previous article about IBM's trench war) and Doug Mahugs article Similar accusations have been made at the other two of "the three stooges", Bob Sutor and Rob Weir.

I don't know where Arnaud lives (presumably in US), so he might have been at sleep when I posted my comment, but it took a few hours before my comment appeared on his blog. In the mean time I couldn't help thinking about whether or not I had been moderated to death as well ... or if it was all a storm in a tea-cup.

So on my way home from work I thought I'd help out a little with straightning out the confusion. I don't moderate my blog (and never will) so I hereby put forward, as a service to you all, the option of using the comment section of this entry as a "Big Blue Comment censorship archive".

So if you are about to post a comment on one of IBM's blogs, feel free to also post it here with a link to the blog post you would expect it to appear in.

I think this would be a win/win situation for us all. It will provide means to say and claim, that IBM is really censoring their blogs ... and if IBM stops moderating so aggressively, they will be able to claim that we were all wrong.

I will cast the first stone.


Comments (6) -

Posted at lehors.wordpress.com/.../ on March 27th 2008.


Actually, it is not difficult to find out what the Fast-track process is really about - you need just open the JTC1 directives and find section 13.

It simply says:

13.1 Any P-member of JTC 1 or organisation in Category A liaison with JTC 1 (the proposer) may propose that

a) an existing standard from any source be submitted without modification directly for vote as a DIS;


b) an existing amendment to a standard, with the approval of the responsible SC, be submitted without modification directly for vote as a DAM.

It is clear that OOXML satisfies both requirements for inclusion in the Fast-Track.

So your innuendo that “The Fast Track process is merely designed to ratify specifications that already meet ISO standards criteria or are very close to.”

… is simply not true. I think it would be beneficial to us all, if you could try a bit harder to seperate facts from fiction.



There are actually quite a few things in the JTC1-directives that do not apply to fast-tracked standards - among these the use of "modal verbs" (I think it is the correct words in English) and reference to other standards (AROs).

I contradict your phrase "The Fast Track process is merely designed to ratify specifications that already meet ISO standards criteria or are very close to."

This is simpy not correct. The purpose is to give the possibility of submitting any standard to ISO by any NB or Liaison A (to JTC1). Of course the process should make it possible to improve the submitted text - this is what the BRM is for.

And please - that you pick out the words "without modification" and twist them to your satisfaction only highlights the M.O. of a lot of the critisisme of OOXML. The words mean that the submitted standard need not be modified before submission. It's not that hard.



Rob et al,

you all forget to mention, that what you are stating here is your opinion of the process and the JTC1 directives. So when you talk about OOXML not being suitable for Fast-track or "ECMA and Microsoft abused the process" or "not designed to fix broken specifications" I would assume there would be at least a couple of words about these things in the directives.

Sadly, there are not. The only requirement for a standard to be eligible for Fast-Track is that it does not contradict already existing standards or projects. The JCT1 secretariat and ITTF decided that OOXML didn't.



(I appologize for responding so late, but the last week or so have been really crazy, so I have not had the time to get back to you before now)

Actually you said pretty much the point I was trying to make - that the statements you (and I) present are merely matters of opinion. The reason I picked at you was really, that being from IBM injects an enormous amount of credibility into any arguments you guys might make.

(the same, only negated, goes for Microsoft in these debates) Smile

The, to me, sad consequence of this is that what you IBM-guys say are percieved as the complete truth - at least in the blogsphere, and that makes my effort so much harder than if we were just "two guys talking".




About quality of ODF vs OOXML:

Rob Weir presented a very short and perfect example of what kind of mess OOXML is and why ODF is superior
Do you really think it does make any sense what so ever to conclude that "OSF is superior" by the example Rob gave?

Do you think it would be fair to claim OOXML was superior to ODF using the specification around document protection as an argument?

(I am sure you know that this part is unspecified in ODF)


For what it’s worth, what I’ve learned from this is that ISO, which is often seen as paramount among standards organizations, is actually very weak

I think this is true. ISO and its processes are not in themselves strong. The responsibility of creating strong standards are the members of ISO - the national bodies.


XPS is being dealt with by ECMA TC46 and a good guess will be that it will be submitted to SC34 in FT-mode.

However -TC46 has established liaison-agreements with quite a large number of committees.

From: www.ecma-international.org/memento/TC46-M.htm

TC46 has formal liaisons with the following standards bodies:

ISO/IEC JTC1/SC 28: Office equipment
ISO/IEC JTC 1/SC 29: Coding of audio, picture, multimedia and hypermedia information
ISO/IEC JTC 1/SC 34: Document Description and Processing Languages
ISO TC 130 WG2: Graphic technology – Prepress data exchange
ISO TC 171 : Document management applications
Ecma TC45: Office Open XML Formats
International Color Consortium

It doesn't seem that they have actually produced anything yet - at least I cannot locate any available drafts of the future spec.

Comments are closed