a 'mooh' point

clearly an IBM drone

Blog-roll update

Small note:

The other day I was mistakingly taken as being a Microsoft employee by Bob ... due to the contents of my Blog-roll.

Smile

So now the persons on it are sorted alphabetically and not in the order they were added. I hope this clears up any confusion. 

OOXML "T minus 14 dage"

Slutspillet omkring OOXML er i disse dage virkeligt gået ind i sin sidste fase og det er tydeligt, at nerverne begynder at sidde lidt udenpå tøjet. Det er næsten som de sidste 10 minutter af dette års SuperBowl imellem New England Patriots og New York Giants, hvor spændingen også næsten var uudholdelig. Udtrykket "May you live in interesting times" kommer virkeligt til sin ret.

Det er måske derfor passende at lave en opsummering af, hvad der er sket i det sidste års tid:

I december 2006 godkendte ECMA dokumentformatet OOXML som ECMA-standard (376) og indsendte den et par uger senere til ISO via den såkaldte Fast-Track procedure. Der var herefter en 30-dages "contradiction period" hvor de enkelte lande kunne fx redegøre for, om OOXML var i modstrid med andre ISO-standarder og om der var andre ting, der kunne diskvalificere OOXML og dens anvendelse af FT-proceduren. ISOs JTC1-sekretariat afgjorde i april 2007, at det ikke var tilfældet. Omkring dette tidspunkt udlagde Dansk Standard (DS) OOXML til offentlig høring og bad om branchens input til den. Dette resulterede i omkring 500 indvendinger i alt.

Herefter var der en 5-måneders afstemningsperiode, hvori debatten om OOXML fandt sted. Der kom en masse indvendinger imod standarden - både tekniske og politiske argumenter og disse lagde i store træk grundlaget for beslutningerne i de lande, der ønskede at stemme om OOXML i september 2007. I den periode deltog jeg via min arbejdsgiver CIBER i arbejdet i DS med at behandle alle indvendingerne. Det har været et hårdt - men også utroligt interessant arbejde at deltage i. Afstemingsperioden sluttede med, at hvert land valgte den stemme, som passede dem bedst. Danmark valgte "Dissaprove, with comments" og understregede, at skulle de danske kommentarer blive adresseret på passende vis, ville Danmark ændre sin stemme til et "Approve". Jeg støtter fuldt, at Danmark stemte "Dissaprove, with comments" i september 2007. Danmark ledsagede sin stemme med 168 kommentarer til standarden.

Det samlede resultat af afstemningen var, at OOXML ikke blev godkendt i ISO.

Hvis en afstemning om en standard falder i ISO, er ISO sådan indrettet, at der planlægges et "Ballot Resolution Meeting" (BRM), hvor man vil tale om, hvorvidt man kan rette nogle ting i standarden for at få nogle lande til at skifte deres stemme til et "Approve" eller "Abstain". Efter afstemingen begyndte ISO/IEC så at gennemgå de samlede kommentarer - der var 3522 i alt. Disse blev "kogt ned" til 1027 dispositioner, der udgjorde forslagsstillers (ECMAs) svar på det konkrete spørgsmål. I løbet af efteråret 2007 er disse dispositioner blevet sendt til de enkelte nationale råd og de er her blevet behandlet. I Dansk Standard har vi løbende fra oktober 2007 til februar 2008 behandlet disse svar og har været i dialog med ECMA omkring de svar, som vi ikke mente var gode nok.

I sidste uge af februar 2008 blev BRM-mødet afholdt i Geneve og Dansk Standard deltog i mødet for at varetage de danske interesser bedst muligt. Det var en meget hård uge, og de fleste af os var ret udmattede fredag eftermiddag, hvor mødet sluttede. Mødets formål var at tage stilling til konkrete ændringer til den oprindelige tekst og det var altså ikke et møde, hvor der direkte eller indirekte blev taget stilling til standarden i sig selv. Dette blev understreget af, at de enkelte landes delegationer arbejdede konstruktivt sammen omkring de enkelte emner - uanset om de var imod- eller for OOXML. Udfaldet af mødet blev, at godt og vel 98% af samtlige 1027 dispositioner blev godkendt - herunder alle de danske. Der var i ugen efter BRM heftig kritik og debat om udfaldet, men heldigvis er det nu faldet til ro, og der er efterhånden konsensus om, at alle regler blev overholdt. Der er i skrivende stund ikke indgivet nogen klager over selve processen.

