a 'mooh' point

clearly an IBM drone

Ja, man tager sig jo til hovedet

Den anden dag kunne bla. version2.dk fortælle, at Microsoft har tilbudt finansiel støtte til (udvalgte) svenske partnere, hvis de ville stemme "Ja" til OOXML-afstemningen i det svenske SIS-udvalg.

Jeg kan slet ikke forstå, at personen, der sendte disse emails åbenbart stadig er ansat i Microsoft i Sverige. Det er simpelthen så tosse-åndssvagt gjort og personen burde fyres på gråt papir - evt skrevet med fonten "Comic Sans-serif". Jeg er helt sikker på, at for ORACLE, IBM og Microsoft er hele sagen om ISO/OOXML et minefelt uden lige at bevæge sig i, og at formulere en email som denne er et bevis på, at personen ikke har været sit ansvar voksent og har fejlvurderet situationen totalt.

Personligt kan jeg blive så edderspændt rasende over fodfejl som disse. Jeg er af den opfattelse, at IBM, ORACLE, Microsoft og andre spiller "spillet" på samme måde i øjeblikket - og jeg er helt sikker på, der ikke er forskel på de våben de anvender. Man kan måske sige, at (primært) IBM spiller deres kort lidt mere elegant end Microsoft gør i dette tilfælde.

Når jeg bliver så edderspændt sur, så skyldes det, at fejl som disse falder tilbage på sådan nogen som mig. Jeg står fuldt ved min opfattelse af, at OOXML skal ISO-certificeres og jeg baserer denne opfattelse på det tekniske overblik jeg har over formatet. Jeg er også klar til at snakke om forskellige forhold i det omfang nogen skulle ønske det. Jeg har aldrig modtaget noget som helst økonomisk og finansielt af Microsoft eller andre for mit arbejde med OOXML. Men når det alligevel falder tilbage på mig, så skyldes det, at mine argumenter for OOXML nu bliver set i lyset af hændelserne i Sverige, og andre kan (med rette) påstå, at mine holdninger er købt af Microsoft eller andre af dens partnere. Jeg forsøger selv at bygge mine argumenter på et teknisk grundlag - det politiske interesserer mig ikke synderligt - men når Microsoft gør som de gjorde i Sverige, så er det så stort et selvmål i form af "tabt terræn" at klaphatten i Parken til fodboldkampen for et par måneder siden i den grad må se sig slået i forhold til selvdestruktiv adfærd.

Microsoft i Sverige: I burde fandeme skamme jer! 

Trapped in a monopoly's web

Monopolies or monopoly-like situations are seldom a benefit for anyone in the long run - except for the monopolist itself, naturally.  This is regardless of wether the monopoly is controlled by Microsoft, iTunes, Ford, Fox News or Google. Sadly I've been caught in the dominated market of the latter.

Basically, I have/had a need to figure out the amount of a specific filetypes located on the internet. Luckily, Google has a method for doing just this. You simply supply a  "filetype:"-argument to your search, and you can then figure out, that there are roughly 93.700 files of the type "Open Document Text", which are created e.g by the office applications KOffice or OpenOffice. You can also determine that there are roughly 45.100.000 documents of the type "Microsoft Office Word Document", primarily created by the office application Microsoft Office. Now, you can also see, that there are just 1040 files of the type "docx", the filetype of the document type "OOXML".

See, this is kindda weird, since docx-files is the default format for the office application Microsoft Office 2007 - the latest edition of the Microsoft Office-suite ... and by far the most used office application in the world. 1040 files doesn't sound like a whole lot - and it doesn't seem to rightfully represent the document world as it is right now. Some have even spun this as the ... ahem ... naïve ... proof that the world doesn't care about OOXML and that the proposed market penetration of it is a joke.

So ... watcha-ya-gonna-do? Well, I looked at the Google search results and I noticed something. The results of the ODT-search included data like:



Notice that Google's index recognizes the file as a OpenDocument file and correctly displays a portion of the content of it.

But when I looked at the results for the docx-search, it listed data like this:

In case you don't read and understand Danish, Google says that the filetype is unknown ("Ikke genkendt") and - as a consequence - it cannot display the file correctly. Notice also that Google somehow actually managed to display the contents of the embedded files in the docx file container. Well, my conclusion of this is, that OOXML-files are propably not included in Google's index at all and that the few files represent a few "off bits" in Google's spiders/crawlers. Hence the comparison between the result of the odt-search and the docx-search is ... well, moot. Of course ... if you had, say, a business need for it, you could always conclude that there are no docx-files on the internet. My take on this argument is:

Dear Rob, your argument concerning the market penetration of OOXML is the - in the words of Comic Book Guy from the Simpson's - worst argument ever ...

