a 'mooh' point

clearly an IBM drone

Final nail in the coffin for the "highlander approach"

On January 29th the Danish politicians finally got their acts together and did something about open document formats. After almost 3 years of debate and endless dragging of their feet - a consensus and agreement was finally made on that Friday.

The agreement made had this content:

For use in the public sector in Denmark, a document format can be used, if it is on the list of approved document formats. To get on the list, the document format must comply with these rules:

  • It has to be completely documented and be publicly available
  • It has to be implementable by anyone without financial-, political- and legal limitations on neither implementation nor utilization
  • It has to have been approved by an internationally recognised standardisation organisation, such as ISO, and standardised and maintained in an open forum with an transparent process.
  • It must be demonstrated that the standard can be implemented by everyone directly in its entirety on several platforms.

If you ask me, this list is pure rubbish. Apparently a deal was made on that Friday morning literally minutes before an open hearing in Parliament and this bears all signs of a job done in too much haste.

(of course, all this happened when I was away on family weekend, but as you can imagine the blog-sphere went crazy and twitter buzzed like a hive of bees with the gent's of "big blue" and "big red" taking swings at each other)

Devil in the details

The problem is that it is written all over it that this list will be taken very literally and we are going to continue to have to discuss stupid details with stupid people - instead of getting to work to start giving value to our customers.

The problems pertain to item 1) and item 4).

Item 1 is actually not that big of a deal, but it is an example of a requirement that cannot be verified. Because what does "completely documented mean"? Does it mean that a mere list of all elements and attributes is enough to give a "thumbs-up"? Does it mean that a single ocurrence of the phrase "... is application defined" provides automatic rejection? Now, I agree with the idea behind this, coz' shit has to be documented but this item should be removed or altered to provide real meaning.

And what about item 4) ?

Well the problem with this is that no document standard of today can be said to comply with this requirement - thereby making the list Ø. The only way a document format can be said to comply with this would be to have 2 independant applications, each claiming to be implementing the specification in "its entirety". And still we wouldn't be able to actually prove it. We would, at best, be able to show that with high likelyhood the applications do actually implement the specification "in its entirety".

Two to go ...

So that basically leaves us with two requirements. The only requirement we should think of adding would be "It has to be relevant in the market" ... ODA, anyone?

The silver lining

But do not fret - it is not all bad. No, because the agreement effectively puts the final nail in the coffin for the "there can be only one document format"-line of thought. The Danish parliament has has turned its back on any exclusivity with regards to document formats and has turned its focus to "open standards". This is no doubt a positive move, because now it doesn't make any sense any more to argue "which one is bigger (or, smaller)" or over who got to the playground first.

With this decision Denmark follows other countries like Norway, Belgium and Holland where the notion of "open standards" is also the center of thought - and who have also discarded the idea of "value can only come if we only have one document format". This is fantastic - and I applaud our politicians on making this decision - even though some of the details lacked consideration.

Smile

Maintenance of IS26300 in SC34

The streets of Prague are buzzing with rumours coming out of the work in the working groups of SC34 and SC34 itself as SC34 is currently having its plenary meeting in Prague.

It seems that SC34 has done the only clever thing to do - to create an Ad Hoc Group (AHG) to have responsibility of maintaining IS26300. I applaud the decision to do so, and it has in my view been a long time coming.

The details and scope of the group is yet to be seen, but I am glad that SC34 has chosen to create it. There is only one entity responsible for maintaining ISO standards, and that is ISO. Maintenance of IS26300 has falling between two chairs at the moment, where WG1 was initially responsible for it, but it has been preoccupied with other tasks. Also, I think the maintenance agreement of IS26300 has been mentally prohibiting any work being done.

The upside of this is that there is now a group in SC34 responsible for receiving defect reports submitted by NBs. One group is responsible for preparing reports to OASIS and the get the responses back in the ISO system.

This is a clear improvement and it is a sign and a statement that we believe that IS26300 is too important to not have a group responsible for its maintenance in ISO.

Smile

OASIS to JTC1: Bye, bye ...

Ever since the hoola about OOXML-approval there has been quite some discontent in the ISO community regarding how ODF TC has fulfilled its obligations after IS26300 approval. A few meetings have taken place to "amend the harsh feelings" and now some preliminary results have been sent to the NBs for consideration. For those with ISO privileges the documents [1], [2] can be found in the SC34 document repository.

There has been a lot of debate as to where maintenance of ODF should take place, be it in OASIS via ODF TC or via some construction as with OOXML, where the originating TC is included (assimilated) into SC34 and maintenance and development takes place there. I really don't care where these activities take place. I just want the best qualified people to do it.

