Int9

Det har blitt mye tilbakemeldinger på mitt innlegg om filnavn. Noe tror jeg bygger på misforståelser eller en trang til personangrep, men noe er også god kritikk.

Premissene

Det jeg vil ha frem var at det er merkelig at vi (i dag) blander sammen filnavn og filtype og lagrer dette i samme enhet. Jeg er klar over at dagens teknologier er bygget på tanken om at slutten på filnavnet angir typen. Men er det sannsynlig at vi holder oss til disse begrensningene i fremtiden? Vil vi om 30 år fortsatt bruke tre bokstaver i filnavnet til å angi filens type? Om 50 år?

• Jeg mener altså ikke at vi alle burde slutte øyeblikkelig med hvordan vi navngir filer.
• Jeg vet altså at hvis vi våknet opp i morgen uten filendelser på filene våre så ville det blitt problemer.
• Jeg er klar over hva dette innebærer med tanke på filtype må overføres ved filoverføring og endringer i lesing og skriving av filer i operativsystem.

Den meste av kritikken går på å ramse opp hva det er med dagens filbehandling og filoverføring som gjør at et bytte i neste uke ikke vil fungere. Det er ikke særlig vanskelig. Det jeg påstår er at om vi ser bort fra dagens begrensninger og ser hvor vi vil i fremtiden, så er det naturlig å skille mellom navn og type. Jeg påstår at grunnen til måten vi gjør det på i dag er historisk heller enn at det å blande navn og type er en god idé.

Det er også ingenting som hindrer oss i å beholde informasjon om typen både i filnavn og som metadata i en 20-30 år, eller så lenge vi måtte ønske.

Eksempel 1

Jeg kan prøve å illustrere det med et eksempel:

Se for deg at vi i dag skulle designe et nytt OS fra bunnen - uten av vi var klar over historikken og konvensjonene knyttet til hvordan filer navngis.

• Vi kommer frem til at vi må ha en form for filer som representerer programmer og en rekke typer forskjellig informasjon.
• Om disse filene er vi interessert i å lagre en del informasjon (hvem eier filen, når ble den sist åpnet, når ble den opprettet).
• Vi vil også lagre noe som forteller oss hva denne filen inneholder.

Jeg har vanskelig med å se for meg hvordan disse hypotetiske designerne tenker at “informasjon om filene lagres som metadata - med unntak at informasjonen som sier hvilken type fil dette er. Den putter vi inn sammen med filnavnet.”

Hvis noen mener de vet noen god grunn til at dette er en god løsning, så må de gjerne opplyse meg.

Eldre OS skiller mellom navn og type.

Når tidlige OS ble designet blandet de ikke sammen navn og type (DOS skiller for eksempel mellom filnavn og filtype). Det var satt av 8 bytes til navn, og 3 bytes til type.

Dagens OS skiller ikke mellom navn og type, men stoler på konvensjoner. (De siste ca 3-5 bokstavene etter siste punktum i navnet angir hva jeg skal gjøre med denne filen).

Eksempel 2

Sett at du jobber som programutvikler. Hvis du bruker navnefeltet i en database til å angi personens type (kjønn), så får sannsynligvis kjeft.

• “Fornavn Etternavn.mann” er en dårlig løsning fordi den blander informasjon om navn med informasjon om kjønn. Den baserer seg på at et punktum skiller navn og kjønn. Skillet kommer ikke frem i måten dataene er strukturert.
• “Fornavn Etternavn” og et eget felt for kjønn er selvfølgelig bedre. Det skilles klart mellom navn og kjønn. (Det beste er selvfølgelig i tillegg å skille for- og etternavn)

Legg merke til at det er ingenting som hindrer deg fra å lese inn eller vise dataene på formen “Fornavn Etternavn.mann”.

Svar

For å referere til filer.

Det skrives at “filetternavn” er en god måte å referere til filer. Det nevnes et eksempel der readme.txt og readme.html ligger i samme katalog.

Det er selvfølgelig helt rett. Dette er nettopp det som er grunnen til at punktum opprinnelig ble innført som separator. Det jeg mener er at OS bør skille mellom navn og type basert på noe annet enn konvensjoner. Ditt OS bør skille mellom navn og type. Navn og type bør lagres som separate data. Jeg sier altså ikke at du ikke bør kunne referere til dine filer som readme.txt, (men det kan hende fremtidens OS presenterer filer anderledes)