Men hvad så nu?

I Dansk Standard er næste møde berammet til 26. marts, og her skal vi tale om, hvorvidt vi skal ændre vores stemme fra "Dissaprove" til noget andet. Det bliver et spændende møde, og jeg ser frem til nogle gode diskussioner til mødet. Målet er, som Dansk Standard skriver, at opnå en eller anden form for konsensus om, hvad Dansk Standard anbefales at gøre.

Indtil da sker der ikke så meget på formelt plan i Dansk Standard, så vi kan jo følge med i, hvad Morten Messerschmidt og Helge Sander finder ud af med konkurrencestyrelsens undersøgelse af konsekvensen af beslutningsforslaget B103 fra marts 2006.

Smile 

Why ISO-approval of OOXML is not an option

Now that the BRM has been done for about a week, I can't help but think back on what has happened in the past 9 months - the BRM was a pretty big mile-stone. It has been a crazy time and a crazy process to be a part of ... especially since the way the world usually works has been turned upside-down. On one side we have Microsoft making the file format of their Microsoft Office Suite publically available, thus being "open", and on the other side we have the OSS-community yelling "We don't want it, since it is too much like the internal format of your Microsoft Office Suite".

One of the first major mile-stones was when the EU-Commission in 2004 asked Microsoft to submit the file format of the Microsoft Office product line to an international standards body. Now, when the EU-Commission asks you for something, it is generally really just a polite way to say: "You must" ... much like when a police officer wakes you up outside of a bar and says: "You really should go home now".

IDABC: Microsoft should consider the merits of submitting XML formats to an international standards body of their choice;

So Microsoft did what they were told - they submitted their file format to first ECMA and then ISO. They didn't start from scratch and make the mother of all generic file formats - they took the file format of their Microsoft Office Suite and made it publically available for everyone to use. Essentially they said: "This is what we use - now you can use it too".

I have often been accused of being too gullable by those opposing OOXML - especially those that don't trust Microsoft as far as they can throw them. Sadly, they just don't get it

I'm not advocating ISO-approval of OOXML because I trust Microsoft to do the right thing -  I am advocating ISO-approval of OOXML because we as society cannot afford the possibility of Microsoft not doing the right thing

