a 'mooh' point

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? 

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 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

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"? 

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.

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. 

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?

Ifølge sædvanligvis velunderrettet kilde arbejder Folketingets partier i øjeblikket på en beslutning om standarderne, der indebærer følgende:

1. Offentlige myndigheder pålægges at kunne modtage henvendelser i både ODF-formatet og OOXML-formatet.
2. De to formater bliver obligatoriske dokumentstandarder i det offentlige.
3. Det bliver obligatorisk for offentlige institutioner at indkøbe software, der understøtter mindst én af de to standarder.
4. Tidsrummet fra 1. januar 2008 til 1. januar 2009 skal bruges til at vurdere om OOXML reelt kan fungere uafhængigt af produkter og leverandører. Er det tilfældet "ophøjes" formatet til obligatorisk standard.

Umiddelbart er det faktisk en ganske glimrende løsning, de åbenbart er ved at tage. Den afbalancerer nemlig ønsket om at frigøre sig fra Microsofts defacto-monopol på kontorprogrammer i den offentlige sektor - samtidig med at den tilgodeser virkeligheden i den offentlige forvaltning - nemlig at det vil være en katastrofe for arbejdsprocesserne i det offentlige at kræve, at man bruger et nedbarberet dokumentformat som ODF.

Det er også værd at bemærke ordlyden af ovenstående. Den siger nemlig, at offentlige myndigheder skal kunne modtage og dermed også reelt kunne sende dokumenter i begge formater, hvorimod offentlige institutioner ikke er bundne af samme krav men "blot" skal kunne honorere det ene format. I mine øjne giver dette fint mening. Christian Nobel skrev på version2.dk, at det ville give uhensigtsmæssigheder, når han så skal sende et brev til en vuggestue, der jo ikke er en myndighed og derfor ikke nødvendigvis kan læse ODF-dokumenter. Det har han jo ret i og det vil givetvis give nogle problemer i indkørselsfasen. Min pointe er blot, at kravet er fuldt rimeligt, da offentlige myndigheder - dvs den del af den offentlige verden, der reelt betyder noget - skal kunne modtage begge formater men at andre (mindrebetydende) institutioner ikke stilles overfor samme krav.

I punkterne ovenfor står også, at der vil være en indkørselsperiode på et års tid fra 1. januar 2008. Morten Messerschmidt udtaler iflg. Computerworld, at det vil være fint med en indkørselsperiode, hvor der kan blive samlet erfaringer. Han har også betinget sig, at konkurrencestyrelsen bliver en del af denne post-indkørselsvurdering, der skal foretages. Igen kan jeg kun sige, at det for mig er ganske rimelige ting. Faktum er jo, at der er blevet sået så meget tvivl (i mine øjne uretmæssigt) om OOXMLs muligheder for anvendelse af andre end Microsoft, at jeg godt kan forstå, at politikerne er urolige ved det. Jeg bifalder dermed, at de er så modige, at de tør sige, at nu kigger vi igen på det om et års tid.

I hovedtræk mener jeg, at politikerne har taget ikke alene en god politisk beslutning, men også en pragmatisk rigtig beslutning om at sikre den offentlige sektor så optimale vilkår som muligt. Hvis de havde hørt efter de meget højrystede ODF-only fortalere og smidt OOXML på porten, så ville konsekvenserne have været uoverskuelige og jeg er sikker på, at de har haft dette for øje. Med beslutningen i dag signalerer politikerne at de både vil blæse og have mel i munden - menher på den gode måde. De signalerer at de vil fravriste Microsoft deres monopol i den offentlige sektor samtidig med, at de respekterer den virkelighed, som de offentligt ansatte lever i hver dag. Dét er da en god beslutning!

... og så glæder jeg mig i øvrigt til se se ordlyden af aftalen. Specielt bliver det spændende at se, hvilke versioner af de enkelte formater de vælger at anbefale. Jeg håber meget, at de vælger at anbefale navngivne versioner af de to standarder, og det vil sandsynligvis blive Ecma 376 for OOXMLs vedkommende og ISO/IEC 26300:2006 for ODFs vedkommende.

Og lad os så komme i gang med at arbejde med formaterne. Som Brian Jones sagde: "We aren't philosophers; we're geeks who build software to solve people's problems…". 

I noget tid har jeg debatteret "højlydt" på primært version2.dk om valget imellem OOXML og ODF - eller begge - som anbefalet standardformat i den offentlige sektor i Danmark. Det har været meget interessant og jeg håber at andre som jeg har fået deres holdninger udfordret og er blevet klogere undervejs.

Jeg er dog kommet til den erkendelse, at jeg ikke får nok ud af at debattere "på bagkant" i trådene på version2.dk . Ikke alene bestemmer jeg ikke selv emnerne, men det er også svært at få sin pointe frem, når det eneste input-mode jeg har er et TEXTAREA-felt. Hvis jeg vil understrege noget eller lægge vægt på noget andet, så er det ofte nødvendigt at illustrere med tabeller, formattering og lignende. Derudover er version2.dk's grafiske brugerflade ikke "den bedste i verden" ... for nu at sige det mildt, så det er ikke muligt at linke til seperate indlæg i de enkelte tråde og det er i det hele taget svært at bevare overblikket. Jeg håber at kunne løse alle disse problemer ved at ibrugtage min egen blog.

Nu er dette jo "første blad" i min nye bog, så alt er endnu lidt jomfrueligt. Derfor har jeg endnu ikke lagt mig fast på om jeg skal skrive på engelsk eller på dansk. Hvis jeg skriver på dansk, så har det den fordel at jeg nok vil få flere danske læsere og at jeg vil bedre kunne præge debatten i Danmark. Hvis jeg derimod skriver på engelsk, så vil jeg potentielt kunne være med til at præge debatten på et mere globalt plan ... men jeg mister måske den danske vinkel.

Hvad siger du?

Tja- velkommen til min nye blog ... jeg håber, at du får noget ud af det.