Sortering

Du vil fortsatt kunne sortere filene dine om typen lagres separat. Dette klarte du i DOS. Du klarer å sortere basert på for eksempel dato i dag.

Ikke klag - det er bare å skru av i Windows.

Hvis du har lest helt hit så håper jeg du ikke tror mitt problem er at det er plagsomt å se på filendelser. Det er ikke poenget. Jeg er blitt anklaget for å skrive 90% microsoft-hat til å være en Windows-bruker basert på samme innlegg.

Hvert OS sin tilnærming.

Det som kommer klart frem av debatten er at forskjellige OS forholder seg til filtyper på forskjellige måter. Det er uklart hvordan filens type skal avgjøres.

Konvensjonen sier at de tre (enkelte ganger fire eller fem) bokstavene etter siste punktum angir hvilken type fil det er. Etter hver som vi får flere og flere filtyper, blir det trangt om plassen og mange typer brukes til forskjellige formål.

Si at du får tilsendt en fil som har navnet “navn.img”. Ditt operativsystem må finne ut av hva denne filen er og hvordan den eventuelt skal åpnes. I følge filext.com er det 24 alternativer.

Enkle OS slår bare opp program basert på filtypen, mens andre bruker andre metoder for å gjette seg frem. Det innebærer mye gjetting, og jeg mener vi i fremtiden bør kunne løse dette bedre. Ikke at løsningen er å kutte ut filtypen.

Norske myndigheter med sin forakt for våre privatliv utsteder i dag pass med RFID-chip. Make har en artikkel der det beskrives hvordan RFID kan settes ut av spill.

Jeg aner ikke hva som vil skje i det du prøver å komme gjennom tollen med et pass der RFID ikke fungerer, men det kunne jo vært gøy å funnet ut. (Eller?) Muligens litt hodebry for betjentene på flyplassen, men dine personopplysninger er iallefall noe tryggere. Når myndighetene ikke gjør noe for å beskytte våre privatliv bør man jo kunne ta grep selv.

Men det frister vel ikke å prøve, tatt i betraktning hva et nytt pass og en tapt utenlandstur koster.

Det er kjent at historie og vane veier tungt når det gjelder hvordan vi bruker PC’en. Jeg mener at dette er grunnen til at utviklingen går i sneglefart når det gjelder vårt grensesnitt til PC’er. Hender det du setter deg ned og tenker på filnavn? Hvorfor de er som de er og hvilke begrensninger som er knyttet til de? Neppe, med mindre din interesse til datamaskiner grenser til det syke. Undertegnede har altså tenkt mye på filnavn i dag.

For eksempel: README.TXT

En fil heter “README.TXT”. Dette er jo litt forvirrende - navnet på filen burde jo vært “README”. Slutten på filnavnet angir hvilken type fil dette er. “.TXT” forteller oss at dette er en tekstfil. Men vi kaller altså hele navnet (“README.TXT) for filnavnet. Er ikke det rart?

Problemet mitt er altså at når vi sier “filnavn”, så blander vi sammen filnavnet og filtypen.

Warum?

Grunnen til dette er historisk. I gamledager så ble filtype angitt på denne måten. Filnavnet var maks 5-9 bokstaver langt, og filtypen ble angitt av 2-3 bokstaver. Filtypen anga hvilken type fil dette var. Når brukeren skulle taste inn kombinasjonen filnavn + filtype, var det vanlig å skille de med et punktum. Tidlige versjoner av FAT-filsystemet (for de som husker DOS) bygget på denne tanken. Kjørbare filer måtte for eksempel slutte på “.EXE” eller “.COM”. Det kalles “8.3 filename” på godt norsk.

Dette er godt innarbeidet hos de fleste av oss, og (nesten) ingen tenker på det i dag. Jeg har erfart at hos enkelte er det så innarbeidet at de går i forsvarsposisjon hvis jeg påstår at det er en dustete måte å navngi filer på.

Dårlig design.

De historiske grunnene til dette er altså klare. Men hva er grunnen til at vi fortsatt har det i dag? Moderne filsystem støtter metadata som angir en rekke egenskaper ved filene. De forteller oss hvem som eier filen, om den er eksekverbar, når den var opprettet, sist lest, og så videre.