And this brings me back to the title of this post -  coz what can you do, when Google fails? I've looked far and near to find a way to do a similar search, but so far without any luck. Some search-engines allow searh for file types - but limit the choices of valid file types. Most search engines doesn't allow file type search at all. I naturally tried searching using LIVE, but I cannot figure out if it is even possible to have it do the search for me. I have been through most of the engines listed through Search Engine Watch ... but it was a fruitless effort.

My question to you is: where can I go to to find the fact I'm looking for? 

Værktøjer, ODF, AODL

I de sidste par dage har jeg kigget på de tilgængelige værktøjer til generering af ODF-filer - pt. AODL. AODL er en del af ODF Toolkit til generering af ODF-dokumenter og AODL er C#-versionen af dette kit. Kildekoden til dette toolkit kan hentes fra OOs' CVS-repository.

Et ODF-dokument er jo reelt "blot" et ZIP-arkiv indeholdende en række folder og filer og det er et eller andet sted ikke noget, som er relevant for særligt mange. AODL ligger som et objektmæssigt abstraktionslag over dette faktum - og når man anvender biblioteket behøver man ikke at vide dette - altså før det tidspunkt, hvor koden ikke virker. Her er det til gengæld væsentligt at have viden om denne ZIP-fils sttruktur i forbindelse med fejlretning. Ved anvendelse af biblioteket danner man et "regnearks-objekt" (SpreadsheetDocument), hvis man vil lave et regneark, et "teksbehandlingsobjekt" (TextDocument), hvis man vil danne et tekstbehandlingsdokument etc. Man kan tilføje et afsnit (Paragraph) til et tekstbehandlingsdokument og lignende. Abstraktionsmæssigt er implementeringen altså meget tæt på den måde, som man bruger et tekstbehandlingssystem på og det er ganske intuitivt at komme igang med at lave dokumenter.

Et eksempel på dette taget fra AODL-code snippets, der viser dannelse af et tekstbehandlingsdokument:

TextDocument document = new TextDocument();
document.New();
Paragraph paragraph = ParagraphBuilder.CreateStandardTextParagraph(document);
FormatedText formText = new FormatedText(document, "T1", "Some formated text!");
formText.TextStyle.TextProperties.Bold = "bold";
paragraph.TextContent.Add(formText);
document.Content.Add(paragraph);
document.SaveTo("formated.odt");

Ganske tilsvarende er eksempelkoden til generering af et regnearksdokument med en celle med indhold:

SpreadsheetDocument spreadsheetDocument = new SpreadsheetDocument();
spreadsheetDocument.New();
Table table = new Table(spreadsheetDocument, "First", "tablefirst");
Cell cell = table.CreateCell("cell001");
cell.OfficeValueType = "string";
cell.CellStyle.CellProperties.Border = Border.NormalSolid;          
Paragraph paragraph = ParagraphBuilder.CreateSpreadsheetParagraph(spreadsheetDocument);
paragraph.TextContent.Add(new SimpleText(spreadsheetDocument, "Some text"));
cell.Content.Add(paragraph);
table.InsertCellAt(2, 3, cell);
spreadsheetDocument.TableCollection.Add(table);
spreadsheetDocument.SaveTo("F:\tests\simple.ods");

Jeg vil vove den påstand, at selv folk uden dyb programmeringsmæssig baggrund vil kunne give en beskrivelse af, hvad koden gør. Two thumbs up herfra!.

Kodegennemgang:

Selve designet af det begrebsmæssige abstraktionslag for ODF er - sagt igen - rigtigt godt. Jeg kan godt lide at arbejde med objekter med semantisk mening og arkitekturen er sådan relativt gennemført. Der anvendes polymorfi, nedarvning og objekterne er definerede via interfaces de rigtige steder. En løs gennemgang af koden indikerer, at de har lavet det rigtigt godt.

Men mest interessant - uderover objektmodellen - er jo hvordan den bruges. På objektet TextDocument findes en SaveTo()-metode med to overloads. SaveTo() er defineret i interfacet IDocument som både TextDocument() og SpreadsheetDocument() implementerer. Den mest simple af disse overloads tager en "filename"-parameter som argument. Naturligt nok gemmes indholdet af dokumentet i den specificerede fil. Den anden metode tager - udover en filename-parameter - et "IExporter"-objekt. Idéen med dette objekt er, at man kan gemme sit ODF-dokument ved at specificere en konkret exporter. Der medfølger en "PDFExporter" med AODL, og man må antage, at den gemmer ODF-dokumentet som en PDF-fil (jeg har ikke prøvet selv). Idéen er faktisk rigtigt god. Det er dermed muligt at implementere en konkret exporter - til HTML, RTF, OOXML eller hvad man måtte ønske - og så medsende den som argument til SaveTo-kaldet. Men der mangler i mine øjne en overload til SaveTo-metoden. Metoderne jeg kunne ønske mig at have i IDocument-interfacet er:

