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.


EEE - the SC34-way

In my recent post about the outcome of the AHG1-meeting in London, IBM's Rob Weir pointed out, that

What everyone is missing is the fact that Microsoft is not obligated to participate in SC34/WG4 maintenance, or to do maintenance exclusively in SC34/WG4. Ecma is fully capable of submitting any future version of OOXML under Fast Track rules directly to JTC1 (not SC34) for another 6-month ballot.

Well, as I have said repetedly before, when Rob is right, he is right, and this is no exception. As JTC1 Class A Liaison (there are actually only three of those, the other being ITU and the European Union, if I remember correctly), they can do pretty much what they want. So if we wanted to ensure maintance of OOXML would take place completely in SC34, we couldn't rely on JTC1 directives for help. We had to do something else.

One way would be to strong-arm ECMA into signing a binding, legal letter in which they committed to exclusive maintenance of OOXML in SC34. I you ask me, I don't think that is a good idea. I think most of us will agree, that this process has seen too many lawyers already.

Another way would be to indirectly make sure that ECMA does all their activities within the SC34-sphere. Like all organisations, people with the right skills are a constrained resource and it is in no way different for ECMA. As Rob pointed out, there is only limited time available for everyone, and we all need to prioritize our resources. So even though we did not discuss this particular angle with respect to ensuring maintenance in SC34, this was in effect what was the result.

SC34 needs to appoint resources to two areas when setting up WG4:

  1. The editor of the project
  2. Who should run the secretariat for the working group

ECMA volunteered to manage both areas, and we discussed quite a bit about that being a good idea or not. Come to think of it, I think it is.

ECMA (here Rex Jaeschke) has been the editor throughout the process - first in ECMA itself and next in ISO. It is clear that he has the right skill-set to follow the process and he has a clear interest in a fast-paced process. ECMA also volunteered to run the secretariat for the WG. As I wrote in my previous post, the work-load of the WG will be quite big, and a secretariat is really needed to keep track with everyone, to coordinate meetings and to create meeting reports, agendas etc.

So what we essentially did was a "Tripple-E" on ECMA. We have embraced ECMA and their OOXML-resources and we have sure, that given the amount of resources they are to put into SC34/WG4, they are not likely to have their own work run in parallel in ECMA. Now, at some point WG4 will be presented suggestions for additions to the specification. These could be from ECMA, but they could be from just about any member of SC34 - including countries opposing OOXML or competing companies represented in their favorite country. This is really the "ISO-model" at work.

So, you might say, this is just a load of good intentions and wishes for the best possible outcome ... and this is perfectly correct. Sadly though, these were our only options given the JTC1 directives. You might also say that it is highly likely that ECMA will be the only entity that will show up with additions to the specification. I have absolutely no idea of the propabilities for this to happen, but I think it would be very sad. We need other stakeholders and participants in the work with OOXML than ECMA and the national bodies' standards people and I think it would be unfortunate if the only stakeholder in WG4 with real, hands-on experience with creation of Office applications was ECMA. As Rick pointed out the major participants in ODF TC all develop applications based on the same code base and rumour even has it that development of additions to ODF is largely driven by Sun's development of OpenOffice.org in a "we need this element for our implementation - please put it in the specification"-kind-of-way. I have no idea if it is only a theoretical issue or if it is a concrete problem, but I would imagine that a document format to be used by a variety of implementations would benefit from different implementations being present at the development table. This is indeed also true for OOXML. We need the competitors of Microsoft at the table as well.

(ECMA TC-45 already consists of major office suite developers (Apple, Microsoft, Novell etc), so you already have the diversity of vendors present, but I have collectively referred to them as "ECMA". I would still, however, prefer to have participants present not associated with ECMA)


Luckily, you should brace yourselves that even in the event that everything mentioned above falls apart and ECMA litteraly goes their own way, the net effect will "just" be that maintenance of OOXML will be as with ODF where OASIS ODF TC works on maintenance completely seperate from JTC1/SC34.

ECMA har udsendt de sidste svar

I går var så dagen, hvor de sidste svar fra ECMA blev gjort tilgængelige for de nationale råd rundt omkring i verden. Dermed har ECMA svaret på alle godt og vel 3500 kommentarer, der indløb i løbet af behandlingen af DIS 29500 i sommer/efterår 2007.

Under arbejdet med standarden og diskussionerne om den henover sommeren kunne jeg ikke lade være med at tænke på, at rigtigt mange af kommentarene var det rene vås eller i bedste fald ligegyldige. De var som lavet ud fra devisen "hvor jeg nu bevidst prøver at misforstå det - hvor er det så lettest henne?" (ex: OLE). Det er klart, at der var mange gode kommentarer, men mange af dem var faktuelt noget ævl.