Det er også blitt såpass mange filer at det blir konflikter. Får du en DOC-fil, kan det være ren tekst, eller Microsoft Word-dokument. Får du en IMG-fil, kan det være et CD-image, en fotografi, bitmap bilde, eller et disk-image.

Det er tyvetydelighet rundt hvordan programmer viser filtyper. Du kan motta en epost med en “readme.txt” som du dobbeltklikker på. Det viser seg at filen egentlig het “readme.txt.exe”, og at din PC nå reklamerer stort for viagra eller billige armbåndsur.

Jeg har ikke lyst til å bruke mye tid i dag på å rakke ned på Windows (men det er vanskelig å stanse når jeg først begynner) - jeg har brukt GNU/Linux og BSD for lenge til å være helt oppdatert på Windows.

Altså, jeg mener at der i gården må filtypen være en del av filnavnet. Et program må altså ha et navn som: “program.exe” for å kunne kjøres. NTFS er designet for å kunne lagre en rekke metadata om filene, men Windows baserer seg på at filnavnet må slutte på “.XYZ” for å vite om den skal kjøres eller ikke. Hvorfor da ikke også lagre filtypen som metadata og bruke filnavnet til - tja - filnavnet? Helt idiotisk spør du meg.

Til Windows sitt forsvar, så er det vanlig at GUI på for eksempel GNU/Linux også baserer seg i stor grad på filendelser. Men GNU/Linux i seg selv bryr seg ikke et døyt om hva filen heter.

Andre begrensninger

Et annet tegn på det jeg mener er svakt design på Windows er reserverte filnavn. Du trodde kanskje et filnavn bestod av tekst og kunne være hva som helst (med unntak av noen spesialtegn)?

Windows har også en rekke reserverte ord som hindrer deg fra å lage filer med enkelte navn (du får det til hvis du prøver hardt nok, men det er ikke anbefalt). Du får ikke lage filer av navn som: CON, PRN, AUX, NUL, COM1 til COM9 og LPT1 til LPT9. Også her er grunnen for det meste historisk fra DOS sine dager, selv om “copy con filnavn.txt” eller “copy filnavn.txt prn” også (vistnok) skal virke i dag. Ønsker du å lagre medlemslisten til Namsos Ungdomslag i filen “nul.txt”, eller passord til dine porn voksen-nettsider i filen prn.txt, bør du altså bruke et ordentlig operativsystem. Dette har også ført til en rekke morsomme feil der du kunne provosere frem kræsj ved å referere til filer som “c:\con\con” på forskjellige måter (i HTML-dokumenter eller fra en FTP-klient).

Noe annet merkelig er at NTFS tillater filnavn som slutter på mellomrom eller punktum, men Windows vil ikke tillate dette.

. . Og jeg skal ikke engang begynne å skrive om at Windows ikke ser forskjell på STORE og små bokstaver.

Mitt poeng er at dette er dårlig design, men at det er vanskelig å endre det som brukerne har vendt seg til.

Bedre løsning?

Jeg forstår at folk har sine vaner, og at endring i brukergrensesnitt er noe mange brukere ikke nødvendigvis vil like. Det er kjekt å se ut fra endelsen hvilken type fil det er snakk om, men jeg mener heller at operativsystemer skal designes for å vise filtypen som en egen kolonne i utforskeren, ved ikoner, eller på andre måter. Det er ikke lett å erstatte vanlige teknologier (se på DAB-radioer eller IPv6), og det kan være en leng og smertefull prosess for brukere som har sine faste vaner.

Men er vi ikke snart klare for å legge bak oss begrensninger som stammer fra 60- og 70-tallets operativsystemer? På 70-tallet hadde filendelser en funksjon - i dag er bakoverkompatibilitet hovedårsaken. På Internet bruker vi allerede MIME-typer, og filsystemer lagrer en rekke metadata om filer. Jeg mener informasjonen om filtype er metadata og bør flyttes sammen med resten av metadataene. Filnavn bør brukes til - nettopp - filnavn.

Da har jeg brukt noen dager på å roe meg etter å ha lest Steve Pepper sin redegjørelse for prosessen i Standard Norge som leder til en godkjennelse av OOXML som en ISO-standard. Det er nesten uvirkelig å lese hvordan prosessen har foregått og hvordan Ivar Jachwitz har kapret avgjørelsen på tross klare råd fra den tekniske ekspertisen. Standard Norge har utgitt en mer fyldig redegjørelse der de forsøker å forsvare sin avgjørelse. Etter min mening graver de hullet enda litt dypere.