void SaveTo(System.IO.Stream stream);
void SaveTo(System.IO.Stream stream, AODL.Document.Export.IExporter iExporter);

Rationalet er, at det ikke altid er tilfældet, at man har behov for at persistere et dokument i en fysisk fil på disk. Naturligvis man kan hente den dannede fil fra disk og lave en stream af dette, men det er en lidt omvendt metodik. Skal et dokument dannes via en JIT-tankegang og sendes til fx en browser fra en web-applikation, er det et unødigt niveau af kompleksitet først at skulle danne filen på disk. Her kunne det være lækkert at kunne sende dokumentet til fx en MemoryStream og derefter til klienten. I/O-mæssigt ville dette være det mest optimale. At insistere på at danne en fil undervejs afstedkommer nemlig også yderligere problemer. Selve AODL skal nemlig konfigureres til at gemme filer på bestemte steder og i forbindelse med anvendelse af AODL på web er det ganske sandsynligt at det kommer til at give problemer med skriverettigheder til disk. Men hvis jeg lægger mine "bruger-briller" på hylden og i stedet kigger på AODL med udviklingsøjne, så kunne de næsten ikke implementere det på andre måder. Som nævnt ovenfor er et ODF-dokument reelt en fil- og folderstruktur, der er zippet i en fil. Indholdet af denne zip-fil skal jo være et eller andet sted indtil den dannes, og da der mig bekendt ikke findes metoder til at persistere en folderstruktur i hukommelsen, så har de været nødt til at lave den konkrete implementering.

Konklusion

Helt overordnet set er AODL et behageligt framework at arbejde med. Objektmodellen er intuitiv og let tilgængelig og da den er et OSS-projekt er kildekoden til det også fri. Det er helt klart en fordel og jeg drog netop nytte af dette, da jeg skulle finde ud af, hvordan framework'et var skruet sammen. På den negative side tæller at der i mine øjne mangler nogle muligheder for at gemme til andet end en disk. Det er også frustrerende at dokumentationen er sløset sat sammen - fx er kommentaren ved flere metoder og klasser "Summary of <some class>" - hvilket et default-kommentaren i Visual Studio 2003. Det kunne være rart med en mere gennembearbejdet dokumentation. Hvis man dykker helt ned i koden og eksemplerne herover, vil man lægge mærke til, at der efter instantiering af fx TextDocument() kaldes metoden .New(). Det synes jeg ærligt talt er en smule bekymrende, da et generelt designprincip i OOP er, at et objekt som udgangspunkt skal være klar til anvendelse efter en ctor er kaldet. At kræve at en ekstra metode afvikles er blot at introducere fejl. Fejlhåndtering i klassebiblioteket er også reelt ikke-eksisterende, da fejl blot genkastes, og det giver et overordnet indtryk af, at AODL ikke kvalitetsmæssigt er helt i top.

Min vurdering (af max 5 mulige smileys):

SmileSmileSmile

Værktøjer til dokumentgenerering

I Danmark har bølgerne efterhånden lagt sig efter forårets intensive debatter om valg af dokumentformater i den offentlige sektor i Danmark. Det var jo en debat, som jeg deltog ret kraftigt i, og jeg må ærligt erkende, at jeg er glad for, at der kun er nogle få pip tilbage hist og pist. Vi er naturligvis ikke blevet enige - og roen skyldes sikkert også sommerferien - men det er glædeligt, at tonelejet er kommet ned på et behageligt niveau.

