a 'mooh' point

clearly an IBM drone

Conformance of ODF-documents

Ever since the now infamous article by Alex Brown the blogsphere has been filled with interpretations of the, really not so surprising, results - that the OOXML document with the original ECMA-376 spec does not conform to IS 29500.

The, really not so surprising, conclusions have been "Office 2007 does not even produce valid OOXML" followed closely by statements like "This shows that Microsoft Office 2007 should not be allowed since it does not produce valid OOXML".

Hmmm ... ok.

As some of you might remember, I participated in some lab tests with OOXML/ODF interop in Fall 2007. Basically I sat in a small room with guys from IBM, Microsoft, Novell and some guys from the Danish National IT- and Telecom Agency sifting through documents, converting them and examining the resulting XML generated. The documents we worked on were supplied by different parts of the Danish public sector. They were basically told to use some of their existing documents as basis for the parts of the tests they participated in. So these documents were real-world-documents.

One of the things we tested was to see if the documents were in compliance with their respective specs. The original OOXML-documents we tested were all compliant to the ECMA-376 spec ... but it was a different case with the ODF-documents. So the other day I tried to validate all the sent-in original ODF-documents supplied to us.

The results are illustrated in the table below:

File name

Generator

Konklusion

DFFE_Afgået svar til Jane Doe.odt

OpenOffice.org/2.3

not valid

DFFE_SJ_(1) - 15-06-2007 Foreløbig Høring om forslag.odt

OpenOffice.org/2.0

valid

GRIBSKOV_bek-281(BS).odt

OpenOffice.org/2.0

valid

GRIBSKOV_Standardbrev ifm ITST pilotprojekt.odt

OpenOffice.org/2.2

valid

GRIBSKOV_Udkast til Forslag til Lokalplan.odt

OpenOffice.org/2.1

not valid

ITST standardbrev ODT.odt

OpenOffice.org/2.0

valid

ITST Testdokument ODT.odt

OpenOffice.org/2.2

not valid

RM Kursusmateriale.odt

OpenOffice.org/2.0

not valid

RM Standardbrev 2s.odt

OpenOffice.org/2.3

not valid

The table contains information about the file name of the original document, the application that generated it (from the META-file in the ODF-package) and if the document passed the test.

Overall conclusion of this was:

Application

Creates consistantly valid ODF?

OpenOffice.org/2.0

 

OpenOffice.org/2.1

 

OpenOffice.org/2

OpenOffice.org/2.3

 

So should we demand that OOo not be used at all? Of course not, but we should keep the pressure on the OOo-team to fix their code ... just as we should with Microsoft and Microsoft Office.

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.

Smile

Committee-stuffing (the anti-OOXML-way)

I just wanted to give everyone a heads up on some information I recently got on our cold (but warm at heart) friends way up in the most Northern part of Europe - the Norwegians.

It seems that Google and IBM have just within recent days joined the Norwegian NSB (National Standardisation Body). So much for critizising supporters of OOXML if they were late joiners in various countries, claiming abuse of the standardisation process by undue influence.

If I know the FOSS-community right, they will now be tripping over each other's feet for a shot at "first post" being pissed about Google and IBM's actions - demanding that they withdraw completely from the process.

(or maybe not) 

Now if you ask me, it's not that big of a deal that some companies arrive late.

Matthew 20:16 - So the last shall be first, and the first last.

What is a big deal is that people should naturally contribute to the work in the NSBs if they join ... but simply focusing on the admission-date is really stupid. Contributing in the work is about taking part in the debate and discussions in the NSB. It's about doing homework between meetings and knowing what the hell is being talked about. Basically, it's doing almost anything but simply attending the meetings, sipping in the free coffee. One could argue, though, that when paying DKK 20.000 for an annual membership, it doesn't really make sense to talk about "free coffee", but I am sure you catch my drift ...

Granted, being late does make it difficult to achieve other influence than raising your hand when voting ... but having been a member of a committe for several years does not in itself ensure that you have participated. There are members of the Danish committee that I have never heard speak and there are members of the Danish committee that alter the attending employee for each new meeting. They may not speak at the meeting - but they have certainly raised their hands when voting.

What is also important to me is that the rules in the specific NSB are not broken. If the Danish NSB decides that members can join the day before a vote (they can) - it's probably because the Danish NSB felt that it was OK to do so. If the Danish NSB decides that a member cannot vote until after a month of membership - it's probably because the Danish NSB felt that it was OK. Different countries have different rules and it is up to each NSB to manage these rules and make sure members obey them.

So what can you do? well, how about rules that say:

  • You must have attended at least two meetings before eligible to vote.
  • You must be actively participating in the meetings by actively participating in the discussions.
  • Every two months point two above is evaluated and be simply majority it is decided who gets kicked out ot the committee.
Is it a bit extreme? Welll maybe ... but it is also a bit extreme to judge solely on the basis of the admission date.