SN ventet seg kritikk

Som forsvar har SN hevdet at en avgjørelse kom til å bli kritisert uansett hvilken “side” som hadde vunnet. Dette er en stor overdrivelse. De som offentlig har lobbyet for OOXML er få i antall og har klare motiver. Ved å stemme nei til OOXML, ser jeg for meg at kritikken hadde kommet fra Shahzad Rana (som får betalt for dette), og (i verste fall) et par andre personer. Kritikken ved en nei-stemme ville altså blitt marginal.

Fast-track som metode

SN gjør klart at avgjørelsen om at fast-track var riktig prosedyre for denne standarden ble tatt av ISO. Det har hele tiden vært åpenbart at fast-track ikke har vært en riktig prosedyre, men vi som har kritisert har heller ikke lastet SN for dette. Greit nok - SN peker på ISO som vel bør få skylden.

Høringen

Det kom som kjent 37 likelydende brev i støtte for OOXML. Disse hadde store mangler som skulle tilsi at enkelte ikke engang var gyldige. Etter møtet i 2007 ble kritikerne beroliget med at disse ikke skulle tas hensyn til. (- og stanset med det en debatt som vi egentlig burde hatt den gang)

Så viser det seg at nå er de allikevel blitt gyldige stemmer “for” OOXML. SN redegjør at alle brevene kom med “kjent avsender og i undertegnet stand”. De unnlater elegant å nevne det som digi allerede har påpekt at de har store betenkeligheter knyttet til seg.

Videre i sin redegjørelse graver SN hullet dypere ved å gjenta at kriteriet for å endre vår nei-stemme fra 2007: For å lande på en ja-stemme skal kommentarene være tilfredsstillende løst (dette kommer klarere frem i pressemeldingen fra 2007). Dette har åpenbart ikke vært tilfelle.

Vurdering av BRM

Om BRM-møtet beskriver de antallet kommentarer som skulle vurderes som “betydelig”. Dette er i beste fall å underdrive. Andre beskriver det som et hastemøte der hvert land fikk tatt opp og diskutert 1-2 kommentarer. Den store majoriteten ble tatt som “hjemmelekse” og stemt over eller bulk-godkjent uten diskusjon.

Slik SN ordlegger seg så blir 2 kommentarer avvist. De resterende 10 ble “akseptert eller akseptert med modifikasjoner”. Det virker jo som at det store flertallet ble akseptert.

Steve Pepper ordlegger seg anderledes. Han skriver at det var enighet om at 2 kommetarer var løst, og at 2 ikke var løst. De resterende 8 var det uenighet om.

Jeg vil tro at det de aller fleste anså de resterende 8 som ikke løst, og jeg tror jeg vet hvem som helst ville anse de som løst. Tatt i betraktning at Microsoft har en betalt person til stede, så er det urimelig å vente seg konsensus rundt hva som er løst tilfredsstillende.

Partisk komité

SN trekker frem et åpent brev som ble undertegnet av en majoritet før komitémøtet som et tegn på at medlemmene hadde tatt stilling før møtet. Slik jeg forstår SN så antyder de at majoriteten av komiteen var forutinntatt og inhabile.

Dette er naivt - hele komiteen (med noen få unntak) har deltatt i den offentlige debatten rundt dette og argumentert for sitt standpunkt. Dette har foregått i over et år, og medlemmenes standpunkter er slettes ingen hemmelighet. Jeg forstår ikke SN sin påstand.

Avstemming

Det har vært klart at det ikke skal stemmes om SN sin avgjørelse. Men, SN sin uttalelse påpeker at det (samlet sett) var en overvekt av ja-stemmer.

Men vent litt - de har jo allerede fastslått at standarden har en rekke punkter som må utbedres. Hvorfor teller de da med stemmene fra 2007 da Microsoft stuffet komitéen og sendte inn ferdig-brev? Med mindre jeg husker helt feil, så uttalte de i 2007 at de ville se bort fra brevene.

For å sli det slik: De konkluderte i 2007 med at (på tross av majoritetens stemmer) standarden hadde punkter som måtte rettes. De så altså bort fra disse stemmene og deres ferdig-brev i 2007.