Jeg vil derfor lægge diskussionerne på bla. version2.dk lidt til side - eller i det mindste barbere dem næsten helt ned. Jeg har fundet ud af, at jeg kan udøve indflydelse bedre på andre måder end diskussionsfora, så jeg vil i stedet koncentrere mig om noget, der ligger mig tættere på hjertet - nemlig programmering. I de næste uger vil jeg kigge på, hvilke værktøjer der findes til automatisk dokumentgenerering af ODF-dokumenter samt OOXML-dokumenter. Jeg vil sandsynligvis primært kigge på tekstbehandlingsdokumenter samt regneark. Platformen jeg vil anvende er .Net ( C# ) til begge formål.

Som det ser ud lige nu, så vil jeg kigge på mulighederne for dokumentgenerering via de nyeste værktøjer. Det vil konkret sige værktøjerne til OOXML fra Microsoft til .Net 3.0 . Til generering af ODF-dokumenter har jeg fundet pakker som AODL, og disse bliver udgangspunktet for arbejdet med ODF-generering. Jeg har endnu ikke gravet værktøjerne frem til dokumentgenerering til OOXML, men jeg tror, at et godt udgangspunkt vil være openxmldeveloper.org .

Generelt: hvis du kender til værktøjer til C#, der kan generere ODF-dokumenter, så sig endelig til. Jeg får også brug for noget C#-kode, der kan danne MathML til brug i mine ODF-dokumenter, så sådanne biblioteker skal jeg også have fundet.

Jeg har opfundet et ord

Den anden dag, da jeg sad og skrev på indlægget "Er det nok at standarden er åben?" blev jeg træt af hele tiden af skrive "ODF-only-fortalere". Ikke alene er det træls at taste - det er også typografisk lidt et grimt ord. Derfor fandt jeg på at bruge forkortelsen "oODF", der fra nu af betyder Only-Open-Document-Format. Til min store positive overraskelse begyndte andre folk også at bruge det - faktisk gik der ganske få timer fra jeg brugte det på version2.dk til det blev brugt af andre.

Men nu ruller snebolden!

  • Søg på Google efter OODF og min blog kommer frem som nummer 1 (ændrer sig nok igennem tid)
  • Søg på overskrift.dk og min blog kommer frem som nummer 1

... og for at det ikke skal være løgn, så har jeg oprettet ordet på wiktionary.org .

Som min gode tidligere kollega Søren Laurits Nielsen sagde: "Det er sandt hvad jeg siger. Du kan selv checke det på Wikipedia ... om 10 minutter".

Smile

Høringssvar til Dansk standard

Jeg har lavet mit første udkast til mit arbejdes høringssvar til Dansk Standard for accept af OOXML til videre behandling i ISO-systemet. Jeg blev bedt om dette af min chef, da han mente, at jeg nok var den person i virksomheden, der var mest kvalificeret til det og i øvrigt også brændte mest for det.

... det kan han jo have en pointe i

Smile

Det var dog noget sværere at skrive end jeg havde regnet med. Jeg valgte bevidst den strategi at lave en positiv kommentar i stedet for en negativ kommentar i forhold til ODF ... det ville jo have været det nemmeste. Der er faktuelt masser af steder, hvor OOXML er ODF teknisk overlegent, så der ville sådan set have været masse af krudt at fyre af. Jeg er også sikker på, at en lang række af de andre kommentarer til Dansk Standard fra oODF-fortalerne vil lave negative sammenligninger af ODF og OOXML. Jeg synes bare ikke, at det er den rigtige måde at argumentere på og jeg er generelt ikke så meget for "name-calling". Den eneste reference jeg reelt har lavet til andre standarder er i et afsnit, hvor jeg snakker om, at vi ikke ser et principielt problem i at have flere standarder for dokumenter - specielt ikke når de som tilfældet er med OOXML og ODF ikke dækker samme områder.

Men det var som sagt sværere end jeg havde regnet med. Dette skyldes flere ting - hvoraf én var den vinkel jeg havde valgt. En anden ting var dog det simple faktum, at kommentarerne sikkert bliver offentliggjort efter indsendelsesperioden er ovre, og jeg er sikker på, at svarene fra vi fortalere forbåde OOXML og ODF vil blive fluekneppet som aldrig før. Det har dermed betydet, at jeg har været super opmærksom på, hvilke ord og vendinger jeg bruger og hvilke ting jeg har fjernet. Når jeg debatterer her og på version2.dk er tonen jo relativt løssluppen ... ja jeg er faktisk blevet citeret i version2.dks fysiske udgave med bandeord. Men virkeligheden er jo en noget anden, når jeg skriver et officielt svar på vegne af min arbejdsgiver. Flere løse formuleringer kom dog også med i de første afsnit, men de er blevet fjernet igen.

... der er jo ingen grund til at give oODF-fortalerne mere krudt til deres pistoler.

Rick Jelliffe har formuleret følgende i en artikel om standarder for vurdering af standarder:

"The tactic adopted by some activists is to read the draft text, think of the worst possible interpretation and ramification, then insist it is the case"

Det er præcist sådan jeg nogle gange føler behandlingen af OOXML. Se blot på diskussionen på version2.dk, hvor jeg til sidst måtte sige stop.

Han skriver lidt videre:

"The trouble with this approach is that it won’t work; impartial reviewers will note that there is some kind of concern but that the actual issue raised does is not a problem. The result will be frustration and a lack of a “meeting of the minds”. Indeed the legitimate issues that underly some of the anti-OpenXML comments risk being unaddressed."

Var der nogen, der sagde "du skyder dig i foden"? 

Bit-masks i OOXML

Når kampen for OOXML og ODF er så meget op ad bakke skyldes det i høj grad usikkerhed om, hvad der rent faktisk er fakta i diskussionen. Én af kilderne til denne usikkerhed er desværre Grokdoc.net. Når jeg skriver "desværre" er det fordi Grokdoc har lavet en ganske omfattende gennemgang af specifikationen for OOXML (hvilket jo i sig selv piller ved argumentet om, at den er for stor til at nogen andre end Microsoft kan overskue den), men den er desværre også fejlbehæftet. De fejlbehæftede dele er ikke så store - problemet ligger i, at det netop er disse fejlantagelser, der bliver brugt som primære argumenter imod OOXML som standard.

Én af disse fejl er de såkalte "bit-masks".

Der er såmænd ikke så meget forkert i selve observationen af, at der er bitmasks i OOXML-spec. Problemet ligger i, at problematikken i deres tilstedeværelse overdrives, ja Rick Jelliffe fra O'Reilly går så langt som at sige: "Some of the technical claims are silly (such as the "bitmask rubbish").

Grokdoc definerer en "bitmask" som:

"A bitmask is a technique to encode multiple values inside a single variable, by assigning a meaning to each individual bits of the variable. For example, the binary 10110001 (decimal 177) would mean Yes/No/Yes/Yes/No/No/No/Yes and contain the answers to 8 different yes/no questions." Grokdoc inkluderer herefter en liste over de steder i OOXML-spec, der omhandler bitmasks af forskellig art.

OOXML indeholder en række eksempler på anvendelsen af disse bitmasks. Ét af eksemplerne er fra sektion 2.8.2.16 for attribut usb1:

[Example: Consider font information specified as follows:
<w:font w:name="Times New Roman">
<w:sig w:usb2="00000008" … />

</w:font>
The usb0 attribute value of 80000000 specifies that the first 32 bits of the bitfield are
00000000000000000000000000001000, which corresponds to:
Arabic Presentation Forms-B
end example]

Læg her mærke til, at bitmasken er en string-repræsentation af en Hex'et bitværdi.

Et andet eksempel som jeg selv er faldet over tidligere (men ikke er nævnt på Grokdoc) er fra afsnit 2.8.11 ST_Cnf (Conditional Formatting Bitmask):

Fra OOXML-spec har jeg klippet følgende forklaring:

10 This simple type specifies the format for the set of conditional formatting properties that have been applied to
11 this object.
12 These properties are expressed using a string serialization of a binary bitmask for each of the following
13 properties (reading from the first character position right):

[Example: Consider a paragraph in the top right corner of a table with a table style applied. This paragraph
35 would need to specify the following WordprocessingML:
36 <w:p>
37   <w:pPr>
38     <w:cnfStyle w:val="101000000100" />

1       …
2     </w:pPr>
3     …
4 </w:p>
5 This paragraph specifies that it has the conditional properties from the table style for the first column, first row,
6 and the NW corner of the parent table by setting the appropriate bits in the val attribute. end example]

Grokdoc har følgende indvendinger overfor anvendelsen af disse bitmasks:

1.Bitmasks cause significant validation problems

Using bitmasks creates a new data model, separate from the XML data model. In particular, the bitmask cannot be described in or validated by XML Schema, Relax NG, Schematron or any standard XML schema language or current validator.

Selve bitmask-værdien er en ganske almindelig element-attribut og OOXML-spec beskriver endda, at indholdet af denne her skal matche det regulære udtryk [01]* . At sige at det ikke kan lade sig gøre at validere denne værdi er en pudsig anke imod OOXML, da man jo heller ikke kan validere andre (komplekse) værdier i en XML-fil for mening. Selvom jeg anvendte enums i mit XML-schema ville jeg ikke kunne validere om det enkelte "1" eller "0", hhv "true" eller "false" rent faktisk gav mening.

2. Bitmasks defeat XSLT manipulation

XSLT is the W3C standard for manipulating and converting XML documents, and is by far the most popular tool for working with XML. XSLT has no tools for bitwise operators, since bitmasks are not part of the XML data model.

Det er vigtigt at understrege, at bitmaskerne er reelt bit-flag, der ikke er relaterede til hinanden. Det er også vigtigt at understrege, at bitmasken ikke er "en række bits" men derimod en serialisering af en række flag. Derfor giver det ikke mening at tale om, at XSLT ikke kan anvendes på disse bitflag, da XSLT ikke indeholder mulighed for "bitwise operators". Bitwise operators er jo noget med OR, AND, XOR, NAND etc, men det giver slet ikke mening at tale om dette i denne kontekst. Hvis OOXML-spec i stedet havde udskilt disse 12 formatteringsflag i selvstændige attributter/elementer med mønstret [true,false] ville det have været nøjagtigt lige så nemt/svært at manipulere disse værdier som det er nu i bitmasken, som jeg hellere vil benævne en "short-hand positioning-definition" end en "bitmaske". At omtale disse flag som bits forvirrer mere end det gavner (man kan sige, at OOXML har skudt sig selv i foden ved at benævne dem som "bitmasks").

3. Bitmasks conflict with the Ecma TC45 charter

The TC45 is the Ecma Technical Committee charged with developing the Ecma 376 specification. The charter of the TC45 includes the specific goal of: "...enabling the implementation of the Office Open XML Formats by a wide set of tools and platforms in order to foster interoperability across office productivity applications and with line-of-business systems"

Since bitmasks cannot be implemented in any of the standard tools for XML data formats, their use is in conflict with the TC45's charter.

Er dette ikke liiige at stramme den? For det første er værktøjerne til manipulering af OOXML ikke kun indsnævret til XML-værktøjer som XSLT. For det andet er der intet i disse eksempler på bitflag, der afholder manipulering af dem fra at blive implementeret i XSLT. Man kan argumentere for, at bitflagene ikke er specielt "XML-agtige", men at bruge dette som argument for at afvise standarden er i mine øjne for langt ude.

4. Bitmasks are not extensible

The bitmasks specified by Ecma 376 are mostly of fixed length (a fixed number of bits). For example, the bitmasks used in sections 2.4.51, 2.4.52, 2.15.1.86, and 2.15.1.87 are all of type ST_ShortHexNumber (2.18.86, p. 2591), which is defined as consisting of exactly 4 hexadecimal digits (16 bits, see above regarding conflicting definitions). The bitmasks in section 2.8.2.16 are of type ST_LongHexNumber (2.18.57, p. 2542) which is defined as consisting of exactly 8 hexadecimal digits (32 bits, see above regarding conflicting definitions). The bitmasks in sections 2.3.1.8, 2.4.7, and 2.4.8 are of type ST_Cnf (2.18.11, p. 2478), which is defined as consisting of exactly 12 binary digits (12 bits). The bitmask in section 6.1.2.7 (p. 5227) consists of exactly "three bits".

Because it is not possible to add new bits to a fixed-length bitmask, extensibility is extremely limited.

Jeg kan godt forstå, hvorfor Grokdoc ønsker denne mulighed, for det er netop én af arkitekturprincipperne for ODF - nemlig muligheden for at udvide spec'en afhængigt at applikationen. Pudsigt nok er den manglende mulighed for applikationsspecifik udvidelse netop ét af grundprincipperne for OOXML. Argumentet fra OOXML er, at det er svært at sikre interoperabilitet, når hver implementering af formatet kan udvide dette som man lyster. Var det her muligt at udvide en af bitflagsrækkerne med ekstra flag - hvordan skulle andre applikationer kunne anvende dette? Dette er ét af en række eksempler på, hvordan en arkitekturbeslutning påvirker den konkrete implementering af den. Diskussionen om disse flag bør altså reelt ikke dreje sig om deres eksistens men derimod om hvilket arkitekturprincip, der bør ligge bag formatet.

 

ODF, OOXML, oO.org, MSOffice ... eller Mooh?

Jeg er lidt nødt til at poste dette link, som jeg fandt via en eller anden RSS-aggregator. Det er til en artikel fra The Copenhagen Posts website, der omhandler sidste uges beslutning om valg af (indtil videre) både ODF og OOXML. Artiklens indhold understreger meget godt, hvorfor de fleste mennesker ikke bekymrer sig om "kampen" ... de forstår den simpelthen ikke.

Når overskriften i artiklen er:

"The two leading open source computer programme candidates will have a year and a half to compete head-to-head for control of government computers

... kan man jo nærmest ikke lade være med at knibe en lille trist tåre over det uhørt lave journalistiske niveau. 

Er det nok at standarden er åben?

Efterhånden som det går op for flere og flere af ODF-only fortalerne, at deres foretrukne format ikke er modent nok, er taktikken nu blevet ændret. Fra at tale om ODFs fortræffeligheder i kraft af letlæsbar xml, specifikationens diminutive sideantal og reference til eksisterende standarder tales der nu næsten udelukkende om de politiske overvejelser bag valget af format. Specielt tales der meget om åbne standarder.

aabnestandarder.dk er listet en definition af egenskaber for en åben standard.

  1. Veldokumenteret med den fuldstændige specifikation offentligt tilgængelig.
  2. Frit implementerbar uden økonomiske, politiske eller juridiske begrænsninger på implementation og anvendelse.
  3. Standardiseret og vedligeholdt i et åbent forum (en såkaldt "standardiseringsorganisation") via en åben proces.


Jeg vil i øvrigt anbefale læsere at læse lidt på siden. Det er interessant læsning og forklarer på en god måde årsagen til at åbne standarder er en god idé. Bagmændene bag definitionen fik i øvrigt noget af et scoop, da ovenstående definition endte i det såkaldte B 103-forslag.

Når jeg bruger lidt tid på at skrive om denne definition skyldes det at den i øjeblikket misbruges af fortalerne for "Only-ODF" (fremover benævnes dette som oODF) i deres argumentation for kun at vælge ODF. Argumentet er det simple, at da OOXML ikke opfylder denne definition kan den ikke vælges - altså en reel apriori-forudsætning for valg af format. Tilsvarende omtales definitionen nærmest som én af matematikkens 5 aksiomer eller i det mindste som var de ristede i runer (Jellingestenens uægte lillebror) eller stod med småt på tavlerne, som Moses havde med efter sin tête-a-tête med Gud på Sinajbjerget. Lad mig ydmygt understrege, at ingen af disse ting er tilfældet.

For mig er de tre punkter en hensigtserklæring og et mål, men det er ikke udgangspunktet - og de trumfer slet ikke den virkelighed de skal anvendes i eller de tekniske egenskaber ved en standard, der skal overvejes. Har vi en situation, hvor standard X og standard Y reelt er ens og de adskillende detaljer kun er småting, vil jeg naturligvis foretrække den standard, der i videst muligt omfang dækkes af definitionen af en åben standard. Er vi derimod i en situation som med OOXML og ODF er billedet mere grumset og bestemt ikke sort/hvidt.

Når oODF-fortalerne insisterer på udelukkende at tale om overholdelse af aksiomerne, så siger de dermed samtidig, at de tekniske aspekter ikke har så høj rang i diskussions-kæden. Det er også den fornemmelse det giver at deltage i diskussionerne, hvor det er tydeligt at bevæggrundende ofte er politiske og også ofte drevet af et ideologisk "korstog" imod Microsoft. Jeg behøver vel ikke at nævne, at jeg ser det lidt anderledes. Jeg er pragmatiker af natur og det er vigtigere for mig at der er valgfrihed og at valget af dokumentstandard ikke kommer til at hæmme produktiviteten i den offentlige sektor, hvor jeg dagligt arbejder. Det er i øvrigt en holdning som jeg nu kan se jeg deler med IT-ordførerne i Folketinget. Når oDDF-fortalerne siger, at det vigtigste er at formatet opfylder alt i definitionen end at formatet er "spiseligt", bringer det minder frem fra tiden, hvor Linux var et relativt nyt fænomen. Dengang kunne man ofte høre Linux-brugere sige, at "ja, brugerfladen kan forbedres, det er svært at installere og indlæringskurven er lidt for stejl. Men Linux er meget mere stabil og så er det gratis". Til Linux-fortalernes ros er de blevet klogere (eller mere pragmatiske) - det er blot ærgeligt at vi nu igen skal spilde tid på den samme diskussion - blot nu med et nyt format, nemlig ODF.

Hvis du spørger mig, så er det ikke til diskussion at ODF ikke er modent nok til at kunne stå alene som eksklusivt dokumentformat i den offentlige, sektor ligesom det heller ikke er til diskussion, at OOXML er langt mere grundigt bearbejdet og langt mere gennemført end ODF. Ja, der er nogle usikkerheder omkring vedligeholdelse af formatet men teknisk set er der ikke rigtigt noget at rafle om. OOXML er ganske enkelt et bedre format. Når oODF-fortalerne alligevel negligerer disse ting og siger at "der vil naturligvis være en indkørselsfase med problemer" og "det er vigtigere at fravriste Microsoft deres monopol end sikre effektiviteten i den offentlige sektor", så kan jeg ikke lade være med at tænke på Grev Farquard fra DreamWorks-filmen "Shrek". Inden han sender en flok riddere afsted for at redde Prinsesse Fiona for ham (han tør jo ikke selv), siger han med megen empati: "Some of you may die, but that is a sacrifice I am willing to make". Ligeledes synes det at være åbenbart, at mange af oODF-fortalernes eneste fremtidige interaktion med ODF bliver deres installation af OpenOffice.org eller KOffice ... og kommer altså slet ikke til at arbejde konkret med formaterne i den offentlige sektor. De kommer altså ikke til at mærke problemer på egen krop.

Smile

Post-afgørelses hysteri

Som man næsten kunne forvente, kogte debatforaerne i går næsten over med diskussioner om afgørelsen omkring valgte dokumentformater i den offentlige sektor i Danmark. Som jeg skrev i går, så er jeg af den holdning, at beslutningen var klog og afvejet og tog hensyn til den tekniske verden, der eksisterer i den offentlige sektor. Trist nok står jeg ret alene med denne holdning. Der er et par "holdnings-frænder" på version2.dk og også et par stykker på computerworld.dk ... men vi er groft "underbemandede".

Som sagt nåede den skingre tone i går nye højder - ja selv jeg blev beskyldt for at være en "troll" på version2.dk :o)