IBM is now fighting from the trenches

After the BRM it seems to be more the rule than the exception to be denied "speech" on the blogs of the front-runners of the IBM bloggers. First it happened to me on Robs blog (where I commented on his patronizing tone towards a Czech delegate at the BRM and now it happened to me on Bob Sutors blog as well. Actually I thought it was just my point of view that was really stupid (so that Bob was essentially doing me a favour in not approving my comment), but today in the newsgroup comp.os.linux.advocacy I heard that Bob had completely disabled comments to this particular post and a post routing more of the, ahem, "balanced" views of the ODF Alliance. It seems to me that IBM has given up debating the issues at hand and are now using their blogs as mere portals with no user-interaction ... at least not interaction of the people opposing their views.

Well, to the amusement of you all - here is what I wrote:

Hi Bob,

I am a bit confused to why the lawyers of the Software Freedom Law Center has not compared the OSP of Microsoft to IBMs Interoperability Specifications Pledge at http://www-03.ibm.com/linux/opensource/isplist.shtml .

They seem to focus on two sentences from the OSP, but similar ones are present in IBMs ISP:

Microsoft:
New versions of previously covered specifications will be separately considered for addition to the list.

IBM:
IBM will evaluate new versions or additional specifications for inclusion based on their consistency with the objectives of this pledge which is to support widespread adoption of open specifications that enable software interoperability for our customers, and may, from time to time, make additional pledges.

Microsoft:
The OSP does not apply to any work that you do beyond the scope of the covered specification(s).

IBM:
IBM irrevocably covenants to you that it will not assert any Necessary Claims against you for your making, using, importing, selling, or offering for sale  Covered Implementations [...]. Covered Implementations" are those specific portions of a product (hardware, software, services or combinations thereof) that implement and comply with a Covered Specification and are included in a fully compliant implementation of that Covered Specification.

By decuction, shouldn't OSS-developers avoid ODF too?

I won't repeat Bobs response to me, since it was in a private email, but Bob, please feel free to comment here.

Smile

 

OOXML is defective #1 (Pasword hashing)

OOXML has been accused of being rushed through not even the writing itself but also certification in both ECMA and ISO. It's a quick accusation to make but sometimes it can be really tricky to figure out if a statement is true or false. But you know, sometimes you stumple over something that really shows you that the specification was rushed through not only preliminary editing but also certification in ISO.

The one thing I noticed in was password hashing. As with other document formats, document protection can be defined in multiple ways. There is of course protection of the document itself but most document formats also allow protection of specific parts of the document or even read-only protection of the document. The way it's usually done is to ask the user for a password, hash it and store it in the document. When the document is opened the next time, the user is prompted for a password, and if it matches the stored value - the protection of the document (or parts of it) is released.

Now, this is defined, amongst other places, in section 4.4.1 (Section attributes) where it deals with protection of sections. The text says:

A section can be protected, which means that a user can not edit the section. The text:protected attribute indicates whether or not a section is protected. The user interface must enforce the protection attribute if it is enabled.

This is more or less what I wrote above. It also says:

A user can use the user interface to reset the protection flag, unless the section is further protected by a password. In this case, the user must know the password in order to reset the protection flag. The text:protection-key attribute specifies the password that protects the section. To avoid saving the password directly into the XML file, only a hash value of the password is stored.

And that's it.

WTF? Nothing more? Nothing about how to specify the hashing algorithm? Nothing about how to specify initialization vectors, prepending of zeroes ... nothing?

But wait - what if we look in the schema itself - maybe it's just the descriptive text that is a bit ... ahem ... limited. Ok - the schema says:

<define name="sectionAttr" combine="interleave">
 <optional>
  <attribute name="text:protection-key">
   <ref name="string"/>
  </attribute>
 </optional>
</define>

Dammit - nothing here either. Notice also that it is not possible to store the way the hash-value is persisted. Is it a bit-sequence? A Hex'ed bit-sequence? A Base64-sequence? Nothing!

But wait again - let's look into the file of an actual document with read-only protection. Let's see what is stored in the document. Well, the XML-fragment lists as:

<table:table
 table:name="Ark1"
 table:style-name="ta1"
 table:protected="true"
 table:protection-key="PnKGfjzdfrt6XxQxdTcQVqbmA/7Ro="
 table:print="false"
>

Any clever suggestions for me as an ocument consumer to what to do with this value? This is truly amazing. One one hand the authors talk about their document format being able to provide true and pure interoperability ... but they haven''t specified something as common as document protection. I wonder how they can claim this with a straight face. Interoperability is certainly not enabled by limiting the details of the specification to as little as this ... but maybe they just hope noone will use this feature and thereby have "interoperability by rejection".

I cannot help to wonder: who in their right mind would put up a suggestion for standardisation of a document format that was unspecified in such a central feature as "document protection". This must be one of those places where

Ratification trumphs perfection 

Yeah, well ...