Now, the documents deal with a definition of principles and a more specific definition of "who takes care of what?"-items. When reading through the documents, I couldn't help getting the feeling that what OASIS was essentially telling JTC1 was "It's my way or the highway".

JTC1 and OASIS have come to the following agreement around maintenance: 

  • OASIS ODF TC takes care of maintenance and development of ODF. 
  • National body participation in this work is encouraged to take place in ODF TC by either direct membership, via the "Comment mail list" or via TC Liaison (I didn't know JTC1/SC34 had one of those in ODF TC)
  • OASIS will submit each approved edition of ODF to JTC1/S34 for approval to make sure that approved standards are equivilant.

I completely agree on item 1) and 3) above, but item 2)? In the paper there is not a single sentence on how the procedures in JTC1 fit into all this. Why are there no wording regarding voting procedures in SC34? If ODF TC comes up with something new and "substantially different", it should be submitted using the "PAS submitter status" of OASIS (similar to the Fast track procedure ECMA used with OOXML). But a PAS submission requires voting in SC34 and if the vote fails (or substantial concern is raised), a BRM is scheduled. If the comments are fixed, the result of the BRM will be an "errata-sheet" and a new vote takes place.

Suppose the post-BRM vote approves the submitted ODF edition

  • what will OASIS do with the errata-sheet?
  • what are the principles for getting them back into the OASIS-approved edition of ODF?
  • what is the time frame?

Is the truth really, that OASIS doesn’t want JTC1/SC34 to do anything to ODF but rubber-stamp it when it comes our way?

When the original ODF 1.0 was submitted to JTC1, a maintenance plan was agreed upon. It had two small but really important words in it: "as is". The maintenance agreement said (AFAIR) that JTC1/SC34 was expected to approve future editions of ODF "as is". In other words, what OASIS managed to get JTC1 to agree to was essentially: "Don't look at it, don’t' open it, don't flip through it, just - don't touch it. Get a hold of the ISO-approval stamp, stamp it and send it back to us".

The only possible conclusion is that OASIS does not want any direct ISO-involvement in development of ODF.

That is fine - the ODF TC should do what they find best. But I am wondering if that also means, that OASIS will not send future editions of ODF to JTC1 for approval? Surely, OASIS can't live with the reputation of having their standards simply rubber-stamped by ISO? 

You may also ask why it is not good enough for JTC1-members to contribute to ODF through ISO. Well, OASIS is a vendor-consortium and the interests of the vendors seem to be somewhat different than the interests of the national bodies. If you look at the contributions of Murata Makato and Alex Brown through the ODF Comment list, it is clear that their interests in quality in schemas, constructs and the specification itself was not prioritized in the TC at all. To me a mix of vendor interests and national bodies is the best way to ensure high quality in any specification, but the proposed agreement between JTC1 and OASIS seems to cut out the national bodies acting as "national bodies"

I think it is a good idea to ISO-approve ODF in the future. But JTC1 needs to send a clear signal to OASIS saying, that is it fine that they want the “Seal of ISO” and we welcome them. But in order to have the cake, OASIS must eat it too. The ISO package must come with two items, 1) the ISO quality stamp and 2) national body involvement. You cannot just have the stamp! It should be emphasized that it is the prerogative of the national bodies to process the standards that come their way and that cutting them off and have them do nothing but rubber-stamping the specification is completely unacceptable.

The proposed maintenance proposal will be discussed at the JTC1/SC34 plenary in Prague on Friday, and I hope all national bodies have understood the ramifications of approving the maintenance agreement. I suggest the plenary responds by saying to JTC1/OASIS: "Thank you for your suggestion for a maintenance plan for ODF, but come back again when we as  national bodies have a solidly founded role in the maintenance of the specification".

ODF 1.0 Errata 01 released

Yesterday the official Open Document Format for Office Applications (OpenDocument) 1.0 Errata 01 was released for public feedback. The email in part says that

The public review starts today, 7 August 2008, and ends 22 August 2008. This is an open invitation to comment. We strongly encourage feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of OASIS work.
The document is available http://docs.oasis-open.org/office/v1.0/errata/cd02/ for those of you wanting to take a peek or contribute to the work. The document consists of 88 corrections to the text with references to both the OASIS-edition as well as the ISO-edition of ODF 1.0.

I am a bit unsure if the Japaneese ISO-NB defect report as well as the comments from the original ODF ISO ballot are included in this errata - maybe they will not be dealt with before ODF 1.2 hits ISO (possibly) sometime this Fall.

 

Smile