Angrebene på beslutningen var generelt fokuserede på et par områder, og jeg vil prøve at addressere disse her.

1. Beslutningen var taget på forhånd

Sådan en udtalelse er jo svær at tilbagevise - ligesom den er svær at bevise. Det er sådan en af de udtalelser, der er på linie med "JFK blev myrdet af CIA" eller "Prinsgemalen er bøsse og Dronningen har et seksuelt forhold til Susse Wold". Sandhedsværdien i disse udsagn er nok relativt begrænset og i øvrigt tjener de intet formål andet end at "kridte banen op" for et skænderi. Generelt burde man holde sig for god til at komme med disse udtalelser.

2. Høringen var en parodi, da man ikke lyttede efter indsigelserne

Tja- udtalelser som disse indikerer jo, at man ikke helt har fanget idéen med en høring. En høring er jo ikke en afstemning, hvor man rækker hånden op og stemmer for et forslag. En hørings formål er at indhente feedback fra interessenterne i en konkret problemstilling. I debatten tilknyttet artiklen "Dokument-afklaring på vej allerede i dag" på version2.dk blev der udtalt:

"Hvis du kikker på høringssvarene vil du altså se at ret vægtige foretagender som Sun, Oracle, IBM, samt f.eks. region Midtjylland på det kraftigste fraråder dobbelt standard, men alligevel negligeres deres argumenter."