Microsoft opponents should actually be the ones screaming "Microsoft, put OOXML in ISO - we don't trust you". Instead they say "Microsoft. we don't trust you - kep your file format to yourself". I'm sorry, but I don't understand this. Rick Jellife has advocated that all protocols, APIs and document formats of major players in a given industry should be made part of the public domain (Rick, I have been trying to find the blog-entry where you mentioned this, but unsuccessful. If you (or anyone selse) have it, please send it to me and I'll update this article) (update: I found it myself). I agressively second this notion. We should not only encourage ISO-approval OOXML (and other important file formats) - we should demand it. This is what the EU-Commission wisely did.  In contrast to the American way of letting the marked decide what to do (my American friends, please take note of this) - the EU-Commission said that it is totally unacceptable that the file format of the Office Suite with a 95% install base is out of reach of governments, NGOs, competing companies etc. I totally agree. We want it to be defined and maintained in a forum, where we have a say - and that forum is the ISO. Rob Weir is correct when he on Tim Bray's blog said "IMHO, this really isn't a question of whether OOXML should exist or not. OOXML is here, just like the binary formats before". But he shows a slight lack of understanding of the big picture in his next sentense where he says: "The question is whether OOXML should be given ISO standard status in addition to being an Ecma standard.".

Rob seems to be under the impression that ISO-approval is some kind of quality badge of honor that you can proudly carry around. First of all, I think we can all agree that ODF itself is a clear example that ISO-approval not necessarily implies quality, interoperability and clearness. Secondly, how the specification was made is not the first priority when talking ISO-approval. The first priority should be:

We need to take control of OOXML out of the hands of Microsoft and back into society as a whole

This was imho the focal point of Patrick Durusau's support of DIS 29500 approval. Amongst other things he said that

Patrick Durusau: The cost of rejection is that ordinary users, governments, smaller interests, all lose a seat at the table where the next version of the Office standard is being written

This is my point!

Let's talk ISO-approval first - then quality. This is a whole new approach of ISO-usage (at least within IT), where we as society demand proprietary formats, APIs and protocols to be put in ISO - because the costs to society of not doing so are simply too big. We should use ISO as a tool to gain greater insight and control of important parts of the IT infrastructure. We need it in ISO, since IS's members are countries and not companies. This is our turf!

Some might say "hey, Microsoft will never abide by the format put in ISO - they'll simply extend it". Well, we should demand something else of them. We should do as the Danish Government wisely chose last year: A procurement requirement saying that new software must support, in our case, ODF and OOXML. Stop talking about applications - start talking about file formats! The bottom line of the Danish decision is that if Microsoft Office doesn't follow the rules of OOXML, it will either not be bought or not upgraded to. Microsoft Office being Microsoft's #1 revenue stream - they will not be able to ignore this. So to enhance competition we need to do two things:

  1. Demand that e.g. a file format is put in ISO
  2. Demand that the applications conform to this format

 

That should be our focus - and not trashing and badmouthing the competing format. In his latest article, Patrick Durusau tells a story of an angry Russian pessant.

One evening, through a cold miserable rain, a hungry Russian peasant was walking home. A luminous being appeared in their path. "Please! If you will make one wish, it will free me from my prison!" The genie pointed to an oddly shaped lamp on the side of the path. "Wish for anything you want, food, power, wealth, ..., anything!" The peasant grunted, "I wish my neighbor's cow would die," as he pushed past the genie to continue home.

The strategy behind NOOXML strikes me as being quite similar to that of the Russian peasant. It seeks nothing that would benefit itself, no new product to sell to customers, no new service to serve as a revenue stream. It is simply a wish that "...my neighbors cow would die."

Come on, guys ... let's move on! Let's stop bitching about the file formats and their differences and let's start doing what we all love the most - building applications on top of them.

Smile

... which brings me back to the headline of this article:

ISO-approval of OOXML is not just an option - it really should be a requirement. 

BRM resolution documents now available

The BRM resolution documents are now publically available from the JTC1-SC34 website.

Take a look at them on

http://www.itscj.ipsj.or.jp/sc34/open/0989.pdf

http://www.itscj.ipsj.or.jp/sc34/open/0990.pdf 

Smile

Patrick Durusau supports approval of DIS 29500

Now, this is one of the times where I realize that all of us supporting OOXML in ISO are not complete morons ... even though it is the point of view of many of the participants. Patrick Durusau has now openly stated his position on OOXML in ISO, which is: Welcome to the party!

I am sure everyone supporting OOXML in ISO will run around in the next days chearing their heads of ... and that the anti-OOXML-wolf-pack will do the same ... but more in the way of "chicken without a head".

Please read the statement from Patrick Durusau yourself - let me just make this small quote:

That point of agreement is that everyone at the table was heard. That may not seem like a lot to an Oracle or IBM, but name the last time Microsoft was listening to everyone in a public and international forum? At a table where a standard for a future product was being debated by non-Microsoft groups?

Smile

Now I get it - ODF and MathML

(see updated content below) 

Some time ago I wrote an article about ODF and usage of mathematical content by MathML. One of the quirks I couldn't get my head around was why the XML-file containing the MathML-document had to be named "content.xml". I used the phrasing

This was a bit more tricky, since somehow it seems that the mathical formula can only be contained in a file called "content.xml" - otherwise OpenOffice.org simply shuts down.

Well ... the answer came to me almost in a dream - or at least in the evening in one of those semi-awake-states. Basically the answer lies in the answer I never got on my question on which parts in an ODF-poackage are mandatory and if there are any parts with pre-defined names. The ODF-specification  section 9.3.3 says for embedding objects:

  • The xlink:href attribute links to the object representation, as follows:
    • For objects that have an XML representation, the link references the sub package of the object. The object is contained within this sub page exactly as it would as it is a document of its own.
    • For objects that do not have an XML representation, the link references a sub stream of the package that contains the binary representation of the object.

Now, in ODF MathML clearly has an XML-representation and MathML is also a "real" "OpenDocument representation". So a MathML is stored as a "sub package" within the ODF-package itself. And that brings me back to my original question.  You see, even though a piece of MathML is not a OpenDocument file per se, it still has to be embedded as an entire ODF-package (without the ZIP-structure). Section 2.1 clearly states this as

A document root element is the primary element of a document in OpenDocument format. It contains the entire document. All types of documents, for example, text documents, spreadsheets, and drawing documents use the same types of document root elements. The OpenDocument format supports the following two ways of document representation: 

  • As a single XML document.
  • As a collection of several subdocuments within a package (see section 17), each of which stores part of the complete document. Each subdocument has a different document root andsstores a particular aspect of the XML document. For example, one subdocument contains the style information and another subdocument contains the content of the document. All types of documents, for example, text and spreadsheet documents, use the same document and subdocuments definitions.

And since an ODF-package requires the main part to be called "content.xml" the MathML-file needs to be called "content.xml" as well. There is also no manifest file in the sub-package to tell the name of the package part - hence the requirement to have a fixed part name for the main part.  I wish this information was more clearly described in ODF and not simply implied in the text.

... did I mention that I prefer the relationship-model of OPC?

Smile

(update  2008-05-16)

A bit down in the comment track of this post I promised to make an ODT-file with MathML embedded inline as opposed to the "regular" OOo-way of embedding it as a seperate object. Today I finally got around to doing it. It was actually really easy - I just took the embedded MathML-object from the ODF-package and pasted in into the correct location in the content.xml-file. A good thing is that with this approach you don't have to worry about specifying a DOCTYPE (the OOo-dependancy), so I would say this is highly recommendable. The XML looks like this:

[code=xml]<draw:frame
  draw:name="Objekt1"
  text:anchor-type="as-char"
  svg:width="2.972cm"
  svg:height="1.138cm"
  draw:z-index="0">
  <draw:object>
    <math:math>
      <math:mrow>
        <math:mtext>cos</math:mtext>
        <math:mo>(</math:mo>
        <math:mfrac>
          <math:mi>pi</math:mi>
          <math:mn>4</math:mn>
        </math:mfrac>
        <math:mo>)</math:mo>
        = <math:mo>(</math:mo>
        <math:mfrac>
          <math:msqrt>
            <math:mn>2</math:mn>
          </math:msqrt>
          <math:mn>2</math:mn>
        </math:mfrac>
        <math:mo>)</math:mo>
      </math:mrow>
    </math:math>
</draw:object>
</draw:frame>[/code]

When opened in OOo (2.4 DA) the result looks like this:

 


Only remaining quirk is the missing "equals-sign", but I haven't had time to dig into those details yet.

If anyone can help and contribute here, that would be great.

 

T-Shirts for everyone

On the last day of the BRM I posted an image emailed to me during the very last minutes of the meeting. This image has now made it to CaféPress. Now this's one for the beaches this summer!

Check it out ... 

 

Update 2008-03-23:

If you have pictures - please send them to me ... I'll post them here.

Smile


(notice sticker) 

BRM aftermath

Sitting in the airport in Geneva waiting for my home-bound fight I finally have a couple of hours to do nothing but reflect on what happened through last week.

It truly has been a magnificent week. About 120 people from a bit more than 35 countries from around the world participated in the technical discussion in improving the OOXML-spec (DIS 25000). It was a monstrous task and I think we all felt a bit nervous on the first day – at least I can see Tim Bray was as nervous as I. The task at hand – to reach consensus on the 1000 odd responses from ECMA – was an impossible task given the 5 working days we had, so I was anxious to find out what the convener Alex Brown had up his sleeve. We, the delegates at the BRM, have naturally been talking a great deal in the corridors between sessions, in the hotel lobbies and everywhere else we got together about how to solve this “Gordian knot” and countless emails have been exchanged between us about this very subject. We have also talked a lot about this afterwards and have tried to do some evaluations on the process chosen by the BRM. It is always nice to do this – hind-sight is 20/20-vision.

Smile

Let me also note that I was deeply impressed about the technical level of the delegates. We had some really good and in-depth discussions during the week. Countries that particularly impressed me were Canada, UK, USA, Germany, Israel and The Czech Republic. I appologize to those I forgot.

I think the process chosen was the best process given the circumstances. All alternatives were in my opinion worse than the one chosen – and I think it is important to emphasize that the process was chosen by the BRM and not chosen for the BRM. The way the BRM works is normally this: When a DIS fails it is evaluated if the countries voting had a desire to approve the specification – but that they didn’t feel the specification was good enough. If this is the case a BRM is scheduled and the purpose of the BRM is to improve the specification so that the countries can change their vote from “No” to “Yes” (or any other way). The result of the BRM is a list of improvements or changes to the DIS. These improvements have to be presented and approved (preferably by consensus) by the BRM itself. So the rules governing the BRM essentially meant this: If a piece of text is not presented to the BRM, it cannot get approved and hence incorporated into the failed DIS. A side note is that at the BRM the member-status of SC34 does not count, so O-members are not treated differently than P-members (at least that was my understanding).

When talking to the other delegates we more or less agreed that the number of Responses not dealt with would be something in the area of 800-850 in total. So we basically had two choices:

  • Do nothing
  • Do something

The BRM chose to do something. We didn’t all agree to what to do and as it has been reported all over the blog-sphere, most parts of a whole day was spent discussing what to do. I think most of the delegates disliked the position we were put in – but regardless of this we were in this situation whether we liked it or not. We had to do something.

That “something” was to do a vote on each of the remaining responses from ECMA. It was not a bulk-vote as reported on various sites – it was a vote on each and every single response.

I will not comment on what individual countries (including my own) voted and their reasons for it, but it seemed to be from discussing this, that the various reasons given for a specific vote fell into these categories:

  • We think the responses from ECMA are generally an improvement to the DIS and therefore we approve all responses not dealt with during the BRM
  • As a principle we cannot do anything but disapprove responses that have not been dealt with
  • We think the BRM is about reaching consensus and this vote bypasses this process and we therefore disapprove  all responses we haven’t dealt with
  • We will vote “yes” or “no” to those responses we have a qualified opinion about and we will abstain on the rest. This effectively means that the “fate” of these responses is left to those countries that actually have an opinion on them
  • We don’t want to participate in this vote at all

… and the rest, as they say, is history.

Smile

Within minutes of after Friday 29th of February at 17:00 rumors started to flow that “The BRM failed” or “ISO failed”. I honestly disagree to this. We were facing an impossible task but we dealt with it according to the purpose of the BRM: To change and improve the DIS. There is really nothing more to say about it. Now the national bodies can sit down and look at the result of the BRM and see if the DIS is now in a position to be approved. That process has always been aside to the BRM itself and whatever was voted on and how the votes were distributed is really not relevant in terms of approving the DIS. The DIS is now what it is and that is what is to be decided 29 days from now.

And now for a few quotes from inside the BRM:

“We need a precise definition of inaccuracy”

“The <country omitted> would like to note that there are actually ‘normal’ people that don’t speak English natively”

“Convener: <country omitted>, you had a comment?
Country: I have absolutely no idea“

Smile

(and now my plane is delayed for at least two hours)

Namedropping in Geneva

So - that was it ... it really was. The BRM ended a bit less than an hour ago and I am now back at my hotel. I have previously been accused of name-dropping too much, but I'm glad to be able to say, that I have now been name-dropped. At least Dough Mahugh was kind enough to mention me yesterday before rambling about burning his suit. It has been a pleasure to work with all these 120 people frm 37 countries in the last week and it has been great to finally get to meet Rob Weir, Tim Bray, Charlez H. Schultz (who attended the OFE-meetings down-stairs) and of course Alex Brown.

I will be back with more info lter this weekend ... when I am no longer as sleep-deprived as now.

Smile

I love BRM

 

 

Thanks to the Portugeese delegation Smile