Nå, i 2008, teller disse stemmene og brevene igjen? Har SN snudd igjen og mener at kommentarene ikke var relevante? Stemmene fra 2007 var tatt på et helt annet grunnlag enn det som ble diskutert i 2008.

Ser man for seg det samme ved f.eks. stortingsvalg, ser man absurditeten. Når man stemmer gjør man det ut fra dagens situasjon. Selv om hva du stemte ved sist valg kan være en faktor for deg personlig, så er det ikke en faktor når stemmene skal telles opp. “FRP gjorde det godt dette valget - men ved forige valg var det ikke mange som stemte FRP. Vi får korrigere resultatet”

Vi kan jo fikse standarden

SN argumenterer med at vi bør akseptere OOXML som en standard for da kan vi fikse standarden. Da vil vi kunne “være i en best mulig posisjon for å initiere og delta aktivt i et slikt revisjonsarbeid”. Dette er et gyldig argument i seg selv, hadde det ikke vært for at SN motsier seg selv. I 2007 var de klare på at kriteriet var at kommentarerne skulle utbedres tilfredsstillende. SN skal ta stilling til hvorvidt standarden er god nok - ikke om den kan la seg fikses.

I følge Geir Isene sin redegjørelse var dette heller ikke et kriterie på møtet, med unntak av en bisetning fra Jachwitz mot slutten.

Det at ISO kan være i stand til å fikse standarden er altså et ugyldig argument fra SN. Tullprat altså.

Og de graver dypere . .

Avslutningsvis skriver SN at de mener ISO bør evaluere fast-track-prosedyren og de påpeker at ECMA sin mulighet for å bruke frast-track bør diskuteres. De skriver “Vi mener at arbeidet med OOXML ville ha vært bedre tjent med om det hadde vært initiert som et nytt ISO-prosjekt.” Så hvorfor i all verden trumfet du da igjennom en godkjenning, Jachwitz? Dette har vært nei-sidens kanskje sterkeste argument. Ved å stemme nei hadde vi tvunget OOXML gjennom ISO “fra bunn”, slik SN hevder de ønsker og slik nei-siden hele tiden har arbeidet for. Hvorfor i all verden avgir du da en ja-stemme på vegne av Norge? Og hvordan kan du begrunne norges ja-stemme ved å argumentere for en nei-stemme?

Det blir for enkelt når Shahzad Rana avskriver de som vel er blandt de mest kompetente tekniske offentlige personene i Norge som “emosjonelle” og vanskelig å debattere med forde de har et “hatforhold til Microsoft”. Det er et billig triks for å slippe å ta stilling til problemene de tar opp, og det står klart for de aller fleste om en skal dømme etter kommentarene han får på utspillene.

Jeg har ikke sett annet enn at det Rana beskriver som et “emosjonellt hatforhold” er bygget på fakta, erfaring rundt Microsofts historie og deres holdninger til standarder. Jeg ser ikke noe irrasjonelt hat til Microsoft. Jeg ser sunn faglig skepsis til en bedrift som er dømt for monopolvirksomhet og som har en tvilsom historie med å sabotere standarder.

Hva mener han ligger bak Håkon W. Lie og Knut Yrvins eller andres agenda mot Microsoft om ikke faglige argumenter?

Slik jeg ser det vil de fleste av OOXML sine motstandere vil tjene på å ha to dokumentformater dersom virkeligheten er så rosenrød som Rana beskriver. For de som lager programmer så vil OOXML-støtte medføre en verdiøkning i deres produkter. For de som driver konsulentvirksomhet vil enda et dokumentformat bety enda flere timer som føres. Hvem av disse vil vel ikke tjene enda mer penger? Når selskaper og personer allikevel går mot OOXML så er grunnen selvsagt ikke et irrasjonelt hat mot Microsoft. Grunnen er at OOXML er en svak standard fra en monopolist, og at virkeligheten er langt fra så idyllisk som Rana beskriver den.

Som en motsetning, så kommer mange av motstanderene med gode argumenter og de har kilder å vise til. De lirer ikke av seg selvfølgeligeheter som alle er enige i eller snakker rundt grøten.

Jeg har fulgt Rana sine utspill i denne debatten i en god tid nå. Mitt inntrykk er at han forsøker å slite ut sine motdebatanter ved å gjøre alt for å unngå å svare på deres spørsmål og ty til billige triks på å avspore diskusjonen. Og det er forlengst blitt kjedelig.