Men jeg må erkende, når jeg nu sidder og kigger på resultatet af behandlingen af kommentarene, at den samlede mængde kommentarer har resulteret i en standard, der på mange måder er bedre end den var før. Standarden er helt enkelt blevet mere præcist formuleret og generelt lettere at anvende. Det er helt klart et anerkendende nik værd overfor alle de mennesker, der (om de er for- eller imod OOXML) har gennemtrævlet forslaget til standard. Tak til jer! Det er værd at understrege, at standarden ikke er blevet lavet totalt om - den er derimod blevet forbedret på en række områder, hvor den trængte til finpudsning. Selve arkitekturen er den samme, dvs den energi man skulle have brugt på at anvende den eksisterende ECMA-376 er bestemt ikke spildt. Af de punkter, hvor jeg synes de største forbedringer er kommet, er:

  • Der er ikke længere noget krav om at skulle anvende VML i nye dokumenter
  • Angivelse af landekoder skal nu ske som specificeret i RFC-4646
  • Det er mere tydeligt, at OOXML skal anvende eksisterende, velafprøvede hash-koder som bla. specificeret ved FIPS-180
  • Conformance-kravene er blevet mere tydelige
  • Den berømte "leap year bug" er nu markeret som forældet
  • Det er muligt at anvende datoer før 1900
  • Formel-specifikationerne for regneark er nu beskrevet i EBNF-notation

Og hvad så med resten af de mange kommentarer som fx "Compatibility-elements? Tja - nu nævnte jeg blot de dele, som jeg synes er de vigtigste (og så har jeg naturligvis sikkert glemt nogle andre vigtige).


Yderligere svar fra ECMA

Svarene på de 750 unikke kommentarer fra de nationale råd er nu begyndt at komme i en lind strøm fra ECMA. Seneste udmelding fra ECMA er, at antallet af behandlede kommentarer nu er på 51% og tilgængelige fra det ISO/IEC-kontrollerede website. På seneste udmelding fra ECMA er tillige listet en del af de forslag, som de har valgt at følge. Det er en interessant liste, specielt da de faktisk var valgt at lave nogle ændringer, som jeg i hvert fald ikke havde regnet med de ville ændre. Listen er jo på deres website, men er tilføjet dette indlæg også:

  • Anvendelse af ISO-datoer
    Dette er faktisk én af de ting, som jeg er græsk/katolsk overfor, men det ser ud til, at man nu tillader persistering af datoer i regneark som både ISO-datoer og tal. Dermed gøres det på samme måde som i ODF, hvor man også har valget imellem tal eller datoer (hvilket i øvrigt har gået langt over hovedet på de fleste)
  • Internationalisering af ugedage
    Ét kritikpunkt af OOXML har været funktionen WEEKDAY() i regneark, der ikke tillader angivelse af en uge, der starter på andet end enten søndag eller mandag. Nu bliver det muligt at angive dagen, som ugen starter på
  • Sprog-angivelser
    Dette er så vidt jeg kan huske "ST_Lang-problematikken", hvor angivelse af datoer skulle gøre på to forskellige måder i stedet for at anvende en givet standard. Super!, at de nu bliver fixet
  • Side-kanter
    Angivelse af grafik til side-kanter var tidligere en lukket liste, dvs ikke ret fleksibelt. Nu bliver listen åben. Det er en god idé, da kontrol over dokumentets visuelle layout dermed gives tilbage til brugeren ... og ikke er forbeholdt formatet selv.
  • Formel-grammatik
    OOXML anvendte sin egen måde at beskrive formler, og ikke alene var det ikke en standardiseret måde at gøre det på, den var også mangelfuld. Nu ændres det til at anvende en såkaldt "udvidet BNF-notation". Den tekniske reference for dette er "ISO/IEC 14977:1996 – Syntactic metalanguage – Extended BNF."

Jeg deltog i ECMA-mødet 7. december 2007 og ISO/IEC-plenary 8. december 2007 i Kyoto som repræsentant for Danmark og jeg og de andre repræsentanter for forskellige råd var bla. en del af diskussionerne i ECMA af flere af punkterne herover. Det var rart at høre og få vished for, at de rent faktisk bekymrede sig for vores holdninger til deres rettelser og de spurgte flere gange konkret, om vores respektive holdninger til den ene eller den anden løsning. Det var tydeligt for mig, hvor vigtig godkendelsen af DIS29500 er, og formatet ikke var helligt i dets nuværende form, men at der var en accept af formatet ville blive ændret som et resultat af processen.

Skulle du være interesseret i at se mine egne, personlige, rejseoplevelser, så kig forbi www.ringtilcamilla.dk Smile