Lad mig for et øjeblik glemme, at både Sun, IBM og Oracle har vægtige forretningsmæssige grunde til at mene, at ODF er det eneste rigtige format. Der blev også udtalt:

"det er da en parodi at der laves en skinhøring, hvor ca. 80% af svarende siger at 2 formater er en dårlig løsning, ca. 70% peger på kun ODF, ca. 20% er ligeglade, og kun et høringssvar (gæt fra hvem) går 100% helhjertet ind for OOXML!"

Igen er det i mine øjne en misforståelse af idéen med en høring. Lad mig sætte det lidt på spidsen og antage, at der var 100 virksomheder, der alle sagde, at ODF skulle være eneste tilladte format pga fx frigørelse fra Microsoft etc og at der var 1 virksomhed, der sagde, at de ikke var enige i dette, da der er nogle tekniske problemer i valget af kun ODF og derfor anbefalede to formater. Dette betyder altså ikke, at ODF-only argumentet vægter 100 gange mere end den enkelte virksomhed - specielt ikke når den ene virksomhed kan argumentere for dens sag. Uanset hvordan ODF-only fortalerne vender og drejer det, er der nogle tekniske udfordringer i kun at tillade ODF og der er nogle procesmæssige udfordringer i kun at tillade ODF. Når ODF-only fortalerne ikke kan argumentere for, hvorfor dette ikke er tilfældet, så er det ligemeget hvor mange de indkalder til at sige "Jeg mener det samme som ham den anden".