Mobiltelefonen er for lengst mye mer enn kun en telefon. Den er en kalender, vekkeklokke, kamera, GPS; vi bruker den til å surfe med, til å høre på musikk, sende meldinger, osv osv. Vi kobler den opp mot andre telefoner, mot PC’en, mot GPS’en eller bilen. Vi følger med på forskjellige nettsteder mens vi er borte fra hjemme-PC’en, eller leser aviser på den. Ja, også ringer vi med den.

Alle håndholde dingser blir før eller siden nok en funksjon på din telefon. Så da blir jo spørsmålet; hva kommer vi til å kalle denne dingsen om noen år?

Jeg lurer altså naturligvis på:

Vil vi fortsatt kalle den en “mobiltelefon”, selv om telefonen bare er en del av det vi bruker den til? Eller vil vi komme opp med et annet navn på den? Bruker vi den mest til å ringe med, eller kommuniserer vi heller på andre måter?

Og når kommer vi eventuelt til å se dette nye navnet? (Og slipper vi at det blir “iPhone”?) 1 år? 5 år? 10 år?

Jeg tror at innen få (5) år, så vil vi kalle den ved et annet navn. Men, hva den kommer til å kalles er jeg usikker på. Bidra gjerne med dine egne spekulasjoner.

Rana er frempå igjen - denne gangen med en krass irettesettelse av Håkon Wium Lie (som vel er kjent for de fleste). Håkon ble intervjuet om OOXML for litt siden og Rana forsøker å motbevise dette ved å åpne et OOXML-dokument i OpenOffice.

Bakgrunnen

Bakgrunnen er Håkons uttalelse om at han sammenliknet fordelen vi gir Microsoft ved å godkjenne OOXML som en ISO-standard med at folk må betale en “skatt” til Microsoft. Jeg synes det er en helt grei sammenlikning, spesielt med tanke på at den er utført på stående fot foran kamera. Hadde han uttrykt seg skriftlig så hadde vi kanskje sett et noe mer diplomatisk svar.

At Rana går aggressivt etter personer på denne måten har vi hørt eksempler på før. Det er ikke noe nytt. Jeg begynner strengt tatt å gå lei. Det som derimot har vært interessant er den påfølgende diskusjonen der folk har forsøkt å åpne dette dokumentet.

Så la oss forsøke

Undertegnede satt i tre kvarter før han innså at det var bedre ting å bruke en fredags kveld på. Debatten på digi viser flere eksempler der folk har forsøkt uten å få åpnet noe. På EFN-listen skapte Rana sitt utspill en lang epost-tråd der folk forsøkte å åpne dokumentet. Så langt har jeg ikke sett at noen rapportert at de har greid det. Fredrik E. Nilsen måtte avklare på digi sitt forum at trikset var å laste ned et tredjeparts program som gjør (MS)OOXML-filen om til et ODF-dokument. Han måtte presisere at det var “kan vises i OpenOffice” Rana hadde ment, og ikke “åpnes i OpenOffice”.

Jeg vet det finnes mange tekniske personer på digi sitt forum, og den tekniske ekspertisen på EFN-listen er absolutt respektabel. Når disse har såpass problemer med å få åpnet Rana sitt dokument så synes jeg dette taler for seg selv.

Hvems påstand står?

Når ingen (eller få) med teknisk anlegg får til å åpne Rana sitt dokument så synes jeg det er søkt av Rana å forvente at en vanlig forelder (Håkon W. Lie sitt eksempel) skal få åpnet dokumentet. Det er selvfølgelig en viss sjans - det er også en viss sjans for at du skal få Yatzi på første kast.

Vi kan vel være enig om er at det er gode grunner til at norske lærere ikke sender LaTeX til foreldre på barneskolen. Det er klart at enkelte foreldre vil kunne klare å åpne og bruke LaTeX-dokument. Men som argument for at LaTeX er en god løsning er litt søkt.

Slik jeg ser det så holder Håkon W. Lie sin påstand absolutt vann.

Avleder oppmerksomheten

Dette er selvfølgelig ikke alvorlig ment av Rana. Det er nok et forsøk på å avspore debatten fra en teknisk debatt til flisespikkeri over påstander. Han vet at visse påstander er som å kaste en saftig biff ut til en flokk med hunder. Han vet hvilke utsagn som er kontroversielle og som får oss til å fly i taket. Vi bruker all vår oppmerksomhet på å motbevise tøvete påstander og dissekere tall i Microsoft sine “undersøkelser”. Imens slipper Rana unna den diskusjonen vi burde hatt. Dette har han åpenbart lykkes med, og han har fått meg til å synde nok en gang. Microsoft har i alle fall fått valuta for pengene sine i Norge.

Digi har fått til et intervju med Patrick Durusau der han igjen tar til orde for at to standarder er bedre enn én og at ISO kan reparere OOXML. Han sier en del lurt om standarder, men (med all respekt), det virker som at han stiller svakere når det kommer til Microsofts historie og de tekniske og politiske aspektene. Rob Weir har gått gjennom Durusaus påstander tidligere, og er absolutt anbefalt lesing.

“ODF-redaktøren støtter OOXML”

Det er egentlig synd han ikke følger med på pressedekningen om seg selv. Han bør være klar over til hvilken grad Microsofts ansatte har brukt “ODF-redaktørens” uttalelser i sitt spinn for å undergrave ODF. Det som i realiteten vel er en ganske nøytral redaktør for flere standarder blir forsøkt fremstilt som at ODF sin Gudfar ser lyset og hopper på OOXML-toget.

Han er nøytral og vil ikke fremme ODF på bekostning av OOXML. Ser man isolert på det som direkte angår standardene, så er nok dette riktig.

Nøytraliteten og det at hans meninger begrenser til selve standardiseringsarbeidet kommer frem når journalisten fra digi spør han om hvilket alternativ han mener Norge bør gå for.

Alternativene er altså:

1. Ikke godkjenne bruk av OOXML til offentlig publisering av informasjon
2. Godkjenne OOXML på lik linje med ODF
3. Godkjenne OOXML, men kreve at alle offentlige redigerbare dokumenter publiseres i både ODF og OOXML

[…] når digi.no har lagt problemstillingen frem for Patrick Durusau for så å be om hans kommentar, blir han sittende å tenke lenge. Veldig lenge.

• Jeg tenker… Jeg prøver å tenke ut noe fornuftig å svare, sier Durusau etter omtrent ett minutt.

Durusau er tydeligvis veldig diplomatisk av natur. Han ser problemstillingen, og ser at den besluttningen trolig vil få mye å si for utbredelsen av formatet han selv jobber med. Likevel ønsker han ikke å gi den norske fornyingsministeren råd om hvilket alternativ hun bør gå for.

For standardene isolert er det helt klart positivt med konkurranse. Men i praksis vil vi måtte ta stilling til spørsmål som dette. Vi vil måtte velge mellom kostnader - enten ved at det stilles unødvendige krav til brukerene eller ved øknomiske kostnader.

Men bland inn den virkelige verden..

Alterativ 1 er kontroversielt. Det vil legge press på Microsoft for å implementere ODF-støtte på bekostning den vanlige brukeren som ikke er vant til annet enn “word-dokumenter”. Fornyingsministeren ønsker neppe å la vanlige folk ta støyten på denne måten, selv om dette nok er det beste pressmiddelet for å få på plass ODF-støtte.

Alternativ 2 vil skape forvirring ved at folk må forholde seg til to formater som fyller samme behov. Vi har problematikken fra pkt 1, samtidig som man gir Microsoft et konkurransefortrinn.

Alternativ 3 vil påføre ekstra kostnader. Staten vil kunne spare mye ved å gå over til ODF, men dette vil spises opp dersom man (i verste fall) blir nødt til å bruke Microsoft sine programmer parallelt.

Virkeligheten vil ligge et sted i mellom. Det kommer sannsynligvis fri programvare som på en eller annen måte klarer å implementere lovlig og akseptabel støtte OOXML. Forhåpentligvis kommer dette før Microsoft patcher sin kode og kaprer markedet. Konkurransen er ikke rettferdig i og med at Microsoft har programmer som er mer enn 90% ferdig og en standard som gir rom for valgfrihet. Det er iallefall et faktum at så fort man ser på forhold utenom det som direkte berører standarden så blir bildet mer komplisert.