... og så skal man også lige huske, at de indsendte svar ikke nødvendigvis er repræsentative for danske virksomheder generelt. Typisk er det jo de sureste, der råber højest, og det har desværre en tendens til at skævvride resultaterne.

Moralen

Hvis der skal være nogen morale i dette er det jo, at høringen rent faktisk har tjent sit formål. En række virksomheder indsendte deres svar og efter behandling er Folketinget nu nået frem til, at ODF og OOXML bliver obligatoriske for offentlige myndigheder. Som jeg læser svaret har man anerkendt følgende kendsgerninger:

  1. ODF er ikke modent nok til at blive anvendt alene
  2. ODF kan ikke alene dække behovene i den offentlige forvaltning
  3. Der er tvivl om, hvorvidt andre end Microsoft kan implementere OOXML

 

Løsningen på denne gordiske knude har været at tillade begge formater og lave en post-vurdering om et par år for at se, om det har vist sig at andre kan implementere OOXML. Jeg synes ganske enkelt, at det er en perfekt løsning.

Hvis jeg endog skal konkludere en smule på debatten omkring ODF og/eller OOXML, så må det være den glædelige kendsgerning, at så længe man argumenterer sagligt og nøgternt, så er det faktisk muligt at budskabet trænger igennem - selvom oppositionen er nok så følelsesladet.

... PS: og dagen i går var også dagen, hvor jeg blev beskyldt for at være korrupt. I hvert fald faldt jeg over følgende afsnit på en blog "i nærheden":

The bad things are:

  1. [...]
  2. The MP's shows that they are not ready to make a decision, after almost half a year with discussion and documents. They can see the reports, that shows all the benefits of open standards and that the only pro EOOXML is Microsoft related of payed by Microsoft directly.

 

Huskede jeg at nævne, at tonen var blevet lidt skinger?