Det blir iallefall en spennende tid fremover. Norge må avgjøre en strategi i forhold til OOXML i offentlig sektor. Her kommer det også til å bli bråk uansett hvilken avgjørelse de lander på. Jeg vil også til å følge med på hvordan Microsoft vil bruke formatet i tiden fremover; hvilket grep de får på markedet mens ISO prøver å få standarden til å flyte, og i hvilken grad FLOSS-utviklere må bruke tiden sin på å reverse-engineere Microsoft sin tolkning av standarden.

The New York Times har skrevet om OOXML-avgjørelsen der Steve Peppers klage til ISO også er nevnt. Det kommer frem at Roger Frost, en ISO-talsmann, mener ISO vil se bort fra Peppers klager.

Det skrives også litt om avstemmingen i andre land. Malaysia sin linje er interessant - der ble representanter for Microsoft og IBM som ikke var invitert bedt om å holde seg unna kommitearbeidet. Microsoft fikk ikke utøvd sine triks i samme grad som de gjorde i Norge. Det er vel ingen overaskelse at Malaysia landet på en nei-stemme til OOXML.

Ivar Jachwitz blir også sitert på at de faktisk tok hensyn til de ferdigskrevne brevene som Microsoft sendte gjennom en rekke norske selskaper - som i varierende grad husket å fylle inn sitt eget navn og signatur. Etter møtet i 2007 fikk vi høre at disse brevene ikke ville bli lagt vekt på.

En annen artig notis er jo at Dagbladet (så vidt jeg kan se) ikke har nevnt debatten rundt juksing i Standard Norge i det hele tatt. The New York Times tydligvis mener dette er verdt en artikkel. Dagbladet er kanskje opptatt med å dekke viktige ting som hvor god bakkekontakt Paris Hilton har eller fortelle deg at travle jenter trenger en sexy framtoning.

Shahzad Rana trekker frem 2007-avgjørelsen i OOXML-saken og peker på at prosessen var den samme i 2007, uten at det høstet kritikk dengang. Avgjørelsen og begrunnelsen for denne skiller seg derimot fundamentalt.

Begynte på nok et svar på Shahzad Rana sin blogg. Det ble litt omfattende, så det kvalifiserer vel heller til et innlegg her.

Shahzad Rana:

Den gang…

Da Standard Norge i slutten av august avga en foreløpig nei-stemme, var det interessant nok ingen sterke reaksjoner å spore. Tvert i mot uttalte flere av Open XML motstanderne seg positivt om prosessen. Trond Heier i Linpro uttalte til PC World 31. august: “Dette er sterkt gjort av Standard Norge, som har klart å ri av en storm. De har stått ved sin integritet i forhold til å sikre standardens kvalitet.” Overfor Digi mente han at Standard Norge hadde gjort en god jobb og vist stor faglig integritet i en svært presset situasjon.” Prosessen var den samme da som nå.

Jeg forstår ikke hvorfor du sammenlikner avgjørelsen i 2007 med den siste. De er fundamentalt forskjellige.

2007

Når avgjørelsen i 2007 ble tatt så skrev SN: “Vi finner imidlertid for mange svakheter i OOXML til å kunne godkjenne det foreliggende dokumentet som forslag til ISO-standard i sin nåværende form.”

Dette er helt riktig og i tråd med det så å si alle hevdet. SN hadde motstått Microsoft sin brevkampanje, så jeg kan ikke se annet enn at Trond Heier hadde sitt på det tørre når det gjelder utalelsene over.

Selv du må vel innse at ditt opprinnelig standpunkt i 2007 var galt - det ble jo faktisk funnet en rekordstor mengde punkter som måtte utbedres!

2008

Siste avgjørelsen skiller seg fra 2007-avgjørelsen ved at standarden fortsatt inneholdt svakheter. Premissene var at dersom ikke svakhetene var utbedret, så skulle forslaget avvises.

Av grunner som fortsatt er ukjent velger SN allikevel å se bort fra dette faktum.

Når konsensus i komiteen er målet med tanke på en avgjørelse så er det rart at SN ser bort i fra det store flertallet. Grunnen til at dette er gjort er også ukjent.

Det som skjedde var at de så bort fra de opprinnelige premissene og fant opp en unnskyldning om at det var bedre for brukerene at de kontrollerte en halvgod standard enn at noen andre gjorde det. Dette er en unnskyldning og ikke en begrunnelse.

Grunnen til at dette ble gjort er også et mysterium.